draft-ietf-v6ops-design-choices-04.txt   draft-ietf-v6ops-design-choices-05.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 22, 2015 Dyn Expires: August 26, 2015 Dyn
February 18, 2015 February 22, 2015
Some Design Choices for IPv6 Networks Some Design Choices for IPv6 Networks
draft-ietf-v6ops-design-choices-04 draft-ietf-v6ops-design-choices-05
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 22, 2015. This Internet-Draft will expire on August 26, 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 3, line 6 skipping to change at page 3, line 6
such consensus exists. such consensus exists.
This document does not present advice on strategies for adding IPv6 This document does not present advice on strategies for adding IPv6
to a network, nor does it discuss transition mechanisms. For advice to a network, nor does it discuss transition mechanisms. For advice
in these areas, see [RFC6180] for general advice, [RFC6782] for in these areas, see [RFC6180] for general advice, [RFC6782] for
wireline service providers, [RFC6342] for mobile network providers, wireline service providers, [RFC6342] for mobile network providers,
[RFC5963] for exchange point operators, [RFC6883] for content [RFC5963] for exchange point operators, [RFC6883] for content
providers, and both [RFC4852] and [RFC7381] for enterprises. Nor providers, and both [RFC4852] and [RFC7381] for enterprises. Nor
does this document discuss the particulars of creating an IPv6 does this document discuss the particulars of creating an IPv6
addressing plan; for advice in this area, see [RFC5375] or addressing plan; for advice in this area, see [RFC5375] or
[v6-addressing-plan]. The use of ULAs instead of globally-routed [v6-addressing-plan]. The details of ULA usage is also not
addresses is also not discussed; for this the reader is referred to discussed; for this the reader is referred to
[I-D.ietf-v6ops-ula-usage-recommendations]. [I-D.ietf-v6ops-ula-usage-recommendations].
Finally, this document focuses on unicast routing design only and Finally, this document focuses on unicast routing design only and
does not cover multicast or the issues involved in running MPLS over does not cover multicast or the issues involved in running MPLS over
IPv6 transport. IPv6 transport.
2. Design Choices 2. Design Choices
Each subsection below presents a design choice and discusses the pros Each subsection below presents a design choice and discusses the pros
and cons of the various options. If there is consensus in the and cons of the various options. If there is consensus in the
skipping to change at page 4, line 34 skipping to change at page 4, line 34
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 the
interface: interface:
a. Use only link-local addresses ("unnumbered"), OR a. Use only link-local addresses ("unnumbered"), OR
b. Have global (or unique-local) addresses assigned in addition to b. Have global and/or unique-local) addresses assigned in addition
link-locals? to link-locals?
There are two advantages of unnumbered interfaces. The first There are two advantages of unnumbered interfaces. The first
advantage is ease of configuration. In a network with a large number advantage is ease of configuration. In a network with a large number
of unnumbered interfaces, the operator can just enable an IGP on each of unnumbered interfaces, the operator can just enable an IGP on each
router, without going through the tedious process of assigning and router, without going through the tedious process of assigning and
tracking the addresses for each interface. The second advantage is tracking the addresses for each interface. The second advantage is
security. Since packets with link-local destination addresses should security. Since packets with link-local destination addresses should
not be routed, it is very difficult to attack the associated not be routed, it is very difficult to attack the associated
interfaces from an off-link device. This implies less effort around interfaces from an off-link device. This implies less effort around
maintaining security ACLs. maintaining security ACLs.
skipping to change at page 5, line 19 skipping to change at page 5, line 19
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.
o On some devices, by default the link-layer address of the o On some routers, by default the link-layer address of the
interface is derived from the MAC address assigned to interface. interface is derived from the MAC address assigned to interface.
When this is done, swapping out the interface hardware (e.g. When this is done, swapping out the interface hardware (e.g.
interface card) will cause the link-layer address to change. In interface card) will cause the link-layer address to change. In
some cases (peering config, ACLs, etc) this may require additional some cases (peering config, ACLs, etc) this may require additional
changes. However, many devices allow the link-layer address of an changes. However, many devices allow the link-layer address of an
interface to be explicitly configured, which avoids this issue. interface to be explicitly configured, which avoids this issue.
This problem should fade away over time as more and more routers
select interface identifiers according to the rules in [RFC7217].
o The practice of naming router interfaces using DNS names is o The practice of naming router interfaces using DNS names is
difficult and not recommended when using link-locals only. More difficult and not recommended when using link-locals only. More
generally, it is not recommended to put link-local addresses into generally, it is not recommended to put link-local addresses into
DNS; see [RFC4472]. DNS; see [RFC4472].
o It is often not possible to identify the interface or link (in a o It is often not possible to identify the interface or link (in a
database, email, etc) by giving just its address without also database, email, etc) by giving just its address without also
specifying the link in some manner. specifying the link in some manner.
skipping to change at page 17, line 15 skipping to change at page 17, line 15
[RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 [RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6
Deployment", RFC 6342, August 2011. Deployment", RFC 6342, August 2011.
[RFC6782] Kuarsingh, V. and L. Howard, "Wireline Incremental IPv6", [RFC6782] Kuarsingh, V. and L. Howard, "Wireline Incremental IPv6",
RFC 6782, November 2012. RFC 6782, November 2012.
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content Providers and Application Service Providers", RFC Content Providers and Application Service Providers", RFC
6883, March 2013. 6883, March 2013.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014.
[RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
Guidelines", RFC 7381, October 2014. Guidelines", RFC 7381, October 2014.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404, November Addressing inside an IPv6 Network", RFC 7404, November
2014. 2014.
[v6-addressing-plan] [v6-addressing-plan]
SurfNet, "Preparing an IPv6 Address Plan", 2013, SurfNet, "Preparing an IPv6 Address Plan", 2013,
 End of changes. 8 change blocks. 
9 lines changed or deleted 15 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/