Network Working Group
Internet Engineering Task Force (IETF)                            B. Liu
Internet Draft
Request for Comments: 7010                                      S. Jiang
Intended status:
Category: Informational                    Huawei Technologies Co., Ltd
Expires: December 11, 2013 Ltd.
ISSN: 2070-1721                                             B. Carpenter
                                                  University of Auckland
                                                               S. Venaas
                                                           Cisco Systems
                                                               W. George
                                                       Time Warner Cable
                                                          June 9,
                                                          September 2013

                   IPv6 Site Renumbering Gap Analysis
                   draft-ietf-6renum-gap-analysis-08.txt

Abstract

   This document briefly introduces the existing mechanisms that could
   be utilized for IPv6 site renumbering and tries to cover most of the
   explicit issues and requirements associated with IPv6 renumbering.
   The content is mainly a gap analysis that provides a basis for future
   works to identify and develop solutions or to stimulate such
   development as appropriate.  The gap analysis is organized by the
   main steps of a renumbering process.

Status of this This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF). Note that other groups may also distribute working
   documents as Internet-Drafts. The list  It represents the consensus of current Internet-Drafts is
   at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a maximum candidate for any level of six months Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 11, 2013.
   http://www.rfc-editor.org/info/rfc7010.

Copyright Notice

   Copyright (c) 2012 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Abstract

   This document briefly introduces the existing mechanisms that could
   be utilized for IPv6 site renumbering and tries to cover most of the
   explicit issues and requirements of IPv6 renumbering. Its main
   content is a gap analysis that provides a basis for future works to
   identify and develop solutions or to stimulate such development as
   appropriate. The gap analysis is organized by the main steps of a
   renumbering process.

Table of Contents

   1. Introduction ................................................. 4 ....................................................4
   2. Overall Requirements for Renumbering ......................... 4 ............................4
   3. Existing Components for IPv6 Renumbering ..................... 5 ........................5
      3.1. Relevant Protocols and Mechanisms ....................... 5 ..........................5
      3.2. Management Tools ........................................ 6 ...........................................6
      3.3. Procedures/Policies ..................................... 7 Procedures and Policies ....................................7
   4. Managing Prefixes ............................................ 7 ...............................................7
      4.1. Prefix Delegation ....................................... 7 ..........................................7
      4.2. Prefix Assignment ....................................... 8 ..........................................8
   5. Address Configuration ........................................ 8 ...........................................8
      5.1. Host Address Configuration .............................. 8 .................................8
      5.2. Router Address Configuration ............................ 9 ...............................9
   6. Updating Address-relevant Address-Relevant Entries ........................... 10 ..............................10
      6.1. DNS Records Update ..................................... 10 ........................................10
      6.2. In-host In-Host Server Address Update .......................... 11 .............................11
      6.3. Address update Update in scattered configurations ............. 11 Scattered Configurations ................11
   7. Renumbering Event Management ................................ 13 ...................................13
      7.1. Renumbering Notification ............................... 13 ..................................13
      7.2. Synchronization Management ............................. 14 ................................14
      7.3. Renumbering Monitoring ................................. 14 ....................................15
   8. Miscellaneous ............................................... 14 ..................................................15
      8.1. Multicast .............................................. 14 .................................................15
      8.2. Mobility ............................................... 16 ..................................................17
   9. Gap Summary ................................................. 17 ....................................................17
      9.1. Managing Prefixes ...................................... 17 .........................................17
      9.2. Address configuration .................................. 17 Configuration .....................................17
      9.3. Address relevant entries update ........................ 17 Address-Relevant Entries Update ...........................18
      9.4. Renumbering event management ........................... 18 Event Management ..............................19
      9.5. Miscellaneous .......................................... 19 .............................................19
   10. Gaps considered unsolvable ................................. 19 Considered Unsolvable ....................................20
      10.1. Address Configuration ................................. 19 ....................................20
      10.2. Address-relevant Address-Relevant Entries Update ....................... 19 ..........................20
      10.3. Miscellaneous ......................................... 20 ............................................21
   11. Security Considerations .................................... 20 .......................................21
   12. IANA Considerations......................................... 21
   13. Acknowledgments ............................................ 21
   14. ...............................................22
   13. References ................................................. 22
      14.1. ....................................................23
      13.1. Normative References .................................. 22
      14.2. .....................................23
      13.2. Informative References ................................ 23 ...................................23

1.  Introduction

   As introduced in [RFC5887], renumbering, especially for medium to
   large sites and networks, is currently viewed as an expensive,
   painful, expensive and
   painful.  This error-prone process, process is avoided by network managers as
   much as possible.  If IPv6 site renumbering continues to be
   considered difficult, network managers will turn to Provider
   Independent (PI) addressing for IPv6 to as an attempt to minimize the
   need for future renumbering.  However, widespread use of PI
   addressing may create very serious BGP4 scaling problems [RFC4984].
   It is thus desirable to develop tools and practices that may make
   renumbering a simpler process to
   reduce and reduces demand for IPv6 PI space.

   Building upon the IPv6 enterprise renumbering scenarios described in
   [RFC6879], this document performs a gap analysis to provide a basis
   for future work to identify and develop solutions or to stimulate
   such development as appropriate.  The gap analysis is organized
   according to the main steps of a renumbering process, which include includes
   prefix management, node address (re)configuration, and updating updates to
   address-relevant entries in various devices such as firewalls,
   routers and servers, etc.  Renumbering event management is presented
   independently from the steps of a renumbering process, process in order to
   identify some operational and administrative gaps in renumbering.

   This document starts from existing work in [RFC5887] and [RFC4192].
   It does further analysis analyzes and identifies the valuable and solvable issues,
   digs out of some undiscovered gaps, and gives some solution
   suggestions.  This document considers the make-before-break approach
   as a premise for the gap analysis, so readers should be familiar with
   [RFC4192].

   Renumbering nodes with static addresses has a particular set of
   problems, thus discussion of that space has been covered in a related
   document [RFC6866].

   This document does not cover the un-planned unplanned emergency renumbering
   cases.

2.  Overall Requirements for Renumbering

   This section introduces the overall goals we want to achieve in of a renumbering event.  In
   general, we need to leverage renumbering automation to avoid human
   intervention as much as possible at a reasonable cost.  Some existing
   mechanisms have already provided provide useful ability. capabilities.

   The automation can be divided into four aspects as follows.
   (Detailed analysis of the four aspects is presented respectively in section
   Sections 4
   to section through 7.)
   o  Prefix delegation and delivery should be automatic and accurate in
      aggregation and coordination.

   o  Address reconfiguration should be automatically achieved through
      standard protocols with minimum human intervention.

   o  Address-relevant entry updates should be performed together and
      without error.

   o  Renumbering event management is needed to provide the functions of
      renumbering notification, synchronization, and monitoring.

   Besides automation, session survivability is another important issue
   during renumbering since application outage is one of the most
   obvious impacts that make renumbering painful and expensive.  Session
   survivability is a fundamental issue that cannot be solved within a
   renumbering context only.  However, with the [RFC4192] make-before-
   break make-before-break
   approach, and which uses the address lifetime mechanisms in IPv6
   Stateless Address Autoconfiguration (SLAAC) and Dynamic Host
   Configuration Protocol for IPv6 (DHCPv6), allows for a smooth
   transition mechanism from old to new prefixes is applicable. prefixes.  In most of the cases, since
   we can set the transition period to be long enough to cover the on-going
   ongoing sessions, we consider this mechanism sufficient for
   avoiding session brokenness issue to avoid
   broken sessions in IPv6 site renumbering.  (Please note that if
   multiple addresses are running simultaneously on hosts, hosts simultaneously, the address
   selection [RFC6724] needs to be carefully handled.)

3.  Existing Components for IPv6 Renumbering

   Since renumbering is not a new issue, some protocols and mechanisms
   have already been utilized for renumbering. this purpose.  There were are also some
   dedicated protocols and mechanisms that have been developed for
   renumbering.  This section briefly reviews these existing protocols
   and mechanisms to provide a basis for the gap analysis.

3.1.  Relevant Protocols and Mechanisms

   o RA  Router Advertisement (RA) messages, defined in [RFC4861], are used
      to deprecate/announce
      old/new deprecate prefixes that are old or announce prefixes that are
      new, and to advertise the availability of an upstream router.  In
      renumbering, it RA is one of the basic mechanisms for host
      configuration.

   o  When renumbering a host, SLAAC [RFC4862] may be used for address
      configuration with the new prefix(es).  Hosts receive RA messages
      which
      that contain a routable prefix(es) and the address(es) of the
      default router(s), router(s); then hosts can generate an IPv6 address(es) by
      themselves.

   o  Hosts that are configured through DHCPv6 [RFC3315] obtain new
      addresses through the renewal process or when they receive the
      reconfiguration messages initiated by the DHCPv6 servers.

   o  DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated
      delegation of IPv6 prefixes using the DHCPv6.

   o  [RFC2894] defined defines standard ICMPv6 messages for router renumbering.
      This is a dedicated protocol for renumbering, but we are not aware
      of it being used in real network deployment.

3.2.  Management Tools

   Some renumbering operations could be automatically processed by
   management tools in order to make the renumbering process more
   efficient and accurate.  The tools may be designed specifically for
   renumbering, or common tools could be utilized for some of the
   renumbering operations.

   Following are examples of these tools. such tools:

   o  IP address management (IPAM) tools.  There are both commercial and
      open-source solutions.  IPAM tools are used to manage IP address
      plans,
      plans and usually integrate the DHCPv6 and DNS services together
      as a whole solution.  Many mature commercial tools can support
      management operations, but normally they do not have dedicated
      renumbering functions.  However, the integrated DNS/DHCPv6
      services and address management function can obviously facilitate
      the renumbering process.

   o  Third-party tools.  Some organizations use third-party tools to
      push configuration to devices.  This is sometimes used as a
      supplement to vendor specific vendor-specific solutions.  A representative of such
      a third-party tool is [cfengine]. [CFENGINE].

   o  Macros.  [LEROY] proposed a mechanism of macros to automatically
      update the address-relevant entries/configurations inside the DNS,
      firewall, etc.  The macros can be delivered though through the SOAP
      protocol from a network management server to the managed devices.

   o  Asset management tools/systems.  These tools may provide the
      ability of managing to manage configuration files in nodes devices so that it is
      convenient to update the address-relevant configuration in these
      nodes.
      devices.

3.3. Procedures/Policies  Procedures and Policies

   o  [RFC4192] proposed a procedure for renumbering an IPv6 network
      without a flag day.  The document includes a set of operational
      suggestions which that can be followed step by step by network
      administrators.  It should be noted that the administrators need
      to carefully deal with the address selection issue issue, while the old
      and new prefixes are both available during the overlapping period
      as described in
      [RFC4192] procedure. And the procedures in [RFC4192].  The address
      selection policies might need to be updated after renumbering. So renumbering, so
      the administrator could leverage the address selection policy address-selection-policy
      distribution mechanism as described in
      [I-D.ietf-6man-addr-select-opt]. [6MAN-ADDR-OPT].

   o  [RFC6879] analyzes the enterprise renumbering events and gives the makes
      recommendations among based on the existing renumbering mechanisms.
      According to the different stages, renumbering considerations are
      described in three categories: considerations and recommendations
      during network design, for the preparation of enterprise network
      renumbering, and during the renumbering operation.

4.  Managing Prefixes

   When renumbering an IPv6 enterprise site, the key procedural issue is
   switching the old prefix (es) prefix(es) to the a new one(s).  A new short prefix may
   be divided into longer ones for subnets. So subnets, so we need to carefully
   manage the prefixes to ensure they are synchronized and coordinated
   in
   within the whole network.

4.1.  Prefix Delegation

   For big enterprises, the new short prefix(es) usually comes down
   through off-line offline human communication. But  But, for the SOHO style SOHO-style (Small
   Office, Home Office) SMEs (Small & Medium Enterprises), the prefixes
   might be dynamically received by DHCPv6 servers or routers inside the
   enterprise networks.  The short prefix(es) could be automatically
   delegated through DHCPv6-
   PD. DHCPv6-PD.  Then the downlink DHCPv6 servers or
   routers can could begin advertising the longer prefixes to the subnets.

   The delegation routers might need to renumber themselves with the new
   delegated prefixes. So  So, there should be a mechanism informing to inform the
   router
   routers to renumber themselves by delegated prefixes; and there also should
   also be a mechanism for the routers to derive addresses automatically
   based on the delegated prefixes.

4.2.  Prefix Assignment

   When subnet routers receive the longer prefixes, they can advertise a
   prefix on a link to which hosts are connected.  Host address
   configuration, rather than routers, is the primary concern for prefix
   assignment
   assignment, which is described in the following section Section 5.1.

5.  Address Configuration

5.1.  Host Address Configuration

   o SLAAC/DHCPv6 interaction problems  SLAAC and DHCPv6 Interaction Problems

      Both of the DHCPv6 and Neighbor Discovery (ND) protocols have an IP
      address configuration function. They function, which are suitable for different
      scenarios.  During renumbering, the SLAAC-configured hosts can
      reconfigure IP addresses by receiving ND Router Advertisement (RA)
      messages containing new prefix information.  (It should be noted that,
      that the prefix delivery could be achieved through DHCPv6
      according to
   [I.D ietf-dhc-host-gen-id]). [PREFIX-DHCPv6]).  The DHCPv6-configured hosts can
      reconfigure addresses by initiating RENEW sessions [RFC3315] when
      the current addresses' lease times are expired or when they
      receive reconfiguration messages initiated by the DHCPv6 servers.

      Sometimes the two address configuration modes may both be available in one
      the same network.  This would add additional complexity for both
      the hosts and the network management.

      With the flags defined in RA (ManagedFlag (M) indicating the
      DHCPv6 service available in the network; OtherConfigFlag (O)
      indicating other configurations such as DNS/routing), the two
      separated address configuration modes are correlated.  However,
      the ND protocol did does not define the flags as prescriptive but only
      as advisory.  This has led to variation in the behavior of hosts
      when interpreting the flags.
   Different flags; different operating systems have
      followed different approaches.  (For more details, please refer to [I-D.liu-bonica-dhcpv6-slaac-problem]
      [DHCPv6-SLAAC] and [I-D.liu-6renum-dhcpv6-slaac-switching].) [6RENUM-SLAAC].)

      The impact of ambiguous M/O flags includes the following aspects:

      -  DHCPv6-configured hosts might not be able to be renumbered by
         RA

         It is unclear whether a DHCPv6 configured DHCPv6-configured host will accept
         address configuration though RA messages, especially when the M
         flag
     transitioning transitions from 1 to 0; this depends on the
         implementation of the operating system.  It might not be
         possible for administrators to only use RA messages for
         renumbering, since renumbering might fail on some already
         DHCPv6-configured hosts. It  This means administrators have to use
         DHCPv6 reconfiguration for some DHCPv6-
     configured DHCPv6-configured hosts.  It is
         not convenient convenient, and DHCPv6 reconfiguration is not suitable for
         bulk usage as analyzed in below.

      -  DHCPv6-configured hosts might not be able to learn new RA
         prefixes

         [RFC5887] mentioned mentions that DHCPv6-configured hosts may want to
         learn about the upstream availability of new prefixes or loss
         of prior prefixes dynamically by deducing this from periodic RA
         messages.  Relevant standards ([RFC4862],[RFC3315]) [RFC4862] [RFC3315] are ambiguous
         about what approach should be taken by a DHCPv6-configured host
         when it receives RA messages containing a new prefix.  Current
         behavior depends on the operating system of the host and cannot
         be predicted or controlled by the network.

      -  SLAAC-configured hosts might not be able to add a DHCPv6
         address(es)

         The behavior when the host receives RA messages with the M flag
         set is unspecified.

         The host may start a DHCPv6 session and receive the DHCPv6
         address configuration, or it may just ignore the messages. If the network
     side wants
         Whether the hosts to start DHCPv6 configuration, it configuration is just out
     of outside the
         control of the network side.

5.2.  Router Address Configuration

   o  Learning new prefixes New Prefixes

      As described in [RFC5887], "if a site wanted to be multihomed
      using multiple provider-aggregated (PA) routing prefixes with one
      prefix per upstream provider, then the interior routers would need
      a mechanism to learn which upstream providers and prefixes were
      currently reachable (and valid).  In this case, their Router
      Advertisement messages could be updated dynamically to only
      advertise currently valid routing prefixes to hosts.  This would
      be significantly more complicated if the various provider prefixes
      were of different lengths or if the site had non-uniform subnet
      prefix lengths."
   o Restart after renumbering  Restarting After Renumbering

      As [RFC2072] mentioned, mentions, some routers cache IP addresses in some
      situations, so routers might need to be restarted as a result of
      site renumbering.  While most modern systems support a cache-clear
      function that eliminates the need for restarts, there are always
      exceptions that must be taken into account.

   o  Router naming Naming

      [RFC4192] suggests states that "To better support renumbering, switches and
      routers should use domain names for configuration wherever
      appropriate, and they should resolve those names using the DNS
      when the lifetime on the name expires." expires".  As [RFC5887] described,
      this capability is not new, and currently it is present in most
      IPSec VPN implementations.  However, many administrators may need
      to be alerted to the fact that it could can be utilized to avoid manual
      modification during renumbering.

6.  Updating Address-relevant Address-Relevant Entries

   In conjunction with renumbering the nodes, any configuration or data
   store containing previous addresses must be updated as well.  Some
   examples include DNS records and filters in various entities such as
   ACLs
   Access Control Lists (ACLs) in firewalls/gateways.

6.1.  DNS Records Update

   o  Secure Dynamic DNS update (DDNS) Update

      In real network operations, a DNS update is normally achieved by
      maintaining a DNS zone file and loading this file into the site's
      DNS server(s).  Synchronization between host renumbering and the
      updating of its A6 or AAAA record is hard.  [RFC5887] mentioned that discusses an
      alternative is to use that uses the Secure Dynamic DNS Update [RFC3007], in
      which a host informs its own DNS server when it receives a new
      address.

      The Secure Dynamic DNS Update has been widely supported by the
      major DNS implementations, but it hasn't been widely deployed.
      Normal hosts are not suitable to do the update update, mainly because of
      the complexity of key
   management complex key-management issues inherited from secure DNS
      mechanisms, so current practices usually assign the DHCP servers to
      act as DNS clients to request that the DNS server updating update relevant
      records [RFC4704]. This
   server-oriented approach  The key-management problem is applicable tractable in the
      case of updates for large numbers a limited number of hosts'
   using secure DDNS. (In some commercial solutions, servers, so Dynamic DNS service
      updates could
   be integrated with DHCP service provided by the same vendor so that
   the secure DDNS might be silently enabled serve as default.) a suitable solution for keeping server DNS
      records up to date on a typical enterprise network.  However, there this
      solution is still a gap here, since not easily applicable to hosts in general.

      To address the larger use case of arbitrary non-server hosts being
      renumbered, DHCP servers have to learn that the relevant hosts
      have changed their addresses and thus trigger the DDNS update.  If
      the hosts were numbered and also renumbered by DHCP, then it is would be
      easy for the DHCP servers to learn the address changes; but however,
      if the hosts were numbered by SLAAC, then there could be trouble.
   [I-D.ietf-dhc-addr-registration] proposed a address registration
   mechanism which could be used to address the latter issue; however,
   it has not been deployed yet.

6.2. In-host  In-Host Server Address Update

   While DNS stores the addresses of hosts in servers, hosts are also
   configured with the addresses of servers servers, such as DNS server, radius
   server. and RADIUS
   servers [RFC2865].  While renumbering, the hosts must update these
   addresses if the server addresses changed. change.

   In principle, the addresses of DHCPv6 servers do not need to be
   updated,
   updated since they could be dynamically discovered through DHCPv6
   relevant
   DHCPv6-relevant multicast messages.  But in practice, most relay
   agents have the alternative option of being configured with a DHCPv6 server
   address rather than sending to a multicast address. So  Therefore, the
   DHCP server addresses update might be an issue in practice.

6.3.  Address update Update in scattered configurations Scattered Configurations

   Besides the DNS records and the in-host server address entries, there
   are also many places in which IP addresses are configured, for
   example, filters such as ACL and routing policies.  There are even
   more sophisticated cases where the IP addresses are used for deriving
   values, for example, using the unique portion of the loopback address
   to generate an ISIS net ID.

   In renumbering, it is annoying and error-prone to update updating the IP addresses in all the above mentioned places.
   places is burdensome and error-prone.  We lack a "one-stop" mechanism
   to trigger the updates for all the subsystems on a
   host/server, host/server and
   all the external databases that refer to the IP address update.  We decompose
   break the general "one-stop" gap into the following two aspects.

   o Self-contained  Self-Contained Configuration in Individual device

   In an ideal way, the Devices

      Ideally, IP addresses can be defined as a value once, and then the
      administrators can use either keywords or variables to call the
      value in other places such as a sort of internal inheritance in
      CLI (command line interface) or other local configurations.  This
      makes it easier to manage a renumbering event by reducing the
      number of places where a device's configuration must be updated.

      However, it still means that every device needs to be touched, individually
      updated, but only once instead of having to inspect the whole
      configuration to ensure that none of the separate places that a
      given IP address occurs is missed.

      Among the current devices, some routers support defining multiple
      loopback interfaces which that can be called in other configurations.
      For example, when defining a tunnel, it can call the defined
      loopback interface to use its address as the local address of the
      tunnel.  This can be considered as a kind of parameterized self-contained self-
      contained configuration. But  However, this only applies to certain
      use cases; it is impossible to use the loopback interfaces to
      represent external
   devices devices, and it is not always possible to call
      loopback interfaces in
   many other configurations.  Parameterized self-contained self-
      contained configuration is still a gap for current devices. that needs to be filled.

   o  Unified Configuration Management among Devices

      This refers to a more formalized central configuration management
      system, where all changes are made in one place place, and the system
      manages how to push the changes are pushed to the individual devices.  This
      issue contains two aspects aspects, as the following. follows:

      -  Configuration Aggregation

         Configuration data based on addresses or prefixes are usually
         spread out in various devices.  As [RFC5887] described, describes, some
         address configuration data might be widely dispersed and much
         harder to find, even find.  Some will inevitably be found only after the
         renumbering event. So  Because there's a big gap for in configuration
         aggregation, it is hard to get all the relevant configurations through configuration
         data together in one place.

      -  Configuration Update Automation

         As mentioned in section Section 3.2, [LEROY] proposed proposes a mechanism which that
         can automatically update the configurations.  The mechanism
         utilizes macros suitable for various devices such as routers, firewalls. routers
         and firewalls to update the configurations based on the new prefix.
         Such an automation tool is valuable for renumbering because it
         can reduce manual
     operation operation, which is error-prone and inefficiency.
         inefficient.

         Besides the macros, [LEROY] also proposed to proposes the use of SOAP to
         deliver the macros to the devices. As well as SOAP  Along with SOAP, we may
         consider whether it is possible and suitable to use other
         standardized protocols protocols, such as NETCONF [RFC4714].

     But in the Network Configuration
         Protocol (NETCONF) [RFC6241].

         In current real networks, most of the devices use vendor-
     private vendor-private
         protocols to update configurations, so it is not necessarily
         valid to assume that there is going to be a formalized
         configuration management system to leverage.  Although there
         are some vendor-independent tools as mentioned in section Section 3.2,
         a standard and comprehensive way of to uniformly updating update
         configurations in multi-vendor devices is still a big gap currently. missing.

7.  Renumbering Event Management

   From the perspective of network management, renumbering is a kind of an event which
   that may need additional process processes to make it more easy easier and more
   manageable.

7.1.  Renumbering Notification

   If

   The process of renumbering could benefit from hosts or servers are being
   made aware of an occurrence of a renumbering event happening, it
   may benefit the relevant process. event.  Following are
   several examples of
   such additional process processes that may ease the renumbering.

   o  A notification mechanism may be needed to indicate to hosts that a
      renumbering event has changed some DNS records in DNS servers
      (normally, in an enterprise it/they is/are (a) enterprise, it is a local recursive DNS
      server(s).),
      server(s)), and then the hosts might want to refresh the DNS
      cache.  That mechanism may also need to indicate that such a
      change will happen at a specific time in the future.

   o  As suggested in [RFC4192], [RFC 4192], if the DNS service can be given prior
      notice about a renumbering event, then people could reduce the delay in the transition to
      new IPv6 addresses, addresses could be reduced and thus improve the
      efficiency of renumbering.

   o  Router awareness: in In a site with multiple domains which that are
      connected by border routers, all border routers should be aware of
      renumbering in one domain or multiple domains, domains and update the
      internal forwarding tables and the address/prefix based address-/prefix-based filters
      accordingly to correctly handle inbound packets.

   o  Ingress filtering: ISPs normally enable an ingress filter to drop
      packets with source addresses from other ISPs at the end site end-site
      routers to prevent IP spoofing [RFC2827].  In a multihomed site
      with multiple PA prefixes, the ingress router of ISP A should be
      notified if the ISP B initiates a renumbering event in order to
      properly update its filters to permit the new legitimate prefix
      (es).
      prefix(es).  For large enterprises, it might be applicable practical to indicate
      manage this new legitimate prefix information through human communication,
      however,
      communication.  However, for the millions of small enterprises, an
      automated notification mechanism is needed.

   o  Log collectors: In the NMS (network management system), log
      collectors that collect logs collected through syslog, SNMP notification,
      IPFIX, etc. usually treat the UDP message source IP addresses as
      the host or router IDs. When one source IP address is changed, the
      log collectors will consider that a new device appeared in the
      network. So  Therefore, a mechanism is needed for the NMS
      applications to learn the renumbering event, so
      that they could correlate event including the mappings
      of old and new IP addresses in for each host/router, so that they
      could update the logs. address-relevant mappings as described in Section
      7.2.

7.2.  Synchronization Management

   o  DNS update synchronization Update Synchronization

      The DNS changes must be coordinated with the changes of node address
   configuration.
      configuration changes.  DNS has a latency issue of propagating
      information from the server to the resolver.  The latency is
      mainly caused by TTL the Time to Live (TTL) assigned to individual DNS
      records and the timing of updates from primary to secondary
      servers [RFC4192].

      Ideally, during a renumbering operation, the DNS TTLs should
      always be shorter than any other lifetime lifetimes associated with an
      address.  If the TTLs were set correctly, then the DNS latency
      could be well controlled.  However, there might be some
      exceptional situations in which the DNS TTLs were already set too
      long for the time available to plan and execute a renumbering
      event.  In these situations, there
   currently are currently no mechanisms to
      deal with the already configured long DNS TTLs.

   o  NMS Address-Relevant Mapping Synchronization

      As described in Section 7.1, the NMS needs to learn the
      renumbering event and thus correlate the old and new address in
      the logs.  If the NMS applies unique IDs for the hosts or routers,
      then the mappings between the unique IDs and IP addresses also
      need to be updated after renumbering.

7.3.  Renumbering Monitoring

   While treating renumbering as a network event, mechanisms to monitor
   the renumbering process might be needed to inform the administrators
   whether the renumbering has been successfully done. successful.  Considering that the
   address configuration operation might be stateless (if ND is used for
   renumbering), it is difficult for monitoring. to monitor.

8.  Miscellaneous

   Since multicast and mobility are special use cases which that might not be
   included in routine/common routine or common renumbering operations, they are
   separately
   discussed as miscellaneous separately in this miscellaneous section.

8.1.  Multicast

   In

   From the perspective of interface renumbering operations, renumbering
   a multicast address is the same with as renumbering a unicast address.  So
   this section mainly discusses the issues from the perspective of the
   impact to the multicast application systems caused by renumbering.
   Renumbering also has an impact on multicast.  Renumbering of unicast
   addresses affects multicast even if the multicast addresses are not
   changed.  There may also be cases where the multicast addresses need
   to be renumbered.

   o  Renumbering of multicast sources Multicast Sources

      If a host that is a multicast source is renumbered, the
      application on the host may need to be restarted for it to
      successfully send packets with the new source address.

      For ASM (Any-Source Multicast) Multicast), the impact on a receiver is that a
      new source appears to start sending, sending and it no longer receives from
      the previous source.  Whether this is an issue depends on the
      application, but we believe it is likely to not to be a major issue.

      For SSM (Source-Specific Multicast) however, there is one
      significant problem.  The receiver needs to learn which source
      addresses it must join.  Some applications may provide their own
      method for learning sources, where the source application may
      somehow signal the receiver.

      Otherwise, the receiver may e.g. may, for example, need to get new SDP
      (Session Description Protocol) information with the new source
      address.  This is similar to how to learn the process for learning a new group
   address,
      address; see the "Renumbering of multicast addresses" Multicast Addresses" topic below.

   o  Renumbering of Rendezvous-Point

      If the unicast addresses of routers in a network are renumbered,
      then the RP (Rendezvous-Point) address is also likely to change
      for at least some groups.  An RP address is needed by PIM-SM for providing
   ASM,
      (Protocol Independent Multicast - Sparse Mode) to provide ASM and
      for Bidir PIM.  Changing the RP address is not a major issue,
      except that the multicast service may be impacted while the new RP
      addresses are configured.  If dynamic protocols are used for
   distributing to
      distribute group-to-RP mappings, the change can be fairly quick, quick
      and any impact time should be only for a very brief time. brief.  However, if routers are
      statically configured, this the time impacted depends on how long it
      takes to update all the configurations.

      For PIM-SM PIM-SM, one typically switches to SPT (Shortest-Path-Tree)
      when the first packet is received by the last-hop routers.
      Forwarding on the SPT should not be impacted by the change of IP
      address. Network  A network operator should be careful not to deprecate
      the previous mapping before configuring a new one, because
      implementations may revert to Dense Mode if no RP is configured.

   o  Renumbering of multicast addresses Multicast Addresses

      In general general, multicast addresses can be chosen independently of the
      unicast addresses, and the multicast addresses can remain fixed
      even if the unicast addresses are renumbered.  However, for IPv6 IPv6,
      there are useful ways of deriving multicast addresses from unicast
      addresses, such as unicast-prefix-based described in "Unicast-Prefix-based IPv6
      Multicast Addresses Addresses" [RFC3306] and
   Embedded-RP "Embedded-RP IPv6 Multicast Addresses
      Addresses" [RFC3956].  In that case those cases, the multicast addresses
      used may have to be renumbered.

      Renumbering group addresses may be complicated.  For multicast, it
      is common to use literal addresses, addresses and not DNS.  When multicast
      addresses are changed, source applications need to be reconfigured
      and restarted.

      Multicast receivers need to learn the new group addresses to join.

      Note that for SSM, receivers need to learn which multicast
      channels to join.  A channel is a source and group pair.  This
      means that for an SSM application, a change of source address is
      likely to have the same effect as a change of group address.

      Some applications may have dynamic methods of learning which
      groups (and possibly sources) to join.  If not, the application
      may have to be reconfigured and restarted.

      One common way for receivers to learn the necessary parameters is
      by use of SDP.  SDP information may be distributed via various
      application protocols, protocols or it may be from a file.  An SDP file may be
      distributed via HTTP, email email, etc.  If a user is using a web
      browser and clicking on a link to launch the application with the
      necessary data, it may be a matter of closing the current application,
      application and re-
   clicking re-clicking the link.

      In summary, currently the currently, multicast renumbering issues are basically
      handled by application-specific methods.  There is no standard way
      to guarantee that multicast service could live across a
      renumbering event.

8.2.  Mobility

   As described in [RFC5887], if a mobile node's home address changes
   unexpectedly, the node can be informed of the new global routing
   prefix used at the home site through the Mobile Prefix Solicitation
   and Mobile Prefix Advertisement ICMPv6 messages [RFC6275]. But  However,
   if the mobile node is unfortunately disconnected at the time of home address
   renumbering, it will no longer know a valid subnet anycast address
   for its home agent, leaving it to deduce a valid address on the basis
   of DNS information.

   So, for Mobile IP, we need a better mechanism to handle the change of
   home agent address while the mobile address is disconnected.

9.  Gap Summary

   The following is a summary of the gaps identified previously in this
   document that are considered solvable, but may require process or
   protocol changes to resolve.

9.1.  Managing Prefixes

   o  A mechanism informing the router routers to renumber themselves by
      delegated prefixes prefixes.

   o  A mechanism for the routers to derive addresses automatically
      based on the delegated prefixes.

9.2.  Address configuration Configuration

   o  Host address configuration Address Configuration

      -  DHCPv6-configured hosts might not be able to be renumbered by
         RA on some of current implementations implementations.

      -  DHCPv6-configured hosts might not be able to learn new RA
         prefixes on some of current implementations implementations.

      -  SLAAC-configured hosts might not be able to add DHCPv6
         address(es) on some of current implementations implementations.

   o  Router address configuration Address Configuration

      -  A mechanism for interior routers in a multihomed site to learn
         which upstream providers and prefixes were are currently reachable reachable.

      -  Cache-clear might need to restart (rarely in modern routers) routers).

      - Using  Use of router domain names is not widely learned/deployed learned or deployed by
        administrators
         administrators.

9.3. Address relevant entries update  Address-Relevant Entries Update

   o  DNS records update Records Update

      -  For key management scalable issue, key-management scalability issues, secure dynamic DNS
         update is usually done by DHCP servers on behalf of the hosts,
         so it might not be applicable practical for SLAAC-configured hosts to do
         secure DDNS.

   o In-host server address update  In-Host Server Address Update

      -  DHCP relays might be configured with DHCP server addresses
         rather than by sending multicast messages to discover the DHCP
         server dynamically, so updating the DHCP server addresses update might
         be an issue in practice.

   o  Address update Update in scattered configurations Scattered Configurations

      - Devices  For devices that don't support parameterized configuration,
         administrators need to touch every places where individually update all devices in which
         IP addresses were configured previously configured.

      -  It is hard to get all the address-relevant configurations
         spread in various devices through one place place.

      -  Uniformly update updating configurations in multi-vendor devices is
         currently a big gap currently that needs to be filled.

9.4.  Renumbering event management Event Management

   o  Renumbering notification Notification

      -  A mechanism to indicate hosts a host's local recursive DNS is going
         to be
        renumbered renumbered.

      -  A prior notice about a renumbering event for DNS DNS.

      -  A mechanism for border routers to know internal partial
        renumbering
         renumbering.

      -  For multihomed sites, a mechanism is needed to notify the
         egress router of
        ISPA connecting to ISP A that the egress router
         connecting to ISPB initiates renumbering
        is needed. ISP B has initiated renumbering.

      -  A mechanism is needed for the NMS applications to learn the
         renumbering event, so that they could correlate the old and new
         addresses in the logs. logs, and update the unique ID of the device
         and address mappings.

   o  Synchronization management Management

      -  DNS information propagating propagation latency issue issue.

      -  Mechanisms are needed for the NMS applications to correlate the
         old and new addresses in logs and to update the unique ID of
         the device and address mappings.

   o  Renumbering monitoring Monitoring

      -  Mechanisms to monitor the process and feedback of renumbering
         might be needed.

9.5.  Miscellaneous

   o  Multicast

      - Mechanism  A mechanism for SSM receivers to learn the source addresses
         when multicast sources are renumbered.

   o  Mobility

      -  A better mechanism to handle a change of home agent address
         while the mobile address is disconnected.

10.  Gaps considered unsolvable Considered Unsolvable

   This section lists gaps that have been identified by other documents
   but are considered unsolvable.

10.1.  Address Configuration

   o  RA prefix lifetime limitation

   In section Prefix Lifetime Limitation

      Section 5.5.3 of [RFC4862], it is defined that [RFC4862] states "If the received Valid Lifetime
      is greater than 2 hours or greater than RemainingLifetime, set the
      valid lifetime of the corresponding address to the advertised
      Valid Lifetime."  So when renumbering, if the previous
      RemainingLifetime is longer than two hours, it is impossible to
      reduce a prefix's lifetime to less than two hours.  This
      limitation is to prevent denial-of-service attack. attacks.

10.2. Address-relevant  Address-Relevant Entries Update

   o  DNS authority Authority

      In an enterprise that hosts servers on behalf of collaborators and
      customers, it is often the case that DNS zones outside the
      administrative control of the hosting enterprise maintain resource
      records concerning addresses for hosted nodes within its address
      space.  When the hosting enterprise renumbers, it does not have
      sufficient authority to change those records.

      This is an operational and policy issue.  It is out of scope for
      this document to consider a technical solution or to propose an
      additional protocol or mechanism to standardize the interaction
      between DNS systems for authority negotiations.

   o  DNS Entries

      DNS entries commonly have matching Reverse reverse DNS entries which that will
      also need to be updated during renumbering.  It might not be
      possible to combine forward and reverse DNS entries update entry updates in one
      procedure.
      procedure where addresses are not being managed using DHCP.

   o  DNS data structure optimization Data Structure Optimization

      [RFC2874] proposed an A6 record type for DNS recording of the IPv6
      address and prefix.  Several extensions to DNS query and
      processing were also proposed.  A6 was designed to be a
      replacement for the AAAA record.  The changes were designed to
      facilitate network renumbering and multihoming.  With the A6
      record and the extensions, an IPv6 address could be defined by
      using multiple DNS records.  This feature would increase the
      complexity of resolvers but reduce the cost of zone file
      maintenance, so renumbering could be easier than with the AAAA
      record.

   However, the

      [RFC2874] has been deprecated and moved to Historic status by
      [RFC6563].  The A6 record has not been widely used, used and has been
      shown to have various problems and disadvantages (see section Section 2 in
      [RFC6563]). It has been deprecated and moved to historic status by
   [RFC6563].  The idea of a structured record to separate prefix
      and suffix is still potentially valuable for renumbering, but
      avoiding the problems of the A6 record would require a major
      development effort.

10.3.  Miscellaneous

   o  For the transport layer, [RFC5887] said that TCP connections and
      UDP flows are rigidly bound to a given pair of IP addresses.

   o  For the application layer, in general, we can assert that any
      implementation is at risk from renumbering if it does not check
      whether an address is valid each time it starts session resumption
      (e.g.
      (e.g., a laptop wakes from sleep state).  It is also more of or less
      risky when it opens a new communications session by using cached
      addresses.

   We considered the above two points (ID/Locator overloading in
   transport layer & and address caching in app application layer) are fundamental
   issues that might not be proper to deal with them just in terms of
   renumbering.

11.  Security Considerations

   o  Prefix Validation

      Prefixes from the ISP may need authentication to prevent prefix
      fraud.  Announcing changes of site prefix to other sites (for
      example, those that configure routers or VPNs to point to the site
      in question) also need needs validation.

      In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) [SECURE-DHCPv6] or Secure Neighbor
      Discovery (SEND, [RFC3971]) (SEND) [RFC3971] deployment may be needed to validate
      prefixes.

   o  Influence on Security Controls

      During renumbering, security controls (e.g. (e.g., ACLs) protecting
      legitimate resources should not be interrupted.  For example, if
      some addresses are in a blacklist, they should not escape from the
      blacklist due to renumbering.

   If there are DHCPv6 authentication keys associated with an IP address
   then the keys need to be changed for continually working when the
   addresses are renumbered.

      Addresses in SEND certificates are going to will need to get updated when
      renumbering.  During the overlap between old and new addresses,
      both certificates must remain valid.

   o  Security Protection for Renumbering Notification

      Section 7.1 mentions possible notification mechanisms to signal a
      change in the DNS system or in the border routers related to a
      renumbering event.  Since the DNS system and border routers are
      key elements in any network, and they might take action according
      to the notification, a security authentication for the renumbering
      notification is needed.

   o  Security Protection for Configuration Update

      Automated configuration update approaches like [LEROY] would
      increase the risk since a bad actor with the right permission
      could cause havoc to the networks.

12. IANA Considerations

   This draft does not request any IANA actions.

13.  Acknowledgments

   This work adopts significant amounts of content from [RFC5887] and
   particularly [RFC5887].  In
   addition, it draws largely from the "DNS Authority" topic in section Section
   10.2 is from
   [draft-chown-v6ops-renumber-thinkabout]. [IPv6-RENUM-THINK].  Both of the two documents
   are offer such important
   input for this work, work that some
   principles/considerations principles and considerations applied
   in this work are implicitly inherited from them.  So thanks go to
   Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, and Alan
   Ford.  Some useful materials were provided by Oliver Bonaventure and
   his student student, Damien Leroy.

   Many useful comments and contributions were made by Ted Lemon, Lee
   Howard, Robert Sparks, S. Moonesamy, Fred Baker, Sean Turner, Benoit
   Claise, Stephen Farrell, Brian Haberman, Joel Jaeggli, Eric Vyncke,
   Phillips Matthew, Benedikt Stockebrand, Gustav Reinsberger, Teco Boot
   Boot, and other members of the 6renum WG.

   This document was prepared using 2-Word-v2.0.template.dot.

14.  References

14.1.  Normative References

   [RFC3007] B.   Wellington, B., "Secure Domain Name System (DNS) Dynamic
               Update", RFC 3007, November 2000.

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

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

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

   [RFC3971]   Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander Nikander,
               "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4861]   Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
               "Neighbor Discovery for IP version 6 (IPv6)", RFC
             4861,September 4861,
               September 2007.

   [RFC4862]   Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
               Address Autoconfiguration", RFC 4862, September 2007.

14.2.  Informative References

   [RFC2072] H.   Berkowitz, H., "Router Renumbering Guide", RFC2072, RFC 2072,
               January 1997.

   [RFC2827]   Ferguson, P. and D. Senie, "Network Ingress Filtering:
               Defeating Denial of Service Attacks which employ IP
               Source Address Spoofing", BCP 38, RFC 2267, January 1998. 2827, May 2000.

   [RFC2865]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
               "Remote Authentication Dial In User Service (RADIUS)",
               RFC 2865, June 2000.

   [RFC2874]   Crawford, M., M. and C. Huitema, "DNS Extensions to Support
               IPv6 Address Aggregation and Renumbering", RFC 2874, July
               2000.

   [RFC2894] M.   Crawford, M., "Router Renumbering for IPv6", RFC 2894,
               August 2000.

   [RFC3306] B.   Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
               Multicast Addresses", RFC 3306, August 2002.

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

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

   [RFC4704]   Volz, B., "The Dynamic Host Configuration Protocol for
               IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
               Option", RFC 4704, October 2006.

   [RFC4714]

   [RFC6241]   Enns, R., "NETCONF Ed., Bjorklund, M., Ed., Schoenwaelder, J.,
               Ed., and A. Bierman, Ed., "Network Configuration Protocol", Protocol
               (NETCONF)", RFC 4714,
             December 2006. 6241, June 2011.

   [RFC4984]   Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
               from the IAB Workshop on Routing and Addressing", RFC
               4984, September 2007.

   [RFC5887]   Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
               Still Needs Work", RFC 5887, May 2010.

   [RFC6275]   Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
               Support in IPv6", RFC 6275, July 2011.

   [RFC6563]   Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to
               Historic Status", RFC 6563, May March 2012.

   [RFC6724]   Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
               "Default Address Selection for Internet Protocol Version
               6 (IPv6)", RFC 6724, September 2012.

   [RFC6275] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
             in IPv6", RFC 3775, June 2004.

   [RFC6866]   Carpenter, B. and S. Jiang, "Problem Statement for
               Renumbering IPv6 Hosts with Static Addresses in
               Enterprise Networks", RFC 6866, February 2013.

   [RFC6879]   Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
               Network Renumbering Scenarios, Considerations, and
               Methods", RFC 6879, February 2013.

   [I-D.ietf-6man-addr-select-opt]

   [6MAN-ADDR-OPT]
               Matsumoto, A.M., Fujisaki T.F., and T. Chown,
               "Distributing Address Selection Policy using DHCPv6", Working
               Work in Progress, April 2013.

   [I-D.ietf-dhc-secure-dhcpv6]
             Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working
             in progress, March 2012.

   [I-D.ietf-dhc-addr-registration]
             Jiang, S., Chen G., and S. Krishnan, "A Generic IPv6
             Addresses Registration Solution Using DHCPv6", working in
             progress, February 2013.

   [I-D.liu-6renum-dhcpv6-slaac-switching]

   [6RENUM-SLAAC]
               Liu, B., "DHCPv6/SLAAC Address Configuration Switching
               for Host Renumbering", Working Work in Progress, July 2012.

   [I-D.liu-bonica-dhcpv6-slaac-problem]

   [CFENGINE]  CFEngine, <http://cfengine.com/what-is-cfengine>.

   [DHCPv6-SLAAC]
               Liu, B., B. and R. Bonica, "DHCPv6/SLAAC Address
               Configuration Interaction Problem Statement", Working Work in
               Progress, February 2013.

   [cfengine]http://cfengine.com/what-is-cfengine

   [IPv6-RENUM-THINK]
               Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things
               to think about when Renumbering an IPv6 network", Work in
               Progress, September 2006.

   [LEROY]     Leroy, D. and O. Bonaventure, "Preparing network
               configurations for IPv6 renumbering", International of
               Network Management, 2009, <http://
             inl.info.ucl.ac.be/system/files/dleroy-nem-2009.pdf> <http://inl.info.ucl.ac.be/
               system/files/dleroy-nem-2009.pdf>

   [PREFIX-DHCPv6]
               Jiang, S., Xia, F., and B. Sarikaya, "Prefix Assignment
               in DHCPv6", Work in Progress, February 2013.

   [SECURE-DHCPv6]
               Jiang, S. and Shen S., "Secure DHCPv6 Using CGAs", Work
               in Progress, March 2012.

Authors' Addresses

   Bing Liu
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus
   No.156 Beiqing Rd.
   Hai-Dian District, Beijing 100095
   P.R. China

   Email:
   EMail: leo.liubing@huawei.com

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus
   No.156 Beiqing Rd.
   Hai-Dian District, Beijing 100095
   P.R. China

   Email:
   EMail: jiangsheng@huawei.com

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland, 1142
   New Zealand
   EMail: brian.e.carpenter@gmail.com

   Stig Venaas
   Cisco Systems
   Tasman Drive
   San Jose, CA 95134
   USA

   Email:
   United States
   EMail: stig@cisco.com

   Wesley George
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA 20171
   USA
   United States
   Phone: +1 703-561-2540
   Email:
   EMail: wesley.george@twcable.com