IPv6 Path MTU Option
draft-kline-6man-pmo-00

Abstract

This document describes an IPv6 Neighbor Discovery (ND) Path MTU Option (PMO) for inclusion in Router Advertisements (RAs). This allows some environments greater flexibility to support, for example, a higher MTU for on-link or intra-administrative-domain communications than for broader Internet communications.

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 January 9, 2020.

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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

This document describes an IPv6 Neighbor Discovery (ND) Path MTU Option (PMO) for inclusion in Router Advertisements (RAs). This allows some environments greater flexibility to support, for example, a higher MTU for on-link or intra-administrative-domain communications than for broader Internet communications.

TBD: Explain why extending RFC4191 RIOs didn't look easy.

TBD: more discussion

2. Terminology

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2.2. Summary of key terms

For the purposes of this document the following terms are used as described here.

2.2.1. Link MTU

The MTU of the link ([RFC4861]); alternatively, the MTU as it would be determined were no Path MTU Option present. This may be:

the value specified in an MTU Option,

a value specified in a separate document that covers operating IP over a particular link type (e.g., [RFC2464]), or

a value derived by other means (e.g. administrative or a hint from a sub-IP layer mechanism).

The Link MTU MUST be the initial Path MTU used when transmitting to any link-local destination.

2.2.2. Path MTU

TBD: Path MTU

2.2.3. Path MTU Discovery

TBD: Path MTU Discovery (cite [RFC8201])

2.2.4. MTU Option

The MTU Option is defined in [RFC4861] section 4.6.4. In this documented it may also be referred to as the Link MTU Option, in order to disambiguate it from this the Path MTU Option.

2.2.5. Path MTU Option

The IPv6 ND Path MTU Option is described in this document. It provides more explicit signaling of the best initial Path MTU value for a given set of destinations when sending via the advertising router.

3. Path MTU Option Format

 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     MTU #1 (upper 16 bits)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     MTU #1 (lower 16 bits)    | num prefixes  | prefix len #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   prefix #1  ...                                              |
.                                                               .
.                                                               .
.                                                               .
|   ...                                                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                
                

Fields:

The Path MTU Option contents are encoded as a repeated sequence of:

4-octet MTU value

1-octet number of prefixes

sequence of prefixes to which this MTU applies

where each prefix is encoded as:

1-octet prefix length

variable length leading bits of prefix or IP address

Each sequence of octets representing a prefix uses only as many octets as required to by the prefix length (e.g. for a prefix length of 0: 0 octets are required, for prefix lengths 1 through 8: 1 octet is required, and so on).

The option is padded with zero-valued octets to the 8 octet boundary as given by the option length.

4. Option Processing Rules

Nodes compliant with this specification do not change their processing of RAs that contain no Path MTU Options. Additionally, for all Path MTU determination, an effective Path MTU learned via a Path MTU Discovery mechanism ([RFC8201]) MUST take precedence.

Any IPv6 link-local prefixes listed within a Path MTU Option MUST be ignored by the receiver and SHOULD be logged for review by an administrator.

Any MTU value lower than the IPv6 minimum MTU (i.e. 1280, [RFC8200] section 5), SHOULD be logged for administrator review as a configuration error and MUST be treated by the receiver as though the IPv6 minimum MTU had been the encoded value.

The Link MTU MUST also be used for all on-link destinations, to maintain compatibility with existing behavior and expectations. For the same reason, the Link MTU SHOULD be used for destinations within any PIO prefix in the RA, even if the L bit is not set. As noted in [RFC5942], a destination may at some time be learned to be on-link, and this information may expire or be changed.

For all other destinations considered reachable via the option's advertising router, an initial Path MTU SHOULD be determined by first looking for a prefix that includes the destination in a Path MTU Option and using the corresponding MTU value. If no such prefix exists, the Link MTU SHOULD be assumed to be the default.

Note that as a matter of convenience a Path MTU Option may contain an entry for ::/0 even when the router lifetime is zero. This in no way indicates that the router will function as a default gateway. Rather, it may be used, for example, to apply a Path MTU to all prefixes listed in a set of RIOs.

5. Examples

TBD

6. Security Considerations

TBD

7. References

7.1. Normative References

7.2. Informative References

Author's Address

Table of Contents

• 1. Introduction
• 2. Terminology
• 2.1. Requirements Language
• 2.2. Summary of key terms
• 2.2.1. Link MTU
• 2.2.2. Path MTU
• 2.2.3. Path MTU Discovery
• 2.2.4. MTU Option
• 2.2.5. Path MTU Option
• 3. Path MTU Option Format
• 4. Option Processing Rules
• 5. Examples
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address