IPv6 Operations I. Lubashev
Internet-Draft E. Nygren
Intended status: Informational Akamai Technologies
Expires: April 30, 2018 October 27, 2017
A Recommendation for IPv6 Address/Mask Notation
draft-lubashev-ipv6-addr-mask-01
Abstract
Since network operators are commonly assigned at least /48 IPv6
address prefixes, the operators and standards occasionally find
opportunities to devise addressing schemes that further assign
operational semantics to less significant bit ranges. There is
currently no standard or interoperable textual representation of
addresses sharing bit patterns that are not prefixes. This RFC
introduces IPv6 Address/Mask notation that allows one to represent
address groupings beyond "all addresses that share a single prefix".
The representation is similar to the IPv4 address/mask notation in
its expressiveness, but it is derived from the familiar address/
prefix-length notation for clarity and compatibility with existing
parsers.
For example, using this representation, both 2001:db8::/32 and
2001:db8:://ffff:ffff:: have the same meaning. However, a group of
addresses having the first 32 bits "2001:0db8::" and the last 16 bits
"::1234" requires the new representation:
2001:db8::1234//ffff:ffff::ffff or, equivalently,
2001:db8::1234//32+::ffff.
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 April 30, 2018.
Lubashev & Nygren Expires April 30, 2018 [Page 1]
Internet-Draft v6AddrMask October 2017
Copyright Notice
Copyright (c) 2017 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Netmask and Prefix-Length Notations . . . . . . . . . . . 3
2. Problem Description . . . . . . . . . . . . . . . . . . . . . 4
3. Notational Conventions . . . . . . . . . . . . . . . . . . . 5
4. IPv6 Address/Mask Textual Representation . . . . . . . . . . 5
4.1. Constraints and Validation . . . . . . . . . . . . . . . 5
4.2. Examples: groups of addresses . . . . . . . . . . . . . . 5
4.3. Examples: specific addresses and groups to which they
belong . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Textual representation of the Address and Mask . . . . . 6
4.5. Use prefix length instead of mask . . . . . . . . . . . . 6
5. Scoped Mask/Value notation . . . . . . . . . . . . . . . . . 6
6. Compatibility and Parser guidelines . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Address Utilization Considerations . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Since draft-lubashev-ipv6-addr-mask-00 . . . . . . . . . 8
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Examples of Semantic Use of Lower Address Bits . . . 11
A.1. A Framework for Semantic IPv6 Prefix and Gap Analysis . . 11
A.2. Teredo . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.3. OpenFlow Switch Configuration . . . . . . . . . . . . . . 11
A.4. TeraStream IPv6 Addressing . . . . . . . . . . . . . . . 11
A.5. SURFnet IPv6 Address Plan and Incognito Routing Plan . . 11
A.6. Geolocation-based addressing method for IPv6 addresses . 12
A.7. Customer IDs in less significant bits . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Lubashev & Nygren Expires April 30, 2018 [Page 2]
Internet-Draft v6AddrMask October 2017
1. Introduction
We have learned to think of IPv4 address groupings in terms of CIDR
blocks, because virtually all logical address groupings fit that
model well: IP address allocations, subnets, routing announcements,
etc.
With the move to IPv6, the primary mechanism for address grouping
remains matching by prefix length, albeit with longer prefix lengths.
This only allows for strictly hierarchical address groupings. The
longer address lengths, however, provide opportunities for assigning
operator-specific semantics to bit strings within addresses beyond
the prefix, especially when allocating addresses for virtual
services.
Numerous systems (see Appendix A for examples) have been assigning
semantics to IPv6 bits that come after IANA prefix bits. Developers
of these systems attempted to communicate address patterns underlying
their system semantics both in documentation and in machine-readable
configurations accompanying the systems. Due to the lack of a
standard textual representation, the documentation often resorted to
pictographs and verbose English descriptions. The configuration
syntax and parsers were invariably ad hoc and incompatible with other
systems.
Here we define a syntax for representing groupings (matching rules)
of IPv6 addresses, where a set of less significant bits have a
particular value. For example, 2001:db8::1234//ffff:ffff::ffff
matches all addresses whose 32 most significant bits are 2001:0db8
and whose 16 least significant bits are 1234.
This document only concerns itself with the textual representation of
address groups that cannot be expressed as CIDR blocks. Our goal is
standardizing on a consistent representation to remove a hindrance to
interoperability of systems that wish to express rules and policies
that apply to such address groups (see Appendix A for examples).
Guidance for the applicability of such address groupings is outside
the scope of this document.
1.1. Netmask and Prefix-Length Notations
There are two common textual representations for identifying groups
of addresses (networks, subnets, internet routing blocks). These
representations can also be used to identify an individual address
and its subnet.
Lubashev & Nygren Expires April 30, 2018 [Page 3]
Internet-Draft v6AddrMask October 2017
The netmask notation described by [RFC0950] is commonly used for
IPv4. It consists of a tuple of a network address and a network
mask. For example: 198.51.100.4 netmask 255.255.255.0.
The address/prefix-length notation described by [RFC4632] is commonly
used for both IPv4 and IPv6. It consists of a tuple of a network
address and a prefix length. For example: 198.51.100.4/24 or
2001:db8::1234/32.
Depending on the context, netmask and prefix length notations can
specify either a "group of addresses" or "an individual address and a
group of addresses to which it belongs". If the network address
contains one or more set bits not selected by the network mask or
prefix length, then network address specifies an individual address
in addition to the subnet. For example: 198.51.100.4/24 means
"address 198.51.100.4 within a group of addresses 198.51.100.0 -
198.51.100.255".
2. Problem Description
The problem with the prefix length notation for IPv6 is that it is
not sufficiently expressive of IPv6 address groupings for a growing
number of applications.
IPv6 address allocation guidelines [RFC6177] guarantee at least a /48
allocation to network operators and strongly recommend a multi-/64
allocation to end sites. Because these address blocks are orders of
magnitude larger than any imaginable number of physical hosts,
network operators are managing those addresses in new and creative
ways.
Sometimes, useful address grouping are not "all addresses that share
a prefix of a certain length". Additionally, within an
administrative scope, there are use-cases where semantics are
assigned to individual bit ranges.
Consider these examples:
1. Allocating a block of addresses to each host and using the least
significant bits to indicate a TLS certificate. These operators
may need a way to express a rule that applies to all traffic that
uses a particular TLS certificate.
2. Network operators managing multiple similar data centers may have
different prefixes routed to those data centers but desire a
unified set of rules for assigning, managing, and routing IPv6
addresses within those data centers. These operators need to
Lubashev & Nygren Expires April 30, 2018 [Page 4]
Internet-Draft v6AddrMask October 2017
express rules that do not depend on the prefixes of the addresses
to which the rules apply.
3. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
4. IPv6 Address/Mask Textual Representation
This RFC extends address/prefix-length notation of [RFC4632] in a way
that is reminiscent of the IPv4 netmask notation of [RFC0950]. The
address/mask notation allows specifying IPv6 mask instead of the
prefix length.
The address/mask notation is defined as:
ADDRESS // MASK
Both ADDRESS and MASK are IPv6 addresses. The MASK indicates which
bits of the ADDRESS are relevant for the address grouping. Note that
the MASK may be sparse and is not strictly a prefix. For example:
2001:db8::1234//ffff:ffff::ffff.
The "//" was chosen as a separator for address/mask notation, since
it is similar to the "/" separator used by address/prefix-length (and
hence is readily recognizable) but prevents incorrectly parsing
address/mask as address/prefix-length.
4.1. Constraints and Validation
To be a valid definition for just a group of addresses, the ADDRESS
part MUST NOT have any bits set outside of the MASK. Otherwise, the
ADDRESS // MASK represents an individual address and a group of
addresses it belongs to.
4.2. Examples: groups of addresses
1. 2001:db8::1234//ffff:ffff::ffff
This specifies IPv6 addresses that look like 2001:db8::1234 when
you ignore bits 16-95.
2. ::aa00:1234//::ff00:ffff
This specifies IPv6 addresses that have "aa" in bits 24-31 and
"1234" in bits 0-15.
Lubashev & Nygren Expires April 30, 2018 [Page 5]
Internet-Draft v6AddrMask October 2017
3. 2001:db8:://ffff:ffff::
This is equivalent to 2001:db8::/32.
4.3. Examples: specific addresses and groups to which they belong
1. 2001:db8::1:1234//ffff:ffff::ffff
This specifies IPv6 address 2001:db8::1:1234 that belongs to a
group of addresses that look like 2001:db8::1234 when you ignore
bits 16-95.
2. 2001:db8::aa00:1234//::ff00:ffff
This specifies IPv6 address 2001:db8::aa00:1234 that belongs to a
group of addresses that have "aa" in bits 24-31 and "1234" in
bits 0-15.
3. 2001:db8::1//ffff:ffff::
This is equivalent to 2001:db8::1/32.
4.4. Textual representation of the Address and Mask
When IPv6 mask is used after "//", both the network address and mask
parts MUST be formatted as IPv6 addresses and, therefore, their
canonical textual representation is dictated by [RFC5952].
4.5. Use prefix length instead of mask
The canonical representation of a group of IPv6 addresses MUST use a
prefix length instead of a mask if possible. That is, if the mask
has all its most significant bits set, up to some bit, followed by
all clear bits, then the canonical representation MUST use a prefix
length.
5. Scoped Mask/Value notation
Since assigning operator-specific semantics to bit ranges is only
possible within the address space assigned to the operator by IANA, a
common use-case is to specify an address/mask within an IANA-assigned
prefix scope. For example, all addresses ending with ::1234 within
2001:db8::/32 can be specified as 2001:db8::1234//ffff:ffff::ffff.
To make these representations easier to manage and validate, it helps
to have an explicit convention for representing prefixes within
address groups. For example, 2001:db8::1234//ffff:ffff::ffff can be
represented as 2001:db8::1234//32+::ffff.
Lubashev & Nygren Expires April 30, 2018 [Page 6]
Internet-Draft v6AddrMask October 2017
This is specified as:
ADDRESS // PFX_LEN + SCOPED_MASK
Scoped Mask/Value notation representation can be canonicalized using
a ADDRESS // MASK notation. The canonical MASK is constructed by
performing the bitwise-or of SCOPED_MASK and the mask derived from an
address with the PFX_LEN most significant bits set.
The PFX_LEN most significant bits MUST NOT be set in SCOPED_MASK.
6. Compatibility and Parser guidelines
Only parsers that wish to support address groupings that cannot be
represented using address/prefix-length are required to support
address/mask notation.
Systems that support communicating address grouping in address/mask
notation to other systems SHOULD communicate such grouping in
canonical address/prefix-length notation, if possible. This ensures
compatibility with systems that do not support address/mask notation,
if all configured address groupings are proper CIDR prefixes.
Address groupings that cannot be expressed using address/prefix-
length notation MAY be communicated using Scoped Mask/Value
(Section 5) notation, as long as the PFX_LEN (semantic prefix scope)
has been configured via external means (i.e. PFX_LEN SHOULD NOT be
automatically derived from the MASK bitmap by the system itself).
7. Security Considerations
This document only defines textual representation for IPv6 address
groupings. It does not intend to recommend when assigning semantics
to specific bit ranges and matching based on bit substrings is
applicable or appropriate.
IP addresses can be spoofed or attacker-controlled. This is
especially true of IPv6 addresses differing only in less significant
bits and belonging to different administrative domains. When used in
policies applied to incoming traffic, the MASK part of the address/
mask notation SHOULD have as many set bits as the semantics of the
policy would allow.
Operators wishing to assign semantics to bit ranges should be aware
that these semantics may be guessable or leaked outside the
organization. Hence, there is a risk of privacy/information leakage.
Lubashev & Nygren Expires April 30, 2018 [Page 7]
Internet-Draft v6AddrMask October 2017
8. Address Utilization Considerations
Since IPv6 allocation guidelines [RFC6177] guarantee at least a /48
allocation to network operators, it would be an enormous waste of the
address space to assign IPv6 addresses only to physical hosts or
network interfaces.
On the other hand, a gratuitous use of lower address bits can lead to
a premature address space exhaustion and difficulties in adapting to
the future needs of the organization within the assigned address
space. An example of such gratuitous use is designating large parts
of the address space for a bitmask, where only a small fraction of
all possible bit combinations is utilized.
9. IANA Considerations
This document has no actions for IANA.
10. Change Log
10.1. Since draft-lubashev-ipv6-addr-mask-00
- Changed separator from "/" to "//"
- Addressed privacy in Section 7
- Added Section 6
- Added Section 8
- Added Appendix A
11. Acknowledgments
The Acknowledgments will come here.
12. References
12.1. Normative References
[RFC0950] Mogul, J. and J. Postel, "Internet Standard Subnetting
Procedure", STD 5, RFC 950, DOI 10.17487/RFC0950, August
1985, <https://www.rfc-editor.org/info/rfc950>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Lubashev & Nygren Expires April 30, 2018 [Page 8]
Internet-Draft v6AddrMask October 2017
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177,
DOI 10.17487/RFC6177, March 2011,
<https://www.rfc-editor.org/info/rfc6177>.
12.2. Informative References
[GeoAddressPatent]
Chen, L., Steenstra, J., and K. Taylor, "US 7929535:
Geolocation-based addressing method for IPv6 addresses",
April 2011, <http://patft1.uspto.gov/netacgi/
nph-Parser?patentnumber=7929535>.
[I-D.jiang-semantic-prefix]
Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang,
"Analysis of Semantic Embedded IPv6 Address Schemas",
draft-jiang-semantic-prefix-06 (work in progress), July
2013.
[IncognitoRoutingPlan]
Kostur, A., "How to Plan Routing for IPv6", July 2015,
<https://www.incognito.com/tips-and-tutorials/
how-to-plan-routing-for-ipv6>.
[OpenFlow]
Open Networking Foundation, "OpenFlow Switch
Specification, Version 1.2", December 2011,
<https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/
wp-content/uploads/2014/10/openflow-spec-v1.2.pdf>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<https://www.rfc-editor.org/info/rfc4380>.
Lubashev & Nygren Expires April 30, 2018 [Page 9]
Internet-Draft v6AddrMask October 2017
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[SURFnetAddrPlan]
SURFnet, "Preparing an IPv6 Address Plan", September 2013,
<https://www.ipv6forum.com/dl/presentations/
IPv6-addressing-plan-howto.pdf>.
[TeraStream]
Lothberg, P. and M. Abrahamsson, "TeraStream - IPv6
Addressing Format", October 2013,
<https://ripe67.ripe.net/presentations/251-ripe2-4.pdf>.
Lubashev & Nygren Expires April 30, 2018 [Page 10]
Internet-Draft v6AddrMask October 2017
Appendix A. Examples of Semantic Use of Lower Address Bits
Assigning semantics to lower bits of IPv6 addresses and defining
policies based on such address groupings have been done for many
years. Documents describing such policies and configurations for
equipment implementing these policies do not use a consistent
notation. Most documents resort to pictographs and verbose English,
while the configuration syntax and parsers are invariably ad hoc.
A.1. A Framework for Semantic IPv6 Prefix and Gap Analysis
Internet draft [I-D.jiang-semantic-prefix] describes the need for
adding semantics to lower IPv6 address bits to define address groups
that cannot be expressed as CIDR blocks and analyzes some
implications of this practice. This draft describes uses of such
address groups for creating routing policies as well as configuring
such policies on hosts and routers both statically and dynamically.
A.2. Teredo
Teredo protocol [RFC4380] uses four bit ranges past Teredo IANA
prefix bits to encode server and client IPv4 addresses, a flags
bitmap, and a port (section "4. Teredo Addresses").
A.3. OpenFlow Switch Configuration
OpenFlow Switch Specification [OpenFlow] describes OpenFlow switch
configuration API that can match flows based on an arbitrary IPv6
bitmask applied to IPv6 source (OXM_OF_IPV6_SRC) or destination
(OXM_OF_IPV6_DST) addresses. Version 1.2 was the first version to
introduce such IPv6 address/bitmask flow match rules (chapter
A.2.3.7) in 2011.
A.4. TeraStream IPv6 Addressing
TeraStream [TeraStream] system is using bit ranges to encode service
type in IPv6 address bits that come after IANA prefix bits. The
system was launched in 2012.
A.5. SURFnet IPv6 Address Plan and Incognito Routing Plan
SURFnet published a white paper [SURFnetAddrPlan] advocating that
ISPs use bit ranges past their IANA prefix to encode geo-location and
address use types. The white paper is giving examples of a sample
address allocation that uses one nibble (bits 68-71) for encoding
geo-location and another nibble (bits 64-67) for the use type.
Lubashev & Nygren Expires April 30, 2018 [Page 11]
Internet-Draft v6AddrMask October 2017
IPv6 Routing Plan [IncognitoRoutingPlan] by incognito is advocating
allocating bit ranges past an IANA prefix to designate various
address attributes, including "subnet types".
A.6. Geolocation-based addressing method for IPv6 addresses
Qualcomm US patent 7,929,535 [GeoAddressPatent] describes a method of
embedding geo-location information, such as latitude, longitude,
altitude, in predefined ranges of bits of an IPv6 address past their
IANA prefix.
A.7. Customer IDs in less significant bits
CDNs and hosting providers host web sites belonging to multiple
customers using shared servers. Due to the lack of support for SNI
TLS extension [RFC6066] by some user agents active on the Internet,
CDNs resort to using unique IP addresses to identify specific
customer domains and, hence, certificates for TLS negotiation. In
case of IPv6 addresses, at least some CDNs use the less significant
bits of an IPv6 address to identify customer domains (while the more
significant bits carry internal routing information). The
configuration of systems matching lower bits of IPv6 addresses to
individual customer domains must use ad hoc syntax due to the lack of
a standard way to express semantics of matching on bit ranges other
than address prefixes.
Authors' Addresses
Igor Lubashev
Akamai Technologies
EMail: igorlord@alum.mit.edu
Erik Nygren
Akamai Technologies
EMail: erik+ietf@nygren.org
URI: http://erik.nygren.org/
Lubashev & Nygren Expires April 30, 2018 [Page 12]