|Router|----|Router|----\|Router|--|--|Switch|--
| | | | | | | | |--
+------+ /+------+ +------+ | +------+
| / | |
+-------+/ +-------+ |
| | | |
|Access1| |Access2|
| | | |
+-------+ +-------+
||||| ||||| ISP Network
----|-----------|----------------------
| | Customer Networks
+--------+ +--------+
| | | |
|Customer| |Customer|
| | | |
+--------+ +--------+
Figure 3: ISP Sample Network Layout
9.1. Example 1
Example 1 presents a network built according to the sample network
layout with a native IPv4 backbone. The backbone is running IS-IS
and IBGP as routing protocols for internal and external routes,
respectively. Multiprotocol BGP is used to exchange routes over the
connections to ISP2 and the exchange point. Multicast using PIM-SM
routing is present. QoS using DiffServ is deployed.
Access 1 is xDSL connected to the backbone through an access router.
The xDSL equipment, except for the access router, is considered to be
layer 2 only, e.g., Ethernet or ATM. IPv4 addresses are dynamically
assigned to the customer with DHCP. No routing information is
exchanged with the customer. Access control and traceability are
performed in the access router. Customers are separated into VLANs
or separate ATM PVCs up to the access router.
Access 2 is "fiber to the building or home" (FTTB/H) connected
directly to the backbone router. This connection is considered
layer-3-aware, because it uses layer 3 switches and performs access
control and traceability through its layer 3 awareness by using DHCP
snooping. IPv4 addresses are dynamically assigned to the customers
with DHCP. No routing information is exchanged with the customer.
The actual IPv6 deployment might start by enabling IPv6 on a couple
of backbone routers, configuring tunnels between them (if not
adjacent) and connecting to a few peers or upstream providers (either
through tunnels or at an internet exchange).
After a trial period, the rest of the backbone is upgraded to dual-
stack, and IS-IS, without multi-topology extensions (the upgrade
order is considered with care), is used as an IPv6 and IPv4 IGP.
During an upgrade until IPv6 customers are connected behind a
backbone router, the convexity requirement is not critical: The
routers will just not be reachable with IPv6. Software supporting
IPv6 could be installed even though the routers would not be used for
(customer) IPv6 traffic yet. That way, IPv6 could be enabled in the
backbone as needed.
Separate IPv6 BGP sessions are built similarly to IPv4. Multicast
(through SSM and Embedded-RP) and DiffServ are offered at a later
phase of the network, e.g., after a year of stable IPv6 unicast
operations.
Offering native service as quickly as possible is important. In the
meantime, however, a 6to4 relay may be provided in the meantime for
optimized 6to4 connectivity and may also be combined with a tunnel
broker for extended functionality. Operating as bridges at Layer 2
only, xDSL equipment does not require changes in CPE: IPv6
connectivity can be offered to the customers by upgrading the PE
router to IPv6. In the initial phase, only Router Advertisements are
used; DHCPv6 Prefix Delegation can be added as the next step if no
other mechanisms are available.
The FTTB/H access has to be upgraded to support access control and
traceability in the switches, probably by using DHCP snooping or a
similar IPv6 capability, but it also has to be compatible with prefix
delegation, not just address assignment. This could, however, lead
to the necessity to use DHCPv6 for address assignment.
9.2. Example 2
In example 2, the backbone is running IPv4 with MPLS and is using
OSPF and IBGP for internal and external routes, respectively. The
connections to ISP2 and the exchange point run BGP to exchange
routes. Multicast and QoS are not deployed.
Access 1 is a fixed line, e.g., fiber, connected directly to the
backbone. Routing information is in some cases exchanged with CPE at
the customer’s site; otherwise static routing is used. Access 1 can
also be connected to a BGP/MPLS-VPN running in the backbone.
Access 2 is xDSL connected directly to the backbone router. The xDSL
is layer 2 only, and access control and traceability are achieved
through PPPoE/PPPoA. PPP also provides address assignment. No
routing information is exchanged with the customer.
IPv6 deployment might start with an upgrade of a couple of PE routers
to support [BGPTUNNEL], as this will allow large-scale IPv6 support
without hardware or software upgrades in the core. In a later phase,
native IPv6 traffic or IPv6 LSPs would be used in the whole network.
In this case, IS-IS or OSPF could be used for the internal routing,
and a separate IPv6 BGP session would be run.
For the fixed-line customers, the CPE has to be upgraded, and prefix
delegation using DHCPv6 or static assignment would be used. An IPv6
MBGP session would be used when routing information has to be
exchanged. In the xDSL case, the same conditions for IP-tunneling
apply as in Example 1. In addition to IP-tunneling, a PPP session
can be used to offer IPv6 access to a limited number of customers.
Later, when clients and servers have been updated, the IPv6 PPP
session can be replaced with a combined PPP session for both IPv4 and
IPv6. PPP has to be used for address and prefix assignment.
9.3. Example 3
A transit provider offers IP connectivity to other providers, but not
to end users or enterprises. IS-IS and IBGP are used internally, and
BGP is used externally. Its accesses connect Tier-2 provider cores.
No multicast or QoS is used.
As this type of transit provider has a number of customers, who have
a large number of customers in turn, it obtains an address allocation
from an RIR. The whole backbone can be upgraded to dual-stack in a
reasonably short time after a trial with a couple of routers. IPv6
routing is performed by using the same IS-IS process and separate
IPv6 BGP sessions.
The ISP provides IPv6 transit to its customers for free, as a
competitive advantage. It also provides, at the first phase only, a
configured tunnel service with BGP peering to the significant sites
and customers (those with an AS number) who are the customers of its
customers whenever its own customer networks are not offering IPv6.
This is done both to introduce them to IPv6 and to create a
beneficial side effect: A bit of extra revenue is generated from its
direct customers as the total amount of transited traffic grows.
10. Security Considerations
This document analyzes scenarios and identifies transition mechanisms
that could be used for the scenarios. It does not introduce any new
security issues. Security considerations of each mechanism are
described in the respective documents.
However, a few generic observations are in order.
o Introducing IPv6 adds new classes of security threats or
requires adopting new protocols or operational models than
those for IPv4; typically these are generic issues, to be
discussed further in other documents, for example, [V6SEC].
o The more complex the transition mechanisms employed become, the
more difficult it will be to manage or analyze their impact on
security. Consequently, simple mechanisms are preferable.
o This document has identified a number of requirements for
analysis or further work that should be explicitly considered
when adopting IPv6: how to perform access control over shared
media or shared ISP customer connection media, how to manage
the configuration management security on such environments
(e.g., DHCPv6 authentication keying), and how to manage
customer traceability if stateless address autoconfiguration is
used.
11. Acknowledgments
This document has greatly benefited from input by Marc Blanchet,
Jordi Palet, Francois Le Faucheur, Ronald van der Pol, and Cleve
Mickles.
Special thanks to Richard Graveman and Michael Lambert for
proofreading the document.
12. Informative References
[EMBEDRP] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", RFC
3956, November 2004.
[MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M-ISIS:
Multi Topology (MT) Routing in IS-IS", Work in
Progress.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June
2000.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
March 1999.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6
Site-Multihoming Architectures", RFC 3582, August
2003.
[RFC3178] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at
Site Exit Routers", RFC 3178, October 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[BGPTUNNEL] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le
Faucheur, F., "Connecting IPv6 Islands across IPv4
Clouds with BGP", Work in Progress.
[DUAL-ACCESS] Shirasaki, Y., Miyakawa, S., Yamasaki, T., Takenouchi,
A., "A Model of IPv6/IPv4 Dual Stack Internet Access
Service", Work in Progress.
[STEP] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment
Procedure (STEP)", Work in Progress.
[TSP] Blanchet, M., "IPv6 Tunnel Broker with Tunnel Setup
Protocol (TSP)", Work in Progress.
[TUNREQS] Palet, J., Nielsen, K., Parent, F., Durand, A.,
Suryanarayanan, R., and P. Savola, "Goals for
Tunneling Configuration", Work in Progress, February
2005.
[UNMANEVA] Huitema, C., Austein, R., Satapati, S., van der Pol,
R., "Evaluation of Transition Mechanisms for Unmanaged
Networks", Work in Progress.
[PROTO41] Palet, J., Olvera, C., Fernandez, D., "Forwarding
Protocol 41 in NAT Boxes", Work in Progress.
[V6SEC] Savola, P., "IPv6 Transition/Co-existence Security
Considerations", Work in Progress.
[DNSGUIDE] Durand, A., Ihren, J., "DNS IPv6 transport operational
guidelines", Work in Progress.
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", Work in Progress.
Appendix A: Convexity Requirements in Single Topology IS-IS
The single-topology IS-IS convexity requirements could be summarized,
from IPv4/6 perspective, as follows:
1) "any IP-independent path from an IPv4 router to any other IPv4
router must only go through routers which are IPv4-capable", and
2) "any IP-independent path from an IPv6 router to any other IPv6
router must only go through routers which are IPv6-capable".
As IS-IS is based upon CLNS, these are not trivially accomplished.
The single-topology IS-IS builds paths which are agnostic of IP
versions.
Consider an example scenario of three IPv4/IPv6-capable routers and
an IPv4-only router:
cost 5 R4 cost 5
,------- [v4/v6] -----.
/ \
[v4/v6] ------ [ v4 ] -----[v4/v6]
R1 cost 3 R3 cost 3 R2
Here the second requirement would not hold. IPv6 packets from R1 to
R2 (or vice versa) would go through R3, which does not support IPv6,
and the packets would get discarded. By reversing the costs between
R1-R3, R3-R2 and R1-R4,R4-R2 the traffic would work in the normal
case, but if a link fails and the routing changes to go through R3,
the packets would start being discarded again.
Authors’ Addresses
Mikael Lind
TeliaSonera
Vitsandsgatan 9B
SE-12386 Farsta, Sweden
EMail: mikael.lind@teliasonera.com
Vladimir Ksinant
Thales Communications
160, boulevard de Valmy
92704 Colombes, France
EMail: vladimir.ksinant@fr.thalesgroup.com
Soohong Daniel Park
Mobile Platform Laboratory, SAMSUNG Electronics.
416, Maetan-3dong, Paldal-Gu,
Suwon, Gyeonggi-do, Korea
EMail: soohong.park@samsung.com
Alain Baudot
France Telecom R&D Division
42, rue des coutures
14066 Caen - FRANCE
EMail: alain.baudot@francetelecom.com
Pekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fi
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.