doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc7596.txt b/doc/rfc/rfc7596.txt
new file mode 100644
index 0000000..ecc4e86
--- /dev/null
+++ b/doc/rfc/rfc7596.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            Y. Cui
+Request for Comments: 7596                           Tsinghua University
+Category: Standards Track                                         Q. Sun
+ISSN: 2070-1721                                            China Telecom
+                                                            M. Boucadair
+                                                          France Telecom
+                                                                 T. Tsou
+                                                     Huawei Technologies
+                                                                  Y. Lee
+                                                                 Comcast
+                                                               I. Farrer
+                                                     Deutsche Telekom AG
+                                                               July 2015
+
+
+  Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture
+
+Abstract
+
+   Dual-Stack Lite (DS-Lite) (RFC 6333) describes an architecture for
+   transporting IPv4 packets over an IPv6 network.  This document
+   specifies an extension to DS-Lite called "Lightweight 4over6", which
+   moves the Network Address and Port Translation (NAPT) function from
+   the centralized DS-Lite tunnel concentrator to the tunnel client
+   located in the Customer Premises Equipment (CPE).  This removes the
+   requirement for a Carrier Grade NAT function in the tunnel
+   concentrator and reduces the amount of centralized state that must be
+   held to a per-subscriber level.  In order to delegate the NAPT
+   function and make IPv4 address sharing possible, port-restricted IPv4
+   addresses are allocated to the CPEs.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7596.
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 1]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Conventions .....................................................4
+   3. Terminology .....................................................5
+   4. Lightweight 4over6 Architecture .................................6
+   5. Lightweight B4 Behavior .........................................7
+      5.1. Lightweight B4 Provisioning with DHCPv6 ....................7
+      5.2. Lightweight B4 Data-Plane Behavior ........................10
+           5.2.1. Fragmentation Behavior .............................11
+   6. Lightweight AFTR Behavior ......................................12
+      6.1. Binding Table Maintenance .................................12
+      6.2. lwAFTR Data-Plane Behavior ................................13
+   7. Additional IPv4 Address and Port-Set Provisioning Mechanisms ...14
+   8. ICMP Processing ................................................14
+      8.1. ICMPv4 Processing by the lwAFTR ...........................15
+      8.2. ICMPv4 Processing by the lwB4 .............................15
+   9. Security Considerations ........................................15
+   10. References ....................................................16
+      10.1. Normative References .....................................16
+      10.2. Informative References ...................................17
+   Acknowledgements ..................................................19
+   Contributors ......................................................19
+   Authors' Addresses ................................................21
+
+
+
+
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 2]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+1.  Introduction
+
+   Dual-Stack Lite (DS-Lite) [RFC6333] defines a model for providing
+   IPv4 access over an IPv6 network using two well-known technologies:
+   IP in IP [RFC2473] and Network Address Translation (NAT).  The
+   DS-Lite architecture defines two major functional elements as
+   follows:
+
+   Basic Bridging BroadBand (B4) element:  A function implemented on a
+      dual-stack-capable node (either a directly connected device or a
+      CPE) that creates an IPv4-in-IPv6 tunnel to an AFTR.
+
+   Address Family Transition Router (AFTR) element:  The combination of
+      an IPv4-in-IPv6 tunnel endpoint and an IPv4-IPv4 NAT implemented
+      on the same node.
+
+   As the AFTR performs the centralized NAT44 function, it dynamically
+   assigns public IPv4 addresses and ports to a requesting host's
+   traffic (as described in [RFC3022]).  To achieve this, the AFTR must
+   dynamically maintain per-flow state in the form of active NAPT
+   sessions.  For service providers with a large number of B4 clients,
+   the size and associated costs for scaling the AFTR can quickly become
+   prohibitive.  Maintaining per-flow state can also place a large NAPT
+   logging overhead on the service provider in countries where logging
+   is a legal requirement.
+
+   This document describes a mechanism called "Lightweight 4over6"
+   (lw4o6), which provides a solution for these problems.  By relocating
+   the NAPT functionality from the centralized AFTR to the distributed
+   B4s, a number of benefits can be realized:
+
+   o  NAPT44 functionality is already widely supported and used in
+      today's CPE devices.  lw4o6 uses this to provide private<->public
+      NAPT44, meaning that the service provider does not need a
+      centralized NAT44 function.
+
+   o  The amount of state that must be maintained centrally in the AFTR
+      can be reduced from per-flow to per-subscriber.  This reduces
+      the amount of resources (memory and processing power) necessary in
+      the AFTR.
+
+   o  The reduction of maintained state results in a greatly reduced
+      logging overhead on the service provider.
+
+   Operators' IPv6 and IPv4 addressing architectures remain independent
+   of each other.  Therefore, flexible IPv4/IPv6 addressing schemes can
+   be deployed.
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 3]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   Lightweight 4over6 is a solution designed specifically for complete
+   independence between IPv6 subnet prefixes and IPv4 addresses with or
+   without IPv4 address sharing.  This is accomplished by maintaining
+   state for each softwire (per-subscriber state) in the central lwAFTR
+   and a hub-and-spoke forwarding architecture.  "Mapping of Address and
+   Port with Encapsulation (MAP-E)" [RFC7597] also offers these
+   capabilities or, alternatively, allows for a reduction of the amount
+   of centralized state using rules to express IPv4/IPv6 address
+   mappings.  This introduces an algorithmic relationship between the
+   IPv6 subnet and IPv4 address.  This relationship also allows the
+   option of direct, meshed connectivity between users.
+
+   The tunneling mechanism remains the same for DS-Lite and Lightweight
+   4over6.  This document describes the changes to DS-Lite that are
+   necessary to implement Lightweight 4over6.  These changes mainly
+   concern the configuration parameters and provisioning method
+   necessary for the functional elements.
+
+   One of the features of Lightweight 4over6 is to keep per-subscriber
+   state in the service provider's network.  This technique is
+   categorized as a "binding approach" [Unified-v4-in-v6] that defines a
+   unified IPv4-in-IPv6 softwire CPE.
+
+   This document extends the mechanism defined in [RFC7040] by allowing
+   address sharing.  The solution in this document is also a variant of
+   Address plus Port (A+P) called "Binding Table Mode" (see Section 4.4
+   of [RFC6346]).
+
+   This document focuses on architectural considerations, particularly
+   on the expected behavior of the involved functional elements and
+   their interfaces.  Deployment-specific issues such as redundancy and
+   provisioning policy are out of scope for this document.
+
+2.  Conventions
+
+   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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 4]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+3.  Terminology
+
+   This document defines the following terms:
+
+   Lightweight 4over6 (lw4o6):   An IPv4-over-IPv6 hub-and-spoke
+                                 mechanism that extends DS-Lite by
+                                 moving the IPv4 translation (NAPT44)
+                                 function from the AFTR to the B4.
+
+   Lightweight B4 (lwB4):        A B4 element [RFC6333] that supports
+                                 Lightweight 4over6 extensions.  An lwB4
+                                 is a function implemented on a
+                                 dual-stack-capable node -- either a
+                                 directly connected device or a CPE --
+                                 that supports port-restricted IPv4
+                                 address allocation, implements NAPT44
+                                 functionality, and creates a tunnel to
+                                 an lwAFTR.
+
+   Lightweight AFTR (lwAFTR):    An AFTR element [RFC6333] that supports
+                                 the Lightweight 4over6 extension.  An
+                                 lwAFTR is an IPv4-in-IPv6 tunnel
+                                 endpoint that maintains per-subscriber
+                                 address binding only and does not
+                                 perform a NAPT44 function.
+
+   Restricted port set:          A non-overlapping range of allowed
+                                 external ports allocated to the lwB4 to
+                                 use for NAPT44.  Source ports of IPv4
+                                 packets sent by the B4 must belong to
+                                 the assigned port set.  The port set is
+                                 used for all port-aware IP protocols
+                                 (TCP, UDP, the Stream Control
+                                 Transmission Protocol (SCTP), etc.).
+
+   Port-restricted IPv4 address: A public IPv4 address with a restricted
+                                 port set.  In Lightweight 4over6,
+                                 multiple B4s may share the same IPv4
+                                 address; however, their port sets must
+                                 be non-overlapping.
+
+   Throughout the remainder of this document, the terms "B4" and "AFTR"
+   should be understood to refer specifically to a DS-Lite
+   implementation.  The terms "lwB4" and "lwAFTR" refer to a Lightweight
+   4over6 implementation.
+
+
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 5]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+4.  Lightweight 4over6 Architecture
+
+   The Lightweight 4over6 architecture is functionally similar to
+   DS-Lite.  lwB4s and an lwAFTR are connected through an IPv6-enabled
+   network.  Both approaches use an IPv4-in-IPv6 encapsulation scheme to
+   deliver IPv4 connectivity.  The following figure shows the data plane
+   with the main functional change between DS-Lite and lw4o6:
+
+   +--------+   +---------+  IPv4-in-IPv6  +---------+   +-------------+
+   |IPv4 LAN|---|    B4   |================|AFTR/NAPT|---|IPv4 Internet|
+   +--------+   +---------+                +---------+   +-------------+
+                  DS-Lite NAPT model: all state in the AFTR
+
+
+   +--------+   +---------+  IPv4-in-IPv6  +------+   +-------------+
+   |IPv4 LAN|---|lwB4/NAPT|================|lwAFTR|---|IPv4 Internet|
+   +--------+   +---------+                +------+   +-------------+
+                           lw4o6 NAPT model:
+           subscriber state in the lwAFTR, NAPT state in the lwB4
+
+     Figure 1: Comparison of DS-Lite and Lightweight 4over6 Data Plane
+
+   There are three main components in the Lightweight 4over6
+   architecture:
+
+   o  The lwB4, which performs the NAPT function and IPv4/IPv6
+      encapsulation/decapsulation.
+
+   o  The lwAFTR, which performs the IPv4/IPv6 encapsulation/
+      decapsulation.
+
+   o  The provisioning system, which tells the lwB4 which IPv4 address
+      and port set to use.
+
+   The lwB4 differs from a regular B4 in that it now performs the NAPT
+   functionality.  This means that it needs to be provisioned with the
+   public IPv4 address and port set it is allowed to use.  This
+   information is provided through a provisioning mechanism such as
+   DHCP, the Port Control Protocol (PCP) [RFC6887], or the Broadband
+   Forum's TR-69 specification [TR069].
+
+   The lwAFTR needs to know the binding between the IPv6 address of
+   each subscriber as well as the IPv4 address and port set allocated to
+   each subscriber.  This information is used to perform ingress
+   filtering upstream and encapsulation downstream.  Note that this is
+   per-subscriber state, as opposed to per-flow state in the regular
+   AFTR case.
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 6]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   The consequence of this architecture is that the information
+   maintained by the provisioning mechanism and the one maintained by
+   the lwAFTR MUST be synchronized (see Figure 2).  The precise
+   mechanism whereby this synchronization occurs is out of scope for
+   this document.
+
+   The solution specified in this document allows the assignment of
+   either a full or a shared IPv4 address to requesting CPEs.  [RFC7040]
+   provides a mechanism for assigning a full IPv4 address only.
+
+                             +------------+
+                     /-------|Provisioning|<-----\
+                     |       +------------+      |
+                     |                           |
+                     V                           V
+   +--------+   +---------+    IPv4/IPv6     +------+    +-------------+
+   |IPv4 LAN|---|lwB4/NAPT|==================|lwAFTR|----|IPv4 Internet|
+   +--------+   +---------+                  +------+    +-------------+
+
+         Figure 2: Lightweight 4over6 Provisioning Synchronization
+
+5.  Lightweight B4 Behavior
+
+5.1.  Lightweight B4 Provisioning with DHCPv6
+
+   With DS-Lite, the B4 element only needs to be configured with a
+   single DS-Lite-specific parameter so that it can set up the softwire
+   (the IPv6 address of the AFTR).  Its IPv4 address can be taken from
+   the well-known range 192.0.0.0/29.
+
+   In lw4o6, a number of lw4o6-specific configuration parameters must be
+   provisioned to the lwB4.  These are:
+
+   o  IPv6 address for the lwAFTR
+
+   o  IPv4 external (public) address for NAPT44
+
+   o  Restricted port set to use for NAPT44
+
+   o  IPv6 binding prefix
+
+   The lwB4 MUST implement DHCPv6-based configuration using
+   OPTION_S46_CONT_LW as described in Section 5.3 of [RFC7598].  This
+   means that the lifetime of the softwire and the derived configuration
+   information (e.g., IPv4 shared address, IPv4 address) are bound to
+   the lifetime of the DHCPv6 lease.  If stateful IPv4 configuration or
+   additional IPv4 configuration information is required, DHCP 4o6
+   [RFC7341] MUST be used.
+
+
+
+Cui, et al.                  Standards Track                    [Page 7]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   Although it would be possible to extend lw4o6 to have more than one
+   active lw4o6 tunnel configured simultaneously, this document is only
+   concerned with the use of a single tunnel.
+
+   The IPv6 binding prefix field is provisioned so that the Customer
+   Edge (CE) can identify the correct prefix to use as the tunnel
+   source.  On receipt of the necessary configuration parameters listed
+   above, the lwB4 performs a longest-prefix match between the IPv6
+   binding prefix and its currently active IPv6 prefixes.  The result
+   forms the subnet to be used for sourcing the lw4o6 tunnel.  The full
+   /128 address is then constructed in the same manner as [RFC7597].
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Operator Assigned Prefix                     |
+   .                        (64 bits)                              .
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Zero Padding          |         IPv4 Address          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       IPv4 Addr cont.         |             PSID              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 3: Construction of the lw4o6 /128 Prefix
+
+   Operator Assigned Prefix:
+                 IPv6 prefix allocated to the client.  If the prefix
+                 length is less than 64, it is right-padded with zeros
+                 to 64 bits.
+
+   Padding:      Padding (all zeros).
+
+   IPv4 Address: Public IPv4 address allocated to the client.
+
+   PSID:         Port Set ID.  Allocated to the client; left-padded with
+                 zeros to 16 bits.  If no PSID is provisioned, all
+                 zeros.
+
+   In the event that the lwB4's IPv6 encapsulation source address is
+   changed for any reason (such as the DHCPv6 lease expiring), the
+   lwB4's dynamic provisioning process MUST be re-initiated.  When the
+   lwB4's public IPv4 address or Port Set ID is changed for any reason,
+   the lwB4 MUST flush its NAPT table.
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 8]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   An lwB4 MUST support dynamic port-restricted IPv4 address
+   provisioning.  The port-set algorithm for provisioning this is
+   described in Section 5.1 of [RFC7597].  For lw4o6, the number of
+   a-bits SHOULD be 0, thus allocating a single contiguous port set to
+   each lwB4.
+
+   Provisioning of the lwB4 using DHCPv6 as described here allocates a
+   single PSID to the client.  In the event that the client is
+   concurrently using all of the provisioned L4 ports, it may be unable
+   to initiate any additional outbound connections.  DHCPv6-based
+   provisioning does not provide a mechanism for the client to request
+   more L4 port numbers.  Other provisioning mechanisms (e.g., PCP-based
+   provisioning [PCP-PORT_SET]) provide this function.  Issues relevant
+   to IP address sharing are discussed in more detail in [RFC6269].
+
+   Unless an lwB4 is being allocated a full IPv4 address, it is
+   RECOMMENDED that PSIDs containing the system ports (0-1023) not be
+   allocated to lwB4s.  The reserved ports are more likely to be
+   reserved by middleware, and therefore we recommend that they not be
+   issued to clients other than as a deliberate assignment.
+   Section 5.2.2 of [RFC6269] provides analysis of allocating system
+   ports to clients with IPv4 address sharing.
+
+   In the event that the lwB4 receives an ICMPv6 error message (Type 1,
+   Code 5) originating from the lwAFTR, the lwB4 interprets this to mean
+   that no matching entry in the lwAFTR's binding table has been found,
+   so the IPv4 payload is not being forwarded by the lwAFTR.  The lwB4
+   MAY then re-initiate the dynamic port-restricted provisioning
+   process.  The lwB4's re-initiation policy SHOULD be configurable.
+
+   On receipt of such an ICMP error message, the lwB4 MUST validate the
+   source address to be the same as the lwAFTR address that is
+   configured.  In the event that these addresses do not match, the lwB4
+   MUST discard the ICMP error message.
+
+   In order to prevent forged ICMP messages (using the spoofed lwAFTR
+   address as the source) from being sent to lwB4s, the operator can
+   implement network ingress filtering as described in [RFC2827].
+
+   The DNS considerations described in Sections 5.5 and 6.4 of [RFC6333]
+   apply to Lightweight 4over6; lw4o6 implementations MUST comply with
+   all requirements stated there.
+
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                    [Page 9]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+5.2.  Lightweight B4 Data-Plane Behavior
+
+   Several sections of [RFC6333] provide background information on the
+   B4's data-plane functionality and MUST be implemented by the lwB4, as
+   they are common to both solutions.  The relevant sections are:
+
+   5.2 Encapsulation                 Covering encapsulation and
+                                     decapsulation of tunneled traffic
+
+   5.3 Fragmentation and Reassembly  Covering MTU and fragmentation
+                                     considerations (referencing
+                                     [RFC2473])
+
+   7.1 Tunneling                     Covering tunneling and Traffic
+                                     Class mapping between IPv4 and IPv6
+                                     (referencing [RFC2473]).  Also see
+                                     [RFC2983]
+
+   The lwB4 element performs IPv4 address translation (NAPT44) as well
+   as encapsulation and decapsulation.  It runs standard NAPT44
+   [RFC3022] using the allocated port-restricted address as its external
+   IPv4 address and range of source ports.
+
+   The working flow of the lwB4 is illustrated in Figure 4.
+
+                        +-------------+
+                        |     lwB4    |
+      +--------+  IPv4  |------+------| IPv4-in-IPv6  +----------+
+      |IPv4 LAN|------->|      |Encap.|-------------->|Configured|
+      |        |<-------| NAPT |  or  |<--------------|  lwAFTR  |
+      +--------+        |      |Decap.|               +----------+
+                        +------+------+
+
+                    Figure 4: Working Flow of the lwB4
+
+   Hosts connected to the customer's network behind the lwB4 source IPv4
+   packets with an [RFC1918] address.  When the lwB4 receives such an
+   IPv4 packet, it performs a NAPT44 function on the source address and
+   port by using the public IPv4 address and a port number from the
+   allocated port set.  Then, it encapsulates the packet with an IPv6
+   header.  The destination IPv6 address is the lwAFTR's IPv6 address,
+   and the source IPv6 address is the lwB4's IPv6 tunnel endpoint
+   address.  Finally, the lwB4 forwards the encapsulated packet to the
+   configured lwAFTR.
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 10]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   When the lwB4 receives an IPv4-in-IPv6 packet from the lwAFTR, it
+   decapsulates the IPv4 packet from the IPv6 packet.  Then, it performs
+   NAPT44 translation on the destination address and port, based on the
+   available information in its local NAPT44 table.
+
+   If the IPv6 source address does not match the configured lwAFTR
+   address, then the packet MUST be discarded.  If the decapsulated IPv4
+   packet does not match the lwB4's configuration (i.e., invalid
+   destination IPv4 address or port), then the packet MUST be dropped.
+   An ICMPv4 error message (Type 3, Code 13 -- Destination Unreachable,
+   Communication Administratively Prohibited) MAY be sent back to the
+   lwAFTR.  The ICMP policy SHOULD be configurable.
+
+   The lwB4 is responsible for performing Application Layer Gateway
+   (ALG) functions (e.g., SIP, FTP) and other NAPT traversal mechanisms
+   (e.g., Universal Plug and Play (UPnP) IGD (Internet Gateway Device),
+   the NAT Port Mapping Protocol (NAT-PMP), manual binding
+   configuration, PCP) for the internal hosts, if necessary.  This
+   requirement is typical for NAPT44 gateways available today.
+
+   It is possible that an lwB4 is co-located in a host.  In this case,
+   the functions of NAPT44 and encapsulation/decapsulation are
+   implemented inside the host.
+
+5.2.1.  Fragmentation Behavior
+
+   For TCP and UDP traffic, the NAPT44 implemented in the lwB4 MUST
+   conform to the behavior and best current practices documented in
+   [RFC4787], [RFC5508], and [RFC5382].  If the lwB4 supports the
+   Datagram Congestion Control Protocol (DCCP), then the requirements in
+   [RFC5597] MUST be implemented.
+
+   The NAPT44 in the lwB4 MUST implement ICMP message handling behavior
+   conforming to the best current practice documented in [RFC5508].  If
+   the lwB4 receives an ICMP error (for errors detected inside the IPv6
+   tunnel), the node relays the ICMP error message to the original
+   source (the lwAFTR).  This behavior SHOULD be implemented conforming
+   to Section 8 of [RFC2473].
+
+   If IPv4 hosts behind different lwB4s sharing the same IPv4 address
+   send fragments to the same IPv4 destination host outside the
+   Lightweight 4over6 domain, those hosts may use the same IPv4
+   fragmentation identifier, resulting in incorrect reassembly of the
+   fragments at the destination host.  Given that the IPv4 fragmentation
+   identifier is a 16-bit field, it could be used similarly to port
+   ranges: An lwB4 could rewrite the IPv4 fragmentation identifier to be
+   within its allocated port set, if the resulting fragment identifier
+   space is large enough related to the rate at which fragments are
+
+
+
+Cui, et al.                  Standards Track                   [Page 11]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   sent.  However, splitting the identifier space in this fashion would
+   increase the probability of reassembly collision for all connections
+   through the lwB4.  See also Section 5.3.1 of [RFC6864].
+
+6.  Lightweight AFTR Behavior
+
+6.1.  Binding Table Maintenance
+
+   The lwAFTR maintains an address binding table containing the binding
+   between the lwB4's IPv6 address, the allocated IPv4 address, and the
+   restricted port set.  Unlike the DS-Lite extended binding table,
+   which is a 5-tuple NAPT table and is defined in Section 6.6 of
+   [RFC6333], each entry in the Lightweight 4over6 binding table
+   contains the following 3-tuples:
+
+   o  IPv6 address for a single lwB4
+
+   o  Public IPv4 address
+
+   o  Restricted port set
+
+   The entry has two functions: the IPv6 encapsulation of inbound
+   IPv4 packets destined to the lwB4 and the validation of outbound
+   IPv4-in-IPv6 packets received from the lwB4 for decapsulation.
+
+   The lwAFTR does not perform NAPT and so does not need session
+   entries.
+
+   The lwAFTR MUST synchronize the binding information with the
+   port-restricted address provisioning process.  If the lwAFTR does not
+   participate in the port-restricted address provisioning process, the
+   binding MUST be synchronized through other methods (e.g., out-of-band
+   static update).
+
+   If the lwAFTR participates in the port-restricted provisioning
+   process, then its binding table MUST be created as part of this
+   process.
+
+   For all provisioning processes, the lifetime of binding table entries
+   MUST be synchronized with the lifetime of address allocations.
+
+
+
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 12]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+6.2.  lwAFTR Data-Plane Behavior
+
+   Several sections of [RFC6333] provide background information on
+   the AFTR's data-plane functionality and MUST be implemented by the
+   lwAFTR, as they are common to both solutions.  The relevant
+   sections are:
+
+   6.2 Encapsulation                 Covering encapsulation and
+                                     decapsulation of tunneled traffic
+
+   6.3 Fragmentation and Reassembly  Fragmentation and reassembly
+                                     considerations (referencing
+                                     [RFC2473])
+
+   7.1 Tunneling                     Covering tunneling and Traffic
+                                     Class mapping between IPv4 and IPv6
+                                     (referencing [RFC2473]).  Also see
+                                     [RFC2983]
+
+   When the lwAFTR receives an IPv4-in-IPv6 packet from an lwB4, it
+   decapsulates the IPv6 header and verifies the source addresses and
+   port in the binding table.  If both the source IPv4 and IPv6
+   addresses match a single entry in the binding table and the source
+   port is in the allowed port set for that entry, the lwAFTR forwards
+   the packet to the IPv4 destination.
+
+   If no match is found (e.g., no matching IPv4 address entry, port out
+   of range), the lwAFTR MUST discard or implement a policy (such as
+   redirection) on the packet.  An ICMPv6 Type 1, Code 5 (Destination
+   Unreachable, source address failed ingress/egress policy) error
+   message MAY be sent back to the requesting lwB4.  The ICMP policy
+   SHOULD be configurable.
+
+   When the lwAFTR receives an inbound IPv4 packet, it uses the IPv4
+   destination address and port to look up the destination lwB4's IPv6
+   address in its binding table.  If a match is found, the lwAFTR
+   encapsulates the IPv4 packet.  The source is the lwAFTR's IPv6
+   address, and the destination is the lwB4's IPv6 address from the
+   matched entry.  Then, the lwAFTR forwards the packet to the lwB4
+   natively over the IPv6 network.
+
+   If no match is found, the lwAFTR MUST discard the packet.  An ICMPv4
+   Type 3, Code 1 (Destination Unreachable, Host Unreachable) error
+   message MAY be sent back.  The ICMP policy SHOULD be configurable.
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 13]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   The lwAFTR MUST support hairpinning of traffic between two lwB4s, by
+   performing decapsulation and re-encapsulation of packets from one
+   lwB4 that need to be sent to another lwB4 associated with the same
+   AFTR.  The hairpinning policy MUST be configurable.
+
+7.  Additional IPv4 Address and Port-Set Provisioning Mechanisms
+
+   In addition to the DHCPv6-based mechanism described in Section 5.1,
+   several other IPv4 provisioning protocols have been suggested.  These
+   protocols MAY be implemented.  These alternatives include:
+
+   o  DHCPv4 over DHCPv6: [RFC7341] describes implementing DHCPv4
+      messages over an IPv6-only service provider's network.  This
+      enables leasing of IPv4 addresses and makes DHCPv4 options
+      available to the DHCPv4-over-DHCPv6 client.  An lwB4 MAY implement
+      [RFC7341] and [Dyn-Shared-v4Alloc] to retrieve a shared IPv4
+      address with a set of ports.
+
+   o  PCP [RFC6887]: an lwB4 MAY use [PCP-PORT_SET] to retrieve a
+      restricted IPv4 address and a set of ports.
+
+   In a Lightweight 4over6 domain, the binding information MUST be
+   synchronized across the lwB4s, the lwAFTRs, and the provisioning
+   server.
+
+   To prevent interworking complexity, it is RECOMMENDED that an
+   operator use a single provisioning mechanism / protocol for their
+   implementation.  In the event that more than one provisioning
+   mechanism / protocol needs to be used (for example, during a
+   migration to a new provisioning mechanism), the operator SHOULD
+   ensure that each provisioning mechanism has a discrete set of
+   resources (e.g., IPv4 address/PSID pools, as well as lwAFTR tunnel
+   addresses and binding tables).
+
+8.  ICMP Processing
+
+   For both the lwAFTR and the lwB4, ICMPv6 MUST be handled as described
+   in [RFC2473].
+
+   ICMPv4 does not work in an address-sharing environment without
+   special handling [RFC6269].  Due to the port-set style of address
+   sharing, Lightweight 4over6 requires specific ICMP message handling
+   not required by DS-Lite.
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 14]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+8.1.  ICMPv4 Processing by the lwAFTR
+
+   For inbound ICMP messages, the following behavior SHOULD be
+   implemented by the lwAFTR to provide ICMP error handling and basic
+   remote IPv4 service diagnostics for a port-restricted CPE:
+
+   1.  Check the ICMP Type field.
+
+   2.  If the ICMP Type field is set to 0 or 8 (echo reply or request),
+       then the lwAFTR MUST take the value of the ICMP Identifier field
+       as the source port and use this value to look up the binding
+       table for an encapsulation destination.  If a match is found, the
+       lwAFTR forwards the ICMP packet to the IPv6 address stored in the
+       entry; otherwise, it MUST discard the packet.
+
+   3.  If the ICMP Type field is set to any other value, then the lwAFTR
+       MUST use the method described in REQ-3 of [RFC5508] to locate the
+       source port within the transport-layer header in the ICMP
+       packet's data field.  The destination IPv4 address and source
+       port extracted from the ICMP packet are then used to make a
+       lookup in the binding table.  If a match is found, it MUST
+       forward the ICMP reply packet to the IPv6 address stored in the
+       entry; otherwise, it MUST discard the packet.
+
+   Otherwise, the lwAFTR MUST discard all inbound ICMPv4 messages.
+
+   The ICMP policy SHOULD be configurable.
+
+8.2.  ICMPv4 Processing by the lwB4
+
+   The lwB4 MUST implement the requirements defined in [RFC5508] for
+   ICMP forwarding.  For ICMP echo request packets originating from the
+   private IPv4 network, the lwB4 SHOULD implement the method described
+   in [RFC6346] and use an available port from its port set as the ICMP
+   identifier.
+
+9.  Security Considerations
+
+   As the port space for a subscriber shrinks due to address sharing,
+   the randomness for the port numbers of the subscriber is decreased
+   significantly.  This means that it is much easier for an attacker to
+   guess the port number used, which could result in attacks ranging
+   from throughput reduction to broken connections or data corruption.
+
+   The port set for a subscriber can be a set of contiguous ports or
+   non-contiguous ports.  Contiguous port sets do not reduce this
+   threat.  However, with non-contiguous port sets (which may be
+   generated in a pseudorandom way [RFC6431]), the randomness of the
+
+
+
+Cui, et al.                  Standards Track                   [Page 15]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   port number is improved, provided that the attacker is outside the
+   Lightweight 4over6 domain and hence does not know the port-set
+   generation algorithm.
+
+   The lwAFTR MUST rate-limit ICMPv6 error messages (see Section 5.1) to
+   defend against DoS attacks generated by an abuse user.
+
+   More considerations about IP address sharing are discussed in
+   Section 13 of [RFC6269], which is applicable to this solution.
+
+   This document describes a number of different protocols that may be
+   used for the provisioning of lw4o6.  In each case, the security
+   considerations relevant to the provisioning protocol are also
+   relevant to the provisioning of lw4o6 using that protocol.  lw4o6
+   does not add any other security considerations specific to these
+   provisioning protocols.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+              and E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
+              <http://www.rfc-editor.org/info/rfc1918>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
+              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
+              December 1998, <http://www.rfc-editor.org/info/rfc2473>.
+
+   [RFC4787]  Audet, F., Ed., and C. Jennings, "Network Address
+              Translation (NAT) Behavioral Requirements for Unicast
+              UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787,
+              January 2007, <http://www.rfc-editor.org/info/rfc4787>.
+
+   [RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
+              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
+              RFC 5382, DOI 10.17487/RFC5382, October 2008,
+              <http://www.rfc-editor.org/info/rfc5382>.
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 16]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   [RFC5508]  Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
+              Behavioral Requirements for ICMP", BCP 148, RFC 5508,
+              DOI 10.17487/RFC5508, April 2009,
+              <http://www.rfc-editor.org/info/rfc5508>.
+
+   [RFC5597]  Denis-Courmont, R., "Network Address Translation (NAT)
+              Behavioral Requirements for the Datagram Congestion
+              Control Protocol", BCP 150, RFC 5597,
+              DOI 10.17487/RFC5597, September 2009,
+              <http://www.rfc-editor.org/info/rfc5597>.
+
+   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee,
+              "Dual-Stack Lite Broadband Deployments Following IPv4
+              Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
+              <http://www.rfc-editor.org/info/rfc6333>.
+
+   [RFC7598]  Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
+              W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
+              Configuration of Softwire Address and Port-Mapped
+              Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,
+              <http://www.rfc-editor.org/info/rfc7598>.
+
+10.2.  Informative References
+
+   [B4-Trans-DSLite]
+              Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and
+              I. Farrer, "Lightweight 4over6: An Extension to the
+              DS-Lite Architecture", Work in Progress,
+              draft-cui-softwire-b4-translated-ds-lite-11,
+              February 2013.
+
+   [DSLite-LW-Ext]
+              Deng, X., Boucadair, M., and C. Zhou, "NAT offload
+              extension to Dual-Stack lite", Work in Progress,
+              draft-zhou-softwire-b4-nat-04, October 2011.
+
+   [Dyn-Shared-v4Alloc]
+              Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and
+              M. Boucadair, "Dynamic Allocation of Shared IPv4
+              Addresses", Work in Progress,
+              draft-ietf-dhc-dynamic-shared-v4allocation-09, May 2015.
+
+   [PCP-PORT_SET]
+              Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T.,
+              and S. Perreault, "Port Control Protocol (PCP) Extension
+              for Port Set Allocation", Work in Progress,
+              draft-ietf-pcp-port-set-09, May 2015.
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 17]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
+              Defeating Denial of Service Attacks which employ IP Source
+              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
+              May 2000, <http://www.rfc-editor.org/info/rfc2827>.
+
+   [RFC2983]  Black, D., "Differentiated Services and Tunnels",
+              RFC 2983, DOI 10.17487/RFC2983, October 2000,
+              <http://www.rfc-editor.org/info/rfc2983>.
+
+   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
+              Address Translator (Traditional NAT)", RFC 3022,
+              DOI 10.17487/RFC3022, January 2001,
+              <http://www.rfc-editor.org/info/rfc3022>.
+
+   [RFC6269]  Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
+              P. Roberts, "Issues with IP Address Sharing", RFC 6269,
+              DOI 10.17487/RFC6269, June 2011,
+              <http://www.rfc-editor.org/info/rfc6269>.
+
+   [RFC6346]  Bush, R., Ed., "The Address plus Port (A+P) Approach to
+              the IPv4 Address Shortage", RFC 6346,
+              DOI 10.17487/RFC6346, August 2011,
+              <http://www.rfc-editor.org/info/rfc6346>.
+
+   [RFC6431]  Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and
+              T. Tsou, "Huawei Port Range Configuration Options for PPP
+              IP Control Protocol (IPCP)", RFC 6431,
+              DOI 10.17487/RFC6431, November 2011,
+              <http://www.rfc-editor.org/info/rfc6431>.
+
+   [RFC6864]  Touch, J., "Updated Specification of the IPv4 ID Field",
+              RFC 6864, DOI 10.17487/RFC6864, February 2013,
+              <http://www.rfc-editor.org/info/rfc6864>.
+
+   [RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
+              P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
+              DOI 10.17487/RFC6887, April 2013,
+              <http://www.rfc-editor.org/info/rfc6887>.
+
+   [RFC7040]  Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
+              IPv4-over-IPv6 Access Network", RFC 7040,
+              DOI 10.17487/RFC7040, November 2013,
+              <http://www.rfc-editor.org/info/rfc7040>.
+
+   [RFC7341]  Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
+              Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
+              RFC 7341, DOI 10.17487/RFC7341, August 2014,
+              <http://www.rfc-editor.org/info/rfc7341>.
+
+
+
+Cui, et al.                  Standards Track                   [Page 18]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   [RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
+              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
+              Port with Encapsulation (MAP-E)", RFC 7597,
+              DOI 10.17487/RFC7597, July 2015,
+              <http://www.rfc-editor.org/info/rfc7597>.
+
+   [Stateless-DS-Lite]
+              Penno, R., Durand, A., Clauberg, A., and L. Hoffmann,
+              "Stateless DS-Lite", Work in Progress,
+              draft-penno-softwire-sdnat-02, March 2012.
+
+   [TR069]    Broadband Forum TR-069, "CPE WAN Management Protocol",
+              Amendment 5, CWMP Version: 1.4, November 2013,
+              <https://www.broadband-forum.org>.
+
+   [Unified-v4-in-v6]
+              Boucadair, M., Farrer, I., Perreault, S., Ed., and S.
+              Sivakumar, Ed., "Unified IPv4-in-IPv6 Softwire CPE", Work
+              in Progress, draft-ietf-softwire-unified-cpe-01, May 2013.
+
+Acknowledgements
+
+   The authors would like to thank Ole Troan, Ralph Droms, and Suresh
+   Krishnan for their comments and feedback.
+
+   This document is a merge of three documents: [B4-Trans-DSLite],
+   [DSLite-LW-Ext], and [Stateless-DS-Lite].
+
+Contributors
+
+   The following individuals contributed to this effort:
+
+   Jianping Wu
+   Tsinghua University
+   Department of Computer Science, Tsinghua University
+   Beijing  100084
+   China
+   Phone: +86-10-62785983
+   Email: jianping@cernet.edu.cn
+
+   Peng Wu
+   Tsinghua University
+   Department of Computer Science, Tsinghua University
+   Beijing  100084
+   China
+   Phone: +86-10-62785822
+   Email: pengwu.thu@gmail.com
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 19]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   Qi Sun
+   Tsinghua University
+   Beijing  100084
+   China
+   Phone: +86-10-62785822
+   Email: sunqi@csnet1.cs.tsinghua.edu.cn
+
+   Chongfeng Xie
+   China Telecom
+   Room 708, No. 118, Xizhimennei Street
+   Beijing  100035
+   China
+   Phone: +86-10-58552116
+   Email: xiechf@ctbri.com.cn
+
+   Xiaohong Deng
+   The University of New South Wales
+   Sydney  NSW 2052
+   Australia
+   Email: dxhbupt@gmail.com
+
+   Cathy Zhou
+   Huawei Technologies
+   Section B, Huawei Industrial Base, Bantian Longgang
+   Shenzhen  518129
+   China
+   Email: cathyzhou@huawei.com
+
+   Alain Durand
+   Juniper Networks
+   1194 North Mathilda Avenue
+   Sunnyvale, CA  94089-1206
+   United States
+   Email: adurand@juniper.net
+
+   Reinaldo Penno
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA  95134
+   United States
+   Email: repenno@cisco.com
+
+
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 20]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   Axel Clauberg
+   Deutsche Telekom AG
+   CTO-ATI
+   Landgrabenweg 151
+   Bonn  53227
+   Germany
+   Email: axel.clauberg@telekom.de
+
+   Lionel Hoffmann
+   Bouygues Telecom
+   TECHNOPOLE
+   13/15 Avenue du Marechal Juin
+   Meudon  92360
+   France
+   Email: lhoffman@bouyguestelecom.fr
+
+   Maoke Chen (a.k.a. Noriyuki Arai)
+   BBIX, Inc.
+   Tokyo Shiodome Building, Higashi-Shimbashi 1-9-1
+   Minato-ku, Tokyo  105-7310
+   Japan
+   Email: maoke@bbix.net
+
+Authors' Addresses
+
+   Yong Cui
+   Tsinghua University
+   Beijing  100084
+   China
+
+   Phone: +86-10-62603059
+   Email: yong@csnet1.cs.tsinghua.edu.cn
+
+
+   Qiong Sun
+   China Telecom
+   Room 708, No. 118, Xizhimennei Street
+   Beijing  100035
+   China
+
+   Phone: +86-10-58552936
+   Email: sunqiong@ctbri.com.cn
+
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 21]
+
+RFC 7596                   Lightweight 4over6                  July 2015
+
+
+   Mohamed Boucadair
+   France Telecom
+   Rennes  35000
+   France
+
+   Email: mohamed.boucadair@orange.com
+
+
+   Tina Tsou
+   Huawei Technologies
+   2330 Central Expressway
+   Santa Clara, CA  95050
+   United States
+
+   Phone: +1-408-330-4424
+   Email: tena@huawei.com
+
+
+   Yiu L. Lee
+   Comcast
+   One Comcast Center
+   Philadelphia, PA  19103
+   United States
+
+   Email: yiu_lee@cable.comcast.com
+
+
+   Ian Farrer
+   Deutsche Telekom AG
+   CTO-ATI, Landgrabenweg 151
+   Bonn, NRW  53227
+   Germany
+
+   Email: ian.farrer@telekom.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cui, et al.                  Standards Track                   [Page 22]
+