Using 127-Bit IPv6 Prefixes on Inter-Router Links
RFC 6164
| Document | Type |
RFC - Proposed Standard
(April 2011; Errata)
Updated by RFC 6547
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Replaces | draft-kohno-ipv6-prefixlen-p2p | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| 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,
Show full document text