Subject: [v6ops] Fwd: IETF v6ops doc review

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 8 Feb 2013 20:30:03 +0000

Comments from Cisco IT on the two documents in question

On Dec 11, 2012, at 3:41 AM, Jon Woolwine (jwoolwin) wrote:

> Sorry for the delay in getting back on this.  I reviewed the 2 docs
> below:
> 
> draft-ietf-v6ops-enterprise-incremental-ipv6
> draft-matthews-v6ops-design-guidelines
> 
> 
> I agree with your assessment about the first being much more useful.  I
> focused my feedback below on the first:
> 
> 
> IPv4-only Considerations
> * Section talks about rogue RA problem, but what about security risk of
> auto-tunneling?
> 
> Reasons for Phased Approach
> * Most large enterprises have extensive extranet environments for
> connectivity to partners.  Extranets should also be considered in this
> section. Parity in security capabilities is a major factor for IPv6
> deployment in Extranets.
> * "Internet facing servers cannot be managed over IPv6 unless the
> management systems are IPv6 capable". Enterprises can take an
> incremental
> approach here.  For some aspects of service assurance you do need an
> IPv6
> transport (availability and performance monitoring using synthetic
> transactions).  But for other aspects of network management, NMS just
> needs to deal with IPv6 as data in payload of network management
> traffic.
> *  Consider external providers for things like CDN, monitoring (e.g.
> gomez), goelocation services, cloud providers (SaaS/PaaS/Iaas), etc.
> 
> Preparation and Assessment Phase
> Inventory Phase
> * Need to consider security capabilities there
> * No talk about service providers (ISP, CDN, avail/perf monitoring,
> cloud
> providers (SaaS/PaaS/IaaS), ASP's, geolocation, etc)
> 
> Section 4.1 - Connectivity
> * Scenario where MPLS VPN provider doesn't provide IPv6 serviceŠtunnel
> yourself.  Guidance and best practices on tunnel solutions.
> 
> Section 5.1 - Network infrastructure
> * Sometimes access switches do QoS classification based on packet
> attributes; so, just because its a layer 2 switch doesn't mean its not
> doing L3 operations
> * FHRP - Global IP address as HSRP VIP
> 
> 
> DDoS mitigation
> 
> Remote access VPN's - IPv6 on inside header vs outside header
> 
> Prefix filtering by ISP's
> 
> Extranets are another potential use case where NAT66 is needed; many
> enterprises don't like carrying prefixes of all their partners on their
> internal routing tables
> 
> For ISP and WAN circuits, be prepared to swing circuits to different
> infra
> on the SP side to get dual stack support.
> 
> 
> 
> 
> 
> -jon