Subject: [renum] WG Review: IPv6 Site Renumbering (6renum)

From: IESG Secretary <[email-masked]>
Date: Thu, 2 Jun 2011 10:54:54 -0700 (PDT)

A new IETF working group has been proposed in the Operations and 
Management Area.  The IESG has not made any determination as yet. The 
following draft charter was submitted, and is provided for informational 
purposes only. Please send your comments to the IESG mailing list 
([email-masked]) by Thursday, June 9, 2011                            

IPv6 Site Renumbering (6renum) 
-------------------------------
Last Modified: 2011-06-02

Current Status: Proposed Working Group

Chairs: TBD

Area Director: Ron Bonica

Mailing list
  Address: [email-masked]
  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 IPv6 adoption begins to gather momentum, those managers may turn to
PI addressing for IPv6 to attempt to minimise the need for future 
renumbering. However, such an approach would create very serious BGP4
scaling problems if used by millions of end sites; it is thus desirable 
to develop tools, techniques and practices that may make renumbering a
simpler process, to reduce demand for IPv6 PI space. In addition, as
RFC 5887 describes, there are other 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.   

Strategically 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.

For renumbering to become more routine, a systematic address management 
approach will be essential. A large site with a short prefix will be 
divided into subnets with longer prefixes. In this scenario, renumbering 
or partial renumbering can be complicated. Aggregation, synchronisation, 
coordination, etc., need to be carefully managed, and the use of 
manually inserted address literals minimised. In unmanaged scenarios, 
consideration may 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 managed (enterprise) and unmanaged (SOHO) networks, to 
identify specific renumbering problems in the context of site-wide 
renumbering, and to then recharter with a view to develop point 
solutions and system solutions to address those problems or to stimulate 
such development in other working groups if appropriate.  The principal 
target will be solutions for IPv6.

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 managed 
   (enterprise) and unmanaged (SOHO) networks.  These texts should 
   contribute towards the gap analysis and provide an agreed basis for 
   subsequent WG rechartering towards development of solutions 
   (potentially in other WGs) and improved practices. Operator input 
   will be of particularly high value for this stage.

2. To examine fully automatic, self-organising networks (manet/autoconf) 
   as a possible third scenario. 

3. To perform a gap analysis for renumbering practices, drawing on RFCs
   4192 and 5887, to identify generic issues for network design, network
   management, and renumbering operations. The scenario texts will
   contribute to the analysis.

4. To document existing IP address management models and practices with
   a view to proposing (at a high level) an appropriate model to allow
   simplification of any partial or full site renumbering process
   (this would likely be applicable to managed rather than unmanaged
   scenarios).

The general methodology for the WG will be to first build managed and
unmanaged baseline scenario descriptions, while in parallel undertaking 
an initial gap analysis from existing work in (at least) RFC4192 and 
RFC5877. As the scenario texts harden, their contributions will be 
incorporated into the gap analysis, which can be published once the 
scenarios are completed.   

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.  More benefit can be achieved by focusing effort on site 
   renumbering.  The site analysis should include the ISP's role in its 
   own renumbering event.

A recharter of the WG will be possible once the gap analysis and 
scenario descriptions are completed, and the IP address management 
('numbering tool') review and (high level) proposal have been published.   
The rechartering will identify more specific work items within the 
6RENUM WG or appropriate protocol WGs. 

Milestones
----------

Aug 2011    managed (enterprise) scenario draft ready for WG adoption 
            (partly based on draft-jiang-ipv6-site-renum-guideline)

Aug 2011    unmanaged (SOHO) scenario draft ready for WG adoption

Oct 2011    gap analysis document ready for WG adoption (already some 
            considerations in RFC5887 and 
            draft-jiang-ipv6-site-renum-guideline)

Oct 2011    management model draft ready for WG adoption

Jan 2012    managed (enterprise) scenario draft ready for WGLC

Jan 2012    unmanaged (SOHO) scenario draft ready for WGLC

Feb 2012    management model ready for WGLC

Mar 2012    gap analysis document ready for WGLC

Apr 2012    recharter WG towards solution space

---

From: Scott Brim <[email-masked]>
Date: Thu, 2 Jun 2011 20:38:32 -0400

In favor. The problems and tradeoffs need to be explored, analyzed and
documented.

---

From: Tim Chown <[email-masked]>
Date: Fri, 3 Jun 2011 11:26:48 +0100

I have alerted Ron to the fact that the old description has been used. The correct description, which was posted to renum yesterday after feedback from the list, is as follows:

IPv6 Enterprise Site Renumbering (6RENUM) WG
Chairs: TBD
Area Director: Ron Bonica

Mailing list Address: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/renum 
Archive: http://www.ietf.org/mail-archive/web/renum/

Description
-----------

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
------------------

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.

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.

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 

Tim

On 2 Jun 2011, at 18:54, IESG Secretary wrote:

> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Jun 2011 11:31:44 -0700

Thanks.

I'm in favor of this.

On Jun 3, 2011, at 3:26 AM, Tim Chown wrote:

> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum