IETF-84 6renum WG Minutes Tuesday 31 July 2012 Chairs: Tim Chown (tjc@ecs.soton.ac.uk) Lee Howard (Lee.Howard@twcable.com) Minute taker: Gunther Van de Velde Welcome and administrivia, agenda bashing http://tools.ietf.org/agenda/84/slides/slides-84-6renum-0.pdf - no comments New WG chair Lee Howard Static Problem Enterprise Scenarios draft-ietf-6renum-enterprise-01.txt http://tools.ietf.org/agenda/84/slides/slides-84-6renum-1.pdf Status update: added section: Usage of ULA in 4.1 Believe that ULA can be served as a tool to avoid renumbering moved sections: Router awareness and border filtering to Gap Analysis section 5 deleted due to overlap with Gap Analysis Reference for RFC6563 is updated as it is historical Discussion: None. Solicitation for comments specifically on ULA and A6, none. One person using ULA. Gap Analysis http://tools.ietf.org/wg/6renum/draft-ietf-6renum-gap-analysis/ http://tools.ietf.org/agenda/84/slides/slides-84-6renum-2.pdf Status update: added description of IPAM tools in section 3.2, mentioned in a couple of places, suggest that integrating them could beneift the renumbering process added two topics about router awareness and border filtering deleted MSDP peers as out of scope Updated SLAAC/DHCPv6 co-existence analysis in section 5.1 Wrote draft-liu-6renum-dhcv6-slaac-switching confusion in M/O flags in updated SLAAC in RFC4862 the specification of the flags has been removed in this document The situation now: ISP's need clear definition of the M/O flags OS's bahaviour is different per system to fix this is very hard for the desktops Especially for renumbering: new requirement the behavior SLAAC and DHCPv6 then the original M/O definition network split/merge/relocation has specific behavior how does the network switch from SLAAC to DHCPv6? system behavior is different this difference results in better need for good definition Future Work:  http://tools.ietf.org/agenda/84/slides/slides-84-6renum-3.pdf By the chairs Have we captured the problem right? Wes George Believes that work here is good, but that the work is needs extra review. Move forward to find out if we missed anything. Tim Chown Capture the problems that we need to work upon Lee Howard Need problem space to start working on the solution space Sheng Jiang Some problems we said are too hard to solve. Some people say that renumbering is a too hard problem to solve, but believes that with the work done will provide new issues. Chairs ask again—is this work ready to move forward? Thumbs up and nods. Ron Bonica Yes, these documents capture the problem, and are close to being ready. Tim Chown: The renumbering problem needs to be fragmented in smaller chunks so it is digestable chunks Tim Chown What could we do next: push the existing drafts for publication hand the gaps over to the appropriate WG's recharter 6renum to provide a strategic steer to build  refine operational practices Should we look into rapid renumbering? or should it be left at Homenet Sheng Jiang Homenet said they would do renumbering Tim Chown Yes, but they haven’t done it yet, and somebody needs to be chartered to do it. But we’ll coordinate with them before rechartering. DNSEXT is closing, but we may have DNS work. Suggestions made for future work: interaction of SLAAC/DHCPv6, M/O flags Multicast DHCPv6 simplified secure dynamic DNS Sync DNS TTL with renumbering How to manage static addresses ACL/filter bulk update method improved IPAM support Wes A recharter is maybe not the best thing. Regarding additional work items, the list shown is going into protocol changes instead of operational elements. We should find homes for the work and trust them to work on them. None of the other work requires our expertise. Dan York If these suggestions is given to other WG's then how can they follow up? Don’t just throw work to them, we should go to those WG’s to write documents. Sheng Jiang Believes that this work needs to be done, and how can we make sure that it will progress? Ron Bonica Speaking as AD sees a list of things that nees to be done. Some chunks have already WG attached. Other chunks are non-homeble and they can go to the OPS Area WG. Suggests to go through the list and try to find a home for it. #1. Simplified secure DNS: DNSEXT is shutting down. Mark Andrews The work is largely done, the only trick is key management. Ron Bonica Key management, could go to DNSOPS? Mark Andrews Maybe. Our code can handle it. The Windows Domain model is a good one for us. The host registers with a network, then sends update. Lee Howard Good, write that document. Will it have a home? Ron Bonica Does it require a new protocol? Mark Andrews Could be done on top of TKEY, which exists. Ron Bonica Start it in DNSOPS, and if we need to move it out, we will. #2 Synchronizing DNS TTLs with renumbering. Mark Andrews What we really need is the ability to identify addresses in a deprecated state in the DNS. No way to do that in the DNS now. We could create a new type, “deprecated.” But you have to touch every node. Tim Chown Maybe need a BCP to honor TTL? Mark Andrews Should go to 6man to work through it. #3 Automated management of static addresing Sheng Jiang Mostly operational Time Chown All three of these last items could be operational. – Automatic management of static addressing – ACL/filter bulk update method – Improved IPAM support for renumbering Lee Howard Let’s take them to OPSAREA first; if protocol work is needed, we’ll move it from there. Tim Chown: Have an inventory find out what and who can work on it do we need re-charter? check with homenet on the rapid renumbering