One document matched: draft-ietf-v6ops-ent-analysis-01.txt
Differences from draft-ietf-v6ops-ent-analysis-00.txt
IPv6 Operations Working Group
Internet Draft Jim Bound (Editor)
Document: draft-ietf-v6ops-ent-analysis-01.txt HP
Obsoletes: ietf-v6ops-ent-analysis-00.txt
Expires: June 2005
IPv6 Enterprise Network Analysis
<draft-ietf-v6ops-ent-analysis-01.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been
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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document analyzes the transition to IPv6 in enterprise
networks. These networks are characterized as a network that has
multiple internal links, one or more router connections, to one or
more Providers, and is managed by a network operations entity. The
analysis will focus on a base set of transition notational networks
and requirements expanded from a previous Enterprise Scenarios
document. Discussion is provided on a focused set of transition
analysis required for the enterprise to transition to IPv6,
assuming a dual IP layer (IPv4 and IPv6) network and node
environment, within the enterprise. Then a set of transition
mechanisms are recommended for each notational network.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 1]
Internet Draft IPv6 Enterprise Network Analysis January 2005
Table of Contents:
1 Introduction.................................................3
2 Terminology..................................................5
3 Enterprise Matrix Analysis for Transition....................6
4 Wide-Scale Dual-Stack Deployment Analysis....................9
4.1 Staged Dual-Stack Deployment...............................9
4.2 Analysis of Required Tools for Dual-Stack Deployment......10
4.3 IPv6 Capability in the Routing Infrastructure.............10
4.4 IPv6 Capability not in the Routing Infrastructure.........10
4.4.1 Tunnel IPv6 over the IPv4 infrastructure................10
4.4.2 Deploy a parallel IPv6 infrastructure...................11
4.5 Remote IPv6 access to the enterprise......................11
4.6 Other considerations......................................11
5 Sparse Dual-Stack Deployment Analysis.......................12
5.1 Internal versus External Tunnel End Point.................12
5.2 Manual versus Autoconfigured..............................13
6 IPv6 Dominant Network Deployment Analysis...................14
7 General Issues and Applicability from Analysis..............15
7.1 Staged Plan for IPv6 Deployment............................15
7.2 Network Infrastructure Requirements.......................15
7.3 Stage 1: Initial connectivity steps........................15
7.3.1 Obtaining external connectivity..........................15
7.3.2 Obtaining global IPv6 address space......................16
7.4 Stage 2: Deploying generic basic service components........16
7.4.1 IPv6 DNS.................................................16
7.4.2 IPv6 Routing............................................16
7.4.3 Configuration of Hosts..................................17
7.4.4 Developing an IPv6 addressing plan......................17
7.4.5 Security................................................17
7.5 Stage 3: Widespread Dual-Stack deployment on-site.........18
7.5.1 Deploying IPv6 across the enterprise....................18
8 Applicable Transition Mechanisms............................19
9 Security Considerations.....................................20
10 References.................................................20
10.1 Normative References.....................................20
10.2 Non-Normative References.................................21
Changes from -00 t -01.........................................21
Document Acknowledgments.......................................22
Author Addresses...............................................23
Appendix A - Campus Deployment Scenario with VLANs.............23
Appendix B - Crisis Management Network Scenarios...............24
Intellectual Property and Copyright Statements.................29
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 2]
Internet Draft IPv6 Enterprise Network Analysis January 2005
1 Introduction
NOTE to v6ops WG: This draft is mainly to get consensus on section
3, that we have correct analysis topics sections 4-7, and section 8
still has to be written. All sections need more work but this is
to move discussion further. See changes from -00 to -01.
This document analyzes the transition to IPv6 in enterprise
networks. These networks are characterized as a network that has
multiple internal links, one or more router connections, to one or
more Providers, and is managed by a network operations entity. The
analysis will focus on a base set of transition notational networks
and requirements expanded from a previous Enterprise Scenarios
document. Discussion is provided on a focused set of transition
analysis required for the enterprise to transition to IPv6,
assuming a dual IP layer (IPv4 and IPv6) network and node
environment, within the enterprise. Then a set of transition
mechanisms are recommended for each notational network.
The audience for this document is the enterprise network team
considering deployment of IPv6. The document will be useful for
enterprise teams that will have to determine the IPv6 transition
strategy for their enterprise. It is expected those teams include
members from management, network operations, and engineering. The
analysis and notational networks presented provide an example set
of cases the enterprise can use to build an IPv6 transition
strategy.
The enterprise analysis will begin by describing a matrix as a tool
to be used to portray the different IPv4 and IPv6 possibilities for
deployment. The document will then provide analysis to support a
wide dual IP layer deployment strategy across the enterprise, to
provide the reader a view of how that can be planned and what is
options are available. The document will then discuss the
deployment of sparse IPv6 nodes within the enterprise and what
requirements need to be considered and implemented, when the
enterprise will remain with IPv4-only routing infrastructure for
some time. The next discussion focuses on the use of IPv6 when it
is determined to be dominant across or within parts of the
enterprise network.
The document then begins to discuss the the general issues and
applicability from the previous analysis. The document concludes
providing a set of recommendations for each notational network
within the matrix based on the previous analysis, issues and
applicability discussion, adding additional analysis useful for an
enterprise planning to deploy IPv6.
This document, as stated in the introduction, focuses only on the
deployment cases where a dual IP layer is supported across the
network and on the nodes in the enterprise. Additional deployment
transition analysis will be required from the effects of IPv6-only
node or Provider deployments, and beyond the scope of this
document. In addition this document does not attempt to define or
discuss any use with network address translation or the use of
Provider Independent address space.
The following specific topics are currently out of scope for this
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 3]
Internet Draft IPv6 Enterprise Network Analysis January 2005
document:
- Multihoming
- Application transition/porting (see [APPS]).
- IPv6 VPN, firewall or intrusion detection deployment
- IPv6 network management and QoS deployment
- Detailed IT Department requirements
- Deployment of novel IPv6 services, e.g. Mobile IPv6
- Requirements or Transtion at the Providers network
- Transport protocol selection for applications with IPv6
- Application layer and configuration issues.
- IPv6 only future deployment scenarios.
We are focusing in this document on Layer 3 deployment, in the same
way as the other IPv6 deployment analysis works have done
[UMAN,ISPA, 3GPA]. This document covers deployment of IPv6 "on the
wire", including address management and DNS services.
We are also assuming that the enterprise deployment is one being
undertaken by the network administration team, i.e. this document
is not discussing the case of an individual user gaining IPv6
connectivity (to some external IPv6 provider) from within an
enterprise network. Much of the analysis is applicable to wireless
networks, but there are additional considerations for wireless
networks not contained within this document.
In Section 2 we introduce the terminology used in this document.
In Section 3 we introduce and define a tools matrix and define the
layer 3 connectivity requirements. In Section 4 we discuss wide
scale dual IP layer use within an enterprise. In section 5 we
discuss sparse dual IP layer deployment within an enterprise. In
section 6 we discuss IPv6 dominant network deployment within the
enterprise. In sectioin 7 we discuss general issues and
applicability. In section 8 a set of deployment analysis is
provided and recommendations.
This document then provides Appendix A for readers depicting a
Crisis Management enterprise network to demonstrate an enterprise
network example that requires all the properties as analyzed in
Sections 3, 4, 5, 6, and 7.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 4]
Internet Draft IPv6 Enterprise Network Analysis January 2005
2 Terminology
Enterprise Network - A network that has multiple internal links,
one or more router connections, to one or
more Providers and is actively managed by a
network operations entity.
Provider - An entity that provides services and
connectivity to the Internet or
other private external networks for the
enterprise network.
IPv6-capable - A node or network capable of supporting both
IPv6 and IPv4.
IPv4-only - A node or network capable of supporting only
IPv4.
IPv6-only - A node or network capable of supporting only
IPv6. This does not imply an IPv6 only
stack, in this document.
Dual-IP - References a network or node that supports both
IPv4 and IPv6.
IP-capability - The ability to support IPv6 only, IPv4 only,
or Dual IP Layer
IPv6-dominant - A network or link that uses only IPv6 routing.
Transition - The network strategy the enterprise uses to
Implementation transition to IPv6.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 5]
Internet Draft IPv6 Enterprise Network Analysis January 2005
3 Enterprise Matrix Analysis for Transition
To provide layer 3 enterprise analysis context for discussion we
provide for this document the use of a matrix with a common set of
enterprise notational networks resulting from a selected Transition
Implementation chosen for the enterprise. The notional networks
are comprised of hosts attached to an enterprise-owned intranet(s)
at two different global locations separated by the Internet. The
enterprise owns, operates and maintains its own intranetworks, but
relies on an external provider organization that offers Internet
Service. Both local and destination intranetworks are operated by
different organizations within the same enterprise and consequently
could use different IP-capability, than other intranetworks, at
certain times in the transition period.
Addressing every possible combination of network IP-capability in
this notional enterprise network is impractical, therefore trivial
(i.e. pure IPv4, pure IPv6, ubiquitous dual-IP and straight forward
tunneling or translation at local or destination hosts) are not
considered. In addition, the authors could not conceive of any
scenarios involving IPv6-only ISPs or IPv6-only nodes in the near-
term and consequently have not addressed scenarios with IPv6-only
ISPs or IPv6-only nodes. We assume all nodes that use IPv6
applications are Dual IP. The matrix does not assume or suggest
that network address translation is used. The authors recommend
that network address translation not be used in these notational
cases.
Future enterprise transitions that will support IPv6-only nodes and
IPv6-only ISPs will be a separate analysis required, that is beyond
the scope of this document.
Table 1 below is a matrix of nine possible Transition
Implementations that may be selected in an enterprise, which
require analysis and the selection of an IPv6 transition mechanism
for that notational network, which are the rows of the matrix. The
matrix describes a set of notational networks as follows:
- The first column represents the protocol used by the
application and below the IP-capability of the node
originating the IP packets.
(Application/Host 1 OS).
- The second column represents the IP-capability of the
network where the node originated the packet.
(Host 1 Network)
- The third column represents the IP-capability of the
service provider network.
(Service Provider)
- The fourth column represents the IP-capability of the
destination network where the originating IP packets
are received.
(Host 2 Network)
- The fifth column represents the protocol used by the
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 6]
Internet Draft IPv6 Enterprise Network Analysis January 2005
application and below the IP-capability of the
destination node receiving the originating IP packets.
(Application/Host 2 OS).
As an example, notational network 1 is an IPv6 application residing
on a dual IP layer host trying to establish a communications
exchange with a destination IPv6 application. To complete the
information exchange the packets must first traverse the host's
originating IPv4 network (intranet), then the service provider's,
and destination hosts dual-IP network.
Obviously Table 1 does not describe every possible scenario.
Trivial notational networks (such as pure IPv4, pure IPv6, and
straight-forward tunneling or translation) are not addressed.
Additionally there are other possible permutations, which are not
addressed. However, the authors feel these nine represent
notational networks, which are likely to be encountered in today's
enterprise. Therefore, we will use these nine to address the
analysis for enterprise deployment.
======================================================
|Application |Host 1 |Service |Host 2 |Application |
|----------- |Network|Provider|Network|---------- |
| Host 1 OS | | | | Host 2 OS |
=====================================+================
| IPv6 | | | | IPv6 |
1 | ---- | IPv4 |Dual IP |Dual IP| ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv6 | | | | IPv6 |
2 | ---- | IPv4 |Dual IP | IPv4 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv6 | | | | IPv6 |
4 | ---- |Dual IP|Dual IP | IPv4 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv6 | | | | IPv6 |
4 | ---- |Dual IP| IPv4 |Dual IP| ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv6 | | | | IPv6 |
5 | ---- | IPv4 | IPv4 |Dual IP| ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 | | | | IPv4 |
6 | ---- | IPv6 |Dual IP |Dual IP| ---- |
| Dual IP | | | | IPv4 |
======================================================
| IPv4 | | | | IPv4 |
7 | ---- | IPv6 | IPv4 | IPv6 | ---- |
| Dual IP | | | | Dual IP |
======================================================
| IPv4 | | | | IPv4 |
8 | ---- | IPv4 |Dual IP | IPv6 | ---- |
| IPv4 | | | | Dual IP |
======================================================
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 7]
Internet Draft IPv6 Enterprise Network Analysis January 2005
| IPv4 | | | | IPv4 |
9 | ---- | IPv4 | IPv4 | IPv6 | ---- |
| IPv4 | | | | Dual IP |
======================================================
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 8]
Internet Draft IPv6 Enterprise Network Analysis January 2005
4 Wide-Scale Dual-Stack Deployment Analysis
In this section we are covering Scenario 1 as described in Section
3.1 of [BSCN]. The scenario, assumptions and requirements are
driven from the [BSCN] text.
A common scenario for IPv6 deployment is the enterprise network
that wishes to introduce IPv6 by enabling IPv6 on the wire in a
structured fashion with the existing IPv4 infrastructure. In such a
scenario, a number of the existing IPv4 routers (and thus subnets)
will be made dual-stack, such that communications can run over
either protocol.
Nodes within the dual-stack links may themselves be IPv4-only and
IPv6-capable. The driver for deploying IPv6 may not be for
immediate wide-scale usage of IPv6, but rather to prepare an
existing IPv4 infrastructure to support IPv6-capable nodes, such
that Dual-IP nodes exist, but IPv6 is not used, but exist when IPv6
is implemented.
We analyze the scenario against existing transition mechanisms for
their applicability, suggesting a staged approach for IPv6
deployment in the enterprise.
4.1 Staged Dual-Stack Deployment
The site administrator should formulate a staged plan for the
introduction of dual-stack IPv6 network. We suggest that the
generic plan of Section 7 of this document provides a good basis
for such a plan.
The generic plan has a number of stages that are independent of
whether Dual-IP IPv4, or IPv6-dominant networks are selected as a
IP-cabability Transition Implmentation for deployment.
In an enterprise network, the administrator will generally seek to
deploy IPv6 in a structured, controlled manner, such that IPv6 can
be enabled on specific links at specific stages of deployment. It
may be a specific requirement that some links remain IPv4 only, or
specifically should not have IPv6 connectivity. It may also be a
requirement that aggregatable global IPv6 addresses, assigned by
the enterprise's upstream provider from the address space allocated
to them by the Regional Internet Registries (RIRs), are used for
assignment.
In this document we do not discuss the deployment of Unique Local
IPv6 Unicast Addresses [ULA]. The address type and scope selected
is orthogonal to the the layer 3 analysis in this document.
A typical deployment would involve the establishment of a single
"testbed" Dual-IP subnet at the enterprise site, prior to wider
deployment. Such a testbed not only allows the IPv6 capability of
specific platforms and applications to be evaluated and verified,
it also permits the steps in Sections 7.3 and 7.4 of this document
to be undertaken without (potential) adverse impact on the
production elements of the enterprise.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 9]
Internet Draft IPv6 Enterprise Network Analysis January 2005
Section 7.5 describes the stages for the widespread deployment in
the enterprise, which would be undertaken after the basic building
blocks for IPv6 deployment are in place.
4.2 Analysis of Required Tools for Dual-Stack Deployment
The critical part of Dual-IP deployment is the IPv6 routing
infrastructure implemented. The path taken will depend on whether
the enterprise has existing Layer 2/3 switch/router equipment that
has an IPv6 (routing) capability, or that can be upgraded to have
such capability.
In Section 4, we are not considering sparse IPv6 deployment; the
goal of Dual-IP deployment is widespread use in the enterprise.
4.3 IPv6 Capability in the Routing Infrastructure
Where IPv6 routing capability exists within the infrastructure, the
network administrator can enable IPv6 on the same physical hardware
as the existing IPv4 service. This is the end goal of any
enterprise Dual-IP deployment, when the capability, performance, and
robustness of the Dual-IP operational deployment has been verified.
Ideally, the IPv6 capability will span the entire enterprise,
allowing deployment on any link or subnet. If not, techniques from
Section 4.4 below may be required.
4.4 IPv6 Capability not in the Routing Infrastructure
In this case the enterprise administrator faces two basic choices,
either to tunnel IPv6 over some or all of the existing IPv4
infrastructure, or to deploy a parallel IPv6 routing infrastructure
providing IPv6 connectivity into existing IPv4 subnets.
It may thus be the case that a nodes IPv4 and IPv6 default routes to
reach other links (subnets) are through different routing platforms.
4.4.1 Tunnel IPv6 over the IPv4 infrastructure
The tunneling, as described in [BCNF] would be established between
Dual-IP capable routers on the enterprise, thus "bypassing" existing
non IPv6-capable routers and platforms. For example, some IPv6
edge routers in the enterprise may be IPv6-capable, while others,
and perhaps the enterprise backbone itself, are not IPv6-capable.
In the widespread dual-stack scenario, a more structured, manageable
method is required, where the administrator has control of the
deployment per-link and (ideally) long-term, aggregatable global
IPv6 addressing is obtained, planned and used from the outset.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 10]
Internet Draft IPv6 Enterprise Network Analysis January 2005
4.4.2 Deploy a parallel IPv6 infrastructure
In this case, the administrator may deploy a new, separate IPv6-
capable router (or set of routers). It is quite possible that such
a parallel infrastructure would be IPv6-dominant.
Such an approach can mean acquiring additional hardware, but it has
the advantage that the existing IPv4 routing platforms are not
disturbed by the introduction of IPv6.
To distribute IPv6 to the existing IPv4 enterprise subnets, either
dedicated physical infrastructure can be deployed or, if it is
available, IEEE 802.1q VLANs could be used, as described in [VLAN].
The latter has the significant advantage of not requiring any
additional physical cabling/wiring; it offers all the advantages of
VLANs for the new dual-stack environment.
Many router platforms can tag multiple VLAN IDs on a single physical
interface based on the subnet/link the packet is destined for; thus
multiple IPv6 links can be collapsed for delivery on a single (or
small number of) physical IPv6 router interfaces in the early stages
of deployment.
The parallel infrastructure would only ever be seen as an interim
step towards a full Dual-IP deployment on a unified infrastructure.
The parallel infrastructure however allows all other aspects of the
IPv6 enterprise services to be deployed, including IPv6 addressing,
ready for that unifying step at a later date.
4.5 Remote IPv6 access to the enterprise
Where the enterprise's users are off-site, and using an ISP that
does not support any native IPv6 service or IPv6 transition aids,
the enterprise may consider deploying it's own remote IPv6 access
support, as described in Section 7.5.2.
4.6 Other considerations
There are some identified issues with turning IPv6 on by default,
including application connection delays, poor connectivity, and
network insecurity, as discussed in [V6DEF]. The issues can be
worked around or mitigated by following the advice in [V6DEF].
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 11]
Internet Draft IPv6 Enterprise Network Analysis January 2005
5 Sparse Dual-Stack Deployment Analysis
This section covers the Scenario 2 as described in Section 3.1 of
[BSCN]. This scenario assumes the requirements defined within the
[BSCN] text.
IPv6 deployment within the enterprise network, with an existing
IPv4 infrastructure, could be motivated by mission critical or
business applications or services that require IPv6. In this case
the prerequisite is that only the nodes using those IPv6
applications need to be upgraded to be IPv6-capable. The routing
infrastructure will not be upgraded to support IPv6, nor does the
enterprise wish to deploy a parallel IPv6 routing infrastructure at
this point, since this is an option in section 4.
There is a need for end-to-end communication with IPv6, but the
infrastructure only supports IPv4 routing. Thus, the only viable
method for end-to-end communication with IPv6 is to tunnel the
traffic over the existing IPv4 infrastructure, within this analysis
documents boundaries defined.
The network team needs to decide which are the most efficient the
available transition tunneling mechanisms to deploy, so they can be
used without disrupting the existing IPv4 infrastructure. Several
conditions require analysis, as introduced in the following sub
sections.
5.1 Internal versus External Tunnel End Point
Assuming the upstream provider has deployed some IPv6 services,
either native IPv6 in its backbone or in the access network, or a
combination of both. Also, or alternatively, could have deployed
one or more several transition mechanisms based upon tunnels for
subscribers.
for example in the case where the access network doesn't support
IPv6, the enterprise could decide to use those available transition
services from the Provider. However, this will usually mean that
individual nodes in the network will have their own IPv6-in-IPv4
tunnel. Then, the IPv6 intranetworks communication may not be as
efficient, because it will require all the traffic to be forwarded
by the IPv4 infrastructure to the Tunnel-End-Point located at the
Provider. This may be acceptable if the IPv6 applications do not
require intranetworks communication at all. For example in the case
where the application server is located outside of the enterprise
network, or on other intranetworks of the same enterprise.
The enterprise could also decide to deploy its own transition
mechanism node, and possibly collocate it adjacent to the border
router that connects to the upstream Provider. In this case,
intranetnetworks communication using this tunnel end point is also
possible.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 12]
Internet Draft IPv6 Enterprise Network Analysis January 2005
5.2 Manual versus Autoconfigured
If the number of nodes to be using IPv6 is reduced, an option is to
use statically configured tunnels.
However, in general automatic configured tunnels will be preferred.
Section 5 doesn't yet discuss pros and cons of connecting sparse
nodes, nor management/security issues. We need to add that in -02.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 13]
Internet Draft IPv6 Enterprise Network Analysis January 2005
6 IPv6 Dominant Network Deployment Analysis
In this section we are covering Scenario 3 as described in Section
3.1 of [BSCN]. The scenario, assumptions and requirements are
driven from the [BSCN] text.
IPv6 deployment in some enterprise networks will use an IPv6-
dominant network deployment strategy. What this means essentially
is that the network or specific sites within the enterprise network
will transition to IPv6 using only IPv6 routing to transfer both
IPv4 and IPv6 packets over the network, even though the network is
Dual-IP capable.
IPv6 communications between IPv6 nodes will use IPv6 to
communicate. When IPv6-capable nodes in the IPv6-dominant network
need to communicate with IPv4 nodes, on the IPv6-dominant network,
the IPv6 nodes will use their Dual-IP implementation to tunnel IPv4
packets in IPv6 [6TUN]. An edge router within the IPv6-dominant
network will decapsulate the IPv4 packet and route to the path of
the IPv4 node on the network. This permits Dual-IP layer nodes to
communicate with legacy IPv4 nodes within an IPv6-dominant network.
This section needs more work.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 14]
Internet Draft IPv6 Enterprise Network Analysis January 2005
7 General Issues and Applicability from Analysis
In this section we describe generic enterprise IPv6 deployment
issues, applicable to the analysis sections 4-6 in this document.
This section needs more work.
7.1 Staged Plan for IPv6 Deployment
The enterprise network administrator will need to follow a staged
plan for IPv6 deployment.
This section needs more work.
7.2 Network Infrastructure Requirements
The considerations for the enterprise components are detailed in
Section 3.2 of [BSCN]. We do not go into detail of all aspects of
such components in this document. In this document we focus on
Layer 3 issues.
This section needs more work.
7.3 Stage 1: Initial connectivity steps
The first steps for IPv6 deployment do not involve technical
aspects per se; the enterprise needs to select an external IPv6
provider, and obtain globally routable IPv6 address space from that
provider.
7.3.1 Obtaining external connectivity
The enterprise service provider would typically be a
topographically close (to minimize connectivity RTT) IPv6 provider
that is able to provide an IPv6 upstream link.
It would be expected that the enterprise would use either native
IPv6 upstream connectivity or, in its absence, a manually
configured tunnel [BCNF] to the upstream provider.
It is not recommended to use 6to4 [6TO4] or a tunnel broker [TBRK]
for an enterprise deployment. The enterprise has a requirement for
long-term, stable IPv6 connectivity. 6to4 and the tunnel broker
are more appropriate for SOHO or single node environments. Use of
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 15]
Internet Draft IPv6 Enterprise Network Analysis January 2005
6to4 also prevents the enterprise adopting aggregatable global IPv6
addressing from the outset.
7.3.2 Obtaining global IPv6 address space
The enterprise will obtain global IPv6 address space from its
selected upstream provider, as provider assigned (PA) address
space.
The enterprise should receive at least a /48 allocation from its
provider, as described in [ALLOC].
The procedure for enterprise renumbering between providers is
described in [RENUM].
This section needs more work.
7.4 Stage 2: Deploying generic basic service components
Most of these are discussed in Section 4 of [BSCN]. Here we
comment on those aspects that we believe are in scope for this
analysis document. Thus we have not included network management,
multihoming, multicast or application transition analysis here, but
these aspects should be addressed in Stage 2.
7.4.1 IPv6 DNS
The enterprise site should deploy a DNS service that is capable of
both serving IPv6 DNS records using the AAAA format [DNSV6REC] and
of communicating over IPv6 transport.
Specific IPv6 DNS issues are reported in [DNSV6].
This section needs more work.
7.4.2 IPv6 Routing
The enterprise network will need to support methods for internal
and external routing.
For a single-homed single-site network, a static route to a single
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 16]
Internet Draft IPv6 Enterprise Network Analysis January 2005
upstream provider may be sufficient, although the site may choose
to use an exterior routing protocol, especially where it has
multiple upstream providers.
For internal routing, an appropriate interior routing protocol may
be deployed.
IPv6 routing protocols that can be used are as follows: BGP4+
[BGPv6], IS-IS [ISISv6], OSPFv3 [RFC????) and RIPng [RIPv6].
This section needs more work.
7.4.3 Configuration of Hosts
An enterprise network will have a number of tools available for
IPv4 address and other configuration information delegation and
management, including manual configuration, NIS [NIS] or DHCP
[DHCPv4].
In an IPv6 enterprise, Stateless Address Autoconfiguration
[ADDRCONF] may be used to configure a host with a global IPv6
address, a default router, and an on-link prefix information.
For secure autoconfiguration, the IPsec [IPSEC] or SEND method
[SEND] can be used.
A stateless configured node wishing to gain other configuration
information (e.g. DNS, NTP servers) will likely need a Stateful
DHCPv6 [DHCPv6] service available.
For nodes configuring via DHCPv6, where DHCPv6 servers are offlink,
a DHCPv6 Relay Agent function will be required.
Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6];
there is support for DHCPv6 to assign privacy addresses to nodes in
managed environments.
This section needs more work continuity.
7.4.4 Developing an IPv6 addressing plan
<to be completed >
7.4.5 Security
<to be completed - see Pekka's various drafts on 6to4 and others?,
and emphasize use of best practice>
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 17]
Internet Draft IPv6 Enterprise Network Analysis January 2005
7.5 Stage 3: Widespread Dual-Stack deployment on-site
With the basic building blocks of external connectivity, interior
IPv6 routing, an IPv6 DNS service and address allocation management
in place, the IPv6 capability can be rolled out to the wider
enterprise. This involves putting IPv6 on the wire in the desired
links, and enabling applications and other services to begin using
IPv6 transport.
7.5.1 Deploying IPv6 across the enterprise
In the Dual-IP deployment case, this means enabling IPv6 on
existing IPv4 subnets. It is most likely that the administrator
will deploy IPv6 links to be congruent with existing IPv4 subnets
(because IPv4 subnets tend to be created for geographic, policy or
administrative reasons that would be IP-independent).
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 18]
Internet Draft IPv6 Enterprise Network Analysis January 2005
8 Applicable Transition Mechanisms
This section will provide guidance for the use of specific
transition mechanisms below that can be used by the enterprise to
support the enterprise matrix notational networks (rows) in Section
3, and within the context of the analysis discussed in Sections 4,
5, and 6.
Section to be written.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 19]
Internet Draft IPv6 Enterprise Network Analysis January 2005
9 Security Considerations
WRITING: Lets do this after we get above writing done.
10 References
10.1 Normative References
Most of these need to be moved to non-normative reference section
and additional references need to be added.
[DNSV6] Durand, A., Ihren, J. and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", Work in
Progress.
[CONF] Thomson, S., Narten, T., "IPv6 Stateless Autoconfiguration"
RFC 2462 December 1998.
[DHCPF] Droms, R., Bound, J., Volz, B., Lemon, T., et al. "Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)" RFC 3315 July
2003.
[DHCPL] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6" RFC 3756 April 2004.
[APPS] Shin, M-K., Hong, Y-G., Haigino, J., Savola, P., Castro, E.,
"Application Aspects of IPv6 Transition" Work in Progress.
[BSCN] Bound, J., (Ed) et al. "IPv6 Enterprise Network Scenarios"
Work in Pogress.
[6TO4] Carpenter, B., Moore, K., "Connection of IPv6 Domains via
IPv4 Clouds" RFC 3056 February 2001.
[TRDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs" Work in Progress.
[BCNF] Nordmark, E., Gilligan, R., "Basic Transition Mechanisms
for IPv6 Hosts and Routers" Work in Progress from RFC 2893.
[DSTM] Bound, J., (Ed) et al. "Dual Stack Transition Mechanim"
Work in Progress.
[ISTP] Templin, F., et al "Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)". Work in Progress.
[6TUN] Conta, A., Deering, S., "Generic Packet Tunneling in
IPv6" RFC 2473 December 1998.
[TBRK] Durand, A., et al "IPv6 Tunnel Broker"
RFC 3053 January 2001.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 20]
Internet Draft IPv6 Enterprise Network Analysis January 2005
[SEC1] Savola, P., Patel, C., "Security Considerations for
6to4. Work in Progress.
[ULA] Hinden, B., Haberman, B., "Unique Local IPv6
Addresses". Work in Progress.
[RENUM] Baker, F., Lear, E., Droms, R., "Procedures for Renumbering
an IPv6 Network without a Flag Day". Work in Progress.
[ALLOC] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites" RFC 3177 September 2001.
[NATPT] Tsirtsis, G., Srisuresh, P., "Network Address Translation -
Protocol Translation (NAT-PT)" RFC 2766 February 2000
[UMAN] Huitema, C.,. et al "Evaluation of IPv6 Transition Mechanisms
for Unmanaged Networks". Work in Progress.
[ISPA] Lind, M., et al "Scenarios and Analysis for Introducing IPv6
into ISP Networks". Work in Progress.
[3GPA] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks"
Work in Progress.
10.2 Non-Normative References
To be completed in next draft version.
Changes from -00 t -01
- Changed abstract and context of document to only deal with dual
IP layer
networks and nodes.
- Changed introduction, Section 1-3 to reflect authors and IETF WG
discussions
to attempt consensus on these initial sections.
- Added explanation of why Appendix A is in the document to
introduction.
- Expanded what topics are out of scope for this document.
- Updated terminology section
- Updated section 3 matrix and description to simplify and focus on
dual IP layer
- Edited base text of Sections 4-7 but all three require extensive
additional test
for descriptions.
- Edited section 8 and removed table and will reference table in
section 3. This
section still needs to be written.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 21]
Internet Draft IPv6 Enterprise Network Analysis January 2005
Document Acknowledgments
The Authors would like to acknowledge contributions from the
following: IETF v6ops Working Group members Pekka Savola.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 22]
Internet Draft IPv6 Enterprise Network Analysis January 2005
Author Addresses
Jim Bound
HP
110 Spitbrook Road
Nashua, NH 03062
USA
Phone: 603.305.3051
Email: jim.bound@hp.com
Yanick Pouffary
HP Competency Center
950, Route des Colles, BP027,
06901 Sophia Antipolis CEDEX
FRANCE
Phone: + 33492956285
Email: Yanick.pouffary@hp.com
Tim Chown
School of Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom
Email: tjc@ecs.soton.ac.uk
David Green
SRI International
333 Ravenswood Ave
Menlo Park, CA 94025-3493
USA
Phone: 732 532-6715
Email: david.green@sri.com
Jordi Palet Martinez
Consulintel
San Jose Artesano, 1
Madrid, SPAIN
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
Email: jordi.palet@consulintel.es
Steve Klynsma
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102-5708
USA
703-883-6469
Email: sklynsma@mitre.org
fi
Appendix A - Campus Deployment Scenario with VLANs
To be completed in next drafts.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 23]
Internet Draft IPv6 Enterprise Network Analysis January 2005
Appendix B - Crisis Management Network Scenarios
Introduction:
This appendix first describes different scenarios for the
introduction of IPv6 into a crisis management network for
emergency services, defense, or security forces that are currently
running IPv4 service. Then, the scenarios for introducing IPv6 are
analyzed and the relevance of already defined transition mechanisms
are evaluated. Known challenges are also identified.
When a crisis management enterprise deploys IPv6, its goal is to
provide IPv6
connectivity on it's institutional fixed networks and on the mobile
wireless
services that are deployed to a crisis area. The new IPv6 service must
be added to an already existing IPv4 service, the introduction of
IPv6 must not interrupt this IPv4 service, and the IPv6 services must
be interoperable with existing IPv4 services.
Crisis management enterprises accessing IPv4 service across mobile
ground
networks, airborne networks, and satellites will find different ways to
add
IPv6 to this service based on their network architecture, funding,
and institutional goals. This document discusses a small set of
scenarios representing the architectures for IPv6 expected to be
dominant
in crisis management networks during the next decade. It evaluates the
relevance of the existing transition mechanisms in the context of
these deployment scenarios, and points out the lack of essential
functionality in these methods to the ISP's operation of an IPv6
service.
The document is focused on services that include both IPv6 and IPv4
and does cover issues surrounding accessing IPv4 services across
IPv6-only
networks. It is outside the scope of this document to describe detailed
implementation plans for IPv6 in defense networks
Scenarios for IPv6 Deployment in Crisis Management Networks:
Scenario 1: Limited IPv6 Deployment Network.....................
Sparse IPv6 dual-stack deployment in an existing IPv4 network
infrastructure.
Enterprise with an existing IPv4 network wants to deploy a set of
particular
IPv6 "applications" and have some ability to interoperate with other
institutions that are using IPv6 services. The IPv6 deployment is
limited
to the minimum required to operate this set of applications.
Assumptions: IPv6 software/hardware components for the application are
available, and platforms for the application are IPv6 capable.
Requirements: Do not disrupt IPv4 infrastructure.
Scenario 2: Dual Stack Network
Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable hosts
and network infrastructure. Enterprise with an existing
IPv4 network wants to deploy IPv6 in conjunction with their IPv4
network in order to take advantage of emerging IPv6 network-centric
capabilities and to be interoperable with other agencies, international
partners, and commercial enterprises that are deploying an IPv6
architecture.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 24]
Internet Draft IPv6 Enterprise Network Analysis January 2005
Assumptions: The IPv4 network infrastructure used has an
equivalent capability in IPv6.
Requirements: Do not disrupt existing IPv4 network infrastructure
with IPv6. IPv6 should be equivalent or "better" than the network
infrastructure in IPv4. It may not be feasible to deploy IPv6 on all
parts of
the network immediately. Dual stacked defense enterprise network
must be interoperable with both IPv4 and IPv6 networks and
applications.
Scenario 3: ..............................IPv6 Dominant Network
Enterprise has some limited IPv4-capable/only nodes/applications
needing to
communicate over the IPv6 infrastructure. Crisis management enterprise
re-structuring an existing network, decides to pursue aggressive IPv6
transition as an enabler for network-centric services and wants to run
some native IPv6-only networks to eliminate cost/complexity of
supporting a
dual stack. Some legacy IPv4 capable nodes/applications within the
enterprise
will have slow technical refresh/replacement path and will need to
communicate
over the IPv6 dominant infrastructure for years
until they are replaced. The IPv6 dominant enterprise network will need
to be
interoperable with it's own legacy networks, commercial networks, and
the
legacy networks of similar organizations that will remain IPv4 dominant
during a long transition period. Reserve units, contractors, other
agencies,
and international partners may need IPv4 service across this
enterprise's
IPv6 dominant backbone.
Assumptions: Required IPv6 network infrastructure is available, or
available
over some defined timeline, supporting the aggressive transition plan.
Requirements:Reduce operation and maintenance requirements and
increase
net-centricity through aggressive IPv6 transition. Interoperation and
coexistence with legacy IPv4 networks and applications is required.
Legacy
IPv4 nodes/applications/networks will need to be able to operate across
the
IPv6 backbone and need to be able to interoperate with the
IPv6-dominant
network's nodes/applications.
Description of a Generic Crisis Management Network
A generic network topology for a crisis management reflects the various
ways
a crisis management network can connect customers through their network
infrastructure. Because the institution's existing wired and fixed site
wireless
infrastructure can be destroyed or unavailable in a crisis, the crisis
management network must be able to deploy it's own mobile wireless
network
or connect through external wired and wireless networks provided by
ISPs or
partner organizations. This infrastructure lets us divide the basic
areas
for IPv4/IPv6 interoperability into three main areas:
the customer applications, the local network, and the network backbone.
The basic components in a crisis management network are depicted in
Figure 1.
------------ ---------- ---- Wired Connection
| Network and| | | .... Wireless Connection
| Service |--| Backbone |
| Operation | | |
------------ ----------
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 25]
Internet Draft IPv6 Enterprise Network Analysis January 2005
/ | ---------------------
/ : _|Connection to |
/ : |Commercial Internet |
/ : --------------------- Network
Backbone
--------------
/------|-------------|--------------------------------
---------- / ---------- ----------
| Home |/ | Wireless | External |.............
| Base | | Mobile | |Untrusted |+--------- :
| Network | | Network | |Network | | :
---------- ---------- ---------- | :
| : : | : Local
Network
-----:------------:---------------------------------------------------
| : : | : Customer
Apps
+--------+ +--------+ +--------+ | :
| | | | | | | :
|Customer| |Customer| |Customer|+----------- :....
| | | | | |..............
+--------+ +--------+ +--------+
Figure 1: Crisis Management Network Topology.
Stages of IPv6 Deployment:
The stages are derived from the generic description of scenarios
for crisis management networks in Section 2. Combinations of
different building blocks that constitute an crisis network
environment lead to a number of scenarios from which the network
engineers can choose. The scenarios most relevant to this document
are those that maximize the network's ability to offer IPv6 to its
customers in the most efficient and feasible way. The assumption in
the first three stages the goal is to offer both IPv4 and IPv6 to
the customer, and that in the distant future all IPv4 services will
be eventually switched to IPv6. This document will cover
engineering the first four stages.
The four most probable stages are:
o Stage 1 Limited Launch
o Stage 2 Dual Stack Dominance
o Stage 3 IPv6 Dominance
o Stage 4 IPv6 Transition Complete
Generally, a crisis management network is able to entirely upgrade
a current IPv4 network to provide IPv6 services via a dual-stack
network in Stage 2 and then slowly progress to stages 3 and 4 as
indicted in Figure 2. During stage 2, When most applications are
IPv6 dominant, operational and maintenance costs can be reduced on
some networks by moving to stage 3 and running backbone networks
entirely on IPv6 while adding IPv4 backwards compatibility via v4
in v6 tunneling or translation mechanisms to the existing
configuration from stage 2. When designing a new network, if a new
IPv6-only service is required, it can be implemented at a lower
cost jumping directly to stage 3/4 if there are only limited/no
legacy concerns.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 26]
Internet Draft IPv6 Enterprise Network Analysis January 2005
Tunnels Dominant dual Full dual Stack
IPv4-only --> or limited --> stacking with --> everywhere, mostly -->
V6
dual stacks transition v6 apps, some
Only
Limited v6 mechanisms in v6 only nets with
Applications backbone transition mechanisms
pushed to legacy v4
nets
Figure 2: Transition Path.
Stage 1 Scenario: Limited Launch
The first stage begins with an IPv4-only network and IPv4
customers. This is the most common case today and the natural
starting point for the introduction of IPv6. During this stage the
enterprise begins to connect individual IPv6 applications run on
dual stacked hosts through host based tunneling using Tunnel
Broker, ISATAP, Teredo. Some early adopter networks are created for
pilot studies and networked together through configured tunnels and
6to4.
The immediate first step consists of obtaining a prefix allocation
typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC,
ARIN, LACNIC, RIPE, ...) according to allocation procedures.
The crisis management enterprise will also need to establish IPv6
connectivity between its home base networks and mobile wireless
networks over it's backbone and negotiate IPv6 service with its
service providers and with peer organizations; it is of utmost
importance to require IPv6 capability or an upgrade plan when
negotiating purchases of network applications and infrastructure.
In the short term, network connections, especially legacy wireless
networks, that cannot provide IPv6 services can provide IPv6
services through the use of tunnels. However, the longer-term goal
must be requiring and obtaining IPv6 native connectivity from the
transit networks, because otherwise the quality of IPv6
connectivity will likely be poor and the transition to stage 2 will
be delayed.
Stage 2 Scenario: Dual Stack Dominance
Stage 2 occurs when most applications, local networks, and network
backbones become dual-stacked so that native IPv6 connections are
enabled. At this point there is a mix of IPv4 and IPv6 applications
and services in use across the enterprise. The enterprise may be
made IPv6-capable through either software upgrades, hardware
upgrades, or a combination of both. Generally IPv6 is added during
normal technical refresh as the enterprise buys new equipment that
is IPv6 ready.
Specialty legacy applications and wireless/satellite networks may
be especially slow to transition to IPv6 capability due to upgrade
costs so plans must be made for backwards compatibility for these
systems. Since some new IPv6 services cannot be provided through
IPv4, and some legacy network connections may not yet be upgraded,
tunneling mechanisms have to be provided on the backbone to provide
IPv6 connectivity through to customer IPv6 applications still
relying on legacy IPv4-only networks. The tunnels may provide
host-based tunneling for individual customers or site-to-site
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 27]
Internet Draft IPv6 Enterprise Network Analysis January 2005
tunnels to connect small IPv6 domains through IPv4 only networks.
If any new applications are IPv6-only rather than dual-stacked, and
need to interact with IPv4-only legacy applications, translators
will be used as a transition mechanism of last resort during this
stage.
Stage 3 Scenario: IPv6 Dominance
Stage 3 occurs when the majority of network services are being
provided by IPv6 so that most network traffic is dominantly IPv6
and the net-centric benefits of IPv6 end-to-end communications,
IPSEC based security, QOS, mobility, and autoconfiguration are
realized. During this stage, some networks and applications will
become native IPv6-only and will have to rely on transition
mechanism for backwards compatibility with IPv4. The switch to
native IPv6 may be pursued to lower the operations and maintenance
cost of network operations and lower the performance overhead
associated with running two stacks on networked systems. During
this stage, IPv4 in IPv6 tunnels are used to provide IPv4 services
to the remaining customers needing these services across IPv6 only
backbones. At this stage requirements for IPv4 compatibility can be
pushed out of the network backbone and to IPv4 end-user networks.
DSTM, with or without tunnel brokers, can be used to provide host-
based tunnels for IPv4 service on local networks that only support
IPv6. Remaining IPv4 dominant networks requiring IPv4 service
across IPv6-only backbones will have to connect through site-to-
site tunnels. Since many new applications are IPv6-only rather than
dual-stacked, legacy IPv4 applications may require translators for
interoperability.
Stage 4 Scenario: IPv6 Only In the future, if IPv6 becomes the only
service required, IPv4 service can be dropped. This transition may
be hastened by the desire to save operational and maintenance costs
by dropping IPv4 services and only supporting one IP family.
Security Concerns
Adding security to IPv6 services requires developing new customer
applications for IPSEC, new firewalls, guards, VPN/encrypters, and
end-user security such as host-based firewalls and virus checkers
for IPv6 attacks. Police, homeland defense, and military crisis
management networks require especially high levels of security and
should begin creation and implementation of their specialized
security architectures as soon as they begin planning for IPv6
transition. New IPv6 features such as MIPv6, stateless address
auto-assignment, and ubiquitous end-user IPSEC will likely not be
compatible with current information-assurance tools that are simply
ported from IPv4 to a minimal IPv6 capability. A complete new
security policy, architecture, and tools will most likely be
required to realize the true net-centric benefits of IPv6 in crisis
networks requiring high security.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 28]
Internet Draft IPv6 Enterprise Network Analysis January 2005
Intellectual Property and Copyright Statements
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
draft-ietf-v6ops-ent-analysis-01.txt Expires June 2005 [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-22 23:16:37 |