[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11                           
Internet Draft                                          R. Atkinson
draft-rja-ilnp-intro-01.txt                        Extreme Networks
Expires:  10 Dec 2008                                  10 June 2008
Category: Experimental

                       ILNP Concept of Operations
                      draft-rja-ilnp-intro-01.txt

Status of this Memo

   Distribution of this memo is unlimited.

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document is a contribution to the IRTF Routing Research Group.
   It is NOT a contribution to the IETF or to any IETF Working Group
   or to any IETF Area.


Abstract

   This documents the Concept of Operations for an experimental
   extension to IPv6 which is known as the Identifier Locator
   Network Protocol (ILNP).









Atkinson           Expires in 6 months                          [Page 1]


Internet Draft     ILNP Intro         10 JUNE 2008


Table of Contents

   1. Introduction ...................................................2
   2. Transport Protocols.............................................4
   3. Multi-Homing....................................................5
   4. Mobility........................................................6
   5. Localised Addressing............................................7
   6. IP Security Enhancements........................................7
   7. Backwards Compatibility.........................................8
   8. Incremental Deployment..........................................9
   9. Security Considerations .......................................10
  10. IANA Considerations ...........................................11
  11. References ....................................................11


1. Introduction

   At present, the IRTF Routing Research Group is studying
   different approaches to evolving the Internet Architecture.
   Several different classes of evolution are being considered.
   One class is often called "Map and Encapsulate", where
   traffic would be mapped and then tunnelled through the
   inter-domain core of the Internet.  Another class being
   considered is sometimes known as "Identifier/Locator Split".
   This document relates to a proposal that is in the latter
   class of evoluationary approaches.

   There has been substantial research relating to naming in
   the Internet through the years.[IEN-1][IEN-19][IEN-23]
   [IEN-31][RFC-814][RFC-1498] More recently, and mindful of
   that important prior work, the author has been examining
   enhancements to certain naming aspects of the Internet
   Architecture.[MobiArch07][MobiWAC07]

   This architectural concept derives originally from a note by
   Dave Clark to the IETF mailing list suggesting that the IPv6
   address be split into separate Identifier and Locator
   fields.  Afterwards, Mike O'Dell persued this concept in
   Internet-Drafts describing "GSE" or "8+8".[8+8][GSE] More
   recently, the IRTF Namespace Research Group (NSRG) studied
   this matter.  Unusually for an IRTF RG, the NSRG operated on
   the principle that unanimity was required for the NSRG to
   make a recommendation.  The author was a member of the IRTF
   NSRG.  At least one other proposal, the Host Identity
   Protocol (HIP), also derives in part from the IRTF NSRG
   studies (and related antecedant work).  This current
   proposal differs from O'Dell's work in various ways.




Atkinson           Expires in 6 months                          [Page 2]


Internet Draft     ILNP Intro         10 JUNE 2008


   The crux of this proposal is to split each 128-bit IPv6
   address into two separate fields, with crisp semantics for
   each.  It is worth remembering here that an IPv6 address
   names a specific interface on a node, since the new scheme
   will be different in that regard.














































Atkinson           Expires in 6 months                          [Page 3]


Internet Draft     ILNP Intro         10 JUNE 2008


                            1        1                2               3
    0       4      8        2        6                4               1
   +---------------+-----------------+----------------+---------------+
   | Version| Traffic Class |           Flow Label                    |
   +---------------+-----------------+----------------+---------------+
   |          Payload Length         |   Next Header  |  Hop Limit    |
   +---------------+-----------------+--------------------------------+
   |                          Source Address                          |
   +                                                                  +
   |                                                                  |
   +                                                                  +
   |                                                                  |
   +                                                                  +
   |                                                                  |
   +---------------+-----------------+----------------+---------------+
   |                        Destination  Address                      |
   +                                                                  +
   |                                                                  |
   +                                                                  +
   |                                                                  |
   +                                                                  +
   |                                                                  |
   +---------------+-----------------+----------------+---------------+

           Figure 1:  Existing ("Classic") IPv6 Header


   The high-order 64-bits of the IPv6 address become the Locator.
   The Locator indicates the subnetwork point of attachment for
   a node.  In essence, the Locator names a subnetwork.  Locators
   are also known as Routing Prefixes.

   The low-order 64-bits of the IPv6 address become the
   Identifier.  The Identifier provides a fixed-length identity
   for a node, rather than an identity for a specific interface
   of a node.  Identifiers are bound to nodes, not to
   interfaces, and are in the same modified EUI-64 syntax
   already specified for IPv6.[RFC-2460][RFC-4219][IEEE-EUI]

   Identifiers are unique within the context of a given
   Locator; in many cases, Identifiers might happen to be
   globally unique, but that is not a functional requirement
   for this proposal.

                            1        1                2               3
    0       4      8        2        6                4               1
   +---------------+-----------------+----------------+---------------+
   | Version| Traffic Class |           Flow Label                    |



Atkinson           Expires in 6 months                          [Page 4]


Internet Draft     ILNP Intro         10 JUNE 2008


   +---------------+-----------------+----------------+---------------+
   |          Payload Length         |   Next Header  |   Hop Limit   |
   +---------------+-----------------+----------------+---------------+
   |                          Source Locator                          |
   +                                                                  +
   |                                                                  |
   +---------------+-----------------+----------------+---------------+
   |                         Source Identifier                        |
   +                                                                  +
   |                                                                  |
   +---------------+-----------------+----------------+---------------+
   |                        Destination  Locator                      |
   +                                                                  +
   |                                                                  |
   +---------------+-----------------+----------------+---------------+
   |                        Destination Identifier                    |
   +                                                                  +
   |                                                                  |
   +---------------+-----------------+----------------+---------------+

              Figure 2: Enhanced IPv6 Header

   Most commonly, a node's set of Identifiers are derived from
   the IEEE 802 or IEEE 1394 MAC addresses associated with that
   node.  This use of MAC addresses to generate Identifiers is
   convenient and is not required.  Other methods also might be
   used to generate Identifiers.

   This proposal enhances the Internet Architecture by adding
   crisp and clear semantics for the Identifier and for the
   Locator, removing the semantically-muddled concept of the
   IP address, and updating end system protocols slightly,
   without requiring router changes.

   With these naming enhancements, we have improved the
   architectural support not only for multi-homing, but also
   for mobility, localised addressing, and IP Security.


2. Transport Protocols

   At present, commonly deployed transport protocols include a
   pseudo-header checksum that includes certain network-layer
   fields, the IP addresses used for the session, in its
   calculation.  This inclusion of network-layer information
   within the transport-layer session state creates issues for
   multi-homing, mobility, IP Security, and localised
   addressing (e.g. using Network Address Translation).



Atkinson           Expires in 6 months                          [Page 5]


Internet Draft     ILNP Intro         10 JUNE 2008


   [RFC-1631][RFC-3022]

   This unfortunate aspect of the TCP pseudo-header checksum
   has been understood to be an architectural problem at least
   since 1977, well before the transition from NCP to
   IPv4.[IEN-1][IEN-19][IEN-23][IEN-31][RFC-1498]

   With this proposal, transport protocols include only the
   Identifier in their pseudo-header calculations, but do not
   include the Locator in their pseudo-header calculations.

   To minimise the changes required within transport protocol
   implementations, when this proposal is in use for an IP
   session, the Locator fields are zeroed before use by the
   transport protocols.

   Later in this document, methods for incremental deployment
   of this change and backwards compatibility with non-upgraded
   nodes are described.

3. Multi-Homing

   Conceptually, there are two kinds of multi-homing.  Site
   multi-homing is when all nodes at a site are multi-homed at
   the same time.  This is what most people mean when they talk
   about multi-homing.  However, there is also a separate
   concept of node multi-homing, where only a single node is
   multi-homed.

   At present, site multi-homing is common in the deployed
   Internet.  This is primarily achieved by advertising the
   site's routing prefix(es) to more than upstream Internet
   service provider at a given time.  In turn, this requires
   de-aggregation of routing prefixes within the inter-domain
   routing system.  In turn, this increases the entropy of the
   inter-omain routing system (e.g.  RIB/FIB size increases
   beyond the minimal RIB/FIB size that would be required to
   reach all sites).

   At present, node multi-homing is not uncommon.  When TCP
   or UDP are in use for a session, node multi-homing cannot
   provide session reslience, because the transport
   pseudo-header checksum binds the session to a single
   interface of the multi-homed node.  It must be noted that
   SCTP has a protocol-specific mechanism to support node
   multi-homing; SCTP can support session resilience both at
   present and also without change in the proposed approach.




Atkinson           Expires in 6 months                          [Page 6]


Internet Draft     ILNP Intro         10 JUNE 2008


   In the new scheme, when a node is multi-homed, it has more
   than one valid Locator value.  When one upstream connection
   fails, the node sends an ICMP Locator Update message to each
   existing correspondent node to remove the no-longer-valid
   Locator from the set of valid Locators. [ILNP-ICMP] Also,
   the node will use Secure Dynamic DNS Update to alter the set
   of currently valid L records associated with that node.
   [RFC-3007] This second step ensures that any new
   correspondents can reach the node.

   In the new scheme, site multi-homing works in a similar
   manner, with nodes having one Locator for each upstream
   connection to the Internet.  To avoid a DNS Update burst
   when a site or subnetwork moves location, a DNS record
   optimisation is possible.  This would change the number of
   DNS Updates required from Order(number of nodes at the
   site/subnetwork that moved) to Order(1).[ILNP-DNS]

4.  Mobility

   There are no standardised mechanisms to update most
   transport protocols with new IP addresses in use for the
   session.  [NB: There is IETF work in progress to add this
   capability into the Stream Control Transport Protocol
   (SCTP).]

   This creates various issues for mobility.  For example,
   there is no method at present to update the IP addresses
   associated with a transport layer session when one of the
   nodes in that session moves (i.e. changes one of its points
   of network attachment).  So, the several approaches to IP
   mobility seek to hide the change in location (and
   corresponding change in IP addresses) via tunnelling, home
   agents, foreign agents, and so forth.[RFC-3775] All of this
   can add substantial complexity to IP mobility approaches,
   both in the initial deployment and also in ongoing
   operation.

   By contrast, this ILNP proposal hides the nodes location
   information from the transport layer protocols at all times,
   by removing location information from the transport session
   state (e.g. pseudo-header checksum calculations).

   In this proposal, mobility is supported using the same
   mechanisms as multihoming.  Both cases use Locator values to
   identify different IP subnetworks. To handle the move of a
   node, we add a new ICMP control message.  The ICMP Locator
   Update message is used by a node to inform its existing



Atkinson           Expires in 6 months                          [Page 7]


Internet Draft     ILNP Intro         10 JUNE 2008


   correspondents that the set of valid Locators for the node
   has changed.  This mechanism can be used to add newly valid
   Locators, to remove no longer valid Locators, or to do both
   at the same time.  Further, the node uses Secure Dynamic DNS
   Update to correct the set of L records in the DNS for that
   node.  This enables any new correspondents to correctly
   initiate a new session with the node at its new location.
   This use of DNS for initial rendezvous with mobile node was
   independently proposed by others [PHG02] and then separately
   by the current author later on.

   Note that we can (and do) treat network mobility (as well as
   node mobility) as a special case of multihoming.  That is,
   when a network moves, it uses a new Locator value for all of
   its communications sessions.  So, the same mechanism, using
   a new or additional Locator value, also supports network
   mobility.

5. Localised Addressing

   As the Locator value no longer forms part of the node
   session state (e.g. TCP pseudo-header), it is easier to
   implement localised addressing based on the use of local
   values of the Locator.  This would be either in place of,
   or to supplement, existing NAT-based schemes.[RFC-1631]
   [RFC-3022]

   In the simplest case, an ILNP capable NAT only would need to
   change the value of the Source Locator in an outbound
   packet, and the value of the Destination Locator for an
   inbound packet.  Identifier values would not need to change,
   so a true end-to-end session can be maintained.

   Please note that with this proposal, localised addressing
   (e.g. using Network Address Translation) would work in
   harmony with multihoming, mobility, and IP
   Security.[MobiWAC07]


6.  IP Security Enhancements

   A current issue is that the IP Security protocols, AH and
   ESP, have Security Associations that include the IP
   addresses of the secure session endpoints.  This was
   understood to be a problem when AH and ESP were originally
   defined, however the limited set of namespaces in the
   Internet Architecture did not provide any better choices at
   that time.



Atkinson           Expires in 6 months                          [Page 8]


Internet Draft     ILNP Intro         10 JUNE 2008


   Operationally, this binding causes problems for the use of
   the IPsec protocols through Network Address Translation
   devices, with mobile nodes (because the mobile node's IP
   address changes at each network-layer handoff), and with
   multi-homed nodes (because the session is bound to a
   particular interface of the multi-homed node, rather than
   being bound to the node itself).[RFC-3027][RFC-3715]

   To resolve the issue of IPsec interoperability through a NAT
   deployment, UDP encapsulation of IPsec is commonly used
   today.[RFC-3948]

   With this proposal, the IP Security protocols, AH and ESP,
   are enhanced to bind Security Associations only to
   Identifier values and never to Locator values (and also not
   to an entire 128-bit IPv6 address).

   Similarly, key management protocols used with IPsec would be
   enhanced to deprecate use of IP addresses as identifiers and
   to substitute the use of the new Identifier for that
   purpose.

   This small change enables IPsec to work in harmony with
   multihoming, mobility, and localised addressing.  Further,
   it would obviate the need for specialised IPsec NAT
   Traversal mechanisms, thus simplifying IPsec implementations
   while enhancing deployability and
   interoperability.[RFC-3948]

   This change does not reduce the security provided by the IP
   Security protocols.


7. Backwards Compatibility

   First, if one comapres Figure 1 and Figure 2, one can see
   that IPv6 with the Identifier/Locator Split enhancement is
   fully backwards compatible with existing IPv6.  This means
   that no router software or silicon changes are necessary to
   support the proposed enhancements.  A router would be
   unaware whether the packet being forwarded were classic IPv6
   or the proposed enhanced version of IPv6.  So no changes to
   IPv6 routers is required to deploy this proposal.

   Further, IPv6 Neighbour Discovery should work fine without
   any significant protocol changes.

   If a node that has been enhanced to support the Identifier/



Atkinson           Expires in 6 months                          [Page 9]


Internet Draft     ILNP Intro         10 JUNE 2008


   Locator Split mode initiates an IP session with another
   node, normally it will first perform a DNS lookup on the
   responding node's DNS name.  If the inititator node does not
   find any new I and L DNS resource records for the responder
   node, then the initiator uses the Classical IPv6 mode of
   operation for the new session with the responder, rather
   than trying to use the I/L Split mode for that session.

   If the responder node for a new IP session has not been
   enhanced to support the I/L Split mode and receives initial
   packet(s) containing the Nonce Destination Option, the
   responder will drop the packet and send an ICMP Parameter
   Problem error message back to the initiator.

   If the initiator node does not receive a response from the
   responder in a timely manner (e.g. within TCP timeout for a
   TCP session) and also does not receive an ICMP Unreachable
   error message for that packet, OR if the initiator receives
   an ICMP Parameter Problem error message for that packet,
   then the initiator knows that the responder is not able to
   support the I/L Split Operating mode.  In this case, the
   initiator node should try again to create the new IP session
   but this time OMITTING the Nonce Destination Option, and
   this time operating in Classic IPv6 mode, rather than I/L
   Split mode.

   The existing BSD Sockets API can continue to be used.  That
   API can be implemented in a manner that hides the underlying
   protocol changes from the applications.  So it is believed
   that existing IP address referrals can continue to work
   properly.

   It is suggested, however, that a new, optional, more
   abstract, API be created so that new applications do not
   have to delve needlessly into low-level details of the
   underlying network protocols.

8. Incremental Deployment

   If a node has been enhanced to support the Identifier/
   Locator Split operating mode, that node's fully-qualified
   domain name will normally have one or more I records and one
   or more L records associated with it in the DNS.

   When a host ("initiator') initiates a new IP session with a
   correspondent ("responder"), it normally will perform a DNS
   lookup to determine the address(es) of the responder.  A
   host that has been enhanced to support the Identifier/



Atkinson           Expires in 6 months                         [Page 10]


Internet Draft     ILNP Intro         10 JUNE 2008


   Locator Split operating mode normally will look for
   Identifier ("I") and Locator ("L") records in any received
   DNS replies.  DNS servers that support I and L records
   should include them (when they exist) as additional data in
   all DNS replies to queries for DNS AAAA records.[ILNP-DNS]

   If the initiator supports the I/L Split mode and from DNS
   information learns that the responder also supports the I/L
   Split mode, then the initiator will generate an
   unpredictable nonce value, store that value in a local
   session cache, and will include the Nonce Destination Option
   in its initial packet(s) to the responder.[ILNP-Nonce]

   If the responder supports the I/L Split mode and receives
   initial packet(s) containing the Nonce Destination Option,
   the responder will thereby know that the initiator supports
   the I/L Split mode and the responder will also operate in
   I/L Split mode for this new IP session.

   If the responder supports the I/L Split mode and receives
   initial packet(s) NOT containing the Nonce Destination Option,
   the responder will thereby know that the initiator does NOT
   support the I/L Split mode and the responder will operate
   in classic IPv6 mode for this new IP session.

   The previous section described how interoperability between
   enhanced nodes and non-enhanced nodes is retained even if a
   non-enhanced node erroneously has I and L DNS resource
   records in place (e.g. due to some accident).

9. Security Considerations

   This proposal outlines a proposed evolution for the
   Internet Architecture to provide improved capabilities.

   A separate document [ILNP-Nonce] proposed a new IPv6
   Destination Option that can be used to carry a session nonce
   end-to-end between communicating nodes.  That nonce provides
   protection against off-path attacks on an Identifier/Locator
   session.  The Nonce Destination Option is used ONLY for IP
   sessions in the Identifier/Locator Split mode.

   Ordinary IPv6 is vulnerable to on-path attacks unless
   the IP Authentication Header or IP Encapsulating Security
   Payload is in use.  So the Nonce Destination Option
   only seeks to provide protection against off-path attacks
   on an IP session -- equivalent to ordinary IPv6 when
   not using IP Security.



Atkinson           Expires in 6 months                         [Page 11]


Internet Draft     ILNP Intro         10 JUNE 2008


   When the Identifier/Locator split mode is in use for an
   existing IP session, the Nonce Destination Option must be
   included in any ICMP control messages (e.g. ICMP Unreachable,
   ICMP Locator Update) sent with regard to that IP session.

   When in the I/L Split operating mode for an existing IP
   session, ICMP control messages received without a Nonce
   Destination Option must be discarded as forgeries.  This
   security event should be logged.

   When in the I/L Split operating mode for an existing IP
   session, ICMP control messages received without a correct
   nonce value inside the Nonce Destination Option must be
   discarded as forgeries.  This security event should be logged.

   For ID/Locator Split mode sessions operating in higher risk
   environments, the use of the cryptographic authentication
   provided by IP Authentication Header is recommended
   *in addition* to concurrent use of the Nonce Destination
   Option.

   The IP Security standards are enhanced here by binding IPsec
   Security Associations to the Identifiers of the session
   endpoints, rather than binding IPsec Security Associations
   to the IP Addresses as at present.  This change enhances the
   deployability and interoperability of the IP Security
   standards, but does not decrease the security provided by
   those protocols.

   The DNS enhancements proposed here are entirely compatible
   with, and can be protected using, the existing IETF
   standards for DNS Security.[RFC-4033] The Secure DNS Dynamic
   Update mechanism used here is also used unchanged.[RFC-3007]
   So there is no change to the security properties of the
   Domain Name System.

   In the proposed new scheme, firewalls are able to
   authenticate ICMP control messages arriving on the external
   interface.  This enables more thoughtful handling of ICMP
   messages by firewalls than is commonly the case at present.
   As the firewall is along the path between the communicating
   nodes, the firewall can snoop on any Session Nonce being
   carried in the initial packets of an I/L Split mode session.
   The firewall can verify that nonce is present on incoming
   control packets, dropping any control packets that lack the
   correct nonce value.  By always including the nonce, even
   when IP Security is also in use, the firewall can filter out
   all off-path attacks.  In this last case, a forged packet



Atkinson           Expires in 6 months                         [Page 12]


Internet Draft     ILNP Intro         10 JUNE 2008


   from an on-path attacker will still be detected when the
   IPsec input processing occurs in the receiving node; this
   will cause that forged packet to be dropped rather than
   acted upon.  It is important to note that at present an IPv6
   session is entirely vulnerable to on-path attacks unless
   IPsec is in use for that particular IPv6 session, so the
   security properties of the new proposal are never worse than
   for existing IPv6.

10. IANA Considerations

   This document has no IANA considerations.

11.  References

   This section provides both normative and informative
   references relating to this note.

11.1.  Normative References

   [RFC-4033]   R. Arends, et alia, "DNS Security Introduction
                and Requirements", RFC-4033, March 2005.

   [RFC-4219]   R. Hinden & S. Deering, "IP Version 6
                Addressing Architecture", RFC-4219, February
                2006.

   [RFC-2460]   S. Deering & R. Hinden, "Internet Protocol
                Version 6 Specification", RFC-2460, December
                1998.

   [RFC-3007]   B. Wellington, "Secure Domain Name System
                Dynamic Update", RFC-3007, November 2000.

11.2.  Informative References

   [8+8]        M. O'Dell, "8+8 - An Alternate Addressing
                Architecture for IPv6", Internet-Draft,
                October 1996.

   [GSE]        M. O'Dell, "GSE - An Alternate Addressing
                Architecture for IPv6", Internet-Draft,
                February 1997.

   [IEEE-EUI]   IEEE Standards Association, "Guidelines for
                64-bit Global Identifier (EUI-64)", IEEE,
                2007.




Atkinson           Expires in 6 months                         [Page 13]


Internet Draft     ILNP Intro         10 JUNE 2008


   [IEN-1]      C.J. Bennett, S.W. Edge, & A.J. Hinchley,
                "Issues in the Interconnection of Datagram
                Networks", Internet Experiment Note (IEN) 1,
                INDRA Note 637, PSPWN 76, University College
                London, 29 July 1977.
                http://www.postel.org/ien/ien001.pdf

   [IEN-19]     J. F. Shoch, "Inter-Network Naming, Addressing,
                and Routing", IEN-19, January 1978.

   [IEN-23]     J. F. Shoch, "On Names, Addresses, and
                Routings", IEN-23, January 1978.

   [IEN-31]     D. Cohen, "On Names, Addresses, and Routings
                (II)", IEN-31, April 1978.

   [ILNP-Nonce] R. Atkinson, "Nonce Destination Option",
                June 2008.

   [ILNP-DNS]   R. Atkinson, "DNS Resource Records for
                Identifier/Locator Use", June 2008.

   [ILNP-ICMP]  R. Atkinson, "ICMP Locator Update message"
                June 2008.

   [MobiArch07] R. Atkinson, S. Bhatti, & S. Hailes,
                "Mobility as an Integrated Service Through
                the Use of Naming", Proceedings of
                ACM MobiArch 2007, August 2007,
                Kyoto, Japan.

   [MobiWAC07]  R. Atkinson, S. Bhatti, & S. Hailes,
                "A Proposal for Unifying Mobility with
                Multi-Homing, NAT, & Security",
                Proceedings of ACM MobiWAC 2007, Chania,
                Crete. ACM, October 2007.

   [PHG02]      Pappas, A, S. Hailes, & R. Giaffreda,
                "Mobile Host Location Tracking through DNS",
                Proceedings of IEEE London Communications
                Symposium, IEEE, September 2002, London,
                England, UK.

   [RFC-814]    D.D. Clark, "Names, Addresses, Ports, and
                Routes", RFC-814, July 1982.

   [RFC-1498]   J.H. Saltzer, "On the Naming and Binding of
                Network Destinations", RFC-1498, August 1993.



Atkinson           Expires in 6 months                         [Page 14]


Internet Draft     ILNP Intro         10 JUNE 2008


   [RFC-1631]   K. Egevang & P. Francis, "The IP Network
                Address Translator (NAT)", RFC-1631, May 1994.

   [RFC-3022]   P. Srisuresh & K. Egevang, "Traditional IP
                Network Address Translator", RFC-3022,
                January 2001.

   [RFC-3027]   M. Holdrege and P Srisuresh, "Protocol
                Complications of the IP Network Address
                Translator", RFC-3027, January 2001.

   [RFC-3715]   B. Aboba and W. Dixon, "IPsec-Network Address
                Translation (NAT) Compatibility Requirements",
                RFC-3715, March 2004.

   [RFC-3775]   D. Johnson, C. Perkins, and J. Arkko, "Mobility
                Support in IPv6", RFC-3775, June 2004.

   [RFC-3948]   A. Huttunen, et alia, "UDP Encapsulation of
                IPsec ESP Packets", RFC-3948, January 2005.

   (Additional references to be added later.)

Author's Address

   R. Atkinson
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA
   95051  USA

   Telephone: +1 (408)579-2800
   Email:     rja@extremenetworks.com


















Atkinson           Expires in 6 months                         [Page 15]


Internet Draft     ILNP Intro         10 JUNE 2008


Full Copyright Statement

  Copyright (C) The IETF Trust (2008).

  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.

  This document may not be modified, and derivative works of it
  may not be created.

  This document may only be posted in an Internet-Draft.

Expires: 10 December 2008



Atkinson           Expires in 6 months                         [Page 16]


Internet Draft     ILNP Intro         10 JUNE 2008





















































Atkinson           Expires in 6 months                         [Page 17]