[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                       R. Moskowitz
Internet-Draft                                            HTT Consulting
Intended status: Informational                                    GP. Li
Expires: August 3, 2019                                           S. Ren
                                                        January 30, 2019

                           FlexIP Addressing


   This memo proposes an unbounded Flexible Address Space (FAS),
   consisting of a publicly routable Global Address Part (GP) and a
   locally routable Local Address Part (LP).  It expands GP and LP to
   provide address privacy and special LP formats.  Use cases are also

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 https://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 August 3, 2019.

Copyright Notice

   Copyright (c) 2019 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
   (https://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

Moskowitz, et al.        Expires August 3, 2019                 [Page 1]

Internet-Draft              FlexIP Addressing               January 2019

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Related Work  . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
     2.2.  Notations . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Flexible Address System . . . . . . . . . . . . . . . . . . .   4
     3.1.  Infinite address space  . . . . . . . . . . . . . . . . .   4
     3.2.  Textual representation  . . . . . . . . . . . . . . . . .   5
     3.3.  Some Assignment Principles  . . . . . . . . . . . . . . .   6
   4.  Expanding into the Flexible Address System  . . . . . . . . .   6
     4.1.  Adding a MapID to the Local Part  . . . . . . . . . . . .   6
     4.2.  FlexIP Addressing Privacy Concerns  . . . . . . . . . . .   7
       4.2.1.  Address Privacy via a Cryptographic Mapping Function    7
     4.3.  Inbound FlexIP Address Considerations . . . . . . . . . .   8
     4.4.  Adding a MapID to the Global Part . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  FlexIP Addressing Local Part Use Cases . . . . . . .   9
     A.1.  Case 1: FlexIP METrie as Local Forwarding Part  . . . . .   9
     A.2.  Case 2: Layer 2 forwarding network  . . . . . . . . . . .  10
     A.3.  Case 3: IPv4/IPv6 forwarding network  . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   This memo defines a new IP address system, called the Flexible
   Address System (FAS).  Compared to the conventional fixed length IP
   system, FAS is designed with 2 infinite address spaces, Global and
   Local, that can support variable length IP addresses, called flexible
   addresses.  FAS has a global hierarchical structure of flexible
   addresses from the perspective of management.  This hierarchical
   structure may also be used in a local part of FAS.

   It proposes a number of different formats for the Local Part,
   including IPv4/6 addresses and IEEE 802 48 and 64 bit MAC addresses
   in addition to the unbounded FAS bit structure.

Moskowitz, et al.        Expires August 3, 2019                 [Page 2]

Internet-Draft              FlexIP Addressing               January 2019

   Further, it provides privacy of both the LP and customer bits of the
   GP through the use of a MapID (MID).  The MapID is explained for each
   use case.  It works differently when used for LP privacy than it does
   for GP privacy.

1.1.  Related Work

   PIP [RFC1621] provided for variable length addresses so that the size
   of the address could be adjusted to the demands of the particular
   environment, and to ensure the ability to meet any future networking
   requirements.  PIP also made a distinction of identifier from

   FlexIP has parallels in PIP, but takes advantages in advancements in
   Identities, routing, and provider networking.

2.  Terms and Definitions

2.1.  Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.2.  Notations

   ||   signifies concatenation of information - e.g., X || Y is the
      concatenation of X and Y.

   [x|y]  Either x or y.

2.3.  Definitions

   DI (Device Identifier):  The portion of the Local Part that
      Identifies the device interface.

   FAS (Flexible Address System):  The unbounded address space of

   GP (Global Part):  The globally routable portion of FAS.  It is
      textually represented to the left of a period in little endian

   GPF (Global Part Forwarding):  The global routing of a FAS addressed

Moskowitz, et al.        Expires August 3, 2019                 [Page 3]

Internet-Draft              FlexIP Addressing               January 2019

   LP (Local Part):  The locally routable portion of FAS.  It is
      textually represented to the right of a period in big endian

   LPF (Local Part Forwarding):  The local routing of a FAS addressed

   MID (MapID):  Index into the address mapping function used to provide
      address privacy.

   OV (Obfuscated Value):  The mapped value of the hidden address.

3.  Flexible Address System

   This section presents a new IP address system called Flexible Address
   System (FAS), in which the IP addresses can be with variable length,
   rather than the conventional fixed bits.

   FlexIP FAS addresses can simply be viewed as composed of two parts:
   Global (GP) and Local (LP).  The Global part is represented in little
   endian form (most significant adjacent to the period) and the Local
   Part is big endian.


3.1.  Infinite address space

   From the perspective of address space management, flexible IP
   addresses (Flex-IP) can simply be viewed as composed of two parts:
   Global (GP) and Local (LP) Parts, as is shown below.

                        ...00 1 | 01
                       ...00 10 | 100
                     ...00 1010 | 0001
                    ...00 10010 | 100001
                    ...00 10010 | 1000010
           Infinite Global Part | Infinite Local Part

          Figure 1: Flexible address space and structure

   Figure 1 shows the structure of flexible IP addresses, which are
   represented in binary.  A flexible IP address commonly consists of
   two parts, the global part and the local part.  The global prefix is
   a network prefix used for management and assignment.  Each specified

Moskowitz, et al.        Expires August 3, 2019                 [Page 4]

Internet-Draft              FlexIP Addressing               January 2019

   global prefix can be treated as a natural number.  Thus, the number
   of available global prefix equals to natural number domain.

   While the local part is used to identify interfaces or hosts in a
   certain subnet, along with any local routing prefix.  The size of the
   local part can be any bits, determined by the allocation strategies.
   While for a specified subnet with delegated global part, its local
   part should be with fixed bits and cannot be changed once assigned.
   For different subnets, the size of their local parts can be same or
   different.  The local part consists of several units, which further
   consists of one bit or several bits.  The length of the local part
   should be an integer multiple of the unit size.  The size of unit can
   be any length but should be defined uniformly.

   Theoretically, both the global part and local address part are
   infinite.  The FAS address space can be expanded on demand and will
   never be exhausted.  Ideally, if unit size is set to 1 bit, FAS
   address space can evolve completely smooth, bit-by-bit.  Even with a
   bigger unit, FAS address space is still infinite and there is no need
   to prescribe a fixed or maximum length of the address space.

3.2.  Textual representation

   The global part can also be split into several units.  If there is an
   aliquant part when splitting, add auxiliary zeros on the left side.
   Then, by representing each unit as a decimal number, a flexible IP
   address can be represented textually with the conventional dotted-
   decimal form.  For example, as depicted in Figure 2, with 4bits as
   unit size, a 10bits address 10 0100 0110 with the first two bits as
   global part can be transformed to a 12bits address 00 10 0100 0110 by
   adding two auxiliary bits of zeros on the left side.  Then it can be
   further expressed in a textual format as 2.4.6.  Moreover, this
   address can also be expressed as, or even, which
   may provide more convenience in some cases like the routing lookup in
   the following sections.

                              Binary            Dotted decimal

   Effective address           10 0100 01 10  -->     2.0.0
   Expressional address       0010 0100 0110  -->
                         0000 0010 0100 0110

          Figure 2: Textual representation for FAS

Moskowitz, et al.        Expires August 3, 2019                 [Page 5]

Internet-Draft              FlexIP Addressing               January 2019

   For easy understanding and description, the binary address 10 0100
   0110 is called an effective address with 10 bits effective length.
   While 00 10 0100 0110 and are called expression addresses
   with 12 bits expression length.  For special cases, the corresponding
   decimal dotted address 2.4.6 is called an effective address when
   described with 10bits effective length and called expression address
   when described with 12bits expression length.  This document will
   take 8 bits as the unit size to accommodate the custom of IPv4.

3.3.  Some Assignment Principles

   The FAS address should be centralized allocated by some organization
   liken IANA.  When allocating an address block to a company or an
   organization, the value of the global part should be specified.

   If the assigner is a Network Service Provider, they can further
   extend their global part to support their customers.  If they have
   multiple entries into their network and need to advertise different
   GP lengths, this will have an impact on the RIBs.

4.  Expanding into the Flexible Address System

   This simple view of a two-branched tree of addresses for FAS is a
   gross simplification as it hides complexities in both parts.  A
   simple view of the Global Part is that of an unbounded hierarchy to
   facilitate packet forwarding (GPF) between multiple public
   connectivity providers.  The Local Part minimally contains a local
   packet forwarding (LPF) hierarchy and a device 'interface' identifier
   (DI).  This is the simplest case for the Local Part.  The following
   expands to a deeper view of both parts.

4.1.  Adding a MapID to the Local Part

   A MapID (MID) provides an access mechanism to support a different
   presentation of the Local Part to the Global network.  The intention
   is to either provide privacy of the local part to the global network,
   or to provide address transformation of FlexIP global addresses to
   some local addressing structure.  A later section will describe using
   the MID in the Global Part.

   MID applies to inbound processing at the local network border router.
   It is the index to a table that defines the mapping function (e.g.
   lookup or math transform function) and any associated information
   (e.g. key value).  Within the local network, MID has no meaning
   (Appendix A.1 below).

   The MID has local significance and of no semantic value to the global
   FlexIP network nor to other local networks.  Thus its size cannot

Moskowitz, et al.        Expires August 3, 2019                 [Page 6]

Internet-Draft              FlexIP Addressing               January 2019

   easily be fixed.  Although there are use cases where its length could
   be zero (only a single mapping ever used), it is strongly recommended
   it always be present and its length be 8 bits.  It is the privacy
   mapping function that requires multiple values (see Section 4.2).

   Appendix A.3, below, presents an argument for global significance for
   MID for potentially one value (e.g.  MID=0).

4.2.  FlexIP Addressing Privacy Concerns

   A desired goal with FlexIP is to mask information about devices on
   the local network.  This includes and is not limited to the Device
   Identifier and Local Forwarding Part.  Not only is it desirable to
   stop a network observer from linking all traffic from a device by
   observing the DI portion of the address but also from learning about
   the local network design and what devices are, network-wise, close by
   sharing the same local forwarding information.

   There are two ways to obfuscate the LFP + DI address portion on the
   global network.  The most commonly used is a mapping approach where a
   gateway device stores the mapping of local to global addressing to
   produce an Obfuscated Value (OV).  The oldest, NAT, typically employs
   a many-to-one map (except for applications like PASV FTP).  Others
   include one-to-one mapping and encapsulation.  A second approach is a
   reversible function that transform the local to an obfuscated value.
   Packets are transformed bidirectionally as they cross the local

   To facilitate mappings choices in Local Part content a MapID (MID) is
   included as the first portion of the LP.

   Thus at this point we view the FlexIP address as:

          Locally - GP.LFP||DI
          Globally - GP.MID||OV

4.2.1.  Address Privacy via a Cryptographic Mapping Function

   Consider function F where:

          F(K, LFP||DI) = OV
          F'(K, OV) = LFP||DI

   To provide privacy, K should change over time or some function based
   on packet content inspection.  To accommodate multiple, concurrent
   values of K, multiple MIDs are needed.  The nature of F is unknown at

Moskowitz, et al.        Expires August 3, 2019                 [Page 7]

Internet-Draft              FlexIP Addressing               January 2019

   this point.  Since Len(LFP||DI) is small and even variable within a
   local network, many current cryptographic functions are not safe to
   use.  Research is needed to find a safe function for this purpose.
   The actual function used will influence the nature of K lifetime and
   thus how many may exist at a given time.  If MID reuse is allowed, 8
   bits should be sufficient.

4.3.  Inbound FlexIP Address Considerations

   Devices that do not have native FlexIP addressing support, will
   require a network mapping that presents FlexIP addresses in a format
   understood by the device.  This is a highly local consideration.  It
   should present a one-to-one mapping of global to local.

4.4.  Adding a MapID to the Global Part

   A MID can also be used in the Global Part.  For example a provider
   may provide a privacy service to a customer by frequently changing
   the OV.  In this case the address may be:


   There are a number of limitations in using this approach.  It may not
   be viable if the customer needs outward-facing servers that are
   discoverable via DNS.

5.  IANA Considerations

   FAS will need an IP version number assignment.  The FAS header may
   have TLVs to manage.

   IANA may responsible for some level of FAS GP allocation.

6.  Security Considerations

   Address privacy is a major component of FAS, thus a careful
   evaluation of all address mapping methods is required.  Were a
   gateway performs table mappings between internal and external
   addresses, attention is needed ensure the privacy of the mapping
   table.  Where mapping is achieved via a crypto function, there are a
   different set of privacy concerns.

   Further, lifetime of use of an address needs to be a factor.
   Mappings should change regularly to minimize the attack of tracking
   flows with the same OV.

Moskowitz, et al.        Expires August 3, 2019                 [Page 8]

Internet-Draft              FlexIP Addressing               January 2019

7.  Acknowledgments


8.  References

8.1.  Normative References

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

8.2.  Informative References

   [RFC1621]  Francis, P., "Pip Near-term Architecture", RFC 1621,
              DOI 10.17487/RFC1621, May 1994,

Appendix A.  FlexIP Addressing Local Part Use Cases

A.1.  Case 1: FlexIP METrie as Local Forwarding Part

   A local network may deploy the full capability of the FlexIP METrie
   in its own internal tree.  In this case there can be three levels in
   the addresses and two MapIDs:


   In this example, LFP2 may be as in case 3 below.

   It is possible to consider this as an infinite process of "layers of
   an onion", but it is best practice to only carry this to a global
   METrie and a single local METrie.  One valuable benefit of this case
   is the two levels of mappings which provides a level of privacy
   between portions of the local network.

   A simpler instance of local METrie use may be:


   Where GP and LFP are separated instances of the unbounded addressing
   and independent METrie trees.

Moskowitz, et al.        Expires August 3, 2019                 [Page 9]

Internet-Draft              FlexIP Addressing               January 2019

A.2.  Case 2: Layer 2 forwarding network

   There are two common layer 2 technologies for packet forwarding: IEEE
   802.1 and 802.15.10.  802.1 can be used on an 802.3/802.11 deployment
   and 802.15.10 on an 802.15.4 deployment.  In such a network, LFP may
   be null.  The DI would typically be the device MAC address and thus,
   a privacy mapping can be critical (don't expose the MAC address of a
   camera that has a known security flaw).  The DI could also be an IPv6
   Link Local address.  The FE80::/10 prefix need not be included in the

   Packets outbound from the local network will have some destination
   internal address that the border router maps to the global FlexIP

   Packets inbound to the local network need to source addresses mapped
   at the border router to the internal addressing format.  Without
   other knowledge, nothing is known about inbound packet source

A.3.  Case 3: IPv4/IPv6 forwarding network

   As IPv4 and IPv6 addressing naturally can be viewed as LFP||DI, they
   can directly replace those portions of a FlexIP address.  This allows
   for legacy networks to participate in FlexIP and for FlexIP to be
   used as the global infrastructure for an IPv4/v6 service provider.
   The address appears as:


   Border gateway address processing is similar to Case 2.  Global
   agreement on a MID value to represent this case (e.g.  MID=0) could
   facilitate FlexIP infrastructure to be the connectivity between
   legacy IPv4/v6 networks.

Authors' Addresses

   Robert Moskowitz
   HTT Consulting
   Oak Park, MI  48237

   Email: rgm@labs.htt-consult.com

Moskowitz, et al.        Expires August 3, 2019                [Page 10]

Internet-Draft              FlexIP Addressing               January 2019

   Guangpeng Li
   Beijing  100095

   Email: liguangpeng@huawei.com

   Shoushou Ren
   No. 156 of Beiqing Road, Haidian District
   Beijing  100095

   Email: renshoushou@huawei.com

Moskowitz, et al.        Expires August 3, 2019                [Page 11]

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