One document matched: draft-woodyatt-ald-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is the source document for creating the ALD specification using
xml2rfc, which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0768 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY RFC0793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4727 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4727.xml">
<!ENTITY RFC4864 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4864.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-woodyatt-ald-02" ipr="full3978">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only
necessary if the full title is longer than 39 characters -->
<title abbrev="Application Listener Discovery">
Application Listener Discovery (ALD) for IPv6
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="james woodyatt" initials="j h" surname="woodyatt">
<organization abbrev='Apple'>Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<!-- Reorder these if your country does things differently -->
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>US</country>
</postal>
<email>jhw@apple.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2007" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current year
is specified, xml2rfc will fill in the current day and month for you.
If the year is not the current one, it is necessary to specify at
least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally
sufficient to specify just the year. -->
<!-- Meta-data Declarations -->
<area>internet</area>
<workgroup>IP Version 6</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions. If this element is not
present, the default is "Network Working Group", which is used by the
RFC Editor as a nod to the history of the IETF. -->
<keyword>ALD</keyword>
<keyword>ICMP</keyword>
<keyword>IPv6</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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).</t>
<t>Comments are solicited and should be sent to the author and the V6OPS
Residential CPE Design Team mailing list at
<v6ops-residential-cpe-design-team@external.cisco.com>.</t>
</abstract>
</front>
<middle>
<!------------------------------------------------------------------------
INTRODUCTION
------------------------------------------------------------------------>
<section title="INTRODUCTION" anchor='introduction'>
<t>In "Local Network Protection for IPv6" <xref target="RFC4864"/>, 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."</t>
<t>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.</t>
<t>These methods include:
<list style='symbols'>
<t>"NAT Port Mapping Protocol" <xref target="NAT-PMP"/></t>
<t>"Internet Gateway Device (IGD)" standardized device control
protocol of Universal Plug And Play <xref target="UPnP-IGD"/></t>
</list>
</t>
<t>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.</t>
<t>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.</t>
<t>(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.)</t>
</section>
<!------------------------------------------------------------------------
TERMINOLOGY
------------------------------------------------------------------------>
<section title="TERMINOLOGY" anchor='terminology'>
<section title="Requirements Language">
<t>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
<xref target="RFC2119"/>.</t>
<t>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
<xref target="RFC4727">"Experimental Values in IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers"</xref>.</t>
</section>
<section title="Special Terms and Abbreviations">
<t><list style='hanging'>
<t hangText='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.</t>
<t hangText='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.</t>
</list></t>
</section>
</section>
<!------------------------------------------------------------------------
PROTOCOL OVERVIEW
------------------------------------------------------------------------>
<section title="PROTOCOL OVERVIEW" anchor='overview'>
<t>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).</t>
<t>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.</t>
<t>The ALD protocol defines methods for solving each of the following
problems:</t>
<t><list style='hanging'>
<t hangText='Listener Discovery:'>How firewalls discover the transport
protocols and addresses of applications awaiting reception of flow
initiations.</t>
<t hangText='Firewall Discovery:'>How nodes discover what firewalls to
notify that applications are awaiting reception of transport flow
initiations.</t>
<t hangText='Firewall Reset Detection:'>How nodes discover that
firewalls have been reset and now require nodes to restart their
listener discovery functions.</t>
<t hangText='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.</t>
</list></t>
<t>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.</t>
<t>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 Acknowledgment messages to squelch
further retransmits.</t>
<t>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.</t>
<t>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.</t>
<section title='Firewall Discovery'>
<t>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.</t>
<t>Nodes transmit Firewall Solicitation messages and receive Firewall
Advertisement messages in acknowledgment. Firewall Advertisement
messages inform nodes of firewalls that may prohibit flow initiations
from exterior sources to the node.</t>
<t>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.</t>
</section>
<section title='Listener Discovery'>
<t>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
Acknowledgment messages in response to inform listeners how much time
the application can expect receive flow initiations.</t>
<t>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.</t>
</section>
<section title='Firewall Reset Detection'>
<t>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.</t>
<t>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.</t>
</section>
<section title='Application Programming Interface'>
<t>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.</t>
<t>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.</t>
<t>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
parameters on a case by case basis.</t>
</section>
</section>
<!------------------------------------------------------------------------
OPTION FORMATS
------------------------------------------------------------------------>
<section title="OPTION FORMATS" anchor='options'>
<t>The need for nodes to proceed with firewall discovery is signaled by
the presence of a Firewall Discovery option sent in Router Advertisement
messages.</t>
<section title="Firewall Discovery Router Advertisement Option"
anchor='ra_option'>
<t>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.</t>
<figure align='center'>
<preamble>Firewall Discovery Option</preamble>
<artwork align="center"><![CDATA[
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Type:'>TBD</t>
<t hangText='Length:'>4</t>
<t hangText='Hop Limit:'><vspace blankLines='0'/>The hop limit
nodes use to send Firewall Solicit messages.</t>
<t hangText='Reserved:'>This field is unused. It MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.</t>
<t hangText='Destination Address:'><vspace blankLines='0'/>The
destination address for nodes to use when sending Firewall
Solicit messages.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>EXPERIMENTAL: The type value 253 is defined in section 5.1.3 of
<xref target="RFC4727">"Experimental Values in IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers"</xref> 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.</t>
</section>
</section>
<!------------------------------------------------------------------------
MESSAGE FORMATS
------------------------------------------------------------------------>
<section title="MESSAGE FORMATS" anchor='messages'>
<t>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.</t>
<t>This document defines the formats for ALD messages with the following
Code values:</t>
<texttable anchor='msg_codes'>
<preamble>ALD Message Codes</preamble>
<ttcol>Code</ttcol>
<ttcol>Description</ttcol>
<ttcol>Reference</ttcol>
<c>1</c>
<c>Firewall Solicitation</c>
<c><xref target='fw_solicit'/></c>
<c>2</c>
<c>Firewall Advertisement</c>
<c><xref target='fw_advertise'/></c>
<c>3</c>
<c>Listener Notification</c>
<c><xref target='l_ntf'/></c>
<c>4</c>
<c>Listener Acknowledgment</c>
<c><xref target='l_ack'/></c>
</texttable>
<t>All other Code values are reserved for future use. Nodes MUST NOT
send messages containing them.</t>
<t>Firewalls MUST NOT prohibit the flow of ALD messages from their
exterior to their interior.</t>
<section title="Firewall Solicitation" anchor="fw_solicit">
<t>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.</t>
<figure align='center'>
<preamble>Firewall Solicitation</preamble>
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Type:'>TBD. Assigned by IANA to ALD messages.</t>
<t hangText='Code:'>1.</t>
<t hangText='Checksum:'><vspace blankLines='0'/>ICMPv6 checksum.</t>
</list></t>
<t>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 <xref target="RFC4443">
"Internet Control Message Protocol (ICMPv6)"</xref> 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.</t>
</section>
<section title="Firewall Advertisement" anchor='fw_advertise'>
<t>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.</t>
<figure align='center'>
<preamble>Firewalls Advertisement</preamble>
<artwork align="center"><![CDATA[
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Type:'>TBD. Assigned by IANA to ALD messages.</t>
<t hangText='Code:'>2.</t>
<t hangText='Checksum:'><vspace blankLines='0'/>ICMPv6 checksum.</t>
<t hangText='Elapsed Time Since Reset:'><vspace blankLines='0'/>
Number of elapsed seconds since the firewall state was last
reset.</t>
<t hangText='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.)</t>
<t hangText='Reserved:'><vspace blankLines='0'/>This field is unused.
It MUST be initialized to zero by the sender and MUST be ignored by
the receiver.</t>
<t hangText='Interior Prefix:'><vspace blankLines='0'/>The IPv6
address prefix on the interior subject to the firewall policy.</t>
</list></t>
<t>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.</t>
<t>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 <xref target="RFC4443">
"Internet Control Message Protocol (ICMPv6)"</xref> 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.</t>
</section>
<section title="Listener Address Specifier" anchor='l_addrspec'>
<t>Listener Notification and Listener Acknowledgment 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 <xref target='RFC2460'>
"Internet Protocol, Version 6"</xref> for details.</t>
<t>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.</t>
<t>Nodes MUST NOT send Listener Address Specifiers with protocol
numbers assigned for identifying IPv6 extension headers.</t>
<section title="All Protocols Listener Address Specifier">
<t>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.</t>
<figure align='center'>
<preamble>All Protocols Listener Address Specifier</preamble>
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Reserved:'><vspace blankLines='0'/>This field is
unused. It MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
</list></t>
<t>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.</t>
</section>
<section title="All Specific Protocol Listener Address Specifier">
<t>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.</t>
<figure align='center'>
<preamble>All Specific Protocol Listener Address
Specifier</preamble>
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Protocol:'><vspace blankLines='0'/>The upper-layer
protocol number.</t>
</list></t>
<t>Nodes MUST NOT send All Specific Protocol Listener Address
Specifier elements with protocol numbers reserved for IPv6 header
extensions in the Protocol field.</t>
<t>Nodes MUST NOT send All Specific Protocol Listener Address
Specifier elements with 255 in the Protocol field.</t>
</section>
<section title="Encapsulating Security Payload Listener Address
Specifier">
<t>Nodes notify firewalls of that inbound <xref target='RFC4303'>IP
Encapsulating Security Payload (ESP) flows</xref> 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.</t>
<figure align='center'>
<preamble>Encapsulating Security Payload Listener Address
Specifier</preamble>
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Reserved:'><vspace blankLines='0'/>This field is
unused. It MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText='SPI:'>Security Parameter Index for inbound flow.</t>
</list></t>
<t>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.</t>
</section>
<section title="TCP Listener Address Specifier">
<t>Nodes notify firewalls that inbound <xref target="RFC0793">
Transmission Control Protocol (TCP) connections</xref> 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.</t>
<figure align='center'>
<preamble>TCP Listener Address Specifier</preamble>
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Reserved:'><vspace blankLines='0'/>This field is
unused. It MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText='TCP Port Number:'><vspace blankLines='0'/>The TCP
port for the application endpoint.</t>
</list></t>
<t>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.</t>
</section>
<section title="UDP Listener Address Specifier">
<t>Nodes notify firewalls that inbound <xref target="RFC0768">
User Datagram Protocol (UDP) flow initiations</xref> 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.</t>
<figure align='center'>
<preamble>UDP Listener Address Specifier</preamble>
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Reserved:'><vspace blankLines='0'/>This field is
unused. It MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText='UDP Port Number:'><vspace blankLines='0'/>The UDP
port for the application endpoint.</t>
</list></t>
<t>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.</t>
</section>
<section title="SCTP Listener Address Specifier">
<t>Nodes notify firewalls that inbound <xref target="RFC4960">
Stream Control Transport Protocol (SCTP) flow initiations</xref>
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.</t>
<figure align='center'>
<preamble>SCTP Listener Address Specifier</preamble>
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Reserved:'><vspace blankLines='0'/>This field is
unused. It MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText='UDP Port Number:'><vspace blankLines='0'/>The SCTP
port for the application endpoint.</t>
</list></t>
<t>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.</t>
</section>
<section title="DCCP Listener Address Specifier">
<t>Nodes notify firewalls that inbound <xref target="RFC4340">
Datagram Congestion Control Protocol (DCCP) flow initiations</xref>
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.</t>
<figure align='center'>
<preamble>DCCP Listener Address Specifier</preamble>
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Reserved:'><vspace blankLines='0'/>This field is
unused. It MUST be initialized to zero by the sender and MUST be
ignored by the receiver.</t>
<t hangText='UDP Port Number:'><vspace blankLines='0'/>The DCCP
port for the application endpoint.</t>
</list></t>
<t>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.</t>
</section>
</section>
<section title="Listener Notification" anchor='l_ntf'>
<t>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.</t>
<figure align='center'>
<preamble>Listener Notification</preamble>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Type:'>TBD. Assigned by IANA to ALD messages.</t>
<t hangText='Code:'>3.</t>
<t hangText='Checksum:'><vspace blankLines='0'/>ICMPv6 checksum.</t>
<t hangText='Expected Duration:'><vspace blankLines='0'/>The
number of seconds the application expects to be listening.</t>
<t hangText='Listener Address Specifier:'><vspace blankLines='0'/>
Describes the transport address of the application listener. See
<xref target='l_addrspec'/>.</t>
</list></t>
<t>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.</t>
<t>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 <xref target="RFC4443">
"Internet Control Message Protocol (ICMPv6)"</xref> 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.</t>
</section>
<section title="Listener Acknowledgment" anchor='l_ack'>
<t>Firewalls send Listener Acknowledgment messages in response to
receiving Listener Solication messages from nodes.</t>
<figure align='center'>
<preamble>Listener Acknowledgment</preamble>
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
]]></artwork>
</figure>
<t><list style='hanging' hangIndent='8'>
<t hangText='Type:'>TBD. Assigned by IANA to ALD messages.</t>
<t hangText='Code:'>4.</t>
<t hangText='Checksum:'><vspace blankLines='0'/>ICMPv6 checksum.</t>
<t hangText='Elapsed Time Since Reset:'><vspace blankLines='0'/>
Number of elapsed seconds since the firewall state was last reset.</t>
<t hangText='Acknowledged Duration:'><vspace blankLines='0'/>The
number of seconds the firewall acknowledges the node will be
listening.</t>
<t hangText='Listener Address Specifier:'><vspace blankLines='0'/>
Describes the transport address of the application listener. See
<xref target='l_addrspec'/>.</t>
</list></t>
<t>Firewalls MUST NOT transmit Listener Acknowledgment messages except
in response to received Listener Notification messages.</t>
<t>Firewalls MUST NOT transmit Listener Acknowledgment messages with
an Acknowledged Duration greater than the Expected Duration in the
corresponding Listener Notification message.</t>
<t>After receiving a Listener Acknowledgment message, nodes MUST NOT
transmit Listener Notification messages with a non-zero Requested
Lifetime and the same Listener Address Specifier unless the Requested
Lifetime is less than seven eighths (87.5%) of the Granted Lifetime
value.</t>
<t>EXPERIMENTAL: Firewalls operating in experimental mode MAY respond
to Experimental Listener Notification messages with the Experimental
Listener Acknowledgment message, i.e. the same message except with
type value 100 as defined in <xref target="RFC4443">"Internet Control
Message Protocol (ICMPv6)"</xref> for use in experimental protocols and
the four octet code 0x6161706c inserted between the Checksum and
Elapsed Time Since Reset fields.</t>
</section>
</section>
<!------------------------------------------------------------------------
APPLICATION PROGRAMMING INTERFACE
------------------------------------------------------------------------>
<section title="APPLICATION PROGRAMMING INTERFACE" anchor='api'>
<t>[ 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. ]</t>
<t>Existing programming interfaces, e.g. the widely used BSD sockets API,
are sufficient for most applications. When TCP endpoints bound to global
addresses transition into the LISTENING state, firewalls can be notified
automatically with Listener Notification messages. Similar methods can
be used for all other transport protocols.</t>
<t>Some applications require finer control over whether and how to notify
firewalls of their listeners. This document recommends extensions to
system configuration, interface control messages and socket options to
meet their needs.</t>
<section title="Normal Behavior of IPv6 Sockets">
<t>Applications using the BSD <spanx style='verb'>listen(2)</spanx>
function to place a TCP socket into the LISTENING state MAY be blocked
while ALD notifies the appropriate firewalls. If the socket descriptor
is opened with <spanx style='verb'>O_NONBLOCK</spanx> or is otherwise
marked as non-blocking, then <spanx style='verb'>listen(2)</spanx> MAY
return <spanx style='verb'>EINPROGRESS</spanx> to indicate that ALD has
not yet received Listener Acknowledgment messages from all appropriate
firewalls. It MAY be possible to <spanx style='verb'>select(2)</spanx>
for completion by checking the socket for writing.</t>
<t>Applications using the BSD <spanx style='verb'>bind(2)</spanx>
function with UDP sockets MAY be blocked while ALD notifies the
appropriate firewalls. If the socket descriptor is opened with
<spanx style='verb'>O_NONBLOCK</spanx> or is otherwise marked as
non-blocking, then <spanx style='verb'>bind(2)</spanx> MAY return
<spanx style='verb'>EINPROGRESS</spanx> to indicate that ALD has not
yet received Listener Acknowledgment messages from all appropriate
firewalls. It MAY be possible to <spanx style='verb'>select(2)</spanx>
for completion by checking the socket for writing.</t>
<t>Implementations of SCTP and DCCP are expected to implement similar
methods of plumbing up ALD operations to the application layer.</t>
<t>If an application binds to specific interface addresses, then
Listener Notification messages MAY be sent only to those firewalls
with matching interior prefixes.</t>
<t>If a node receives a Listener Acknowledgment with an address
specification that indicates the firewall has already discovered the
application listener, then transmitting a Listener Notification MAY be
skipped. If no ALD messages are necessary, then the application MUST
receive the same service from the <spanx style='verb'>bind(2)</spanx>
and <spanx style='verb'>listen(2)</spanx> system functions as when
ALD is not operating.</t>
</section>
<section title="Extensions to BSD Socket Interface">
<t>A new system configuration variable of boolean type,
<spanx style='verb'>net.inet6.icmp6.ald_enabled</spanx>, MAY be
available on nodes to control whether ALD is enabled. The recommended
default value is TRUE.</t>
<t>A new interface flag, <spanx style='verb'>IFF_NOALD</spanx> MAY be
available for disabling ALD on a per-interface basis. The recommended
default if for the flag not to be set. The
<spanx style='verb'>ifconfig(8)</spanx> utility MAY provide the "-ald"
parameter for controlling this option.</t>
<t>A new socket option of boolean type,
<spanx style='verb'>IPV6_ALD_ENABLED</spanx> MAY be used to control
whether ALD is to be used on a per-socket basis. The default value for
is recommended to be TRUE unless
<spanx style='verb'>net.inet6.icmp6.ald_enabled</spanx> is FALSE or the
socket has already been bound to an interface address for which the
interface has the <spanx style='verb'>IFF_NOALD</spanx> flag set.</t>
</section>
</section>
<!--
This PI places the pagebreak correctly (before the section title) in the
text output.
-->
<?rfc needLines="8" ?>
<!-- Possibly a 'Contributors' section ... -->
<!------------------------------------------------------------------------
IANA CONSIDERATIONS
------------------------------------------------------------------------>
<section anchor="IANA" title="IANA CONSIDERATIONS">
<t>This memo includes several requests to IANA, which need to be gathered
into this section accordingly.</t>
<t>All drafts are required to have an IANA considerations section (see
<xref target="I-D.narten-iana-considerations-rfc2434bis">the update of
RFC 2434</xref> 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.</t>
</section>
<!------------------------------------------------------------------------
SECURITY CONSIDERATIONS
------------------------------------------------------------------------>
<section anchor="Security" title="SECURITY CONSIDERATIONS">
<t>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 Acknowledgment
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 essential.</t>
<t>All drafts are required to have a security considerations section.
See <xref target="RFC3552">"Guidelines for Writing RFC Text on Security
Considerations"</xref> for a guide.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<!------------------------------------------------------------------------
REFERENCES
------------------------------------------------------------------------>
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2119; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC0768;
&RFC0793;
&RFC2119;
&RFC2460;
&RFC4303;
&RFC4340;
&RFC4443;
&RFC4727;
&RFC4960;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC3552;
&RFC4864;
<reference anchor='NAT-PMP'
target='http://tools.ietf.org/html/draft-cheshire-nat-pmp'>
<front>
<title>NAT Port Mapping Protocol (NAT-PMP)</title>
<author initials='S.' surname='Cheshire'>
<organization abbrev='Apple'>Apple, Inc.</organization>
</author>
<author initials='M.' surname='Krochmal'>
<organization abbrev='Apple'>Apple, Inc.</organization>
</author>
<author initials='K.' surname='Sekar'>
<organization abbrev='Sharpcast'>Sharpcast, Inc.</organization>
</author>
<date month='November' year='2001'/>
</front>
</reference>
<reference anchor='UPnP-IGD'
target='http://www.upnp.org/standardizeddcps/igd.asp'>
<front>
<title>Universal Plug and Play Internet Gateway Device Standardized
Gateway Device Protocol</title>
<author fullname='UPnP Forum'>
<organization>UPnP Forum</organization>
</author>
<date month='September' year='2006'/>
</front>
</reference>
&I-D.narten-iana-considerations-rfc2434bis;
</references>
<!-- Change Log -->
<section anchor='changelog' title="Change Log">
<section title='draft-woodyatt-ald-01 to draft-woodyatt-ald-02'>
<t><list style='symbols'>
<t>Fixed spelling errors.</t>
<t>Local Network Protection is now <xref target='RFC4864'/>.</t>
<t>Fix some bugs related to <xref target='RFC2119'/> compliance.</t>
<t>SCTP is now <xref target='RFC4960'/>.</t>
</list></t>
</section>
<section title='draft-woodyatt-ald-00 to draft-woodyatt-ald-01'>
<t><list style='symbols'>
<t>Added geeky cross-references for TCP and UDP.</t>
<t>Simplified description of ICMPv6 checksum field descriptions.</t>
<t>Changed the All Protocols Listener Address Specifier to use zero
instead of 41, so that IPv6-in-IPv6 is eligible for specification.</t>
<t>Added the SPI field to the ESP Listener Address Specifier.</t>
<t>Added a note about zero UDP and TCP port numbers in the associated
Listener Address Specifiers.</t>
<t>Added Listener Address Specifiers for SCTP and DCCP.</t>
<t>Added the All Specific Protocol Listener Address Specifier element
and changed the associated requirements language to allow nodes to
send them, and to explicitly disallow protocol numbers corresponding
to IPv6 header extensions and the reserved protocol number.</t>
</list></t>
</section>
</section>
<!-- Open Issues To Resolve
+ Application programming interface needs detailed definition.
+ IANA and Security Considerations sections need to be completed.
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:23:59 |