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

Versions: 00 01 draft-ietf-v6ops-nap

Network Working Group                                    G. Van de Velde
Internet-Draft                                                   T. Hain
Expires: April 12, 2005                                         R. Droms
                                                           Cisco Systems
                                                            B. Carpenter
                                                         IBM Corporation
                                                                E. Klein
                                                             TTI Telecom
                                                        October 12, 2004


                  IPv6 Network Architecture Protection
                  <draft-vandevelde-v6ops-nap-00.txt>

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 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.

   This Internet-Draft will expire on April 12, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   Although there are many perceived benefits to Network Address
   Translation (NAT), the primary benefit of "amplifying" available



Van de Velde, et al.     Expires April 12, 2005                 [Page 1]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   address space is not needed in IPv6.  In addition to its many serious
   disadvantages there is a perception that other benefits exist, such
   as a variety of management and security reasons that could be useful
   for an Internet Protocol.  IPv6 does not support NAT by design and
   this document shows how Network Architecture Protection (NAP) using
   IPv6 can provide the benefits without the need for NAT.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Perceived benefits of NAT and its impact on IPv4 . . . . . . .  4
     2.1   Simple gateway between Internet and internal network . . .  5
     2.2   Simple security due to stateful filter implementation  . .  5
     2.3   User/Application tracking  . . . . . . . . . . . . . . . .  5
     2.4   Privacy and topology hiding  . . . . . . . . . . . . . . .  6
     2.5   Independent control of addressing in a private network . .  6
     2.6   IPv4 and address allocation dynamics with NAT devices  . .  7
       2.6.1   Medium/large private networks  . . . . . . . . . . . .  7
       2.6.2   Small private networks . . . . . . . . . . . . . . . .  8
       2.6.3   Single user connection . . . . . . . . . . . . . . . .  8
       2.6.4   ISP/Carrier customer networks  . . . . . . . . . . . .  8
     2.7   Multihoming and renumbering with NAT . . . . . . . . . . .  9
   3.  Description of the IPv6 tools  . . . . . . . . . . . . . . . .  9
     3.1   Privacy addresses (RFC 3041) . . . . . . . . . . . . . . .  9
     3.2   Unique Local Addresses . . . . . . . . . . . . . . . . . . 10
     3.3   DHCPv6 prefix delegation . . . . . . . . . . . . . . . . . 10
     3.4   Untraceable IPv6 addresses . . . . . . . . . . . . . . . . 10
     3.5   Route-injection  . . . . . . . . . . . . . . . . . . . . . 11
   4.  Using IPv6 technology to provide the market perceived
       benefits of NAT  . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1   Simple gateway between Internet and internal network . . . 11
     4.2   IPv6 and Simple security . . . . . . . . . . . . . . . . . 11
     4.3   User/Application tracking  . . . . . . . . . . . . . . . . 13
     4.4   Privacy and topology hiding using IPv6 . . . . . . . . . . 13
     4.5   independent control of addressing in a private network . . 14
     4.6   IPv6 and address allocation dynamics . . . . . . . . . . . 14
       4.6.1   Medium/large private networks  . . . . . . . . . . . . 14
       4.6.2   small private networks . . . . . . . . . . . . . . . . 16
       4.6.3   Single user connection . . . . . . . . . . . . . . . . 16
       4.6.4   ISP/Carrier customer networks  . . . . . . . . . . . . 16
     4.7   Multihoming and renumbering  . . . . . . . . . . . . . . . 17
   5.  Additional benefits due to Native IPv6 and universal
       unique addressing  . . . . . . . . . . . . . . . . . . . . . . 17
     5.1   Universal any-to-any connectivity  . . . . . . . . . . . . 18
     5.2   Auto-configuration . . . . . . . . . . . . . . . . . . . . 18
     5.3   Native Multicast services  . . . . . . . . . . . . . . . . 18
     5.4   Increased security protection  . . . . . . . . . . . . . . 19
     5.5   Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 19



Van de Velde, et al.     Expires April 12, 2005                 [Page 2]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


     5.6   Merging networks . . . . . . . . . . . . . . . . . . . . . 20
     5.7   Community of interest  . . . . . . . . . . . . . . . . . . 20
   6.  IPv6 gap analysis  . . . . . . . . . . . . . . . . . . . . . . 20
     6.1   Completion of work on ULAs . . . . . . . . . . . . . . . . 20
     6.2   How to completely hide subnet topology . . . . . . . . . . 21
     6.3   Minimal traceability of privacy addresses  . . . . . . . . 21
     6.4   Renumbering procedure  . . . . . . . . . . . . . . . . . . 21
     6.5   Site multihoming . . . . . . . . . . . . . . . . . . . . . 21
     6.6   Untraceable addresses  . . . . . . . . . . . . . . . . . . 21
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   9.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 22
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
       Intellectual Property and Copyright Statements . . . . . . . . 25



































Van de Velde, et al.     Expires April 12, 2005                 [Page 3]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


1.  Introduction

   The serious disadvantages of ambiguous "private" address space and of
   Network Address Translation (NAT) [2][4] have been well documented
   [3][5].  However, given its wide market acceptance NAT undoubtedly
   has some perceived benefits.  Indeed, in an Internet model based on
   universal any-to-any connectivity, product marketing departments have
   driven a perception that some connectivity and security concerns can
   only be solved by using a NAT device or by using logically separated
   LAN address spaces.  This document describes the market perceived
   reasons to utilize a NAT device in an IPv4 environment and shows how
   these needs can be met and even exceeded with native IPv6.  The use
   of the facilities from IPv6 described in this document avoids the
   negative impacts of translation and may be described as Network
   Architecture Protection (NAP).

   As far as security and privacy is concerned, this document considers
   how to mitigate a number of threats.  Some are obviously external,
   such as having a hacker try to penetrate your network, or having a
   worm infected machine outside your network trying to attack it.  Some
   are local such as a disgruntled employee disrupting business
   operations,or the unintentional negligence of a user download some
   malware which then proceeds to attack any device on the LAN.  Some
   may be embedded such as having some firmware in a domestic appliance
   "call home" to its manufacturer without the user's consent.

   This document describes several techniques that may be combined on an
   IPv6 site to protect the integrity of its network architecture.
   These techniques, known collectively as NAP, retain the concept of a
   well defined boundary between "inside" and "outside" the private
   network, and allow firewalling, topology hiding, and privacy and
   achieve these goals without address translation.

   This document first identifies the perceived benefits of NAT in more
   detail, and then shows how IPv6 NAP can provide each of them.  It
   concludes with a reminder of the other benefits of the enlarged IPv6
   address space, and a gap analysis of work that remains to be done.

2.  Perceived benefits of NAT and its impact on IPv4

   This section provides visibility into the generally perceived
   benefits of the use of IPv4 NAT.  The goal of this description is not
   to analyze these benefits or discus the rightfulness of the
   perception, but to identify the connectivity and security
   prerequisites to deploy IPv6 to functionally replace IPv4 combined
   with a NAT device.





Van de Velde, et al.     Expires April 12, 2005                 [Page 4]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


2.1  Simple gateway between Internet and internal network

   A NAT device can connect a private network with any kind of address
   (ambiguous [RFC 1918] or global registered address) towards the
   Internet.  The address space of the private network can be built from
   globally unique addresses, from ambiguous addresses space or from
   both simultaneously.  Without specific configuration from public to
   private, the NAT device enables access between the client side of an
   application in the private network with the server side in the public
   Internet.

   Wide-scale deployments have shown that attaching a private network to
   the Internet is simple and practical for the non-technical end user.
   Frequently a simple user interface is sufficient for configuring both
   device and application access rights.  Additional, thanks to
   successful marketing campaigns it is perceived by end users that
   their equipment is protected from the bad-elements and attackers on
   the public IPv4 Internet.

2.2  Simple security due to stateful filter implementation

   It is frequently believed that a NAT device puts in an extra barrier
   to keep the private network protected from evil outside influences
   due to the stateful character of NAT technology (to protect against
   hackers, worms, etc..).  This benefit may be partially real; however,
   experienced hackers are well aware of NAT devices and are very
   familiar with the private address space, and hence the secure feeling
   is in vain.

   Address translation does not provide security on itself; for example,
   consider a configuration with static NAT translation and all ports
   translating to a single machine.  In such a scenario the security
   risk for that machine is identical as if there were no NAT device in
   the communication path.  As result there is no specific security
   value in the address translation function.  The perceived security
   comes from the lack of pre-established mapping state.  Dynamically
   establishing state in response to internal requests reduces the
   threat of unexpected external connections to internal devices.

2.3  User/Application tracking

   Due to the fact that NAT is a stateful technology, it could provide
   limited capabilities for the administrator of the NAT to gather
   information about who in the private network is requesting access to
   which Internet location.  This can be done by checking the network
   address translation details of the private and the public addresses
   of the NAT devices state-database.




Van de Velde, et al.     Expires April 12, 2005                 [Page 5]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   The checking of this database is not always a simple task, especially
   if Port Address Translation is used.  It also has an unstated
   assumption that the administrative instance has a mapping between an
   IPv4-address and a network element or user at all times, or the
   administrator has a time-correlated list of the address/port
   mappings.

2.4  Privacy and topology hiding

   The ability NAT to provide internet access by the use of a single (or
   few) global IPv4 routable addresses to a large community of users
   offers a simple mechanism to hide the internal topology of a network.
   In this example the large community will be reflected in the internet
   by a single (or few) IPv4 address(es).

   The use of NAT then results in a user behind a NAT gateway actually
   appearing on the Internet as a user inside the NAT box itself; i.e.,
   the IPv4 address that appears on the Internet is only sufficient to
   identify the NAT.  Thus it is impossible to tell from the outside
   which member of a family, which customer of an Internet caf‰, or
   which employee of a company generated or received a particular
   packet, if concealed behind NAT.  Thus, although NATs do nothing to
   provide application level privacy, they do prevent the external
   tracking and profiling of individual host computers by means of their
   IP addresses.  At the same time it creates a smaller pool of
   addresses for a much more focused point of attack.

   Some enterprises prefer to hide as much as possible of their internal
   network topology from outsiders.  Mostly this is achieved by blocking
   "traceroute" etc., but NAT of course entirely hides the internal
   subnet topology, which some network managers believe is a useful
   precaution to mitigate scanning attacks.

   Once a list of available devices and IP addresses has been mapped, a
   port-scan on these IP addresses can be performed.  A port scan is an
   automated procedure of initiating sessions on every specified TCP
   port to see whether the host replies.  If it does, a service is
   running on the target port of the machine.  Different services run on
   default ports.  For example, FTP usually runs on port 21, and HTTP
   usually runs on port 80.  These open port cold be used for initiating
   attacks on an end system.

2.5  Independent control of addressing in a private network

   Due to the ongoing depletion of the IPv4 address range, the remaining
   pool of unallocated IPv4 addresses is below 30%.  Recent consumption
   rates are over 7% of the total IPv4 space per year.  This run rate
   leaves about 4 years to deplete the remaining unallocated pool.  A



Van de Velde, et al.     Expires April 12, 2005                 [Page 6]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   direct result of this is that the administrative cost of a globally
   unique and routable IPv4 address will continue increasing as
   allocation policies tighten so that they become more difficult to
   obtain.  Due to these increased administrative barriers, many
   Internet Service Providers (ISPs) decide to use addresses based on
   RFC 1918 for various services they provide, and use NAT to provide
   global Internet connectivity for some end-customers.  This type of
   local control of address resources allow a clean and hierarchical
   addressing structure in the network that is not restricted by the
   size of the publicly routed address pool.

   Many private IPv4 networks take benefit from using the address space
   defined in RFC 1918 to enlarge the available addressing space for
   their private network, and at the same time reduce their need for
   globally routable addresses.  This type of local control of address
   resources allow a clean and hierarchical addressing structure in the
   network.

   Another benefit is due to the usage of independent addresses on
   majority of the network infrastructure there is an increased ability
   to change provider with less operational difficulties.

2.6  IPv4 and address allocation dynamics with NAT devices

   Based on the amount of connections and required network services the
   network design and addressing dynamics are different.  It is possible
   to differentiate the type of networks in four different types:

   o  Medium/large private networks (typically >10 connections)
   o  Small private networks (typically 1 to 10 connections)
   o  Single user connection (typically 1 connection)
   o  ISP/Carrier customer networks


2.6.1  Medium/large private networks

   Under this category fall the majority of private enterprise networks.
   Many of these networks have one or more exit points to the Internet.
   There are several reasons why NAT be be used in such a network.  For
   the ISP there is no need to import the IPv4 address range from the
   remote end-customer, which facilitates IPv4 address summarization.
   The customer can use a larger IPv4 address range (probably with
   less-administrative overhead) by the use of RFC 1918 and NAT.  The
   customer also reduces the overhead in changing to a new ISP, because
   the addresses assigned to devices behind the NAT do not need to be
   changed when the customer is assigned a different address by a new
   ISP.  Finally, the customer can provide privacy about its hosts and
   the topology of its internal network if the internal addresses are



Van de Velde, et al.     Expires April 12, 2005                 [Page 7]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   mapped through NAT.

2.6.2  Small private networks

   This category describes those networks which have few routers in the
   topology, and have a single network egress point.  These networks are
   also known as SOHO (Small Office/Home Office) networks.  Typically
   these networks don't have dedicated Network Operation Center (NOC)
   and are using either a dial-up connection or broadband access.  In
   many cases the received global IPv4 prefix is not fixed and may add
   an administrative overhead for address management to the user.  An
   ISP will typically have a higher cost attached to a dedicated user
   IPv4 address due to his own higher administration costs with this
   type of addresses.

   Small networks typically deploy RFC 1918 addressing internally to
   limit the explicit charges for a dedicated publicly routable
   addresses.  This approach also has the advantage of avoiding the
   administrative overhead and dedicated NOC associated with acquiring
   blocks of publicly routed address space.

2.6.3  Single user connection

   This group identifies the users which are connected via a single IPv4
   address and use a single piece of equipment (PC, PDA, etc.).  This
   user may get an ambiguous IPv4 address from the service provider
   which is based on RFC 1918.  If ambiguous addressing is utilized, the
   service provider will execute NAT on the allocated IPv4 address for
   global Internet connectivity.  This also limits the internet
   capability of the equipment to being mainly a receiver of Internet
   data, and makes it quite hard for the equipment to become a world
   wide internet server (i.e.  HTTP, FTP, etc.) due to the stateful
   operation of the NAT equipment.

2.6.4  ISP/Carrier customer networks

   This group refers to the actual service providers that are providing
   the IP access.  They tend to have three separate IP domains that they
   support.  For the first they fall into the Medium/large private
   networks category (above) for their own internal networks, LANs etc.
   The second is their Operations network which addresses their backbone
   and access switches, and other hardware, this is separate for both
   engineering reasons as well as simplicity in managing the security of
   the backbone.  The third is the IP addresses (single or blocks) that
   they assign to customers.  These can be registered addresses (usually
   given to category a and b and sometimes c) or can from a pool of RFC
   1918 addresses used with NAT for single user connections.  Therefore
   they can actually have two different NAT domains that are not



Van de Velde, et al.     Expires April 12, 2005                 [Page 8]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   connected (internal LAN and single user customers).

2.7  Multihoming and renumbering with NAT

   The elements of multihoming and renumbering are quite different.
   Multihoming is often a transitioning state for renumbering, however
   NAT interacts with both in the same way.

   For enterprise networks, it is highly desirable to be connected to
   more than one Internet Service Provider (ISP) and to be able to
   change ISPs at will.  This means that a site must be able to operate
   under more than one CIDR prefix [1] and/or readily change its CIDR
   prefix.  Unfortunately, IPv4 does not allow for either of these
   maneuvers.  However, if a site is connected to its ISPs via NAT
   boxes, only those boxes need to deal with multihoming issues or to be
   renumbered.

   Similarly, if two enterprise IPv4 networks need to be merged, it may
   well be that installing a NAT box between them will avoid the need to
   renumber one or both.  For any enterprise, this can be a short term
   financial saving, and allow more time to renumber the network
   components.  The longterm solution is a single network without usage
   of NAT to avoid the ongoing operational complexity of overlapping
   addresses

3.  Description of the IPv6 tools

   This section describes several features that can be used to provide
   the protection features associated with IPv4 NAT.

3.1  Privacy addresses (RFC 3041)

   Nodes use IPv6 stateless address autoconfiguration to generate
   addresses without the necessity of a Dynamic Host Configuration
   Protocol (DHCP) server.  Addresses are formed by combining network
   prefixes with an interface identifier.  On interfaces that contain
   embedded IEEE Identifiers, the interface identifier is typically
   derived from it.  On other interface types, the interface identifier
   is generated through other means, for example, via random number
   generation.  RFC 3041 describes an extension to IPv6 stateless
   address autoconfiguration for interfaces whose interface identifier
   is derived from an IEEE identifier [6].  Use of the privacy address
   extension causes nodes to generate global-scope addresses from
   interface identifiers that change over time, even in cases where the
   interface contains an embedded IEEE identifier.  Changing the
   interface identifier (and the global-scope addresses generated from
   it) over time makes it more difficult for eavesdroppers and other
   information collectors to identify when different addresses used in



Van de Velde, et al.     Expires April 12, 2005                 [Page 9]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   different transactions actually correspond to the same node.

   There is nothing that prevents a DHCP server from running RFC 3041
   for any new MAC it hears, then remembering that for future queries.
   This would allow using them in DNS for registered services since the
   assumption would be a persistent value that minimizes DNS churn.

3.2  Unique Local Addresses

   A unique local address (ULA) is an IPv6 unicast address format that
   is globally unique and is intended for local communications [12].
   These are expected NOT to be routed on the global Internet.  They are
   routable inside of a more limited area defined by a local network
   administrator.

   ULAs have the following characteristics:
   o  Globally unique prefix.
   o  Well known prefix to allow for easy filtering at network
      boundaries
   o  Allows networks to be combined or privately interconnected without
      creating any address conflicts or requiring renumbering of
      interfaces using these prefixes.
   o  ISP independent and can be used for communications inside of a
      network without having any permanent or intermittent Internet
      connectivity
   o  If accidentally leaked outside of a network via routing or DNS,
      there is no conflict with any other addresses
   o  In practice, applications may treat these addresses like global
      scoped addresses

3.3  DHCPv6 prefix delegation

   The Prefix Delegation (DHCP-PD) options [8] provide a mechanism for
   automated delegation of IPv6 prefixes using the Dynamic Host
   Configuration Protocol (DHCP) [7].  This mechanism (DHCP-PD) is
   intended for delegating a long-lived prefix from a delegating router
   to a requesting router, across an administrative boundary, where the
   delegating router does not require knowledge about the topology of
   the links in the network to which the prefixes will be assigned.

3.4  Untraceable IPv6 addresses

   These are globally routable IPv6 addresses which can be randomly and
   dynamically assigned to IPv6 devices and are globally aggregatable
   addresses assigned to the local network by either a registry or
   connecting ISP.  The random assignment has as purpose to confuse the
   outside world on the structure of the local network, while for the
   local network the location of the randomly assigned IPv6 address is



Van de Velde, et al.     Expires April 12, 2005                [Page 10]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   known and connectivity inside the local network can exist.  The goal
   is to create a network infrastructure which appears from external
   networks with an unpredictable structure, to avoid malicious events
   to happen to the local network.  When using untraceable IPv6
   addresses, it may be that two apparently sequential addresses are
   reachable on very different parts of the local network instead of
   belonging to the same subnet next to each other.

3.5  Route-injection

   To complement the untraceable IPv6 addresses, it will be required to
   implement a mechanism to correlate the IPv6 address with the location
   of the device using the IPv6 untraceable address.  This can be done
   by injecting the dynamic allocated untraceable addresses into a
   routing protocol.

4.  Using IPv6 technology to provide the market perceived benefits of
   NAT

   The facilities in IPv6 can be used to provide the protection
   perceived to be associated with IPv4 NAT.  This section gives some
   examples of how IPv6 can be used securely.

4.1  Simple gateway between Internet and internal network

   The connection creation towards the global Internet hosts/systems
   will always happen with global IPv6 addresses.  An enterprise will
   typically receive a global IPv6 address prefix from his connecting
   IPv6 Service Provider.

4.2  IPv6 and Simple security

   The vulnerability of an IPv6 host is similar as for an IPv4 host
   directly connected towards the Internet, and firewall and IDS systems
   are recommended.  However, with IPv6, the following protections are
   available without the use of NAT:

   1.  Short lifetimes on privacy extension suffixes reduce the attack
       profile since the node will not respond to the address once the
       address is no longer valid.
   2.  IPsec is a mandatory service for IPv6 implementations.  IPsec
       functions to prevent session hijacking, prevent content
       tampering, and optionally masks the packet contents.  While IPsec
       might be available in IPv4 implementations, deployment in NAT
       environments either breaks the protocol or requires complex
       helper services with limited functionality.
   3.  The size of the typical subnet ::/64 will make a network ping
       sweep and resulting port-scan virtually impossible due to the



Van de Velde, et al.     Expires April 12, 2005                [Page 11]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


       amount of possible combinations available

   IPv4 NAT was not developed as security mechanism.  Despite marketing
   messages to the contrary it is not a security mechanism, and hence it
   will pose some security holes while many people assume their network
   is secure due to the usage of NAT.  This is directly the opposite of
   what IPv6 security best-practices are trying to achieve.

   An example of a potential rule could be:

           Source_A:    IPv6 Home broadband user
                           located on the internal network
           Destination_B:  IPv6 HTTP server
                           located on the external network

           On the edge broadband router a security rule could be:

           Internal network -> external network:

          Actions:
               Allow all traffic
               Create reflective session state (true) for the session

           External network -> internal network

          Actions:
            If the session had reflective 'true'-state,
                 then allow the inbound traffic
            If the session had reflective 'false' state,
                 then drop the traffic

   This simple rule would create similar protection and security holes
   the typical IPv4 NAT device will offer and may for example be enabled
   by default on all broadband edge-routers.  but with that difference
   that the security caveats will be documented, and may hence be
   removed with the next revision of the rule.  The goal is that every
   iteration, the IPv6 internet will become more secure for the
   oblivious users.

   The increased size of the IPv6 address will make topology probing
   much harder, and almost impossible for IPv6 devices.  What one does
   when topology probing is to get an idea of the available hosts inside
   an enterprise.  This mostly starts with a ping-sweep.  This is an
   automated procedure of sending Internet Control Message Protocol
   (ICMP) echo requests (also known as PINGs) to a range of IP addresses
   and recording replies.  This can enable an attacker to map the
   network.  Since the IPv6 subnets are 64 bits worth of address space,
   this means that an attacker has to send out many more (simply



Van de Velde, et al.     Expires April 12, 2005                [Page 12]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   unrealistic) pings to map the network, and virus/worm propagation
   will be thwarted in the process At full rate 40Gbps (400 times the
   typical 100Mbps LAN, and 13,000 times the typical DSL/Cable access
   link) it takes over 5000 years to scan a single 64 bit space.

4.3  User/Application tracking

   IPv6 enables the collection of information about data flows.  Due to
   the fact that all addresses used for Internet and intra-/inter- site
   communication are unique, it is possible for an enterprise or ISP to
   get very detailed information on any communication exchange between
   two or more devices.  This enhances the capability of data-flow
   tracking over IPv4 with NAT because in IPv6 a flow between a sender
   and receiver will always be uniquely identified due to the unique
   IPv6 source and destination addresses.

4.4  Privacy and topology hiding using IPv6

   Partial host privacy is achieved in IPv6 using pseudo-random privacy
   addresses (RFC 3041) which are generated as required, so that a
   session can use an address that is valid only for a limited time.
   Exactly like IPv4 NAT, this only allows such a session to be traced
   back to the subnet that originates it, but not immediately to the
   actual host.

   If a network manager wishes to conceal the internal IPv6 topology,
   and the majority of its host computer addresses, a good option will
   be to run all internal traffic using ULA since such packets can by
   definition never exit the site.  For hosts that do in fact need to
   generate external traffic, by using multiple IPv6 addresses (ULAs and
   one or more global addresses), it will be possible to hide and mask
   some or all of the internal network.  For external communication, the
   global unique address(es) must be used.  They can of course be
   privacy addresses (see above) if required.

   By using untraceable addresses, it is possible to only allocate
   certain parts of the internal network with global prefixes, while
   other, private network parts do not have global prefixes and remain
   totally cut off from the outside.  If an edge firewall is used (which
   is strongly suggested) a traffic policy can be implemented as today,
   based on various filtering and inspection rules.  (Older techniques
   such as application level proxies and SOCKS also remain available.)

   An alternative method to hide the internal topology would be to use
   MIPv6 internally where the public facing addresses (HA) are
   consolidated on an edge Home Agent, then use MIP in tunnel mode to
   the ULA as a COA.  This truly masks the internal topology as all
   nodes with global access appear to share a common subnet.  (it



Van de Velde, et al.     Expires April 12, 2005                [Page 13]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   wouldn't really need to be a single subnet either so local policy can
   run rampant trying to obscure addressing correlations.) There is no
   reason that rack mounted devices shouldn't be considered mobile nodes
   to mask the internal topology.

4.5  independent control of addressing in a private network

   IPv6 provides for autonomy in local use addresses through ULAs.  At
   the same time IPv6 simplifies simultaneous use of multiple addresses
   per interface so that a NAT is not required (or even defined) between
   the ULA and the public Internet.  Nodes that need access to the
   public Internet should have a global use address, and may
   simultaneously have a local use ULA.  Since the IPv6 address space
   for global use is not a scarce resource like it is in IPv4, each
   network should be able to acquire a sufficient quantity for its
   needs.  While global IPv6 allocation policy is managed through the
   Regional Internet Registries, it is expected that they will continue
   with derivatives of RFC 3177 for the foreseeable future.

4.6  IPv6 and address allocation dynamics

   In an IPv6 networks the network design and addressing dynamics are
   different from those seen in IPv4 networks and the impact on the four
   network types is discussed below.
   o  Medium/large private networks (typically >10 connections)
   o  Small private networks (typically 1 to 10 connections)
   o  Single user connection (typically 1 connection)
   o  ISP/Carrier customer networks

4.6.1  Medium/large private networks

   Under this category fall the majority of private enterprise networks.
   Many of these networks have single or more exit points to the
   Internet.

   It is expected that there will be enough IPv6 addresses available for
   all networks and appliances in the first couple of decennia.  The
   basic IPv6 address-range an ISP allocates for a private network is
   large enough (currently /48) for most of the medium and large
   enterprises, while for the very large private enterprise networks
   address-ranges can be concatenated.

   The summarization benefit for the ISP is happening based on the IPv6
   allocation rules.  This means that the ISP will provide the
   enterprise with an IPv6 address-range (typically a single or multiple
   range(s) of '/48') from its RIR assigned IPv6 address-space.  The
   goal of this allocation mechanism is to decrease the total size of
   the internet routing table.



Van de Velde, et al.     Expires April 12, 2005                [Page 14]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   To mask the identity of a user on a network of this type, the usage
   of IPv6 privacy extensions may be advised.  This technique is useful
   when an external element wants to track and collect all information
   sent and received by a certain host with known IPv6 address.  Privacy
   extensions add a random factor to the host part of an IPv6 address
   and will make it very hard for an external element to keep
   correlating the IPv6 address to a host on the inside network.  The
   usage of IPv6 privacy extensions does not mask the internal network
   structure of an enterprise network.

   If there is need to mask the internal structure towards the external
   IPv6 internet, then the usage of 'Untraceable' addresses may be used.
   These addresses will be derived from a local pool, and may be
   assigned to those hosts for which topology masking is required or
   which want to reach the IPv6 Internet or other external networks.
   The technology to assign these addresses to the hosts could be based
   on DHCPv6.  To complement the 'Untraceable' addresses it is needed to
   have at least awareness of the IPv6 address location when routing an
   IPv6 packet through the internal network.  This could be achieved by
   'route-injection' in the network infrastructure.  This
   route-injection could be done based on ::/128 host-routes to each
   device that wants to connect to the Internet.  This will provide with
   the most dynamic masking, but will have a scalability limitation, as
   an IGP is typically not designed to carry many thousands of IPv6
   prefixes.  A large enterprise may have thousands of hosts willing to
   connect to the internet.  Less flexible masking could be to have
   time-based IPv6 prefixes per link or subnet.  This may reduce the
   amount of route-entries in the IGP with a significant factor, but has
   as trade-off that masking is time and subnet based.

   The dynamic allocation of 'Untraceable' addresses, can also limit the
   IPv6 access between local and external hosts to those local hosts
   being authorized for this capability.

   The internal topology masking could be complemented with the usage of
   ULA addresses for the site local communication.  The combination of
   'FIXED' ULA addresses on a site, provide the benefit that even if an
   enterprise would change from ISP, the renumbering is only affecting
   those devices that have a wish to connect beyond the site.  Internal
   servers and services would not change the allocated IPv6 ULA address,
   and the service would remain available even during global address
   renumbering.  The dynamically allocated 'Untraceable' addresses, may
   also facilitate and simplify the connectivity to the outside networks
   during renumbering, because the existing IPv6 central address-pool
   could be swapped for the newly allocated IPv6 address-pool.






Van de Velde, et al.     Expires April 12, 2005                [Page 15]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


4.6.2  small private networks

   The category describes those networks which only have only few
   routers in the topology, and have a single network egress point.
   These networks are also known as SOHO (Small Office/Home Office)
   networks.  Typically these networks don't have dedicated Network
   Operation Center (NOC) and are using either a dial-up connection or
   broadband access..

   Currently, there are two approaches possible with respect to IPv6
   addressing in this kind of network topology and design.
   o  DHCPv6 Prefix-Delegation
   o  ISP provides a static IPv6 address-range

   For the DHCPv6-PD solution, a dynamic address allocation approach is
   chosen.  By means of the enhanced DHCPv6 protocol it is possible to
   have the ISP push down an IPv6 prefix range automatically towards the
   small private network and populate all interfaces in that small
   private network dynamically.  This reduces the burden for
   administrative overhead because everything happens automatically.

   For the static configuration the mechanisms used could be same as for
   the medium/large enterprises.  Typically the need for masking the
   topology will not be of high priority for these organizations, and
   the usage of IPv6 privacy extensions could be sufficient.

   For both alternatives the ISP has the unrestricted capability for
   summarization of its RIR allocated IPv6 prefix, while the small
   private network administrator has all flexibility in using the
   received IPv6 prefix to its advantage.

4.6.3  Single user connection

   This group identifies the users which are connected via a single IPv6
   address and use a single piece of equipment (PC, PDA, etc.).

   In IPv6 world the assumption is that there is unrestricted
   availability of a large amount of globally routable and unique IPv6
   addresses.  The ISP will not be motivated to allocate private
   addresses towards the single user connection because he has enough
   global addresses available.  If the single user wants to mask his
   identity, he may choose to enable IPv6 privacy extensions.

4.6.4  ISP/Carrier customer networks

   This group refers to the actual service providers that are providing
   the IP access.  They tend to have three separate IP domains that they
   support.  For the first they fall into the Medium/large private



Van de Velde, et al.     Expires April 12, 2005                [Page 16]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   networks category (above) for their own internal networks, LANs etc.
   and will be able to use the same solutions as above.  The second is
   their Operations network which addresses their backbone and access
   switches, and other hardware, this is separate for both engineering
   reasons as well as simplicity in managing the security of the
   backbone, for this it is again possible to configure a single range
   of addresses with the defined local scope defined in order to prevent
   these from being accessed from the public network.  The third is the
   IP addresses (single or blocks) that they assign to customers.  These
   can be registered addresses (usually given to category a and b and
   sometimes c) or can from a pool of RFC 1918 addresses used with NAT
   for single user connections.  Therefore they can actually have two
   different NAT domains that are not connected (internal LAN and single
   user customers) again this will be resolved by the large availability
   of addresses and the procedures mentioned above.

4.7  Multihoming and renumbering

   Multihoming and renumbering remain technically challenging with IPv6
   (see the Gap Analysis below).  However, IPv6 was designed to allow
   sites and hosts to run with several simultaneous CIDR-like prefixes
   and thus with several simultaneous ISPs.  An address selection
   mechanism [9] is specified so that hosts will behave consistently
   when several addresses are simultaneously valid.  The fundamental
   difficulty that IPv4 has in this regard therefore does not apply to
   IPv6.  IPv6 sites can and do run today with multiple ISPs active, and
   the processes for adding and removing active prefixes at a site have
   been documented [11].

   The IPv6 address space allocated by the ISP will be dependent upon
   the connecting Service provider.  This may result in a renumbering
   effort if the enterprise changes from Service Provider.  To keep the
   impact on the gateway when changing ISP to a zero human touch
   environment, DHCPv6 Prefix Delegation [10] can be used.

5.  Additional benefits due to Native IPv6 and universal unique
   addressing

   The users of native IPv6 technology and global unique IPv6 addresses
   have the potential to make use of the enhanced IPv6 capabilities, in
   addition to the benefits offered by the IPv4 technology.

NOTE:

   Is all of the material in this section, specifically the material
   that does not directly address the "advantages" of IPv4 NAT,
   necessary?




Van de Velde, et al.     Expires April 12, 2005                [Page 17]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


5.1  Universal any-to-any connectivity

   One of the original design points of the Internet was any-to-any
   connectivity.  The dramatic growth of Internet connected systems
   coupled with the limited address space of the IPv4 protocol spawned
   address conservation techniques.  NAT was introduced as a tool to
   reduce demand on the limited IPv4 address pool, but the side effect
   of the NAT technology was to remove the any-to-any connectivity
   capability.  By removing the need for address conservation (and
   therefore NAT), IPv6 returns the any-to-any connectivity model and
   removes the limitations on application developers.  With the freedom
   to innovate unconstrained by NAT traversal efforts, developers will
   be able to focus on new advanced network services (i.e.  peer-to-peer
   applications, IPv6 embedded IPsec communication between two
   communicating devices, instant messaging, Internet telephony, etc..)
   rather than focusing on discovering and traversing the increasingly
   complex NAT environment.

5.2  Auto-configuration

   IPv6 offers a scalable approach to minimizing human interaction and
   device configuration.  Whereas IPv4 implementations require touching
   each end system to indicate the use of DHCP vs.  a static address and
   management of a server with the pool size large enough for the
   potential number of connected devices, IPv6 uses an indication from
   the router to instruct the end systems to use DHCP or the stateless
   auto configuration approach supporting a virtually limitless number
   of devices on the subnet.  This minimizes the number of systems that
   require human interaction as well as improves consistency between all
   the systems on a subnet.  In the case that there is no router to
   provide this indication, an address for use on the local link only
   will be derived from the interface media layer address.

5.3  Native Multicast services

   Multicast services in IPv4 were severely restricted by the limited
   address space available to use for group assignments and an implicit
   locally defined range for group membership.  IPv6 multicast corrects
   this situation by embedding explicit scope indications as well as
   expanding to 4 billion groups per scope.  In the source specific
   multicast case, this is further expanded to 4 billion groups per
   scope per subnet by embedding the 64 bits of subnet identifier into
   the multicast address.

   IPv6 allows also for innovative usage of the IPv6 address length, and
   makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)
   directly in the IPv6 multicast address when using ASM multicast.
   this is not possible with limited size of the IPv4 address.



Van de Velde, et al.     Expires April 12, 2005                [Page 18]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


5.4  Increased security protection

   The security protection offered by native IPv6 technology is more
   advanced as with IPv4 technology.  There are various transport
   mechanisms enhanced to allow a network to operate more secure with
   less performance impact:
   o  IPv6 has the IPsec technology embedded directly embedded into the
      IPv6 protocol.  This allows for simpler peer-to-peer encryption
      and authentication, while the usage of some other less secure
      mechanisms is avoided (i.e.  md5 password hash for neighbor
      authentication)
   o  On a local network, any user will have more security awareness.
      This awareness will motivate the usage of simple firewall
      applications/devices to be inserted on the border between the
      external network and the local (or home network).
   o  All flows on the Internet will be better traceable due to a unique
      and globally routable source and destination IPv6 address.  This
      may facilitate an easier methodology for back-tracing DoS attacks
      and avoid illegal access to network resources by simpler traffic
      filtering
   o  The usage of private address-space in IPv6 still provides with
      Unique Local Addresses, which will avoid conflict situations when
      joining networks and securing the internal communication on a
      local network infrastructure due to simpler traffic filtering
      policy
   o  The technology to enable source-routing on a network
      infrastructure has been enhanced to allow this feature to
      function, without impacting the processing power of intermediate
      network devices.  The only devices impacted with the
      source-routing will be the source and destination node and the
      intermediate source-routed nodes.  This impact behavior is
      different if IPv4 is used, because then all intermediate devices
      would have had to look into the source-route header.  Looking into
      the source-route header consumed CPU power of these devices and
      was generally discouraged to be enabled on a network due to
      potential Denial-of-Service attack potential.

5.5  Mobility

   Anytime, anywhere, universal access requires mIPv6 services in
   support of mobile nodes.  While a Home Agent is required for initial
   connection establishment in either protocol version, IPv6 mobile
   nodes are able to optimize the path between them using the mIPv6
   option header while IPv4 mobile nodes are required to triangle route
   all packets.  In general terms this will minimize the network
   resources used and maximize the quality of the communication





Van de Velde, et al.     Expires April 12, 2005                [Page 19]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


5.6   Merging networks

   When two IPv4 networks want to merge it is not guaranteed that both
   networks would be using different address-ranges on some parts of the
   network infrastructure due to the legitimate usage of RFC 1918
   private addressing.  This potential overlap in address space may
   complicate a merge of two and more networks dramatically due to the
   additional IPv4 renumbering effort.  i.e.  when the first network has
   a service running (NTP, DNS, DHCP, HTTP, etc..) which need to be
   accessed by the 2nd merging network.  Similar address conflicts can
   happen when two network devices from these merging networks want to
   communicate.

   With the usage of IPv6 the addressing overlap will not exist because
   of the existence of the Unique Local Address usage for private and
   local addressing.

5.7  Community of interest

   Although some Internet-enabled devices will function as fully-fledged
   Internet hosts, it is believed that many will be operated in a highly
   restricted manner functioning largely or entirely within a Community
   of Interest.  By Community of Interest we mean a collection of hosts
   that are logically part of a group reflecting their ownership or
   function.  Typically, members of a Community of Interest need to
   communicate within the community but should not be generally
   accessible on the Internet.  They want the benefits of the
   connectivity provided by the Internet, but do not want to be exposed
   to the rest of the world.  This functionality will be available
   through the usage of NAP and native IPv6 dataflows, without any
   stateful device in the middle.

6.  IPv6 gap analysis

   Like IPv4 and any major standards effort, IPv6 standardization work
   continues as deployment starts.  This section discusses several
   topics for which additional standardization, or documentation of best
   practice, is required to fully realize the benefits of NAP.  None of
   these items are show-stoppers for immediate usage of NAP.

6.1  Completion of work on ULAs

   As noted above, a new form of Unique Local IPv6 Unicast Addresses
   (ULAs) is being standardized by the IETF.  Since these addresses can
   be used to guarantee concealment of hosts or interfaces from the
   outside unless they communicate externally, they assist NAP in
   several ways, and this work should be completed as soon as possible.




Van de Velde, et al.     Expires April 12, 2005                [Page 20]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


6.2  How to completely hide subnet topology

   ULAs may be used to assist in hiding subnet topology, but as
   mentioned, this could be done more effectively by combining ULAs with
   Mobile IP.  This work should be pursued in the IETF.

6.3  Minimal traceability of privacy addresses

   Privacy addresses (RFC 3041) may certainly be used within the
   enterprise to limit the traceability of external traffic flows, but
   they would still reveal the subnet address bits.  To eliminate this,
   some combination of privacy addresses with the previous two points is
   required, and this work remains to be done.

6.4  Renumbering procedure

   Documentation of site renumbering procedures [11] should be
   completed.  It should also be noticed that ULAs will help here too,
   since a change of ISP prefix will only affect hosts that need an
   externally routeable address as well as a ULA.

6.5  Site multihoming

   This complex problem has never been well solved for IPv4, which is
   exactly why NAT has been used as a partial solution.  For IPv6, after
   several years' work, the relevant IETF WG is finally converging on an
   architectural approach intended to reconcile enterprise and ISP
   perspectives.  Again, ULAs will help since they will provide stable
   addressing for internal communications that are not affected by
   multihoming.

6.6  Untraceable addresses

   The details of the untraceable addresses, along with any associated
   mechanisms such as route injection, must be worked out and specified.

7.  IANA Considerations

   This document requests no action by IANA

8.  Security Considerations

   Various security and privacy benefits of both IPv4 NAT and native
   IPv6 are discussed throughout this document.  It does not introduce
   any new security concerns.






Van de Velde, et al.     Expires April 12, 2005                [Page 21]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


9.  Conclusion

   This document has described a number of techniques that may be
   combined on an IPv6 site to protect the integrity of its network
   architecture.  These techniques, known collectively as Network
   Architecture Protection, retain the concept of a well defined
   boundary between "inside" and "outside" the private network, and
   allow firewalling, topology hiding, and privacy.  However, because
   they preserve address transparency where it is needed, they achieve
   these goals without the disadvantage of address translation.  Thus,
   Network Architecture Protection in IPv6 can provide the benefits of
   IPv4 Network Address Translation without the corresponding
   disadvantages.

   The document has also identified a few ongoing IETF work items that
   are needed to realize 100% of the benefits of NAP.

10.  Acknowledgements

   Christian Huitema has contributed during the initial round table to
   discus the scope and goal of the document

11  References

   [1]   Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
         Inter-Domain Routing (CIDR): an Address Assignment and
         Aggregation Strategy", RFC 1519, September 1993.

   [2]   Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E.
         Lear, "Address Allocation for Private Internets", BCP 5, RFC
         1918, February 1996.

   [3]   Hain, T., "Architectural Implications of NAT", RFC 2993,
         November 2000.

   [4]   Srisuresh, P. and K. Egevang, "Traditional IP Network Address
         Translator (Traditional NAT)", RFC 3022, January 2001.

   [5]   Holdrege, M. and P. Srisuresh, "Protocol Complications with the
         IP Network Address Translator", RFC 3027, January 2001.

   [6]   Narten, T. and R. Draves, "Privacy Extensions for Stateless
         Address Autoconfiguration in IPv6", RFC 3041, January 2001.

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




Van de Velde, et al.     Expires April 12, 2005                [Page 22]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   [8]   Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain,
         "Representing Internet Protocol version 6 (IPv6) Addresses in
         the Domain Name System (DNS)", RFC 3363, August 2002.

   [9]   Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [10]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
         Configuration Protocol (DHCP) version 6", RFC 3633, December
         2003.

   [11]  Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering
         an IPv6 Network without a Flag Day",
         draft-ietf-v6ops-renumbering-procedure-01 (work in progress),
         July 2004.

   [12]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
         Addresses", draft-ietf-ipv6-unique-local-addr-06 (work in
         progress), September 2004.


Authors' Addresses

   Gunter Van de Velde
   Cisco Systems
   De Kleetlaan 6a
   Diegem  1831
   Belgium

   Phone: +32 2704 5473
   EMail: gunter@cisco.com


   Tony Hain
   Cisco Systems
   500 108th Ave. NE
   Bellevue, Wa.
   USA

   EMail: alh-ietf@tndh.net











Van de Velde, et al.     Expires April 12, 2005                [Page 23]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


   Ralph Droms
   Cisco Systems
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   EMail: rdroms@cisco.com


   Brian Carpenter
   IBM Corporation
   Sauemerstrasse 4
   Rueschlikon,   8803
   Switzerland

   EMail: brc@zurich.ibm.com


   Eric Klein
   TTI Telecom
   Petach Tikvah,
   Israel

   Phone: +972 3 926-9130
   EMail: erick@tti-telecom.com


























Van de Velde, et al.     Expires April 12, 2005                [Page 24]


Internet-Draft    IPv6 Network Architecture Protection      October 2004


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.




Van de Velde, et al.     Expires April 12, 2005                [Page 25]


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