**************************************************************** Site Renumbering (renum) BOF - IETF80 - March 31, 2011 **************************************************************** ----------------------------------------------------------------- 0) Agenda bash http://www.ietf.org/proceedings/80/agenda/renum.txt ----------------------------------------------------------------- - Brian Carpenter, Tim Chown co-chairs - Same Note Well disclosure rules apply here as for WGs - Need to stay focused on-topic - BOF sponsored by Ron Bonica - not able to attend but present on Webex, Jabber and audio feed - Brian presented a summary of the draft description/charter for the proposed renum WG - Renumbering sometimes unavoidable - Three documents as starting points (RFC4192, RFC5887, draft-jiang-ipv6-site-renum-guideline-00); plus an older draft from Tim Chown (draft-chown-v6ops-renumber-thinkabout-05) which was drawn upon to create RFC5887 ----------------------------------------------------------------- 1) Renumbering still needs work (RFC5887) http://tools.ietf.org/html/rfc5887 http://www.ietf.org/proceedings/80/slides/renum-1.pdf ----------------------------------------------------------------- - Renumbering is a non-issue for many users (e.g. renumbering a CPE every time you boot, for a simple single subnet home network) - Planned renumbering of larger sites sometimes needed: - when change ISP - when add a second ISP - when ISP has to renumber - etc. - Note: PI, ULA, NAT don't get you completely away from renumbering - A hard target - but we need a solution for renumbering - The RFC includes a survey of existing mechanisms/tools (DHC, SLAAC, etc.) - IPv6 gives multi-addressing, allows the RFC4192 'no flag day' approach - It surveys operational issues - hard ones are application-layer issues and management issues - Problem - finding all of the configuration files that have addresses - Possible mechanisms - shim6, MANET work, etc - Gap analysis - address lifetimes in socket API, etc. Lots of little things that don't work well - How to tell peers that your address has changed - e.g. what if MIPv6 HA renumbers? - No questions ----------------------------------------------------------------- 2) UNH-IOL Testing Event - Tim Winters http://www.ietf.org/proceedings/80/slides/renum-7.pdf ----------------------------------------------------------------- - RFC6204 testing run by UNH for DOCSIS and Ethernet CE routers - DHCPv6 Prefix delegation for renumbering - DHCPv6 reconfigure is preferred method - DHCPv6 renew is another method - DHCPv6 reconfigure not included in all CEs - DHCPv6 renew/reply - servers were sending two IA_PDs, but routers were only servicing the first - caused loss of connectivity - Recommendations - renumbering through renew/reply was the most successful approach Brian Carpenter - Tim, you did an IPv6 renumber in 6NET, have things gotten better since? Tim Chown - we didn't have DHCPv6 PD then, but the network element renumbering/multi-addressing worked fine (results on 6NET web site) Tim Winters - thought Reconfigure would work, but it didn't. Lots of moving parts - DHCP PD, SLAAC, M&O bits, etc. ----------------------------------------------------------------- 3) IPv6 site renumbering guidelines - Sheng Jiang http://tools.ietf.org/html/draft-jiang-ipv6-site-renum-guideline-00 http://www.ietf.org/proceedings/80/slides/renum-8.ppt ----------------------------------------------------------------- - Renumbering is not new - standing on shoulders of giants - Dates back to at least RFC1900 - "Renumbering needs work" - Long list of additional RFCs and credits - Focusing here on IPv6 renumbering - Three perspectives on issues: network design, network operation, renumbering operation - Summarised requests to extend current protocols - Recommends network choosing only one of SLAAC or DHCP - DNS record updates - Security mechanisms needed, e.g. SEND - Misc: addresses should not be used to configure network utilities - Management: stable records and long lifetimes means less flexibility - Transition period - ideally needs to be longer than all address lifetimes - Many unsolved remaining issues - But some of the unsolved issues are harmless and/or minimal impacts - Routers might need to be restarted due to renumbering - RFC2072 - Further analysis needed - Many non-network issues - Requests to extend protocols - diagnostic function to detect conflicts, combine forward and reverse DNS updates, etc. Brian - note this is a very early draft; there is much more development to come Sheng - the draft was drawn up from from material in RFC5887 Lee Howard - concerned about recommendation to choose either SLAAC or DHCP, need to figure out how to reconcile them Sheng - coexistence is possible; working on the issues, but we're trying to make coexistence better Brian - managed networks can take that approach but not unmanaged Bob Hinden - different IPv6 deployments will do different things on different subnets Teco Boot - problems with both SLAAC and DHCPv6 - need to take away the problems Tim C. - have different address configuration mechanisms in a campus; manual servers, DHCPv6 for managed and SLAAC for unmanaged systems. Brian - we need clarity for both managed and unmanaged scenarios ----------------------------------------------------------------- 4) Renumbering Networks (RFC4192) - Fred Baker http://www.ietf.org/proceedings/80/slides/renum-2.ppt ----------------------------------------------------------------- - Fred told a story - thought renumbering wasn't hard and thought he was missing something, so he wrote an Internet draft. Went to operators to ask what was hard. After discussion, Fred, Ralph Droms and Eliot Lear got together and wrote a first draft - Turned out is was hard. The reason: almost any configuration tool can change the network configuration - The problem is stupidity - places where people write down numbers instead of names - Thing #1 that makes renumbering hard - human stupidity - Fred went on to describe how Cisco outsources much of its manufacturing and shipping, but in one case as units were shipped scanners noted down addresses of equipment, and sent data back to the company, but by IP address! - The fix: DNS! - Thing #2 - numeric router configurations - Examples of configuration paradigm - not as simple as adding things to ACLs and removing things Fred continued part two of his talk - My View of Network Renumbering - Q: how did the network box get a number in the first place? - There is some kind of configuration language, program, etc. in place - A simple approach might be to build a configuration management tool - Need it to be able to add or delete prefixes/addresses - It would handle both the initial numbering of the network and subsequent renumbering of the network Brian - what if the site manager doesn't have tools? Fred - they might want to get tools Cathy Aronson - IPv6 addresses are hard to remember - need to use a name. Addresses dynamically assigned - need to deal with customer networks as well as your own Fred - just added this to the list Mark Rample(?) - point on human stupidity - firewall rules with IP addresses Fred - suggests a network management tool to deal with a database of ACL settings. Need it to be ONE manager that changes by add/drop Mark - 2nd observation - hasn't IPv6 introduced a problem? In IPv4, renumbered and only had to change the firewall (NAT). Took 10-15mins. In IPv6, addresses are back in the customer network. Joel Jaeggli - firewalls need configuration management policy tool. Need the problem to be made tractable. Wes George - need to decide on goals. ----------------------------------------------------------------- 5) Solution Space proposals ----------------------------------------------------------------- The chairs explained these talks were only included as 1-slide lightning talks to show there is interest in solutions in the renumbering space; solutions are not in scope for the discussion today though. 5a) Teco Boot - BRDP http://www.ietf.org/proceedings/80/slides/renum-3.pdf - edge networks have multiple uplinks to multiple ISPs - single edge network - source-address based forwarding (packets from ISP1 source address go through ISP1) - advertise prefixes downlink in multihop fashion - work came from MANET space 5b) Fred Templin - IRON http://www.ietf.org/proceedings/80/slides/renum-4.ppt - Fred described his overlay network approach (see RFC6179) - falls in the category of renumbering avoidance 5c) Remi Despres - approach; not a solution http://www.ietf.org/proceedings/80/slides/renum-5.pdf - renumber hosts, but avoid renumbering routers - hosts must cooperate - encapsulation of one family in a second family - using ULA local IPv6 addressing - when site changes providers, send DHCPv6 update and hosts do the updates 5d) Bing Liu - SLAAC/DHCPv6 conflict diagnostics during site renumbering http://www.ietf.org/proceedings/80/slides/renum-6.pdf - prefix announced - if host detects conflict, reports mistakes to network - admins can identify mistakes during renumbering - human stupidity is a key issue ----------------------------------------------------------------- 6) Discussion of goals and milestones ----------------------------------------------------------------- Brian - if we assume for a moment that there will be a WG formed, let's look at the goals and milestones Fred Baker - WG description - build a mechanism/tool/procedure/etc. to provide for site-wide renumbering? Brian - yes Fred - thinks renumbering is a special-case of numbering; if we are going to charter a WG to look at small aspect of numbering, probably should do a WG to look at configuring and managing a *network* Brian - Are we trying to build a single tool, or a methodology? Fred - bigger problem has to solve it anyway Bob Hinden - lots of thought about this earlier, IPv6 was designed to make this easier. Supports the work. Making renumbering routine is too high of a goal - should be happy if we could get to 90%. Should be a non-goal to renumber every day. Tim Chown - we should discuss how realistic things are Brian - RRG looked into frequent renumbering, but unrealistic (Bob is right) Erik Kline - things often managed by completely different organizations. Application problem - need configuration updates from different systems, e.g. netconf WG. Could lead there dangerously. Tim C. - the issue is not dissimilar to scenarios where a site has policy in place on data protection, but information leaks due to republishing by others - it's similar with renumbering, the numbers may be used by users or non-network teams at the site in unexpected ways Brian - after renumbering, CERN program library had a statistics module with hard-coded numberings Tim Shepard - thinks IPv6 deployment incredibly important. Solving this problem is necessary for the viability of IPv6. Huge problem and scary. Problem isn't solved by an IETF WG - problem is in the heads of network admins who think they know how to deploy IPv6. Tim C. - just reinforcing Fred B.'s point Tim S. - act of typing an IPv6 address is creating a future problem Tim C. - may be protocol gaps or ambiguities in protocols; we should seek to identify and remedy both where possible Tim S. - wants a WG, but it may not be enough Brian C. - what admins will do for IPv6 is close to the same practice that is used for IPv4 Shane Amante - supports taking the work on, but wants more specificity. Put difficult parts later in the process. Have to do this, because PI is not sustainable. Lee Howard - after hearing Fred's presentation and the 1-slide talks, at least 7 major problems. Making one single point of reference scary due to single point of failure, human errors. There are a number of problems - not just one problem. We should only solve this for IPv6 Brian - IPv4 problem is overtaken by events Lee - IETF cannot resolve human stupidity. We are creating a single point of attack if we're not careful. Doesn't think it is tractable with the charter as written. Chris Morrow - thinks that could be addressed by abstractions, but not in actual device. Goal of IRTF wasn't renumbering. Making renumbering for a single organization may be tractable. When IPv6 was finished 10 yrs ago ... problem now is configuration management; not address management Mark Townsley - problem space centered around large / medium-sized sites, also actively-managed networks. Will this work also include small networks and unmanaged networks? Tim Chown - need to consider low power subnets/PANs in SOHOs - what happens when the ISP renumbers? Users just want remote light switches to work when controlled via their multi-subnet home network Mark T. - flash-cut renumbering of residential networks necessary Tim C. - ULAs could be in-scope. Will be discussed in v6ops later today Brian - is our scope managed networks, unmanaged, or both? Thomas Narten - extremely pessimistic that we can do anything in this space. Reality of gap between what we have today and where we need to get to is tremendous. E.g. site with 100 routers - how can we help them? Lots we have to do, but not sure we can help them. Gap is astonishing, people who do this stuff don't attend this meeting. Need to peel off specific problems before we jump into this work. Brian - should we do piece-parts? Thomas - look at architecture Greg Lebovitz - have to do this in order to prevent IPv4-like NATs. Rather have great minds fail while trying rather than give up now because it looks too difficult. ----------------------------------------------------------------- 7) Proposed WG charter targets ----------------------------------------------------------------- Brian Carpenter - shows list of initial goals/deliverable/milestones Wes George - list of milestones looks vague - do we want to talk about solutions, and will they solve the problems? Do we want to farm off application issues to application area? Need to have not as many IP addresses in CLI in routers anymore. Need to have these things in initial set of goals. Brian - can this be integrated into charter? Wes - yes, some work needed though. Ralph Droms - Thomas' remarks - tension between tool development, and big problem with a number of steps along the way. May not be able to get to a complete automation from beginning to end. Keep in mind that these things will be deployed but human beings. Need to coordinate human operations. Brian - milestone dates unrealistic. Won't have this done by IPv6 day. Dan Romascanu - question on 2nd deliverable - are there people interested in working on a management model for site renumbering? Brian - wants to ask Fred B. work work on managed side. Need to find someone for unmanaged side. Remi Despres - can we present solutions here, or is it just renumbering guidelines Brian - need to be clear on problem statement and guidelines before looking at solutions Brian - solutions identified here might belong in different WGs Ralph Droms - pieces being coordinated - one piece shouldn't break the other pieces. Understand problem here before charging off into solutions Tim Chown - make the items clearer Bob Hinden - router renumbering RFC - will you look at this? Brian - wasn't much information available Bob - might want to look at this Brian - we could ask volunteers to look into this and read it Ralph - document doesn't have sufficient controls, synchronization, etc. Talks about prefix substitutions, but not much more. Bob - maybe fix the router renumbering document? Wes George - possibly have fixing the document as top of the list Thomas Narten - router renumbering was an academic exercise, but disconnected from reality ----------------------------------------------------------------- 8) Conclusion discussion ----------------------------------------------------------------- Brian - should further work be done (draft charter needs to change)? Thomas - how can anyone be opposed to working on this, but what can we do to make a difference? Dan Wing - doesn't think we can be successful Thomas - work on the tractable problems Tim C. - it's an 80/20 thing - need to identify and prioritise work items Scott Brim - thinks we should go forward on this David Kessens - topic has been discussed so many times, but nothing in charter to do something complete. Unless we can come up with something that we can complete, shouldn't do a working group Brian - a number of goals in the draft charter - not just handwaving Glenn Kowack - problem needs to be solved - need to pay attention to the cost. One possible outcome is to identify some other group that can get this done. A moment of Zen; it's a little like Y2K. Remi Despres - likes the idea of identifying problems that are tractable and those that are not. Tim Shepard - pessimistic, but we should still try. More urgent things are not writing drafts. Need to get people to think about places where IPv6 addresses are typed in. Maybe we need to set up a wiki? Get people to share all of these places where renumbering is needed. Need to get the word out. Cathy Aronson - RIR issues - infinite number of addresses in IPv6, so policies are that people get PI blocks because renumbering is hard. Has implications on the routing table. May may/not be doing this in an efficient way. Lorezno Colitti - look at access networks, enterprise networks, mobile networks. People say this is too hard, and he kind of agrees. No "magic wand" to renumber an entire AS - too ambitious. However, operational community doesn't know how to renumber at even a small scale. So, for the smaller tasks we have a lot of the pieces but still don't know how to put them together. Can ssh into routers and do what he wants. Maybe we can focus on individual parts like renumbering a CPE, renumbering a mobile network, etc. Sheng Jiang - agrees issue is difficult. Does not mean that every small step is not useful. Start with small steps, may still have problems, but our work will make things better. Greg Lebovitz - hears Lorenzo saying we want well-defined and useful use cases. Ruediger Volk - getting depressed. What idea did the RRG chairs have when they put renumbering avoidance as an architectural goal? Probably we should do something like the avoidance. In general, probably picking things where names/numbers need to be matched is an area where fixed identification is relevant. But, this needs to be separated out. Big jump in architecture - especially for host stacks. Restrict renum to domains where it can be managed (e.g., provider networks). Brian - how many people willing to work on documents? 10-12 Brian - how many think we should have a WG? 20-25 Brian - how many think we should NOT have a WG? 5-6 Brian - how many unsure? 12 Thomas Narten - is it premature to form a WG? BOF might be appropriate, but what would be appropriate for WG? Brian - WG gives a point of focus Scott Brim - should it be a research group? Brian and Wes - No! Greg Lebovitz - problem is immediate - not a research group issue. Dan Romascanu - Ron on audio stream but couldn't jabber. Dan's opinion is there is a certain level of interest, but problem statement needs to be developed. Ron Bonica - at the moment, I am torn. Ralph Droms - keep folks who run networks in the loop. Is there some way we could adopt a model like the IETF tools development group? Can we move forward incrementally? Brian - not just ISP operators, but also enterprise operators Ralph - Zigbee alliance, 802.15.4 analogy. How to do this for completely unmanaged networks? Ron Bonica - give me a day or two to think about it. Ralph - research group on renumbering avoidance is a good topic Cathy - renumbering avoidance is what we do NOW! ----------------------------------------------------------------- [ end of BOF ] -----------------------------------------------------------------