draft-ietf-v6ops-design-choices-05.txt   draft-ietf-v6ops-design-choices-06.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: August 26, 2015 Dyn Expires: September 10, 2015 Dyn
February 22, 2015 March 9, 2015
Some Design Choices for IPv6 Networks Some Design Choices for IPv6 Networks
draft-ietf-v6ops-design-choices-05 draft-ietf-v6ops-design-choices-06
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 August 26, 2015. This Internet-Draft will expire on September 10, 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 4, line 29 skipping to change at page 4, line 29
support today for individual statistics on IPv4 traffic vs IPv6 support today for individual statistics on IPv4 traffic vs IPv6
traffic when option (a) is used. Other, device-specific, limitations traffic when option (a) is used. Other, device-specific, limitations
exist as well. It is expected that these limitations will go away as exist as well. It is expected that these limitations will go away as
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 the one fundamental question in this area that often arises: Should an
interface: interface:
a. Use only link-local addresses ("unnumbered"), OR a. Use only a link-local address ("unnumbered"), OR
b. Have global and/or unique-local) addresses assigned in addition b. Have global and/or unique-local addresses assigned in addition to
to link-locals? the link-local?
There are two advantages of unnumbered interfaces. The first There are two advantages in interfaces with only link-local addresses
advantage is ease of configuration. In a network with a large number ("unnumbered interfaces"). The first advantage is ease of
of unnumbered interfaces, the operator can just enable an IGP on each configuration. In a network with a large number of unnumbered
router, without going through the tedious process of assigning and interfaces, the operator can just enable an IGP on each router,
tracking the addresses for each interface. The second advantage is without going through the tedious process of assigning and tracking
security. Since packets with link-local destination addresses should the addresses for each interface. The second advantage is security.
not be routed, it is very difficult to attack the associated Since packets with Link-Local destination addresses should not be
interfaces from an off-link device. This implies less effort around routed, it is very difficult to attack the associated nodes from an
maintaining security ACLs. off-link device. This implies less effort around maintaining
security ACLs.
Countering this advantage are various disadvantages to unnumbered Countering this advantage are various disadvantages to interfaces
interfaces in IPv6: with only link-local addresses:
o It is not possible to ping an interface that has only a link-local 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. address from a device that is not directly attached to the link.
Thus, to troubleshoot, one must typically log into a device that Thus, to troubleshoot, one must typically log into a device that
is directly attached to the device in question, and execute the is directly attached to the device in question, and execute the
ping from there. ping from there.
o A traceroute passing over the unnumbered link will return the o A traceroute passing over the unnumbered interface will return the
loopback or system address of the router, rather than the address loopback or system address of the router, rather than the address
of the interface itself. 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.
 End of changes. 10 change blocks. 
20 lines changed or deleted 22 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/