IETF81 Quebec 6renum WG meeting Date: 27th July 2011 Chairs: Tim Chown, Wes George Scribe: Eric Vyncke (evyncke@cisco.com) ------------------------------------------------------------ Introduction, Agenda Bashing, Document Status, Chairs ------------------------------------------------------------ The BoF at last meeting was a good one. The resulting focused charter has two goals, each with an associated deliverable text: 1. Scenario descriptions and BCP for IPv6 enterprise networks 2. Gap analysis The WG results may inform SOHO or IPv4 networks, but the focus is the IPv6 enterprise. Background reading presented by Tim: RFC 2894, 4192, 4076, 5887 & draft-chown-v6ops-renumber-thinkabout ------------------------------------------------------------ IPv6 Enterprise Network Renumbering Scenarios and Guidelines ------------------------------------------------------------ draft-jiang-6renum-enterprise-00 Sheng Jiang The goal is to make renumbering as easy as possible to avoid the explosion of demand for PI space. The WG is chartered to document existing BCP in enterprise networks; it may be possible that some of that BCP could also be applied to ISPs. Question raised on whether gaps identified in the enterprise analysis should be documented in the enterprise text or just moved to the gap analysis I-D? A: the important aspect is to capture the gaps in the gap analysis text. RFC4057 has a definition of an enterprise network. Main causes of renumbering: changing of ISP hence getting new PA prefix (external factor) but also because of merging, splitting, re-organising (internal factors). The use of PI space does not avoid renumbering driven by internal factors. Gunter Vandevelde: could also have one prefix removed (such as going from 3 providers to 2 providers). Lee Howard proposes a new use case: a SMB could move to a different location and even if keeping the same ISP they would probably get a new PA prefix. Sheng highlighted some BCP open questions: - Whether DHCP-PD is enough to manage prefix delegation - Should we use DNS as much as possible? - What can we do with manually configured hosts? - Should ULA be recommended? Attendee: ULA could be useful for sensors because they are stable. Marc Lampro: with two providers, easier to use ULA (Wes: then we have NPT66?). Eric Vyncke: we should recommend NOT to use ULA in enterprise. Tim Chown: we need to be clear whether we expect ULAs to be natted, or for hosts to have a ULA for local commincation and a global address for global communication. Mark Townsley agreed wholeheartedly with the latter and referenced homenet BoF. Tim suggests we should support a model where both SLAAC & DHCPv6 are used in the same network (and mention all potential problems), whether on purpose or not (including malicious users). Joel Halpern: SAVI has a mixed-mode document where SLAAC & DHCPv6 are used for the same prefix => should reuse the SAVI document. Sheng: Should we recommend A6 (RFC 3363) because of its advantage for renumbering? Stig Venaas: last experience with A6 is at least 5 years oldÉ Dynamic DNSSEC update can be complex. Eric Vyncke: use of DNSEC is becoming more common so let's use it. Marc Lampro: be cautious about lifetime, CNAME can have a very long lifetime, only AAAA are concerned with renumbering. Security recommendation: during renumbering there is a potential exposure to address hijacking. No current BCP to handle black lists. Eric Vyncke & Wes: black lists (such as spammer DNS black lists) are for the Internet and are out of scope for this WG that focuses on enterprise. Gunter Vandevelde: should have a section on routing protocols. Other questions: Flag day? Is it triggered by a network event? Lee Howard: using RA lifetime is good but should also include DNS RR lifetime (Tim: and other application related timers, and we should consider session survivability). Discussion: Marc Lampro: The text is currently missing ACL renumbering Gunter Vandevelde: We may want to add different kinds of network complexities ------------------------------------------------------------ IPv6 Site Renumbering Gap Analysis ------------------------------------------------------------ draft-liu-6renum-gap-analysis-01 Bing Liu Bing started with a review of the renumbering goals: automatic, accurate with minimum human intervention. The goal of the I-D is to identify valuable and solvable issues and give proposals. (Tim: The gap analysis should document all gaps, whether we believe the can be solved now or not) Bing presented methods to get a prefix. Gunter Vandevelde: We should add 6rd which also provisions an IPv6 prefix. The M bit in RA is only vaguely specified. DHCPv6 is not ready for bulk usage. RA prefix lifetime has a minimum duration of 2 hours minimum specification (without authentication of the RA). Eric Vyncke: We can use preferred lifetime which can be 0. (see RFC 4192) RFC2072 mentions that some routers cache IP addresses in some situations. Do we then need to restart the routers when renumbering? RFC4192 suggests that routers & switches should support FQDN in configuration. Is that method used widely? Should we propose a lighter protocol to update DNSSEC? In some cases, a zone cannot be dynamically updated by lack of privilege/delegation of authority. Another issue is the update of address-based filters... Can this update be done over a standard protocol? Addresses are often hardcoded in configuration files in servers and hosts. Other issue how can we synchronize all the renumbering events and how can we monitor the operations? Multicast - if the RP address changes, then the group addresses change accordingly => need to change at the application layer. Discussion Tim: in Prague, 20 people have agreed to contribute but not seen a lot of contributions or reviews. Contributors are very welcome.