IPv6 Migration Flashcards
IPv6 migration approaches
- Dual Stack
- Dual Layer
Dual stack migration approach
Dual Stack
- Both capabilities in all entities supporting v6
- v4 support can be graudally removed
- Complete duplication of all protocol stack components
- Routing protocols, tables, access lists
- It doesn’t reduce the need for more v4 addresses
- Application need to choose between v4 and v6.

Dual layer migration approach
Application are not responsible for choosing protocol to use: TCP/UDP selects most suited protocol (for example using information from DNS records (Type A, AAAA))
Less modifications in the applications
Less used than dual stack.

Travering IPv4 only network
Tunneling:
- Encapsulating v6 packets in v4 packets emulating a directs link
- End-point: hosts and routers
- Protocols:
- GRE
- IPv6 in IPv4
- Setup: manual and automatic
- IPV4-compatible addresses
- 6over4
- 6to4
- Tunnel broker
- ISATAP
- Teredo
Host centered vs Networks centered vs Carrier-Grade solution list
HC solutions: Dual stack hosts exchange IPv6 packets through an IPv4 network
- ipv4 compatible addresses
- 6over4
- ISATAP
NC solutions: Dual stack and native v6 hosts exchange v6 packets through a v4 network.
- Teredo
- Tunnel Broker
- 6to4
Scalable, CG solutions: Native IPv6 (ipv4) hosts exchange IPv6 (ipv4) packetrs through IPv4 (IPv6) network.
- DS-lite
- A+P
- MAP-T and MAP-E
- NAT64
- 6PE (MPLS-based)
ipv6 migration: ipv4 compatible addresses
improperly called automatic tunneling
ipv4-compatible addresses (::/96) are used for v6 communication
process:
- app send ipv6 packets to ipv6 addresses
- static route forewards packets to ::/96 through pseudo-interface
- pseudo-interface encapsulates v6 packets in v4 packets and sends them out
If configured with dual stack router:
- pseudo-interface in sending host in is configured to terminate tunnels on router
- encapsulating v4 packets are sent to v4 address of dual stack router

6over4
- Host cenetered solution in ipv6 transition
- ipv4 networks emulates a virtual LAN
- broadcast multiple access data link
- ip multicasting used for the purpose
- Neighbor and router discovery enabled
- v4 address is used for automatic v6 interface ID generation of link local address
- Not very used because of the lacking support for v4 multicast
6over4 neighbor discovery
- ipv6 mutlicast addresses are mapped on ipv4 multicast addresses
- 239.192.x.y where x.y are last 2 bytes of ipv6 address

ISATAP
- Intra-site automatic tunnel addressing protocol
- ipv4 netowrk as non-broadcast multiple access data link (NBMA)
- No IP multicast suppport
- Interface Id derived from lpv4 address
- Prefixed by 0000:5efe
- fe80::5efe:0101:0101
- No neighbor discovery: not needed for data-link address discovery as ipv4 address is embedded in ipv6 address
- PRL (Potential Router List) must be provided: router discovery is not possible
- List usually obtained to DNS query to isatap.domain.com (usually domain is obtained through DHCP) or through configuration
- Each router in the list is infrequently probed to check if they are working and to perform unicast-only configuration.
6to4
- Network centered solution for ipv6 migration
- Relay v4 address is embedded in ipv6 prefix by appending it to 2002::/16
- 192.0.2.4 -> 2002:c000:0204::/48
- Basic scenario: not meant for ipv4 host to ipv6 host communication
- Mixed scenario (ipv4 global internet + ipv6 gobal internet): 6to4 relay must be default gatway (192.88.99.1) of 6to4 routers to handle cases of prefix not matching 6to4
- Default gateway (6to4) realy: to be used whener I don’t know what to do with an ipv6 packet (prefix not matching 6to4 prefix)

Teredo
- Solution to ipv6 transition with network centered approach
- Architecture similar to 6to4
- IPv6 packets are encapsulated in IP/UDP to be compatible with NAT, since NAT cannot use ports with IPV6 in IPv4.

Tunnel Broker
- Solution to ipv6 transition with network centered approach
- Solves the problem of 6to4: I cannot use a general ipv6 prefix
- Tunnel broker server:
- Indentifies tunnel servers (routers) and mediates tunnel setup (gives us the ipv4 addresses to contact)
- IPv6 in IPv4 tunnels
- Tunnel setup Protocol/Tunnel Information Control: protocol used to setup tunnels
- 6to4 doens’t support any prefix, but is completely decentralized, doesn’t need central server, here we need it.
- Who is in charge of the server (who pays for it) when it is shared between ISPs? big problem.
- Pretty similar to ISATAP

Goal of Scalable, carrier grade solution to ipv6 transition
Goals:
- need to support
- ipv4 servers possibly communicating with ipv6 hosts
- ipv4 clients

AFTR
Address family transition router:
- allows ipv4 hosts to communcate wit ipv4 hosts over an ipv6 carrier infrastructure
- residential hosts and current providers
- features ipv6 tunnel concentrator and possibly a large-scale NAT
- in use in DS-lite and A+P

DS-lite
Dual stack lite
- Dual stack at the edge of the network
- IPv6 only service provider backbone
- Properties:
- Reduces requirement for ipv4 addresses compared to dual-stack approach
- dual-stack requires an ipv4 public address per host
- Extended NAT enables customer assigned addressing
- IPv6 address of CPE in NAT table
- Reduces requirement for ipv4 addresses compared to dual-stack approach
- Limitation:
- NAT is not under control of customer (same as with CarrierGradeNAT)
- Problematic with servers (static mapping and port forwarding cannot be configured)

A+P
- Address + Port
- Carrier grade solution to ipv6 migration
- NAT is under control of customer
- Ranges of TCP/UDP ports are assigned to each customer
- Only ports used by NAT on outside
- Features
- No problem with overlapping private address spaces at customers’
- Ports acan be assigned automatically to CPE using the Port Control Protocol
- CPE can negotiate more ports at any time
- AFTR is just IPv4-in-IPv6 (proto-41) tunnel terminator
- NAT44 is not needed

MAP ipv6 migration
- Mapping address and port
- Multiple CPE use same public IPv4 address
- set (not range) of ports assigned to cpe
- Client ipv4 address and port set mapped to unique ipv6 address
- prefix routed to cpe
- ipv4 public server address mapped to unique ipv6 address
- prefix routed to border relay
- MAP-E (E stands for Encapsulation):
- IPv4 packets are tunneled
- MAP-T (translation): ipv4 translated to ipv6

MAP port set
Port set:
- Each CPE is assigned a unique PSID.
- A > 0 is a bits; PSID is k bits; ; j is m bits.
- a+ k + m = 16bits
- The cpe uses ports with psid value, varying A and j.
MAP CPE ipv6 address
- EA(Embedded address) bits contain PSID and partial ipv4 address
- uniquely identifis the cpe

MAP border relay
- BR address must be known to CPEs Multiple BRs might have same address
- Anycasting
- MAP-E: BR address terminates tunnel
- MAP-T: prefix associated to BR used for translation of outside IPv4 addreses
- BR prefix is advertised on the backbone
- Might be advertised by multiple BRs
NAT64 + DNS64
Principles:
- an ipv6 prefix is dedicated to a mapped ipv4 address
- dns64 maps A records (ipv4) into AAAA using NAT64 prefix, then serves A and AAAA records to the client
- NAT64 router advertises NAT64 prefix into ipv6 network to attract traffic toward ipv4 hosts
Limitations:
- Possible only when dns is involved
- does not work if user specifies directly ipv4 address
- no dnssec (authoritative dns signs records): since dns64 modifies records

NAT64 + DNS64 deployment scenarios

nat64 packet forwarding
- Translates ipv6 adress and packet into ipv4
- picks a free ipv4 address/port form its pool
- build nat session entry

DNS64 + NAT64 special case of no need for dns

6PE
- Only PE routers need to be changed
- same mechanism as MPLS-based VPN
- very scalable
- Minimum configuration required
- As more customers require ipv6 connectivity, provider might consider migrating to native support.
- Internal routing
- 6PE and P routers advertise their ipv4 prefixes with Labels bound to each PE
- Topology based label binding.
- 6PE and P routers advertise their ipv4 prefixes with Labels bound to each PE
In the image:
P-1, P-2: IPV4 only routers
PE-1,PE-2: Dual stack IPv4-IPv6 with MultiProtocol-BGP (MP-BGP)

MPLS-Based solutions
- Meant for interconnecting ipv6 islads through an ipv4 mpls backbone
- most netowrk service providers deploy mpls anyway
- IPv6 and MPLS:
- Data plane is agnostic to ipv4/ipv6 (labels)
- Control plane is not agnostic: destinations are identified through IP address.
Solutions:
- Native IPv6 over MPLS
- IPv6 over Circtuit Transport
- 6PE
Native IPv6 over MPLS
- Control plane fully upgraded
- IPv6 support in:
- routing
- label distribution protocol
- management
- Possibly Dual support
IPv6 over Circuit transport
- MPLS as layer 2 connectivity
- LSP === L2 tunnel
- PEs are ipv6 aware: static routes to ipv6 destinations and routing with remote PEs
- No changes needed to P routers
- It does not scale:
- L2 tunnels routes are configured manually
- possibly mesh topology of L2 tunnels
Propagation and redistribution of routes, announcing ipv6 network with 6PE
- Propagation of routes
- 6pe exchange routing info through mp-bgp sessions over ipv4
- 6pe ipv4-mapped address as BGP next hop
- Announcing ipv6 networks
- CE and 6PE connect through native ipv6 interfaces
routing information is exchanged
- Redistribution of ipv6 routes
- PEs propagate adv to ipv6 networks through IGP
- May not be needed if CE-1 uses a default route
- Label distribution
- For ipv4 dest. among P and 6PE routers
- LDP or RSVP
- For ipv6 routers: directly between 6PE, using MP-iBGPv4
- For ipv4 dest. among P and 6PE routers

6PE packet forwarding
- CE routers send IPv6 packets to 6PE routers
- 6PE has label mapping for destination
- was distributed by iBGP
- next hop: 6PE identified the BGP next hop
- ipv4-mapped ipv6 address
- Next hop is reachable through ipv4 (IGP said that)
*
