* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

6renum Status Pages

IPv6 Site Renumbering (Concluded WG)
Ops Area: Robert Wilton, Warren Kumari | 2011-Jun-14 — 2013-Oct-11 
Chairs
 
 


2013-09-20 charter

IPv6 Site Renumbering (6renum)
------------------------------

 Charter

 Current Status: Active

 Chairs:
     Tim Chown <tjc@ecs.soton.ac.uk>
     Lee Howard <lee.howard@twcable.com>

 Operations and Management Area Directors:
     Benoit Claise <bclaise@cisco.com>
     Joel Jaeggli <joelja@bogus.com>

 Operations and Management Area Advisor:
     Joel Jaeggli <joelja@bogus.com>

 Secretary:
     Sheng Jiang <jiangsheng@huawei.com>

 Mailing Lists:
     General Discussion: renum@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/renum
     Archive:            http://www.ietf.org/mail-archive/web/renum/

Description of Working Group:


    As outlined in RFC 5887, renumbering, especially for medium to large
    sites and networks, is currently viewed as an expensive, painful, and
    error-prone process, avoided by network managers as much as possible.

    As that RFC describes, there are triggers that mean some cases of
    renumbering are unavoidable, so it should be considered a given that a
    site may need partial or complete renumbering at some stage. It is thus
    important to implement and deploy techniques that facilitate simpler
    IPv6 site renumbering, so that as IPv6 becomes universally deployed,
    renumbering can be viewed as a more routine event. This includes
    consideration of how the initial assignment and subsequent management of
    address information is performed, as this will affect future renumbering
    operations.

    If IPv6 site renumbering continues to be considered difficult, network
    managers will turn to PI addressing for IPv6 to attempt to minimise the
    need for future renumbering. However, widespread use of PI may create
    very serious BGP4 scaling problems. It is thus desirable to develop
    tools and practices that may make renumbering a simpler process to
    reduce demand for IPv6 PI space.

    Renumbering, or partial renumbering, can be complicated in an enterprise
    site where a short prefix is divided into subnets with longer prefixes.
    Aggregation, synchronisation, coordination, etc., need to be carefully
    managed, and the use of manually inserted address literals minimised.

    Other factors such as applications binding long-term to low level IP
    addresses may add constraints to what can be realistically achieved, but
    identifying and documenting such factors is a useful objective.  In some
    scenarios, consideration may also need to be made for 'flag day'
    renumbering (in contrast to the procedure described in RFC4192).

    The task of the 6RENUM working group is to document existing renumbering
    practices for enterprise site networks and to identify specific
    renumbering problems or 'gaps' in the context of partial or site-wide
    renumbering.  Completion of these tasks should provide a basis for
    future work to identify and develop point solutions or system solutions
    to address those problems or to stimulate such development in other
    working groups as appropriate.

    6RENUM is chartered to perform an analysis of IPv6 site renumbering. If
    the analysis leads to conclusions that are also applicable to IPv4 that
    will be an advantage, but it is not an objective of the WG to make its
    outputs more widely available than IPv6. Similarly the WG is targeting
    enterprise networks, but the analysis may also be applicable to SOHO or
    other (e.g. ad-hoc) scenarios.

    It may be that for site renumbering to become more routine, a systematic
    address management approach will be required. By documenting current
    practices and undertaking a gap analysis, we should become better
    informed of the requirements of such an approach. Post-analysis
    rechartering may lead to further work in this area. RFC 4192, RFC 5887,
    and draft-jiang-ipv6-site-renum-guideline are starting points for this
    work.

    Goals/deliverables
    ------------------

    The goals of the 6RENUM working group are:

    1. To undertake scenario descriptions, including documentation of
    current capability inventories and existing BCPs, for enterprise
    networks, including managed and unmanaged elements. These texts should
    contribute towards a gap analysis and provide an agreed basis for
    subsequent WG rechartering towards development of solutions (which may
    be more appropriate for other WGs to undertake) and improved practices.
    Operator input will be of high value for this text.

    2. To perform a gap analysis for renumbering practices, to identify
    generic issues for network design, network management, address
    management and renumbering operations. The methodology for the WG will
    be to begin building the enterprise scenario description while in
    parallel constructing an initial gap analysis drawing on existing work
    in (at least) RFC4192 and RFC5887. As the scenario text hardens, its
    contributions will be incorporated into the more detailed gap analysis,
    which can be published once the scenario text is completed. The
    deliverables are thus the scenario and gap analysis texts.

    The following topics are out of scope for the working group:

    1. Renumbering avoidance; this can perhaps be considered by appropriate
    IRTF groups. As documented in RFC5887, renumbering cannot be completely
    avoided. The WG is limited to dealing with how to renumber when it is
    unavoidable.

    2. IPv4 renumbering. While many sites are likely to run dual-stack, IPv6
    is the future and, especially given concerns over extensive use of IPv6
    PI, the most appropriate place to focus effort.

    3. ISP renumbering; this is potentially the most complex renumbering
    case. However, more benefit can be achieved by focusing effort on site
    renumbering. The enterprise site analysis should include the ISP's role
    in the site's renumbering events.

    4. Neither SOHO nor manet networks are targeted by the WG. However, if
    outputs from the WG are applicable to those scenarios, that would be an
    advantage.

    A recharter of the WG will be possible once the gap analysis and
    scenario description are completed and published. Such rechartering
    would identify more specific work items within the 6RENUM WG or
    appropriate protocol WGs, and may include a proposal for work on a
    systematic address management approach.



Goals and Milestones:
  Oct 2011 - IPv6 enterprise site scenario draft ready for WG adoption
  Nov 2011 - Gap analysis document ready for WG adoption
  Jun 2012 - IPv6 enterprise site scenario draft ready for WGLC
  Jul 2012 - Gap analysis document ready for WGLC
  Jul 2012 - Static addressing gap analysis doc ready for WG adoption
  Aug 2012 - Static addressing gap analysis doc ready for WGLC


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/6renum/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -