IPv6

Page Links: 2017, 2016, 2015, Notes, Useful

2018 News

  • 15-08-2018: The state of the IPv4 market.  [Russ White]  [CircleID]
  • 08-08-2018: IPv6: It's only NAT-ural that network nerds are dragging their feet.  [The Register]
  • 06-08-2018: IPv6-only world on the horizon.  [EETimes]
  • 28-06-2018: Time to dump dual-stack networks and get on the IPv6 train – with LW4o6.  [The Register]
  • 06-06-2018: Vint Cerf blasts techies for lackluster worldwide IPv6 adoption.  [The Register]
  • 06-06-2018: IPv6 makes progress, but much work remains.  [Network Computing]
  • 18-04-2018: The last available IPv4 address block has gone.  [The Register]
  • 11-04-2018: The next chapter in IPv6 multihoming saga.  [ipSpace]

2017 News

  • 27-11-2017: China plots new Great Leap Forward: to IPv6.  [The Register]
  • 23-05-2017: IETF RFC8159 keyed IPv6 tunnel.  [EtherealMind]  [RFC 8159]
  • 05-05-2017: What IPv6 transitions mechanisms are actually being used?  [ipSpace]
  • 21-04-2017: MIT selling 8 million IPv4 addresses.  [HardOCP]  [GitHubGist]
  • 20-04-2017: Seven steps to successful IPv4 transfers.  [Russ White]  [APNIC Blog]
  • 19-04-2017: Governing body declares: No IP addresses for governments that shut down internet access.  [ExtremeTech]
  • 19-04-2017: IPv6 extensions are already dead.  [EtherealMind]
  • 10-04-2017: Finally a reason not to bother with IPv6: Uh, security concerns...?  [The Register]  [HardOCP]  [Russ White]  [ITnews]
  • 10-03-2017: Public IPv4 drought: Verizon Wireless to stop handing out static addresses.  [The Register]
  • 15-02-2017: Global IPv4 address drought: Seriously, we're done now.  [The Register]
  • 31-01-2017: IPv4 in a world of IoT.  [DC Knowledge]
  • 18-01-2017: IPv6 vulnerable to fragmentation attacks that threaten core internet routers.  [The Register]
  • 09-01-2017: Studying the IPv4 transfer market.  [Russ White]  [APNIC]
  • 05-01-2017: The back-door feature problem.  [Russ White]  [CAIDA, PDF]

2016 News

  • 08-11-2016: IPv4 is over, so quit relying on it in new protocols.  [The Register]
  • 29-09-2016: ARIN IPv4 depletion: the aftermath.  [Network Computing]
  • 19-09-2016: IPv4 apocalypse means we just can't measure the internet any more.  [The Register]
  • 16-09-2016: Google: there are three certainties in life – death, taxes and IPv6.  [The Register]
  • 16-09-2016: IPv6 versus v4 performance map.  [Russ White]  [APNIC]
  • 29-07-2016: This is how you build an IPv6-only data center.  [ipSpace]  [Hostinger]
  • 28-07-2016: IPv6 now faster than IPv4 when visiting 20% of top websites – and just as fast for the rest.  [The Register]
  • 12-07-2016: Measuring IPv6 from the Internet's core.  [Russ White]  [APNIC Blog]
  • 05-07-2016: Cutting through the IPv6 requirements red tape.  [ipSpace]
  • 01-07-2016: How IPv6 enables the connected home.  [Network Computing]
  • 22-06-2016: Fraudsters are buying IPv4 addresses.  [Schneier]  [The Register]
  • 06-06-2016: IPv6 progress report: going mainstream.  [Network Computing]
  • 02-06-2016: Cisco warns IPv6 ping-of-death vulnerability is everyone's problem.  [The Register]

2015 News

  • 23-11-2015: IPv6 performace.  [Geoff Huston]
  • 05-11-2015: There's a problem with IPv6 multihoming.  [ipSpace]
  • 10-08-2015: IPv6 and the swinging technology pendulum.  [ipSpace]
  • 05-08-2015: IPv4 address exhaustion in APNIC.  [Geoff Huston]
    • 12-08-2015: A second look at APNIC and IPv4 address exhaustion.  [Geoff Huston]
    • 14-08-2015: Engineering lessons, IPv6 edition.  [Russ White]
  • 03-08-2015: What’s driving IPv6 adoption? An IPv6 epiphany.  [Juniper]
  • 22-06-2015: IPv6 is here -- get used to it.  [ipSpace]
  • 15-06-2015: An update on IPv6.  [Geoff Huston]
  • 04-04-2015: IPv6 is 20 years old.  [ipSpace]
  • 26-03-2015: MLD considered harmful.  [ipSpace]

Useful Articles

General Notes

  • Because the Internet is almost exclusively based on IPv4, clients will need to use IPv4 to access this content.  Therefore, the introduction of IPv6 on its own does not solve the IPv4 address exhaustion problem in the short term.  As such, a two-pronged approach is needed: dual stack support and an IPv4 continuity strategy to prevent IPv4 address exhaustion.
  • The success of RFC1918, NAT/PAT, etc. has made migration to IPv6 today a bigger problem than it would have been 10 years ago.
  • The IPv4 address exhaustion issue doesn't have a "drop dead" deadline as the Y2K issue had.
  • The IPv4 address exhaustion issue also doesn't enable new revenue applications.
  • Different parts of the world will migrated at different speeds -- e.g. the following will migrate sooner:
    • US Gov and DoD set a 2008 deadline;
    • Many APAC countries will migrate sooner as they joined the Internet community late.
  • Different applications/technologies will migrate at different speeds -- e.g. the following will migrate sooner:
    • Mobile networks, as they have higher growth rates and fewer legacy constraints.
  • An ALu study has shown that the largest share of IPv6 upgrade/migration cost is contributed to by the IP clients (IPv6-capable RGWs are about 30% more expensive than IPv4-only versions).
  • IPv4 continuity tries to postpone IPv4 address exhaustion by address overloading using:
    • LSN (NAT444)
    • DS Lite (464)
    • NAT64/NAT46 protocol translation
    • L2-aware NAT, uses L2 connectivity information to distinguish between subscribers:
      • 802.1Q (VLAN ID)
      • 802.1AD (stacked VLAN, or QinQ)
      • MAC address
      • PPPoE or L2TP ID
  • General approach:
    • Determine the most suitable IPv4 continuity strategy:
      • The impact of introducing network-based NAT functionality on existing services/processes.
      • The implications of IPv4 address overloading on existing addressing plans.
      • Operational procedures to migrated from transparent IPv4 to NATed operation.
      • Performance, scalability, interoperability and management requirements.
    • Determine the most appropriate IPv6 introduction strategy:
      • How legacy IPv4 services would interwork and/or migrate to IPv6 operation.
      • The differences and impact of IPv6 compared to IPv4 operation on the network, control plane and OSS.
      • IPv6 readiness of existing network and OSS infrastructure, and any necessary hardware/software upgrades.
      • Cost options and timing of introducing dual-stack operation in the CPE, access, aggregation, edge and core.
      • Training operational/technical staff (and customers) about IPv6 and its introduction.

Technical Info

  • Router Discovery
  • SLAAC
  • DHCPv6
  • Address Resolution
  • Transition Phases
  • NAT444, NAT464, NAT64+DNS64, DS Lite, NAT type comparison
  • Dual Stack
  • Migration options: dual stack, 6over4, 6PE, 6VPE
  • Various IPv6-related RFCs

Vendor Info

  • Cisco
  • Juniper
  • Alcatel-Lucent
  • Others

Miscellaneous


© Robert Larsen.  All rights reserved.
Ċ
IPv6Link-LocalAddresses.pdf
(10k)
Robert Larsen,
23 Oct 2017, 16:29
v.4
Ċ
IPv6_addr_plan4.pdf
(513k)
Robert Larsen,
23 Oct 2017, 16:29
v.4
Ċ
SuccessfulStrategiesforIPv6Rollouts.Really.pdf
(148k)
Robert Larsen,
23 Oct 2017, 16:29
v.4
Ċ
ipv6-address-types.pdf
(77k)
Robert Larsen,
23 Oct 2017, 16:29
v.4