draft-ietf-v6ops-design-choices-06.txt   draft-ietf-v6ops-design-choices-07.txt 
V6OPS Working Group P. Matthews V6OPS Working Group P. Matthews
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Informational V. Kuarsingh Intended status: Informational V. Kuarsingh
Expires: September 10, 2015 Dyn Expires: October 4, 2015 Dyn
March 9, 2015 April 2, 2015
Some Design Choices for IPv6 Networks Some Design Choices for IPv6 Networks
draft-ietf-v6ops-design-choices-06 draft-ietf-v6ops-design-choices-07
Abstract Abstract
This document presents advice on certain routing-related design This document presents advice on certain routing-related design
choices that arise when designing IPv6 networks (both dual-stack and choices that arise when designing IPv6 networks (both dual-stack and
IPv6-only). The intended audience is someone designing an IPv6 IPv6-only). The intended audience is someone designing an IPv6
network who is knowledgeable about best current practices around IPv4 network who is knowledgeable about best current practices around IPv4
network design, and wishes to learn the corresponding practices for network design, and wishes to learn the corresponding practices for
IPv6. IPv6.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Mix IPv4 and IPv6 on the Same Layer-3 Interface? . . 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.1.2. Interfaces with Only Link-Local Addresses? . . . . . 4
2.2. Static Routes . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Static Routes . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Link-Local Next-Hop in a Static Route? . . . . . . . 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.3.1. IGP Choice . . . . . . . . . . . . . . . . . . . . . 7
2.4. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1. Which Transport for Which Routes? . . . . . . . . . . 8 2.4.1. Which Transport for Which Routes? . . . . . . . . . . 8
2.4.1.1. BGP Sessions for Unlabeled Routes . . . . . . . . 10 2.4.1.1. BGP Sessions for Unlabeled Routes . . . . . . . . 10
2.4.1.2. BGP sessions for Labeled or VPN Routes . . . . . 11 2.4.1.2. BGP sessions for Labeled or VPN Routes . . . . . 11
2.4.2. eBGP Endpoints: Global or Link-Local Addresses? . . . 11 2.4.2. eBGP Endpoints: Global or Link-Local Addresses? . . . 11
3. General Observations . . . . . . . . . . . . . . . . . . . . 12 3. General Observations . . . . . . . . . . . . . . . . . . . . 12
3.1. Use of Link-Local Addresses . . . . . . . . . . . . . . . 12 3.1. Use of Link-Local Addresses . . . . . . . . . . . . . . . 12
3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 13 3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 4, line 32 skipping to change at page 4, line 32
support for IPv6 matures, making option (b) less and less attractive support for IPv6 matures, making option (b) less and less attractive
until the day that IPv4 is finally turned off. until the day that IPv4 is finally turned off.
2.1.2. Interfaces with Only Link-Local Addresses? 2.1.2. Interfaces with Only Link-Local Addresses?
As noted in the introduction, this document does not cover the ins As noted in the introduction, this document does not cover the ins
and outs around creating an IPv6 addressing plan. However, there is and outs around creating an IPv6 addressing plan. However, there is
one fundamental question in this area that often arises: Should an one fundamental question in this area that often arises: Should an
interface: 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 b. Have global and/or unique-local addresses assigned in addition to
the link-local? the link-local?
There are two advantages in interfaces with only link-local addresses There are two advantages in interfaces with only link-local addresses
("unnumbered interfaces"). The first advantage is ease of ("link-local-only interfaces"). The first advantage is ease of
configuration. In a network with a large number of unnumbered configuration. In a network with a large number of link-local-only
interfaces, the operator can just enable an IGP on each router, interfaces, the operator can just enable an IGP on each router,
without going through the tedious process of assigning and tracking without going through the tedious process of assigning and tracking
the addresses for each interface. The second advantage is security. the addresses for each interface. The second advantage is security.
Since packets with Link-Local destination addresses should not be Since packets with Link-Local destination addresses should not be
routed, it is very difficult to attack the associated nodes from an routed, it is very difficult to attack the associated nodes from an
off-link device. This implies less effort around maintaining off-link device. This implies less effort around maintaining
security ACLs. security ACLs.
Countering this advantage are various disadvantages to interfaces Countering this advantage are various disadvantages to link-local-
with only link-local addresses: only interfaces:
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.
Thus, to troubleshoot, one must typically log into a device that o It is not possible to ping a link-local-only interface from a
is directly attached to the device in question, and execute the device that is not directly attached to the link. Thus, to
ping from there. 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 o A traceroute passing over the link-local-only interface will
loopback or system address of the router, rather than the address return the loopback or system address of the router, rather than
of the interface itself. the address of the interface itself.
o In cases of parallel point to point links it is difficult to o In cases of parallel point to point links it is difficult to
determine which of the parallel links was taken when attempting to determine which of the parallel links was taken when attempting to
troubleshoot unless one sends packets directly between the two troubleshoot unless one sends packets directly between the two
attached link-locals on the specific interfaces. Since many attached link-locals on the specific interfaces. Since many
network problems behave differently for traffic to/from a router network problems behave differently for traffic to/from a router
than for traffic through the router(s) in question, this can pose than for traffic through the router(s) in question, this can pose
a significant hurdle to some troubleshooting scenarios. a significant hurdle to some troubleshooting scenarios.
o On some routers, by default the link-layer address of the o On some routers, by default the link-layer address of the
skipping to change at page 5, line 52 skipping to change at page 6, line 5
because the MAC address is duplicated (due to manufacturing process because the MAC address is duplicated (due to manufacturing process
defaults or the use of virtualization), because a device deliberately defaults or the use of virtualization), because a device deliberately
re-uses automatically-assigned link-local addresses on different re-uses automatically-assigned link-local addresses on different
links, or because an operator manually assigns the same easy-to-type links, or because an operator manually assigns the same easy-to-type
link-local address to multiple interfaces. All these are allowed in link-local address to multiple interfaces. All these are allowed in
IPv6 as long as the addresses are used on different links. IPv6 as long as the addresses are used on different links.
For more discussion on the pros and cons, see [RFC7404]. See also For more discussion on the pros and cons, see [RFC7404]. See also
[RFC5375] for IPv6 unicast address assignment considerations. [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. Static Routes
2.2.1. Link-Local Next-Hop in a Static Route? 2.2.1. Link-Local Next-Hop in a Static Route?
For the most part, the use of static routes in IPv6 parallels their For the most part, the use of static routes in IPv6 parallels their
use in IPv4. There is, however, one exception, which revolves around use in IPv4. There is, however, one exception, which revolves around
the choice of next-hop address in the static route. Specifically, the choice of next-hop address in the static route. Specifically,
should an operator: should an operator:
 End of changes. 10 change blocks. 
20 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/