doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc4135.txt b/doc/rfc/rfc4135.txt
new file mode 100644
index 0000000..78c9091
--- /dev/null
+++ b/doc/rfc/rfc4135.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                           JH. Choi
+Request for Comments: 4135                                   Samsung AIT
+Category: Informational                                         G. Daley
+                                                  CTIE Monash University
+                                                             August 2005
+
+
+             Goals of Detecting Network Attachment in IPv6
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   When a host establishes a new link-layer connection, it may or may
+   not have a valid IP configuration for Internet connectivity.  The
+   host may check for link change (i.e., determine whether a link change
+   has occurred), and then, based on the result, it can automatically
+   decide whether its IP configuration is still valid.  During link
+   identity detection, the host may also collect necessary information
+   to initiate a new IP configuration if the IP subnet has changed.  In
+   this memo, this procedure is called Detecting Network Attachment
+   (DNA).  DNA schemes should be precise, sufficiently fast, secure, and
+   of limited signaling.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Problems in Detecting Network Attachment ........................3
+      2.1. Wireless Link Properties ...................................3
+      2.2. Link Identity Detection with a Single RA ...................3
+      2.3. Delays .....................................................4
+   3. Goals for Detecting Network Attachment ..........................5
+      3.1. Goals List .................................................6
+   4. Security Considerations .........................................6
+   5. Acknowledgements ................................................7
+   6. References ......................................................8
+      6.1. Normative References .......................................8
+      6.2. Informative References .....................................8
+
+
+
+
+
+Choi & Daley                 Informational                      [Page 1]
+
+RFC 4135                       DNA Goals                     August 2005
+
+
+1.  Introduction
+
+   When a host has established a new link-layer connection, it can send
+   and receive some IPv6 packets on the link, including those used for
+   configuration.  On the other hand, the host has Internet connectivity
+   only when it is able to exchange packets with off-link destinations.
+
+   When a link-layer connection is established or re-established, the
+   host may not know whether its existing IP configuration is still
+   valid for Internet connectivity.  A subnet change might have occurred
+   when the host changed its point of attachment.
+
+   In practice, the host doesn't know which of its addresses are valid
+   on the newly attached link.  It also doesn't know whether its
+   existing default router is on this link or whether its neighbor cache
+   entries are valid.  Correct configuration of each of these components
+   is necessary in order to send packets on and off the link.
+
+   To examine the status of the existing configuration, a host may check
+   whether a 'link change' has occurred.  In this document, the term
+   'link' is as defined in RFC 2461 [1].  The notion 'link' is not
+   identical with the notion 'subnet', as defined in RFC 3753 [2].  For
+   example, there may be more than one subnet on a link, and a host
+   connected to a link may be part of one or more of the subnets on the
+   link.
+
+   Today, a link change necessitates an IP configuration change.
+   Whenever a host detects that it has remained at the same link, it can
+   usually assume its IP configuration is still valid.  Otherwise, the
+   existing one is no longer valid, and a new configuration must be
+   acquired.  Therefore, to examine the validity of an IP configuration,
+   all that is required is that the host checks for link change.
+
+   In the process of checking for link change, a host may collect some
+   of the necessary information for a new IP configuration, such as on-
+   link prefixes.  So, when an IP subnet change has occurred, the host
+   can immediately initiate the process of getting a new IP
+   configuration.  This may reduce handoff delay and minimize signaling.
+
+   Rapid attachment detection is required for a device that changes
+   subnet while having on-going sessions.  This may be the case if a
+   host is connected intermittently, is a mobile node, or has urgent
+   data to transmit upon attachment to a link.
+
+   Detecting Network Attachment (DNA) is the process by which a host
+   collects the appropriate information and detects the identity of its
+   currently attached link to ascertain the validity of its IP
+   configuration.
+
+
+
+Choi & Daley                 Informational                      [Page 2]
+
+RFC 4135                       DNA Goals                     August 2005
+
+
+   DNA schemes are typically run per interface.  When a host has
+   multiple interfaces, the host separately checks for link changes on
+   each interface.
+
+   It is important to note that DNA process does not include the actual
+   IP configuration procedure.  For example, with respect to DHCP, the
+   DNA process may determine that the host needs to get some
+   configuration information from a DHCP server.  However, the process
+   of actually retrieving the information from a DHCP server falls
+   beyond the scope of DNA.
+
+   This document considers the DNA procedure only from the IPv6 point of
+   view, unless explicitly mentioned otherwise.  Thus, the term "IP" is
+   to be understood to denote IPv6, by default.  For the IPv4 case,
+   refer to [7].
+
+2.  Problems in Detecting Network Attachment
+
+   A number of issues make DNA complicated.  First, wireless
+   connectivity is not as clear-cut as wired connectivity.  Second, it's
+   difficult for a single Router Advertisement (RA) message to indicate
+   a link change.  Third, the current Router Discovery specification
+   specifies that routers wait a random delay of 0-.5 seconds prior to
+   responding with a solicited RA.  This delay can be significant and
+   may result in service disruption.
+
+2.1.  Wireless Link Properties
+
+   Unlike in wired environments, what constitutes a wireless link is
+   variable both in time and space.  Wireless links do not have clear
+   boundaries.  This may be illustrated by the fact that a host may be
+   within the coverage area of multiple (802.11) access points at the
+   same time.  Moreover, connectivity on a wireless link can be very
+   volatile, which may make link identity detection hard.  For example,
+   it takes time for a host to check for link change.  If the host
+   ping-pongs between two links and doesn't stay long enough at a given
+   link, it can't complete the DNA procedure.
+
+2.2.  Link Identity Detection with a Single RA
+
+   Usually, a host gets the information necessary for IP configuration
+   from RA messages.  Based on the current definition [1], it's
+   difficult for a host to check for link change upon receipt of a
+   single RA.
+
+   To detect link identity, a host may compare the information in an RA,
+   such as router address or prefixes, with the locally stored
+   information.
+
+
+
+Choi & Daley                 Informational                      [Page 3]
+
+RFC 4135                       DNA Goals                     August 2005
+
+
+   The host may use received router addresses to check for link change.
+   The router address in the source address field of an RA is of link-
+   local scope, however, so its uniqueness is not guaranteed outside a
+   link.  If it happens that two different router interfaces on
+   different links have the same link-local address, the host can't
+   detect that it has moved from one link to another by checking the
+   router address in RA messages.
+
+   The set of all global prefixes assigned to a link can represent link
+   identity.  The host may compare the prefixes in an incoming RA with
+   the currently stored ones.  An unsolicited RA message, however, can
+   omit some prefixes for convenience [1], and it's not easy for a host
+   to attain and retain all the prefixes on a link with certainty.
+   Therefore, neither the absence of a previously known prefix nor the
+   presence of a previously unknown prefix in the RA guarantees that a
+   link change has occurred.
+
+2.3.  Delays
+
+   The following issues cause DNA delay that may result in communication
+   disruption.
+
+   1) Delay for receiving a hint
+
+   A hint is an indication that a link change might have occurred.  This
+   hint itself doesn't confirm a link change, but initiates appropriate
+   DNA procedures to detect the identity of the currently attached link.
+
+   Hints come in various forms and differ in how they indicate a
+   possible link change.  They can be link-layer event notifications
+   [6], the lack of RA from the default router, or the receipt of a new
+   RA.  The time taken to receive a hint also varies.
+
+   As soon as a new link-layer connection has been made, the link layer
+   may send a link-up notification to the IP layer.  A host may
+   interpret the new link-layer connection as a hint for a possible link
+   change.  With link-layer support, a host can receive such a hint
+   almost instantly.
+
+   Mobile IPv6 [4] defines the use of RA Interval Timer expiry for a
+   hint.  A host keeps monitoring for periodic RAs and interprets the
+   lack of them as a hint.  It may implement its own policy to determine
+   the number of missing RAs needed to interpret that as a hint.  Thus,
+   the delay depends on the Router Advertisement interval.
+
+   Without schemes such as those above, a host must receive a new RA
+   from a new router to detect a possible link change.  The detection
+   time then also depends on the Router Advertisement frequency.
+
+
+
+Choi & Daley                 Informational                      [Page 4]
+
+RFC 4135                       DNA Goals                     August 2005
+
+
+   Periodic RA beaconing transmits packets within an interval varying
+   randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds.
+   Because a network attachment is unrelated to the advertisement time
+   on the new link, hosts are expected to arrive, on average, halfway
+   through the interval.  This is approximately 1.75 seconds with
+   Neighbor Discovery [1] advertisement rates.
+
+   2) Random delay execution for RS/RA exchange
+
+   Router Solicitation and Router Advertisement messages are used for
+   Router Discovery.  According to [1], it is sometimes necessary for a
+   host to wait a random amount of time before it may send an RS, and
+   for a router to wait before it may reply with an RA.
+
+   According to RFC 2461 [1], the following apply:
+
+   -  Before a host sends an initial solicitation, it SHOULD delay the
+      transmission for a random amount of time between 0 and
+      MAX_RTR_SOLICITATION_DELAY (1 second).
+
+   -  Furthermore, any RA sent in response to a Router Solicitation MUST
+      be delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5
+      seconds).
+
+3.  Goals for Detecting Network Attachment
+
+   The DNA working group has been chartered to define an improved scheme
+   for detecting IPv6 network attachment.  In this section, we define
+   the goals that any such solution should aim to fulfill.
+
+   DNA solutions should correctly determine whether a link change has
+   occurred.  Additionally, they should be sufficiently fast so that
+   there would be no or at most minimal service disruption.  They should
+   neither flood the link with related signaling nor introduce new
+   security holes.
+
+   When defining new solutions, it is necessary to investigate the usage
+   of available tools, Neighbor Solicitation/Neighbor Advertisement
+   messages, RS/RA messages, link-layer event notifications [6], and
+   other features.  This will allow precise description of procedures
+   for efficient DNA Schemes.
+
+
+
+
+
+
+
+
+
+
+Choi & Daley                 Informational                      [Page 5]
+
+RFC 4135                       DNA Goals                     August 2005
+
+
+3.1.  Goals List
+
+   G1  DNA schemes should detect the identity of the currently attached
+       link to ascertain the validity of the existing IP configuration.
+       They should recognize and determine whether a link change has
+       occurred and initiate the process of acquiring a new
+       configuration if necessary.
+
+   G2  DNA schemes should detect the identity of an attached link with
+       minimal latency lest there should be service disruption.
+
+   G3  If a host has not changed a link, DNA schemes should not falsely
+       assume a link change, and an IP configuration change should not
+       occur.
+
+   G4  DNA schemes should not cause undue signaling on a link.
+
+   G5  DNA schemes should make use of existing signaling mechanisms
+       where available.
+
+   G6  DNA schemes should make use of signaling within the link
+       (particularly link-local scope messages), because communication
+       off-link may not be achievable in the case of a link change.
+
+   G7  DNA schemes should be compatible with security schemes such as
+       Secure Neighbor Discovery [3].
+
+   G8  DNA schemes should not introduce new security vulnerabilities.
+       The node supporting DNA schemes should not expose itself or other
+       nodes on a link to additional man-in-the-middle, identity-
+       revealing, or denial-of-service attacks.
+
+   G9  Nodes (such as routers or hosts) that support DNA schemes should
+       work appropriately with unmodified nodes that do not.
+
+   G10 Hosts, especially in wireless environments, may perceive routers
+       reachable on different links.  DNA schemes should take into
+       consideration the case where a host is attached to more than one
+       link at the same time.
+
+4.  Security Considerations
+
+   The DNA process is intimately related to the Neighbor Discovery
+   protocol [1] and its trust model and threats have much in common with
+   those presented in RFC 3756 [5].  Nodes connected over wireless
+   interfaces may be particularly susceptible to jamming, monitoring,
+   and packet-insertion attacks.
+
+
+
+
+Choi & Daley                 Informational                      [Page 6]
+
+RFC 4135                       DNA Goals                     August 2005
+
+
+   With unsecured DNA schemes, it is inadvisable for a host to adjust
+   its security based on which network it believes it is attached to.
+   For example, it would be inappropriate for a host to disable its
+   personal firewall because it believed that it had connected to a home
+   network.
+
+   Even in the case where authoritative information (routing and prefix
+   state) are advertised, wireless network attackers may still prevent
+   soliciting nodes from receiving packets.  This may cause unnecessary
+   IP configuration change in some devices.  Such attacks may be used to
+   make a host preferentially select a particular configuration or
+   network access.
+
+   Devices receiving confirmations of reachability (for example, from
+   upper-layer protocols) should be aware that unless these indications
+   are sufficiently authenticated, reachability may falsely be asserted
+   by an attacker.  Similarly, even if such reachability tests are known
+   to originate from a trusted source, they should be ignored for
+   reachability confirmation if the packets are not fresh or have been
+   replayed.  This may reduce the effective window for attackers
+   replaying otherwise authentic data.
+
+   It may be dangerous to receive link-change notifications from the
+   link layer and network layer, if they are received from devices that
+   are insufficiently authenticated.  In particular, notifications that
+   authentication has completed at the link layer may not imply that a
+   security relationship is available at the network layer.  Additional
+   authentication may be required at the network layer to justify
+   modification of IP configuration.
+
+5.  Acknowledgements
+
+   Erik Nordmark has contributed significantly to work predating this
+   document.  Also Ed Remmell's comments on the inconsistency of RA
+   information were most illuminating.  The authors wish to express our
+   appreciation to Pekka Nikander for valuable feedback.  We gratefully
+   acknowledge the generous assistance we received from Shubhranshu
+   Singh for clarifying the structure of the arguments.  Thanks to Brett
+   Pentland, Nick Moore, Youn-Hee Han, JaeHoon Kim, Alper Yegin, Jim
+   Bound, and Jari Arkko for their contributions to this document.
+
+
+
+
+
+
+
+
+
+
+
+Choi & Daley                 Informational                      [Page 7]
+
+RFC 4135                       DNA Goals                     August 2005
+
+
+6.  References
+
+6.1.  Normative References
+
+   [1]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
+        for IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+   [2]  Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
+        3753, June 2004.
+
+   [3]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
+        Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+6.2.  Informative References
+
+   [4]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
+        IPv6", RFC 3775, June 2004.
+
+   [5]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
+        Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
+
+   [6]  Yegin, A., "Link-layer Event Notifications for Detecting Network
+        Attachments", work in progress, July 2005.
+
+   [7]  Aboba, B., "Detecting Network Attachment (DNA) in IPv4", work in
+        progress, June 2005.
+
+Authors' Addresses
+
+   JinHyeock Choi
+   Samsung AIT
+   Communication & N/W Lab
+   P.O.Box 111 Suwon 440-600
+   KOREA
+
+   Phone: +82 31 280 9233
+   EMail: jinchoe@samsung.com
+
+
+   Greg Daley
+   CTIE Monash University
+   Centre for Telecommunications and Information Engineering
+   Monash University
+   Clayton 3800 Victoria
+   Australia
+
+   Phone: +61 3 9905 4655
+   EMail: greg.daley@eng.monash.edu.au
+
+
+
+Choi & Daley                 Informational                      [Page 8]
+
+RFC 4135                       DNA Goals                     August 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Choi & Daley                 Informational                      [Page 9]
+