Network Working Group F. Templin
Internet-Draft Boeing Research & Technology
Intended status: Standards Track November 23, 2009
Expires: May 27, 2010
Stub Router Advertisements in IPv6 Neighbor Discovery
draft-templin-6man-stub-router-00.txt
Abstract
The IPv6 Neighbor Discovery protocol [RFC4861] specifies the
operation of routers, including the process of sending and receiving
Router Advertisement (RA) messages. However, the specification makes
no distinction between different classes of routers that may occur on
a link. In particular, the specification is written from the
perspective of routers that are "authoritative for the link", i.e.,
routers that connect the link to provider networks. This document
discusses considerations for a different class of routers known as
"stub routers".
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 27, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Templin Expires May 27, 2010 [Page 1]
Internet-Draft Stub Router Advertisement November 2009
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Requirements . . . . . . . . . . . . . . . . . 3
3. Sending Stub Router Advertisements . . . . . . . . . . . . . . 3
4. Processing Stub Router Advertisements . . . . . . . . . . . . . 4
5. Stub Router Solicitation by Authoritative Routers . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Templin Expires May 27, 2010 [Page 2]
Internet-Draft Stub Router Advertisement November 2009
1. Introduction
The IPv6 Neighbor Discovery protocol [RFC4861][RFC2460] specifies the
operation of routers, including the process of sending and receiving
Router Advertisement (RA) messages. However, the specification makes
no distinction between different classes of routers that may occur on
a link. In particular, the specification is written from the
perspective of routers that are "authoritative" for the link, i.e.,
routers that connect the link to provider networks. This document
discusses considerations for a different class of routers known as
"stub routers".
A stub router is any router that attaches stub networks to the link,
but does not itself attach the link to a provider network. Here, a
"stub network" could be as simple as a small collection of IPv6
links, or as large as a complex corporate enterprise network. Stub
routers are said to be "non-authoritative" for the link, since they
cannot themselves provide forwarding services for packets emanating
from their stub networks without using another router on the link as
a transit.
Stub routers may send Router Advertisements (RAs) only if the RAs
include no information that could conflict with the information
advertised by authoritative routers. As such, stub router RAs must
be sent as unicast-only since the 'M' and 'O' flags (and possibly
other information) in the RAs could override the values that hosts
have cached from RAs received from an authoritative router.
Moreover, stub router RAs must be sent only to other routers, since
legacy hosts have no way to determine whether the RA came from an
authoritative or non-authoritative router.
The following sections outline processing rules for stub router RAs.
Also specified are two new RA flags known as the "Stub Router
Advertisement (SRA)" and "Stub Router Solicitation (SRS)" flags that
stub routers can use to exchange information with other routers.
2. Terminology and Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
3. Sending Stub Router Advertisements
Stub routers sends RAs to the unicast addresses of other routers on
the link discovered through a link-specific means. Examples include
Templin Expires May 27, 2010 [Page 3]
Internet-Draft Stub Router Advertisement November 2009
listening for multicast RAs from authoritative routers, parsing a
list of unicast addresses of on-link routers, etc. Stub routers MUST
set all authoritative fields in the RA message to 0, including:
o the Cur Hop Limt field,
o the 'M' and 'O' bits,
o any other flag bits that are authoritative for the link (e.g., the
Router Selection Preference bits [RFC4191]),
o the Router Lifetime field,
o the Reachable Time field,
o The Retrans Timer field.
Additionally, stub router RAs MUST NOT include options that contain
information that is authoritative for the link. Examples include the
link MTU option and Prefix Information Options (PIOs).
Stub router RAs set a new flag known as the Stub Router Advertisement
(SRA) flag [RFC5175]; they also set the Stub Router Solicitation
(SRS) flag in RAs for which they require receipt of confirmation (see
Section 4).
When the SRS flag is set, stub routers send up to
MAX_RTR_SOLICITATIONS RAs until a unicast RA response is received.
Stub routers parse any such unicast RAs in the same manner as a host
would parse them, except that they ignore the values in the 'A' and
'L' bits of any PIOs and treat those values as zero. Hence, stub
routers may discover IPv6 prefixes that are associated with the link
but MUST NOT configure addresses from those prefixes nor assign those
prefixes to an interface.
4. Processing Stub Router Advertisements
[RFC4861], Section 6.2.7 states that "Any other action on reception
of Router Advertisement messages by a router" (i.e., other than
consistency checking) "is beyond the scope of this document.". This
document therefore updates [RFC4861] by specifying the manner in
which routers process Stub Router Advertisements.
When a router (either authoritative or stub) receives an RA message
with the SRA flag set, it ignores all fields and options in the RA
that are authoritative for the link (see Section 3) and processes all
other options, including Route Information Options (RIOs) [RFC4191].
Templin Expires May 27, 2010 [Page 4]
Internet-Draft Stub Router Advertisement November 2009
If the SRS flag is also set, the router prepares a unicast RA message
with the SRS flag set to 0 and sends the message to the unicast
source address of the RA that elicited the response.
5. Stub Router Solicitation by Authoritative Routers
Authoritative routers may solicit unicast RA responses from other
routers by sending unicast RA messages with the SRS and SRA bits set
as specified in Section 4 and 5. If so, the authoritatitve router
processes any information that is authoritatitve for the link for
consistency checking purposes only.
6. IANA Considerations
New Router Advertisement flag bits [RFC5175] are requested for the
SRA and SRS flags.
7. Security Considerations
The security considerations in [RFC4861] apply.
8. Acknowledgments
The author acknowledges the many list discussions which have covered
topics such as RA 'M' and 'O' bit settings, PIO 'A' and 'L' bit
settings, rogue router advertisements, RA guards, etc.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement
Flags Option", RFC 5175, March 2008.
Templin Expires May 27, 2010 [Page 5]
Internet-Draft Stub Router Advertisement November 2009
9.2. Informative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Author's Address
Fred L. Templin
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires May 27, 2010 [Page 6]