Site Renumbering (RENUM) BOF at IETF 80 THURSDAY, March 31, 2011, 1520-1720, Congress Hall II Chairs: Brian Carpenter + TBD Sponsoring AD: Ron Bonica Mailing list: renum@xxxxxxxx Subscribe: https://www.ietf.org/mailman/listinfo/renum Description ----------- As outlined in RFC 5887, renumbering, especially for medium to large sites and networks, is viewed as an expensive, painful, and error-prone process, avoided by network managers as much as possible. Some would argue that the very design of IP addressing and routing makes automated renumbering intrinsically impossible. In fact, managers have an economic incentive to avoid having to renumber, and many have resorted to private addressing and Network Address Translation (NAT) as a result. This has the consequence that any mechanisms for managing the scaling problems of wide-area (BGP4) routing that require site renumbering have been dismissed as unacceptable. Even so, renumbering is sometimes unavoidable. It is expected that as the pressure on IPv4 address space intensifies in the next few years, there will be many attempts to consolidate usage of IPv4 addresses so as to avoid wastage, which necessarily requires renumbering of the sites involved. Unfortunately, current IPv4 deployment practices mean that automating this process appears extremely difficult. However, strategically, it is more important to implement and deploy techniques for IPv6 site renumbering, so that as IPv6 becomes universally deployed, renumbering can be viewed as a relatively routine event. For renumbering to become 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. The task of the RENUM working group is to identify specific renumbering problems in the context of site-wide renumbering, and 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, but solutions that apply equally to IPv4 may be considered. RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are starting points for this work. Goals/deliverables ------------------ Develop draft-jiang-ipv6-site-renum-guideline as a roadmap for the WG and for items that should be specified by other WGs. - The result of this work will be a more specific list of goals and deliverables Develop a management model for site renumbering. Milestones ---------- Jul 2011 draft-jiang-ipv6-site-renum-guideline ready for WGLC Sep 2011 draft-jiang-ipv6-site-renum-guideline ready for IESG Oct 2011 management model ready for WGLC Nov 2011 recharter with specific goals and deliverables Dec 2011 management model ready for IESG BOF agenda ---------- 0. Agenda Bash, Intro. (5 min) 1. Brief review of RFC 5887. (Brian Carpenter, 10 min) 2. Main lessons from UNH experience (Tim Winters, Lincoln Lavoie, 10 min) 3. Review of draft-jiang-ipv6-site-renum-guideline. (Sheng Jiang, 15 min) 4. Brief review of RFC 4192, and a management model for systematic renumbering. (Fred Baker, 15 min) 5. Brief announcements of "solution space" drafts (1 slide each, 2 min each): 5.1. Border Router Discovery Protocol (BRDP) framework, draft-boot-brdp-framework (Teco Boot) 5.2. Diagnostic function for SLAAC/DHCPv6 conflicts, draft-liu-ipv6-renum-conflicts (Sheng Jiang) 6. Discussion of goals and milestones. (30 min) 7. Discussion of conclusions (further work justified? WG? Which area?). (10 min) -- _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf