Copyright © 2002 Juniper Networks, Inc. Introduction to IPv6 Ross Callon Net 2002 Fredericton, New Brunswick

Copyright © 2002 Juniper Networks, Inc. http://www.juniper.net

Introduction to IPv6

Ross CallonNet 2002

Fredericton, New Brunswick

Agenda

IPv6, What and Why? IPv6 Technical Description Transition to IPv6 Juniper's Phased IPv6

introduction Status and Plans for IPv6

http://www.juniper.net Copyright © 2002 Juniper Networks, Inc. 3

What is IPv6?

Datagram Protocol ** Routing via RIP, OSPF, IS-IS, BGP ** End-to-end reliability via TCP ** Can make use of MPLS **

** The same as IPv4 Semantics are very similar to IPv4 Larger addresses More emphasis on security


Why: Advantages of IPv6

Technical Advantages Larger addresses Easier configuration

Including easier address change Security “built in” Fix a few minor details


Why: Advantages of IPv6

Larger address space is the main point

Permit growth into new areas Cellular phones / wireless devices IP telephony “Always on” high speed internet service

requires “always available” address

Avoid issues with NAT


Growth of the Internet

63 new hosts per minute 11 new domains per minute 109M total hosts (March 2001) Current annual growth rate: 51% Estimated 1B hosts by mid-2005 8,000 ISPs worldwide (4700+ in U.S.

alone) Traffic growth 100-1000% per year Over 3M Websites 70% of Fortune 1000 use NAT

Source: Center for Next Generation Internet NGI.ORG


Growth of the Mobile IP Market

0

200

400

600

800

1000

1200

1400

1600

1995 1996 1997 1998 1999 2000 2001 2002 2003 2004

Millions

Sources: ABN AMRO/IDC/Ovum

Mobile Subscriber

s

PCs Connected

to Web

MobileInternet

Users


Inertia vs Incentive

Lots of inertia is supporting IPv4 IPv4 is mature & widely deployed What is incentive to move to IPv6?

IPv6 needs to Open up a new application area; or Relieve considerable pain

IPv6 does the former now, and will do the latter eventually

Agenda



IPv6 Technical Description

Addressing architecture Packet structure and header

formats Header extensions ICMPv6 Neighbor discovery Autoconfiguration IPv6 routing protocols Flow Label


IPv6 Addressing Architecture

Addresses similar to IPv4 IPv6 addresses identify interfaces (not

nodes) Hierarchical, topological addresses Forwarding based on best match

Some extra flexibility provided eg, anycast, auto-configuration Local node and link addresses available Easier address change supported

<draft-ietf-ipngwg-addr-arch-v3-07.txt> updates RFC 2373


IPv6 Address types

Unicast Identifies a single interface Packet sent to a unicast address is delivered to the

interface identified by that address Anycast

Identifies a set of interfaces (typically on different nodes) Packet sent to an anycast address is delivered to one of

the interfaces identified by that address (normally the nearest)

Multicast Identifies a set of interfaces (typically on different nodes) Packet sent to a multicast address is delivered to all

interfaces identified by that address IPv6 has no broadcast address


IPv6 Address types: Unicast

HTTP

HTTP

NTP

NTP

Host


3 Hops away

4 Hops away

IPv6 Address types: Anycast

HTTP

HTTP

NTP

NTP

Host

Example:NTP Servers use the same anycast addresses.Anycast takes shortest link to NTP server.

Host


IPv6 Address types: Multicast

Video

Video

NTP

NTP

HostHost


IPv6 Address Text Representation

128 bit length (16 octets) Represented as 8 * 16-bit pieces in

hexadecimal, separated by colons ":" For prefixes: IPv6-address/length (bits) Multiple 16-bit fields of zeros can be

compacted by using a double-colon "::" Compaction only used once per address Low order 32 bits can use v4 format

“d.d.d.d“


IPv6 Address Representation examples

IPv6 Addresses:CDFE:910A:2356:5709:8475:1024:3911:20212080:0000:0000:0000:0090:7AEB:1000:123A1800:0000:0000:7AEF:0000:0000:1072:43101800:0000:0000:7AEF:0000:0000:16.114.67.16

Compacted IPv6 Address:2080:0:0:0:90:7AEB:1000:123A Legal compaction2080::90:7AEB:1000:123A Legal compaction1800::7AEF:0:0:1072:4310 Legal compaction1800:0:0:7AEF::1072:4310 Legal compaction1800::7AEF::1072:4310 Illegal compaction

Compaction used twice!


IPv6 Address types

High order bits define IPv6 address type Current IPv6 prefix allocation

Special format addresses (00/8)(unspecified and loopback addresses)

Link-local unicast addresses (FE8/10) Site-local unicast addresses (FEC/10) Multicast addresses (FF/8) Aggregatable global unicast addresses (other) Anycast addresses are allocated from unicast

space


Aggregatable global unicast address

May be used to connect to public internet

Globally unique Based on topology Efficient routing Supports provider-based and

exchange-based aggregation


Internet hierarchy

ISP 1ISP 1

ISP 2ISP 2

ISP 3ISP 3

ISP 4ISP 4IX1 IX2

S1S1 P1P1S2S2

S3S3

P2P2

S4S4 S5S5

PublicPublic

SiteSite

ISP = Internet Service ProviderIX = Internet Exchange PointSn = Site nPm = Provider m

S6S6


Internet hierarchy explained

Currently 3 levels defined Public Site Interface

Both Public and Site topology can be further subdivided to create even more hierarchies


IPv6 Address format (RFC 2374)

FP = Format Prefix (= 001 for globally aggregated unicast addresses)

TLA-ID = Top-level aggreation identifierRES = Reserved for future useNLA = Next-level aggregation identifierSLA-ID = Site-level aggregation identifierInterface ID = Interface identifier

Interface-IDFP TLA-ID Res NLA-ID SLA-ID

≥3 ≤13 8 24 16 64

128 bit

Public TopologySite

Topology Interface Identifier

Network Portion Node Portion


Interface ID

Unique to the link Identifies interface on a specific link All except multicast addresses, must have

EUI-64 format MAC-to-EUI-64 conversion

1. First three octets of MAC becomes Company-ID2. Last three octets of MAC becomes Node-ID3. 0xFFFE is inserted between Company-ID and

Node-ID4. Universal/Local-Bit (U/L-bit) is set to 1 for

global scope


MAC-to-EUI-64 conversion example

MAC Address: 0000:0B0A:2D51 In binary:

00000000 00000000 00001011 00001010 00101101 01010001

U/L Bit

Company-ID Individual Node-ID

Insert FFFE between Company-ID and Node-ID00000000 00000000 00001011 11111111 11111110 00001010 00101101 01010001

Set U/L bit to 100000010 00000000 00001011 11111111 11111110 00001010 00101101 01010001

Resulting EUI-64 Address: 0200:0BFF:FE0A:2D51

U/L Bit

= FFFE


Special-format addresses (FP=0x00) Unspecified address

Format: 0:0:0:0:0:0:0:0 (all zeros) MUST NEVER be assigned to any node Represents absence of an address MUST NEVER be used as destination

address in IPv6 packets nor in IPv6 routing headers

Used for host initialization (i.e. autoconfiguration)


Special-format addresses (FP=0x00) Loopback address

Format: 0:0:0:0:0:0:0:1 Analogous to IPv4 loopback 127.0.0.1 Can NEVER be assigned to any

physical interface Used by nodes to send packets to

themselves Traffic destined to loopback address

MUST NEVER leave the sending node


Special-format addresses (FP=0x00) IPv6 with embedded IPv4 addresses

Format: ::a.a.a.a Used for dual-stack nodes with v4 and v6

IPv6 address assignment is based on v4 address

Used for automatic tunnels IPv6 automatically encapsulated over IPv4

This transition approach is not currently recommended (has been replaced by other approaches)


Local-use addresses -Link-local address (FP=FE8/10)

Local significance only Meaningful only to nodes on a single link

within a single site NOT globally unique Unique only within respective scope Used for autoconfiguration, neighbor

discovery, nodes on routerless links, routing protocols

Routers MUST NOT forward packets with either source or destination link-local addresses beyond that link


Link-local address format

ExamplesFE80:0000:0000:5ABC:01FF:FE01:1111

FE80::0060:08FF:FEB1:7EA2

FE80::200:CFF:FE0A:2C51

Interface-ID1111111010 0

10 54 64

128 bit


Local-use addresses - Site-local address (FP=FEC/10)

To be used within a site only NOT globally unique Recommended for router interfaces NOT to be propagated beyond site

boundaries Network configured with site-local

address is NOT reachable from locations OUTSIDE the site

Edge routers MUST keep site-local traffic within site


Site-local address format

Interface-ID1111111011 0

10 54 64

128 bit

Subnet-ID(SLA-ID)

16

ExamplesFEC0:0000:0000:5ABC:01FF:FE01:1111

FEC0::0060:08FF:FEB1:7EA2

FEC0::200:CFF:FE0A:2C51


Anycast Addresses

Used to address multiple interfaces on different nodes with SAME IPv6 address

Allocated from unicast address space Addresses are taken from Interface-ID

field Currently, only specified anycast

addresses are for subnet-router and for Mobile IPv6 home-agents


Subnet-router anycast address format

ExamplesSubnet-router anycast address: FEC0:0:0:A::

Resulting Unicast router address:FEC0:0:0:A:200:CFF:FE0A:2C51

00000000000000000Subnet Prefix

n Bits 128-n Bits

128 bit

SubnetFEC0:0:0:A::

Interface-ID200:CFF:FE0A:2C51

Interface-ID200:CFF:FE0C:4A72


Multicast Addresses

Always begin with 0xFF Two types

Well-known – assigned by an official authority Transient – locally assigned for non-global use

Multicast addresses are scoped Currently 5 scope levels defined:

Local to the node (scope = 1, node-local) Local to the link (scope = 2, link-local) Local to the site (scope = 5, site-local) Local to the organization (scope = 8) Global (scope = E) Reserved (scope = 0 and scope = F)


Multicast address format

Group-ID11111111 flgs

8 4 112

128 bit

scope

4

First 3 bits set to 0Last bit defines address type:0 = Permanent (or well-known)1 = Locally assigned (or transient)

Defines address scope0 Reserved1 Node-local scope2 Link-local scope5 Site-local scope8 Organization local scopeE Global scopeF Reserved


IPv6 Well-known multicast addresses

IPv6 Well-known multicast address

IPv4 Well-known multicast address

Multicast Group

Node-local scope

FF01:0:0:0:0:0:0:1 224.0.0.1 All-nodes address

FF01:0:0:0:0:0:0:2 224.0.0.2 All-routers address

Link-local scope

FF02:0:0:0:0:0:0:1 224.0.0.1 All-nodes address


FF02:0:0:0:0:0:0:5 224.0.0.5 OSPFIGP

FF02:0:0:0:0:0:0:6 224.0.0.6 OSPFIGP-DR‘s

FF02:0:0:0:0:0:0:9 224.0.0.9 RIP routers

FF02:0:0:0:0:0:0:D 224.0.0.13 All PIM routers

Site-local scope


Any valid scope

FF0X:0:0:0:0:0:0:101 224.0.1.1 Network time protocol NTP


Required IPv6 addresses for nodes

Link-local address for each interface All assigned unicast addresses Loopback address All-nodes multicast addresses Solicited-node multicast address for each of

its assigned unicast and anycast addresses Multicast addresses of all other groups to

which the host belongs

A host is required to recognize the following addresses:


Required IPv6 addresses for routers

Subnet-router anycast address for each of its routing interfaces

All other anycast addresses configured on the router

All-routers multicast address Multicast addresses of all other groups to

which the router belongs

In addition to the host address requirements a router is required to recognize the following addresses:


Multi-Homing

Multi-Homed domains are common Are a “challenge” for topological addressing

IPv6 requires hosts and DNS to deal with multiple addresses for a host <draft-ietf-ipngwg-default-addr-select-06.txt>

is a proposal for how hosts select addresses to use for any particular communication

This provides one possible solution An alternative: Exchange-based addresses More work is needed in this area





IPv4 vs. IPv6 Header formats

Ver.6

Ver.6

Traffic class8 bits

Traffic class8 bits

Flow label20 bits

Flow label20 bits

Payload Length16 bits

Payload Length16 bits

Next Hdr.8 bits

Next Hdr.8 bits

Hop Limit8 bits

Hop Limit8 bits

Source Address128 bits

Source Address128 bits

Destination Address128 bits

Destination Address128 bits

32 bits

Ver.4

Ver.4 HLHL Datagram LengthDatagram LengthTOS

Datagram-IDDatagram-ID FlagsFlags Flag OffsetFlag Offset

TTLTTL ProtocolProtocol Header ChecksumHeader Checksum

Source IP AddressSource IP Address

Destination IP AddressDestination IP Address

IP Options (with padding if necessary)IP Options (with padding if necessary)

32 bits

IPv4 header

IPv6 header

TOSTOS


“Missing” Fields from IPv4

Options Moved to be separate headers (discussed

later) Fragmentation fields

MTU discovery is a better approach For translation, is available in optional

header Checksum

Redundant with layer 2 CRC Length fields simplified

No fragmentation, no options





Benefits of IPv6 extension headers

IPv4 options drawbacks IPv4 options required special treatment in routers Options had negative impact on forwarding performance Therefore rarely used

Benefits of IPv6 extension headers Extension headers are external to IPv6 header Routers do not look at these options except for Hop-by-

hop options No negative impact on router‘s forwarding performance Easy to extend with new headers and option


IPv6 extension headers

IPv6 headerNH=TCP

TCP header + data

Routing headerNH=TCP

IPv6 headerNH=Routing

IPv6 headerNH=Routing

Routing headerNH=Fragment

Fragment headerNH=TCP

TCP header + data

TCP header + data


IPv6 extension headers

Header Previous header‘s NH-

value

Hop-by-hop options 0

Destination options 60

Routing 43

Fragment 44

Authentication 51

Encapsulating Security Payload

(ESP)

50

Destination options 60

OSPF for IPv6 89


IPv6 extension header processing

Extension headers are NOT examined or processed by any node along a packet’s delivery path

ONLY hop-by-hop extension header is processed by every node along a packet's delivery path (including source and destination)

Hop-by-hop header (if present) must immediately follow IPv6 header

Extension headers are processed strictly in order they appear in the packet


IPv6 extension header orders

RFC 2460 recommends following order:

1. IPv6 header2. Hop-by-hop options header3. Destination options header4. Routing header5. Fragment header6. Authentication header7. ESP header8. Destination options header9. Upper-layer header


Currently available IPv6 options

Hop-by-hop Must be processed by every node on the packet‘s

path Must always appear immediately after IPv6

header Two Hop-by-hop options already defined:

1. Router alert option2. Jumbo payload option

Destination Meant to carry information intended to be

examined by the destination node Only options currently defined are padding

options to fill out header on a 64-bit boundary if (future) options require it


Routing header

Next header value: 43 Provides "source-routing" functionality Format:

Next header Hdr. Ext. Len Routing TypeSegments left

Type-specific data

32 bits


Fragment header

Next header value: 44 Used to provide datagram fragmentation Format:

Next header Reserved Fragment offset Res

Identification

M

32 bits


Authentication

Next header value: 51 Provides data integrity and

authentication Format:

Next header Payload Len. RESERVED

Authentication data

Security Parameters Index (SPI)

Sequence Number Field

32 bits


Encapsulating Security Payload (ESP)

Next header value: 50 Provides confidentiality, data origin

authentication, connectionless integrity, and anti-replay service

Format:

Authentication data

Sequence Number

Payload data

32 bits

Security Parameters Index (SPI)

Pad length Next header

Payload data Padding

Padding





ICMPv6 Messages

Destination unreachable Packet too big Time exceeded Parameter problem Echo request Echo reply


ICMPv6: Destination Unreachable

Code 0 - no route to destination1 - communication with destination

administratively prohibited2 - (not assigned)3 - address unreachable4 - port unreachable

Type=1 Code Checksum

As much of invoking packetas will fit without the ICMPv6 packet

exceeding the minimum IPv6 MTU

32 bits

Unused

Unused This field is unused for all code values. It must be initialized to zero by the sender and ignored by the receiver.

IPv6 HeaderDestination Address:Copied from the Source Address field of the invoking packet.


ICMPv6: Packet too big

Code Set to 0 by the sender and ignored by the receiverMTU The maximum transmission unit of the next-hop link




32 bits

MTU



ICMPv6: Time exceeded

Code 0 – Hop limit exceeded in transit1 – Fragment reassembly time

exceeded




32 bits

Unused

Unused This field is unused for all code values. It must be initialized to zero by the sender and ignored by the receiver.



ICMPv6: Parameter problem

Code 0 - erroneous header field encountered 1 - unrecognized Next Header type

encountered 2 - unrecognized IPv6 option encountered




32 bits

Pointer

Pointer Identifies the octet offset within the invoking packet where the error was detected. The pointer will point beyond the end of the ICMPv6 packet if the field in error is beyond what can fit in the maximum size of an ICMPv6 error message.



ICMPv6: Echo request

Code 0Identifier An identifier to aid in matching Echo Replies to this Echo Request.

May be zero.Sequence Number A sequence number to aid in matching Echo

Replies to this Echo Request. May be zero.Data Zero or more octets of arbitrary data.

Type=128 Code=0 Checksum

Data

32 bits

Identifier Sequence Number

IPv6 HeaderDestination Address:Any legal IPv6 address.


ICMPv6: Echo reply

Code 0Identifier The identifier from the invoking Echo Request message. Sequence Number The sequence number from the invoking Echo

Request messageData The data from the invoking Echo Request message.

Type=129 Code=0 Checksum

Data

32 bits

Identifier Sequence Number

IPv6 HeaderDestination Address:Copied from the Source Address field of the invoking Echo Request packet.





Neighbor discovery

Provides functionality for Serverless autoconfiguration Router discovery Prefix discovery Address resolution Neighbor unreachability detection Link MTU discovery Next-hop determination Duplicate address detection


Neighbor discovery

Defines five ICMPv6 packets1. Router solicitation (RS)2. Router advertisement (RA)3. Neighbor solicitation (NS)4. Neighbor advertisement (NA)5. Redirect


Router solicitation (RS)

ICMP packet type 133 Sent by host to speed up learning of link-

local routers Source address is sending host‘s address or 0:0:0:0:0:0:0:0

Destination address is typically all-routers multicast address: FF02::2

May contain sender‘s link layer address (only if source address is not unspecified)

Reply is a Router Advertisement (RA)


Router solicitation (RS) format


Reserved

32 bits

Options....


Router advertisement (RA)

ICMP packet type 134 Sent by routers periodically or in response to a

solicitation to provide information necessary for a node to configure itself

Source address is link-local address of the sending router

Destination address is either unicast address of a node that sent an RS, or link-scope all-nodes multicast address: FF02::1

Hop-limit MUST be set to 255 Possible options contained in RA:

Source link layer address of the router MTU Prefix information about on-link prefixes


Router advertisement (RA) format


Reachable Time

32 bits

Cur. Hop LimitM OReserved Router lifetime

Retransmit Timer

Options....


Neighbor discovery:Router solicitation

A

B

C

D

E

F G

Default GW-ListA

BC

RS

RA


Neighbor discovery:Router advertisement

A

B

C

D

E

F G

Default GW-ListA

RA


Neighbor solicitation (NS)

ICMP packet type 135 Used to provide/obtain link-layer address to/of a

neighbor Used to verify neighbor reachability Source-address is link-local address of soliciting

node Destination-address is either

solicited-node multicast address associated with target IP address (link layer determination)

Unicast address of the target (reachability verification) Hop-limit MUST be set to 255 Reply is a Neighbor advertisement (NA)


Neighbor solicitation (NS) format


Reserved

32 bits

Target address

Options....


Neighbor advertisement (NA)

ICMP packet type 136 Sent in response to NS or unsolicited to

immediately propagate new information Source address is any valid unicast address

assigned to sending node Destination address is

For solicited advertisements Source address of the solicitation If solicitations‘s address is unspecified: all-nodes

multicast address For unsolicited advertisements

All-nodes multicast Hop-limit MUST be set to 255


Neighbor advertisement (NA) format


Reserved

32 bits

Target address

Options....

R S O


Redirect


Reserved

32 bits

Target address

Options....

Destination address


Redirect

A

B

C

D

E

F G

Default GW-ListA

BC

ICMP Redirect to Router B

Path used with Default Gateway "A"

Host 3

Sent data to Host 3 using Default GW "A"

Redirect traffic via Router B


Next-hop discovery

Check neighbor cache for existing next-hop entry for particular destination

Check whether destination is on- or off-link

On-link: Sent directly to destination Off-link: Sent to default router Identify link-layer address of next-hop


Address resolution

Uses Neighbor solicitation & advertisements Node checks neighbor cache first If no entry exists, node creates IP entry with

state INCOMPLETE Node then sends NS to solicited-node

multicast address Source address of NS is a unicast address Receiving node responds with NA indicating

it‘s own link-level address Soliciting node updates neighbor cache

entry from INCOMPLETE to REACHABLE upon receiption of NA


Neighbor unreachability detection

2 ways to verify neighbor reachability: Using hints from upper-layer protocols From responses to neighbor solicitations

Forward direction communication (FDC) must be possible for a neighbor to be REACHABLE

FDC is verified if forward progress is being made by an upper-layer protocol (i.e. TCP, receiption of TCP acks)



If no verification can be received from upper-layer protocols (like UDP): Node actively probes neighbors to

determine reachability state Probes are sent in conjunction with

traffic. No traffic, no probes! Probe is neighbor solicitation (NS) Neighbor advertisement (NA) reply is

expected to establish FDC



Neighbor cache stores information about neighbors IP address Link-layer address Reachability state

Neighbor reachability states INCOMPLETE REACHABLE STALE DELAY PROBE


Default router selection

Uses default router list and neighbor cache Host chooses one router from it‘s default

router list, if destination is off-link AND no cache entry exists for

the destinationOR Exisiting default router appears to be failing

Default router is chosen the first time traffic is sent to an off-link destination

REACHABLE routers have preference If multiple reachable routers exist, selection

process depends on vendor‘s implementation


Duplicate address detection

Must be performed by all nodes Performed before assigning a unicast

address to an interface Performed on interface initialization Not performed for anycast addresses Link must be multicast capable New address is called "tentative" as

long as duplicate address detection takes place



1. Interface joins all-nodes multicast group

2. Interface joins solicited-node multicast group

3. Node sends (one) NS with Target address = tentative IP address Source address = unspecified (::) Destination address = tentative

solicited-node address



If address already exists, the particular node sends a NA reply with Target address = tentative IP address Destination address = tentative solicited-

node address If soliciting node receives NA reply

with target address set to the tentative IP address, the address must be duplicate





Stateless Autoconfiguration

Router Advertisements are used to configure hosts

M-bit set to 0 tells host to use stateless address autoconfiguration

O-bit set to 0 tells host to use stateless autoconfiguration for other parameters


Stateless autoconfiguration process

1. Node initialization2. Node creates link-local address3. Node runs duplicate address detection process

If process fails, autoconfiguration fails. Manual configuration required.

4. Host (not routers) sends an all-routers multicast solicitation to find a router on the link

5. A router responds to the RS with router advertisement

6. Host uses information contained in RA to: Create site-local address Build an on-link prefix-list Know the link MTU


Stateful Autoconfiguration

Router Advertisements are used to configure hosts

M-bit set to 1 tells host to use stateful address autoconfiguration (like DHCPv6)

O-bit set to 1 tells host to use stateful autoconfiguration for other parameters (like DNS)





MTU path discovery

Minimum MTU for IPv6: 1280 bytes Recommended MTU: 1500 bytes Nodes should implement MTU PD Otherwise they must use minimum

MTU MTU path discovery works for unicast

& multicast MTU path discovery uses ICMP

"packet too big" error messages


Static Routes

[edit routing-options]ps@R1# show rib inet6.0 { static { route abcd::/48 next-hop 8:3::1; }}


RIPng

RFC 2080 describes RIPngv1, not to be confused with RIPv1

Based on RIP Version 2 (RIPv2) Uses UDP port 521 Operational procedures, timers and stability

functions remain unchanged Message format changed to carry larger

IPv6 addresses RIPng is not backward compatible to RIPv2


Multiprocotol BGP-4

Two new attributes support multiprotocol BGP-4 (aka BGP+) Multiprotocol reachable NLRI (MP_REACH_NLRI) Multiprotocol unreachable NLRI (MP_UNREACH_NLRI)

MBGP extensions use for IPv6 is described in RFC 2545 MP_REACH_NLRI attribute describes reachable

destinations Attribute contains information about

Network layer protocol (i.e. IPv6) Prefixes Next-hop to reach prefixes

MP_REACH_NLRI updates include One next-hop address List of associated NLRI‘s

Follows BGP-4 rules for next-hop attribute IPv6 BGP routers advertise global address of NH-router


IS-IS

draft-ietf-isis-ipv6-02.txt, Routing IPv6 with IS-IS

2 new TLVs are defined: IPv6 Reachability (TLV type 236) IPv6 Interface Address (TLV type 232) Otherwise, uses same packet formats (!)

IPv6 NLPID = 142


OSPFv3

Unlike IS-IS, new version required RFC 2740 Fundamental OSPF mechanisms and

algorithms unchanged Packet and LSA formats are different


OSPFv3 Differences from OSPFv2

Runs per-link rather than per-subnet Multiple instances on a single link More flexible handling of unknown LSA types Link-local flooding scope added

Similar to flooding scope of type 9 Opaque LSAs Area and AS flooding remain unchanged

Authentication removed Neighboring routers always identified by RID Removal of addressing semantics

IPv6 addresses not present in most OSPF packets RIDs, AIDs, and LSA IDs remain 32 bits


OSPFv3 LSAs

Type Description0x2001 Router-LSA

0x2002 Network-LSA

0x2003 Inter-Area-Prefix-LSA

0x2004 Inter-Area-Router-LSA

0x2005 AS-External-LSA

0x2006 Group-Membership-LSA

0x2007 Type-7-LSA (NSSA)

0x2008 Link-LSA

0x2009 Inter-Area-Prefix-LSA





IPv6 Flow Label

20-bit field to indicate individual flows Scope is per source/destination address

pair This is a major change to current IP

use Is it useful?

In the core, probably not Closer to the edge, or for BIG flows,

maybe This is primarily an economic issue

(do the benefits justify the cost?)

Agenda




Transition is expected to take many years IPv4 address exhaustion: 2005 and beyond

IPv4 will not disappear anytime soon IPv4 is deployed on an enormous scale Protocols die very slowly, if at all

Transition enablers Vendors must provide comparable features,

functionality, robustness, performance,… … at all levels (routers to application) Customers must drive the transition

Transition Overview


Lessons from History

IP is not first protocol to transition There have been “issues” during

previous transitions, example: New name service assumes unique

addresses (huge address, clever admin.) Protocol translation, with address

translation between old and new format Users had deployed local addresses Subtle contradiction big problem

Interactions between mechanisms are key


Interaction of Transition Mechanisms

draft-ietf-ngtrans-interation-00.txt discusses interactions between mechanisms Limited to two-way interactions

(between 16 mechanisms) Does not discuss routing aspects Does not discuss security aspects Limited discussion of effect of translation

There are very good reasons for these omissions (it is just too hard)


Myriad proposals Coexistence

Dual IP stacks All network devices run both IPv4 and IPv6 stacks

Dual IP layers TCP/UDP layer is shared

"Bump In the Stack" (BIS) IPv6 modules in IPv4 implementations

Tunneling Configured tunnels Automatic tunnels 6 to 4 tunnels 6 over 4 tunnels

Translation SIIT – Stateless IP/ICMP Translator NAT-Protocol Translation (NAT-PT)

Transition Mechanisms


Dual Stack Transition, Basic Method

Routers & DNS are updated to support dual stack (v4 and v6)

Hosts are then updated gradually to be dual Use v6 if policy and both ends support it Otherwise use v4 DNS used to determine capability of other

end Tunneling may be used with this approach Eventually v4 is phased out

This is included in RFC 2893 “Transition Mechanisms for IPv6 Hosts and Routers” (originally proposed in RFC 1347)


“Dual Stack Transition Mechanism”

<draft-ietf-ngtrans-dstm-07.txt> proposes additional functions No native V4 routing, tunnel over v6 instead Temporary v4 address assigned to v6 host,

only when they want to talk to older v4 host May assign range of ports, reuse address Address servers and tunnel gateways (TEPs)

This is said to be a simplification (??) The jury is still out on this one


Configured tunnels Connects IPv6 hosts or networks over an existing IPv4

infrastructure Generally used between sites exchanging traffic regularly Static tunnels configured on point-to-point basis Examples: CCC, MPLS, GRE, IP-IP, IPSec

Automatic tunnels Tunnel is created then removed after use Requires IPv4 compatible addresses

6 to 4 – dynamically established Desirable as no explicit tunnel configuration required

6 over 4 - dynamically established Assumes IPv4 transit network is multicast enabled

Tunnel broker IPv6 hosts request v6 tunnel; obtain script to build tunnel

Tunneling


6 to 4 Tunneling

IPv6/Dual IPv6/Dual NetworkNetwork

6to4 Router

Adds v4 header

IPv6/Dual IPv6/Dual NetworkNetwork IPv4 CoreIPv4 Core

IPv6 Packet

Connects isolated IPv6 domains over an IPv4 infrastructure

Minimal manual configuration Uses globally unique prefix comprised of the unique

6 to 4 TLA and the globally unique IPv4 address of the exit router

Expected to ease initial transition

IPv4 PE Router

Forwards as Usual

Destination 6to4 router removes IPv4 header DeliveryGeneration


Translation

Multiple forms of translation: Between semantically identical

protocols Not applicable in this case (nor most)

Semantic Dual-Stack (SIIT, RFC 2765) Application needs to be dual stack No meaningful gain over pure dual-stack

NAT-PT Same packet translation as SIIT Different semantics (see following slides)


Network Address Translation -- Protocol Translation (NAT-PT)

Semantically similar to (v4-to-v4) NAT v6-only hosts need to connect to v4 world DNS servers dynamically assign addresses

from pool of global IPv4 addresses IP headers and addresses in applications

are translated at NAT boxes NAT box must maintain state

Address mappings, TCP sequence number change, Data Unit ID, reassembly, etc..


NAT-PT, continued

Translation for any one session must take place at the same NAT-PT router Restricted topology NAT-PT is, like NAT, local to a domain This makes routing straightforward

Security is limited (end to end can’t be translated, also no secure DNS)

NAPT-PT extends maps TCP/UDP port #s (multiple v6 sessions use one v4 address)


Transition Lessons from the Past

KEEP TRANSITION SIMPLE Limit scope and interaction of

mechanisms Beware of semantic interdependence Make sure normal humans can fully

understand the interactions and implications of all mechanisms

Transition/Migration is THE hard part Ensuring existing products do IPv6 well Keeping transition mechanisms under

control


Key Factors to a Successful Transition

No "Flag Day" transitions! Last Internet transition was 1983 (NCP

TCP) Maintain full IPv4/IPv6 dual access Minimize transition dependencies

Don't upgrade node X before node Y Must be incremental Must be easy for end user

Transition from IPv4 to dual stack must not break anything


Example Site Migration

1. Upgrade applications to be v4/v6 independent

2. Install transition mechanisms at domain edge (Tunnels, Translators)

3. Upgrade routing for native IPv64. Upgrade DNS to support IPv65. Upgrade hosts to dual stack6. Convert hosts to IPv6-only (much

later)


Example of Dual-Server Transition

Client-server model is common Clients talk to servers Servers talk to other servers

Install dual-stack Routers and servers (Including DNS, Email, and WWW servers) Communications between servers can use

IPv4 or IPv6 Single-protocol clients contact

servers using either protocol (v4 or v6)


Transition Security Risks

Many transition technologies may open security risks such as DoS attacks

Automated interactions open security holes

Details aren’t fully understood Packet and route filters, DOS protection needs

to be extended to transition techniques Authentication is needed where applicable Translation and authentication may be at odds

Agenda




Phase DetailsPlatform, Interface Support

IPv6 Support Across All Platforms, Interfaces

Category Feature Phase Related RFC

Media Support

Ethernet P1 RFC 2464

PPP P1 RFC 2472

NBMA P1 RFC 2491

ATM (all encapsulations)

P1 RFC 2492

Frame Relay P1 RFC 2590


Phase DetailsFundamental Features


Forwarding

IPv6 forwarding (in hardware) P1 --

Addressing

IPv6 Address types P1 RFC 2373

Global unicast address aggregation P1 RFC 2373

:hex format with zero suppression P1 RFC 2373

DNS P1 RFC 2874

Stateless autoconfiguration P1 RFC 2462

Network prefix length notation P1 RFC 2373

Routing Static routes P1 --

RIPng P1 RFC 2080

IS-IS P1 --

BGP with v4 Peering P1 RFC 2283, 2545

BGP with v6 Peering P1 RFC 2283, 2545


Phase DetailsNeighbor Discovery


Neighbor Discovery(Router portion)

Router discovery P1 RFC 2461

Prefix discovery P1 RFC 2461

Parameter discovery P1 RFC 2461

Address autoconfiguration P1 RFC 2461

Address resolution P1 RFC 2461

Next-hop determination P1 RFC 2461


P1 RFC 2461

Duplicate address detection P1 RFC 2461Note: Host portion for router in Next Phase (NP)


Phase DetailsManagement


ICMPv6 Destination unreachable P1 RFC 2463

Packet too big P1 RFC 2463

Time exceeded P1 RFC 2463

Parameter Problem P1 RFC 2463

Echo request/reply P1 RFC 2463

JUNOScript P1 --

Transition Dual stack P1 RFC 2767

Configured tunnels P1 RFC 2893


Phase DetailsApplications


Applications

Ping P1 --

Telnet P1 --

Traceroute P1 --

FTP P1 --

Netstat P1 --

TCPdump P1 --

SSH P1 --

ifinfo P1 --


Phase DetailsMPLS


MPLS L2 MPLS VPN/CCC P1 --


Phase DetailsOptions and Miscellaneous


OptionalHeaders

Hop-by-hop P1 RFC 2460

Path MTU Discovery

Host portion P1 RFC 1981

Router portion P1 RFC 1981

Multicast addresses (forwarding - NP)

P1/NP RFC 2373

Agenda




Selected IPv6 RFC’s RFC 1881 – IPv6 Address allocation management RFC 1886 – DNS Extensions to Support IPv6 RFC 1887 – IPv6 Unicast address allocation RFC 1924 – IPv6 Compact representation of IPv6 addresses RFC 1981 – Path MTU discovery for IPv6 RFC 2073 – An IPv6 Aggregatable Global Unicast Address Format RFC 2080 – RIPng for IPv6 RFC 2373 – IPv6 Addressing architecture RFC 2374 – IPv6 Global aggregatable unicast address format RFC 2375 – IPv6 Multicast address assignments RFC 2460 – Internet Protocol, Version 6 (IPv6) Specification RFC 2461 – Neigbhor discovery for IPv6 RFC 2462 – IPv6 Stateless Address Autoconfiguration RFC 2463 – Internet Control Message Protocol Version 6


Selected IPv6 RFC’s, continued RFC 2675 – IPv6 Jumbograms RFC 2711 – IPv6 Router alert option RFC 2740 – OSPF for IPv6 RFC 2765 – Stateless IP/ICMP Translation Algorithm (SIIT) RFC 2766 – Network Address Translation -- Protocol Translation

(NAT-PT) RFC 2767 – Dual Stack Hosts using the Bump-in-the-Stack

Technique (BIS) RFC 2772 – 6Bone Backbone Routing Guidelines RFC 2893 – Transition mechanisms for IPv6 hosts and routers RFC 3056 – Connection of IPv6 Domains via IPv4 Clouds


Selected IPv6 Internet Drafts Note: These will be updated over time <draft-ietf-ipngwg-icmp-v3-02.txt> <draft-ietf-ipngwg-addr-arch-v3-07.txt> <draft-ietf-ipngwg-scoping-arch-03.txt> <draft-ietf-ipv6-flow-label-01.txt> <draft-ietf-ngtrans-introduction-to-ipv6-transition-08.txt> <draft-ietf-ngtrans-bia-05.txt> <draft-ietf-ngtrans-6to4-dns-00.txt> <draft-ietf-ngtrans-interaction-00.txt> <draft-ietf-ipngwg-default-addr-select-06.txt> (or go to www.ietf.org; click on ‘IETF Working Groups‘, click on

ipv6 under the Internet area; also click on ngtrans under the Operations and Management area.)

Copyright © 2002 Juniper Networks, Inc. http://www.juniper.net

http://www.juniper.net

Thank you!

Documents

Copyright © 2002 Juniper Networks, Inc. Introduction to IPv6 Ross Callon Net 2002 Fredericton, New Brunswick