1 / 6

K. Chittimaneni, T. Chown , L. Howard, V. Kuarsingh , Y. Pouffary , E. Vyncke

IETF LIM Amsterdam, The Netherlands. Enterprise Incremental IPv6 draft -ietf-v6ops-enterprise -incremental- ipv6. K. Chittimaneni, T. Chown , L. Howard, V. Kuarsingh , Y. Pouffary , E. Vyncke. Updates. Document accepted as WG item

atira
Download Presentation

K. Chittimaneni, T. Chown , L. Howard, V. Kuarsingh , Y. Pouffary , E. Vyncke

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETFLIM Amsterdam, The Netherlands • Enterprise Incremental IPv6draft-ietf-v6ops-enterprise-incremental-ipv6 K. Chittimaneni, T. Chown, L. Howard, V. Kuarsingh, Y. Pouffary, E. Vyncke

  2. Updates • Document accepted as WG item http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01 • Changed name to “Enterprise IPv6 Deployment Guidelines” • Addressed some comments from list • Updated references • 3.4.3 Specific Security Issues for IPv6 • Clarified that the use of Privacy extension addresses requires the additional monitoring and logging • Added reference to draft-ietf-opsec-v6-00 • 5.1 Network Infrastructure • Made it explicit that OSPFv2 and v3 are not the same • Added reference to draft-matthews-v6ops-design-guidelines

  3. Mailing List Comments (1/2) • Clarify that whether or not the ISP may provide native IPv6 services has no bearing on whether the enterprise should also provide native IPv6 services • Add a statement that states that many of the reasons given in this section are new since the publication of RFC1687 and do give good reasons for transition • Add citation to reflect ease and speed of merging IPv6 networks • Elaborate on the PI/PA recommendations • Consolidate security and routing section • Move 3.6 “Program Planning” to be up on the top as 3.1 • Elaborate on operational costs vs. needs • Clarify recommendations on tunneling vs. translation vs. native and elaborate on where each makes sense

  4. Mailing List Comments (2/2) • Add reference to RFC6724, RFC 6177, RFC 5375 • Describe the issues and the importance of ICMP/pMTUd as it pertains to MTU settings • Add some text to cover NAT66

  5. Next Steps • Next pass to fill in rest of gaps • Get feedback on updated draft

  6. Q&A THANK YOU!

More Related