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]