IPv6 Address and Migration Chal enges Peter.J.Wil is@bt.com
Contents – IPv6 Addresses sTLAs are too smal . NLAs are too smal . IPv6 Address Hierarchies, which one? Commercial restraints caused by the address al ocation rules. Alternative schemes. My crystal bal . © British Telecommunications plc 2001 2
Contents IPv6 Deployment Chal enges – Cost model ing of migration.- Suggested strategy for migration Where are the NGN applications? Home Networks – Home gateways- Addressing & naming in context- Its about communications not architectures. © British Telecommunications plc 2001 3
Why is address structure important? Address structure is more than the total number of bits. It is the address format & structure that defines the fundamental nature of a network. (Think of the close relationship between IPv4 address structures & the Internet.) The structure can define the way you build networks. If you get the structure wrong it costs you money to build a network to make that address structure work. (Think of the cost of memory for al those IPv4 routes.) © British Telecommunications plc 2001 4
IPv6 – Addressing Issues Internet Assigned Numbers Authority Registries eg. 2001::/23 Internet Service Providers (ISP’s)Exchanges / Carriers eg. 2001:618::/35 Sites / SME’s / Home Users (Site) eg. 2001:618:100B::/48 Mobile Phones / Home AppsPDA’s eg. 2001:618:100B:F8:/64 © British Telecommunications plc 2001 5
sTLAs Are Too Smal Currently IPv6 network service providers (NSP) are using sub-TLAs during the boot-strap phase of IPv6. The sTLA is a /35 The first 13 bits after the /35 is the NLA (Next- Level Aggregation) Identifier. This NLA space has to be used to address the customers & describe the NSP topology. If the customer is an ISP then they too have to use the NLA space. (Ripe-196) © British Telecommunications plc 2001 6
NLA Field Explained Sub-TLA holders have 13bits of Next Level Aggregation (NLA ID) Example 1 /35 /40 /48 NLA1 NLA2 NLA1, 5 bit = 32 ISPs & NLA2, 8 bits = 256 End sites Example 2 /35 /43 /48 NLA1 NLA2 NLA1, 8 bits = 256 ISPs & NLA2, 5 bits = 32 End sites © British Telecommunications plc 2001 7
Sub-TLA IDs – Use the reserved field NLA field can grow from 13 bits to 19 bits using the reserved bits /29 /35 /48 /64 subTLA R NLA SLA Interface E 2001:618::/35 S 13 16 64 bits 13 bits = 8,192 /48’s per subTLA /29 /48 /64 subTLA NLA SLA Interface2001:618::/29 19 16 64 bits 19 bits = 524,288 /48’s per subTLA © British Telecommunications plc 2001 8
Using the NLA Hierarchical y In NGNs with bil ions of attached devices the only way networks wil scale wil be with a deep hierarchy. To keep the routing table to a minimum size each layer of the hierarchy must do near perfect routing aggregation. Lets explore some network hierarchies and see how many bits are required: © British Telecommunications plc 2001 9
Network Addressing Scheme1 Hierarchical Size Number of bits Level Continent 7 3 Country 221 8 State/County 64 6 Town 128 7 Line/Site 1024 10 Total = 34 bits © British Telecommunications plc 2001 Remember current NLA size = 24 bits. +8 more reserved bits 10
Network Addressing Scheme2 Hierarchical Size Number of bits Level International backbone 10 PoPs 4 Continental backbone 20 PoPs 5 Country backbone 1000 PoPs 10 Lines to customers 1024 lines 10 Total = 29 bits Remember current NLA size = 24 bits. +8 more reserved bits © British Telecommunications plc 2001 11
Network Addressing Scheme3 and NLA Size Conclusion •Assume very efficient address al ocation without any network hierarchy (not a recommended design!)then how many lines to customers could we have with a 24 bit NLA? 2^24 = 16 Mil ion. •Using the Huitema-Durand method then 31 bits is required to address 30 Mil ion homes. (See notes)•Simply a NLA of 24 bits is not big enough for a global network operator nor big enough for a UK operator aiming to reach every home.•A 34 bit NLA should be sufficient. © British Telecommunications plc 2001 12
IPv6 Address Hierarchies, which one? • RFC 2450 “Proposed TLA and NLA Assignment Rules F TLA sub NLA SLA INTERFACE P ID TLA ID ID ID /3 /16 /29 /48 /64 • RIPE 196 “Provisional IPv6 Assignment and Al ocation Policy Document” F TLA sub R NLA SLA INTERFACE E P ID TLA S ID ID ID /3 /16 /29 /35 /48 /64 • RFC 2374 “An Aggregatable Global Unicast Address Format” F R TLA E NLA SLA INTERFACE P ID S ID ID ID /3 /16 /24 /48 /64 © British Telecommunications plc 2001 13
IPv6 Address Hierarchies,even more? • draft-ietf-ipngwg-addr-arch-v3-06.txt Now an RFC. global routingSubnet INTERFACE prefix ID ID n bits m bits 128-n-m bits See also http://www.apnic.net/meetings/12/sigs/joint_ipv6.html RIPE 40 1st October Prague http://www.ripe.net /ripe/meetings/current/ripe-40/index.html © British Telecommunications plc 2001 14
Commercial restraints caused by the address al ocation rules. The TLA/NLA/SLA structuring and address assignment rules drives a commercial model of customers dependent on Tier 2 ISPs dependent on Tier 1 ISPs. This is not the way it works with 3G! Slow start rules provide unfair competitive advantage to established & large networks. Address utilisation targets if set too high cause a flattening of network hierarchy which leads to higher engineering costs. © British Telecommunications plc 2001 15
Alternatives draft-hain-ipv6-pi-addr-00.txt “An IPv6 Provider-Independent Global Unicast Address Format”. The users IPv6 address is derived from their latitude and longitude. Increase the number of bits in the global routing prefix by reducing the number in the interface id. Then al ow any ISP unqualified address space. The ideal situation is that every ISP has enough address space to address everyone. © British Telecommunications plc 2001 16
My Crystal Bal In the short term looking to see some improvement in the IPv6 address structure and al ocation rules in the current RIRs considerations. In the long term I expect IPv6.1 which wil make much better use of the 128 bit address space. © British Telecommunications plc 2001 17
IPv6 Deployment Strategy:Cost Modelling of IPv6 Migration Understanding the business case for deploying IPv6 is the first key step. Understanding the costs of IPv6 is key and it is the costs that wil form a significant obstacle. Your IPv6 deployment strategy should seek to minimise costs and maximise commercial advantages. © British Telecommunications plc 2001 18
IPv6 Migration Costs Study The study looked at the whole costs of migrating to IPv6 for the fol owing scenarios: – A Big or Tier1 ISP – A Big enterprise- A SME- A Dial-ISP The study examined the costs of migrating now and migrating in 5 years time. Extra maintenance costs included. © British Telecommunications plc 2001 19
IPv6 Migration Costs Assumptions Attempted to include al costs, including new software, memory, hardware, OSS and desktop upgrades. Extra maintenance costs assume the extra costs of running IPv6 on an existing IPv4 network. That is assuming a dual-stack scenario. Once IPv4 is phased out then extra- maintenance costs no longer apply. Application migration costs not included but al owed for with BITS s/w for legacy IPv4 applications that could not be migrated. © British Telecommunications plc 2001 20
Big ISP Migration CostsBig ISP equivalent to a Tier 1 ISP £4K Cost/ customer Max cost £2K £1K Min cost Now +5 Years © British Telecommunications plc 2001 21
Big ISP Extra Maintenance CostsBig ISP equivalent to a Tier 1 ISP £200 Cost/ customer £100 £50 Max costMin cost Now +5 Years © British Telecommunications plc 2001 22
Big Enterprise Migration Costs 100,000 Desktops £1K Cost/ Employee £500 Max cost £250 Min cost Now +5 Years © British Telecommunications plc 2001 23
Big Enterprise Extra Maintenance Costs 100,000 Desktops £100 Cost/ Employee £50 £25 Max costMin cost Now +5 Years © British Telecommunications plc 2001 24
SME Migration Costs £1K Cost/ Employee £500 £250 Max cost Min cost Now +5 Years © British Telecommunications plc 2001 25
SME Extra Maintenance Costs £15 £10 Cost/ Employee £5 Now +5 Years © British Telecommunications plc 2001 26
Dial-ISP Migration Costs1 Mil ion lines £30 £20 Cost/ Line Max cost £10 Min cost Now +5 Years © British Telecommunications plc 2001 27
Dial-ISP Extra Maintenance Costs 1 Mil ion lines £7.5 £5 Cost/ Line £2.5 Now +5 Years © British Telecommunications plc 2001 28
Recommendations Do not upgrade to IPv6 now but plan to do it in about 5 years time. Ensure as kit & software is churned or upgraded for operational reasons that it is upgraded to be IPv6 capable. Start work on your IPv6 upgrade strategy now. Waiting for the kil er IPv6 application or until your competition has upgraded to IPv6 could be more expensive than a planned gradual upgrade in IPv6 capability. Once IPv6 is deployed shortening the life time of IPv4 wil reduce maintenance costs. © British Telecommunications plc 2001 29
Where are the NGN applications? NGN is not the same as IPv6. What is stopping NGN applications being deployed in IPv4? If you have an application but can’t deploy it because of a lack of IPv4 addresses or because IPv6 not widely deployed we need to know! © British Telecommunications plc 2001 30
Home Networks and IPv6 When thinking about naming & addressing we need to consider the context of the communications. The residential/home gateway may be a better place to manage communications in & out of the house. The Internet’s end-to-end architecture may no longer be appropriate. Architectures develop as technology changes. “Meta networks” with “intel igent” translation of messages at the edge of network domains may now be more appropriate. SIP & NAT are examples. This gives security & control (no more dDOS attacks). Given a “SIP” that works then global IP addresses are no longer needed – communications routed on names. (XML routing is another alternative tech.) © British Telecommunications plc 2001 31
Conclusion As an industry we need to make sure we don’t make the same “Class A,B,C” mistake we made with IPv4. That is not thinking about the future. If IPv6 happens the costs of migrating to it can be mitigated by an IPv6 upgrade strategy applied now. Don’t become religious about architectural principles that were created in a different technological era. © British Telecommunications plc 2001 32
Thank you. Peter.J.Wil is@bt.com