datatracker.ietf.org
Sign in
Version 5.9.0, 2014-12-18
Report a bug

Support of Address Families in OSPFv3
RFC 5838

Document type: RFC - Proposed Standard (April 2010; No errata)
Updated by RFC 6969
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 5838 (Proposed Standard)
Responsible AD: Ross Callon
Send notices to: ospf-chairs@tools.ietf.org, draft-ietf-ospf-af-alt@tools.ietf.org

Internet Engineering Task Force (IETF)                    A. Lindem, Ed.
Request for Comments: 5838                                      Ericsson
Category: Standards Track                                   S. Mirtorabi
ISSN: 2070-1721                                                   A. Roy
                                                               M. Barnes
                                                           Cisco Systems
                                                             R. Aggarwal
                                                        Juniper Networks
                                                              April 2010

                 Support of Address Families in OSPFv3

Abstract

   This document describes a mechanism for supporting multiple address
   families (AFs) in OSPFv3 using multiple instances.  It maps an AF to
   an OSPFv3 instance using the Instance ID field in the OSPFv3 packet
   header.  This approach is fairly simple and minimizes extensions to
   OSPFv3 for supporting multiple AFs.

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/rfc5838.

Copyright Notice

   Copyright (c) 2010 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.

Lindem, et al.               Standards Track                    [Page 1]
RFC 5838                        OSPFv3 AF                     April 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Design Considerations  . . . . . . . . . . . . . . . . . .  2
     1.2.  Requirements Notation  . . . . . . . . . . . . . . . . . .  3
   2.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Instance ID Values for New AFs . . . . . . . . . . . . . .  3
     2.2.  OSPFv3 Options Changes . . . . . . . . . . . . . . . . . .  4
     2.3.  Advertising Prefixes in AFs Other Than IPv6  . . . . . . .  4
     2.4.  Changes to the Hello Packet Processing . . . . . . . . . .  4
     2.5.  Next-Hop Calculation for IPv4 Unicast and Multicast AFs  .  5
     2.6.  AS-External-LSA and NSSA-LSA Forwarding Address for
           IPv4 Unicast and IPv4 Multicast AFs  . . . . . . . . . . .  5
     2.7.  Database Description Maximum Transmission Unit (MTU)
           Specification for Non-IPv6 AFs . . . . . . . . . . . . . .  6
     2.8.  Operation over Virtual Links . . . . . . . . . . . . . . .  8
   3.  Backward Compatibility . . . . . . . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 12

1.  Introduction

   OSPFv3 [OSPFV3] has been defined to support the base IPv6 unicast
   address family (AF).  There are requirements to advertise other AFs
   in OSPFv3, including multicast IPv6, unicast IPv4, and multicast
   IPv4.  This document supports these other AFs in OSPFv3 by mapping
   each AF to a separate Instance ID and OSPFv3 instance.

1.1.  Design Considerations

   This section describes the rationale for using the multiple Instance
   ID approach to support multiple address families in OSPFv3.  As
   described earlier, OSPFv3 is designed to support multiple instances.
   Hence, mapping an instance to an address family doesn't introduce any
   new mechanisms to the protocol.  It minimizes the protocol extensions
   required, and it simplifies the implementation.  The presence of a

[include full document text]