[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

Network Working Group                                             J. Bi
Internet Draft                                                  Y. Wang
Intended status: Experimental                                    K. Gao
Expires: November, 2016                             Tsinghua University
                                                            May 1, 2016


  Implementation Experience of Identifier-Locator Network Protocol for
                             IPv6 (ILNPv6)

              draft-bi-rrg-ilnpv6-implementation-experience-06

Abstract

   The Identifier-Locator Network Protocol (ILNP) defines an
   evolutionary enhancement to IP to address multi-homing, mobility as
   well as other issues. This document provides experience of
   implementing ILNPv6 which is a specific engineering instance of ILNP
   based on IPv6. This document describes the problems arisen and our
   choices to solve the issues which may be helpful to others in
   implementing the protocol.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 2, 2016.

Copyright Notice

   Copyright (c) 2013 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



Bi, et al.             Expires November 2, 2016               [Page 1]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


   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 ................................................. 2
      1.1. Terminology ............................................. 3
   2. An Alternative Way to Implement ILNPv6 ....................... 3
      2.1. Transport-layer Session State Modification .............. 3
         2.1.1. Locator Erasion/Refilling .......................... 3
         2.1.2. Packet Sending ..................................... 4
         2.1.3. Packet Receiving.................................... 5
      2.2. Identical Identifiers Management ........................ 5
   3. Handling Special Cases........................................ 6
      3.1. Multiple Identifiers..................................... 6
         3.1.1. A Global ILCC Table................................. 6
         3.1.2. Independent ILCC Tables ............................ 7
      3.2. Missing Nonce Values .................................... 8
         3.2.1. Avoid Both Identical Identifiers and Nonces......... 9
   4. Other Considerations......................................... 10
      4.1. Path Selection Subsystem ............................... 10
      4.2. SBR Extension .......................................... 10
   5. Security Considerations...................................... 12
   6. IANA Considerations ......................................... 12
   7. Acknowledgments ............................................. 12
   8. References .................................................. 13
      8.1. Normative References.................................... 13
      8.2. Informative References.................................. 13

1. Introduction

   The Identifier-Locator Network Protocol (ILNP) [RFC6740] is an
   evolutionary protocol which addresses a wide range of issues
   including site/host multi-homing, site/host mobility, end-to-end
   security, etc. ILNP adopts an "Identifier/Locator Split" way to
   decouple end-to-end transport-layer session state from interfaces and
   addresses of a node.

   ILNPv6 is a specific engineering instance of ILNP that is based on
   IPv6. [RFC6741], [RFC6743] and [RFC6744] describe engineering
   considerations about ILNPv6 implementation which needs modifications
   to the protocol stack of hosts. This document describes issues that
   arise in implementing ILNPv6 according to existing specifications


Bi, et al.             Expires November 2, 2016               [Page 2]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


   together with possible solutions. This document only provides an
   alternative way to develop ILNPv6 based on Linux, and the goal is to
   offer experiences which may help the readers to make their own
   implementations of the protocol.

1.1. Terminology

   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 RFC-2119 [RFC2119].

   Some terms used in this document are defined in [RFC6740]. This
   document assumes that the reader has read the related RFC:
   Identifier-Locator Network Protocol (ILNP) Architectural Description
   [RFC6740].

2. An Alternative Way to Implement ILNPv6

   This section discusses the implementation challenges and alternative
   ways to overcome these challenges. The implementation described in
   this section is based on modifying GNU/Linux kernel 3.2.12.

2.1. Transport-layer Session State Modification

   One of the biggest challenges in implementing ILNPv6 is how to
   maintain transport-layer session state. As is specified in [RFC6740],
   transport layer on an ILNP node uses only the Identifier value (64
   bits suffix of IPv6 address) for the transport-layer session state,
   while current TCP and UDP use the entire IPv6 address as the session
   state.

2.1.1. Locator Erasion/Refilling

   There exist different ways to realize the modification, and the
   choice proposed in this document is to hide locator values (64 bits
   prefix of IPv6 address) from the transport layer by adopting locator
   erasion/refilling. The benefit of this method is that the transport
   layer will stay untouched while modifications are almost only
   required in the network layer.

   Locator erasion requires the network layer to erase the locator part
   of received ILNP packets (zero the 64 bits prefix) before sending
   them to the transport layer. The transport layer still regards the
   packets with zero prefixes as ordinary IPv6 packets and processes
   them normally. Since the IPv6 address within ILNP packet headers in
   transport layer contains only Identifier information, Locator changes



Bi, et al.             Expires November 2, 2016               [Page 3]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


   in the network layer will never affect the session states of
   transport layer protocols.

   Locator refilling requires the network layer to refill the locator
   part of outgoing ILNP packets from the transport layer. The locator
   information is obtained from ILCC introduced in [RFC6740]. After the
   refilling process, ILNP packets will be forwarded normally as
   ordinary IPv6 packets.

   In order to make the implementation compatible with existing Linux
   IPv6 socket API, Locator erasion/refilling also requires the socket
   layer to erase the locator part of ILNP packets before sending them
   to the transport layer and refill the locator part of ILNP packets
   received from the transport layer.

   The procedures of Locator erasion/refilling in both packet sending
   and receiving are shown in Figure 2.1 and described separately in the
   next two sub-sections.

        |                   |
        +-------------------+         Locator + Identifier
        |                   |             /\       |
        |   Socket layer    |     Locator  |       | Locator
        +-------------------+     Refilling|      \/ Erasion
        |  Transport layer  |           Zero + Identifier
        +-------------------+             /\       |
        |                   |      Locator |       | Locator
        |   Network layer   |      Erasion |      \/ Refilling
        |                   |         Locator + Identifier
        +-------------------+             /\       |
        |                   |              |      \/

   Figure 2.1: Locator Erasion/refilling Procedure in protocol stack

2.1.2. Packet Sending

   The socket API stays unchanged in this implementation, but the IP
   addresses maintained in socket are processed by Locator erasion
   function and are equivalent to Identifiers. Thus data packets
   delivered to the transport layer do not contain Locator information.
   Then packets get through the unmodified transport layer and reach the
   network layer.

   To handle ILNP packets from the transport layer, modifications are
   made in the network layer. For each ILNP packet, the network layer


Bi, et al.             Expires November 2, 2016               [Page 4]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


   looks up in the ILCC to get available Locator set and fills the 64
   bits prefix of the IPv6 address in the packet header. Locator
   refilling is achieved using Netfilter Hook in this implementation.
   Specifically, the Locator part is refilled in NF_IP_LOCAL_OUT. After
   the refilling, ILNP packets will be forwarded as normal IPv6 packets.

2.1.3. Packet Receiving

   For each incoming ILNP packet, the network layer needs to judge
   whether it should be delivered to upper layer protocols for further
   processing. According to the implementation of Linux IPv6 protocol
   stack, this is achieved by adding related entries in the routing
   table. Thus all possible IL-Vectors MUST be added into the table and
   set as local entries to ensure that all ILNP packets can be correctly
   received.

   For each packet whose destination is a local socket, the network
   layer sets the 64 bits prefix of the IPv6 address in the header to
   zero and transmit it to the transport layer. Locator erasion is also
   achieved using Netfilter Hook NF_IP_LOCAL_IN. The packet will be
   handled normally by the transport layer and then go to the
   corresponding socket and finally reach the destined application.

2.2. Identical Identifiers Management

   If an ILNP node simultaneously has two or more correspondents nodes
   with identical Identifiers, additional information is required in the
   transport layer to lookup sockets. [RFC6740] suggests using Locator
   values to distinguish between correspondent nodes that have identical
   Identifier value when delivering ILNP packets to applications.

   In current Linux IP/TCP implementation, the sockets are hashed
   globally with IP addresses and ports of both the local and remote
   nodes. Thus, if we simply use the combination of both Identifiers and
   Locators to lookup sockets, a large space may be required as all
   possible local-remote Locator pairs must be taken into consideration.
   Besides, since the lookup is performed in the transport layer,
   Locator values are no longer transparent which violates the intention
   of hiding Locator information from transport layer in this
   implementation.

   This document provides an alternative way for socket lookup in the
   transport layer. Since using Identifier value alone is not able to
   uniquely identify correspondent of an ILNP node, a local number
   called Peer Index (PI) for an ILNP peer is introduced. Different from
   Identifier, the local uniqueness of PI can be ensured. Thus the
   transport layer is able to use the tuple


Bi, et al.             Expires November 2, 2016               [Page 5]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


   <PI_local, PI_remote, Port_local, Port_remote>

   to uniquely identify a local socket. There are different ways to
   generate PI and one simplest method is to use a counter which
   increases along with the number of ILNP correspondents.

   The bindings between PIs and other information of the correspondent
   node (including its Identifier, Locator set, nonce, etc.) is stored
   in a hash table in the network layer. There are two ways to get the
   PI value of a correspondent node: use its Identifier-Locator pair and
   Identifier-Nonce pair to lookup in the hash table. Thus the
   disadvantage of this method is that we may have to make three lookups
   instead of one.

3. Handling Special Cases

   This section discusses some special cases in implementing ILNPv6. The
   ways to handle these cases are not described in the existing ILNP
   specifications and in this document we propose possible methods to
   deal with them. We believe that the issues discussed in this section
   need to be solved not only in Linux-based ILNP implementation, but
   also in other ways to implement the protocol.

3.1. Multiple Identifiers

   As specified in [RFC6740], one ILNP node may have multiple Identifier
   values that are associated with it and used concurrently. One
   scenario is that multiple virtual nodes are located on one physical
   device.

   This specification has impact on the implementation of the ILCC on an
   ILNP node. [RFC6741] suggests that ILCC should contain both
   information (Identifier values, Locator values, IL-Vectors and Nonce
   values) of the local node and correspondent nodes but does not
   specify the ways to organize the information. We discuss the
   following two methods separately.

3.1.1. A Global ILCC Table

   A straight forward method is to maintain a global ILCC table on each
   ILNP node. This method may work well if each ILNP node uses only one
   Identifier value at the same time. However, having multiple
   Identifiers but one ILCC table may lead to inconsistency and
   conflicts.

   Considering the scenario shown in Figure 3.1, an ILNP host H uses
   both Identifier IH1 and IH2 to communicate with correspondent node C


Bi, et al.             Expires November 2, 2016               [Page 6]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


   simultaneously. Since each Identifier represents a logical end point
   in the network, there is no way node C can be aware that the two
   identifiers resides in one node. Thus node C is likely to have
   different Nonce values for each Identifier for security reasons, and
   there is a high chance that C appears as two different nodes in node
   H's ILCC.

   [RFC6741] suggest using <Locator_remote, Identifier_remote> tuple as
   the lookup key in ILCC lookups, but in this situation, the 'two
   nodes' in H's ILCC will share exactly the same locator set. Thus H is
   not able to distinguish the correct correspondent node for packets
   without NONCE as they share the same <LC, IC> tuple.

         +--------------+        ......
         | Host H       |       .      .
         | +----------+ |      .        .
         | |ID IH1    | |     .          .    +-----------------+
         | |Locator LH|-|-----.          .    | Correspondent C |
         | +----------+ |     .          .    |                 |
         |              |     . Internet .----+ ID IC           |
         | +----------+ |     .          .    | Locator LC      |
         | |ID IH2    |-|-----.          .    |                 |
         | |Locator LH| |      .        .     +-----------------+
         | +----------| |       .      .
         +--------------+        ......

         Figure 3.1: Having Multiple Identifiers on One ILNP Node

3.1.2. Independent ILCC Tables

   Since one ILNP node could be equipped with several Identifiers, it is
   natural to set up an ILCC table for each one of them. Independent
   ILCC tables avoid the potential conflicts by using local information
   (Identifier_local and Locator_local) in ILNP packets when performing
   ILCC lookups. Another reason to choose Independent ILCC tables is
   that a global ILCC would cost as much memory as independent ones when
   processing the same number of possible Locator Update messages.

   One possible implementation of independent ILCC tables is shown in
   Figure 3.2. First we introduce Association as a data structure that
   stores information of an ILNP-based network-layer session (PI,
   Identifiers, Locators and Nonces of both local and remote nodes). We
   call each independent ILCC table a Cache which stores the
   Associations of all remote nodes that correspondent to a local
   Identifier. Finally all Caches constitute the local ILCC table.


Bi, et al.             Expires November 2, 2016               [Page 7]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


   When looking up in the ILCC, the local Identifier is firstly used as
   the key to find a corresponding Cache. Then both Identifier_remote-
   Locator_remote pair and Identifier_remote-Nonce_remote pair can be
   used as key to find an Association.

     top layer:        ILCC
                        |
                        |  <Identifier_local>
                        \/
     1st layer:       Cache
                        |  <Identifier_remote, Locator_remote> or
                        |  <Identifier_remote, Nonce_remote>
                        \/
     2nd layer:     Association

           Figure 3.2: Implementation of Independent ILCC Tables

3.2. Missing Nonce Values

   In the initial phase of a session between two ILNP nodes, it is
   possible that one side does not know the Nonce value generated by the
   other side for the session (for example, when no packet is sent from
   the other side).

   This case has impact on the ILCC lookup rules. [RFC6741] specifies
   that when looking up into the ILCC, <Identifier_remote, Nonce_remote>
   tuple MUST be used as the lookup key if Nonce Option in contained in
   the packet. Otherwise, <Identifier_remote, Locator_remote> tuple MUST
   be used as the lookup key. However, for the packet from a remote node
   whose Nonce value is unknown to the local node, the lookup rule MUST
   be changed to:

   1. Drop any received packet without Nonce Option, since [RFC6744]
   specifies that initial packet(s) to correspondent ILNP nodes MUST
   include Nonce Option.

   2. For received packet with a Nonce Option, store the Nonce value in
   local ILCC and deliver the packet normally.

   After the Nonce value is acquired from the remote node, follow-up
   packets from the remote node MUST be processed using the normal
   lookup rule.






Bi, et al.             Expires November 2, 2016               [Page 8]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


3.2.1. Avoid Both Identical Identifiers and Nonces

   A special case in handling missing Nonce values is shown in Figure
   3.3 where Host H is communicating with two correspondent nodes C1 and
   C2 with identical Identifiers. In this case, H has an on-going
   session with C1 while is initiating another session with C2 and has
   not yet get Nonce from it.

                             ......
                            .      .      +------------------+
                           .        .     | Correspondent C1 |
                          .          .----| ID IC            |
          +--------+      .          .    | Locator LC1      |
          |        |      .          .    +------------------+
          | Host H |------. Internet .
          |        |      .          .    +------------------+
          +--------+      .          .    | Correspondent C2 |
                           .        .-----| ID IC            |
                            .      .      | Locator LC2      |
                             ......       +------------------+

     Figure 3.3: A Special Case in Dealing with Missing Nonce Values

   If the Nonce value generated by C2 happens to be the same to the
   Nonce of C1 which is stored in H's ILCC, C1 and C2 will share both
   the same Identifier and Nonce. This situation MUST be avoided because
   it makes C1 and C2 undistinguishable when their Locators change.

   One way to handle the special case is to send an ICMP error message
   to C2 if it generates the same Nonce as C1. After receiving the ICMP
   error message, C2 should re-generate another Nonce value.
   Consequently, the lookup rule in this case is changed to:

   1. Drop any received packet without Nonce Option.

   2. For received packet with a Nonce Option, lookup into the ILCC
   using <Identifier_remote, Nonce_remote> as the key. If no entry is
   found, store the Nonce value in local ILCC and deliver the packet
   normally. Otherwise send an ICMP error message to the remote node
   indicated by <Identifier_remote, Locator_remote>.

   Considering the scenario in Figure 3.3, there is another method to
   prevent C2 from generating the same Nonce value as C1: when
   initiating a session with C2, H informs C2 of the Nonce generated by
   C1, thus C2 can avoid generating the same value. However,


Bi, et al.             Expires November 2, 2016               [Page 9]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


   modifications to session establishment process is required using this
   method.

4. Other Considerations

4.1. Path Selection Module

   We suggest introducing a path selection module into ILNP for better
   performance, especially for a multi-homing node. This module
   maintains the best Locator pairs of the local node and its
   correspondent node based on user-defined policy or other criteria
   such as longest matching prefixes. These maintained Locator pairs can
   be used to accelerate the process of selecting Locators when
   transmitting ILNP packets.

   This module MUST respond to basic ICMP messages that have an impact
   on the status of Locators, like Locator Update or Router
   Advertisement. Also, it COULD gather information from
   incoming/outgoing packets to enable features like load balancing.

4.2. SBR Extension

   According to the specifications in [RFC4830], ILNP is a global
   mobility protocol as it needs to change end-to-end route by sending
   Locator Update messages from the Mobile Node (MN) directly to all its
   Correspondent Nodes (CN) after network-layer handover. Thus, ILNP
   cannot avoid the drawbacks of such protocols: the first is heavy
   signaling overhead especially on the wireless links, since the number
   of Locator Update packets sent per handover is proportional to the
   number of CN; the second is potential large handover latency which
   grows with the increasing of MN-to-CN distance and may lead to high
   packet loss; the third is location privacy since IP address(es) of
   the MN are always exposed to its correspondents.

   Location privacy issue is addressed in [RFC6748], thus we suggest
   another extension to address the performance issues, i.e. the
   overhead and latency due to propagation and processing of Locator
   Update messages. We note that [RFC6748] has already utilized ILNP-
   capable Site Border Router (SBR) to realize localized numbering, here
   we further use SBR to localize Locator Update.

   Considering the scenario in Figure 4.1, a site network with SBR and
   Locator value L_1 is divided into two sub networks, e.g. sub network
   1 with local Locator value L_La and sub network 2 with local Locator
   value L_Lb. When an MN moves from sub network 1 to sub network 2,
   according to the specifications in [RFC6748], the MN needs to change
   both its Global Locator L_1 and local Locator L_L. Therefore, even if


Bi, et al.             Expires November 2, 2016              [Page 10]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


   the MN is roaming within a site network using localized numbering,
   the CN needs to be aware of Locator changes of the MN.

   We propose an alternative way to handle intra-site network mobility
   by keeping Global Locator of the MN unchanged when it moves among
   different sub networks within the same site network. In scenario
   shown in Figure 4.1, CN always learns the IL-Vector of MN as [I_H,
   L_1]. When packets destined to the MN arrive at the SBR, it rewrites
   the Locator part of each packet to a local Locator value (L_La or
   L_Lb in this example). During this process, SBR functions similarly
   to the Locator Rewriting Relay (LRR) proposed in [RFC6748], but LRR
   is introduced only for Location privacy issues.

     sub network 1
         .....
        .     .
       .       .L_La                        ........
       .  MN   .----                       .        .     +----+
       .       .    \                     .          .----| CN |
        .     .      \    +---------+     . Internet .    +----+
         .....        ----|         | L_1 .          .
                          +         +-----.          .
         .....        ----|         |     .          .
        .     .      /    +---------+     .          .
       .       .L_Lb/         SBR         .          .
       .  MN'  .----                       .        .
       .       .                            ........
        .     .
         .....
     sub network 2

          CN = Correspondent Node
          MN = Mobile Node
         MN' = Mobile Node after movement
         L_1 = global Locator value
        L_La = local Locator value a
        L_Lb = local Locator value b
         SBR = Site Border Router

     Figure 4.1: Utilize ILNP-capable SBR to localize Locator Update

   To decide which local Locator should be used, SBR needs to maintain a
   mapping table locally which stores mappings from Identifier and
   global Locator values of the MN to its current local Locator value.


Bi, et al.             Expires November 2, 2016              [Page 11]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


   An example of the mapping table for SBR in Figure 4.1 has the
   following form:

    src=[I_H, L_La], L_1                                       ---1(a)
    dst=[I_H, L_1],  L_La                                      ---1(b)

   Expression 1(a) says that for packets with src IL-V [I_H, L_La], its
   source Locator should be rewritten to L_1. Similarly, expression 1(b)
   says for packets with dst IL-V [I_H, L_1], its destination Locator
   should be rewritten to L_La. After the MN moves to another sub
   network within the same site network and changes its local Locator
   value, the MN is responsible to inform the SBR of its new local
   Locator value using Locator Update message. Therefore, instead of
   sending a Locator Update message to each CN, the MN only needs to
   send one Locator Update message to the SBR in this scenario, which
   reduces propagation and processing cost of Locator Update messages.

5. Security Considerations

   TBD.

6. IANA Considerations

   There is no IANA Consideration currently.

7. Acknowledgments

   Thanks to Cisco University Research Program for sponsoring the work.
   Thanks to Tony Li for guidance and suggestions on the implementation.



















Bi, et al.             Expires November 2, 2016              [Page 12]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


8. References

8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network
   Protocol (ILNP) Architectural Description", RFC 6740, November 2012.

   [RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network
   Protocol (ILNP) Engineering and Implementation Considerations", RFC
   6741, November 2012.

   [RFC6743] Atkinson, R. and S. Bhatti, "ICMP Locator Update Message
   for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC
   6743, November 2012.

   [RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination Option
   for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC
   6744, November 2012.

   [RFC6748] Atkinson, R. and S. Bhatti, "Optional Advanced Deployment
   Scenarios for the Identifier-Locator Network Protocol (ILNP)", RFC
   6748, November 2012.

   [RFC4830] Kempf, J., "Problem Statement for Network-Based Localized
   Mobility Management (NETLMM)", RFC 4830, April 2007.

8.2. Informative References


















Bi, et al.             Expires November 2, 2016              [Page 13]


Internet-Draft     ILNPv6 Implementation Experience           May 2016


Authors' Addresses

   Jun Bi
   Tsinghua University
   Network Research Center, Tsinghua University
   Beijing  100084
   China
   EMail: junbi@cernet.edu.cn

   You Wang
   Tsinghua University
   Network Research Center, Tsinghua University
   Beijing  100084
   China
   EMail: wangyou10@mails.tsinghua.edu.cn

   Kai Gao
   Tsinghua University
   Network Research Center, Tsinghua University
   Beijing  100084
   China
   EMail: gaok12@mails.tsinghua.edu.cn


























Bi, et al.             Expires November 2, 2016              [Page 14]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/