IPv6 Renumbering

Tim Chown Alan Ford Mark Thompson Stig Venaas

{tjc,ajf,mkt,sv}@ecs.soton.ac.uk

University of Southampton (UK)

IPv6 Renumbering

 A number of questions to ask:        Why is it an issue for IPv6?

What tools and ‘prior art’ exist?

How do current implementations perform?

What experiments can we run?

How do network management tools behave?

What recommendations can we make?

What future work could be done?

 Looking at these issues in a study funded jointly by 6NET (www.6net.org) and Cisco

The issue: IPv6 and renumbering

   A large IPv4 enterprise will likely have Provider Independent (PI) address space  No need to renumber if enterprise changes provider IPv6 only has Provider Assigned (PA) addresses    No Provider Independent (PI) address space Thus an IPv6 enterprise is tied to its ISP’s address space A proposal to ARIN suggesting that anyone qualifying for an ASN could get a PI prefix has not been adopted No IPv6 NAT  Using IPv4 and NAT a site can change providers and their external PA addresses while keeping the internal private addresses the same

What can we do about it?

    Don’t expect renumbering to ever become trivial or automatic no magic ‘renumber now’ button  But perhaps we can make it simpler Trying to find places where renumbering issues are likely to occur There might be ways to write applications and perform network and system administration tasks that allow a renumbering process to be easier Need to run experiments, analyse tools, and make recommendations for various audiences:  e.g. site admins, vendors, application writers

Existing Renumbering work

  1997 - IETF Procedures for Internet Enterprise Renumbering (PIER) WG  RFC1916: A Renumbering ‘Call to Arms’   RFC2071: Drivers for IPv4 Renumbering RFC2072: Router Renumbering Guide  Appears to have run until 1998/99 No active renumbering study within the IETF at the current time   Two relevant Internet Drafts in the IPv6 Operations WG (more on these later…) Appears timely to focus effort in this area now

IPv6 specific features

  IPv6 has some features that could help make renumbering easier:  Stateless autoconfiguration (RFC2462)     Running with two prefixes on a link and using Default Address Selection (RFC3484) DHCPv6 Prefix Delegation (RFC3633) IPv6 Router Renumbering (RFC2894) Mobile IPv6 (RFC3775) DHCPv6-PD and Router Renumbering lack widespread implementation  Router Renumbering implies authentication infrastructure

Renumbering procedures

   The IETF v6ops WG has defined a process for renumbering without a flag day:  Baker: draft-ietf-v6ops-renumbering-procedure-05 A network passes through distinct phases    Stable, existing prefix New prefix introduced Transient multihomed state (two prefixes in use)   Old prefix deprecated Stable, new prefix only Also have new IETF I-D on renumbering issues:  draft-chown-v6ops-renumber-thinkabout-02

SOHO experiments

 Simplest experiment   One LAN, no management tools, no enterprise scale services (DNS server, etc) Can test e.g. using 6to4 to tunnel broker renumbering  Results:  Generally works well  Default address selection performs generally as expected  Encouraging results towards enterprise case  Some issues remain to be tested, e.g. privacy addresses (RFC3041)

Enterprise experiments

    Tests ongoing Issues:  DNS servers are critical to the process    Network management tools can be problematic Some applications can be fiddly, e.g. Apache needs manual configuration of

VirtualHost

directives Applications with short lived sessions behave ‘better’ in contrast to long-lived sessions (e.g. ssh), as they open new sockets on the new addresses when available Hope to get DHCPv6-PD results soon  Router Renumbering tests require some PKI No firm result yet on IPv4 - IPv6 comparison

ISP/backbone experiments

   JOIN renumbered GWiN backbone   From 6bone (3ffe::/16) to production prefix (2001::/16) Followed the Baker procedure as far as it applied to a backbone network Issues:   Need stepwise changes to avoid route flaps: add new addresses, create new interfaces, then change routing Problems with RPF checks for multicast  Also embedded-RP implies RP address is hard-coded  Management/monitoring tools did not automatically pick up the changes being applied Conclusion: no harder or easier than in IPv4

Network management tools

 Need to manage and monitor the network  During renumbering procedure, links, routers and hosts may run with 2 active prefixes  Lack of widespread network management and monitoring tool implementations   Often rely on IPv4 transport to access IPv6 statistics Situation is improving fast  Issues:   May need to manually rediscover new node addresses Nodes with two prefixes may appear as separate nodes

Possible recommendations

 For various audiences     ISPs Sites, network administrators Vendors Application writers/developers  We present some of these recommendations in the next few slides

ISPs: Address assignment



Give customers a static IPv6 prefix

   Current recommendation is for a /48 per site Avoids forced renumbering of customer site Implies ISP may need more than a /32 itself 

Give customers a fixed size prefix

 If a site always has a /48 available, it does not need to renumber/restructure if a different provider only offers a smaller prefix  As described in RFC2072 from old PIER WG

Sites: consider use of ULAs

 IPv6 has Unique Local Addresses   See draft-ietf-ipv6-unique-local-addr-09.txt

Replace old ‘site local’ unicast prefixes  Can use ULAs and global addresses   Use ULAs for internal communication Prefer ULAs internally, prefer globals externally  Has issues    Need a two-faced DNS Possible address leakage (although not ambiguous) Possible application issues?

Apps/vendors: use of literals

 Hard-coded IP addresses add complexity  Use names rather than literals where possible  Unless performance is a critical issue  Avoid inappropriate caching of DNS results  Allow manual configuration of interface ID  In effect, manually configuration of last 64 bits in address rather than whole address  Consider use of symbolic prefix names to ease use of two prefixes simultaneously  e.g. in firewall implementations

Conclusions

      In principle, there will be more renumbering events required for IPv6 networks due to a lack of PI address space In theory there are tools that could make IPv6 network renumbering easier In practice the advantage is not yet realised  Tools like DHCP-PD and RR in their infancy SOHO renumbering tests went well Enterprise experiments ongoing A set of recommendations has been produced

We welcome feedback

    Existing work documented in 6NET deliverable   D3.6.1 (see www.6net.org, due online this week) Also D3.6.2 due by end of June Have any of you renumbered your network or had customers doing so?

   Many IPv6 networks must have already have renumbered from 6bone to production (or 6to4 to native) prefixes What did you learn?

This is probably easier for provider networks than end sites We would like some feedback What are your thoughts? Please contact us….

Contact:

Tim Chown

[email protected]

Stig Venaas

[email protected]

Mark Thompson

[email protected]

Alan Ford

[email protected]

School of Electronics and Computer Science, University of Southampton, Highfield, Southampton SO17 1BJ United Kingdom