A DNS Resource Record for IPv6 Segment Routing (SR6)
draft-jadin-spring-ipv6-segment-routing-dns-rr-00

Abstract

This document defines the IPv6 Segment Routing (SR6) Resource Record (RR). This Resource Record gives a path to reach a given destination. The path is encoded with an IPv6 Segment List. The host uses a Segment Routing Header (SRH) derived from the SR6 RR to reach the destination.

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 September 6, 2018.

Copyright Notice

Copyright (c) 2018 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
• 1.1. Reserved Keywords
• 2. Resource Record Format
• 2.1. SR6 RDATA Wire format
• 2.1.1. The SID Number field
• 2.1.2. The Flags field
• 2.1.3. The Tag field
• 2.1.4. The Segment List[n] field
• 2.1.5. The Type Length Value (TLV) objects
• 2.2. The SR6 RR Presentation Format
• 2.3. SR6 RR Example
• 3. SRH derivation from SR6 RR
• 3.1. Derived SRH Example
• 4. Security considerations
• 5. IANA Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

Segment Routing is a new architecture [I-D.ietf-spring-segment-routing] that leverages the source routing paradigm. Two data planes are being defined to support this architecture: MPLS [I-D.ietf-spring-segment-routing-mpls] and IPv6 through the IPv6 Segment Routing Header [I-D.ietf-6man-segment-routing-header]. This new architecture has a variety of use cases that are discussed in [I-D.ietf-spring-ipv6-use-cases] [I-D.ietf-spring-resiliency-use-cases] and [I-D.ietf-spring-oam-usecase].

Segment Routing was initially defined as a technique to enable network operators to better control the flow of packets inside their network. Most use cases leverage Segment Routing on routers only. In contrast with the MPLS data plane that is traditionally only supported on routers, the IPv6 Segment Routing Header is supported on both routers [SR6Demo] and on endhosts [SR6Linux]. The ability of setting and processing the IPv6 Segment Routing Header on endhosts opens new “end-to-end” use cases for Segment Routing. We can envision networks where clients set the IPv6 Segment Routing Header in all the packets they send to reach a given server along a specific path that depends on the client’s or the network policies. However, the ability to set and process the IPv6 Segment Routing Header on endhosts [SR6Linux] is not sufficient to support real services. Those endhosts also need a way to learn the IPv6 Segment Routing Header that they need to use to reach a given destination according to the network policies. Several mechanisms are being discussed to distribute the IPv6 addresses that are used as Segments [I-D.ietf-6man-segment-routing-header]. However, these mechanisms typically extend routing protocols such as BGP [I-D.ietf-spring-segment-routing-msdc], OSPF [I-D.ietf-ospf-ospfv3-segment-routing-extensions] or IS-IS [I-D.ietf-isis-segment-routing-extensions] and do not reach endhosts.

In this document, we propose to extend the Domain Name System to distribute IPv6 Segment Routing Headers to endhosts. Our main use case are enterprise networks where the network administrator could use the DNS resolver to distribute IPv6 Segment Routing Headers to endhosts according to the enterprise policies. This use case is described in more details in a forthcoming paper [SRN2018].

This document is organized as follows. Section 2 gives the wire and presentation formats of the proposed SR6 Resource Record. Section 3 describes how endhosts can construct an IPv6 Segment Routing Header from an SR6 RR.

1.1. Reserved Keywords

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].

2. Resource Record Format

This document proposes a new type of Resource Record: the IPv6 Segment Routing (SR6) Resource Record. This RR has a new DNS Type, (suggested value TDB) to be assigned by IANA. The SR6 RR MUST be in the IN class.

2.1. SR6 RDATA Wire format

The SR6 RR contains a set of flags, a tag and a list of segments represented as IPv6 addresses. Its wire format is provided in Figure 1. It encodes a subset of the IPv6 Segment Routing Header defined in [I-D.ietf-6man-segment-routing-header].

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +---------------+---------------+------------------------------+
 |  SID Number   |     Flags     |             Tag              |
 +---------------+---------------+------------------------------+
 |                                                              |
 |           Segment List[1] (128 bits IPv6 address)            |
 |                                                              |
 |                                                              |
 +--------------------------------------------------------------+
 |                                                              |
 |                              ...                             |
 |                                                              |
 |                                                              |
 +--------------------------------------------------------------+
 |                                                              |
 |           Segment List[n] (128 bits IPv6 address)            |
 |                                                              |
 |                                                              |
 +--------------------------------------------------------------+
 /                                                              /
 /        Optional Type Length Value objects (variable)         /
 /                                                              /
 +--------------------------------------------------------------+

Figure 1: SR6 Resource Record

2.1.1. The SID Number field

The SID Number field indicates the number of Segments present in the Segment List.

2.1.2. The Flags field

A subset of the flags defined in the IPv6 Segment Routing Header [I-D.ietf-6man-segment-routing-header] may appear inside the SR6 RR.

  0 1 2 3 4 5 6 7
 +-+-+-+-+-+-----+
 |  U  |A|H|  U  |
 +-+-+-+-+-+-----+

Figure 2: SR6 Flags field

• U: These flags are currently unused and reserved for future use. They SHOULD be unset on transmission and MUST be ignored upon receipt.

• A-flag: Alert flag. If present, it indicates that important Type Length Value (TLV) objects are present.
• H-flag: HMAC flag. If set, the derived SRH MUST be protected by an HMAC TLV object, defined in [I-D.ietf-6man-segment-routing-header].

2.1.3. The Tag field

The Tag field is an opaque value that MUST be equal to the tag field of the derived SRH, defined in [I-D.ietf-6man-segment-routing-header].

2.1.4. The Segment List[n] field

The Segment List[n] field is a list of 128 bit IPv6 addresses with the nth address representing the nth segment in the Segment List. This list is used to construct the SRH, as discussed in Section 3.

2.1.5. The Type Length Value (TLV) objects

A subset of the SRH TLV objects, defined in [I-D.ietf-6man-segment-routing-header], MAY be added at the end of the SR6 RR. This document only allows the Opaque Container and Padding TLV objects.

• The Opaque Container TLV objects MUST be copied at the end of the derived SRH.
• The Padding TLV objects do not carry any information and so, they MAY be ignored during the SRH derivation.

Future versions of this document will discuss the support of other TLV objects.

2.2. The SR6 RR Presentation Format

The presentation format of the RDATA portion is as follows:

• The Flags field MUST be represented as an unsigned decimal integer.
• The Tag field MUST be represented as an unsigned decimal integer.
• The Segment List MUST be represented as IPv6 addresses separated by commas. They MUST appear in the same order as in the wire format (Section 2.1).
• The TLV objects MUST be represented as a sequence of case-insensitive hexadecimal digits. White spaces are allowed within the hexadecimal text.

2.3. SR6 RR Example

  example.com. 86400 IN AAAA 2001:abcd::5

  example.com. 86400 IN SRH 8 3 fc00::1,fc00::5 (03120000DA1F9C8094
                                                 E834A7BC71965A47A1B6C)

Figure 3: Textual representation of SR6 records

The first four text fields of the second line in Figure 3 specify the name, TTL, Class, and RR type (SR6). Value 8 indicates that only the A-flag is set. Value 3 is the Tag field value. The next part is the Segment List represented as a list of comma separated IPv6 addresses. The text between the parentheses is the hexadecimal representation of the TLV objects.

3. SRH derivation from SR6 RR

This section describes the construction of the IPv6 Segment Routing Header from an SR6 RR. The H-flag and A-flag of the SRH MUST be copied from their equivalent fields in the SR6 RR. All the other flags MUST be set to 0.

The Tag field of the SRH MUST be copied from the SR6 RR Tag field.

The SRH Segment List is composed of the destination address as first segment and of the SR6 RR Segment List for the rest of the list. Therefore, SRH Segments Left and Last Entry fields MUST be set to the SR6 RR SID Number field.

Opaque Container TLV objects MUST be added at the end of the SRH if they were present in the Resource Record. Additional Padding TLV objects MAY be added to the SRH. If the H-flag is set, a HMAC TLV MUST be computed for the SRH. The order of the SRH TLV objects MAY be different from the SR6 RR TLV objects.

3.1. Derived SRH Example

The following SRH is derived from the SR6 RR example in Section 2.3.

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +---------------+---------------+---------------+---------------+
 | Next Header   |     0x4B      |     0x04      |     0x02      |
 +---------------+---------------+---------------+---------------+
 |     0x02      |0 0 0 1 0 0 0 0|            0x0003             |
 +---------------+---------------+-------------------------------+
 |                                                               |
 |                         2001:abcd::5                          |
 |                                                               |
 |                                                               |
 +---------------------------------------------------------------+
 |                                                               |
 |                            fc00::1                            |
 |                                                               |
 |                                                               |
 +---------------------------------------------------------------+
 |                                                               |
 |                            fc00::5                            |
 |                                                               |
 |                                                               |
 +---------------+---------------+---------------+---------------+
 |      0x03     |      0x12     |      0x00     |      0x00     |
 +---------------+---------------+---------------+---------------+
 |                                                               |
 |               0xDA1F9C8094E834A7BC71965A47A1B6C               |
 |                                                               |
 |                                                               |
 +---------------------------------------------------------------+

Figure 4: Example of built SRH

4. Security considerations

[I-D.ietf-6man-segment-routing-header] explores security issues related to the SRH itself. [I-D.filsfils-spring-srv6-network-programming] documents how an administrative domain can prevent external traffic from using its SRv6-based services. This section focuses on the security threats raised by the SR6 RR.

Since the SR6 RR provides a SRH to be used by endhosts, the endhosts that request SR6 RR must trust the information received from their DNS resolver. In many networks, this trust comes from the network configuration. In addition, techniques such as DNSSEC [RFC4033] or DNS over TLS [RFC7858] can be used to prevent situations where an attacker could modify the SR6 RR of DNS responses.

5. IANA Considerations

This document requests IANA to assign a DNS RR data type value for the SR6 RR type under the “Resource Record (RR) TYPEs” subregistry under the “Domain Name System (DNS) Parameters” registry.

6. Acknowledgements

The authors would like to thank David Lebrun for his contribution to the design of the SR6 RR.

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses