draft-ietf-v6ops-isp-scenarios-analysis-02.txt   draft-ietf-v6ops-isp-scenarios-analysis-03.txt 
Internet Draft M. Lind Internet Draft M. Lind
<draft-ietf-v6ops-isp-scenarios-analysis-02.txt> TeliaSonera <draft-ietf-v6ops-isp-scenarios-analysis-03.txt> TeliaSonera
V. Ksinant V. Ksinant
Thales Communications Thales
Communications
S. Park S. Park
Samsung Electronics Samsung Electronics
A. Baudot A. Baudot
France Telecom France Telecom
P. Savola P. Savola
CSC/Funet CSC/Funet
Expires: December 2004 June 2004
Expires: October 2004 April 2004
Scenarios and Analysis for Introducing IPv6 into ISP Networks Scenarios and Analysis for Introducing IPv6 into ISP Networks
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 a "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
Abstract Abstract
This document first describes different scenarios for the This document first describes different scenarios for the
introduction of IPv6 into an ISP's existing IPv4 network without introduction of IPv6 into an ISP's existing IPv4 network without
disrupting the IPv4 service. Then, this document analyses these disrupting the IPv4 service. Then, the scenarios for introducing IPv6
scenarios and evaluates the relevance of the already defined are analyzed and the relevance of already defined transition
transition mechanisms in this context. Known challenges are also mechanisms are evaluated. Known challenges are also identified.
identified.
Table of Contents Table of Contents
1. Introduction................................................2 1. Introduction................................................2
1.1 Goal and Scope of the Document...........................2 1.1 Goal and Scope of the Document...........................2
2. Brief Description of a Generic ISP Network..................3 2. Brief Description of a Generic ISP Network..................3
3. Transition Scenarios........................................4 3. Transition Scenarios........................................4
3.1 Identification of Stages and Scenarios...................4 3.1 Identification of Stages and Scenarios...................4
3.2 Stages...................................................5 3.2 Stages...................................................5
3.2.1 Stage 1 Scenarios: Launch..............................5 3.2.1 Stage 1 Scenarios: Launch..............................5
3.2.2 Stage 2a Scenarios: Backbone...........................6 3.2.2 Stage 2a Scenarios: Backbone...........................6
3.2.3 Stage 2b Scenarios: Customer Connection................6 3.2.3 Stage 2b Scenarios: Customer Connection................6
3.2.4 Stage 3 Scenarios: Complete............................6 3.2.4 Stage 3 Scenarios: Complete............................7
3.2.5 Stages 2a and 3: Combination Scenarios.................7 3.2.5 Stages 2a and 3: Combination Scenarios.................7
3.3 Transition Scenarios.....................................7 3.3 Transition Scenarios.....................................7
3.4 Actions Needed When Deploying IPv6 in an ISP's network...7 3.4 Actions Needed When Deploying IPv6 in an ISP's network...8
4. Backbone Transition Actions.................................8 4. Backbone Transition Actions.................................9
4.1 Steps in the Transition of Backbone Networks.............8 4.1 Steps in the Transition of Backbone Networks.............9
4.1.1 MPLS Backbone..........................................9 4.1.1 MPLS Backbone.........................................10
4.2 Configuration of Backbone Equipment.....................10 4.2 Configuration of Backbone Equipment.....................10
4.3 Routing.................................................10 4.3 Routing.................................................10
4.3.1 IGP...................................................10 4.3.1 IGP...................................................11
4.3.2 EGP...................................................12 4.3.2 EGP...................................................12
4.3.3 Transport of Routing Protocols........................12 4.3.3 Transport of Routing Protocols........................12
4.4 Multicast...............................................12 4.4 Multicast...............................................13
5. Customer Connection Transition Actions.....................12 5. Customer Connection Transition Actions.....................13
5.1 Steps in the Transition of Customer Connection Networks.12 5.1 Steps in the Transition of Customer Connection Networks.13
5.1.1 Small end sites.......................................14 5.1.1 Small end sites.......................................14
5.1.2 Large end sites.......................................14 5.1.2 Large end sites.......................................15
5.2 User Authentication/Access Control Requirements.........15 5.2 User Authentication/Access Control Requirements.........15
5.3 Configuration of Customer Equipment.....................15 5.3 Configuration of Customer Equipment.....................16
5.4 Requirements for Traceability...........................16 5.4 Requirements for Traceability...........................16
5.5 Ingress Filtering in the Customer Connection Network....16 5.5 Ingress Filtering in the Customer Connection Network....17
5.6 Multihoming.............................................16 5.6 Multihoming.............................................17
5.7 Quality of Service......................................17 5.7 Quality of Service......................................17
6. Network and Service Operation Actions......................17 6. Network and Service Operation Actions......................18
7. Future Stages..............................................18 7. Future Stages..............................................18
8. Example Networks...........................................18 8. Requirements for Follow-On Work............................19
8.1 Example 1...............................................19 9. Example Networks...........................................19
8.2 Example 2...............................................21 9.1 Example 1...............................................20
8.3 Example 3...............................................21 9.2 Example 2...............................................22
9. Security Considerations....................................22 9.3 Example 3...............................................22
10. Acknowledgements...........................................22 10. Security Considerations....................................23
11. Informative References.....................................22 11. Acknowledgements...........................................23
12. Informative References.....................................24
1. Introduction 1. Introduction
1.1 Goal and Scope of the Document 1.1 Goal and Scope of the Document
When an ISP deploys IPv6, its goal is to provide IPv6 connectivity When an ISP deploys IPv6, its goal is to provide IPv6 connectivity
and global address space to its customers. The new IPv6 service must and global address space to its customers. The new IPv6 service must
be added to an already existing IPv4 service, and the introduction of be added to an already existing IPv4 service, and the introduction of
IPv6 must not interrupt this IPv4 service. IPv6 must not interrupt this IPv4 service.
An ISP offering IPv4 service will find different ways to add IPv6 to An ISP offering IPv4 service will find different ways to add IPv6 to
this service. This document discusses a small set of scenarios for this service. This document discusses a small set of scenarios for
the introduction of IPv6 into an ISP's IPv4 network. It evaluates the the introduction of IPv6 into an ISP's IPv4 network. It evaluates the
relevance of the existing transition mechanisms in the context of relevance of the existing transition mechanisms in the context of
these deployment scenarios, and points out the lack of essential these deployment scenarios, and points out the lack of essential
functionality in these methods to the ISP's operation of an IPv6 functionality in these methods to the ISP's operation of an IPv6
service. service.
The present document is focused on services that include both IPv6 The document is focused on services that include both IPv6 and IPv4
and IPv4 and does not cover issues surrounding IPv6-only service. and does not cover issues surrounding IPv6-only service. It is also
It is also outside the scope of this document to describe different outside the scope of this document to describe different types of
types of access or network technologies. access or network technologies.
2. Brief Description of a Generic ISP Network 2. Brief Description of a Generic ISP Network
A generic network topology for an ISP can be divided into two main A generic network topology for an ISP can be divided into two main
parts: the backbone network and customer connection networks. It parts: the backbone network and customer connection networks. It
includes, in addition to these, some other building blocks such as includes, in addition to these, some other building blocks such as
network and service operations. The additional building blocks used network and service operations. The additional building blocks used
in this document are defined as follows: in this document are defined as follows:
"CPE" : Customer Premises Equipment "CPE" : Customer Premises Equipment
skipping to change at page 4, line 23 skipping to change at page 4, line 23
devices or one involving non-IP technology), this constraint may devices or one involving non-IP technology), this constraint may
result in architectural considerations relevant to this document. result in architectural considerations relevant to this document.
The basic components in the ISP's network are depicted in Figure 1. The basic components in the ISP's network are depicted in Figure 1.
------------ ---------- ------------ ----------
| Network and| | | | Network and| | |
| Service |--| Backbone | | Service |--| Backbone |
| Operation | | |\ | Operation | | |\
------------ ---------- \ ------------ ---------- \
. / | \ \ / | \ \
. / | \ \_Peering( Direct and IX ) / | \ \_Peering( Direct and
. / | \ / | \ exchange points)
. / | \ / | \
. / | \ / | \
---------- / ---------- \ ---------- ---------- / ---------- \ ----------
| Customer | / | Customer | \ | Customer | | Customer | / | Customer | \ | Customer |
|Connection|--/ |Connection| \--|Connection| |Connection|--/ |Connection| \--|Connection|
| 1 | | 2 | | 3 | | 1 | | 2 | | 3 |
---------- ---------- ---------- ---------- ---------- ----------
| | | ISP's Network | | | ISP's Network
------------------------------------------------------- -------------------------------------------------------
| | | Customers' Networks | | | Customers' Networks
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | | | | | | | |
skipping to change at page 6, line 14 skipping to change at page 6, line 14
The first stage is an IPv4-only ISP with an IPv4 customer. This is The first stage is an IPv4-only ISP with an IPv4 customer. This is
the most common case today and the natural starting point for the the most common case today and the natural starting point for the
introduction of IPv6. From this stage, the ISP can move (undergo a introduction of IPv6. From this stage, the ISP can move (undergo a
transition) from Stage 1 to any other stage with the goal of offering transition) from Stage 1 to any other stage with the goal of offering
IPv6 to its customer. IPv6 to its customer.
The immediate first step consists of obtaining a prefix allocation The immediate first step consists of obtaining a prefix allocation
(typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC, (typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC,
ARIN, LACNIC, RIPE, ...) according to allocation procedures. ARIN, LACNIC, RIPE, ...) according to allocation procedures.
The ISP will also need to establish IPv6 connectivity to its upstream
providers and peers; it is of utmost importance to require IPv6
transit when negotiating IP transit deals with the upstream ISPs. If
the upstream is not providing IPv6 connectivity at the moment, it may
be possible to temporarily obtain connectivity from some other ISP
nearby, possibly using a short configured tunnel. However, the
longer-term goal must be requiring and obtaining IPv6 connectivity
from the transit ISPs, because otherwise the quality of IPv6
connectivity will likely be poor.
Connectivity to peers can be typically established either directly or
at Internet Exchange Points (IX). Most IXs are using techniques
where IPv6 is easy to use, and many IXs already provide
infrastructure for IPv6 peerings. Such peerings can be done natively
using IPv6. Peerings over IPv6-in-IPv4 tunnels is also possible but
not recommended at least in the long term. Direct connectivity to
peers may be feasible when there is direct connectivity to the peer
for IPv4.
3.2.2 Stage 2a Scenarios: Backbone 3.2.2 Stage 2a Scenarios: Backbone
Stage 2a deal with an ISP with IPv4-only customer connection networks Stage 2a deal with an ISP with IPv4-only customer connection networks
and a backbone that supports both IPv4 and IPv6. In particular, the and a backbone that supports both IPv4 and IPv6. In particular, the
ISP has the possibility of making the backbone IPv6-capable through ISP has the possibility of making the backbone IPv6-capable through
either software upgrades, hardware upgrades, or a combination of either software upgrades, hardware upgrades, or a combination of
both. both.
Since the customer connections have not yet been upgraded, a Since the customer connections have not yet been upgraded, a
tunneling mechanism has to be used to provide IPv6 connectivity tunneling mechanism has to be used to provide IPv6 connectivity
skipping to change at page 8, line 27 skipping to change at page 8, line 45
* Actions required for customer connection transition: * Actions required for customer connection transition:
- Connect IPv6 customers to an IPv6 backbone through an IPv4 - Connect IPv6 customers to an IPv6 backbone through an IPv4
network. network.
- Transform an IPv4 customer connection network into a dual- - Transform an IPv4 customer connection network into a dual-
stack one. stack one.
* Actions required for network and service operation transition: * Actions required for network and service operation transition:
- Set up IPv6 connectivity to upstream providers and peers.
- Configure IPv6 functions into network components. - Configure IPv6 functions into network components.
- Upgrade regular network management and monitoring - Upgrade regular network management and monitoring
applications to take IPv6 into account. applications to take IPv6 into account.
- Extend customer management (e.g., RADIUS) mechanisms - Extend customer management (e.g., RADIUS) mechanisms
to be able to supply IPv6 prefixes and other information to be able to supply IPv6 prefixes and other information
to customers. to customers.
- Enhance accounting, billing, etc. to work with IPv6 - Enhance accounting, billing, etc. to work with IPv6
skipping to change at page 9, line 9 skipping to change at page 9, line 27
In terms of physical equipment, backbone networks consist mainly of In terms of physical equipment, backbone networks consist mainly of
high-speed core and edge routers. Border routers provide peering high-speed core and edge routers. Border routers provide peering
with other providers. Filtering, routing policy, and policing with other providers. Filtering, routing policy, and policing
functions are generally managed on border routers. functions are generally managed on border routers.
In the beginning, an ISP has an IPv4-only backbone. In the end, the In the beginning, an ISP has an IPv4-only backbone. In the end, the
backbone is completely dual-stack. In between, intermediate steps may backbone is completely dual-stack. In between, intermediate steps may
be identified: be identified:
Tunnels Tunnels Tunnels Tunnels Dual Full
IPv4-only ----> or ---> or + DS -----> Full DS IPv4-only ----> or ---> or + Stack --> Dual Stack
dedicated IPv6 dedicated IPv6 routers dedicated IPv6 dedicated IPv6 routers
links links links links
Figure 2: Transition Path. Figure 2: Transition Path.
The first step involves tunnels or dedicated links but leaves The first step involves tunnels or dedicated links but leaves
existing routers unchanged. Only a small set of routers then have existing routers unchanged. Only a small set of routers then have
IPv6 capabilities. The use of configured tunnels is adequate during IPv6 capabilities. The use of configured tunnels is adequate during
this step. this step.
In the second step, some dual-stack routers are added, progressively, In the second step, some dual-stack routers are added, progressively,
skipping to change at page 10, line 10 skipping to change at page 10, line 29
forwarding support. forwarding support.
2) Require that MPLS networks support native routing and setting 2) Require that MPLS networks support native routing and setting
up of IPv6 LSPs, used for IPv6 connectivity. up of IPv6 LSPs, used for IPv6 connectivity.
3) Use only configured tunneling over IPv4 LSPs. 3) Use only configured tunneling over IPv4 LSPs.
4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation 4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation
for IPv6 connectivity. for IPv6 connectivity.
1) and 2) are clearly the best target approaches. However, 1) may Approaches 1) and 2) are clearly the best target approaches. However,
not be possible if the ISP is not willing to add IPv6 support in approach 1) may not be possible if the ISP is not willing to add IPv6
the network, or if the installed equipment is not capable of high support in the network, or if the installed equipment is not capable
performance native IPv6 forwarding. 2) may not be possible if the of high performance native IPv6 forwarding. Approach 2) may not be
ISP is not willing or able to add IPv6 LSP set-up support in the MPLS possible if the ISP is not willing or able to add IPv6 LSP set-up
control plane. support in the MPLS control plane.
Approach 4) can be used as an interim mechanism where other options Approach 4) can be used as an interim mechanism where other options
are unfeasible or undesirable for the reasons discussed above. are unfeasible or undesirable for the reasons discussed above.
Approach 3) is roughly equivalent to 4) except that it does not Approach 3) is roughly equivalent to approach 4) except that it does
require additional mechanisms but may lack scalability in the larger not require additional mechanisms but may lack scalability in the
networks especially if IPv6 is widely deployed. larger networks especially if IPv6 is widely deployed.
4.2 Configuration of Backbone Equipment 4.2 Configuration of Backbone Equipment
In the backbone, the number of devices is small and IPv6 In the backbone, the number of devices is small and IPv6
configuration mainly deals with routing protocol parameters, configuration mainly deals with routing protocol parameters,
interface addresses, loop-back addresses, ACLs, etc. interface addresses, loop-back addresses, access control lists, etc.
These IPv6 parameters need to be configured manually. These IPv6 parameters need to be configured manually.
4.3 Routing 4.3 Routing
ISPs need routing protocols to advertise reachability and to ISPs need routing protocols to advertise reachability and to
find the shortest working paths, both internally and externally. find the shortest working paths, both internally and externally.
Either OSPFv2 or IS-IS is typically used as the IPv4 IGP. RIPv2 is Either OSPFv2 or IS-IS is typically used as the IPv4 IGP. RIPv2 is
not usually used in service provider networks. BGP is the only IPv4 not usually used in service provider networks due to OSPF and IS-IS
EGP. Static routes also are used in both cases. being far superior IGPs. BGP is the only IPv4 EGP. Static routes also
are used in both cases.
Note that it is possible to configure a given network so that it Note that it is possible to configure a given network so that it
results in having an IPv6 topology different from its IPv4 topology. results in having an IPv6 topology different from its IPv4 topology.
For example, some links or interfaces may be dedicated to IPv4-only For example, some links or interfaces may be dedicated to IPv4-only
or IPv6-only traffic, or some routers may be dual-stack whereas or IPv6-only traffic, or some routers may be dual-stack whereas
others may be IPv4 or IPv6 only. In this case, routing protocols must others may be IPv4- or IPv6-only. In this case, routing protocols
be able to understand and cope with multiple topologies. must be able to understand and cope with multiple topologies.
4.3.1 IGP 4.3.1 IGP
Once the IPv6 topology has been determined, the choice of IPv6 IGP Once the IPv6 topology has been determined, the choice of IPv6 IGP
must be made: either OSPFv3 or IS-IS for IPv6. RIPng is not must be made: either OSPFv3 or IS-IS for IPv6. RIPng is not
appropriate in most contexts and is therefore not discussed here. The appropriate in most contexts, due to RIPv2 not being appropriate
IGP typically includes the routers' point-to-point and loop-back for IPv4 either, and is therefore not discussed here. The IGP
typically includes the routers' point-to-point and loop-back
addresses. addresses.
The most important decision is whether one wishes to have separate The most important decision is whether one wishes to have separate
routing protocol processes for IPv4 and IPv6. Separating them routing protocol processes for IPv4 and IPv6. Separating them
requires more memory and CPU for route calculations, e.g., when the requires more memory and CPU for route calculations, e.g., when the
links flap. On the other hand, separation provides a certain measure links flap. On the other hand, separation provides a certain measure
of assurance that if problems arise with IPv6 routing, they will not of assurance that if problems arise with IPv6 routing, they will not
affect the IPv4 routing protocol at all. In the initial phases, if affect the IPv4 routing protocol at all. In the initial phases, if
it is uncertain whether joint IPv4-IPv6 networking is working as it is uncertain whether joint IPv4-IPv6 networking is working as
intended, running separate processes may be desirable and easier to intended, running separate processes may be desirable and easier to
skipping to change at page 13, line 22 skipping to change at page 13, line 44
IPv6 services to its IPv4 customers. In addition, some ISPs may also IPv6 services to its IPv4 customers. In addition, some ISPs may also
choose to provide IPv6 service independently from the regular IPv4 choose to provide IPv6 service independently from the regular IPv4
service. service.
In any case, IPv6 service can be provided by using tunneling In any case, IPv6 service can be provided by using tunneling
techniques. The tunnel may terminate at the CPE corresponding to the techniques. The tunnel may terminate at the CPE corresponding to the
IPv4 service or in some other part of the customer's infrastructure IPv4 service or in some other part of the customer's infrastructure
(for instance, on IPv6-specific CPE or even on a host). (for instance, on IPv6-specific CPE or even on a host).
Several tunneling techniques have already been defined: configured Several tunneling techniques have already been defined: configured
tunnels with tunnel broker, 6to4, Teredo, etc. Some of them are based tunnels with tunnel broker, 6to4 [RFC3056], Teredo [TEREDO], etc.
on a specific addressing plan independent of the ISP's allocated Some of them are based on a specific addressing plan independent of
prefix(es), while some others use a part of the ISP's prefix. In most the ISP's allocated prefix(es), while some others use a part of the
cases using ISP's address space is preferable. ISP's prefix. In most cases using ISP's address space is preferable.
A key factor is the presence or absence of NATs between the two A key factor is the presence or absence of NATs between the two
tunnel end-points. In most cases, 6to4 and ISATAP are incompatible tunnel end-points. In most cases, 6to4 and ISATAP are incompatible
with NATs, and UDP encapsulation for configured tunnels has not been with NATs, and UDP encapsulation for configured tunnels has not been
specified. specified.
Dynamic and non-permanent IPv4 address allocation is another factor a Dynamic and non-permanent IPv4 address allocation is another factor a
tunneling technique may have to deal with. In this case the tunneling tunneling technique may have to deal with. In this case the tunneling
techniques may be more difficult to deploy at the ISP's end, techniques may be more difficult to deploy at the ISP's end,
especially if a protocol including authentication (like PPP for IPv6) especially if a protocol including authentication (like PPP for IPv6)
skipping to change at page 14, line 43 skipping to change at page 15, line 13
is not an option (e.g., due to dynamic IPv4 addressing), some form of is not an option (e.g., due to dynamic IPv4 addressing), some form of
automation has to be used. Basically, the options are either to automation has to be used. Basically, the options are either to
deploy an L2TP architecture (whereby the customers would run L2TP deploy an L2TP architecture (whereby the customers would run L2TP
clients and PPP over it to initiate IPv6 sessions) or to deploy a clients and PPP over it to initiate IPv6 sessions) or to deploy a
tunnel configuration service. The prime candidates for tunnel tunnel configuration service. The prime candidates for tunnel
configuration are STEP [STEP] and TSP [TSP], which both also work in configuration are STEP [STEP] and TSP [TSP], which both also work in
the presence of NATs. Neither is analyzed further in this document. the presence of NATs. Neither is analyzed further in this document.
5.1.2 Large end sites 5.1.2 Large end sites
Large end sites are usually running managed network. Large end sites usually have a managed network.
Dual-stack access service is often a realistic possibility since the Dual-stack access service is often a realistic possibility since the
customer network is managed (although CPE upgrades may be necessary). customer network is managed (although CPE upgrades may be necessary).
Configured tunnels, as-is, are a good solution when a NAT is not in Configured tunnels, as-is, are a good solution when a NAT is not in
the way and the IPv4 end-point addresses are static. In this the way and the IPv4 end-point addresses are static. In this
scenario, NAT traversal is not typically required. If fine-grained scenario, NAT traversal is not typically required. If fine-grained
access control is needed, an authentication protocol needs to be access control is needed, an authentication protocol needs to be
implemented. implemented.
skipping to change at page 15, line 41 skipping to change at page 16, line 13
access to the IPv6 services. access to the IPv6 services.
When a provider does not wish to give its IPv4 customers When a provider does not wish to give its IPv4 customers
automatic access to IPv6 services, specific IPv6 access control must automatic access to IPv6 services, specific IPv6 access control must
be performed in parallel with the IPv4 access control. This does not be performed in parallel with the IPv4 access control. This does not
imply that different user authentication must be performed for IPv6, imply that different user authentication must be performed for IPv6,
but merely that the authentication process may lead to different but merely that the authentication process may lead to different
results for IPv4 and IPv6 access. results for IPv4 and IPv6 access.
Access control traffic may use IPv4 or IPv6 transport. For instance, Access control traffic may use IPv4 or IPv6 transport. For instance,
Radius traffic related to IPv6 service can be transported over RADIUS [RADIUS] traffic related to IPv6 service can be transported
IPv4. over IPv4.
5.3 Configuration of Customer Equipment 5.3 Configuration of Customer Equipment
The customer connection networks are composed of PE and CPE(s). The customer connection networks are composed of PE and CPE(s).
Usually, each PE connects multiple CPE components to the backbone Usually, each PE connects multiple CPE components to the backbone
network infrastructure. This number may reach tens of thousands or network infrastructure. This number may reach tens of thousands or
more. The configuration of CPE is a difficult task for the ISP, and more. The configuration of CPE is a difficult task for the ISP, and
it is even more difficult when it must be done remotely. In this it is even more difficult when it must be done remotely. In this
context, the use of auto-configuration mechanisms is beneficial, even context, the use of auto-configuration mechanisms is beneficial, even
if manual configuration is still an option. if manual configuration is still an option.
skipping to change at page 16, line 50 skipping to change at page 17, line 21
5.5 Ingress Filtering in the Customer Connection Network 5.5 Ingress Filtering in the Customer Connection Network
Ingress filtering must be deployed towards the customers, everywhere, Ingress filtering must be deployed towards the customers, everywhere,
to ensure traceability, to prevent DoS attacks using spoofed to ensure traceability, to prevent DoS attacks using spoofed
addresses, to prevent illegitimate access to the management addresses, to prevent illegitimate access to the management
infrastructure, etc. infrastructure, etc.
Ingress filtering can be done, for example, by using access lists or Ingress filtering can be done, for example, by using access lists or
Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are
described in [BCP38UPD]. described in [RFC3704].
5.6 Multihoming 5.6 Multihoming
Customers may desire multihoming or multi-connecting for a number of Customers may desire multihoming or multi-connecting for a number of
reasons [RFC3582]. reasons [RFC3582].
Mechanisms for multihoming to more than one ISP are still under Mechanisms for multihoming to more than one ISP are still under
discussion. One working model could be to deploy at least one prefix discussion. One working model could be to deploy at least one prefix
per ISP, and to choose the prefix from the ISP to which traffic is per ISP, and to choose the prefix from the ISP to which traffic is
sent. In addition, tunnels may be used for robustness [RFC3178]. sent. In addition, tunnels may be used for robustness [RFC3178].
Currently, there are no provider-independent addresses for end-sites. Currently, there are no provider-independent addresses for end-sites.
Such addresses would enable IPv4-style multihoming, with associated Such addresses would enable IPv4-style multihoming, with associated
disadvantages. disadvantages.
skipping to change at page 17, line 35 skipping to change at page 18, line 9
Service Level Agreements (SLAs) or similar quality assurances. Service Level Agreements (SLAs) or similar quality assurances.
During the deployment of the IPv6 service, the service could be best- During the deployment of the IPv6 service, the service could be best-
effort or similar even if the IPv4 service has a SLA. In the end both effort or similar even if the IPv4 service has a SLA. In the end both
IP version should be treated equally. IP version should be treated equally.
IntServ and DiffServ are equally applicable to IPv6 as to IPv4 and IntServ and DiffServ are equally applicable to IPv6 as to IPv4 and
work in a similar fashion independent of IP version. Of these, work in a similar fashion independent of IP version. Of these,
typically only DiffServ has been implemented. typically only DiffServ has been implemented.
Many bandwidth provisioning systems operate with IPv4 assumptions,
e.g., taking an IPv4 address or (set of) prefixes for which traffic
is reserved or preferred. These systems require special attention
when introducing IPv6 support in the networks.
6. Network and Service Operation Actions 6. Network and Service Operation Actions
The network and service operation actions fall into different The network and service operation actions fall into different
categories as listed below: categories as listed below:
- Set up IPv6 connectivity to upstream providers and peers.
- IPv6 network device configuration: for initial configuration - IPv6 network device configuration: for initial configuration
and updates and updates
- IPv6 network management - IPv6 network management
- IPv6 monitoring - IPv6 monitoring
- IPv6 customer management - IPv6 customer management
- IPv6 network and service operation security - IPv6 network and service operation security
Some of these items will require an IPv6 native transport layer to Some of these items will require an IPv6 native transport layer to
be available, whereas others will not. be available, whereas others will not.
skipping to change at page 18, line 25 skipping to change at page 18, line 53
7. Future Stages 7. Future Stages
At some point, an ISP might want to transition to a service that is At some point, an ISP might want to transition to a service that is
IPv6 only, at least in certain parts of its network. Such a IPv6 only, at least in certain parts of its network. Such a
transition creates many new cases into which continued maintenance of transition creates many new cases into which continued maintenance of
the IPv4 service must be factored. Providing an IPv6-only service is the IPv4 service must be factored. Providing an IPv6-only service is
not much different from the dual IPv4/IPv6 service described in stage not much different from the dual IPv4/IPv6 service described in stage
3 except for the need to phase out the IPv4 service. The delivery of 3 except for the need to phase out the IPv4 service. The delivery of
IPv4 services over an IPv6 network and the phase out of IPv4 are left IPv4 services over an IPv6 network and the phase out of IPv4 are left
for a subsequent document. for a subsequent document. Note that there are some services which
will need to maintain IPv4 connectivity (e.g., authorative and some
recursive DNS servers [DNSGUIDE]).
8. Example Networks 8. Requirements for Follow-On Work
This section tries to summarize the potential items requiring
specification in the IETF.
Work items for which concrete specifications for which an approach
was not yet apparent as of this writing are:
- A tunnel server/broker mechanisms for the cases where the customer
connection networks cannot be upgraded needs to be specified
[TUNREQS].
- An IPv6 site multihoming mechanism (or multiple ones) need to be
developed.
Work items which were already fast in progress, as of this writing,
are:
- 6PE for MPLS was identified as a required mechanism, and this is
already in progress [BGPTUNNEL]
- IS-IS for Multiple Topologies was noted as a helpful mechanism in
certain environments; however, it is possible to use alternative
methods to achieve the same end, so specifying this is not strictly
required.
- Any-source Multicast can be accomplished using Embedded-RP
[EMBEDRP], already in progress.
9. Example Networks
In this section, a number of different example networks are In this section, a number of different example networks are
presented. These will not necessarily match any existing networks but presented. These will not necessarily match any existing networks but
are intended to be useful even in cases in which they do not are intended to be useful even in cases in which they do not
correspond to specific target networks. The purpose of these examples correspond to specific target networks. The purpose of these examples
is to exemplify the applicability of the transition mechanisms is to exemplify the applicability of the transition mechanisms
described in this document to a number of different situations with described in this document to a number of different situations with
different prerequisites. different prerequisites.
The sample network layout will be the same in all network examples. The sample network layout will be the same in all network examples.
skipping to change at page 19, line 41 skipping to change at page 20, line 48
||||| ||||| ISP Network ||||| ||||| ISP Network
----|-----------|---------------------- ----|-----------|----------------------
| | Customer Networks | | Customer Networks
+--------+ +--------+ +--------+ +--------+
| | | | | | | |
|Customer| |Customer| |Customer| |Customer|
| | | | | | | |
+--------+ +--------+ +--------+ +--------+
Figure 3: ISP Sample Network Layout. Figure 3: ISP Sample Network Layout.
8.1 Example 1 9.1 Example 1
Example 1 presents a network built according to the sample network Example 1 presents a network built according to the sample network
layout with a native IPv4 backbone. The backbone is running IS-IS and layout with a native IPv4 backbone. The backbone is running IS-IS and
IBGP as routing protocols for internal and external routes, IBGP as routing protocols for internal and external routes,
respectively. Multiprotocol BGP is used to exchange routes over the respectively. Multiprotocol BGP is used to exchange routes over the
connections to ISP2 and the exchange point. Multicast using PIM-SM connections to ISP2 and the exchange point. Multicast using PIM-SM
routing is present. QoS using DiffServ is deployed. routing is present. QoS using DiffServ is deployed.
Access 1 is xDSL connected to the backbone through an access router. Access 1 is xDSL connected to the backbone through an access router.
The xDSL equipment, except for the access router, is considered to be The xDSL equipment, except for the access router, is considered to be
skipping to change at page 21, line 5 skipping to change at page 22, line 11
router to IPv6. In the initial phase, only Router Advertisements are router to IPv6. In the initial phase, only Router Advertisements are
used; DHCPv6 Prefix Delegation can be added as the next step if no used; DHCPv6 Prefix Delegation can be added as the next step if no
other mechanisms are available. other mechanisms are available.
The FTTB/H access has to be upgraded to support access control and The FTTB/H access has to be upgraded to support access control and
traceability in the switches, probably by using DHCP snooping or a traceability in the switches, probably by using DHCP snooping or a
similar IPv6 capability, but it also has to be compatible with prefix similar IPv6 capability, but it also has to be compatible with prefix
delegation and not just address assignment. This could, however, lead delegation and not just address assignment. This could, however, lead
to the need to use DHCPv6 for address assignment. to the need to use DHCPv6 for address assignment.
8.2 Example 2 9.2 Example 2
In example 2 the backbone is running IPv4 with MPLS and is using OSPF In example 2 the backbone is running IPv4 with MPLS and is using OSPF
and IBGP are for internal and external routes respectively. The and IBGP are for internal and external routes respectively. The
connections to ISP2 and the exchange point run BGP to exchange connections to ISP2 and the exchange point run BGP to exchange
routes. Multicast and QoS are not deployed. routes. Multicast and QoS are not deployed.
Access 1 is a fixed line, e.g., fiber, connected directly to the Access 1 is a fixed line, e.g., fiber, connected directly to the
backbone. Routing information is in some cases exchanged with CPE at backbone. Routing information is in some cases exchanged with CPE at
the customer's site; otherwise static routing is used. Access 1 can the customer's site; otherwise static routing is used. Access 1 can
also be connected to a BGP/MPLS-VPN running in the backbone. also be connected to a BGP/MPLS-VPN running in the backbone.
skipping to change at page 21, line 39 skipping to change at page 22, line 45
For the fixed-line customers, the CPE has to be upgraded and prefix For the fixed-line customers, the CPE has to be upgraded and prefix
delegation using DHCPv6 or static assignment would be used. An IPv6 delegation using DHCPv6 or static assignment would be used. An IPv6
MBGP session would be used when routing information has to be MBGP session would be used when routing information has to be
exchanged. In the xDSL case the same conditions for IP-tunneling as exchanged. In the xDSL case the same conditions for IP-tunneling as
in Example 1 apply. In addition to IP-tunneling an additional PPP in Example 1 apply. In addition to IP-tunneling an additional PPP
session can be used to offer IPv6 access to a limited number of session can be used to offer IPv6 access to a limited number of
customers. Later, when clients and servers have been updated, the customers. Later, when clients and servers have been updated, the
IPv6 PPP session can be replaced with a combined PPP session for both 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. IPv4 and IPv6. PPP has to be used for address and prefix assignment.
8.3 Example 3 9.3 Example 3
A transit provider offers IP connectivity to other providers, but A transit provider offers IP connectivity to other providers, but
not to end users or enterprises. IS-IS and IBGP are used internally not to end users or enterprises. IS-IS and IBGP are used internally
and BGP externally. Its accesses connect Tier-2 provider cores. No and BGP externally. Its accesses connect Tier-2 provider cores. No
multicast or QoS is used. multicast or QoS is used.
Even though the RIR policies on getting IPv6 prefixes require the As this type of transit provider has a number of customers, which in
assignment of at least 200 /48 prefixes to the customers, this type turn have a large number of customers, it obtains an address
of transit provider obtains an allocation nonetheless, as the number allocation from a RIR. The whole backbone can be upgraded to dual-
of customers their customers serve is significant. The whole backbone stack in a reasonably rapid pace after a trial with a couple of
can be upgraded to dual-stack in a reasonably rapid pace after a routers. IPv6 routing is performed using the same IS-IS process and
trial with a couple of routers. IPv6 routing is performed using the separate IPv6 BGP sessions.
same IS-IS process and separate IPv6 BGP sessions.
The ISP provides IPv6 transit to its customers for free, as a The ISP provides IPv6 transit to its customers for free, as a
competitive advantage. It also provides, at the first phase only, a competitive advantage. It also provides, at the first phase only, a
configured tunnel service with BGP peering to the significant sites configured tunnel service with BGP peering to the significant sites
and customers (those with an AS number) which are the customers of and customers (those with an AS number) which are the customers of
its customers whenever its own customer networks are not offering its customers whenever its own customer networks are not offering
IPv6. This is done both to introduce them to IPv6 and to create a 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 beneficial side-effect: a bit of extra revenue is generated from its
direct customers as the total amount of transited traffic grows. direct customers as the total amount of transited traffic grows.
9. Security Considerations 10. Security Considerations
This document analyses scenarios and identifies some transition This document analyses scenarios and identifies some transition
mechanisms that could be used for the scenarios. It does not mechanisms that could be used for the scenarios. It does not
introduce any new security issues. Security considerations of each introduce any new security issues. Security considerations of each
mechanism are described in the respective documents. mechanism are described in the respective documents.
However, a few generic observations are in order. However, a few generic observations are in order.
o introducing IPv6 adds new classes of security threats or o introducing IPv6 adds new classes of security threats or
requires adopting new protocols or operational models requires adopting new protocols or operational models
skipping to change at page 22, line 43 skipping to change at page 23, line 50
o this document has identified a number of requirements for o this document has identified a number of requirements for
analysis or further work which should be explicitly considered analysis or further work which should be explicitly considered
when adopting IPv6: how to perform access control over when adopting IPv6: how to perform access control over
shared media or shared ISP customer connection media, shared media or shared ISP customer connection media,
how to manage the configuration management security on such how to manage the configuration management security on such
environments (e.g., DHCPv6 authentication keying), and environments (e.g., DHCPv6 authentication keying), and
how to manage customer traceability if stateless address how to manage customer traceability if stateless address
autoconfiguration is used. autoconfiguration is used.
10. Acknowledgements 11. Acknowledgements
This draft has greatly benefited from inputs by Marc Blanchet, Jordi This draft has greatly benefited from inputs by Marc Blanchet, Jordi
Palet, Francois Le Faucheur, Ronald van der Pol and Cleve Mickles. Palet, Francois Le Faucheur, Ronald van der Pol and Cleve Mickles.
Special thanks to Richard Graveman and Michael Lambert for Special thanks to Richard Graveman and Michael Lambert for
proofreading the document. proofreading the document.
11. Informative References 12. Informative References
[EMBEDRP] Savola, P., Haberman, B., "Embedding the Address of [EMBEDRP] Savola, P., Haberman, B., "Embedding the Address of
RP in IPv6 Multicast Address" - RP in IPv6 Multicast Address" -
Work in progress Work in progress
[MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M- [MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M-
ISIS: Multi Topology (MT) Routing in IS-IS" ISIS: Multi Topology (MT) Routing in IS-IS"
Work in progress Work in progress
[RFC 2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz, [RFC2858] Bates, T., Rekhter, Y., Chandra, R., Katz, D.,
"Multiprotocol Extensions for BGP-4" "Multiprotocol Extensions for BGP-4"
RFC 2858 RFC 2858
[RFC 2545] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol [RFC2545] Marques, P., Dupont, F., "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing" Extensions for IPv6 Inter-Domain Routing"
RFC 2545 RFC 2545
[BCP38UPD] F. Baker, P. Savola "Ingress Filtering for [BCP3704] Baker, F., Savola, P., "Ingress Filtering for
Multihomed Networks" Multihomed Networks"
Work in progress RFC 3704
[RFC3582] J. Abley, B. Black, V. Gill, "Goals for IPv6 Site- [RFC3582] Abley, J., Black, B., Gill, V., "Goals for IPv6 Site-
Multihoming Architectures" Multihoming Architectures"
RFC 3582 RFC 3582
[RFC3178] J. Hagino, H. Snyder, "IPv6 Multihoming Support at [RFC3178] Hagino, J., Snyder, H., "IPv6 Multihoming Support at
Site Exit Routers" Site Exit Routers"
RFC 3178 RFC 3178
[BGPTUNNEL] J. De Clercq, G. Gastaud, D. Ooms, S. Prevost, [RFC3056] Carpenter, B., Moore, K., "Connection of IPv6 Domains
F. Le Faucheur "Connecting IPv6 Islands across IPv4 via IPv4 Clouds"
RFC 3056
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865
[BGPTUNNEL] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S.,
Le Faucheur, F., "Connecting IPv6 Islands across IPv4
Clouds with BGP" Clouds with BGP"
Work in progress Work in progress
[DUAL ACCESS] Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi [DUAL ACCESS] Shirasaki, Y., Miyakawa, S., Yamasaki, T.,
Takenouchi, A.
"A Model of IPv6/IPv4 Dual Stack Internet Access "A Model of IPv6/IPv4 Dual Stack Internet Access
Service" Service"
Work in progress Work in progress
[STEP] P. Savola, "Simple IPv6-in-IPv4 Tunnel Establishment [STEP] Savola, P. "Simple IPv6-in-IPv4 Tunnel Establishment
Procedure (STEP)" Procedure (STEP)"
Work in progress Work in progress
[TSP] M. Blanchet, "IPv6 Tunnel broker with Tunnel Setup [TSP] Blanchet, M. "IPv6 Tunnel broker with Tunnel Setup
Protocol (TSP)" Protocol (TSP)"
Work in progress Work in progress
[TUNREQS] A. Durand, F. Parent "Requirements for assisted [TUNREQS] Durand, A., Parent, F. "Requirements for assisted
tunneling" tunneling"
Work in progress Work in progress
[UNMANEVA] C. Huitema, R. Austein, S. Satapati, R. van der Pol,
[UNMANEVA] Huitema, C., Austein, R., Satapati, S.,
van der Pol, R.
"Evaluation of Transition Mechanisms for Unmanaged "Evaluation of Transition Mechanisms for Unmanaged
Networks" Networks"
Work in progress Work in progress
[PROTO41] J. Palet, C. Olvera, D. Fernandez, "Forwarding [PROTO41] Palet, J., Olvera, C., Fernandez, D. "Forwarding
Protocol 41 in NAT Boxes" Protocol 41 in NAT Boxes"
Work in progress Work in progress
[V6SEC] P. Savola, "IPv6 Transition/Co-existence Security [V6SEC] Savola, P. "IPv6 Transition/Co-existence Security
Considerations" Considerations"
Work in progress 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
Authors' Addresses Authors' Addresses
Mikael Lind Mikael Lind
TeliaSonera TeliaSonera
Vitsandsgatan 9B Vitsandsgatan 9B
SE-12386 Farsta, Sweden SE-12386 Farsta, Sweden
Email: mikael.lind@teliasonera.com Email: mikael.lind@teliasonera.com
Vladimir Ksinant Vladimir Ksinant
Thales Communications Thales Communications
skipping to change at page 24, line 51 skipping to change at page 26, line 27
Email: alain.baudot@rd.francetelecom.com Email: alain.baudot@rd.francetelecom.com
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo, Finland Espoo, Finland
EMail: psavola@funet.fi EMail: psavola@funet.fi
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made Copies of IPR disclosures made to the IETF Secretariat and any
to obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementers or users of this specification attempt made to obtain a general license or permission for the use of
can be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
Copyright (C) The Internet Society (2003). All Rights Reserved. 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 translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix A: Convexity Requirements in Single Topology IS-IS Appendix A: Convexity Requirements in Single Topology IS-IS
The single-topology IS-IS convexity requirements could be summarized, The single-topology IS-IS convexity requirements could be summarized,
from IPv4/6 perspective, as follows: from IPv4/6 perspective, as follows:
1) "any IP-independent path from an IPv4 router to any other IPv4 1) "any IP-independent path from an IPv4 router to any other IPv4
router must only go through routers which are IPv4-capable", and router must only go through routers which are IPv4-capable", and
2) "any IP-independent path from an IPv6 router to any other IPv6 2) "any IP-independent path from an IPv6 router to any other IPv6
router must only go through routers which are IPv6-capable". router must only go through routers which are IPv6-capable".
As IS-IS is based upon CLNS, these are not trivially accomplished. As IS-IS is based upon CLNS, these are not trivially accomplished.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/