draft-chown-v6ops-campus-transition-03 IPv6 Campus Transition Scenario Description and Analysis Tim Chown University of Southampton (UK) IETF 66, July 12th 2006 Montreal

draft-chown-v6ops-campus-transition-03 Purpose of this document Validate the approach taken in the IPv6 Enterprise Network Scenarios text (now RFC 4057) Document the approach taken to deploy IPv6 (dual- stack) in a medium-size campus enterprise, and the specific tools used Feed into IPv6 Enterprise Network Analysis text, on relevance and usage of various tools Document ‘gaps’ in deployment

draft-chown-v6ops-campus-transition-03 RFC 4057 (Ent. Scenarios) Describes an approach to plan your enterprise IPv6 transition/integration process We validate that approach in Sections 2, 3 and 4: University department (1,000+ hosts, 1,500+ users) Network infrastructure components Network infrastructure component requirements Specific scenario component review We found this covered 95%+ of our needs (Two) missing considerations listed in Section 9 e.g. WLAN access control

draft-chown-v6ops-campus-transition-03 Analysis Section 5: dual-stack deployment procedure We describe three phases: Advanced planning Testbed/trial deployment Production deployment Section 6: Transition toolbox discussion We used VLANs (draft-ietf-v6ops-vlan-usage-01) as an interim measure, IPv6 tunnel broker, 6to4 relay We didn’t use NAT-PT, ISATAP, Teredo

draft-chown-v6ops-campus-transition-03 Missing components Covered in Section 8 Includes: Vendor/platform specific (bulk of section) Standards Application specific Other (policy/political) Ongoing section; liable (we hope!) to change for the better over time

draft-chown-v6ops-campus-transition-03 Next steps? Comments? Is such a case study useful? Comments from other enterprises? WG adoption? Maybe whittle down or even remove ‘gaps’ section to help make the case study stand the test of time? Abstract gaps to a separate ‘living’ ID? Address planning was abstracted to the ‘addcon’ document (draft-ietf-v6ops-addcon-01)