Using /64 from Customer Prefix for the Inter-Router Link
draft-palet-v6ops-p2p-from-customer-prefix-01

Document Type Active Internet-Draft (individual)
Last updated 2017-10-29
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
v6ops                                                  J. Palet Martinez
Internet-Draft                                          The IPv6 Company
Intended status: Best Current Practice                  October 28, 2017
Expires: May 1, 2018

        Using /64 from Customer Prefix for the Inter-Router Link
             draft-palet-v6ops-p2p-from-customer-prefix-01

Abstract

   This document describes the usage of a /64 from the customer prefix
   for numbering IPv6 point-to-point links in non-broadcast layer 2
   media.

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 May 1, 2018.

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.

Palet Martinez             Expires May 1, 2018                  [Page 1]
Internet-Draft     Point-to-Point from Customer Prefix      October 2017

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Rational for using /64  . . . . . . . . . . . . . . . . . . .   3
   3.  Numbering Interfaces  . . . . . . . . . . . . . . . . . . . .   3
   4.  Routing Aggregation of the Point-to-Point Links . . . . . . .   3
   5.  DHCPv6 Considerations . . . . . . . . . . . . . . . . . . . .   5
   6.  Router Considerations . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   There are different alternatives for numbering IPv6 point-to-point
   links, and from an operational perspective, they may have different
   advantages or disadvantages that need to be taken in consideration
   under the scope of each specific network architecture design.

   [RFC6164] describes using /127 prefixes for inter-router point-to-
   point links, using two different address pools, one for numbering the
   point-to-point links and another one for delegating the prefixes at
   the end of the point-to-point link.  However this doesn't exclude
   other choices.

   This document describes an alternative the approach, using a /64 from
   the customer prefix, which ensure compliance with standards, and
   consequently facilitate interoperability, avoids possible future
   issues if more addresses are needed (e.g., managed bridges) and
   simplifies the addressing plan.

   The use of /64 also facilitates an easier way for routing the shorter
   aggregated prefix into the point-to-point link.  Consequently it
   simplifies the "view" of a more unified addressing plan, providing an
   easier path for following up any issue when operating IPv6 networks.

   The proposed approach is suitable for those point-to-point links
   connecting ISP to Customers and enterprise networks, but not limited
   to those cases, and in fact, is being used by a relevant number of
   networks worldwide, in several different scenarios.

   This mechanism would not work in broadcast layer two media that rely
   on ND (as it will try ND for all the addresses within the shorter
   prefix being delegated thru the point-to-point link).

Palet Martinez             Expires May 1, 2018                  [Page 2]
Internet-Draft     Point-to-Point from Customer Prefix      October 2017

2.  Rational for using /64

   The IPv6 Addressing Architecture ([RFC4291]) specifies that all the
   Interface Identifiers for all the unicast addresses (except for
   000/3) are required to be 64 bits long and to be constructed in
   Modified EUI-64 format.

   The same document also mandates the usage of the predefined subnet-
Show full document text