doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc6535.txt b/doc/rfc/rfc6535.txt
new file mode 100644
index 0000000..95d5641
--- /dev/null
+++ b/doc/rfc/rfc6535.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          B. Huang
+Request for Comments: 6535                                       H. Deng
+Obsoletes: 2767, 3338                                       China Mobile
+Category: Standards Track                                  T. Savolainen
+ISSN: 2070-1721                                                    Nokia
+                                                           February 2012
+
+
+            Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)
+
+Abstract
+
+   Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol
+   translation mechanism that allows a class of IPv4-only applications
+   that work through NATs to communicate with IPv6-only peers.  The host
+   on which applications are running may be connected to IPv6-only or
+   dual-stack access networks.  BIH hides IPv6 and makes the IPv4-only
+   applications think they are talking with IPv4 peers by local
+   synthesis of IPv4 addresses.  This document obsoletes RFC 2767 and
+   RFC 3338.
+
+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/rfc6535.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 1]
+
+RFC 6535                           BIH                     February 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 2]
+
+RFC 6535                           BIH                     February 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Terminology ................................................5
+      1.2. Acknowledgment of Previous Work ............................5
+   2. Components of the Bump-in-the-Host ..............................6
+      2.1. Function Mapper ............................................8
+      2.2. Protocol Translator ........................................8
+      2.3. Extension Name Resolver ....................................8
+           2.3.1. Special Exclusion Sets for A and AAAA Records .......9
+           2.3.2. DNSSEC Support .....................................10
+           2.3.3. Reverse DNS Lookup .................................10
+           2.3.4. DNS Caches and Synthetic IPv4 Addresses ............10
+      2.4. Address Mapper ............................................11
+   3. Behavior and Network Examples ..................................11
+   4. Considerations .................................................15
+      4.1. Socket API Conversion .....................................15
+      4.2. Socket Bindings ...........................................15
+      4.3. ICMP Message Handling .....................................15
+      4.4. IPv4 Address Pool and Mapping Table .......................15
+      4.5. Multi-Interface ...........................................17
+      4.6. Multicast .................................................17
+   5. Application-Level Gateway Requirements Considerations ..........17
+   6. Security Considerations ........................................17
+      6.1. Implications on End-to-End Security .......................18
+      6.2. Filtering .................................................18
+      6.3. Attacks on BIH ............................................18
+      6.4. DNS Considerations ........................................19
+   7. Changes since RFC 2767 and RFC 3338 ............................19
+   8. Acknowledgments ................................................20
+   9. References .....................................................21
+      9.1. Normative References ......................................21
+      9.2. Informative References ....................................21
+   Appendix A. API List Intercepted by BIH ...........................23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 3]
+
+RFC 6535                           BIH                     February 2012
+
+
+1.  Introduction
+
+   This document describes Bump-in-the-Host (BIH), a successor and
+   combination of the Bump-in-the-Stack (BIS)[RFC2767] and Bump-in-the-
+   API (BIA) [RFC3338] technologies, which enable IPv4-only legacy
+   applications to communicate with IPv6-only servers by synthesizing
+   IPv4 addresses from AAAA records.  Section 7 describes the reasons
+   for making RFC 2767 and RFC 3338 obsolete.
+
+   The supported class of applications includes those that use DNS for
+   IP address resolution and that do not embed IP address literals in
+   application-protocol payloads.  This includes legacy client-server
+   applications using the DNS that are agnostic to the IP address family
+   used by the destination and that are able to do NAT traversal.  The
+   synthetic IPv4 addresses shown to applications are taken from the
+   private address pool of [RFC1918] in order to ensure that possible
+   NAT traversal techniques will be initiated.
+
+   The IETF recommends using solutions based on dual stack or tunneling
+   for IPv6 transition and specifically recommends against deployments
+   utilizing double protocol translation.  Use of BIH together with a
+   NAT64 is NOT RECOMMENDED [RFC6180].
+
+   BIH includes two major implementation alternatives: a protocol
+   translator between the IPv4 and the IPv6 stacks of a host or an API
+   translator between the IPv4 socket API module and the TCP/IP module.
+   Essentially, IPv4 is translated into IPv6 at the socket API layer or
+   at the IP layer, the former of which is the recommended
+   implementation alternative.
+
+   When BIH is implemented at the socket API layer, the translator
+   intercepts IPv4 socket API function calls and invokes corresponding
+   IPv6 socket API function calls to communicate with IPv6 hosts.
+
+   When BIH is implemented at the network layer, the IPv4 packets are
+   intercepted and converted to IPv6 using the IP conversion mechanism
+   defined in the Stateless IP/ICMP Translation Algorithm (SIIT)
+   [RFC6145].  The protocol translation has the same benefits and
+   drawbacks as SIIT.
+
+   The location of the BIH refers to the location of the protocol
+   translation function.  The location of the IPv4 address and DNS A
+   record synthesis function is orthogonal to the location of the
+   protocol translation and may or may not happen at the same location.
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 4]
+
+RFC 6535                           BIH                     February 2012
+
+
+   BIH can be used whenever an IPv4-only application needs to
+   communicate with an IPv6-only server, independently of the address
+   families supported by the access network.  Hence, the access network
+   can be IPv6-only or dual-stack capable.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+   This document uses terms defined in [RFC2460] and [RFC4213].
+
+1.1.  Terminology
+
+   DNS synthesis
+
+      The process of creating an A record containing a synthetic IPv4
+      address.
+
+   Real IPv4 address
+
+      An IPv4 address of a remote node a host has learned, for example,
+      from DNS response to an A query.
+
+   Real IPv6 address
+
+      An IPv6 address of a remote node a host has learned, for example,
+      from DNS response to a AAAA query.
+
+   Synthetic IPv4 address
+
+      An IPv4 address that has meaning only inside a host and that is
+      used to provide IPv4 representation of remote node's real IPv6
+      address.
+
+1.2.  Acknowledgment of Previous Work
+
+   This document is a direct derivative of [RFC2767], "Dual Stack Hosts
+   using the "Bump-In-the-Stack" Technique (BIS)" by Kazuaki TSHUCHIYA,
+   Hidemitsu HIGUCHI, and Yoshifumi ATARASHI and of [RFC3338], "Dual
+   Stack Hosts Using "Bump-in-the-API" (BIA)" by Seungyun Lee, Myung-Ki
+   Shin, Yong-Jin Kim, Alain Durand, and Erik Nordmark, which similarly
+   provides IPv4-only applications on dual-stack hosts the means to
+   operate over IPv6.  Section 7 covers the changes since those
+   documents.
+
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 5]
+
+RFC 6535                           BIH                     February 2012
+
+
+2.  Components of the Bump-in-the-Host
+
+   Figure 1 shows the architecture of a host in which BIH is implemented
+   as a socket API-layer translator, i.e., as a "Bump-in-the-API".
+
+                  +----------------------------------------------+
+                  | +------------------------------------------+ |
+                  | |                                          | |
+                  | |            IPv4 applications             | |
+                  | |                                          | |
+                  | +------------------------------------------+ |
+                  | +------------------------------------------+ |
+                  | |           Socket API (IPv4, IPv6)        | |
+                  | +------------------------------------------+ |
+                  | +-[ API translator]------------------------+ |
+                  | | +-----------+ +---------+ +------------+ | |
+                  | | | Ext. Name | | Address | | Function   | | |
+                  | | | Resolver  | | Mapper  | | Mapper     | | |
+                  | | +-----------+ +---------+ +------------+ | |
+                  | +------------------------------------------+ |
+                  | +--------------------+ +-------------------+ |
+                  | |                    | |                   | |
+                  | |    TCP(UDP)/IPv4   | |   TCP(UDP)/IPv6   | |
+                  | |                    | |                   | |
+                  | +--------------------+ +-------------------+ |
+                  +----------------------------------------------+
+
+        Figure 1: Architecture of a dual-stack host using protocol
+                      translation at the socket layer
+
+   Figure 2 shows the architecture of a host in which BIH is implemented
+   as a network-layer translator, i.e., a "Bump-in-the-Stack".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 6]
+
+RFC 6535                           BIH                     February 2012
+
+
+      +------------------------------------------------------------+
+      |  +------------------------------------------+              |
+      |  |    IPv4 applications                     |              |
+      |  |    Host's main DNS resolver              |              |
+      |  +------------------------------------------+              |
+      |  +------------------------------------------+              |
+      |  |    TCP/UDP                               |              |
+      |  +------------------------------------------+              |
+      |  +------------------------------------------+ +---------+  |
+      |  |    IPv4                                  | |         |  |
+      |  +------------------------------------------+ | Address |  |
+      |  +------------------+ +---------------------+ | Mapper  |  |
+      |  |    Protocol      | |   Extension Name    | |         |  |
+      |  |    Translator    | |   Resolver          | |         |  |
+      |  +------------------+ +---------------------+ |         |  |
+      |  +------------------------------------------+ |         |  |
+      |  |    IPv4 / IPv6                           | |         |  |
+      |  +------------------------------------------+ +---------+  |
+      +------------------------------------------------------------+
+
+        Figure 2: Architecture of a dual-stack host using protocol
+                     translation at the network layer
+
+   Dual-stack hosts, defined in [RFC4213], need applications, TCP/IP
+   modules, and addresses for both IPv4 and IPv6.  The proposed hosts in
+   this document have an API or network-layer translator to allow legacy
+   IPv4 applications to communicate with IPv6-only peers.  The BIH
+   architecture consists of an Extension Name Resolver, an address
+   mapper, and depending on implementation either a function mapper or a
+   protocol translator.  It is worth noting that the Extension Name
+   Resolver's placement is orthogonal to the placement of protocol
+   translation.  For example, the Extension Name Resolver may reside in
+   the socket API while protocol translation takes place at the network
+   layer.
+
+   The choice between the socket API- and network-layer architectures
+   varies case by case.  While the socket API architecture alternative
+   is the recommended one, it may not always be possible to choose.
+   This may be the case, for example, when the used operating system
+   does not allow modifications to be done for API implementations, but
+   does allow the addition of virtual network interfaces and related
+   software modules.  On the other hand, sometimes it may not be
+   possible to introduce protocol translators inside the operating
+   system, but it may be easy to modify implementations behind the API
+   provided for applications.  The choice of architecture also depends
+   on who is creating implementation of BIH.  For example, an
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 7]
+
+RFC 6535                           BIH                     February 2012
+
+
+   application framework provider, an operating system provider, and a
+   device vendor may all choose different approaches due their different
+   positions.
+
+2.1.  Function Mapper
+
+   The function mapper translates an IPv4 socket API function into an
+   IPv6 socket API function.
+
+   When detecting IPv4 socket API function calls from IPv4 applications,
+   the function mapper MUST intercept the function calls and invoke IPv6
+   socket API functions that correspond to the IPv4 socket API
+   functions.
+
+   The function mapper MUST NOT perform function mapping when the
+   application is initiating communications to the address range used by
+   local synthesis and the address mapping table does not have an entry
+   matching the address.
+
+   See Appendix A for an informational list of functions that would be
+   appropriate to intercept by the function mapper.
+
+2.2.  Protocol Translator
+
+   The protocol translator translates IPv4 into IPv6, and vice versa,
+   using the IP conversion mechanism defined in SIIT [RFC6145].  To
+   avoid unnecessary fragmentation, the host's IPv4 module SHOULD be
+   configured with a small enough MTU (MTU of the IPv6 enabled link - 20
+   bytes).
+
+   Protocol translation cannot be performed for IPv4 packets sent to the
+   IPv4 address range used by local synthesis and for which a mapping
+   table entry does not exist.  The implementation SHOULD attempt to
+   route such packets via IPv4 interfaces instead.
+
+2.3.  Extension Name Resolver
+
+   The Extension Name Resolver (ENR) returns an answer in response to
+   the IPv4 application's name resolution request.
+
+   In the case of the socket API-layer implementation alternative, when
+   an IPv4 application tries to do a forward lookup to resolve names via
+   the resolver library (e.g., gethostbyname()), BIH intercepts the
+   function call and instead calls the IPv6 equivalent functions (e.g.,
+   getaddrinfo()) that will resolve both A and AAAA records.  This
+   implementation alternative is name resolution protocol agnostic;
+   hence, it supports techniques such as "hosts-file", NetBIOS, mDNS,
+   and anything else the underlying operating system uses.
+
+
+
+Huang, et al.                Standards Track                    [Page 8]
+
+RFC 6535                           BIH                     February 2012
+
+
+   In the case of the network-layer implementation alternative, the ENR
+   intercepts the A query and creates an additional AAAA query with
+   similar content.  The ENR will then collect replies to both A and
+   AAAA queries and, depending on results, either return an A reply
+   unmodified or synthesize a new A reply.  If no reply for the A query
+   is received after ENR-implementation-specific timeout, after
+   reception of positive AAAA response, the ENR MAY choose to proceed as
+   if there were only a AAAA record available for the destination.
+
+   The network-layer implementation alternative will only be able to
+   catch applications' name resolution requests that result in actual
+   DNS queries; hence, it is more limited when compared to the socket
+   API-layer implementation alternative.  Hence, the socket API-layer
+   alternative is RECOMMENDED.
+
+   In either implementation alternative, if a DNS A record reply
+   contains non-excluded real IPv4 addresses, the ENR MUST NOT
+   synthesize IPv4 addresses.
+
+   The ENR asks the address mapper to assign a synthetic IPv4 address
+   corresponding to each received IPv6 address if the A record query
+   resulted in a negative response, all received real IPv4 addresses
+   were excluded, or the A query timed out.  The timeout value is
+   implementation specific and may be short in order to provide a good
+   user experience.
+
+   In the case of the API-layer implementation alternative, the ENR will
+   simply make the API (e.g., gethostbyname) return the synthetic IPv4
+   address.  In the case of the network-layer implementation
+   alternative, the ENR synthesizes an A record for the assigned
+   synthetic IPv4 address and delivers it up the stack.  If the response
+   contains a CNAME or a DNAME record, then the CNAME or DNAME chain is
+   followed until the first terminating A or AAAA record is reached.
+
+   Application    | Network               | ENR behavior
+     query        | response              |
+   ---------------+-----------------------+----------------------------
+ IPv4 address(es) | IPv4 address(es)      | return real IPv4 address(es)
+ IPv4 address(es) | IPv6 address(es)      | synthesize IPv4 address(es)
+ IPv4 address(es) | IPv4/IPv6 address(es) | return real IPv4 address(es)
+
+                    Figure 3: ENR Behavior Illustration
+
+2.3.1.  Special Exclusion Sets for A and AAAA Records
+
+   An ENR implementation SHOULD, by default, exclude certain real IPv4
+   and IPv6 addresses seen on received A and AAAA records.  The
+   addresses to be excluded by default MAY include addresses such as
+
+
+
+Huang, et al.                Standards Track                    [Page 9]
+
+RFC 6535                           BIH                     February 2012
+
+
+   those that should not appear in the DNS or on the wire (see Section
+   5.1.4 of [RFC6147] and [RFC5735]).  Additional addresses MAY be
+   excluded based on possibly configurable local policies.
+
+2.3.2.  DNSSEC Support
+
+   When the ENR is implemented at the network layer, the A record
+   synthesis can cause similar issues as are described in [RFC6147]
+   section 3.  While running BIH, the main resolver of the host SHOULD
+   NOT perform validation of A records, as synthetic A records created
+   by ENR would fail in validation.  While not running BIH, a host's
+   resolver can use DNS Security (DNSSEC) in the same way that any other
+   resolver can.  The ENR MAY support DNSSEC, in which case the (stub)
+   resolver on a host can be configured to trust validations done by the
+   ENR located at the network layer.  In some cases, the host's
+   validating stub resolver can implement the ENR by itself.
+
+   When the ENR is implemented at the socket API level, there are no
+   issues with DNSSEC use, as the ENR itself uses socket APIs for DNS
+   resolution.  This approach is RECOMMENDED.
+
+2.3.3.  Reverse DNS Lookup
+
+   When an application requests a reverse lookup (PTR query) for an IPv4
+   address, the ENR MUST check whether the queried IPv4 address can be
+   found in the address mapper's mapping table and if it is a synthetic
+   IPv4 address.  If an entry is found and the queried IPv4 address is
+   synthetic, the ENR MUST initiate a corresponding reverse lookup for
+   the real IPv6 address.  In the case where the application requested a
+   reverse lookup for an address not part of the synthetic IPv4 address
+   pool, e.g., a global address, the request MUST be passed on
+   unmodified.
+
+   For example, when an application requests a reverse lookup for a
+   synthetic IPv4 address, the ENR needs to intercept that query.  The
+   ENR asks the address mapper for the real IPv6 address that
+   corresponds to the synthetic IPv4 address.  The ENR shall perform a
+   reverse lookup procedure for the destination's IPv6 address and
+   return the name received as a response to the application that
+   initiated the IPv4 query.
+
+2.3.4.  DNS Caches and Synthetic IPv4 Addresses
+
+   When BIH shuts down or address mapping table entries are cleared for
+   any reason, DNS cache entries for synthetic IPv4 addresses MUST be
+   flushed.  There may be a DNS cache in the network-layer ENR itself
+   and at the host's stub resolver.
+
+
+
+
+Huang, et al.                Standards Track                   [Page 10]
+
+RFC 6535                           BIH                     February 2012
+
+
+2.4.  Address Mapper
+
+   The address mapper maintains an IPv4 address pool that can be used
+   for IPv4 address synthesis.  The pool consists of the IPv4 addresses
+   of [RFC1918] as per Section 4.4.  Also, the address mapper maintains
+   a table consisting of pairs of synthetic IPv4 addresses and
+   destinations' real IPv6 addresses.
+
+   When the ENR, translator, or the function mapper requests the address
+   mapper to assign a synthetic IPv4 address corresponding to an IPv6
+   address, the address mapper selects and returns an IPv4 address out
+   of the local pool and registers a new entry into the table.  The
+   registration occurs in the following three cases:
+
+   1.  When the ENR gets only IPv6 addresses for the target host name
+       and there is no existing mapping entry for the IPv6 addresses.
+       One or more synthetic IPv4 addresses will be returned to the
+       application and mappings for synthetic IPv4 addresses to real
+       IPv6 addresses are created.
+
+   2.  When the ENR gets both real IPv4 and IPv6 addresses, but the real
+       IPv4 addresses contain only excluded IPv4 addresses
+       (e.g., 127.0.0.1).  The behavior will follow case (1).
+
+   3.  When the function mapper is triggered by a received IPv6 packet
+       and there is no existing mapping entry for the IPv6 source
+       address (for example, the client sent a UDP request to an anycast
+       address, but a response was received from a unicast address).
+
+   Other possible combinations are outside of BIH.
+
+3.  Behavior and Network Examples
+
+   Figure 4 illustrates a very basic network scenario.  An IPv4-only
+   application is running on a host attached to the IPv6-only Internet
+   and is talking to an IPv6-only server.  Communication is made
+   possible by Bump-in-the-Host.
+
+     +----+                                   +-------------+
+     | H1 |----------- IPv6 Internet -------- | IPv6 server |
+     +----+                                   +-------------+
+     v4 only
+     application
+
+                       Figure 4: Network Scenario #1
+
+
+
+
+
+
+Huang, et al.                Standards Track                   [Page 11]
+
+RFC 6535                           BIH                     February 2012
+
+
+   Figure 5 illustrates a possible network scenario where an IPv4-only
+   application is running on a host attached to a dual-stack network,
+   but the destination server is running on a private site that is
+   numbered with public IPv6 addresses and not globally reachable IPv4
+   addresses, such as the addresses of [RFC1918], without port
+   forwarding set up on the NAT44.  The only means to contact the server
+   is to use IPv6.
+
+     +----------------------+  +------------------------------+
+     | Dual-Stack Internet  |  | IPv4 Private site (Net 10)   |
+     |                      |  | IPv6 routed site             |
+     |                   +---------+             +----------+ |
+     |                 +-|  NAT44  |-------------+          | |
+     |  +----+         | +---------+             |          | |
+     |  | H1 |---------+    |  |                 |  Server  | |
+     |  +----+         | +-----------+           |          | |
+     | v4-only         +-|IPv6 Router|-----------+          | |
+     | application       +-----------+           +----------+ |
+     |                      |  |                  Dual Stack  |
+     |                      |  |                    10.1.1.1  |
+     |                      |  |                 2001:DB8::1  |
+     +----------------------+  +------------------------------+
+
+                       Figure 5: Network Scenario #2
+
+   Illustrations of host behavior in both implementation alternatives
+   are given here.  Figure 6 illustrates a setup where BIH (including
+   the ENR) is implemented at the socket API layer, and Figure 7
+   illustrates a setup where BIH (including the ENR) is implemented at
+   the network layer.
+
+"dual stack"                                                "host6"
+IPv4    Socket |     [ API Translator ]    | TCP(UDP)/IP          Name
+appli-  API    | ENR      Address  Function| (v6/v4)             Server
+cation         |          Mapper   Mapper  |
+ |        |        |        |        |         |              |       |
+<<Resolve IPv4 addresses for "host6".>>        |              |       |
+ |        |        |        |        |         |              |       |
+ |------->|------->|  Query IPv4 addresses for host6.         |       |
+ |        |        |        |        |         |              |       |
+ |        |        |------------------------------------------------->|
+ |        |        |  Query 'A' and 'AAAA' records for host6          |
+ |        |        |        |        |         |              |       |
+ |        |        |<-------------------------------------------------|
+ |        |        |  Reply with the 'AAAA' record.           |       |
+ |        |        |        |        |         |              |
+ |        |        |<<The 'AAAA' record is resolved.>>        |
+ |        |        |        |        |         |              |
+
+
+
+Huang, et al.                Standards Track                   [Page 12]
+
+RFC 6535                           BIH                     February 2012
+
+
+ |        |        |+++++++>|  Request synthetic IPv4 address |
+ |        |        |        |  corresponding to the IPv6 address.
+ |        |        |        |        |         |              |
+ |        |        |        |<<Assign one synthetic IPv4 address.>>
+ |        |        |        |        |         |              |
+ |        |        |<+++++++|  Reply with the synthetic IPv4 address.
+ |        |        |        |        |         |              |
+ |<-------|<-------| Reply with the IPv4 address              |
+ |        |        |        |        |         |              |
+ |        |        |        |        |         |              |
+<<Call IPv4 Socket API function >>   |         |              |
+ |        |        |        |        |         |              |
+ |=======>|=========================>|An IPv4 Socket API action
+ |        |        |        |        |         |              |
+ |        |        |        |<+++++++|  Request IPv6 addresses|
+ |        |        |        |        |  corresponding to the  |
+ |        |        |        |        |  synthetic IPv4 addresses.
+ |        |        |        |        |         |              |
+ |        |        |        |+++++++>| Reply with the IPv6 addresses.
+ |        |        |        |        |         |              |
+ |        |        |        |        |<<Translate IPv4 into IPv6.>>
+ |        |        |        |        |         |              |
+ |  An IPv6 Socket API action        |=======================>|
+ |        |        |        |        |         |              |
+ |        |        |        |        |<<IPv6 data received    |
+ |        |        |        |        |  from network.>>       |
+ |        |        |        |        |         |              |
+ |  An IPv6 Socket API action        |<=======================|
+ |        |        |        |        |         |              |
+ |        |        |        |        |<<Translate IPv6 into IPv4.>>
+ |        |        |        |        |         |              |
+ |        |        |        |<+++++++|  Request synthetic IPv4 addresses
+ |        |        |        |        |  corresponding to the  |
+ |        |        |        |        |  IPv6 addresses.       |
+ |        |        |        |        |         |              |
+ |        |        |        |+++++++>| Reply with the IPv4 addresses.
+ |        |        |        |        |         |              |
+ |<=======|<=========================|  An IPv4 Socket API action
+ |        |        |        |        |         |              |
+
+                 Figure 6: Example of BIH as API Addition
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                   [Page 13]
+
+RFC 6535                           BIH                     February 2012
+
+
+     "dual stack"                                         "host6"
+  IPv4 stub  TCP/    ENR     address  translator  IPv6
+  app  res.  IPv4            mapper
+    |   |    |       |         |       |           |         |
+  <<Resolve an IPv4 address for "host6".>>         |         |
+    |-->|    |       |         |       |           |         |
+    |   |----------->|  Query 'A' records for "host6".       |  Name
+    |   |    |       |         |       |           |         |  Server
+    |   |    |       |------------------------------------------->|
+    |   |    |       |  Query 'A' and 'AAAA'  records for "host6"
+    |   |    |       |         |       |           |         |    |
+    |   |    |       |<-------------------------------------------|
+    |   |    |       |  Reply only with 'AAAA' record.       |
+    |   |    |       |         |       |           |         |
+    |   |    |       |<<Only 'AAAA' record is resolved.>>    |
+    |   |    |       |         |       |           |         |
+    |   |    |       |-------->|  Request synthetic IPv4 address
+    |   |    |       |         |  corresponding to each IPv6 address.
+    |   |    |       |         |       |           |         |
+    |   |    |       |         |<<Assign synthetic IPv4 addresses.>>
+    |   |    |       |         |       |           |         |
+    |   |    |       |<--------|  Reply with the synthetic IPv4 address.
+    |   |    |       |         |       |           |         |
+    |   |    |       |<<Create 'A' record for the IPv4 address.>>
+    |   |    |       |         |       |           |         |
+    |   |<-----------|  Reply with the 'A' record. |         |
+    |   |    |       |         |       |           |         |
+    |<--|<<Reply with the IPv4 address |           |         |
+    |   |    |       |         |       |           |         |
+    <<Send an IPv4 packet to "host6".>>|           |         |
+    |   |    |       |         |       |           |         |
+    |=======>|========================>|  An IPv4 packet.    |
+    |   |    |       |         |       |           |         |
+    |   |    |       |         |<++++++|  Request IPv6 addresses
+    |   |    |       |         |       |  corresponding to the
+    |   |    |       |         |       |  synthetic IPv4 addresses.
+    |   |    |       |         |       |           |         |
+    |   |    |       |         |++++++>|  Reply with the IPv6|
+    |   |    |       |         |       |  addresses.         |
+    |   |    |       |         |       |           |         |
+    |   |    |       |         |       |<<Translate IPv4 into IPv6.>>
+    |   |    |       |         |       |           |         |
+    |   |    |       |An IPv6 packet.  |==========>|========>|
+    |   |    |       |         |       |           |         |
+    |   |    |       |         |   <<Reply with an IPv6 packet.>>
+    |   |    |       |         |       |           |         |
+    |   |    |       |An IPv6 packet.  |<==========|<========|
+    |   |    |       |         |       |           |         |
+
+
+
+Huang, et al.                Standards Track                   [Page 14]
+
+RFC 6535                           BIH                     February 2012
+
+
+    |   |    |       |         |       |<<Translate IPv6 into IPv4.>>
+    |   |    |       |         |       |           |         |
+    |   |    |       |         |<++++++|  Request synthetic IPv4
+    |   |    |       |         |       |  addresses corresponding
+    |   |    |       |         |       |  to the IPv6 addresses.
+    |   |    |       |         |       |           |         |
+    |   |    |       |         |++++++>|  Reply with the IPv4 addresses.
+    |   |    |       |         |       |           |         |
+    |<=======|=========================|  An IPv4 packet.    |
+    |   |    |       |         |       |           |         |
+
+               Figure 7: Example of BIH at the Network Layer
+
+4.  Considerations
+
+4.1.  Socket API Conversion
+
+   IPv4 socket API functions are translated into IPv6 socket API
+   functions that are semantically as identical as possible, and vice
+   versa.  See Appendix A for the API list intercepted by BIH.  However,
+   some IPv4 socket API functions are not fully compatible with IPv6
+   since IPv4 supports features that are not present in IPv6, such as
+   SO_BROADCAST.
+
+4.2.  Socket Bindings
+
+   BIH SHOULD select a source address for a socket from the recommended
+   source address pool if a socket used for communications has not been
+   explicitly bound to any IPv4 address.
+
+   The binding of an explicitly bound socket MUST NOT be changed by the
+   BIH.
+
+4.3.  ICMP Message Handling
+
+   ICMPv4 and ICMPv6 messages MUST be translated as defined by SIIT
+   [RFC6145].  In the network-layer implementation alternative, the
+   protocol translator MUST translate ICMPv6 packets to ICMPv4 and vice
+   versa, and in the socket API implementation alternative, the socket
+   API MUST handle conversions in similar fashion.
+
+4.4.  IPv4 Address Pool and Mapping Table
+
+   The address pool consists of the private IPv4 addresses of [RFC1918].
+   This pool can be implemented at different granularities in the node,
+   e.g., a single pool per node, or at some finer granularity such as
+   per-user or per-process.  In the case of a large number of IPv4
+   applications communicating with a large number of IPv6 servers, the
+
+
+
+Huang, et al.                Standards Track                   [Page 15]
+
+RFC 6535                           BIH                     February 2012
+
+
+   available address space may be exhausted if the granularity is not
+   fine enough.  This should be a rare event and chances will decrease
+   as IPv6 support increases.  The applications may use IPv4 addresses
+   they learn for a much longer period than DNS time to live indicates.
+   Therefore, the mapping table entries should be kept active for a long
+   period of time.  For example, a web browser may initiate one DNS
+   query and then create multiple TCP sessions over time to the address
+   it learns.  When address mapping table clean-up is required, the BIH
+   may utilize techniques used by network address translators, such as
+   described in [RFC2663], [RFC5382], and [RFC5508].
+
+   The address space of RFC 1918 was chosen because legacy applications
+   generally understand it as a private address space.  A new dedicated
+   address space would run the risk of not being understood by
+   applications as private. 127/8 and 169.254/16 are rejected due to
+   possible assumptions applications may make when seeing them.
+
+   The addresses of RFC 1918 used by the BIH have a risk of conflicting
+   with addresses used in the host's possible IPv4 interfaces and
+   corresponding local networks.  The conflicts can be mitigated, but
+   not fully avoided, by using less commonly used portions of the
+   address space of RFC 1918.  Addresses from 172.16/12 are thought to
+   be less likely to be in conflict than addresses from 10/8 or
+   192.168/16 spaces.  A source address can usually be selected in a
+   non-conflicting manner, but a small possibility exists for
+   synthesized destination addresses being in conflict with real
+   addresses used in attached IPv4 networks.
+
+   The RECOMMENDED IPv4 addresses are following:
+
+      Primary source addresses: 172.21.112.0/20.
+
+         Source addresses have to be allocated because applications use
+         getsockname() calls and, in the network-layer mode, an IP
+         address of the IPv4 interface has to be shown (e.g., by
+         'ifconfig').  More than one address is allocated to allow
+         implementation flexibility, e.g., for cases where a host has
+         multiple IPv6 interfaces.  The source addresses are from
+         different subnets than destination addresses to ensure
+         applications would not make on-link assumptions and would
+         instead enable NAT traversal functions.
+
+      Secondary source addresses: 10.170.224.0/20.
+
+         These addresses are recommended if a host has a conflict with
+         primary source addresses.
+
+
+
+
+
+Huang, et al.                Standards Track                   [Page 16]
+
+RFC 6535                           BIH                     February 2012
+
+
+      Primary destination addresses: 10.170.160.0/20.
+
+         The address mapper will select destination addresses primarily
+         out of this pool.
+
+      Secondary destination addresses: 172.21.80.0/20.
+
+         The address mapper will select destination addresses out of
+         this pool if the node has a dual-stack connection conflicting
+         with primary destination addresses.
+
+4.5.  Multi-Interface
+
+   In the case of dual-stack destinations, BIH MUST NOT do protocol
+   translation from IPv4 to IPv6 when the host has any IPv4 interfaces,
+   native or tunneled, available for use.
+
+   It is possible that an IPv4 interface is activated during BIH
+   operation, for example, if a node moves to a coverage area of an
+   IPv4-enabled network.  In such an event, BIH MUST stop initiating
+   protocol translation sessions for new connections, and BIH MAY
+   disconnect active sessions.  The choice of disconnection is left for
+   implementations, and it may depend on whether IPv4 address conflict
+   occurs between addresses used by BIH and addresses used by the new
+   IPv4 interface.
+
+4.6.  Multicast
+
+   Protocol translation for multicast is not supported.
+
+5.  Application-Level Gateway Requirements Considerations
+
+   No Application-Level Gateway (ALG) functionality is specified herein
+   as ALG design is generally not encouraged for host-based translation
+   and as BIH is intended for applications that do not include IP
+   addresses in protocol payloads.
+
+6.  Security Considerations
+
+   The security considerations of BIH follows closely, but not
+   completely, those of NAT64 [RFC6146] and DNS64 [RFC6147].  The
+   following sections are copied from RFC 6146 and RFC 6147 and modified
+   for BIH.
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                   [Page 17]
+
+RFC 6535                           BIH                     February 2012
+
+
+6.1.  Implications on End-to-End Security
+
+   Any protocols that protect IP header information are essentially
+   incompatible with BIH.  This implies that end-to-end IPsec
+   verification will fail when the Authentication Header (AH) is used
+   (both transport and tunnel mode) and when ESP is used in transport
+   mode.  This is inherent in any network-layer translation mechanism.
+   End-to-end IPsec protection can be restored, using UDP encapsulation
+   as described in [RFC3948].  The actual extensions to support IPsec
+   are out of the scope of this document.
+
+6.2.  Filtering
+
+   BIH creates binding state using packets flowing from the IPv4 side to
+   the IPv6 side.  In accordance with the procedures defined in this
+   document, following the guidelines defined in [RFC4787], a BIH
+   implementation MUST offer "Endpoint-Independent Mapping".
+
+   Implementations MAY also provide support for "Address-Dependent
+   Mapping" following the guidelines defined in [RFC4787].
+
+   The security properties, however, are determined by which packets the
+   BIH allows in and which it does not.  The security properties are
+   determined by the filtering behavior and by the possible filtering
+   configuration in the filtering portions of the BIH, not by the
+   address mapping behavior.
+
+6.3.  Attacks on BIH
+
+   The BIH implementation itself is a potential victim of different
+   types of attacks.  In particular, the BIH can be a victim of Denial-
+   of-Service (DoS) attacks.  The BIH implementation has a limited
+   number of resources that can be consumed by attackers creating a DoS
+   attack.  The BIH has a limited number of IPv4 addresses that it uses
+   to create the bindings.  Even though the BIH performs address
+   translation, it is possible for an attacker to consume the synthetic
+   IPv4 address pool by triggering a host to issue DNS queries for names
+   that cause ENR to synthesize A records.  DoS attacks can also affect
+   other limited resources available in the host running BIH such as
+   memory or link capacity.  For instance, it is possible for an
+   attacker to launch a DoS attack on the memory of the BIH running
+   device by sending fragments that the BIH will store for a given
+   period.  If the number of fragments is large enough, the memory of
+   the host could be exhausted.  BIH implementations MUST implement
+   proper protection against such attacks, for instance, allocating a
+   limited amount of memory for fragmented packet storage.
+
+
+
+
+
+Huang, et al.                Standards Track                   [Page 18]
+
+RFC 6535                           BIH                     February 2012
+
+
+   Another consideration related to BIH resource depletion is the
+   preservation of binding state.  Attackers may try to keep a binding
+   state alive forever by sending periodic packets that refresh the
+   state.  In order to allow the BIH to defend against such attacks, the
+   BIH implementation MAY choose not to extend the session entry
+   lifetime for a specific entry upon the reception of packets for that
+   entry through the external interface.  However, such an action would
+   not allow one-way communication sessions to stay alive.
+
+6.4.  DNS Considerations
+
+   BIH operates in combination with the DNS, and it is therefore subject
+   to whatever security considerations are appropriate to the DNS mode
+   in which the BIH is operating (i.e., recursive or stub-resolver
+   mode).
+
+   BIH has the potential to interfere with the functioning of DNSSEC,
+   because BIH modifies DNS answers, and DNSSEC is designed to detect
+   such modifications and to treat modified answers as bogus.
+
+7.  Changes since RFC 2767 and RFC 3338
+
+   This document combines and obsoletes both [RFC2767] and [RFC3338].
+
+   The changes in this document mainly reflect the following:
+
+   1. Addresses of RFC 1918 used for synthesis
+
+      RFC 3338 used unassigned IPv4 addresses (e.g., 0.0.0.1 -
+      0.0.0.255) for synthetic IPv4 addresses.  Those addresses should
+      not have been used and that may cause problems with applications.
+      It is preferable to use addresses defined in RFC 1918 instead, as
+      described in Section 4.4.
+
+   2. Support for reverse (PTR) DNS queries
+
+      Neither RFC 2767 nor RFC 3338 included support for reverse (PTR)
+      DNS queries.  This document adds the support in Section 2.3.3.
+
+   3. DNSSEC support
+
+      RFC 2767 did not include DNSSEC considerations, which are now
+      included in Section 2.3.2
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                   [Page 19]
+
+RFC 6535                           BIH                     February 2012
+
+
+   4. Architectural recommendation
+
+      This document recommends the socket API-layer implementation
+      option over network layer translation, i.e., it recommends the
+      approach introduced in RFC 2767 over the approach of RFC 3338.
+
+   5. Standards-Track document
+
+      RFC 2767 is classified as an Informational RFC and RFC 3338 as an
+      Experimental RFC.  It was discussed and decided in the IETF that
+      this technology should be on the Standards Track.
+
+   6. Set of other extensions and improvements
+
+      A set of lesser extensions, improvements, and clarifications have
+      been introduced.  These include but are not limited to IPv4 and
+      IPv6 address exclusion sets at Section 2.3.1, host's DNS cache
+      considerations, ENR behavior updates, updated security
+      considerations, example updates, and deployment scenario updates.
+
+8.  Acknowledgments
+
+   The authors are grateful for discussion from Gang Chen, Dapeng Liu,
+   Bo Zhou, Hong Liu, Tao Sun, Zhen Cao, and Feng Cao et al. in the
+   development of this document.
+
+   The efforts of Mohamed Boucadair, Dean Cheng, Lorenzo Colitti, Paco
+   Cortes, Ralph Droms, Stephen Farrell, Fernando Gont, Marnix Goossens,
+   Wassim Haddad, Ala Hamarsheh, Dave Harrington, Ed Jankiewizh, Suresh
+   Krishnan, Julien Laganier, Yiu L. Lee, Jan M. Melen, Qibo Niu,
+   Pierrick Seite, Christian Vogt, Magnus Westerlund, Dan Wing, and
+   James Woodyatt in reviewing this document are gratefully
+   acknowledged.
+
+   Special acknowledgments go to Dave Thaler for his extensive review
+   and support.
+
+   The authors of RFC 2767 acknowledged WIDE Project, Kazuhiko YAMAMOTO,
+   Jun MURAI, Munechika SUMIKAWA, Ken WATANABE, and Takahisa MIYAMOTO.
+   The authors of RFC 3338 acknowledged implementation contributions by
+   Wanjik Lee (wjlee@arang.miryang.ac.kr) and i2soft Corporation
+   (www.i2soft.net).
+
+   The authors of "Bump-in-the-Wire IPv4/IPv6 Translator" (a draft
+   document submitted to the v6ops WG in October 2006), P. Moster, L.
+   Chin, and D. Green, are acknowledged.  Some ideas and clarifications
+   from BIW have been adapted to this document.
+
+
+
+
+Huang, et al.                Standards Track                   [Page 20]
+
+RFC 6535                           BIH                     February 2012
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+              E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", RFC 4213, October 2005.
+
+   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
+              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+              RFC 4787, January 2007.
+
+   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+              Algorithm", RFC 6145, April 2011.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, April 2011.
+
+   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
+              Beijnum, "DNS64: DNS Extensions for Network Address
+              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
+              April 2011.
+
+9.2.  Informative References
+
+   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
+              Translator (NAT) Terminology and Considerations",
+              RFC 2663, August 1999.
+
+   [RFC2767]  Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack
+              Hosts using the "Bump-In-the-Stack" Technique (BIS)",
+              RFC 2767, February 2000.
+
+   [RFC3338]  Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A.
+              Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)",
+              RFC 3338, October 2002.
+
+
+
+
+
+Huang, et al.                Standards Track                   [Page 21]
+
+RFC 6535                           BIH                     February 2012
+
+
+   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
+              Stevens, "Basic Socket Interface Extensions for IPv6",
+              RFC 3493, February 2003.
+
+   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
+              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
+              RFC 3948, January 2005.
+
+   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
+              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
+              RFC 5382, October 2008.
+
+   [RFC5508]  Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
+              Behavioral Requirements for ICMP", BCP 148, RFC 5508,
+              April 2009.
+
+   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+              BCP 153, RFC 5735, January 2010.
+
+   [RFC6180]  Arkko, J. and F. Baker, "Guidelines for Using IPv6
+              Transition Mechanisms during IPv6 Deployment", RFC 6180,
+              May 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                   [Page 22]
+
+RFC 6535                           BIH                     February 2012
+
+
+Appendix A.  API List Intercepted by BIH
+
+   The following informational list includes some of the API functions
+   that would be appropriate to intercept by BIH module when implemented
+   at the socket API layer.  Please note that this list is not fully
+   exhaustive, as the function names and services that are available on
+   different APIs vary significantly.
+
+   The functions that the application uses to pass addresses into the
+   system are as follows:
+
+      bind()
+
+      connect()
+
+      sendmsg()
+
+      sendto()
+
+      gethostbyaddr()
+
+      getnameinfo()
+
+   The functions that return an address from the system to an
+   application are as follows:
+
+      accept()
+
+      recvfrom()
+
+      recvmsg()
+
+      getpeername()
+
+      getsockname()
+
+      gethostbyname()
+
+      getaddrinfo()
+
+   The functions that are related to socket options are as follows:
+
+      getsocketopt()
+
+      setsocketopt()
+
+   As well, raw sockets for IPv4 and IPv6 may be intercepted.
+
+
+
+
+Huang, et al.                Standards Track                   [Page 23]
+
+RFC 6535                           BIH                     February 2012
+
+
+   Most of the socket functions require a pointer to the socket address
+   structure as an argument.  Each IPv4 argument is mapped into
+   corresponding an IPv6 argument, and vice versa.
+
+   According to [RFC3493], the following new IPv6 basic APIs and
+   structures are required.
+
+         IPv4                     new IPv6
+         ------------------------------------------------
+         AF_INET                  AF_INET6
+         sockaddr_in              sockaddr_in6
+         gethostbyname()          getaddrinfo()
+         gethostbyaddr()          getnameinfo()
+         inet_ntoa()/inet_addr()  inet_pton()/inet_ntop()
+         INADDR_ANY               in6addr_any
+
+                                 Figure 8
+
+   BIH may intercept inet_ntoa() and inet_addr() and use the address
+   mapper for those.  Doing that enables BIH to support literal IP
+   addresses.  However, IPv4 address literals can only be used after a
+   mapping entry between the IPv4 address and corresponding IPv6 address
+   has been created.
+
+   The gethostbyname() and getaddrinfo() calls return a list of
+   addresses.  When the name resolver function invokes getaddrinfo(),
+   and getaddrinfo() returns multiple IP addresses, whether IPv4 or
+   IPv6, they should all be represented in the addresses returned by
+   gethostbyname().  Thus, if getaddrinfo() returns multiple IPv6
+   addresses, this implies that multiple address mappings will be
+   created: one for each IPv6 address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                   [Page 24]
+
+RFC 6535                           BIH                     February 2012
+
+
+Authors' Addresses
+
+   Bill Huang
+   China Mobile
+   No.32 Xuanwumen West Street
+   Xicheng District
+   Beijing  100053
+   China
+
+   EMail: bill.huang@chinamobile.com
+
+
+   Hui Deng
+   China Mobile
+   No.32 Xuanwumen West Street
+   Xicheng District
+   Beijing  100053
+   China
+
+   EMail: denghui@chinamobile.com
+
+
+   Teemu Savolainen
+   Nokia
+   Hermiankatu 12 D
+   FI-33720 TAMPERE
+   Finland
+
+   EMail: teemu.savolainen@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                   [Page 25]
+