| Network Working Group | R. Moskowitz |
| Internet-Draft | HTT Consulting |
| Intended status: Informational | GP. Li |
| Expires: August 3, 2019 | S. Ren |
| Huawei | |
| January 30, 2019 |
FlexIP Addressing
draft-moskowitz-flexip-addressing-00
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 provided.
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 (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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
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.
PIP 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 addresses.
FlexIP has parallels in PIP, but takes advantages in advancements in Identities, routing, and provider networking.
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.
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.
GP.LP
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 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.
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 0.2.4.6, or even 0.0.2.4.6, 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 --> 0.2.0.0
0000 0010 0100 0110 0.0.2.0.0
Figure 2: Textual representation for FAS
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 0.2.4.6 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.
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.
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.
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 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).
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 gateway.
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
Consider function F where:
F(K, LFP||DI) = OV
and
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 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.
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.
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:
GFP||MID||OV.LP
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.
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.
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.
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC1621] | Francis, P., "Pip Near-term Architecture", RFC 1621, DOI 10.17487/RFC1621, May 1994. |
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:
GP.MID1||LFP1||MID2||LFP2||DI
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:
GP.MID||LFP||DI
Where GP and LFP are separated instances of the unbounded addressing and independent METrie trees.
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 mapping.
Packets outbound from the local network will have some destination internal address that the border router maps to the global FlexIP address.
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 addresses.
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:
GP.MID||[IPv4|IPv6]
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.