Using 127-Bit IPv6 Prefixes on Inter-Router Links
RFC 6164
Document | Type |
RFC - Proposed Standard
(April 2011; Errata)
Updated by RFC 6547
|
|
---|---|---|---|
Authors | Yoshinobu Matsuzaki , Miya Kohno , Thomas Narten , Randy Bush , Becca Nitzan , Lorenzo Colitti | ||
Last updated | 2020-01-21 | ||
Replaces | draft-kohno-ipv6-prefixlen-p2p | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 6164 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Jari Arkko | ||
Send notices to | (None) |
Internet Engineering Task Force (IETF) M. Kohno Request for Comments: 6164 Juniper Networks, Keio University Category: Standards Track B. Nitzan ISSN: 2070-1721 Juniper Networks R. Bush Y. Matsuzaki Internet Initiative Japan L. Colitti Google T. Narten IBM Corporation April 2011 Using 127-Bit IPv6 Prefixes on Inter-Router Links Abstract On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4. This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6164. Kohno, et al. Standards Track [Page 1] RFC 6164 IPv6 prefixlen p2p April 2011 Copyright Notice Copyright (c) 2011 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 (http://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 ....................................................2 2. Scope of This Memo ..............................................3 3. Conventions Used in This Document ...............................3 4. Problems Identified with 127-Bit Prefix Lengths in the Past .....3 5. Reasons for Using Longer Prefixes ...............................4 5.1. Ping-Pong Issue ............................................4 5.2. Neighbor Cache Exhaustion Issue ............................4 5.3. Other Reasons ..............................................5 6. Recommendations .................................................5 7. Security Considerations .........................................6 8. Contributors ....................................................6 9. Acknowledgments .................................................6 10. References .....................................................6 10.1. Normative References ......................................6 10.2. Informative References ....................................7 1. Introduction [RFC4291] specifies that interface IDs for all unicast addresses, except those that start with the binary value 000, are required to be 64 bits long and to be constructed in Modified EUI-64 format. In addition, it defines the Subnet-Router anycast address, which is intended to be used for applications where a node needs to communicate with any one of the set of routers on a link. Some operators have been using 127-bit prefixes, but this has been discouraged due to conflicts with Subnet-Router anycast [RFC3627]. However, using 64-bit prefixes creates security issues that are particularly problematic on inter-router links, and there are other valid reasons to use prefixes longer than 64 bits, in particular /127 (see Section 5). Kohno, et al. Standards Track [Page 2] RFC 6164 IPv6 prefixlen p2p April 2011 This document provides a rationale for using 127-bit prefix lengths, reevaluates the reasons why doing so was considered harmful, and specifies how /127 prefixes can be used on inter-router links configured for use as point-to-point links.Show full document text