[secdir] [new-work] REVISED WG Review: IPv6 Site Renumbering (6renum)

[IESG Secretary <[e-mail]>]

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 
([e-mail]) by Friday, June 10, 2011.               

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

Current Status: Proposed Working Group

Chairs: TBD

Area Director: Ron Bonica

Mailing list
  Address: [e-mail]
  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
------------------

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.

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 


_______________________________________________
new-work mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/new-work