IP Version 6 j h. woodyatt Internet-Draft Apple Intended status: Standards Track June 6, 2007 Expires: December 8, 2007 Application Listener Discovery (ALD) for IPv6 draft-woodyatt-ald-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 8, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies the protocol used by IPv6 nodes comprising stateful packet filters to discover the transport addresses of listening applications (that is, application endpoints for which incoming traffic may be administratively prohibited). Comments are solicited and should be sent to the author and the V6OPS Residential CPE Design Team mailing list at . woodyatt Expires December 8, 2007 [Page 1] Internet-Draft Application Listener Discovery June 2007 Table of Contents 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Special Terms and Abbreviations . . . . . . . . . . . . . 4 3. PROTOCOL OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Firewall Discovery . . . . . . . . . . . . . . . . . . . . 5 3.2. Listener Discovery . . . . . . . . . . . . . . . . . . . . 6 3.3. Firewall Reset Detection . . . . . . . . . . . . . . . . . 6 3.4. Application Programming Interface . . . . . . . . . . . . 6 4. OPTION FORMATS . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Firewall Discovery Router Advertisement Option . . . . . . 7 5. MESSAGE FORMATS . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Firewall Solicitation . . . . . . . . . . . . . . . . . . 9 5.2. Firewall Advertisement . . . . . . . . . . . . . . . . . . 10 5.3. Listener Address Specifier . . . . . . . . . . . . . . . . 11 5.3.1. All Protocols Listener Address Specifier . . . . . . . 12 5.3.2. All Specific Protocol Listener Address Specifier . . . 12 5.3.3. Encapsulating Security Payload Listener Address Specifier . . . . . . . . . . . . . . . . . . . . . . 13 5.3.4. TCP Listener Address Specifier . . . . . . . . . . . . 13 5.3.5. UDP Listener Address Specifier . . . . . . . . . . . . 14 5.3.6. SCTP Listener Address Specifier . . . . . . . . . . . 14 5.3.7. DCCP Listener Address Specifier . . . . . . . . . . . 15 5.4. Listener Notification . . . . . . . . . . . . . . . . . . 16 5.5. Listener Acknowledgement . . . . . . . . . . . . . . . . . 17 6. APPLICATION PROGRAMMING INTERFACE . . . . . . . . . . . . . . 18 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 18 8. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 A.1. draft-woodyatt-ald-00 to draft-woodyatt-ald-01 . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 woodyatt Expires December 8, 2007 [Page 2] Internet-Draft Application Listener Discovery June 2007 1. INTRODUCTION In "Local Network Protection for IPv6" [IPv6-NAP], IETF recommends 'simple security' capabilities for residential and small office gateways that prohibit, by default, all inbound traffic except those packets returning as part of locally initiated outbound flows. It further recommends "an easy interface which allows users to create inbound 'pinholes' for specific purposes such as online gaming." In existing IPv4 gateways, where Network Address Translation (NAT) is commonly used for IPv4 network protection and firewalling, management applications typically provide an interface for manual configuration of pinholes. However, this method is unacceptably difficult for many non-technical Internet users, so most products in the market today also implement one or more automatic methods for creating pinholes. These methods include: o "NAT Port Mapping Protocol" [NAT-PMP] o "Internet Gateway Device (IGD)" standardized device control protocol of Universal Plug And Play [UPnP-IGD] The basic mechanism of these protocols is that applications notify the firewall of their expectation to receive inbound flows, and pinholes are opened accordingly. In the IPv4/NAT case, these protocols are also used for automatic creation of network address translator state in addition to packet filter state. In the IPv6 case, no network address translation is necessary, but packet filters still contain state and pinholes must still be created accordingly. At present, no similar protocol exists for automatically notifying firewalls of the pinholes required by IPv6 endpoint applications. This document defines a method for making such notifications. (NOTE: It is expected that this section will be revised once the concept presented in this document is well socialized in the Internet engineering and operations community.) 2. TERMINOLOGY 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. woodyatt Expires December 8, 2007 [Page 3] Internet-Draft Application Listener Discovery June 2007 Paragraphs that begin with "EXPERIMENTAL:" describe how this protocol may be implemented using numbers assigned by IANA for experimental usage. Prior to publication of this document as a Request For Comments, the RFC Editor is directed to delete all paragraphs that begin with this tag and all references to "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers" [RFC4727]. 2.2. Special Terms and Abbreviations firewall: A node with the capability of administratively prohibiting the flow of packets between a protected "interior" region of the Internet and an "exterior" region. flow initiation: The start of communications between two or more nodes in an application protocol, e.g. the TCP SYN packets that comprise the start of a telnet session, the UDP packets that start an NTP exchange, the first IPsec ESP packet for a new security parameter index (SPI), et cetera. 3. PROTOCOL OVERVIEW This protocol solves a set of problems related to the interaction between applications awaiting reception of transport flow initiations (listeners) and IPv6 nodes comprising packet filtering network policy enforcement points (firewalls). From the perspective of any given IPv6 node, the region of the Internet between itself and a given firewall is the 'interior' domain of that firewall. All other regions of the Internet are the 'exterior' from the perspective of the node. The ALD protocol is concerned only with the problems associated with listeners on nodes reachable only on the interior interfaces of firewalls in receiving transport flow initiations from nodes reachable only on exterior interfaces. The ALD protocol defines methods for solving each of the following problems: Listener Discovery: How firewalls discover the transport protocols and addresses of applications awaiting reception of flow initiations. Firewall Discovery: How nodes discover what firewalls to notify that applications are awaiting reception of transport flow initiations. woodyatt Expires December 8, 2007 [Page 4] Internet-Draft Application Listener Discovery June 2007 Firewall Reset Detection: How nodes discover that firewalls have been reset and now require nodes to restart their listener discovery functions. Application Programming Interface: Extensions to the IPv6 API are defined to permit applications to be selective about how their transport endpoints are subjects of listener notification. When nodes join network segments where one or more global scope address prefixes are advertised, they use a Firewall Discovery method to build or learn a list of firewalls to notify that applications are listening at specific unicast addresses. They send Firewall Solicitation messages to a specified destination address, which may be a multicast destination, and receive directed Firewall Advertisement messages in response. Nodes send Listener Notification messages to firewalls to inform them of their expectations in receiving flow initiations. These messages are sent for each listener endpoint address in use, with retransmits as necessary. Firewalls send Listener Acknowledgement messages to squelch further retransmits. It's important to recognize the notifications are not requests. Firewalls are under no obligation to change their behavior in response to receiving application listener notifications. Nodes are provided with no assurance that inbound flow initiations are or are not prohibited at firewalls in the network, whether advertised with ALD or not. Every ALD message sent by a firewall includes a measurement of the elapsed time since their state was last reset. This is so nodes may recognize when it may be necessary to resend all its listener notifications. Firewalls periodically send announcements, but in general not at a frequency high enough that nodes may rely on the absence of them to detect the failure of a firewall. 3.1. Firewall Discovery For the purposes of application listener discovery, firewalls have an "interior" subject to the policy requiring listeners to notify them, and an "exterior" corresponding to the region of the Internet from which flow initiations are subject to administrative prohibitions. Nodes transmit Firewall Solicitation messages and receive Firewall Advertisement messages in acknowledgement. Firewall Advertisement messages inform nodes of firewalls that may prohibit flow initiations from exterior sources to the node. woodyatt Expires December 8, 2007 [Page 5] Internet-Draft Application Listener Discovery June 2007 A new neighbor discovery option is defined for use in Router Advertisements to specify the destination address and hop limit that nodes are expected to use when sending Firewall Solitation messages. 3.2. Listener Discovery Nodes send Listener Notification messages to firewalls according to their policy requirements. These notifications inform firewalls of which nodes, protocols, and transport addresses are expecting to receive inbound flow initiations. Firewalls send Listener Acknowledgement messages in response to inform listeners how much time the application can expect receive flow initiations. Nodes may notify firewalls that they expect to receive all inbound traffic, regardless of protocol or transport address. Alternatively, they can send notifications for narrower constraints on what to pass through to listening nodes. 3.3. Firewall Reset Detection Firewalls periodically multicast Firewall Advertisement messages on their "interior" interfaces. Immediately after the state in a firewall resets, the transmit interval for these advertisements are very short, rapidly increasing thereafter. Nodes receive Firewall Advertisements directly and compare the Elapsed Time Since Reset (ETSR) against the last value received in any previous message. Computing their own conservative estimates of the expected elapsed time, nodes are able to recognize when retransmitting their listener notifications might be necessary. 3.4. Application Programming Interface Applications need not be written with specific awareness of listener discovery. Operating systems are implemented with default parameters suitable for all but the rarest of exceptions. For example, nodes only inform firewalls about TCP sockets when they require transport address level notification and the node sets a TCP socket into the LISTENING state. Furthermore, the timing limits on notifications vary between temporary privacy addresses and permanently assigned addresses, i.e. a TCP socket bound to a temporary address will have a short binding time in the firewall compared to a TCP socket that binds to a permanent address. Some extensions to the application programming interface are defined for those few applications that need them. These extensions allow applications to disable listener notification or override timing woodyatt Expires December 8, 2007 [Page 6] Internet-Draft Application Listener Discovery June 2007 parameters on a case by case basis. 4. OPTION FORMATS The need for nodes to proceed with firewall discovery is signaled by the presence of a Firewall Discovery option sent in Router Advertisement messages. 4.1. Firewall Discovery Router Advertisement Option In Router Advertisements without the "other stateful configuration" flag set, the Firewall Discovery Option informs nodes of the destination address and hop limit for sending Firewall Solicitation messages. Firewall Discovery Option 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Hop Limit | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | Reserved | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 4 Hop Limit: The hop limit nodes use to send Firewall Solicit messages. woodyatt Expires December 8, 2007 [Page 7] Internet-Draft Application Listener Discovery June 2007 Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Destination Address: The destination address for nodes to use when sending Firewall Solicit messages. Routers MUST NOT send Router Advertisements containing the Firewall Discovery option if the "other stateful configuration" flag is set. Likewise, nodes MUST NOT process the Firewall Discovery Option unless the "other stateful configuration" flag is set in the Router Advertisement that contains it. Routers MUST NOT send Router Advertisements with more than one Firewall Discovery Option present. If nodes receive such Router Advertisements, then nodes MUST NOT process any of the Firewall Discovery Options. Nodes that process Firewall Discovery Options in Router Advertisements MUST NOT send any Firewall Solicitation messages from any addresses in the advertised prefixes except to the specified destination address, and with the specified hop limit. Nodes receiving Router Advertisements with the "other stateful configuration" flags not set, and without a Firewall Discovery Option present, MAY send Firewall Solicitation messages from the advertised prefixes to any address and with any hop limit. EXPERIMENTAL: The type value 253 is defined in section 5.1.3 of "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers" [RFC4727] for use with experimental protocols. Operation of ALD in experimental mode requires the four octet code 0x6161706c be inserted between the Length and Hop Limit fields, and the size of the Reserved field to be reduced by four octets to keep the destination address aligned. Experimental Firewall Discovery Options, i.e. those described in this paragraph, MUST NOT be processed unless the type value is 253 and the four octet code is present in the required position. 5. MESSAGE FORMATS ALD is a sub-protocol of ICMPv6, that is, ALD message types are a subset of the set of ICMPv6 messages, and ALD messages are all identified in IPv6 packets by a preceding Next Header value of 58. ALD messages all have the same Type value, [TBD, assigned by IANA], and their function is differentiated by the Code value. woodyatt Expires December 8, 2007 [Page 8] Internet-Draft Application Listener Discovery June 2007 This document defines the formats for ALD messages with the following Code values: ALD Message Codes +------+--------------------------+-------------+ | Code | Description | Reference | +------+--------------------------+-------------+ | 1 | Firewall Solicitation | Section 5.1 | | 2 | Firewall Advertisement | Section 5.2 | | 3 | Listener Notification | Section 5.4 | | 4 | Listener Acknowledgement | Section 5.5 | +------+--------------------------+-------------+ Table 1 All other Code values are reserved for future use. Nodes MUST NOT send messages containing them. Firewalls MUST NOT prohibit the flow of ALD messages from their exterior to their interior. 5.1. Firewall Solicitation Nodes send Firewall Solicitation messages to request firewalls to respond with directed Firewall Advertisement messages. They are sent periodically to the destination addresses specified in any Firewall Discovery Options received in Router Advertisements for networks they join. Firewall Solicitation 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD. Assigned by IANA to ALD messages. Code: 1. Checksum: ICMPv6 checksum. EXPERIMENTAL: Nodes operating in experimental mode MAY send the Experimental Firewall Solicitation message, i.e. the same message except with type value 100 as defined in "Internet Control Message woodyatt Expires December 8, 2007 [Page 9] Internet-Draft Application Listener Discovery June 2007 Protocol (ICMPv6)" [RFC4443] for use in experimental protocols, and the four octet code 0x6161706c appended after the checksum. Nodes MUST NOT send Experimental Firewall Solicitation messages to destination addresses received in the regular Firewall Discovery Option. 5.2. Firewall Advertisement Firewalls send Firewall Advertisement messages to notify listeners reachable on their interior interfaces that inbound flow initiations to a specific prefix are subject to policy enforcement. Firewalls Advertisement 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Elapsed Time Since Reset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Reserved +-+-+-+-+-+-+-+ | | IPL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Interior Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD. Assigned by IANA to ALD messages. Code: 2. Checksum: ICMPv6 checksum. Elapsed Time Since Reset: Number of elapsed seconds since the firewall state was last reset. woodyatt Expires December 8, 2007 [Page 10] Internet-Draft Application Listener Discovery June 2007 IPL: The length of the interior prefix. Values less than 48 are reserved. Senders MUST NOT use them, and receivers MUST NOT process any messages that contain them. (Note: the width of this field is seven bits.) Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Interior Prefix: The IPv6 address prefix on the interior subject to the firewall policy. Starting when a firewall begins operating on the interior prefix from its reset state, it MUST periodically send Firewall Advertisement messages on all its interfaces where the interior prefix is reachable using a Hop Limit of 255 to the organizational scope All Nodes multicast address, FF08::1. The time interval between multicast transmissions MAY be of any duration. The recommended period is every two seconds for the first ten seconds after the state is reset, followed by a doubling of the interval for every transmission thereafter until the interval reaches a maximum of one hour. EXPERIMENTAL: Firewalls operating in experimental mode MAY send Experimental Firewall Advertisement messages, i.e. the same message except with type value 100 as defined in "Internet Control Message Protocol (ICMPv6)" [RFC4443] for use in experimental protocols and the four octet code 0x6161706c inserted between the Checksum and Elapsed Time Since Reset fields. These are sent to the organizational scope "any private experiment" multicast destination address, i.e. FF08::114, instead of the All Nodes address. Nodes MUST NOT send Experimental Firewall Advertisement messages to any other multicast destination. 5.3. Listener Address Specifier Listener Notification and Listener Acknowledgement messages (see below) each contain Listener Address Specifier elements. These are structured data that describe the transport layer component of a listener address that firewalls are expected to filter, e.g. TCP and UDP ports, etc. As a general rule, this protocol number is expected to match the upper-layer-protocol of the outer-most IPv6 header (including all its extension headers). See "Internet Protocol, Version 6" [RFC2460] for details. The first octet of any Listener Address Specifier is an Internet protocol number, which serves as the type discriminator for a variant subtype of Listener Address Specifier elements. woodyatt Expires December 8, 2007 [Page 11] Internet-Draft Application Listener Discovery June 2007 Nodes MUST NOT send Listener Address Specifiers with protocol numbers assigned for identifying IPv6 extension headers. 5.3.1. All Protocols Listener Address Specifier Nodes notify firewalls that inbound flow initiations are expected by sending a Listener Notification message with the All Protocols Listener Address Specifier. This is a single octet with all zero bits, followed by a reserved field of three octets. All Protocols Listener Address Specifier 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Note: the value of zero is used here for specifying all protocols, even though it is used in IPv6 for specifying hop-by-hop options. 5.3.2. All Specific Protocol Listener Address Specifier Nodes notify firewalls that all inbound flow initiations for a specific upper-layer protocol are expected by sending a Listener Notification message with an All Specific Protocol Listener Address Specifier. This is a single octet with the protocol number, followed by three octets of zeroes. All Specific Protocol Listener Address Specifier 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | 000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol: The upper-layer protocol number. Nodes MUST NOT send All Specific Protocol Listener Address Specifier elements with protocol numbers reserved for IPv6 header extensions in the Protocol field. woodyatt Expires December 8, 2007 [Page 12] Internet-Draft Application Listener Discovery June 2007 Nodes MUST NOT send All Specific Protocol Listener Address Specifier elements with 255 in the Protocol field. 5.3.3. Encapsulating Security Payload Listener Address Specifier Nodes notify firewalls of that inbound IP Encapsulating Security Payload (ESP) flows [RFC4303] are expected by sending a Listener Notification message with the Encapsulating Security Payload Listener Address Specifier. This is a single octet with the ESP protocol number in it, followed by a reserved field of three octets. Encapsulating Security Payload Listener Address Specifier 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 50 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. SPI: Security Parameter Index for inbound flow. An ESP Listener Address Specifier with a value of all zero octets in the SPI field is equivalent to the All Specific Protocol Listener Address Specifier with the ESP protocol number in the Protocol field. 5.3.4. TCP Listener Address Specifier Nodes notify firewalls that inbound Transmission Control Protocol (TCP) connections [RFC0793] are expected by sending a Listener Notification message with the TCP Listener Address Specifier. This is a single octet with the TCP protocol number in it, followed by a reserved octet, followed by the TCP port number for the application endpoint. TCP Listener Address Specifier 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | Reserved | TCP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ woodyatt Expires December 8, 2007 [Page 13] Internet-Draft Application Listener Discovery June 2007 Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. TCP Port Number: The TCP port for the application endpoint. A value of zero in the TCP Port Number field indicates all TCP flows. This is identical to the All Specific Protocol Listener Address Specifier for TCP. 5.3.5. UDP Listener Address Specifier Nodes notify firewalls that inbound User Datagram Protocol (UDP) flow initiations [RFC0768] are expected by sending a Listener Notification message with the UDP Listener Address Specifier. This is a single octet with the UDP protocol number in it, followed by a reserved octet, followed by the UDP port number for the application endpoint. UDP Listener Address Specifier 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 17 | Reserved | UDP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. UDP Port Number: The UDP port for the application endpoint. A value of zero in the UDP Port Number field indicates all UDP flows. This is identical to the All Specific Protocol Listener Address Specifier for UDP. 5.3.6. SCTP Listener Address Specifier Nodes notify firewalls that inbound Stream Control Transport Protocol (SCTP) flow initiations [RFC2960] are expected by sending a Listener Notification message with the SCTP Listener Address Specifier. This is a single octet with the SCTP protocol number in it, followed by a reserved octet, followed by the SCTP port number for the application endpoint. woodyatt Expires December 8, 2007 [Page 14] Internet-Draft Application Listener Discovery June 2007 SCTP Listener Address Specifier 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 132 | Reserved | SCTP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. UDP Port Number: The SCTP port for the application endpoint. A value of zero in the SCTP Port Number field indicates all SCTP flows. This is identical to the All Specific Protocol Listener Address Specifier for SCTP. 5.3.7. DCCP Listener Address Specifier Nodes notify firewalls that inbound Datagram Congestion Control Protocol (DCCP) flow initiations [RFC4340] are expected by sending a Listener Notification message with the DCCP Listener Address Specifier. This is a single octet with the DCCP protocol number in it, followed by a reserved octet, followed by the DCCP port number for the application endpoint. DCCP Listener Address Specifier 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 33 | Reserved | DCCP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. UDP Port Number: The DCCP port for the application endpoint. A value of zero in the DCCP Port Number field indicates all DCCP flows. This is identical to the All Specific Protocol Listener Address Specifier for DCCP. woodyatt Expires December 8, 2007 [Page 15] Internet-Draft Application Listener Discovery June 2007 5.4. Listener Notification When a node expects to receive inbound flows from the exterior of a firewall, it MAY send a Listener Notification message to signal that inbound flow initiations should not be prohibited. Listener Notification 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expected Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Listener Address Specifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Type: TBD. Assigned by IANA to ALD messages. Code: 3. Checksum: ICMPv6 checksum. Expected Duration: The number of seconds the application expects to be listening. Listener Address Specifier: Describes the transport address of the application listener. See Section 5.3. Nodes MUST NOT send Listener Notification messages on any network to any destinations other than the unicast source addresses from which they receive Firewall Advertisement messages after joining the network. EXPERIMENTAL: Nodes operating in experimental mode MAY send the Experimental Listener Notification message, i.e. the same message except with type value 100 as defined in "Internet Control Message Protocol (ICMPv6)" [RFC4443] for use in experimental protocols and the four octet code 0x6161706c inserted between the Checksum and Expected Time Interval fields. Nodes MUST NOT send Experimental Listener Notification messages to destination addresses after receiving any regular Firewall Advertisement messages from the same source address. woodyatt Expires December 8, 2007 [Page 16] Internet-Draft Application Listener Discovery June 2007 5.5. Listener Acknowledgement Firewalls send Listener Acknowledgement messages in response to receiving Listener Solication messages from nodes. Listener Acknowledgement 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Elapsed Time Since Reset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledged Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Listener Address Specifier +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Type: TBD. Assigned by IANA to ALD messages. Code: 4. Checksum: ICMPv6 checksum. Elapsed Time Since Reset: Number of elapsed seconds since the firewall state was last reset. Acknowledged Duration: The number of seconds the firewall acknowledges the node will be listening. Listener Address Specifier: Describes the transport address of the application listener. See Section 5.3. Firewalls MUST NOT transmit Listener Acknowledgement messages except in response to received Listener Notification messages. Firewalls MUST NOT transmit Listener Acknowledgement messages with an Acknowledged Duration greater than the Expected Duration in the corresponding Listener Notification message. After receiving a Listener Acknowledgement message, nodes MUST NOT transmit Listener Notification messages with a non-zero Requested Lifetime and the same Listener Address Specifier unless the Requested woodyatt Expires December 8, 2007 [Page 17] Internet-Draft Application Listener Discovery June 2007 Lifetime is less than seven eighths (87.5%) of the Granted Lifetime value. EXPERIMENTAL: Firewalls operating in experimental mode MAY respond to Experimental Listener Notification messages with the Experimental Listener Acknowledgement message, i.e. the same message except with type value 100 as defined in "Internet Control Message Protocol (ICMPv6)" [RFC4443] for use in experimental protocols and the four octet code 0x6161706c inserted between the Checksum and Elapsed Time Since Reset fields. 6. APPLICATION PROGRAMMING INTERFACE This section needs to be expanded to discuss how ALD functions are related to the operation of the conventional socket layer interface, i.e. how Listener Notifications are emitted when TCP sockets are put into and taken out of the LISTENING states, etc. Additional socket options for advanced usage may also be necessary here. Specific description of behavior for sockets in O_NONBLOCK mode should be defined. 7. IANA CONSIDERATIONS This memo includes several requests to IANA, which need to be gathered into this section accordingly. All drafts are required to have an IANA considerations section (see the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 8. SECURITY CONSIDERATIONS The author has not yet given sufficient consideration to security for writing an adequate security considerations section. Some readers have expressed concerns about spoofing. The author thinks protecting unicast ALD messages with IPsec Authenticated Header is the appropriate method for addressing such issues. An argument might be entertained for protecting the privacy of Listener Notification and Acknowledgement messages, and the author likewise believes IPsec Encapsulating Security Payload is the appropriate method for that. Key exchange for such security mechanisms should be specified by this document if IETF consensus regards addressing these considerations as woodyatt Expires December 8, 2007 [Page 18] Internet-Draft Application Listener Discovery June 2007 essential. All drafts are required to have a security considerations section. See "Guidelines for Writing RFC Text on Security Considerations" [RFC3552] for a guide. 9. References 9.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 9.2. Informative References [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-06 (work in progress), March 2007. woodyatt Expires December 8, 2007 [Page 19] Internet-Draft Application Listener Discovery June 2007 [IPv6-NAP] Van de Velde, G., Hain, T., Droms, R., and B. Carpenter, "Local Network Protection for IPv6", January 2007, . [NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", November 2001, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [UPnP-IGD] UPnP Forum, "Universal Plug and Play Internet Gateway Device Standardized Gateway Device Protocol", September 2006, . Appendix A. Change Log A.1. draft-woodyatt-ald-00 to draft-woodyatt-ald-01 o Added geeky cross-references for TCP and UDP. o Simplified description of ICMPv6 checksum field descriptions. o Changed the All Protocols Listener Address Specifier to use zero instead of 41, so that IPv6-in-IPv6 is eligible for specification. o Added the SPI field to the ESP Listener Address Specifier. o Added a note about zero UDP and TCP port numbers in the associated Listener Address Specifiers. o Added Listener Address Specifiers for SCTP and DCCP. o Added the All Specific Protocol Listener Address Specifier element and changed the associated requirements langauge to allow nodes to send them, and to explicitly disallow protocol numbers corresponding to IPv6 header extensions and the reserved protocol number. woodyatt Expires December 8, 2007 [Page 20] Internet-Draft Application Listener Discovery June 2007 Author's Address james woodyatt Apple Inc. 1 Infinite Loop Cupertino, CA 95014 US Email: jhw@apple.com woodyatt Expires December 8, 2007 [Page 21] Internet-Draft Application Listener Discovery June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). woodyatt Expires December 8, 2007 [Page 22]