1 / 8

UDP Encapsulation of 6RD

UDP Encapsulation of 6RD. IETF 78 Maastricht 2010 July 30. Problem Statement. According to the ISP survey draft working in v6ops, the most common equipment unable to support IPv6 is CPE.

mieko
Download Presentation

UDP Encapsulation of 6RD

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. UDP Encapsulation of 6RD IETF 78 Maastricht 2010 July 30

  2. Problem Statement • According to the ISP survey draft working in v6ops, the most common equipment unable to support IPv6 is CPE. • If we can quickly enable the legacy CPEs to support v6 w/o modifying the CPE, this may be able to speed-up IPv6 adoption to end users. • The current Hub-and-Spoke Softwire framework uses PPPoverUDPoverL2TPv2 (PPPoUDPoL2TP). The encapsulation is fairly complex and stateful.

  3. Objectives • Allows 6RD through unmodified home gateway. • Stateless Tunnel Mechanism. • Simple and easy to implement on SP and CPE ends. • Speed up v6 deployment to users even if the home router can’t be upgraded for various reasons. • Transitional until upgrade of CPE (6rd or Native IPv6).

  4. Ideas • The 6RD-UDP host is provisioned with the 6RD-Prefix and 6RD-BR address. • The 6RD-UDP host constructs the 6RD address by this: • 6RD-Prefix + IPv4 + 16-bit “0” • Eg. 6RD-Prefix is “2001:db8/32”, IPv4 address is 192.0.1.100/24 and IPv4MaskLen is 16, the v6 prefix used by the host is 2001:db8:0164::/64 • When 6RD-BR receives the packet, it will fill the UDP port # learned from the UDP source. • Eg. When BR receives the packet 2001:db8:0164::/64 and the source UDP port is 12345, the v6 address is 2001:db8:0164:3039::/64.

  5. Pros • Stateless translation. The 6RD-BR and the 6RD-UDP host remain stateless. • The mechanism is very similar to 6RD. • The home gateway is unaware and unchanged. • Since only the BR fills up the UDP port information, the IPv6 prefix used by the host won’t change even if the binding is changed in the host gateway. • This is easy to implement and an open-source project is underway.

  6. Cons • Since the encapsulation requires to put the 16-bit port # in the prefix, if we want to maintain /64 for Auto-Config, this will burn /48 per CPE. • Extend the prefix to /96 (similar to Teredo). • Delegate the /96 to the server mode and run DHCPv6 server on the server to give a longer prefix to the hosts. • It creates a NAT-66 which disallows external initialized session. • This technology is meant to encourage v6 deployment andti transition to dual-stack eventually. It isn’t meant to stay in the network forever; authors believe it is worthwhile to deploy it as a transition step.

  7. Working Items • Since the CPE won’t relay the DHCP message to the 6RD-UDP host, we can’t use DHCP to pass the parameters to the host. We are considering two options: • Use Out-Of-Band mechanism (such as http) to pass the 6RD parameters. • Define a new In-Band mechanism to pass the 6RD parameters.

  8. Questions and Comments? • Forget the solution I just presented for the moment. Is there any interest working on a solution to solve the unmodified CPE problem? • Questions and Comments?

More Related