9. IPv6 Transition I Flashcards
Reasons for deploying IPv6
- Exhaustion of IPv4 address space
- Enabling End-to-End global addressing
- Securing IPv6 in your own ‘IPv4 only’ network
- Enabling innovation/research/teaching
- Deploy in a limited scenario to gain experience
- Simplify early adopter IPv6-only access networks’ ability to reach you
- New applications; sensors, logistics, transport
Reasons against deploying IPv6
- I have enough global IPv4 addresses
- I like NAT
- Adding IPv6 adds cost/complexity
- No time/money/not a priority
- Don’t need to talk to IPv6 only devices yet
- Lack of support in certain apps/systems
NAT
Network Address Translation
IPv6 Deployment Approaches
Enable IPv6 capability upon the existing IPv4 infrastructure:
- run both protocols on same devices - known as dual stack
- should enable the network infrastructure before hosts/apps
- ensure connectivity, security & monitoring all are robust 1st
Initial capability may be in islands:
- need ways to connect IPv6 enables networks across intervening IPv4 only networks
- implies some form of tunnelling or encapsulation of traffic
Deploy IPv4/IPv6 dual-stack
Existing network runs IPv4
- introduce IPv6 to same network infrastructure
- known as dual-stack operation
- hosts and routers are able to communicate using either protocol and can thus also talk to IPv4-only or IPv6-only devices
Choice of protocol is application-specific
- DNS returns IPv4 and IPv6 addresses for a given hostname
- MS IE prefers IPv6 but can fall back to IPv4 (Chrome/Firefox try both, pick up whichever first connects)
- need to be confident IPv6 connectivity is good else the application may perform worse than IPv4-only network
Connecting IPv6 islands
May wish to deploy IPv6 at a site (eg campus) and then use IPv6 to communicate with remote IPv6 sites
- intervening networks may be IPv4 only, implies a tunnelling method
What type of tunnels might we need
- router to router (site to site)
- host to router (host to site)
Tunnels could be set up manually or automatically
Tunnelling
IPv6 packets encapsulated in IPv4 packets
- IPv6 packet is payload of IPv4 packet
Usually between routers to connect IPv6 islands
- edge router talks IPv6 natively to internal systems
- encapsulates IPv6 in IPv4 towards remote tunnel endpoint
Packet delivery over the tunnel
- IPv6 node A sends packet towars IPv6 node B
- routed internally to edge router A - Edge router A sees destination network B is reachable over tunnel interface
- encapsulates IPv6 packet in IPv4 packet/s
- sends resulting IPv4 packet/s to edge router B
- delivered over existing IPv4 internet infrastructure - Edge router B decapsulates IPv6 packet from payload of received IPv4 packet
- packet routed internally in network B towards node B
- Node B receives the IPv6 packet
Manually configure tunnels
Easy to set up and configure
- tedious if crating lots, or changing daily
Good management potential
- may be used by an ISP to connect sites using IPv6 over their current IPv4 only infr
- ISP configures all tunnels, so in control of deployment
- this is the current approach used by JANET to connect UK academic sites over IPv6 where native IPv6 connectivity is not available in the regional networks
- sites use a manually configured tunnel to a JANET access router
Connecting single hosts
An individual user - tunnel from their device to access IPv6
- eg user with a dual-stack device in a home ADSL network
- desirable to allow end user to register and subsequently authenticate to request a tunnel
- the IPv6 Tunnel Broker offers such a system, usually for host-to-router connectivity
Tunnel Broker
service which provides a network tunnel.
IPv6 tunnel brokers typically provide IPv6 tunnels to sites or end users over IPv4. In general, IPv6 tunnel brokers offer so called ‘protocol 41’ or proto-41 tunnels. These are tunnels where IPv6 is tunneled directly inside IPv4 packets by having the protocol field set to ‘41’ (IPv6) in the IPv4 packet.
Tunnel Broker MO
User/client registers with the broker system
A tunnel is requested from the user’s IPv4 address
The broker sets up its end of the requested tunnel on its tunnel server
The broker communicates the tunnel settings to the user for the client side configuration
User’s system executes script, establishing the tunnel
Broker issues
Key advantage is its manageability
ISP running the broker can track usage levels
A few downsides
- if broker topologically remote, round trip times for data might suffer
- traffic within the ISP is concentrated through the broker
- if using a remote tunnel broker, your own ISP may not perceive demand for IPv6
- Need additional client capability to handle IPv4 NAT traversal or a SOHO having a dynamic IPv4 address (HE broker uses a heartbeat protocol)
Automatic tunneling
Goal - avoid requiring support staff effort to setup and maintain tunnels
- set up required tunnels on demand
- keep deployment and usage simple for the end user
Most common automatic method is 6to4
( used router to router
widely available,
proven problematic as IPv6 has matured)
6to4
used to automatically connect two IPv6 islands across an intermediate IPv4-only network