draft-ietf-v6ops-design-choices-02.txt   draft-ietf-v6ops-design-choices-03.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: March 8, 2015 Dyn Expires: March 22, 2015 Dyn
September 4, 2014 September 18, 2014
Design Choices for IPv6 Networks Design Choices for IPv6 Networks
draft-ietf-v6ops-design-choices-02 draft-ietf-v6ops-design-choices-03
Abstract Abstract
This document presents advice on the design choices that arise when This document presents advice on the design choices that arise when
designing IPv6 networks (both dual-stack and IPv6-only). The designing IPv6 networks (both dual-stack and IPv6-only). The
intended audience is someone designing an IPv6 network who is intended audience is someone designing an IPv6 network who is
knowledgeable about best current practices around IPv4 network knowledgeable about best current practices around IPv4 network
design, and wishes to learn the corresponding practices for IPv6. design, and wishes to learn the corresponding practices for IPv6.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 March 8, 2015. This Internet-Draft will expire on March 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 5, line 32 skipping to change at page 5, line 32
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.
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 not often not possible to identify the interface or link (in o It is often not possible to identify the interface or link (in a
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.
It should be noted that it is quite possible for the same link-local It should be noted that it is quite possible for the same link-local
address to be assigned to multiple interfaces. This can happen address to be assigned to multiple interfaces. This can happen
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 For more discussion on the pros and cons, see
[I-D.ietf-opsec-lla-only]. [I-D.ietf-opsec-lla-only]. See also [RFC5375] for IPv6 unicast
address assignment considerations.
Today, most operators use numbered links (option b). Today, most operators use numbered links (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?
What form of next-hop address should one use in a static route? What form of next-hop address should one use in a static route?
a. Use the far-end's link-local address as the next-hop address, OR a. Use the far-end's link-local address as the next-hop address, OR
skipping to change at page 6, line 48 skipping to change at page 6, line 48
Furthermore, many network operators are concerned about the Furthermore, many network operators are concerned about the
dependency of the default link-local address on an underlying MAC dependency of the default link-local address on an underlying MAC
address, as described in the previous section. address, as described in the previous section.
Today most operators use GUAs as next-hop addresses. Today most operators use GUAs as next-hop addresses.
2.3. IGPs 2.3. IGPs
2.3.1. IGP Choice 2.3.1. IGP Choice
One of the main decisions for an IPv6 implementor is the choice of One of the main decisions for an IPv6 implementer is the choice of
IGP (Interior Gateway Protocol) within the network. The primary IGP (Interior Gateway Protocol) within the network. The primary
choices are the IETF protocols of RIP [RFC2080], OSPF [RFC2328] choices are the IETF protocols of RIP [RFC2080], OSPF [RFC2328]
[RFC5340] and IS-IS [RFC5120] [RFC5308], though some operators may [RFC5340] and IS-IS [RFC5120] [RFC5308], though some operators may
consider non-IETF protocols. Here we limit our discussion to the consider non-IETF protocols. Here we limit our discussion to the
pros and cons of OSPF vs. IS-IS. pros and cons of OSPF vs. IS-IS.
Considering just OSPF vs. IS-IS, the discussion in this section Considering just OSPF vs. IS-IS, the discussion in this section
revolves around the options in the table below: revolves around the options in the table below:
+--------+--------+---------+---------+------------+----------------+ +--------+--------+---------+---------+------------+----------------+
 End of changes. 6 change blocks. 
8 lines changed or deleted 9 lines changed or added

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