--- 1/draft-ietf-v6ops-design-choices-06.txt 2015-04-01 23:15:15.938430967 -0700 +++ 2/draft-ietf-v6ops-design-choices-07.txt 2015-04-01 23:15:15.978431924 -0700 @@ -1,19 +1,19 @@ V6OPS Working Group P. Matthews Internet-Draft Alcatel-Lucent Intended status: Informational V. Kuarsingh -Expires: September 10, 2015 Dyn - March 9, 2015 +Expires: October 4, 2015 Dyn + April 2, 2015 Some Design Choices for IPv6 Networks - draft-ietf-v6ops-design-choices-06 + draft-ietf-v6ops-design-choices-07 Abstract This document presents advice on certain routing-related design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. @@ -25,21 +25,21 @@ 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 http://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 September 10, 2015. + This Internet-Draft will expire on October 4, 2015. Copyright Notice Copyright (c) 2015 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 @@ -51,21 +51,21 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Mix IPv4 and IPv6 on the Same Layer-3 Interface? . . 3 2.1.2. Interfaces with Only Link-Local Addresses? . . . . . 4 2.2. Static Routes . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Link-Local Next-Hop in a Static Route? . . . . . . . 6 - 2.3. IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.3. IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. IGP Choice . . . . . . . . . . . . . . . . . . . . . 7 2.4. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.1. Which Transport for Which Routes? . . . . . . . . . . 8 2.4.1.1. BGP Sessions for Unlabeled Routes . . . . . . . . 10 2.4.1.2. BGP sessions for Labeled or VPN Routes . . . . . 11 2.4.2. eBGP Endpoints: Global or Link-Local Addresses? . . . 11 3. General Observations . . . . . . . . . . . . . . . . . . . . 12 3.1. Use of Link-Local Addresses . . . . . . . . . . . . . . . 12 3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 @@ -161,49 +161,48 @@ support for IPv6 matures, making option (b) less and less attractive until the day that IPv4 is finally turned off. 2.1.2. Interfaces with Only Link-Local Addresses? As noted in the introduction, this document does not cover the ins and outs around creating an IPv6 addressing plan. However, there is one fundamental question in this area that often arises: Should an interface: - a. Use only a link-local address ("unnumbered"), OR + a. Use only a link-local address ("link-local-only"), OR b. Have global and/or unique-local addresses assigned in addition to the link-local? There are two advantages in interfaces with only link-local addresses - ("unnumbered interfaces"). The first advantage is ease of - configuration. In a network with a large number of unnumbered + ("link-local-only interfaces"). The first advantage is ease of + configuration. In a network with a large number of link-local-only interfaces, the operator can just enable an IGP on each router, without going through the tedious process of assigning and tracking the addresses for each interface. The second advantage is security. Since packets with Link-Local destination addresses should not be routed, it is very difficult to attack the associated nodes from an off-link device. This implies less effort around maintaining security ACLs. - Countering this advantage are various disadvantages to interfaces - with only link-local addresses: - - o It is not possible to ping an interface that has only a link-local - address from a device that is not directly attached to the link. + Countering this advantage are various disadvantages to link-local- + only interfaces: - Thus, to troubleshoot, one must typically log into a device that - is directly attached to the device in question, and execute the - ping from there. + o It is not possible to ping a link-local-only interface from a + device that is not directly attached to the link. Thus, to + troubleshoot, one must typically log into a device that is + directly attached to the device in question, and execute the ping + from there. - o A traceroute passing over the unnumbered interface will return the - loopback or system address of the router, rather than the address - of the interface itself. + o A traceroute passing over the link-local-only interface will + return the loopback or system address of the router, rather than + the address of the interface itself. o In cases of parallel point to point links it is difficult to determine which of the parallel links was taken when attempting to troubleshoot unless one sends packets directly between the two attached link-locals on the specific interfaces. Since many network problems behave differently for traffic to/from a router than for traffic through the router(s) in question, this can pose a significant hurdle to some troubleshooting scenarios. o On some routers, by default the link-layer address of the @@ -230,21 +229,22 @@ because the MAC address is duplicated (due to manufacturing process defaults or the use of virtualization), because a device deliberately re-uses automatically-assigned link-local addresses on different links, or because an operator manually assigns the same easy-to-type link-local address to multiple interfaces. All these are allowed in IPv6 as long as the addresses are used on different links. For more discussion on the pros and cons, see [RFC7404]. See also [RFC5375] for IPv6 unicast address assignment considerations. - Today, most operators use numbered interfaces (option b). + Today, most operators use interfaces with global or unique-local + addresses (option b). 2.2. Static Routes 2.2.1. Link-Local Next-Hop in a Static Route? For the most part, the use of static routes in IPv6 parallels their use in IPv4. There is, however, one exception, which revolves around the choice of next-hop address in the static route. Specifically, should an operator: