idnits 2.17.1 draft-woodyatt-ald-03.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 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1056. 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 (July 31, 2008) is 5746 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 4960 (Obsoleted by RFC 9260) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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 July 31, 2008 5 Expires: February 1, 2009 7 Application Listener Discovery (ALD) for IPv6 8 draft-woodyatt-ald-03 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 February 1, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 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 Acknowledgment . . . . . . . . . . . . . . . . . 17 77 6. APPLICATION PROGRAMMING INTERFACE . . . . . . . . . . . . . . 18 78 6.1. Normal Behavior of IPv6 Sockets . . . . . . . . . . . . . 18 79 6.2. Extensions to BSD Socket Interface . . . . . . . . . . . . 19 80 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 19 81 8. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 20 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 85 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 86 A.1. draft-woodyatt-ald-02 to draft-woodyatt-ald-03 . . . . . . 21 87 A.2. draft-woodyatt-ald-01 to draft-woodyatt-ald-02 . . . . . . 21 88 A.3. draft-woodyatt-ald-00 to draft-woodyatt-ald-01 . . . . . . 22 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 Intellectual Property and Copyright Statements . . . . . . . . . . 23 92 1. INTRODUCTION 94 In "Local Network Protection for IPv6" [RFC4864], IETF recommends 95 'simple security' capabilities for residential and small office 96 gateways that prohibit, by default, all inbound traffic except those 97 packets returning as part of locally initiated outbound flows. It 98 further recommends "an easy interface which allows users to create 99 inbound 'pinholes' for specific purposes such as online gaming." 101 In existing IPv4 gateways, where Network Address Translation (NAT) is 102 commonly used for IPv4 network protection and firewalling, management 103 applications typically provide an interface for manual configuration 104 of pinholes. However, this method is unacceptably difficult for many 105 non-technical Internet users, so most products in the market today 106 also implement one or more automatic methods for creating pinholes. 108 These methods include: 110 o "NAT Port Mapping Protocol" [NAT-PMP] 112 o "Internet Gateway Device (IGD)" standardized device control 113 protocol of Universal Plug And Play [UPnP-IGD] 115 The basic mechanism of these protocols is that applications notify 116 the firewall of their expectation to receive inbound flows, and 117 pinholes are opened accordingly. In the IPv4/NAT case, these 118 protocols are also used for automatic creation of network address 119 translator state in addition to packet filter state. In the IPv6 120 case, no network address translation is necessary, but packet filters 121 still contain state and pinholes must still be created accordingly. 123 At present, no similar protocol exists for automatically notifying 124 firewalls of the pinholes required by IPv6 endpoint applications. 125 This document defines a method for making such notifications. 127 (NOTE: It is expected that this section will be revised once the 128 concept presented in this document is well socialized in the Internet 129 engineering and operations community.) 131 2. TERMINOLOGY 133 2.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 Paragraphs that begin with "EXPERIMENTAL:" describe how this protocol 140 may be implemented using numbers assigned by IANA for experimental 141 usage. Prior to publication of this document as a Request For 142 Comments, the RFC Editor is directed to delete all paragraphs that 143 begin with this tag and all references to "Experimental Values in 144 IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers" [RFC4727]. 146 2.2. Special Terms and Abbreviations 148 firewall: A node with the capability of administratively prohibiting 149 the flow of packets between a protected "interior" region of the 150 Internet and an "exterior" region. 152 flow initiation: The start of communications between two or more 153 nodes in an application protocol, e.g. the TCP SYN packets that 154 comprise the start of a telnet session, the UDP packets that start 155 an NTP exchange, the first IPsec ESP packet for a new security 156 parameter index (SPI), et cetera. 158 3. PROTOCOL OVERVIEW 160 This protocol solves a set of problems related to the interaction 161 between applications awaiting reception of transport flow initiations 162 (listeners) and IPv6 nodes comprising packet filtering network policy 163 enforcement points (firewalls). 165 From the perspective of any given IPv6 node, the region of the 166 Internet between itself and a given firewall is the 'interior' domain 167 of that firewall. All other regions of the Internet are the 168 'exterior' from the perspective of the node. The ALD protocol is 169 concerned only with the problems associated with listeners on nodes 170 reachable only on the interior interfaces of firewalls in receiving 171 transport flow initiations from nodes reachable only on exterior 172 interfaces. 174 The ALD protocol defines methods for solving each of the following 175 problems: 177 Listener Discovery: How firewalls discover the transport protocols 178 and addresses of applications awaiting reception of flow 179 initiations. 181 Firewall Discovery: How nodes discover what firewalls to notify that 182 applications are awaiting reception of transport flow initiations. 184 Firewall Reset Detection: How nodes discover that firewalls have 185 been reset and now require nodes to restart their listener 186 discovery functions. 188 Application Programming Interface: Extensions to the IPv6 API are 189 defined to permit applications to be selective about how their 190 transport endpoints are subjects of listener notification. 192 When nodes join network segments where one or more global scope 193 address prefixes are advertised, they use a Firewall Discovery method 194 to build or learn a list of firewalls to notify that applications are 195 listening at specific unicast addresses. They send Firewall 196 Solicitation messages to a specified destination address, which may 197 be a multicast destination, and receive directed Firewall 198 Advertisement messages in response. 200 Nodes send Listener Notification messages to firewalls to inform them 201 of their expectations in receiving flow initiations. These messages 202 are sent for each listener endpoint address in use, with retransmits 203 as necessary. Firewalls send Listener Acknowledgment messages to 204 squelch further retransmits. 206 It's important to recognize the notifications are not requests. 207 Firewalls are under no obligation to change their behavior in 208 response to receiving application listener notifications. Nodes are 209 provided with no assurance that inbound flow initiations are or are 210 not prohibited at firewalls in the network, whether advertised with 211 ALD or not. 213 Every ALD message sent by a firewall includes a measurement of the 214 elapsed time since their state was last reset. This is so nodes may 215 recognize when it may be necessary to resend all its listener 216 notifications. Firewalls periodically send announcements, but in 217 general not at a frequency high enough that nodes may rely on the 218 absence of them to detect the failure of a firewall. 220 3.1. Firewall Discovery 222 For the purposes of application listener discovery, firewalls have an 223 "interior" subject to the policy requiring listeners to notify them, 224 and an "exterior" corresponding to the region of the Internet from 225 which flow initiations are subject to administrative prohibitions. 227 Nodes transmit Firewall Solicitation messages and receive Firewall 228 Advertisement messages in acknowledgment. Firewall Advertisement 229 messages inform nodes of firewalls that may prohibit flow initiations 230 from exterior sources to the node. 232 A new neighbor discovery option is defined for use in Router 233 Advertisements to specify the destination address and hop limit that 234 nodes are expected to use when sending Firewall Solitation messages. 236 3.2. Listener Discovery 238 Nodes send Listener Notification messages to firewalls according to 239 their policy requirements. These notifications inform firewalls of 240 which nodes, protocols, and transport addresses are expecting to 241 receive inbound flow initiations. Firewalls send Listener 242 Acknowledgment messages in response to inform listeners how much time 243 the application can expect receive flow initiations. 245 Nodes may notify firewalls that they expect to receive all inbound 246 traffic, regardless of protocol or transport address. Alternatively, 247 they can send notifications for narrower constraints on what to pass 248 through to listening nodes. 250 3.3. Firewall Reset Detection 252 Firewalls periodically multicast Firewall Advertisement messages on 253 their "interior" interfaces. Immediately after the state in a 254 firewall resets, the transmit interval for these advertisements are 255 very short, rapidly increasing thereafter. 257 Nodes receive Firewall Advertisements directly and compare the 258 Elapsed Time Since Reset (ETSR) against the last value received in 259 any previous message. Computing their own conservative estimates of 260 the expected elapsed time, nodes are able to recognize when 261 retransmitting their listener notifications might be necessary. 263 3.4. Application Programming Interface 265 Applications need not be written with specific awareness of listener 266 discovery. Operating systems are implemented with default parameters 267 suitable for all but the rarest of exceptions. 269 For example, nodes only inform firewalls about TCP sockets when they 270 require transport address level notification and the node sets a TCP 271 socket into the LISTENING state. Furthermore, the timing limits on 272 notifications vary between temporary privacy addresses and 273 permanently assigned addresses, i.e. a TCP socket bound to a 274 temporary address will have a short binding time in the firewall 275 compared to a TCP socket that binds to a permanent address. 277 Some extensions to the application programming interface are defined 278 for those few applications that need them. These extensions allow 279 applications to disable listener notification or override timing 280 parameters on a case by case basis. 282 4. OPTION FORMATS 284 The need for nodes to proceed with firewall discovery is signaled by 285 the presence of a Firewall Discovery option sent in Router 286 Advertisement messages. 288 4.1. Firewall Discovery Router Advertisement Option 290 In Router Advertisements without the "other stateful configuration" 291 flag set, the Firewall Discovery Option informs nodes of the 292 destination address and hop limit for sending Firewall Solicitation 293 messages. 295 Firewall Discovery Option 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type | Length | Hop Limit | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 302 | | 303 + + 304 | Reserved | 305 + + 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 + + 310 | | 311 + Destination Address + 312 | | 313 + + 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Type: TBD 319 Length: 4 321 Hop Limit: 322 The hop limit nodes use to send Firewall Solicit messages. 324 Reserved: This field is unused. It MUST be initialized to zero by 325 the sender and MUST be ignored by the receiver. 327 Destination Address: 328 The destination address for nodes to use when sending 329 Firewall Solicit messages. 331 Routers MUST NOT send Router Advertisements containing the Firewall 332 Discovery option if the "other stateful configuration" flag is set. 333 Likewise, nodes MUST NOT process the Firewall Discovery Option unless 334 the "other stateful configuration" flag is set in the Router 335 Advertisement that contains it. 337 Routers MUST NOT send Router Advertisements with more than one 338 Firewall Discovery Option present. If nodes receive such Router 339 Advertisements, then nodes MUST NOT process any of the Firewall 340 Discovery Options. 342 Nodes that process Firewall Discovery Options in Router 343 Advertisements MUST NOT send any Firewall Solicitation messages from 344 any addresses in the advertised prefixes except to the specified 345 destination address, and with the specified hop limit. 347 Nodes receiving Router Advertisements with the "other stateful 348 configuration" flags not set, and without a Firewall Discovery Option 349 present, MAY send Firewall Solicitation messages from the advertised 350 prefixes to any address and with any hop limit. 352 EXPERIMENTAL: The type value 253 is defined in section 5.1.3 of 353 "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP 354 Headers" [RFC4727] for use with experimental protocols. Operation of 355 ALD in experimental mode requires the four octet code 0x6161706c be 356 inserted between the Length and Hop Limit fields, and the size of the 357 Reserved field to be reduced by four octets to keep the destination 358 address aligned. Experimental Firewall Discovery Options, i.e. those 359 described in this paragraph, MUST NOT be processed unless the type 360 value is 253 and the four octet code is present in the required 361 position. 363 5. MESSAGE FORMATS 365 ALD is a sub-protocol of ICMPv6, that is, ALD message types are a 366 subset of the set of ICMPv6 messages, and ALD messages are all 367 identified in IPv6 packets by a preceding Next Header value of 58. 368 ALD messages all have the same Type value, [TBD, assigned by IANA], 369 and their function is differentiated by the Code value. 371 This document defines the formats for ALD messages with the following 372 Code values: 374 ALD Message Codes 376 +------+-------------------------+-------------+ 377 | Code | Description | Reference | 378 +------+-------------------------+-------------+ 379 | 1 | Firewall Solicitation | Section 5.1 | 380 | 2 | Firewall Advertisement | Section 5.2 | 381 | 3 | Listener Notification | Section 5.4 | 382 | 4 | Listener Acknowledgment | Section 5.5 | 383 +------+-------------------------+-------------+ 385 Table 1 387 All other Code values are reserved for future use. Nodes MUST NOT 388 send messages containing them. 390 Firewalls MUST NOT prohibit the flow of ALD messages from their 391 exterior to their interior. 393 5.1. Firewall Solicitation 395 Nodes send Firewall Solicitation messages to request firewalls to 396 respond with directed Firewall Advertisement messages. They are sent 397 periodically to the destination addresses specified in any Firewall 398 Discovery Options received in Router Advertisements for networks they 399 join. 401 Firewall Solicitation 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type | Code | Checksum | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Type: TBD. Assigned by IANA to ALD messages. 411 Code: 1. 413 Checksum: 414 ICMPv6 checksum. 416 EXPERIMENTAL: Nodes operating in experimental mode MAY send the 417 Experimental Firewall Solicitation message, i.e. the same message 418 except with type value 100 as defined in "Internet Control Message 419 Protocol (ICMPv6)" [RFC4443] for use in experimental protocols, and 420 the four octet code 0x6161706c appended after the checksum. Nodes 421 MUST NOT send Experimental Firewall Solicitation messages to 422 destination addresses received in the regular Firewall Discovery 423 Option. 425 5.2. Firewall Advertisement 427 Firewalls send Firewall Advertisement messages to notify listeners 428 reachable on their interior interfaces that inbound flow initiations 429 to a specific prefix are subject to policy enforcement. 431 Firewalls Advertisement 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type | Code | Checksum | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Elapsed Time Since Reset | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | | 441 + Reserved +-+-+-+-+-+-+-+ 442 | | IPL | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | | 445 + + 446 | | 447 + Interior Prefix + 448 | | 449 + + 450 | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Type: TBD. Assigned by IANA to ALD messages. 455 Code: 2. 457 Checksum: 458 ICMPv6 checksum. 460 Elapsed Time Since Reset: 461 Number of elapsed seconds since the firewall state was last 462 reset. 464 IPL: The length of the interior prefix. Values less than 48 are 465 reserved. Senders MUST NOT use them, and receivers MUST NOT 466 process any messages that contain them. (Note: the width of 467 this field is seven bits.) 469 Reserved: 470 This field is unused. It MUST be initialized to zero by the 471 sender and MUST be ignored by the receiver. 473 Interior Prefix: 474 The IPv6 address prefix on the interior subject to the 475 firewall policy. 477 Starting when a firewall begins operating on the interior prefix from 478 its reset state, it MUST periodically send Firewall Advertisement 479 messages on all its interfaces where the interior prefix is reachable 480 using a Hop Limit of 255 to the organizational scope All Nodes 481 multicast address, FF08::1. The time interval between multicast 482 transmissions MAY be of any duration. The recommended period is 483 every two seconds for the first ten seconds after the state is reset, 484 followed by a doubling of the interval for every transmission 485 thereafter until the interval reaches a maximum of one hour. 487 EXPERIMENTAL: Firewalls operating in experimental mode MAY send 488 Experimental Firewall Advertisement messages, i.e. the same message 489 except with type value 100 as defined in "Internet Control Message 490 Protocol (ICMPv6)" [RFC4443] for use in experimental protocols and 491 the four octet code 0x6161706c inserted between the Checksum and 492 Elapsed Time Since Reset fields. These are sent to the 493 organizational scope "any private experiment" multicast destination 494 address, i.e. FF08::114, instead of the All Nodes address. Nodes 495 MUST NOT send Experimental Firewall Advertisement messages to any 496 other multicast destination. 498 5.3. Listener Address Specifier 500 Listener Notification and Listener Acknowledgment messages (see 501 below) each contain Listener Address Specifier elements. These are 502 structured data that describe the transport layer component of a 503 listener address that firewalls are expected to filter, e.g. TCP and 504 UDP ports, etc. As a general rule, this protocol number is expected 505 to match the upper-layer-protocol of the outer-most IPv6 header 506 (including all its extension headers). See "Internet Protocol, 507 Version 6" [RFC2460] for details. 509 The first octet of any Listener Address Specifier is an Internet 510 protocol number, which serves as the type discriminator for a variant 511 subtype of Listener Address Specifier elements. 513 Nodes MUST NOT send Listener Address Specifiers with protocol numbers 514 assigned for identifying IPv6 extension headers. 516 5.3.1. All Protocols Listener Address Specifier 518 Nodes notify firewalls that inbound flow initiations are expected by 519 sending a Listener Notification message with the All Protocols 520 Listener Address Specifier. This is a single octet with all zero 521 bits, followed by a reserved field of three octets. 523 All Protocols Listener Address Specifier 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | 00 | Reserved | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Reserved: 532 This field is unused. It MUST be initialized to zero by the 533 sender and MUST be ignored by the receiver. 535 Note: the value of zero is used here for specifying all protocols, 536 even though it is used in IPv6 for specifying hop-by-hop options. 538 5.3.2. All Specific Protocol Listener Address Specifier 540 Nodes notify firewalls that all inbound flow initiations for a 541 specific upper-layer protocol are expected by sending a Listener 542 Notification message with an All Specific Protocol Listener Address 543 Specifier. This is a single octet with the protocol number, followed 544 by three octets of zeroes. 546 All Specific Protocol Listener Address Specifier 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Protocol | 000000 | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Protocol: 555 The upper-layer protocol number. 557 Nodes MUST NOT send All Specific Protocol Listener Address Specifier 558 elements with protocol numbers reserved for IPv6 header extensions in 559 the Protocol field. 561 Nodes MUST NOT send All Specific Protocol Listener Address Specifier 562 elements with 255 in the Protocol field. 564 5.3.3. Encapsulating Security Payload Listener Address Specifier 566 Nodes notify firewalls of that inbound IP Encapsulating Security 567 Payload (ESP) flows [RFC4303] are expected by sending a Listener 568 Notification message with the Encapsulating Security Payload Listener 569 Address Specifier. This is a single octet with the ESP protocol 570 number in it, followed by a reserved field of three octets. 572 Encapsulating Security Payload Listener Address Specifier 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | 50 | Reserved | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | SPI | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Reserved: 583 This field is unused. It MUST be initialized to zero by the 584 sender and MUST be ignored by the receiver. 586 SPI: Security Parameter Index for inbound flow. 588 An ESP Listener Address Specifier with a value of all zero octets in 589 the SPI field is equivalent to the All Specific Protocol Listener 590 Address Specifier with the ESP protocol number in the Protocol field. 592 5.3.4. TCP Listener Address Specifier 594 Nodes notify firewalls that inbound Transmission Control Protocol 595 (TCP) connections [RFC0793] are expected by sending a Listener 596 Notification message with the TCP Listener Address Specifier. This 597 is a single octet with the TCP protocol number in it, followed by a 598 reserved octet, followed by the TCP port number for the application 599 endpoint. 601 TCP Listener Address Specifier 603 0 1 2 3 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | 6 | Reserved | TCP Port Number | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Reserved: 610 This field is unused. It MUST be initialized to zero by the 611 sender and MUST be ignored by the receiver. 613 TCP Port Number: 614 The TCP port for the application endpoint. 616 A value of zero in the TCP Port Number field indicates all TCP flows. 617 This is identical to the All Specific Protocol Listener Address 618 Specifier for TCP. 620 5.3.5. UDP Listener Address Specifier 622 Nodes notify firewalls that inbound User Datagram Protocol (UDP) flow 623 initiations [RFC0768] are expected by sending a Listener Notification 624 message with the UDP Listener Address Specifier. This is a single 625 octet with the UDP protocol number in it, followed by a reserved 626 octet, followed by the UDP port number for the application endpoint. 628 UDP Listener Address Specifier 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | 17 | Reserved | UDP Port Number | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 Reserved: 637 This field is unused. It MUST be initialized to zero by the 638 sender and MUST be ignored by the receiver. 640 UDP Port Number: 641 The UDP port for the application endpoint. 643 A value of zero in the UDP Port Number field indicates all UDP flows. 644 This is identical to the All Specific Protocol Listener Address 645 Specifier for UDP. 647 5.3.6. SCTP Listener Address Specifier 649 Nodes notify firewalls that inbound Stream Control Transport Protocol 650 (SCTP) flow initiations [RFC4960] are expected by sending a Listener 651 Notification message with the SCTP Listener Address Specifier. This 652 is a single octet with the SCTP protocol number in it, followed by a 653 reserved octet, followed by the SCTP port number for the application 654 endpoint. 656 SCTP Listener Address Specifier 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | 132 | Reserved | SCTP Port Number | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 Reserved: 665 This field is unused. It MUST be initialized to zero by the 666 sender and MUST be ignored by the receiver. 668 UDP Port Number: 669 The SCTP port for the application endpoint. 671 A value of zero in the SCTP Port Number field indicates all SCTP 672 flows. This is identical to the All Specific Protocol Listener 673 Address Specifier for SCTP. 675 5.3.7. DCCP Listener Address Specifier 677 Nodes notify firewalls that inbound Datagram Congestion Control 678 Protocol (DCCP) flow initiations [RFC4340] are expected by sending a 679 Listener Notification message with the DCCP Listener Address 680 Specifier. This is a single octet with the DCCP protocol number in 681 it, followed by a reserved octet, followed by the DCCP port number 682 for the application endpoint. 684 DCCP Listener Address Specifier 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | 33 | Reserved | DCCP Port Number | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 Reserved: 693 This field is unused. It MUST be initialized to zero by the 694 sender and MUST be ignored by the receiver. 696 UDP Port Number: 697 The DCCP port for the application endpoint. 699 A value of zero in the DCCP Port Number field indicates all DCCP 700 flows. This is identical to the All Specific Protocol Listener 701 Address Specifier for DCCP. 703 5.4. Listener Notification 705 When a node expects to receive inbound flows from the exterior of a 706 firewall, it MAY send a Listener Notification message to signal that 707 inbound flow initiations should not be prohibited. 709 Listener Notification 711 0 1 2 3 712 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 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Type | Code | Checksum | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Expected Duration | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Listener Address Specifier 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 721 Type: TBD. Assigned by IANA to ALD messages. 723 Code: 3. 725 Checksum: 726 ICMPv6 checksum. 728 Expected Duration: 729 The number of seconds the application expects to be 730 listening. 732 Listener Address Specifier: 733 Describes the transport address of the application listener. 734 See Section 5.3. 736 Nodes MUST NOT send Listener Notification messages on any network to 737 any destinations other than the unicast source addresses from which 738 they receive Firewall Advertisement messages after joining the 739 network. 741 EXPERIMENTAL: Nodes operating in experimental mode MAY send the 742 Experimental Listener Notification message, i.e. the same message 743 except with type value 100 as defined in "Internet Control Message 744 Protocol (ICMPv6)" [RFC4443] for use in experimental protocols and 745 the four octet code 0x6161706c inserted between the Checksum and 746 Expected Time Interval fields. Nodes MUST NOT send Experimental 747 Listener Notification messages to destination addresses after 748 receiving any regular Firewall Advertisement messages from the same 749 source address. 751 5.5. Listener Acknowledgment 753 Firewalls send Listener Acknowledgment messages in response to 754 receiving Listener Solication messages from nodes. 756 Listener Acknowledgment 758 0 1 2 3 759 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 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Type | Code | Checksum | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Elapsed Time Since Reset | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Acknowledged Duration | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Listener Address Specifier 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 770 Type: TBD. Assigned by IANA to ALD messages. 772 Code: 4. 774 Checksum: 775 ICMPv6 checksum. 777 Elapsed Time Since Reset: 778 Number of elapsed seconds since the firewall state was last 779 reset. 781 Acknowledged Duration: 782 The number of seconds the firewall acknowledges the node will 783 be listening. 785 Listener Address Specifier: 786 Describes the transport address of the application listener. 787 See Section 5.3. 789 Firewalls MUST NOT transmit Listener Acknowledgment messages except 790 in response to received Listener Notification messages. 792 Firewalls MUST NOT transmit Listener Acknowledgment messages with an 793 Acknowledged Duration greater than the Expected Duration in the 794 corresponding Listener Notification message. 796 After receiving a Listener Acknowledgment message, nodes MUST NOT 797 transmit Listener Notification messages with a non-zero Requested 798 Lifetime and the same Listener Address Specifier unless the Requested 799 Lifetime is less than seven eighths (87.5%) of the Granted Lifetime 800 value. 802 EXPERIMENTAL: Firewalls operating in experimental mode MAY respond to 803 Experimental Listener Notification messages with the Experimental 804 Listener Acknowledgment message, i.e. the same message except with 805 type value 100 as defined in "Internet Control Message Protocol 806 (ICMPv6)" [RFC4443] for use in experimental protocols and the four 807 octet code 0x6161706c inserted between the Checksum and Elapsed Time 808 Since Reset fields. 810 6. APPLICATION PROGRAMMING INTERFACE 812 [ This section needs to be expanded to discuss how ALD functions are 813 related to the operation of the conventional socket layer interface, 814 i.e. how Listener Notifications are emitted when TCP sockets are put 815 into and taken out of the LISTENING states, etc. Additional socket 816 options for advanced usage may also be necessary here. Specific 817 description of behavior for sockets in O_NONBLOCK mode should be 818 defined. ] 820 Existing programming interfaces, e.g. the widely used BSD sockets 821 API, are sufficient for most applications. When TCP endpoints bound 822 to global addresses transition into the LISTENING state, firewalls 823 can be notified automatically with Listener Notification messages. 824 Similar methods can be used for all other transport protocols. 826 Some applications require finer control over whether and how to 827 notify firewalls of their listeners. This document recommends 828 extensions to system configuration, interface control messages and 829 socket options to meet their needs. 831 6.1. Normal Behavior of IPv6 Sockets 833 Applications using the BSD "listen(2)" function to place a TCP socket 834 into the LISTENING state MAY be blocked while ALD notifies the 835 appropriate firewalls. If the socket descriptor is opened with 836 "O_NONBLOCK" or is otherwise marked as non-blocking, then "listen(2)" 837 MAY return "EINPROGRESS" to indicate that ALD has not yet received 838 Listener Acknowledgment messages from all appropriate firewalls. It 839 MAY be possible to "select(2)" for completion by checking the socket 840 for writing. 842 Applications using the BSD "bind(2)" function with UDP sockets MAY be 843 blocked while ALD notifies the appropriate firewalls. If the socket 844 descriptor is opened with "O_NONBLOCK" or is otherwise marked as non- 845 blocking, then "bind(2)" MAY return "EINPROGRESS" to indicate that 846 ALD has not yet received Listener Acknowledgment messages from all 847 appropriate firewalls. It MAY be possible to "select(2)" for 848 completion by checking the socket for writing. 850 Implementations of SCTP and DCCP are expected to implement similar 851 methods of plumbing up ALD operations to the application layer. 853 If an application binds to specific interface addresses, then 854 Listener Notification messages MAY be sent only to those firewalls 855 with matching interior prefixes. 857 If a node receives a Listener Acknowledgment with an address 858 specification that indicates the firewall has already discovered the 859 application listener, then transmitting a Listener Notification MAY 860 be skipped. If no ALD messages are necessary, then the application 861 MUST receive the same service from the "bind(2)" and "listen(2)" 862 system functions as when ALD is not operating. 864 6.2. Extensions to BSD Socket Interface 866 A new system configuration variable of boolean type, 867 "net.inet6.icmp6.ald_enabled", MAY be available on nodes to control 868 whether ALD is enabled. The recommended default value is TRUE. 870 A new interface flag, "IFF_NOALD" MAY be available for disabling ALD 871 on a per-interface basis. The recommended default if for the flag 872 not to be set. The "ifconfig(8)" utility MAY provide the "-ald" 873 parameter for controlling this option. 875 A new socket option of boolean type, "IPV6_ALD_ENABLED" MAY be used 876 to control whether ALD is to be used on a per-socket basis. The 877 default value for is recommended to be TRUE unless 878 "net.inet6.icmp6.ald_enabled" is FALSE or the socket has already been 879 bound to an interface address for which the interface has the 880 "IFF_NOALD" flag set. 882 7. IANA CONSIDERATIONS 884 This memo includes several requests to IANA, which need to be 885 gathered into this section accordingly. 887 All drafts are required to have an IANA considerations section (see 888 the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] 889 for a guide). If the draft does not require IANA to do anything, the 890 section contains an explicit statement that this is the case (as 891 above). If there are no requirements for IANA, the section will be 892 removed during conversion into an RFC by the RFC Editor. 894 8. SECURITY CONSIDERATIONS 896 The author has not yet given sufficient consideration to security for 897 writing an adequate security considerations section. Some readers 898 have expressed concerns about spoofing. The author thinks protecting 899 unicast ALD messages with IPsec Authenticated Header is the 900 appropriate method for addressing such issues. An argument might be 901 entertained for protecting the privacy of Listener Notification and 902 Acknowledgment messages, and the author likewise believes IPsec 903 Encapsulating Security Payload is the appropriate method for that. 904 Key exchange for such security mechanisms should be specified by this 905 document if IETF consensus regards addressing these considerations as 906 essential. 908 All drafts are required to have a security considerations section. 909 See "Guidelines for Writing RFC Text on Security Considerations" 910 [RFC3552] for a guide. 912 9. References 914 9.1. Normative References 916 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 917 August 1980. 919 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 920 RFC 793, September 1981. 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, March 1997. 925 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 926 (IPv6) Specification", RFC 2460, December 1998. 928 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 929 RFC 4303, December 2005. 931 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 932 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 934 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 935 Message Protocol (ICMPv6) for the Internet Protocol 936 Version 6 (IPv6) Specification", RFC 4443, March 2006. 938 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 939 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 941 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 942 RFC 4960, September 2007. 944 9.2. Informative References 946 [I-D.narten-iana-considerations-rfc2434bis] 947 Narten, T. and H. Alvestrand, "Guidelines for Writing an 948 IANA Considerations Section in RFCs", 949 draft-narten-iana-considerations-rfc2434bis-09 (work in 950 progress), March 2008. 952 [NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port 953 Mapping Protocol (NAT-PMP)", November 2001, 954 . 956 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 957 Text on Security Considerations", BCP 72, RFC 3552, 958 July 2003. 960 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 961 E. Klein, "Local Network Protection for IPv6", RFC 4864, 962 May 2007. 964 [UPnP-IGD] 965 UPnP Forum, "Universal Plug and Play Internet Gateway 966 Device Standardized Gateway Device Protocol", 967 September 2006, 968 . 970 Appendix A. Change Log 972 A.1. draft-woodyatt-ald-02 to draft-woodyatt-ald-03 974 o Adjusted column widths in XML source. 976 A.2. draft-woodyatt-ald-01 to draft-woodyatt-ald-02 978 o Fixed spelling errors. 980 o Local Network Protection is now [RFC4864]. 982 o Fix some bugs related to [RFC2119] compliance. 984 o SCTP is now [RFC4960]. 986 A.3. draft-woodyatt-ald-00 to draft-woodyatt-ald-01 988 o Added geeky cross-references for TCP and UDP. 990 o Simplified description of ICMPv6 checksum field descriptions. 992 o Changed the All Protocols Listener Address Specifier to use zero 993 instead of 41, so that IPv6-in-IPv6 is eligible for specification. 995 o Added the SPI field to the ESP Listener Address Specifier. 997 o Added a note about zero UDP and TCP port numbers in the associated 998 Listener Address Specifiers. 1000 o Added Listener Address Specifiers for SCTP and DCCP. 1002 o Added the All Specific Protocol Listener Address Specifier element 1003 and changed the associated requirements language to allow nodes to 1004 send them, and to explicitly disallow protocol numbers 1005 corresponding to IPv6 header extensions and the reserved protocol 1006 number. 1008 Author's Address 1010 james woodyatt 1011 Apple Inc. 1012 1 Infinite Loop 1013 Cupertino, CA 95014 1014 US 1016 Email: jhw@apple.com 1018 Full Copyright Statement 1020 Copyright (C) The IETF Trust (2008). 1022 This document is subject to the rights, licenses and restrictions 1023 contained in BCP 78, and except as set forth therein, the authors 1024 retain all their rights. 1026 This document and the information contained herein are provided on an 1027 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1028 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1029 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1030 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1031 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1032 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1034 Intellectual Property 1036 The IETF takes no position regarding the validity or scope of any 1037 Intellectual Property Rights or other rights that might be claimed to 1038 pertain to the implementation or use of the technology described in 1039 this document or the extent to which any license under such rights 1040 might or might not be available; nor does it represent that it has 1041 made any independent effort to identify any such rights. Information 1042 on the procedures with respect to rights in RFC documents can be 1043 found in BCP 78 and BCP 79. 1045 Copies of IPR disclosures made to the IETF Secretariat and any 1046 assurances of licenses to be made available, or the result of an 1047 attempt made to obtain a general license or permission for the use of 1048 such proprietary rights by implementers or users of this 1049 specification can be obtained from the IETF on-line IPR repository at 1050 http://www.ietf.org/ipr. 1052 The IETF invites any interested party to bring to its attention any 1053 copyrights, patents or patent applications, or other proprietary 1054 rights that may cover technology that may be required to implement 1055 this standard. Please address the information to the IETF at 1056 ietf-ipr@ietf.org. 1058 Acknowledgment 1060 Funding for the RFC Editor function is provided by the IETF 1061 Administrative Support Activity (IASA).