Introduction to IPv6
Upcoming SlideShare
Loading in...5
×
 

Introduction to IPv6

on

  • 4,185 views

 

Statistics

Views

Total Views
4,185
Views on SlideShare
4,170
Embed Views
15

Actions

Likes
0
Downloads
160
Comments
0

3 Embeds 15

http://www.linkedin.com 11
http://www.slideshare.net 3
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Established in 1988, Huawei Technologies is an innovative and customer-oriented global ICT (Information and Communication Technology) company that provides high quality products, solutions, and services. (Huawei is fully owned by its staff. In other words, employees are the owners of this company. That’s why employees work so hard and get so committed to their work.) By September 2005, Huawei has over 35,000 employees, 90% of them with a bachelor's degree or higher and over 48% people (about 16,800) devoted to R&D. Each year, Huawei invests no less than 10% of its revenue on R&D. This ensures that Huawei is a leading player in technology and to meet our customers’ demands very quickly. Huawei’s full product portfolio covers wireless network products (UMTS/HSDPA, CDMA2000, GSM/GPRS/EDGE and WiMAX), network products (NGN, xDSL, optical transmission, data communications), application and software products (IN, mobile data, OSS/BSS, CDN/SAN), and terminals. We are becoming a leading global supplier with products deployed in more than 90 countries, including the US, the UK, France, Portugal, Russia, Brazil, Singapore and Thailand, and serving 22 of the world’s top 50 operators Our last year’s contract sales reached 5.58 billion USD. In the first half of 2005, our contract sales reached over US$4.1 billion, an increase of 85% over last year, over 62% of which (US$2.47 billion) is from international markets.
  • This slide shows Huawei’s HR (Human Resources) layout. Among our 35,000 staff members, 90% of employees hold bachelor's degree or higher. In R&D, we have a pre-research department to keep abreast with the latest technologies. Each year, 10% of our total R&D investment is put into pre-research. As for marketing, sales and customer service, we invest 38% of our staff in this area, as we understand that customer satisfaction is, and should be, the only benchmark to evaluate our work performance.
  • In order to support our global operations, we have established our global sales and after-sales centers in the global market, including eight regional headquarters and over 70 branch offices outside China: they are located in North America, South America, CIS (the Commonwealth of Independent States), Western Europe, Eastern Europe, North Africa & Middle East, Southern Africa and Asia Pacific. To ensure customer-satisfied maintenance services, we have built a 3-Level Technical Support Service System, ranging from the Headquarters, Regional Headquarters and each single country or region. According to the Gallup survey, Huawei has been holding the No.1 position in terms of service quality and customer satisfaction for many years in the Chinese market. In the international market, we put high priority on improving our customer service. We have invested a lot in after-sales service to ensure high-level service in order to build a long-term partnership with our customers. According to the most recent survey done by Heavy Reading, a London-based research organization under the LightReading group, Huawei has won 16.7% customer recognition in customer service and support in early 2005 compared with the less than 1% in their last survey in autumn of 2003, ranking No.4 among all the worldwide vendors.
  • Huawei has established a complete set of documented processes for all business procedures . Huawei QMS is seamless ly integrated with main business pro cedures such as Integrated Product Development, IPD, Integrated Supply Chain, ISC, Customer Service, and so on. Customer requirements from CRM (Customer Relationship Management) process is collected by OR process and is analyzed by MM process. MM drive s the IPD process to develop new product. Customer contracts from CRM process is inputted in to the ISC (Integrated Supply Chain) process which man ages sourcing, manufactur ing and logistic s. The CS (Customer Service) process manage s installation, commissioning, spare part s and customer training.
  • Huawei’s major development strategy includes four points. 1. Serving our customers is the only reason why Huawei exists; Customer demand is the fundamental driving force of our development. 2. High quality, excellent service, low operating costs, and giving top priority to meeting customer requirements to enhance their competitiveness and profitability. 3. Continuously performing management transformation to realize efficient process-based organization operation for ensuring quality end-to-end delivery. 4. Developing with our peers in the industry as both competitors and partners to jointly create a favorable environment and share the benefits of the value chain.
  • These slides were prepared in January, 2001.
  • Overview of Internet Protocol version 6 Current status of IPv6 specifications, implementations, and transition tools Not Cisco specific! Background Header formats Packet size issues Addressing & routing Security Quality of service Mobility ICMPv6 & neighbor discovery Effects on higher layers IPv4-IPv6 coexistence & transition Current status
  • IPv4 and ST were both specified in the late 1970’s. ST was a complementary protocol to IP, providing a connection-oriented internetwork service that was used to support early experiments in Internet audio/video teleconferencing. SIP[P], CATNIP, Pip, and TUBA were the four candidates considered in the early 1990’s by the IETF for the new IP. SIPP was the “winner”, after it was changed from having 64-bit addresses to 128-bit addresses. SIP = Simple Internet Protocol SIPP = Simple Internet Protocol Plus CATNIP = Common Address Technology for Next-Generation IP Pip = Paul’s IP? TUBA = TCP and UDP with Bigger Addresses (aka CLNP, the OSI Connectionless Network Layer Protocol)
  • The IETF first recognized the problem of eventual IPv4 address exhaustion around 1990, and predicted we had about ten years to go, based on extrapolation of growth to that point (before the Web!). Indeed, it is only in the past year that the “IP address crunch” has become widely acknowledged. Note: We don’t expect there to be a day when the last IPv4 address is handed out; rather, they will just continue to become harder and harder to obtain, i.e., effectively running out, if not technically.
  • “ IPng” stands for IP Next Generation, and was the working name for the new IP in the early phase of its development.
  • IPsec = the IP-layer security protocols, ESP (Encapsulating Security Payload) and AH (Authentication Header), which are defined for both IPv4 and IPv6. These protocols allow receivers to detect and discard packets that have been modified in transit, e.g., by bad guys or by transmission errors. Unfortunately, NATs work by modifying packets in transit…
  • Note that Quality of Service is not one of the benefits of IPv6 over IPv4, despite what you may have heard. Both versions of IP have exactly the same QoS features defined. The only difference is the presence of the Flow Label field in IPv6, which allows more efficient packet classification by routers, but this is really a minor implementation optimization, rather than a significant new QoS feature.
  • Overview of Internet Protocol version 6 Current status of IPv6 specifications, implementations, and transition tools Not Cisco specific! Background Header formats Packet size issues Addressing & routing Security Quality of service Mobility ICMPv6 & neighbor discovery Effects on higher layers IPv4-IPv6 coexistence & transition Current status
  • This is the general form of Global Unicast Addresses; some more specific forms are shown on the next two slides. TLAs are intended to be assigned to large, “tier-1” IP Service Providers (and perhaps, some day, to multi-ISP exchanges, such an an exchange serving a geographical region) One or more NLA fields are be used by TLAs to number their attached down-stream providers and/or end-subscriber sites. The SLA* field is used by end-subscriber sites to number their internal subnets. Very large sites might create a hierarchy of subnets within the SLA* field. The Interface ID field is used to number individual nodes (interfaces, actually) attached to a specific subnet. IPv6’s address auto-configuration technique depends on having the Interface ID field be 64-bits wide. The currently-proposed address allocation policy assigns a 16-bit SLA* field to every subscriber site (or, in other words, each subscriber is assigned a /48 prefix), but this policy is subject to change some day, so you should not assume a fixed boundary between the NLA* and SLA* fields.
  • Current LANs like Ethernet use 48-bit MAC addresses defined by the IEEE 802 standards. The IEEE has introduced a new, 64-bit address space called EUI-64, for new kinds of LANs. There is a standard mapping from a 48-bit MAC into a 64-bit EUI-64.
  • Overview of Internet Protocol version 6 Current status of IPv6 specifications, implementations, and transition tools Not Cisco specific! Background Header formats Packet size issues Addressing & routing Security Quality of service Mobility ICMPv6 & neighbor discovery Effects on higher layers IPv4-IPv6 coexistence & transition Current status
  • Same two basic approaches are defined for both IPv4 and IPv6.
  • Most of the RIP issues should be fixed in 12.2(2)T.
  • Since BGP now supports multiple address families, we felt that it would make more sense to move the BGP commands up to the top level. I.e show ip bgp is now show bgp ipv4. The old CLI will still be supported. Currently only the IPv6 address family has moved to the new CLI.
  • Overview of Internet Protocol version 6 Current status of IPv6 specifications, implementations, and transition tools Not Cisco specific! Background Header formats Packet size issues Addressing & routing Security Quality of service Mobility ICMPv6 & neighbor discovery Effects on higher layers IPv4-IPv6 coexistence & transition Current status
  • Toolbox of mechanisms which can be combined.
  • draft-ietf-ngtrans-6to4-07.txt Uses addresses out of the 6to4 address block, 2002::/16. A site’s prefix /48 is created by appending one of it’s global IPv4 addresses to this prefix. I.e 2002:10.67.0.1::/48.
  • RFC2893 (obsoletes RFC1933) Just like point to point links. IPv6 packets are encapsulated in IPv4, protocol type 41.
  • RFC2893 (RFC1933)
  • Fragmentation: An IPv6 tunnel endpoint should only fragment when the IPv4 MTU is less than 1300 bytes. As long as the IPv4 MTU is larger, Path MTU discovery should take care to tell the IPv6 end-node about the MTU. The current implementation sets IPv6 MTU to IPv4 MTU - 20. If the path has a smaller MTU, IPv4 will have to fragment.
  • There is nothing wrong with having the same interface ID on multiple interfaces on the same router. That is for example the typical case for IPv6 over IPv4 tunnels. Note that we will possibly change the way we generate the interface ID on point to point links, to just be the first MAC address in the box, in EUI-64 format.
  • Overview of Internet Protocol version 6 Current status of IPv6 specifications, implementations, and transition tools Not Cisco specific! Background Header formats Packet size issues Addressing & routing Security Quality of service Mobility ICMPv6 & neighbor discovery Effects on higher layers IPv4-IPv6 coexistence & transition Current status
  • Add text
  • Add text
  • Add text

Introduction to IPv6 Introduction to IPv6 Presentation Transcript

  • A senthilkumars @huawei.com A journey of 1000 miles starts with a single step!! Introduction To IPng
  • Let us know about Huawei
  • Huawei Technologies
    • An innovative and customer-oriented ICT company established in 1988 and fully owned by its staff.
    • Over 64,000 staff members (over 48% engaged in R&D); more than 10% annual revenue invested in R&D.
    • Full product portfolio including wireless products, network products, application and software products and terminals.
    • A leading global supplier with products deployed in over 100 countries, including the US, the UK, France, Portugal, Russia, Brazil, Singapore and Thailand, and serving 28 of the world’s top 50 operators.
    • Contract sales amounted to US$8.2 billion in 2005. over 58% of which (US$4.8 billion) was from international markets.
  • Continuous Growth
    • Serving 28 of the world’s top 50 operators
    • Strategic partner with BT, Vodafone, Telefonica, etc.
    Contract Sales ( USD1 billion ) 0 1 2 3 4 5 6 2002 2003 2004 2005 2.67 3.83 5.58 8.2 7 8 9
    • Total staff: Over 64,000 employees
    Human Resources Supply Chain: 8% Administration: 6% R&D:48% Marketing, Sales and Customer Service : 38% 48% 38% 6% 8%
  • Global Presence
    • 8 regional headquarters, 85 branch offices outside China
    • 3-level customer service system (HQ, regional, local)
    Thailand Saudi Arabia India Nepal Pakistan Russia Kazakhstan Kyrgyzstan South Korea Malaysia Vietnam Philippines Ukraine Egypt Germany Singapore Indonesia Australia Kenya South Africa Zimbabwe Algeria Morocco UK Argentina Chile Peru Colombia Mexico USA Nigeria Huawei Technologies (Headquarters) Tunisia France Canada Bangladesh UAE Portugal Italy Brazil Netherlands Poland Sweden Shenzhen Spain Bulgaria Uzbekistan Ecuador Venezuela Turkey Turkmenistan Greece Romania Sri Lanka Cambodia
  • Global R&D
    • Global R&D
      • Stockholm, Sweden - Base Station architecture and system design, Radio technology and RAN algorithms
      • Dallas, USA - ASIC technology and CDMA algorithms
      • Bangalore, India - Software technology/platform
      • Moscow, Russia - Algorithms and RF
      • Shenzhen, China - CN, service platforms
      • Shanghai, China - RAN, terminals, ASIC chipsets
      • Beijing, China - Packet CN, GW, Terminals
      • Nanjing, China - BOSS, 3G services
    • CMM5 and IPD (Integrated Product Development) have been widely implemented into product development.
    • Four R&D divisions (Central software division and institutes in Bangalore, Shanghai and Nanjing) have been awarded CMM level 5 certification.
    Adopts asynchronous development, unifies product commercialization and speeds up response to market.
  • R&D Based on a Shared Platform Constructing a “speed, quality and cost” advantage, through modular structure, standardization and sharing technology (CBB methodology). Uniform operation and maintenance platform IP+Optical platform Common software and hardware platform Fixed access platform Wireless access platform Service control platform Intelligent network platform Terminal service platform Uniform engineering and material development platform
  • Persistent investment in standards and patents to be at the forefront of future technology. Standards and Patents
    • Standards
      • Participated in 70 international standardization organizations including ITU, 3GPP.
    • Patents
    Domestic Patents       9600 pcs Authorized Patents      1844 pcs PCT International and Overseas Patents 1574 pcs
      • 5% of international UMTS essential patents (69 patents), No.5 of global telecom companies
      •    ( Till 31 Dec. 2005 )
  • Huawei E2E Delivery Process Overview Ad/trade show m g t - Info mgt Relationship mgt - Relationship mgt - Buz partner mgt Sales execution Solution design
    • - Resource allocation
    • Customer sat mgt
    • Market req
    • - Market forecast
    • - Offering info
    Sales mgt
    • - win
    • leadership team
    • drive sales exection
    Opportunity point mgt Cus T Ome r Cus T Ome r Req mgt pro logistics mfg Supply chain plan CRM Partner and supplier mgmt FIN / HR / IT MM IPD ISC OR Research, standard, patent Technology roadmaps Brand mgt CS issues Contract signature Concept Plan Develop Qualify Launch Life Cycle req NPI Engineering implement TS Spare parts mgt training Narrow e2e delivery Broad e2e delivery Within C2C framework, e2e delivery focuses on customer commitment to committed delivery Understand Market Perform Segmentation Portfolio Analysis Dev Bus Plans Align & Optimize Manage & Assess Perf
  • Industry Position
    • 3G
      • World-leading wireless network supplier, 18 commercial UMTS networks
    • NGN
      • No.1 in global VoIP market (Dittberner)
    • Intelligent Network
      • No. 1 in global market (21.6% of users) ( Ovum )
    • Optical Network
      • No.1 in global LH+MR DWDM market (Ovum-RHK)
    • Access Network
      • No.1 in global IP DSLAM market (Infonetics)
      • No.1 in global MSAN market in 1H05 (Infonetics)
    • Data Communication
      • No.3 in worldwide service provider routers (Gartner)
  • VISION To enrich life through communication MISSION To focus on our customers’ challenges and needs by providing excellent communications network solutions and services in order to consistently create maximum value for customers. Vision and Mission www.huawei.com
  • Development Strategy
    • Serving our customers is the only reason Huawei exists; Customer demand is the fundamental driving force of our development.
    • High quality, excellent service, low operating costs, and giving top priority to meeting customer requirements to enhance their competitiveness and profitability.
    • Continuously performing management transformation to realize efficient process-based organization operation for ensuring high quality end-to-end delivery.
    • Developing with our peers in the industry as both competitors and partners to jointly create a favorable environment and share the benefits of the value chain.
  • Fulfilling our social responsibility as a responsible corporate citizen Social Responsibility
    • A dedicated member of the United Nations Global Compact
    • December 2004 Tsunami: Donated 2.42 million USD worth of telecom equipment and an additional 2.42 million USD in cash from the company and its employees
    • August 1998 Flood (China): Donated US$3.7 million worth of equipment, and US$1.85 million in cash schools.
    • Education Fund: Donated US$3.09 million to set up a fund to help needy students complete an undergraduate education.
  • Enriching Life Through Communication Huawei Technologies Co., Ltd. Add: Huawei Base, Bantian, Longgang District, Shenzhen Tel: +86-755-28780808 Zip Code: 518129 http://www.huawei.com
  • Some questions…
    • What is the current version of IP?
    • What is the size of IPv4 address?
    • What is the size of IPv4 header?
    • What is a router?
    • What is version of current IPng?
    • Embrace Multi-Play Age
    • Multi-Play Evolution Solution
    Content
  • Introduction to IPv6
  • Outline
    • Protocol Background
    • Technology Highlights
    • Enhanced Capabilities
    • Transition Issues
    • Next Steps
  • Background
  • Why a New IP?
    • 1991 – ALE WG studied projections about address consumption rate showed exhaustion by 2008.
    • Bake-off in mid-1994 selected approach of a new protocol over multiple layers of encapsulation.
  • What Ever Happened to IPv5?
    • 0 IP March 1977 version (deprecated)
    • 1 IP January 1978 version (deprecated)
    • 2 IP February 1978 version A (deprecated)
    • 3 IP February 1978 version B (deprecated)
    • 4 IPv4 September 1981 version (current widespread)
    • 5 ST Stream Transport (not a new IP, little use)
    • 6 IPv6 December 1998 version (formerly SIP, SIPP)
    • 7 CATNIP IPng evaluation (formerly TP/IX; deprecated)
    • 8 Pip IPng evaluation (deprecated)
    • 9 TUBA IPng evaluation (deprecated)
    • 10-15 unassigned
  • What about technologies & efforts to slow the consumption rate?
    • Dial-access / PPP / DHCP
      • Provides temporary allocation aligned with actual endpoint use.
    • Strict allocation policies
      • Reduced allocation rates by policy of ‘current-need’ vs. previous policy based on ‘projected-maximum-size’.
    • CIDR
      • Aligns routing table size with needs-based address allocation policy. Additional enforced aggregation actually lowered routing table growth rate to linear for a few years.
    • NAT
      • Hides many nodes behind limited set of public addresses.
  • What did intense conservation efforts of the last 5 years buy us?
    • Actual allocation history
      • 1981 – IPv4 protocol published
      • 1985 ~ 1/16 total space
      • 1990 ~ 1/8 total space
      • 1995 ~ 1/4 total space
      • 2000 ~ 1/2 total space
    • The lifetime-extending efforts & technologies delivered the ability to absorb the dramatic growth in consumer demand during the late 90’s.
    • In short they bought – TIME –
  • Would increased use of NATs be adequate?
        • NO!
    • NAT enforces a ‘client-server’ application model where the server has topological constraints.
      • They won’t work for peer-to-peer or devices that are “called” by others (e.g., IP phones)
      • They inhibit deployment of new applications and services, because all NATs in the path have to be upgraded BEFORE the application can be deployed.
    • NAT compromises the performance, robustness, and security of the Internet.
    • NAT increases complexity and reduces manageability of the local network.
    • Public address consumption is still rising even with current NAT deployments.
  • What were the goals of a new IP design?
    • Expectation of a resurgence of “always-on” technologies
      • xDSL, cable, Ethernet-to-the-home, Cell-phones, etc.
    • Expectation of new users with multiple devices.
      • China, India, etc. as new growth
      • Consumer appliances as network devices
          • (10 15 endpoints)
    • Expectation of millions of new networks.
      • Expanded competition and structured delegation.
          • (10 12 sites)
  • Return to an End-to-End Architecture New Technologies/Applications for Home Users ‘ Always-on’—Cable, DSL, Ethernet@home, Wireless,… Global Addressing Realm Always-on Devices Need an Address When You Call Them
  • Why is a larger address space needed?
    • Overall Internet is still growing its user base
      • ~320 million users in 2000 : ~550 million users by 2005
    • Users expanding their connected device count
      • 405 million mobile phones in 2000, over 1 billion by 2005
      • UMTS Release 5 is Internet Mobility, ~ 300M new Internet connected
      • ~1 Billion cars in 2010
      • 15% likely to use GPS and locality based Yellow Page services
      • Billions of new Internet appliances for Home users
      • Always-On ; Consumer simplicity required
    • Emerging population/geopolitical & economic drivers
      • MIT, Xerox, & Apple each have more address space than all of China
      • Moving to an e-Economy requires Global Internet accessibility
  • Why Was 128 Bits Chosen as the IPv6 Address Size?
    • Proposals for fixed-length, 64-bit addresses
      • Accommodates 10 12 sites, 10 15 nodes, at .0001 allocation efficiency (3 orders of mag. more than IPng requirement)
      • Minimizes growth of per-packet header overhead
      • Efficient for software processing on current CPU hardware
    • Proposals for variable-length, up to 160 bits
      • Compatible with deployed OSI NSAP addressing plans
      • Accommodates auto-configuration using IEEE 802 addresses
      • Sufficient structure for projected number of service providers
    • Settled on fixed-length, 128-bit addresses
      • (340,282,366,920,938,463,463,374,607,431,768,211,456 in all!)
  • Benefits of 128 bit Addresses
    • Room for many levels of structured hierarchy and routing aggregation
    • Easy address auto-configuration
    • Easier address management and delegation than IPv4
    • Ability to deploy end-to-end IPsec (NATs removed as unnecessary)
  • Incidental Benefits of New Deployment
    • Chance to eliminate some complexity in IP header
      • improve per-hop processing
    • Chance to upgrade functionality
      • multicast, QoS, mobility
    • Chance to include new features
      • binding updates
  • Summary of Main IPv6 Benefits
    • Expanded addressing capabilities
    • Structured hierarchy to manage routing table growth
    • Serverless autoconfiguration and reconfiguration
    • Streamlined header format and flow identification
    • Improved support for options / extensions
  • IPv6 Advanced Features
    • Source address selection
    • Mobility - More efficient and robust mechanisms
    • Security - Built-in, strong IP-layer encryption and authentication
    • Quality of Service
    • Privacy Extensions for Stateless Address Autoconfiguration ( RFC 3041)
  • IPv6 Markets
    • Home Networking
      • Set-top box/Cable/xDSL/Ether@Home
      • Residential Voice over IP gateway
    • Gaming (10B$ market)
      • Sony, Sega, Nintendo, Microsoft
    • Mobile devices
    • Consumer PC
    • Consumer Devices
      • Sony (Mar/01 - … energetically introducing IPv6 technology into hardware products …)
    • Enterprise PC
    • Service Providers
      • Regional ISP, Carriers, Mobile ISP, and Greenfield ISP’s
  • IPv6 Markets
    • Academic NRN:
      • Internet-II (Abilene, vBNS+), Canarie*3, Renater-II, Surfnet, DFN, CERNET,… 6REN/6TAP
    • Geographies & Politics:
      • Prime Minister of Japan called for IPv6 (taxes reduction)
      • EEC summit PR advertised IPv6 as the way to go for Europe
      • China Vice minister of MII deploying IPv6 with the intent to take a leadership position and create a market force
    • Wireless (PDA, Mobile, Car,...):
      • Multiple phases before deployment
      • RFP -> Integration -> trial -> commercial
      • Requires ‘client devices’, eg. IPv6 handset ?
  • Outline
    • Protocol Background
    • Technology Highlights
    • Enhanced Capabilities
    • Transition Issues
    • Next Steps
  • A new Header
  • The IPv6 Header 40 Octets, 8 fields 0 31 Version Class Flow Label Payload Length Next Header Hop Limit 128 bit Source Address 128 bit Destination Address 4 12 24 16
  • The IPv4 Header 20 octets + options : 13 fields, including 3 flag bits 0 31 Ver IHL Total Length Identifier Flags Fragment Offset 32 bit Source Address 32 bit Destination Address 4 8 24 16 Service Type Options and Padding Time to Live Header Checksum Protocol shaded fields are absent from IPv6 header
  • Summary of Header Changes between IPv4 & IPv6
    • Streamlined
      • Fragmentation fields moved out of base header
      • IP options moved out of base header
      • Header Checksum eliminated
      • Header Length field eliminated
      • Length field excludes IPv6 header
      • Alignment changed from 32 to 64 bits
    • Revised
      • Time to Live ’ Hop Limit
      • Protocol ’ Next Header
      • Precedence & TOS ’ Traffic Class
      • Addresses increased 32 bits ’ 128 bits
    • Extended
      • Flow Label field added
  • Extension Headers next header = TCP TCP header + data IPv6 header next header = Routing TCP header + data Routing header next header = TCP IPv6 header next header = Routing fragment of TCP header + data Routing header next header = Fragment Fragment header next header = TCP IPv6 header
  • Extension Headers (cont.)
    • Generally processed only by node identified in IPv6 Destination Address field => much lower overhead than IPv4 options processing
      • exception: Hop-by-Hop Options header
    • Eliminated IPv4’s 40-byte limit on options
      • in IPv6, limit is total packet size, or Path MTU in some cases
    • Currently defined extension headers:
      • Hop-by-Hop Options, Routing, Fragment, Authentication, Encryption, Destination Options
  • Fragment Header
    • though discouraged, can use IPv6 Fragment header to support upper layers that do not (yet) do path MTU discovery
    • IPv6 frag. & reasm. is an end-to-end function; routers do not fragment packets en-route if too big—they send ICMP “packet too big” instead
    Next Header Original Packet Identifier Reserved Fragment Offset 0 0 M
  • Routing Header
  • Routing
    • Same “longest-prefix match” routing as IPv4 CIDR
    • Straightforward changes to existing IPv4 routing protocols to handle bigger addresses
      • unicast: OSPF, RIP-II, IS-IS, BGP4+, …
      • multicast: MOSPF, PIM, …
    • Use of Routing header with anycast addresses allows routing packets through particular regions
      • e.g., for provider selection, policy, performance, etc.
  • Routing Header
  • Example of Using the Routing Header S A B D
  • Addressing
  • Some Terminology
    • node a protocol module that implements IPv6
    • router a node that forwards IPv6 packets not explicitly addressed to itself
    • host any node that is not a router
    • link a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6
    • neighbors nodes attached to the same link
    • interface a node’s attachment to a link
    • address an IPv6-layer identifier for an interface or a set of interfaces
  • Text Representation of Addresses
    • “ Preferred” form: 1080:0:FF:0:8:800:200C:417A
    • Compressed form: FF01:0:0:0:0:0:0:43
    • becomes FF01::43
    • IPv4-compatible: 0:0:0:0:0:0:13.1.68.3
    • or ::13.1.68.3
  • IPv6 - Addressing Model
    • Addresses are assigned to interfaces
      • No change from IPv4 Model
    • Interface ‘expected’ to have multiple addresses
    • Addresses have scope
      • Link Local
      • Site Local
      • Global
    • Addresses have lifetime
      • Valid and Preferred lifetime
    Link-Local Site-Local Global
  • Types of IPv6 Addresses
    • Unicast
      • Address of a single interface
      • Delivery to single interface
    • Multicast
      • Address of a set of interfaces
      • Delivery to all interfaces in the set
    • Anycast
      • Address of a set of interfaces
      • Delivery to a single interface in the set
    • No more broadcast addresses
  • Interface Address set
    • Loopback
      • (only assigned to a single virtual interface per node)
    • Link local
    • Site local
    • Auto-configured 6to4
      • (if IPv4 public is address available)
    • Auto-configured IPv4 compatible
      • (operationally discouraged)
    • Solicited node Multicast
    • All node multicast
    • Global anonymous
    • Global published
  • Source Address Selection Rules
    • Rule 1: Prefer same address
    • Rule 2: Prefer appropriate scope
      • Smallest matching scope
    • Rule 3: Avoid deprecated addresses
    • Rule 4: Prefer home addresses
    • Rule 5: Prefer outgoing interface
    • Rule 6: Prefer matching label from policy table
      • Native IPv6 source > native IPv6 destination
      • 6to4 source > 6to4 destination
      • IPv4-compatible source > IPv4-compatible destination
      • IPv4-mapped source> IPv4-mapped destination
    • Rule 7: Prefer temporary addresses
    • Rule 8: Use longest matching prefix
      • Local policy may override
  • Destination Address Selection Rules
    • Rule 1: Avoid unusable destinations
    • Rule 2: Prefer matching scope
    • Rule 3: Avoid dst with matching deprecated src address
    • Rule 4: Prefer home addresses
    • Rule 5: Prefer matching label from policy table
      • Native IPv6 source > native IPv6 destination
      • 6to4 source > 6to4 destination
      • IPv4-compatible source > IPv4-compatible destination
      • IPv4-mapped source> IPv4-mapped destination
    • Rule 6: Prefer higher precedence
    • Rule 7: Prefer smaller scope
    • Rule 8: Use longest matching prefix
    • Rule 9: Order returned by DNS
      • Local policy may override
  • Address Type Prefixes
    • Address type Binary prefix
    • IPv4-compatible 0000...0 (96 zero bits)
    • global unicast 001
    • link-local unicast 1111 1110 10
    • site-local unicast 1111 1110 11
    • multicast 1111 1111
    • all other prefixes reserved (approx. 7/8ths of total)
    • anycast addresses allocated from unicast prefixes
  • Global Unicast Addresses
    • TLA = Top-Level Aggregator NLA* = Next-Level Aggregator(s) SLA* = Site-Level Aggregator(s)
    • all subfields variable-length, non-self-encoding (like CIDR)
    • TLAs may be assigned to providers or exchanges
    site topology (16 bits) interface identifier (64 bits) public topology (45 bits) interface ID SLA* NLA* TLA 001
    • Link-local addresses for use during auto-configuration and when no routers are present:
    • Site-local addresses for independence from changes of TLA / NLA*:
    Link-Local & Site-Local Unicast Addresses 1111111010 0 interface ID 1111111011 0 interface ID SLA*
  • Interface IDs
    • Lowest-order 64-bit field of unicast address may be assigned in several different ways:
      • auto-configured from a 64-bit EUI-64, or expanded from a 48-bit MAC address (e.g., Ethernet address)
      • auto-generated pseudo-random number (to address privacy concerns)
      • assigned via DHCP
      • manually configured
      • possibly other methods in the future
  • Some Special-Purpose Unicast Addresses
    • The unspecified address, used as a placeholder when no address is available: 0:0:0:0:0:0:0:0
    • The loopback address, for sending packets to self: 0:0:0:0:0:0:0:1
  • Multicast Address Format
    • flag field
      • low-order bit indicates permanent/transient group
      • (three other flags reserved)
    • scope field:
      • 1 - node local 8 - organization-local
      • 2 - link-local B - community-local
      • 5 - site-local E - global
      • (all other values reserved)
    • map IPv6 multicast addresses directly into low order 32 bits of the IEEE 802 MAC
    FP  (8bits) Flags (4bits) Scope (4bits) Group ID (32bits) 11111111 000T Lcl/Sit/Gbl Locally administered RESERVED (80bits) MUST be 0
  • Multicast Address Format Unicast-Prefix based
    • P = 1 indicates a multicast address that is assigned based on the network prefix
    • plen indicates the actual length of the network prefix
    • Source-specific multicast addresses is accomplished by setting
      • P = 1
      • plen = 0
      • network prefix = 0
          • draft-ietf-ipngwg-uni-based-mcast-01.txt
    FP  (8bits) Flags (4bits) Scope (4bits) Group ID (32bits) 11111111 00PT Lcl/Sit/Gbl Auto configured reserved (8bits) MUST be 0 plen (8bits) Locally administered Network Prefix (64bits) Unicast prefix
  • Outline
    • Protocol Background
    • Technology Highlights
    • Enhanced Capabilities
    • Transition Issues
    • Next Steps
  • Security
  • IPv6 Security
    • All implementations required to support authentication and encryption headers (“IPsec”)
    • Authentication separate from encryption for use in situations where encryption is prohibited or prohibitively expensive
    • Key distribution protocols are under development (independent of IP v4/v6)
    • Support for manual key configuration required
  • Authentication Header
    • Destination Address + SPI identifies security association state (key, lifetime, algorithm, etc.)
    • Provides authentication and data integrity for all fields of IPv6 packet that do not change en-route
    • Default algorithm is Keyed MD5
    Next Header Hdr Ext Len Security Parameters Index (SPI) Reserved Sequence Number Authentication Data
  • Encapsulating Security Payload (ESP) Payload Next Header Security Parameters Index (SPI) Sequence Number Authentication Data Padding Length Padding
  • Quality of Service
  • IP Quality of Service Approaches
    • Two basic approaches developed by IETF:
    • “ Integrated Service” (int-serv)
      • fine-grain (per-flow), quantitative promises (e.g., x bits per second), uses RSVP signaling
    • “ Differentiated Service” (diff-serv)
      • coarse-grain (per-class), qualitative promises (e.g., higher priority), no explicit signaling
  • IPv6 Support for Int-Serv
    • 20-bit Flow Label field to identify specific flows needing special QoS
      • each source chooses its own Flow Label values; routers use Source Addr + Flow Label to identify distinct flows
      • Flow Label value of 0 used when no special QoS requested (the common case today)
      • this part of IPv6 is not standardized yet, and may well change semantics in the future
  • IPv6 Support for Diff-Serv
    • 8-bit Traffic Class field to identify specific classes of packets needing special QoS
      • same as new definition of IPv4 Type-of-Service byte
      • may be initialized by source or by router enroute; may be rewritten by routers enroute
      • traffic Class value of 0 used when no special QoS requested (the common case today)
  • Compromise
    • Signaled diff-serv (RFC 2998)
      • uses RSVP for signaling with course-grained qualitative aggregate markings
      • allows for policy control without requiring per-router state overhead
  • Mobility
  • IPv6 Mobility
    • Mobile hosts have one or more home address
      • relatively stable; associated with host name in DNS
    • A Host will acquire a foreign address when it discovers it is in a foreign subnet (i.e., not its home subnet)
      • uses auto-configuration to get the address
      • registers the foreign address with a home agent, i.e, a router on its home subnet
    • Packets sent to the mobile’s home address(es) are intercepted by home agent and forwarded to the foreign address, using encapsulation
    • Mobile IPv6 hosts will send binding-updates to correspondent to remove home agent from flow
  • Mobile IP (v4 version) home agent home location of mobile host foreign agent mobile host correspondent host
  • Mobile IP (v4 version) home agent home location of mobile host foreign agent mobile host correspondent host
  • Mobile IP (v4 version) home agent home location of mobile host foreign agent mobile host correspondent host
  • Mobile IP (v4 version) home agent home location of mobile host foreign agent mobile host correspondent host
  • Mobile IP (v6 version) home agent home location of mobile host mobile host correspondent host
  • Mobile IP (v6 version) home agent home location of mobile host mobile host correspondent host
  • Mobile IP (v6 version) home agent home location of mobile host mobile host correspondent host
  • Mobile IP (v6 version) home agent home location of mobile host mobile host correspondent host
  • Mobile IP (v6 version) home agent home location of mobile host mobile host correspondent host
  • IPv6 Routing
  • RIPng
    • RIPv2, supports split-horizon with poisoned reverse
    • RFC2080
  • BGP4+ Overview
    • Added IPv6 address-family
    • Added IPv6 transport
    • Runs within the same process - only one AS supported
    • All generic BGP functionality works as for IPv4
    • Added functionality to route-maps and prefix-lists
  • IPv6 routing
    • OSPF & ISIS updated for IPv6
  • Outline
    • Protocol Background
    • Technology Highlights
    • Enhanced Capabilities
    • Transition Issues
    • Next Steps
  • Porting Issues
  • Effects on higher layers
    • Changes TCP/UDP checksum “pseudo-header”
    • Affects anything that reads/writes/stores/passes IP addresses (just about every higher protocol)
    • Packet lifetime no longer limited by IP layer (it never was, anyway!)
    • Bigger IP header must be taken into account when computing max payload sizes
    • New DNS record type: AAAA and (new) A6
  • Sockets API Changes
    • Name to Address Translation Functions
    • Address Conversion Functions
    • Address Data Structures
    • Wildcard Addresses
    • Constant Additions
    • Core Sockets Functions
    • Socket Options
    • New Macros
  • Core Sockets Functions
    • Core APIs
        • Use IPv6 Family and Address Structures
        • socket() Uses PF_INET6
    • Functions that pass addresses
        • bind()
        • connect()
        • sendmsg()
        • sendto()
    • Functions that return addresses
        • accept()
        • recvfrom()
        • recvmsg()
        • getpeername()
        • getsockname()
  • Name to Address Translation
    • getaddrinfo()
      • Pass in nodename and/or servicename string
        • Can Be Address and/or Port
      • Optional Hints for Family, Type and Protocol
          • Flags – AI_PASSIVE, AI_CANNONNAME, AI_NUMERICHOST, AI_NUMERICSERV, AI_V4MAPPED, AI_ALL, AI_ADDRCONFIG
      • Pointer to Linked List of addrinfo structures Returned
          • Multiple Addresses to Choose From
    • freeaddrinfo()
    • struct addrinfo {
    • int ai_flags;
    • int ai_family;
    • int ai_socktype;
      • int ai_protocol;
    • size_t ai_addrlen;
      • char *ai_canonname;
    • struct sockaddr *ai_addr;
      • struct addrinfo *ai_next;
      • };
    int getaddrinfo( IN const char FAR * nodename, IN const char FAR * servname, IN const struct addrinfo FAR * hints, OUT struct addrinfo FAR * FAR * res );
  • Address to Name Translation
    • getnameinfo()
      • Pass in address (v4 or v6) and port
        • Size Indicated by salen
        • Also Size for Name and Service buffers (NI_MAXHOST, NI_MAXSERV)
      • Flags
        • NI_NOFQDN
        • NI_NUMERICHOST
        • NI_NAMEREQD
        • NI_NUMERICSERV
        • NI_DGRAM
    int getnameinfo( IN const struct sockaddr FAR * sa, IN socklen_t salen, OUT char FAR * host, IN size_t hostlen, OUT char FAR * serv, IN size_t servlen, IN int flags );
  • Porting Environments
    • Node Types
        • IPv4-only
        • IPv6-only
        • IPv6/IPv4
    • Application Types
        • IPv6-unaware
        • IPv6-capable
        • IPv6-required
    • IPv4 Mapped Addresses
  • Porting Issues
    • Running on ANY System
        • Including IPv4-only
    • Address Size Issues
    • New IPv6 APIs for IPv4/IPv6
    • Ordering of API Calls
    • User Interface Issues
    • Higher Layer Protocol Changes
  • Specific things to look for
    • Storing IP address in 4 bytes of an array.
    • Use of explicit dotted decimal format in UI.
    • Obsolete / New:
      • AF_INET replaced by AF_INET6
      • SOCKADDR_IN replaced by SOCKADDR_STORAGE
      • IPPROTO_IP replaced by IPPROTO_IPV6
      • IP_MULTICAST_LOOP replaced by SIO_MULTIPOINT_LOOPBACK
      • gethostbyname replaced by getaddrinfo
      • gethostbyaddr replaced by getnameinfo
  • IPv6 literal addresses in URL’s
    • From RFC 2732
    • Literal IPv6 Address Format in URL's Syntax To use a literal IPv6 address in a URL, the literal address should be enclosed in "[" and "]" characters. For example the following literal IPv6 addresses: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
    • 3ffe:2a00:100:7031::1
    • ::192.9.5.5
    • 2010:836B:4179::836B:4179
    • would be represented as in the following example URLs: http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html
    • http://[3ffe:2a00:100:7031::1]
    • http://[::192.9.5.5]/ipng
    • http://[2010:836B:4179::836B:4179]
  • Other Issues
    • Renumbering & Mobility routinely result in changing IP Addresses –
      • Use Names and Resolve, Don’t Cache
    • Multihomed Servers
      • More Common with IPv6
      • Try All Addresses Returned
    • Using New IPv6 Functionality
  • Porting Steps -Summary
    • Use IPv4/IPv6 Protocol/Address Family
    • Fix Address Structures
        • in6_addr
        • sockaddr_in6
        • sockaddr_storage to allocate storage
    • Fix Wildcard Address Use
        • in6addr_any, IN6ADDR_ANY_INIT
        • in6addr_loopback, IN6ADDR_LOOPBACK_INIT
    • Use IPv6 Socket Options
        • IPPROTO_IPV6, Options as Needed
    • Use getaddrinfo()
        • For Address Resolution
  • IPv4 - IPv6 Co-Existence / Transition
  • IPv6 Timeline (A pragmatic projection) Q1 Q2 Q3 Q4 2007 Q1 Q2 Q3 Q4 2004 Q1 Q2 Q3 Q4 2003 Q1 Q2 Q3 Q4 2000 Q1 Q2 Q3 Q4 2001 Q1 Q2 Q3 Q4 2002 Q1 Q2 Q3 Q4 2005 Q1 Q2 Q3 Q4 2006
    • Consumer adoption <= Duration 5+ years
    • Application porting <= Duration 3+ years
    • Early adopter
    => =>
    • Enterprise adoption
    <= Duration 3+ years => => adoption <= Duration 3+ years
      • ISP
  • Deployments
    • IPv6 deployments will occur piecewise from the edge.
      • Core infrastructure only moving when significant customer usage demands it.
      • Platforms and products that are updated first need to address the lack of ubiquity. Whenever possible, devices and applications should be capable of both IPv4 & IPv6, to minimize the delays and potential failures inherent in translation points.
  • Impediments to IPv6 deployment
    • Applications
    • Applications
    • Applications
      • Move to the new APIs NOW
  • Transition / Co-Existence Techniques
    • A wide range of techniques have been identified and implemented, basically falling into three categories:
      • (1) dual-stack techniques, to allow IPv4 and IPv6 to co-exist in the same devices and networks
      • (2) tunneling techniques, to avoid order dependencies when upgrading hosts, routers, or regions
      • (3) translation techniques, to allow IPv6-only devices to communicate with IPv4-only devices
    • Expect all of these to be used, in combination
  • Dual-Stack Approach
    • When adding IPv6 to a system, do not delete IPv4
      • this multi-protocol approach is familiar and well-understood (e.g., for AppleTalk, IPX, etc.)
      • note: in most cases, IPv6 will be bundled with new OS releases, not an extra-cost add-on
    • Applications (or libraries) choose IP version to use
      • when initiating, based on DNS response:
        • Prefer scope match first, when equal IPv6 over IPv4
      • when responding, based on version of initiating packet
    • This allows indefinite co-existence of IPv4 and IPv6, and gradual app-by-app upgrades to IPv6 usage
  • Tunnels to Get Through IPv6-Ignorant Routers
    • Encapsulate IPv6 packets inside IPv4 packets (or MPLS frames)
    • Many methods exist for establishing tunnels:
      • manual configuration
      • “ tunnel brokers” (using web-based service to create a tunnel)
      • automatic (depricated, using IPv4 as low 32bits of IPv6)
      • “ 6-over-4” (intra-domain, using IPv4 multicast as virtual LAN)
      • “ 6-to-4” (inter-domain, using IPv4 addr as IPv6 site prefix)
    • Can view this as:
      • IPv6 using IPv4 as a virtual NBMA link-layer, or
      • an IPv6 VPN (virtual public network), over the IPv4 Internet
  • Translation
    • May prefer to use IPv6-IPv4 protocol translation for:
      • new kinds of Internet devices (e.g., cell phones, cars, appliances)
      • benefits of shedding IPv4 stack (e.g., serverless autoconfig)
    • This is a simple extension to NAT techniques, to translate header format as well as addresses
      • IPv6 nodes behind a translator get full IPv6 functionality when talking to other IPv6 nodes located anywhere
      • they get the normal (i.e., degraded) NAT functionality when talking to IPv4 devices
      • drawback : minimal gain over IPv4/IPv4 NAT approach
  • Tunnels
    • 6to4
    • Configured
    • Automatic
  • 6to4 tunnels IPv4 IPv6 IPv6 6to4 prefix is 2002::/16 + IPv4 address. 2002:a.b.c.d::/48 IPv6 Internet 6to4 relay 2002:B00:1::1 Announces 2002::/16 to the IPv6 Internet 130.67.0.1 148.122.0.1 11.0.0.1 2002:8243:1::/48 2002:947A:1::/48 FP  (3bits) TLA  (13bits) IPv4 Address  (32bits) SLA ID  (16bits) Interface ID (64bits) 001 0x0002 ISP assigned Locally administered Auto configured
  • 6to4 tunnels II NB: there is a draft describing how to use IPv4 anycast to reach the relay router. (This is already supported, by our implementation...) Has to use 6to4 addresses, not native. Works without adjacent native IPv6 routers Requires relay router to reach native IPv6 Internet Only site border router needs to know about 6to4 All issues that NMBA networks have. Minimal configuration Cons Pros
  • Configured tunnels -------------------------------------- |IPv4 header|IPv6 header IPv6 payload| -------------------------------------- IPv4 protocol type = 41 IPv4 IPv6 IPv6 3ffe:c00:1::/48 3ffe:c00:2::/48 130.67.0.1 148.122.0.1
  • Configured tunnels II No keepalive mechanism, interface is always up Real addresses Inefficient traffic patterns Multicast Has to be configured and managed As point to point links Cons Pros
  • Automatic tunnels IPv4 IPv6 IPv6 Connects dual stacked nodes Quite obsolete IPv6 Internet 130.67.0.1 ::130.67.0.1 148.122.0.1 ::148.122.0.1 IPv4 Address  (32bits) ISP assigned Defined 0
  • Automatic tunnels II Has to use IPv4 compatible addresses Useful for some other mechanisms, like BGP tunnels Difficult to reach the native IPv6 Internet, without injecting IPv4 routing information in the IPv6 routing table Obsolete Cons Pros
  • Tunneling issues
    • IPv4 fragmentation needs to be reconstructed at tunnel endpoint.
    • No translation of Path MTU messages between IPv4 & IPv6.
    • Translating IPv4 ICMP messages and pass back to IPv6 originator.
    • May result in an inefficient topology.
  • Tunneling issues II
    • Tunnel interface is always up. Use routing protocol to determine link failures.
    • Be careful with using the same IPv4 source address for several tunneling mechanisms. Demultiplexing incoming packets is difficult.
  • Deployment scenarios
    • Many ways to deliver IPv6 services to End Users
      • Most important is End to End IPv6 traffic forwarding
    • Service Providers and Enterprises may have different deployment needs
    • IPv6 over IPv4 tunnels
    • Dedicated Data Link layers for native IPv6
      • no impact on IPv4 traffic & revenues
    • Dual stack Networks
      • IPv6 over MPLS or IPv4-IPv6 Dual Stack Routers
  • Media - Interface Identifier
    • IEEE interfaces - EUI-64
      • MAC-address: 0050.a218.0c38
      • Interface ID: 250:A2FF:FE18:C38
    • P2P links (HDLC, PPP)
      • Interface ID: 50:A218:C00:D
      • 48 bits from the first MAC address in the box + 16 bit interface index. U/L bit off
    • IPv4 tunnels
      • Interface ID: ::a.b.c.d
  • Outline
    • Protocol Background
    • Technology Highlights
    • Enhanced Capabilities
    • Transition Issues
    • Next Steps
  • Current Status
  • Standards
    • core IPv6 specifications are IETF Draft Standards => well-tested & stable
      • IPv6 base spec, ICMPv6, Neighbor Discovery, PMTU Discovery, IPv6-over-Ethernet, IPv6-over-PPP,...
    • other important specs are further behind on the standards track, but in good shape
      • mobile IPv6, header compression, A6 DNS support,...
      • for up-to-date status: playground.sun.com/ipng
    • UMTS R5 cellular wireless standards mandate IPv6
  • Implementations
    • Most IP stack vendors have an implementation at some stage of completeness
      • some are shipping supported product today, e.g., 3Com, *BSD(KAME), Cisco, Epilogue, Ericsson/Telebit, IBM, Hitachi, NEC, Nortel, Sun, Trumpet
      • others have beta releases now, supported products soon, e.g., Compaq, HP, Linux community, Microsoft
      • others rumored to be implementing, but status unkown (to me), e.g., Apple, Bull, Juniper, Mentat, Novell, SGI
      • (see playground.sun.com/ipng for most recent status reports)
    • Good attendance at frequent testing events
  • IPv6 Addresses Bootstrap phase
    • Where to get address space?
      • Real IPv6 address space now allocated by APNIC, ARIN and RIPE NCC
      • APNIC 2001:0200::/23
      • ARIN 2001:0400::/23
      • RIPE NCC 2001:0600::/23
      • 6Bone 3FFE::/16
    • Have a look at www.cisco.com/ipv6 for further information
  • IPv6 Address Space Current Allocations
    • APNIC (whois.apnic.net)
    • CONNECT-AU-19990916 2001:210::/35
    • WIDE-JP-19990813 2001:200::/35
    • NUS-SG-19990827 2001:208::/35
    • KIX-KR-19991006 2001:220::/35
    • ETRI-KRNIC-KR-19991124 2001:230::/35
    • NTT-JP-19990922 2001:218::/35
    • HINET-TW-20000208 2001:238::/35
    • IIJ-JPNIC-JP-20000308 2001:240::/35
    • CERNET-CN-20000426 2001:250::/35
    • INFOWEB-JPNIC-JP-2000502 2001:258::/35
    • JENS-JP-19991027 2001:228::/35
    • BIGLOBE-JPNIC-JP-20000719 2001:260::/35
    • 6DION-JPNIC-JP-20000829 2001:268::/35
    • DACOM-BORANET-20000908 2001:270::/35
    • ODN-JPNIC-JP-20000915 2001:278::/35
    • KOLNET-KRNIC-KR-20000927 2001:280::/35
    • HANANET-KRNIC-KR-20001030 2001:290::/35
    • TANET-TWNIC-TW-20001006 2001:288::/35
    • SONYTELECOM-JPNIC-JP-20001207 2001:298::/35
    • TTNET-JPNIC-JP-20001208 2001:2A0::/35
    • CCCN-JPNIC-JP-20001228 2001:02A8::/35
    • IMNET-JPNIC-JP-20000314 2001:0248::/35
    • KORNET-KRNIC-KR-20010102 2001:02B0::/35
    • ARIN (whois.arin.net)
    • ESNET-V6 2001:0400::/35
    • ARIN-001 2001:0400::/23
    • VBNS-IPV6 2001:0408::/35
    • CANET3-IPV6 2001:0410::/35
    • VRIO-IPV6-0 2001:0418::/35
    • CISCO-IPV6-1 2001:0420::/35
    • QWEST-IPV6-1 2001:0428::/35
    • DEFENSENET 2001:0430::/35
    • ABOVENET-IPV6 2001:0438::/35
    • SPRINT-V6 2001:0440::/35
    • UNAM-IPV6 2001:0448::/35
    • GBLX-V6 2001:0450::/35
    January 5th, 2001
  • IPv6 Address Space Current Allocations
    • RIPE (whois.ripe.net)
    • UK-BT-19990903 2001:0618::/35
    • CH-SWITCH-19990903 2001:0620::/35
    • AT-ACONET-19990920 2001:0628::/35
    • UK-JANET-19991019 2001:0630::/35
    • DE-DFN-19991102 2001:0638::/35
    • NL-SURFNET-19990819 2001:0610::/35
    • RU-FREENET-19991115 2001:0640::/35
    • GR-GRNET-19991208 2001:0648::/35
    • EU-UUNET-19990810 2001:0600::/35
    • DE-TRMD-20000317 2001:0658::/35
    • FR-RENATER-20000321 2001:0660::/35
    • EU-EUNET-20000403 2001:0670::/35
    • DE-IPF-20000426 2001:0678::/35
    • DE-NACAMAR-20000403 2001:0668::/35
    • DE-XLINK-20000510 2001:0680::/35
    • DE-ECRC-19991223 2001:0650::/35
    • FR-TELECOM-20000623 2001:0688::/35
    • PT-RCCN-20000623 2001:0690::/35
    • SE-SWIPNET-20000828 2001:0698::/35
    • PL-ICM-20000905 2001:06A0::/35
    • DE-SPACE-19990812 2001:0608::/35
    • BE-BELNET-20001101 2001:06A8::/35
    • SE-SUNET-20001218 2001:06B0::/35
    • IT-CSELT-20001221 2001:06B8::/35
    • SE-TELIANET-20010102 2001:06C0::/35
  • Deployment
    • experimental infrastructure: the 6bone
      • for testing and debugging IPv6 protocols and operations (see www.6bone.net)
    • production infrastructure in support of education and research: the 6ren
      • CAIRN, Canarie, CERNET, Chunahwa Telecom, Dante, ESnet, Internet 2, IPFNET, NTT, Renater, Singren, Sprint, SURFnet, vBNS, WIDE (see www.6ren.net, www.6tap.net)
    • commercial infrastructure
      • a few ISPs (IIJ, NTT, SURFnet, Trumpet,…) have announced commercial IPv6 service or service trials
  • Deployment (cont.)
    • IPv6 address allocation
      • 6bone procedure for test address space
      • regional IP address registries (APNIC, ARIN, RIPE-NCC) for production address space
    • deployment advocacy (a.k.a. marketing)
      • IPv6 Forum: www.ipv6forum.com
  • Much Still To Do
    • though IPv6 today has all the functional capability of IPv4,
    • implementations are not as advanced (e.g., with respect to performance, multicast support, compactness, instrumentation, etc.)
    • deployment has only just begun
    • much work to be done moving application, middleware, and management software to IPv6
    • much training work to be done (application developers, network administrators, sales staff,…)
    • many of the advanced features of IPv6 still need specification, implementation, and deployment work
  • Recent IPv6 “Hot Topics” in the IETF
    • multihoming / address selection
    • address allocation
    • DNS discovery
    • 3GPP usage of IPv6
    • anycast addressing
    • scoped address architecture
    • flow-label semantics
    • API issues
      • (flow label, traffic class, PMTU discovery, scoping,…)
    • enhanced router-to-host info
    • site renumbering procedures
    • temp. addresses for privacy
    • inter-domain multicast routing
    • address propagation and AAA issues of different access scenarios
      • (always-on, dial-up, mobile,…)
    • and, of course, transition / co-existence / interoperability with IPv4
    Note: this indicates vitality, not incompleteness, of IPv6!
  • Next Steps
  • For More Information
    • http://www.ietf.org/html.charters/ipngwg-charter.html
    • http://www .ietf.org/html.charters/ngtrans-charter.html
    • http://playground.sun.com/ipv6/
    • http://www.6bone.net/ngtrans/
  • For More Information
    • http://www.6bone.net
    • http://www.ipv6forum.com
    • http://www.ipv6.org
    • http://www.cisco.com/ipv6/
    • http://www.microsoft.com/windows2000/library/howitworks/communications/networkbasics/IPv6.asp
  • For More Information
    • BGP4+ References
      • RFC2858 Multiprotocol extension to BGP RFC2545 BGP MP for IPv6 RFC2842 Capability negotiation
    • RIPng RFC2080
  • Other Sources of Information
    • Books
      • IPv6, The New Internet Protocol by Christian Huitema (Prentice Hall)
      • Internetworking IPv6 with Cisco Routers by Silvano Gai (McGraw-Hill)
      • and many more... (14 hits at Amazon.com)
  • Questions…
  • s.senthilkumar Technical project lead, IPOS-IPv6 Huawei Technologies India PVT LTD Level 3,4,5 and 7, Leela Galleria The Leela Palace, No 23, Airport Road, Bangalore – 560-008 E-Mail: senthilkumars@huawei.com