[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-v6ops-campus-transition

IPv6 Operations                                                 T. Chown
Internet-Draft                                 University of Southampton
Expires: December 28, 2006                                 June 26, 2006


        IPv6 Campus Transition Scenario Description and Analysis
                 draft-chown-v6ops-campus-transition-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on December 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   In this document we consider and analyse the specific scenario of
   IPv6 transition and deployment in a large department of a university
   campus network.  The department is large enough to operate its own
   instances of all the conventional university services including (for
   example) web, DNS, email, filestore, interactive logins, and remote
   and wireless access.  The scenario is a dual-stack one, i.e.
   transition to IPv6 means deploying IPv6 in the first instance
   alongside IPv4.  This analysis identifies the available (and still
   missing) components for IPv6 transition, while validating the



Chown                   Expires December 28, 2006               [Page 1]


Internet-Draft           IPv6 Campus Transition                June 2006


   applicability of the IPv6 Enterprise Network Scenarios informational
   text.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Site Philosophy  . . . . . . . . . . . . . . . . . . . . .  4
   2.  Discussion of Scenarios Network Infrastructure Components  . .  5
     2.1.  Component 1: Enterprise Provider Requirements  . . . . . .  5
     2.2.  Component 2: Enterprise Application Requirements . . . . .  6
     2.3.  Component 3: Enterprise IT Department Requirements . . . .  7
     2.4.  Component 4: Enterprise Network Management System  . . . .  8
     2.5.  Component 5: Enterprise Network Interoperation and
           Coexistence  . . . . . . . . . . . . . . . . . . . . . . .  9
   3.  Discussion of Network Infrastructure Component Requirements  .  9
     3.1.  DNS  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.2.  Routing  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  Configuration of Hosts . . . . . . . . . . . . . . . . . . 10
     3.4.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.5.  Applications . . . . . . . . . . . . . . . . . . . . . . . 10
     3.6.  Network Management . . . . . . . . . . . . . . . . . . . . 10
     3.7.  Address Planning . . . . . . . . . . . . . . . . . . . . . 10
     3.8.  Multicast  . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.9.  Multihoming  . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Specific Scenario Component Review . . . . . . . . . . . . . . 11
     4.1.  Network Components . . . . . . . . . . . . . . . . . . . . 11
       4.1.1.  Physical connectivity (Layer 2)  . . . . . . . . . . . 11
       4.1.2.  Routing and Logical subnets (Layer 3)  . . . . . . . . 12
       4.1.3.  Firewall . . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.4.  Intrusion Detection System . . . . . . . . . . . . . . 12
       4.1.5.  Management . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.6.  Monitoring . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.7.  Remote access  . . . . . . . . . . . . . . . . . . . . 12
       4.1.8.  IPv6 External Access . . . . . . . . . . . . . . . . . 12
     4.2.  Address Allocation Components  . . . . . . . . . . . . . . 12
       4.2.1.  IPv6 network prefix allocation . . . . . . . . . . . . 13
       4.2.2.  IPv6 Address allocation  . . . . . . . . . . . . . . . 13
     4.3.  Services . . . . . . . . . . . . . . . . . . . . . . . . . 13
       4.3.1.  Email  . . . . . . . . . . . . . . . . . . . . . . . . 13
       4.3.2.  Web Hosting  . . . . . . . . . . . . . . . . . . . . . 14
       4.3.3.  Databases  . . . . . . . . . . . . . . . . . . . . . . 14
       4.3.4.  Directory Services . . . . . . . . . . . . . . . . . . 14
       4.3.5.  DNS  . . . . . . . . . . . . . . . . . . . . . . . . . 14
       4.3.6.  PKI  . . . . . . . . . . . . . . . . . . . . . . . . . 14
       4.3.7.  NTP  . . . . . . . . . . . . . . . . . . . . . . . . . 14
       4.3.8.  Multicast  . . . . . . . . . . . . . . . . . . . . . . 15
       4.3.9.  Remote login . . . . . . . . . . . . . . . . . . . . . 15



Chown                   Expires December 28, 2006               [Page 2]


Internet-Draft           IPv6 Campus Transition                June 2006


       4.3.10. File serving . . . . . . . . . . . . . . . . . . . . . 15
       4.3.11. Backups  . . . . . . . . . . . . . . . . . . . . . . . 15
     4.4.  Host and Device Platforms  . . . . . . . . . . . . . . . . 15
       4.4.1.  Server platforms . . . . . . . . . . . . . . . . . . . 15
       4.4.2.  Desktop/laptop platforms . . . . . . . . . . . . . . . 16
       4.4.3.  PDA platforms  . . . . . . . . . . . . . . . . . . . . 16
     4.5.  User Tools . . . . . . . . . . . . . . . . . . . . . . . . 16
       4.5.1.  Hardware . . . . . . . . . . . . . . . . . . . . . . . 16
       4.5.2.  Mail Client  . . . . . . . . . . . . . . . . . . . . . 16
       4.5.3.  Web Browser  . . . . . . . . . . . . . . . . . . . . . 17
       4.5.4.  Conferencing systems . . . . . . . . . . . . . . . . . 17
       4.5.5.  Other collaboration tools  . . . . . . . . . . . . . . 17
       4.5.6.  Usenet news client . . . . . . . . . . . . . . . . . . 17
       4.5.7.  Host communications  . . . . . . . . . . . . . . . . . 17
     4.6.  Hard-coded address points  . . . . . . . . . . . . . . . . 17
   5.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     5.1.  Dual-Stack Deployment: Procedure . . . . . . . . . . . . . 19
       5.1.1.  Advanced Planning  . . . . . . . . . . . . . . . . . . 19
       5.1.2.  Testbed/Trial Deployment . . . . . . . . . . . . . . . 20
       5.1.3.  Production Deployment  . . . . . . . . . . . . . . . . 20
   6.  Dual-Stack Deployment: Transition toolbox  . . . . . . . . . . 21
   7.  Deployment History . . . . . . . . . . . . . . . . . . . . . . 22
   8.  Missing components . . . . . . . . . . . . . . . . . . . . . . 23
     8.1.  Standards (IETF)-specific  . . . . . . . . . . . . . . . . 23
     8.2.  Vendor or platform-specific  . . . . . . . . . . . . . . . 23
     8.3.  Application-specific . . . . . . . . . . . . . . . . . . . 24
     8.4.  Other (policy, political,...)  . . . . . . . . . . . . . . 24
   9.  Considerations beyond the Scenarios Document . . . . . . . . . 24
   10. Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   14. Informative References . . . . . . . . . . . . . . . . . . . . 25
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
   Intellectual Property and Copyright Statements . . . . . . . . . . 29
















Chown                   Expires December 28, 2006               [Page 3]


Internet-Draft           IPv6 Campus Transition                June 2006


1.  Introduction

   The scope of the enterprise network transition scenarios is very
   large, much more so than that of the other three IPv6 transition
   areas that have been studied within the IETF (ISP [9], unmanaged [7]
   and 3GPP [14]).  The IPv6 Enterprise Network Scenarios [11] have been
   defined.  In this document we present a specific case study area for
   IPv6 transition, namely a large department (1,500 staff and students,
   over 1,000 hosts) in an academic campus network.  The purpose of this
   document in its current form is to both define and analyse the IPv6
   transition of such a network, but also to test the applicability of
   the IPv6 Enterprise Network Scenarios document to a specific example.

   This version of this campus transition draft is an interim release to
   re-initiate discussion of the campus issues.  The work on IPv6
   Enterprise Analysis [23] is now at an advanced stage, and this campus
   transition experience has been fed into that analysis.

   Our campus study falls under "Scenario 1" of the IPv6 Enterprise
   Network Scenarios [11] document, i.e. the campus network is an
   existing IPv4 network, where IPv6 is to be deployed in conjunction
   with the IPv4 network.

   "Scenario 1" has the assumption that the IPv4 network infrastructure
   used has an equivalent capability in IPv6.  This document will
   analyse that assumption.  The Scenario also has requirements, i.e.
   that the existing IPv4 network infrastructure is not disrupted, and
   that IPv6 should be equivalent or better than the network
   infrastructure in IPv4.  The Scenario also notes that it may also not
   be feasible to deploy IPv6 on all parts of the network immediately.

   These assumptions and requirements will be discussed later in this
   text.

   It should also be noted why Scenarios 2 and 3 did not apply to this
   campus transition scenario.  Scenario 2 talks of specific
   applications, but in the campus case we wish to deploy IPv6
   pervasively, in wired and wireless networks, as an enabler for
   education and research, to encourage new application development.
   Scenario 3 focuses on using IPv6 as the basis for most network
   communication, but in the campus we already have a significant IPv4
   deployment that will be utilised for the foreseeable future (Scenario
   3 would perhaps be more appropriate for a greenfield deployment).

1.1.  Site Philosophy

   The site which is the subject of this study is an IPv4 network with
   around 20 existing subnets, using a core network infrastructure that



Chown                   Expires December 28, 2006               [Page 4]


Internet-Draft           IPv6 Campus Transition                June 2006


   combines switch-router functionality in central devices, with
   switches at the network edge.  The main switching equipment is all
   VLAN capable.  There are around 1,000 networked nodes and 1,500
   users, not including transient wireless visitors.

   The site wishes to deploy IPv6 dual-stack to support its own users
   along with its teaching and research needs.  The goal is to IPv6
   enable the network (on the wire) and services (DNS, SMTP, etc) such
   that the whole operation is dual-stack.  This in due course will
   allow IPv6-only devices to be deployed within the fully IPv6-capable
   environment.  Some network links may become IPv6-only in the future.

   This text has evolved over time.  When we began writing, the
   department did not have IPv6 capability on its existing IPv4 routing
   equipment, thus a deployment method was required until the next
   procurement.  We discuss that interim solution within this document,
   and present the discussion from an initial point of an interim
   parallel IPv6 deployment prior to unifying the IPv4 and IPv6 routing
   on a single platform.  Our initial deployment plan used a separate
   IPv6 path into the department with a parallel routing infrastructure
   for IPv6.


2.  Discussion of Scenarios Network Infrastructure Components

   In this section, we look at the issues raised by following the
   Scenarios Network Infrastructure Components of the IPv6 Enterprise
   Network Scenarios [11] document, section 3.2.

2.1.  Component 1: Enterprise Provider Requirements

   The answers to the questions posed in this section of the IPv6
   Enterprise Network Scenarios document are as follows:

   o  There is external access to/from the campus network, regional MAN
      and National Research Network beyond.

   o  There are needs for access by remote staff, student and
      researchers.

   o  It is a single site, with four buildings.

   o  There are no leased lines or wide-area VPNs between remote
      buildings.

   o  The department has 12 IPv4 Class C's, the campus has a Class B,
      independent from its provider (assigned prior to use of CIDR).




Chown                   Expires December 28, 2006               [Page 5]


Internet-Draft           IPv6 Campus Transition                June 2006


   o  The IPv4 and IPv6 provider is the National Research and Education
      Network (JANET in the UK).  JANET provides a /48 prefix for the
      university.  The university offers a /52 prefix for the
      department.

   o  The university and department make their own prefix allocations
      for subnets.

   o  There is no multihoming, and thus no multihomed clients.

   o  The provider offers an IPv6 Tunnel Broker [3] service and a 6to4
      [4] relay, though the campus has native IPv6 connectivity via its
      regional MAN.

   o  There is no external IPv6 routing protocol needed due to the use
      of static route configuration.

   o  There is no external data centre.

   o  IPv6 will run over the same access links to campus as IPv4 does
      (the JANET backbone uses true dual stack, the regional MAN uses
      6PE [19]).  On campus, the IPv4 traffic to the department is
      received through a Nokia IP740 firewall, the IPv6 traffic will be
      received through a BSD firewall.  Thus the access links into the
      department for IPv4 and IPv6 are different, though the goal is to
      make them the same.

2.2.  Component 2: Enterprise Application Requirements

   Answers to the next IPv6 Enterprise Network Scenarios section are as
   follows:

   o  The application inventory is discussed in the specific component
      review in the next section.

   o  We expect the first applications to be moved will be the support
      services, including DNS.  The first applications should be the
      common IPv4 applications, e.g. web, remote login and email, such
      that IPv6 offers as least an equivalent service to IPv4 for the
      core service applications.

   o  The academic environment has a good mix of open source and
      commercial software, predominantly either Microsoft or Linux, but
      with a growing number of Mac OS/X users.  Specific platforms are
      reviewed in the component review in the next main section.  Most
      open source applications have been upgraded to allow IPv6
      operation; others can be upgraded given time.




Chown                   Expires December 28, 2006               [Page 6]


Internet-Draft           IPv6 Campus Transition                June 2006


   o  The general goal is for applications to support both IPv4 or IPv6
      operation, i.e. to be IP agnostic.

   o  There is no use of NAT in the department's network.  Home users,
      or users access into the network remotely from certain locations,
      may experience NAT at their client side.

   o  NAT issues are relevant from the end-to-end perspective, for
      establishment of end-to-end security where desired, and in
      relation to IPv6 transition (remote access) methods that may be
      run through NATs.

   o  There is a mix of internal and external applications.  Where
      limitations occur, it is mainly by policy not technology, e.g. as
      implemented in firewall restrictions.

2.3.  Component 3: Enterprise IT Department Requirements

   Here we list responses to the next IPv6 Enterprise Network Scenarios
   section on IT Department Requirements:

   o  Ownership and support is all in-house.

   o  Remote VPNs are supported.

   o  No inter-site networking is required.

   o  No IP mobility support is required at this point, though we expect
      to use Mobile IPv6 between the department network and a local
      community wireless network, on our wireless LAN deployment as it
      grows in size, and to pilot its use inter-campus.

   o  The IPv6 address plan for the department requires a /52 prefix.

   o  There is no detailed asset database, though one exists providing a
      host inventory (for DNS and DHCP use).

   o  There are no geographically separate sites.

   o  The internal IPv4 address assignment mechanism is DHCP for
      clients, with manual configuration for servers.  We thus expect to
      use DHCPv6 for at least some IPv6 clients.

   o  Internal IPv4 routing is static or uses RIP.  We thus expect to
      use RIPng internally.

   o  We expect our IPv6 network management policy to be very similar to
      that for IPv4.



Chown                   Expires December 28, 2006               [Page 7]


Internet-Draft           IPv6 Campus Transition                June 2006


   o  There is no QoS provision at present, largely due to the ample
      campus bandwidth (1Gbit/s uplink).

   o  Security is applied through many technologies implementing our
      policies, e.g. firewall, email scanning, wireless LAN access
      controls.  We expect similar policies for IPv6, but need to
      analyse differences.

   o  Training will be done in-house.

   o  The impacted software components are discussed in the next main
      section.  Not all functions are upgradeable to IPv6; those that
      are not are discussed in the analysis section.  Some are, e.g. use
      of OpenLDAP in place of MS Active Directory.

   o  The impacted hardware components are discussed in the next main
      section.  Not all hardware is upgradeable, e.g. network printers.
      There are no load balancing systems in use.  There are wireless
      LAN hosts in the network that are mobile, but currently the
      wireless network is a flat IPv4 subnet.  There may be nodes moving
      to external wireless networks (the local community wireless
      network.

2.4.  Component 4: Enterprise Network Management System

   The responses to the next IPv6 Enterprise Network Scenarios section
   are as follows:

   o  No performance management is required.

   o  There are a number of network management and monitoring tools in
      use, which will need to be used in a dual stack or IPv6 mode, e.g.
      the nocol availability monitoring tools, and SNMP-based
      management.

   o  The configuration management may include use of tools to configure
      services including DNS and email.

   o  No policy management and enforcement tools are required.

   o  No detailed security management is required, though we expect to
      manage the implementations including firewalls and intrusion
      detection.

   o  We may need to manage the deployed transition tools and
      mechanisms.





Chown                   Expires December 28, 2006               [Page 8]


Internet-Draft           IPv6 Campus Transition                June 2006


   o  We need to analyse the considerations IPv6 creates for network
      management, e.g. use (or not) of RFC3041 privacy addresses.  The
      need for user privacy is recognised, but the need for simplified
      management is also a strong consideration.

2.5.  Component 5: Enterprise Network Interoperation and Coexistence

   Answers to the final IPv6 Enterprise Network Scenarios section on
   Coexistence are as follows:

   o  The platforms that are required to be IPv6 capable are listed in
      the next main section.

   o  There is only one network ingress and egress point to the site
      that needs to be IPv6 capable; this is a Gigabit Ethernet
      interface.

   o  The required transition mechanisms are discussed in the analysis
      section.  We expect to mainly use the VLAN [17] mechanism for
      internal IPv6 transport, with a parallel IPv6 routing
      infrastructure based on BSD routers, until the core infrastructure
      is able to support IPv6 (via upgrade or a new procurement).

   o  The transition to IPv6 will be enabled on the wire first, enabling
      clients, with a phased introduction of service capability, as
      discussed below in the analysis section.

   o  The preferred mechanism for interoperation with legacy nodes is to
      use dual-stack and thus IPv4 to communicate to IPv4 nodes and IPv6
      to communicate to IPv6 nodes.  We have not identified any in-
      house, non-upgradeable legacy applications.


3.  Discussion of Network Infrastructure Component Requirements

   In this section, we discuss the network infrastructure component
   requirements raised in the IPv6 Enterprise Network Scenarios [11]
   document, in section 4.

3.1.  DNS

   BIND9 is used for our three internal name servers.  The servers will
   be made dual stack, to be available for IPv6 transport for local
   dual-stack or IPv6-only nodes.  The three servers will each be listed
   with AAAA records, and AAAA glue added.






Chown                   Expires December 28, 2006               [Page 9]


Internet-Draft           IPv6 Campus Transition                June 2006


3.2.  Routing

   Internal routing is either statically configured or uses RIP.  We
   thus expect to use RIPng for internal IPv6 routing.  The external
   routing is statically configured for IPv4, and thus is likely to be
   statically configured for IPv6.

3.3.  Configuration of Hosts

   IPv4 clients use DHCP for address and other configuration options.
   We expect to use Dynamic Host Configuration Protocol for IPv6
   (DHCPv6) [5] for IPv6 clients.  This will require analysis of the
   IPv4 and IPv6 Dual-Stack Issues for DHCPv6 [16].  We expect some
   clients, especially in wireless LANs, to use IPv6 Stateless
   Autoconfiguration [1], and these nodes will need support for
   Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6
   [6] for other configuration options, including the IPv6 address of a
   local DNS resolver.

   Although IPv6 offers Stateless Autoconfiguration, it is expected that
   the managed environment will continue, driven from the asset
   database, for some time.  Thus DHCPv6 is required.  Use of Stateless
   Autoconfiguration implies a requirement for dynamic DNS updates for
   such nodes.  It is not yet decided how to apply or enforce that plan;
   it may certainly be flexible with time.

3.4.  Security

   We need to identify new IPv6 related security considerations, and
   those associated with transition mechanisms [20].  Site policies may
   need to be updated as a result.

3.5.  Applications

   The Application Aspects of IPv6 Transition [10] document describes
   best porting practice for applications.  There should also be
   consideration for any required application proxies.

3.6.  Network Management

   The network management and monitoring systems will need to embrace
   IPv6, and any transition mechanisms used to deploy IPv6.  Monitoring
   includes usage tracking (e.g. via MRTG) and availability monitoring
   (e.g. via Nagios).

3.7.  Address Planning

   The department receives 12 Class C prefixes for IPv4 use, and uses



Chown                   Expires December 28, 2006              [Page 10]


Internet-Draft           IPv6 Campus Transition                June 2006


   only globally routable addresses internally.  The IPv4 address space
   for the campus was obtained prior to CIDR, but the IPv6 address space
   is allocated from the UK National Research Network (JANET) address
   space under 2001:0630::/32.  The university receives a /48 prefix,
   which is 2001:0630:d0::/48.  The department has a /52 allocation
   within this block of 2001:0630:d0:0:/52.

   IPv6 address assignment planning is discussed in the IPv6 Unicast
   Address Assignment Considerations [18] text.

3.8.  Multicast

   IPv4 multicast is used for a number of applications, including the
   AccessGrid.  Connectivity is provided via the local campus and
   regional network.  We expect to use both IPv6 ASM (i.e.  PIM-SM), and
   we plan to make use of the Embedded-RP [8] technique.  For bridging
   between IPv4 and IPv6 multicast, we believe an IPv4 - IPv6 multicast
   gateway [21] may prove valuable.  Finally, we expect to make use of
   source specific multicast (SSM) more heavily in IPv6, bringing IPv6
   and SSM together in one deployment cycle.

   The use of IPv6 multicast makes it much simpler for our site to
   generate its own globally unique group addresses than is the case for
   IPv4, where we need to use GLOP space from an upstream provider.

3.9.  Multihoming

   The site is not multihomed.


4.  Specific Scenario Component Review

   Here we describe specific technology in use now in the department.
   Later in this section we discuss any items not included in the above
   section, i.e. those not explicitly mentioned in the IPv6 Enterprise
   Network Scenarios document.  In the next main section we analyse
   these for missing technologies, as a form of gap analysis.

4.1.  Network Components

4.1.1.  Physical connectivity (Layer 2)

   o  Switched Ethernet

   o  Gigabit Ethernet

   o  Wireless networking (802.11b)




Chown                   Expires December 28, 2006              [Page 11]


Internet-Draft           IPv6 Campus Transition                June 2006


4.1.2.  Routing and Logical subnets (Layer 3)

   The hybrid Layer 2/3 routing equipment has approximately 20 internal
   IPv4 subnets (in effect, routed VLANs).  There is no specific
   internal routing protocol used.  There is a static route via the site
   firewall to the main upstream provider (academic) running at 1Gbit/s.

4.1.3.  Firewall

   The firewall is currently Firewall-1 running on a Nokia IP740
   hardware platform.  There is one internal facing interface, one
   external facing interface, and two DMZ interfaces, one for wired
   hosts and one for the Wireless LAN provision.

4.1.4.  Intrusion Detection System

   Snort is used locally for IPv4 IDS.  There is some IPv6 functionality
   in Snort.  The precise requirements of an IPv6 IDS need to be
   understood.

4.1.5.  Management

   Some network management is performed by SNMP; there is no specific
   package for this.  There is a greater emphasis on monitoring than
   explicitly in management.

4.1.6.  Monitoring

   A number of tools are used, to monitor network usage as well as
   systems availability, e.g.  Nagios and MRTG.  The network testing
   tools include iperf, rude and crude.

4.1.7.  Remote access

   o  Livingston Portmaster 56K/ISDN dialup (being phased out)

   o  RADIUS servers (running Radiator)

   o  (Microsoft) VPN servers

4.1.8.  IPv6 External Access

   o  IPv6 connectivity comes via 6PE from our regional network.

4.2.  Address Allocation Components

   The department receives its IPv4 and IPv6 address allocations from
   the University.  For IPv4, the University has a Class B allocation



Chown                   Expires December 28, 2006              [Page 12]


Internet-Draft           IPv6 Campus Transition                June 2006


   which is not aggregated under the JANET NREN.  For IPv6, the
   University receives its allocation from JANET.

4.2.1.  IPv6 network prefix allocation

   For IPv6, JANET has the prefix 2001:630::/32 from RIPE-NCC, as the
   national academic ISP in the UK.  The University has been allocated
   2001:630:d0::/48 by JANET.  The department transitioning will be
   allocated a /52 size prefix under 2001:630:d0::/48, i.e. 2001:630:d0:
   0::/52.

   In the initial deployment, we expect that IPv4 and IPv6 subnets will
   be congruent (and share the same VLANs).  The advantage for IPv6 is
   that subnets will not need to be resized to conserve or efficiently
   utilise address space as is the case currently for IPv4 (as subnet
   host counts rise and fall for administrative or research group
   growth/decline reasons).

4.2.2.  IPv6 Address allocation

   It is expected that the network devices will use a combination of
   address allocation mechanisms:

   o  Manually configured addresses (in some servers)

   o  Stateful DHCPv6 (probably in fixed, wired devices and some
      servers)

   o  Stateless address autoconfiguration (probably in wireless and
      mobile devices)

   o  RFC3041 privacy addresses (in some client devices)

   For devices using stateless or RFC3041 mechanisms, a Stateless DHCPv6
   server will be required for other (non-address) configuration
   options, e.g.  DNS and NTP servers.

4.3.  Services

4.3.1.  Email

   There are three MX hosts for inbound email, and two main internal
   mail servers.  Sendmail is the MTA.  POP and IMAP (and their secure
   versions) are used for mail access, using the Cyrus IMAP open source
   code.  There is an MS Exchange server used by a growing proportion of
   users (generally those wanting shared access to mail spools, e.g.
   professors and secretaries).  MailScanner is used for anti-spam/
   anti-virus.  This uses external services including various RBLs for



Chown                   Expires December 28, 2006              [Page 13]


Internet-Draft           IPv6 Campus Transition                June 2006


   part of its spam checking.  Successful reverse DNS lookup is required
   for sendmail to accept internal SMTP connections for delivery.

4.3.2.  Web Hosting

   Web content hosting is provided either with Apache 2.x (open source)
   or Microsoft IIS 5.0.  Common components used to build systems with
   are MySQL, PHP and Perl; these enable local tools such as Wikis to be
   run.

4.3.3.  Databases

   All database systems are presented to users via a web interface,
   including the financial systems.  In some cases, e.g. student
   records, ODBC-like access is required/used in to/out from the
   department systems to the campus systems.  Databases include: finance
   records, people, projects and publications (offered using ePrints).

4.3.4.  Directory Services

   The following are used:

   o  NIS

   o  LDAP

   o  Active Directory

   o  RADIUS

4.3.5.  DNS

   The three DNS servers are running BIND9.  A DNS secondary is held at
   another UK university site.

4.3.6.  PKI

   The department has at least 10 SSL certificates from Thawte,
   including Web-signing certificates.  No personal certificates are
   supported by the department (though users may have their own).

4.3.7.  NTP

   The JANET NREN offers a stratum 0 NTP server.  The department also
   has a GPS-based NTP server built-in to its own RIPE NCC test traffic
   server and an NTP device from Meinberg.





Chown                   Expires December 28, 2006              [Page 14]


Internet-Draft           IPv6 Campus Transition                June 2006


4.3.8.  Multicast

   PIM-SM IPv4 multicast is facilitated via a dedicated Cisco 7206
   router, using a Rendezvous Point operated by our regional network.
   This supports applications including the IPv4 AccessGrid conferencing
   system.  A number of bugs in the existing IPv4 routing equipment
   prevent heavy use of IPv4 Multicast within the department network
   (another reason that an IPv6 Multicast solution is desirable).  An
   IPv4 Multicast beacon is used for monitoring Multicast.

4.3.9.  Remote login

   Remote login access is offered via ssh, with sftp for file transfer.
   Remote use of insecure protocols such as telnet and ftp is denied by
   the firewall.

4.3.10.  File serving

   The main file servers are SGI systems, hosting large (multi-TB)
   standalone RAID arrays.  The files are offered via NFS and Samba to
   client systems.  Our content (package) distribution server is hosted
   on such a system.

4.3.11.  Backups

   Backups are run over SSH, which is IPv6-enabled.  A site using a
   proprietary remote backup solution may not yet have IPv6 capability.

4.4.  Host and Device Platforms

4.4.1.  Server platforms

   These include:

   o  Windows 2003 server

   o  Windows 2000 server

   o  Windows NT

   o  Solaris 8

   o  Solaris 9

   o  Solaris 10

   o  RedHat Linux




Chown                   Expires December 28, 2006              [Page 15]


Internet-Draft           IPv6 Campus Transition                June 2006


   o  SGI Origin 300 (Irix 6.5.x)

4.4.2.  Desktop/laptop platforms

   These include:

   o  Windows 98, 2000, ME, XP

   o  Linux (various flavours)

   o  MacOS/X

   o  BSD (various flavours)

4.4.3.  PDA platforms

   These include:

   o  Windows CE/.NET, Pocket PC

   o  PalmOS

   o  Familiar Linux on iPaQ

   o  Zaurus (Linux)

4.5.  User Tools

   These are non-exhaustive but representative application/platform
   lists

4.5.1.  Hardware

   o  Networked printers

   o  Networked webcams

4.5.2.  Mail Client

   o  Outlook (various versions)

   o  Eudora

   o  Mutt

   o  Pine





Chown                   Expires December 28, 2006              [Page 16]


Internet-Draft           IPv6 Campus Transition                June 2006


4.5.3.  Web Browser

   o  MS Internet Explorer

   o  Mozilla

   o  Firefox

   o  Safari

   o  Opera

4.5.4.  Conferencing systems

   o  AccessGrid

   o  A dedicated H.323 system

   o  MS Netmeeting

4.5.5.  Other collaboration tools

   o  IRC

   o  Jabber

   o  MSN Messenger

   o  cvs

4.5.6.  Usenet news client

   o  nn

   o  Mozilla

4.5.7.  Host communications

   o  X11

   o  VNC

   o  PC Anywhere

4.6.  Hard-coded address points

   Usage of IPv4 hard-coded addresses is interesting for at least two
   reasons.  One is that it illustrates where IPv6 hard-coded addresses



Chown                   Expires December 28, 2006              [Page 17]


Internet-Draft           IPv6 Campus Transition                June 2006


   may appear, and thus secondly it is useful to analyse which hard-
   coded addresses may be barriers to smooth IPv6 renumbering.  A
   procedure for renumbering has been described in Procedures for
   Renumbering an IPv6 Network without a Flag Day [12].  A non-
   exhaustive list of instances of such addresses includes:

   o  Provider based prefix(es)

   o  Names resolved to IP addresses in firewall at startup time

   o  IP addresses in remote firewalls allowing access to remote
      services

   o  IP-based authentication in remote systems allowing access to
      online bibliographic resources

   o  IP address of both tunnel end points for IPv6 in IPv4 tunnel

   o  Hard-coded IP subnet configuration information

   o  IP addresses for static route targets

   o  Blocked SMTP server IP list (spam sources)

   o  Web .htaccess and remote access controls

   o  Apache .Listen. directive on given IP address

   o  Configured multicast rendezvous point

   o  TCP wrapper files

   o  Samba configuration files

   o  DNS resolv.conf on Unix

   o  Nocol monitoring tool

   o  NIS/ypbind via the hosts file

   o  Some interface configurations

   o  Unix portmap security masks

   o  NIS security masks

   The author is contributing to work in studying things to think about
   in IPv6 renumbering [22], where the above issues will be considered.



Chown                   Expires December 28, 2006              [Page 18]


Internet-Draft           IPv6 Campus Transition                June 2006


5.  Analysis

   We start by noting that our analysis does not include issues relating
   to deployment of new IPv6-specific technology, e.g.  MIPv6.

   The work described in this document is also being fed into the IPv6
   Enterprise Analysis [23] document, currently an ongoing work within
   the IPv6 Operations WG.  The reader is referred in particular to
   Section 4 ("Wide-Scale Dual-Stack Deployment") and Section 7
   ("General issues and applicability for all Scenarios") which were
   directly contributed from the work here.

5.1.  Dual-Stack Deployment: Procedure

   As described in the IPv6 Enterprise Analysis [23] document, the
   scenario here is one of wide-scale dual-stack deployment.  The plan
   for deployment follows the general guidelines of Section 7 of that
   document, though we have expanded that description here from
   subsequent experience.

5.1.1.  Advanced Planning

   A first phase for deployment includes the following actions.

   o  Include IPv6 requirements in all future tenders; consult to
      understand IPv6 specification requirements for tenders.

   o  Speak to your IPv6 ISP to acquire IPv6 address space (a /48
      prefix) for your site; you will need this at some point, so may as
      well acquire the space sooner rather than later.  This will
      include delegation of IPv6 forward and reverse DNS for your site.
      Our campus address space is a /48 prefix allocated by JANET, under
      their prefix of 2001:630::/32.

   o  Deploying basic network services: DNS, routing, host
      configuration.

   o  Establish IPv6 training for operational staff, for administration
      of host and router platforms.

   o  Encourage operational staff to get some IPv6 familiarity by trying
      IPv6 through services such as public IPv6 Tunnel Brokers.

   o  Review IPv6 security issues.  IPv6 is enabled by default on many
      host platforms; this should be considered when enforcing security
      policies on systems and networks.

   Following these action points should allow sites or networks to be



Chown                   Expires December 28, 2006              [Page 19]


Internet-Draft           IPv6 Campus Transition                June 2006


   ready for IPv6 deployment, and to have confidence they understand and
   have control of their current usage of IPv6 (from systems which have
   it enabled by default).

5.1.2.  Testbed/Trial Deployment

   In this stage a site is validating IPv6 for deployment, and will thus
   take actions including the following:

   o  Assign and deploy an IPv6-capable router and (we recommend) a
      firewall or filtering device.

   o  Establish IPv6 connectivity to the IPv6 ISP.  Sites might use a
      tunnelled service, or check for any native IPv6 offering.  In our
      case, the connectivity is native IPv6 from JANET, via the regional
      MAN (using 6PE [19]) and the campus (using a VLAN to carry IPv6
      natively).

   o  Connect testbed host systems on the internal router interface,
      using one subnet prefix (a /64) from the site's allocated IPv6 /48
      prefix.

   o  Enable IPv6 on the host systems, and test IPv6 functions on
      services and applications (e.g.  BIND for DNS, Apache for Web,
      sendmail or exim for mail transport).

   In parallel, other preparation can be undertaken for a production
   deployment:

   o  Survey systems, applications and services for IPv6 capability,
      including management, monitoring and access control devices and
      systems.  The Enterprise Scenarios text as evaluated earlier in
      this document is a good basis to undertake this task from.

   o  Formulate an IPv6 address plan for your site/network.  Our campus
      has allocated the department network a /56 prefix that can grow
      into a /52 prefix, i.e. the department can create in theory up to
      256 IPv6 subnets initially.

   o  Document IPv6-related policies (e.g. use of Privacy Addresses, and
      of stateless or stateful address assignment).

   Once the site is satisfied in the testbed deployment, a production
   deployment can be considered, enabling IPv6 for appropriate services.

5.1.3.  Production Deployment

   A production deployment includes the following action points:



Chown                   Expires December 28, 2006              [Page 20]


Internet-Draft           IPv6 Campus Transition                June 2006


   o  Plan which parts of the network will be IPv6-enabled, and which
      existing subnets will be IPv6-enabled (made dual-stack).  This may
      be certain server subnets, a DMZ, or a Wireless LAN network, for
      example.

   o  Determine how your production IPv6 connectivity will be handled;
      it can (ideally) be via a single dual-stack entry point, or
      through separate IPv4 and IPv6 links.  Examples are given in the
      case study above.

   o  Add IPv6 addresses to your DNS systems, and configure them to
      respond over IPv4 or IPv6 transport.

   o  Deploy IPv6 support in appropriate management and monitoring
      tools.

   o  Enable IPv6 in selected production services and applications (e.g.
      Apache or IIS for web servers).  The case study above shows that
      DNS, mail (MX) and web services have been shown to be robust in
      dual-stack mode.

   o  Include IPv6 transport in all ongoing security audit/penetration
      tests.

   o  Support IPv4-IPv6 interworking.  As there are not (yet) any IPv6-
      only links on our site, interworking methods are not required.
      Should IPv6-only devices be deployed on the dual-stack
      infrastructure, we anticipate using proxy tools (web cache, SMTP
      relay, etc) to support their access to legacy IPv4 services.

   o  Supporting remote users.  These may connect via an IPv4 VPN and
      then use an IPv6 connection over that VPN, or use the remote IPv6
      services of your ISP (e.g. our ISP, JANET, runs a tunnel broker
      and a 6to4 relay.

   The depth of the IPv6 deployment may vary from site to site.  By
   enabling key services you make your site ready for fuller deployment,
   and gain confidence and experience in the technology, which is good
   for your support staff, your students and staff and researchers.


6.  Dual-Stack Deployment: Transition toolbox

   We have used the following mechanisms in our department transition
   plan:

   o  VLANs [17] to distribute IPv6 connectivity over the non-dual-stack
      capable network infrastructure.  This VLAN solution is an interim



Chown                   Expires December 28, 2006              [Page 21]


Internet-Draft           IPv6 Campus Transition                June 2006


      step until full dual protocol capable equipment is deployed;

   o  An Tunnel broker [3] for remote access, supported by our IPv6 ISP.
      We initially deployed our own tunnel broker, but now refer our
      home and roaming users to the JANET supported solution;

   o  A 6to4 [4] relay for remote access, supported by our IPv6 ISP.
      Again, we used to run our own relay, but the relay operated by our
      IPv6 ISP is perfectly adequate at this time.

   We considered deploying a Teredo [15] relay to support home users
   behind NATs, but chose not to do so since the tunnel broker service
   supports NAT traversal, and we feel it offers better management and
   monitoring facilities.  This decision may be reviewed should Windows
   Vista ship with Teredo enabled by default.

   We do NOT currently see a requirement for:

   o  NAT-PT [2], because we are dual-stack with no IPv6-only networks
      (yet), and as we introduce such networks, or IPv6-only nodes in
      the dual-stack networks, we expect to use application layer
      gateways and proxies for legacy IPv4 access.  If and when we do
      deploy an IPv6-only link, we would look at DSTM as a solution in
      preference NAT-PT;

   o  ISATAP [13], because we prefer to use a structured internal IPv6
      deployment, and are doing so in a pervasive fashion (i.e. not as a
      sparse deployment);

   o  Teredo [15], as our remote users are capable of using other access
      methods.


7.  Deployment History

   Within our network we initially deployed IPv6 in parallel to IPv4,
   using the VLAN method cited above.  This allowed us to pilot IPv6
   without risking adverse impact on our existing IPv4 platforms.  The
   VLAN method was used for over two years.  Towards the end of its use,
   the BSD platforms used to facilitate this were showing signs of
   strain under the load.  We have since deployed a unified IPv4 and
   IPv6 routing platform from a single vendor, which met all our IPv4
   and IPv6 procurement requirements for IPv4 and IPv6 unicast and
   multicast functions, including but not limited to:

   o  IPv6 unicast routing protocols;





Chown                   Expires December 28, 2006              [Page 22]


Internet-Draft           IPv6 Campus Transition                June 2006


   o  IPv6 multicast routing protocols (PIM-SM, SSM);

   o  IPv6 multicast Embedded-RP support;

   o  IPv6 multicast MLD(v1 and v2) snooping.


8.  Missing components

   Our ongoing gap analysis for technology includes the following
   missing components.

8.1.  Standards (IETF)-specific

   o  No method available to offer reverse IPv6 DNS for sendmail to
      verify autoconfiguring hosts (prepopulating a 64 bit subnet space
      is a problem, some wildcard method is required).

8.2.  Vendor or platform-specific

   o  During early 2005, there was no IPv6 Layer 3 functionality on the
      department's Ethernet switch/routing equipment; we thus used the
      parallel VLAN method.  We now have IPv6-capable routing equipment
      deployed since August 2005;

   o  Lack of NFS/Samba IPv6 support;

   o  No IPv6 support for Active Directory;

   o  Lack of supported IPv6 for Windows 98/2000/ME;

   o  Lack of supported IPv6 for Irix;

   o  Lack of supported IPv6 for various PDA platforms;

   o  Lack of MLDv2 (or MLDv1) snooping in some legacy Ethernet switch
      equipment (thus IPv6 Multicast will flood subnets).  Our newly
      procured equipment does support this;

   o  No available IPv6-enabled X11 (there is an xfree but it is
      encumbered by an unpopular copyright statement that most
      distributors find unacceptable);

   o  No support for IPv6 hotspot access control via web-redirection
      systems;

   o  Few DHCPv6 server implementations, very few client
      implementations;



Chown                   Expires December 28, 2006              [Page 23]


Internet-Draft           IPv6 Campus Transition                June 2006


   o  IPv6 management platforms to recognise multi-addressed nodes as
      single nodes, including use of RFC3041 addresses;

   o  IPv6 functions to be researched and implemented for IDS systems.

8.3.  Application-specific

   o  Lack of MS Exchange, Outlook, Eudora or VPN IPv6 support;

   o  AccessGrid is IPv4-only (initial IPv6-enabling work was undertaken
      in the 6NET project);

   o  Some Apache 2 modules lack Apache 1.3 functionality, hence
      migrating is a problem in a small number of cases;

8.4.  Other (policy, political,...)

   o  The migration from ip6.int to ip6.arpa is underway, but still a
      few remnants to repair.


9.  Considerations beyond the Scenarios Document

   Here we mention issues or scenario components that were not
   explicitly listed in the IPv6 Enterprise Network Scenarios document.
   Due to the scope, that document could not embrace all details.  We
   mention here components that other sites may also wish to consider:

   o  Support for WLAN and other access control.  One solution is to use
      802.1x which is IP-agnostic as a Layer 2 port control mechanism.

   o  Consideration for hard-coded addresses.


10.  Summary

   In this document we have analysed the specific campus transition
   scenario for the author's site, and reported the analysis for the
   benefit of others who may be in a similar scenario, or for whom parts
   of the scenario are relevant.  Our current status is that the core
   department routing infrastructure is now dual-protocol capable, and
   we run both IPv4 and IPv6 on the wire with congruent subnets.  The
   deployment has now been in full dual-stack operation, with key
   services enabled (including DNS, SMTP, web) without adverse effects.
   The VLAN-based interim step was useful for two years until a dual-
   protocol solution could be procured.

   We plan further updates of this text; input is welcomed.



Chown                   Expires December 28, 2006              [Page 24]


Internet-Draft           IPv6 Campus Transition                June 2006


   The address planning element of our campus deployment is being
   discussed in a separate addressing considerations [18] text.


11.  Acknowledgements

   Discussions with fellow participants on the 6NET and Euro6IX projects
   have been valuable.


12.  IANA Considerations

   The document contains no IANA considerations.


13.  Security Considerations

   There are no specific new considerations from this scenario
   description and analysis.

14.  Informative References

   [1]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [2]   Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
         Protocol Translation (NAT-PT)", RFC 2766, February 2000.

   [3]   Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
         Tunnel Broker", RFC 3053, January 2001.

   [4]   Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
         IPv4 Clouds", RFC 3056, February 2001.

   [5]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", RFC 3315, July 2003.

   [6]   Droms, R., "Stateless Dynamic Host Configuration Protocol
         (DHCP) Service for IPv6", RFC 3736, April 2004.

   [7]   Huitema, C., Austein, R., Satapati, S., and R. van der Pol,
         "Evaluation of IPv6 Transition Mechanisms for Unmanaged
         Networks", RFC 3904, September 2004.

   [8]   Savola, P. and B. Haberman, "Embedding the Rendezvous Point
         (RP) Address in an IPv6 Multicast Address", RFC 3956,
         November 2004.



Chown                   Expires December 28, 2006              [Page 25]


Internet-Draft           IPv6 Campus Transition                June 2006


   [9]   Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola,
         "Scenarios and Analysis for Introducing IPv6 into ISP
         Networks", RFC 4029, March 2005.

   [10]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro,
         "Application Aspects of IPv6 Transition", RFC 4038, March 2005.

   [11]  Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
         June 2005.

   [12]  Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering
         an IPv6 Network without a Flag Day", RFC 4192, September 2005.

   [13]  Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-
         Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214,
         October 2005.

   [14]  Wiljakka, J., "Analysis on IPv6 Transition in Third Generation
         Partnership Project (3GPP) Networks", RFC 4215, October 2005.

   [15]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network
         Address Translations (NATs)", RFC 4380, February 2006.

   [16]  Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
         Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack
         Issues", RFC 4477, May 2006.

   [17]  Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in
         Enterprise Networks", draft-ietf-v6ops-vlan-usage-01 (work in
         progress), March 2006.

   [18]  Velde, G., "IPv6 Unicast Address Assignment Considerations",
         draft-ietf-v6ops-addcon-00 (work in progress), June 2006.

   [19]  Clercq, J., "Connecting IPv6 Islands over IPv4 MPLS using IPv6
         Provider Edge Routers  (6PE)", draft-ooms-v6ops-bgp-tunnel-06
         (work in progress), January 2006.

   [20]  Davies, E., "IPv6 Transition/Co-existence Security
         Considerations", draft-ietf-v6ops-security-overview-04 (work in
         progress), March 2006.

   [21]  Venaas, S., "An IPv4 - IPv6 multicast gateway",
         draft-venaas-mboned-v4v6mcastgw-00 (work in progress),
         February 2003.

   [22]  Chown, T., "Things to think about when Renumbering an IPv6
         network", draft-chown-v6ops-renumber-thinkabout-04 (work in



Chown                   Expires December 28, 2006              [Page 26]


Internet-Draft           IPv6 Campus Transition                June 2006


         progress), March 2006.

   [23]  Bound, J., "IPv6 Enterprise Network Analysis",
         draft-ietf-v6ops-ent-analysis-06 (work in progress), June 2006.















































Chown                   Expires December 28, 2006              [Page 27]


Internet-Draft           IPv6 Campus Transition                June 2006


Author's Address

   Tim Chown
   University of Southampton
   School of Electronics and Computer Science
   Southampton, Hampshire  SO17 1BJ
   United Kingdom

   Email: tjc@ecs.soton.ac.uk










































Chown                   Expires December 28, 2006              [Page 28]


Internet-Draft           IPv6 Campus Transition                June 2006


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 (2006).  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.




Chown                   Expires December 28, 2006              [Page 29]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/