130 likes | 242 Vues
This document explores the nuances of 6RD (Rapid Deployment), a stateless, service provider-managed tunneling protocol facilitating IPv6 allocation from IPv4 addresses. It examines the mechanics of IPv6-transition mechanisms, highlighting aspects such as whether to tunnel or translate, stateful versus stateless configurations, and the complexities of dual-stack implementations. The analysis includes practical deployment considerations, typical configurations for consumer equipment, and various scenarios for optimizing IPv6 address allocation. Insights into operational challenges and possible solutions for ISPs are also discussed.
E N D
Issue Definition*:6RD and IPv6 allocation policy Jan Žorž (Go6 Institute Slo) Mark Townsley (Cisco) *Or, Why we had to wake up on Friday to be here?
Aspects of IPv6 Transition Mechanisms Tunnel or Translate Stateless or Stateful SP-Managed or not SP-Managed 6rd is a Stateless, SP-Managed, Tunneling Protocol
IPv6 Prefix from an IPv4 Address • The following construction is what allows 6rd to beSP-managed and Stateless ISP 6rd IPv6 Prefix Subscriber IPv4 address Subnet-ID 198.51.100.1 2001:db8 64 /n /m 0 Interface ID Subscriber Delegated IPv6 Prefix
6rd – Encapsulation and Packet Flow “…externally 6rd looks, feels and smells like native IPv6 ” – RIPE Labs 6rd 6rd Dual Stack IPv4 Dual Stack Dual Stack Dual Stack 6rd Border Relays CE IPv4-only Access Network • IPv6 in IPv4 (protocol 41) encapsulation • Within a domain, IPv6 traffic follows IPv4 routing • CEs reach BRs via IPv4 anycast
6rd – CE Provisioning 6rd 6rd Dual Stack IPv4 Dual Stack Dual Stack Dual Stack 6rd Border Relays CE • Each 6rd CE within a 6rd Domain requires a single DHCP option* carrying 4 values 6rdPrefix 6rdPrefixLen IPv4MaskLen 6rdBRIPv4Address • These 4 values are the same for all CEs within the domain *May also be configured with TR-69 or otherwise
6rd – Deployments 6rd 6rd Dual Stack IPv4 Dual Stack Dual Stack Dual Stack 6rd Border Relays CE • Defined in RFC 5969 • Commercially available products from a number of vendors • First deployment in 2007, multiple deployments today
Q: What should /n and /m be? ISP 6rd Prefix IPv4 (0-32 bits) Subnet-ID 198.51.100.1 2001:db8 Interface ID 64 /m /n 0
Starting simple: /n = 28, /m = 60 ISP 6rdIPv6 Prefix 32 bits Interface ID Subnet-ID 198.51.100.1 2001:db8 64 /60 /28 0 • One 6rd domain • 6rd provisioning is identical for all CEs • Convenient conversion between subscriber IPv6 and IPv4 address • Allows 16 IPv6 subnets in the home • ISP needs a /27 or shorter
But what if you cannot get a /27?/n = 32, /m = 64 ISP 6rdIPv6 Prefix 32 bits Interface ID 2001:db8 198.51.100.1 /32 /64 0 • Still a single domain, but/64 does not allow multiple subnets for the subscriber • No subnets, no routing • Common features such as Guest + Home SSIDs become very difficult • Support for 802.15.4 for Sensors, Zigbee, etc. • Ultimately leads to IPv6 NAT
Using less than 32 bits of IPv4 • If the IPv4 space is an aggregate, 6rd need not carry the common bits • For example, in a CGN world of 10/8, we just don’t carry around the 10 24 bits Subnet-ID .51.100.1 .51.100.1 2001:db8 2001:db80:0 64 64 /60 /56 /36 /32 0 0 Interface ID Interface ID
Multiple 6rd Domains ISP 6rdIPv6 Prefix Distinct IPv4 Aggregates 32 bits 4 bits 8 bits Interface ID (64 bits) 20 bits IPv4 /12 8 bits Interface ID (64 bits) 16 bits 32 bits 8 bits IPv4 /16 8 bits Interface ID (64 bits) 18 bits 32 bits 4 bits IPv4 /14 8 bits Interface ID (64 bits) 19 bits 32 bits 3 bits IPv4 /11 • More efficient in terms of IPv6 space usage • However, CEsin different domains require different configuration • Operations begin to get more complicated, traffic patterns not as efficient, etc.
How do I get my /27? • /27 yields /60 for the home • /29 yields /62 for the home
Possible solutions • Declare this is a non-problem • Special 6rd policy. e.g., /27 granted based on ability and intention to deploy more rapidly with 6rd • Allow /29 to anyone • Others?