IPv6 Technology
www.spirentcampus.com Topics Overview
IPv6 Overview IPv6 Addressing IPv6 Header Structure ICMPv6 Overview Neighbor Discovery IPv4/IPv6 Transition IPv6 Routing Protocols
2 IPv6 Technology What is the significance of these?
0x86DD :: ::1 FE80::/10 FF00::/8 2000::/3 Protocol # 58 3.4x10^38 RFC 2460, 2461 (now 4861), 2462 (now 4862), 2463 (now 4443), 2464 Anycast CIDR MTU 1280
3 IPv6 Technology 10 things about an IPv6 address
21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A (vs. IPv4's 168.13.25.68) 1. It's an IPv6 address 2. It's a Global IP address (RFC 3587) 3. It has an implicit structure /64 4. You can assume its MAC address 5. You can assume it was a burnt in MAC address 6. You can assume the network hierarchy 7. It's not a multicast address 8. It's not a link-local address 9. It's not an IPv4 address (okay I am stretching to reach 10) 10. It's confusing
4 IPv6 Technology What is IPv6?
RFC 2460 [1998] plus many others Too many others; some obsolete; many updates IPv6 was designed to take an evolutionary step from IPv4 The changes from IPv4 to IPv6 fall primarily into the following categories: Expanded Routing and Addressing Capabilities Header Format Simplification Improved Support for Options Quality-of-Service Capabilities Authentication and Privacy Capabilities
5 IPv6 Technology What happened to IPv5?
RFC 1819 The Internet Stream Protocol (ST and ST+) IPv5 is the IP protocol number of the Stream Protocol (ST) It was the next number in line It was an experimental protocol but was never widely used It was to deal with non-IP real time protocol It was the address the resource reservation issue Designed to coexist with IPv4, not a replacement
6 IPv6 Technology IPv6 Benefits
A summary of the Benefits of IPv6 are as follows: Scalability IPv6 has 128-bit address space, which is 4 times wider in bits in compared to IPv4's 32-bit address space. Security IPv6 includes security in the basic specification. IPv6 includes a Flow Label to implement better support for real-time traffic. This enables a router to recognize to which flow the packets belong. IPv6 is Plug and Play. Therefore, it is easier for novice users to connect their machines to the network (i.e., it will be done automatically!). IPv6 follows good practices, and rejects flaws/obsolete items of IPv4. 7 IPv6 Technology Short History of IPv6 1990 – Prediction of the exhaustion of IPv4 Class B by 1994 1992 – Prediction of the exhaustion of the IPv4 addresses by 2005-2011 1993 – IPng proposals solicitation (RFC 1550) 1994 – CATNIP, SIPP, TUBA analyzed. SIPP+ chosen, IPng workgroup started 1995 – First specification (RFC 1883) 1996 – 6Bone started; began first production level IPv6 "Internet" 1997 – First attempt for provider-based address format 1998 – First IPv6 exchange (6tap) 1999 – Registries assign IPv6 prefixes. IPv6 Forum formed (100+ members) 2000 – Major vendors bundle IPv6 in their mainstream product line 2006 – 6Bone deactivated (June) 2011 - 3rd February 2011 is the day that IANA assigned the last five /8 blocks one to each RIR (Regional Internet Registry)
8 IPv6 Technology Where are we at with IPv6 Deployment?
http://bgp.he.net/ipv6-progress-report.cgi In a nut shell, no where and everywhere; but things are rapidly changing Percentage of sites using a different name for IPv6 (e.g., ipv6.google.com) Netherlands #1, USA 12%, Czech 18%, Japan China 2% Percentage of sites using the same name for IPv6 (e.g., www.kame.net) Netherlands 10%; Luxemburg, France, Portugal, USA 2% Google has made YouTube and other services available on IPv6 Facebook also began its IPv6 transition A whopping 84% of the 1500 organizations, from 140 countries, surveyed said they already had IPv6 addresses or were considering a requesting one European Funded Commission for IPv6 readiness found that just 25% of ISPs now offer the service to consumers. 10% of polled ISPs have no plans to offer IPv6 to consumers or businesses
9 IPv6 Technology Why not NAT?
NAT does not scale well: Compromises the performance, robustness, security, and manageability of the Internet Won’t work for large numbers of servers inside that need to be reachable from outside Inhibits deployment of new applications and services Breaks the "Golden Rule" (i.e., don't modify data between clients)
10 IPv6 Technology Global Reachability
IPv6 Internet
Larger address space enables: . A globally reachable address for everything. . End-to-end reachability, full support of application protocols, end-to-end security.
11 IPv6 Technology Built-in Security via IPSec
IPv6 Internet
Security means: . End-to-end network security (integrity, authentication, confidentiality) Built-in on IPv6 . Means any node can use it for all conversations . Unlike ARP, Neighbor Discovery using ICMPv6 is native IP IPSec relies on the IP Authentication Header (see RFC 2402) and the IP Encapsulating Security Payload (see RFC 2406) to ensure integrity and authentication/confidentiality (RFC 2401)
12 IPv6 Technology IPv6 vs. IPv4
Larger Address Space Fixed Length Header Efficient Hierarchical Addressing Implicit Address Structure Built-in Autoconfiguration Built-in Security (IPSec) Alternate Support For QoS 1280 Byte MTU by Default
13 IPv6 Technology Topics Overview
IPv6 Overview IPv6 Addressing IPv6 Header Structure ICMPv6 Overview Neighbor Discovery IPv4/IPv6 Transition IPv6 Routing Protocols
14 IPv6 Technology IPv6 Addressing
IPv4 (32-bit) IPv6 (128-bit)
4.29 Billion 3.4 X 1038
340 undecillion addresses where an undecillion is a billion billion billion billion or 665 Sextillion addresses per m2 of Earth’s surface!
15 IPv6 Technology How Big is a Sextillion?
1 billion, trillion
16 IPv6 Technology IPv6 Address Space
128-bits of address space
0010000111011010000000001101001100000000000000000010111100111011 0000001010101010000000001111111111111110001010001001110001011010
Divided into 8 double-octet fields or blocks of 16-bits each
0010000111011010 0000000011010011 0000000000000000 0010111100111011 0000001010101010 0000000011111111 1111111000101000 1001110001011010
IPv6 Technology IPv6 Address Syntax
From RFC 4291 IPv6 Addressing Architecture obsoletes RFC 3513 which obsoleted RFC 2373 Each 16 bit block is converted to hexadecimal and delimited with colons “:” The resulting representation is called “colon hexadecimal” 21DA : 00D3 : 0000 : 2F3B : 02AA : 00FF : FE28 : 9C5A
18 IPv6 Technology Example Collection Of IPv6 Addresses 33:33:FF:02:6E:A5 (this is actually a MAC address) ::ffff:cb0a:3cdd or ::wwxx:yyzz or ::w.x.y.z fc01:3db6:134a:4bb:1217:f2ff:fec9:1b10 2001:388:1000:4000:217:f2ff:fec9:1b10 3ffe:3700:1100:1:210:a4ff:fea0:bc97 any_64_bit_prefix::0:5EFE:w.x.y.z fe80::20e:7fff:feac:d687 2002:cb0a:3cdd:1::1 ff02::1:FFF3:C4A2 2001:0000:/32 ff00::/8 0200:/3 ::1 :: 19 IPv6 Technology Removing and Compressing Zeros
Leading zeros may be removed within each block
21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A Becomes:
21DA:D3:0:2F3B:2AA:FF:FE28:9C5A
Successive 16-bit blocks of zeros may be simplified by using a double-colon “::” FF02:0:0:0:0:0:0:2 Is equal to: FF02::2
20 IPv6 Technology Compressing Zeros: Limitations
You cannot truncate “trailing” zeros when removing zeros or using double colons.
FF02:30:04A0:0:0:0:0:5
Can NOT be expressed as: FF02:3:4A::5 o Zero compression can only be used once in a given address. FF02:30:0:0:07C0:0:0:5 Can NOT be expressed as: FF02:30::07C0::5
21 IPv6 Technology Compressing Zeros
To determine how many 0 bits are represented by the double-colon “::” Subtract the number of blocks left in the compressed address from 8 and then multiply by 16. Example: FF02::2
(8-2)X16 = 96
96 “0” bits represented by the double colon in this address
22 IPv6 Technology IPv6 Prefixes Indicates the "routable" portion of the address from your point in the network hierarchy IPv6 address prefix notation is the same as IPv4 address prefixes are written in Classless Inter-Domain Routing (CIDR) notation An IPv6 address prefix is represented by the notation: ipv6-address/prefix-length Example: A 60-bit prefix (0x12AB00000000CD3) can be written as: 12AB:0000:0000:CD30::/60 (don’t forget “trailing” zero) 12AB::CD30:0:0:0:0/60 (only one double-colon) 12AB:0:0:CD30::/60 (only one double-colon) When writing both a node address and a prefix of that node address (e.g., the node's subnet prefix), the two can be combined: if the node address is 2001:0DB8:0:CD30:123:4567:89AB:CDEF and its subnet number is 2001:0DB8:0:CD30::/60 it can be written as 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60 NOTE: Dotted decimal subnet masks are NOT used in IPv6
23 IPv6 Technology IPv6 Prefix Example
21DA:D3::/48 is a route Prefix
21DA:D3:0:2F3B::/64 is a subnet Prefix
21DA:D3:0:2F3B::1/128 is a host Prefix
24 IPv6 Technology Implied Network Prefix
Half the address space for networks (/64 implied prefix) Half the address space for host services (Interface ID)
25 IPv6 Technology IPv6 Address Types
Unicast Special Addresses Scoped Addresses Aggregatable Global Unicast addresses Multicast Solicited Node Address Anycast “Nearest” device or router Broadcast eliminated in IPv6!!!
IPv6 addresses of all types are assigned to interfaces, not nodes.
26 IPv6 Technology IPv6 Unicast address
27 IPv6 Technology RFC 2450 Interim Rules
FP set to 001 for unicast TLA ID set to 0x0001 for addresses allocated under RFC 2450 Therefore, initially many addresses will start with 2001
FP TLA ID SUB-TLA NLA-ID 3 13 13 19 001 0 0000 0000 0001 20 01
28 IPv6 Technology IPv6 Unicast address per RFC 3587
Aggregatable Unicast Addresses Are: Addresses for generic use in IPv6 Structured as a hierarchy to keep aggregation to a maximum
29 IPv6 Technology IPv6 Unicast address Interface ID From RFC 4291; for all unicast addresses starting with binary 001, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format Start with the EUI-48 address (e.g., Ethernet address), insert FF:FE in the middle and invert the "U" bit
IPv6 Technology MAC Address Format
An EUI-48 address field shall be 48 bits in length. The most significant 3 bytes are the OUI (Organizational Unique Identifier) or Vendor ID The least significant 3 bytes are assigned by the Vendor.
U I ______L G_
U/L & I/G bits
Vendor ID Vendor Assigned
31 IPv6 Technology An IPv6 Host Has…
Unicast addresses: A link-local address for each interface Possibility other unicast/anycast address(es) for each interface A loopback address (::1) Multicast addresses: The node-local scope all-nodes multicast address (FF01::1) The link-local scope all-nodes multicast address (FF02::1) The solicited-node address for each unicast address The multicast addresses of joined groups
32 IPv6 Technology An IPv6 Router Has…
Unicast addresses: A link-local address for each interface Unicast address(es) for each interface Loopback address (::1) Anycast addresses Subnet-router anycast address for all interfaces for which it is configured to act as a router Multicast addresses: The node-local scope all-nodes multicast address (FF01::1) The node-local scope all-routers multicast address (FF01::2) The link-local scope all-nodes multicast address (FF02::1) The link-local scope all-routers multicast address (FF02::2) The site-local scope all-routers multicast address (FF05::2) The solicited-node address for each unicast address The multicast addresses of joined groups
33 IPv6 Technology Internet Assigned Numbers Authority (IANA)
34 IPv6 Technology IANA and RIR Described Internet Assigned Numbers Authority (IANA) is responsible for the global coordination of the DNS Root, IP addressing, and other Internet protocol resources. IANA allocates addresses to each Regional Internet Registries (RIR). The RIR is responsible for the next level of allocation to large regional entities including Internet Service Providers (ISPs), educational institutions, government bodies, and large private enterprises. Some regions also have National Internet Registries (NIRs) that work with the RIR to provide resources in their countries. RIR policies generally set minimum criteria for networks that need Internet number resources. If your network does not meet those criteria, you should approach an upstream provider, also known as a Local Internet Registry (LIR) or Internet Service Provider (ISP).
35 IPv6 Technology Regional Internet Registries (RIR)
AfriNIC - The Internet Numbers Registry for Africa Africa, portions of the Indian Ocean APNIC - Asia Pacific Network Information Centre Portions of Asia, portions of Oceania ARIN - American Regristry for Internet Numbers Canada, many Caribbean and North Atlantic islands, and the United States LACNIC - Latin America and Caribbean Network Information Centre Latin America, portions of the Caribbean RIPE - Réseaux IP Européens French for "European IP Networks" Europe, the Middle East, Central Asia
36 IPv6 Technology IPv4 Exhaustion Counter as of March 26, 2011 INTEC Systems Institute, Inc. provides a blogpart version of "IPv4 Exhaustion Counter" that visualize the status of IPv4 address exhaustion. It is mashed up with the "IANA IPv4 Address Space Registry" provided by IANA and "IPv4 Address Report" researched by Mr. Geoff Huston of APNIC.
http://inetcore.com/project/ipv4ec/index_en.html 37 IPv6 Technology IPv6 Address Allocation
Unassigned 0000 0000 1/256 Unassigned 0000 0001 1/256 Reserved for NSAP Allocation 0000 001 1/128 [RFC 4548] Unassigned 0000 01 1/64 Unassigned 0000 1 1/32 Unassigned 0001 1/16 Global Unicast 001 1/8 [was RFC 2374 now RFC 3587] Unassigned 010 1/8 Unassigned 011 1/8 Unassigned 100 1/8 Unassigned 101 1/8 Unassigned 110 1/8 Unassigned 1110 1/16 Unassigned 1111 0 1/32 Unassigned 1111 10 1/64 Unique Local Adreess (ULA) 1111 110 1/128 [FC00::/7 RFC 4193] Unassigned 1111 1110 0 1/512 Link-Local Unicast Addresses 1111 1110 10 1/1024 [FE80::/10 RFC 4291] Site-Local Unicast Addresses 1111 1110 11 1/1024 [deprecated now RFC 4193] Multicast Addresses 1111 1111 1/256 [FF00::/8 RFC 4291]
38 IPv6 Technology Link-Local Unicast Address FE80::/10 FE80::/64 prefix FE80::
FE80::1:30FF:FEF3:C110 FE80::1:30FF:FEF3:C4A2
39 IPv6 Technology Site-Local Unicast address Deprecated
FEC0::/10 FEC0::23AD/48 prefix FEC0::
FEC0::23AD:1:30FF:FEF3:C110 FEC0::23AD:1:30FF:FEF3:C4A2
40 IPv6 Technology Unique Local Address FC00::/7
The address block defined in RFC 4193 They are supposed to be used for systems that are not connected to the Internet They are not routable in the global IPv6 Internet FC00::/8 is to be managed by the IANA for /48s in use FD00::/8 uses a randomly generated Global ID
41 IPv6 Technology Special Addresses
Unspecified (::) Used when no address is available . DHCPv6 requests . Duplicate Address Detection Loopback (::1) Identifies self Used to determine if your IPv6 stack works . ex: ping6 ::1
42 IPv6 Technology Multicast Use
Broadcasts in IPv4 Interrupts all computers on the LAN Can completely hang up a network (“broadcast storm”) Broadcasts in IPv6 Are not used and replaced by Multicast Multicast Enables the efficient use of the network Multicast address range is much larger
43 IPv6 Technology Global Multicast Format (All-???)
Flags Scope Defined multicast addresses All-Nodes addresses . FF01::1 (Node Local), FF02::1 (Link Local) All-Routers addresses . FF01::2 (Node Local), FF02::2 (Link Local), FF05::2 (Site Local)
8 bits 4 bits 4 bits 112 bits
1111 1111 Flags Scope Group ID
44 IPv6 Technology Multicast Address Format Prefix
The fields in the multicast address are: Format Prefix (FP) . Always FF for multicast Flags Scope Group ID
FP Flags Scope Group ID 1111 1111 8 4 4 112
45 IPv6 Technology Multicast Address Flags
The high-order flag is reserved, and must be initialized to 0 T = 0 indicates a permanently-assigned ("well-known") multicast address, assigned by the Internet Assigned Numbers Authority (IANA) T = 1 indicates a non-permanently-assigned ("transient" or "dynamically" assigned) multicast address. The P flag's definition and usage can be found in RFC3306 enables support for Unicast-Prefix-based IPv6 Multicast The R flag's definition and usage can be found in RFC3956 indicates whether or not the Address of the PIM RP is embedded in the Multicast Address
Flags FP Scope Group ID 0RPT 8 4 4 112
46 IPv6 Technology Multicast Address Scope
Routers use the scope field to determine whether multicast traffic should be forwarded.
0 reserved 8 Organization-Local scope 1 Interface-Local scope 9 (unassigned) 2 Link-Local scope A (unassigned) 3 reserved B (unassigned) 4 Admin-Local scope C (unassigned) 5 Site-Local scope D (unassigned) 6 (unassigned) E Global scope 7 (unassigned) F reserved
FP FlagsScope Group ID
8 4 4 112
47 IPv6 Technology Multicast Address Group ID The group ID identifies the multicast group, either permanent or transient, within the given scope. Definitions of the multicast group ID field structure are provided in RFC3306. Though 112 bits are available, RFC 4291 suggests only using the low-order 32 bits, thus preserving IPv6 - ETH address mapping outlined in RFC 2464
Multicast MAC - Address Mapping Per RFC 2464
33 33
8 Group ID Multicast IPv6 Address
Group ID FP Flags Scope Reserved Must Be Zero 8 4 4 80 32
48 IPv6 Technology Solicited Node Multicast Address (SNM)
The Solicited Node Multicast address is comprised of: The prefix FF02:0:0:0:0:1:FF00::/104, plus… …the last 24 bits of the Node’s IPv6 address . Therefore, only 1 in 16 million chance of any two nodes having the same SNM address; and that is per subnet! In the case of node B, its SNM address would be...
FF02::1:FFF3:C4A2
A B
2001::23AD:1:30FF:FEF3:C110 2001::23AD:1:30FF:FEF3:C4A2
49 IPv6 Technology SNM Address Usage
Nodes must compute and join a SNM address for EVERY unicast & anycast address it is assigned. Node B’s SNM address is FF02::1:FFF3:C4A2 Node B will “listen” for traffic to the multicast MAC corresponding to the SNM address (33:33:FF:F3:C4:A2) per RFC 2464. Node A’s neighbor solicitation will be addressed to these two addresses (Ethernet and IPv6). A B
2001::23AD:1:30FF:FEF3:C110 2001::23AD:1:30FF:FEF3:C4A2
50 IPv6 Technology Anycast Addresses
An identifier for a set of interfaces. A packet sent to an Anycast address is sent to the “nearest” one based on the routing protocols’ measure of distance. Routing Protocols advertise it as a “host” route Subnet - Router Anycast A pre-defined Anycast ID is currently specified is for Mobile IPv6 Home Agents RFC 2526
Which router will respond to the client?
51 IPv6 Technology Subnet-Router Anycast Address
Per RFC 4291, an Anycast address that identifies all routers on a subnet. Prefix is syntactically the same as the unicast addresses on the link. Interface ID is set to zero. All routers are required to support the Subnet-Router Anycast addresses for the subnets on which they have interfaces.
subnet prefix 00000000000000000000000 n bits 128 - n bits
52 IPv6 Technology Anycast Addresses – Possible Uses
To force routing through a specific ISP without having to know the particular router’s address. To find the nearest Home Agent (HA) for mobile IP services. DNS Services Redundant Application Servers
53 IPv6 Technology IPv4 vs. IPv6 Addresses
IPv4 Address IPv6 Address Globally unique IP addresses Global unicast addresses (unlimited?) Multicast addresses (224.0.0.0/4) IPv6 multicast addresses (FF00::/8) Broadcast addresses N/A Unspecified address is 0.0.0.0 Unspecified address is :: Loopback address is 127.0.0.1 Loopback address is ::1 Public IP addresses Aggregatable global unicast addresses Private IP addresses Unique-local addresses (FC00::/7) APIPA* addresses (169.254/16) Link-local addresses (FE80::/64) Dotted decimal notation Colon hexadecimal format Subnet mask or prefix length Prefix length notation only
*Automatic Private IP Addressing
54 IPv6 Technology Stateless Address Autoconfiguration (SLAAC)
Mac address: 00:2C:04:00:FE:56
Host auto-configured In its Router Advertisement address is: (RA), a router sends network- prefix received + link- type information (prefix, layer address default route, …)
Larger address space enables: . The use of link-layer addresses inside the address space. . Autoconfiguration with "no collisions". . Offers "Plug and play".
55 IPv6 Technology SLAAC Details
Only used by hosts. Since hosts use information sent in router advertisements, the routers must be configured by other means. The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable. The stateful approach is used when a site requires tighter control over exact address assignments. The site administrator specifies which type of auto- configuration to use through the setting of appropriate fields in Router Advertisement messages A host forms a link-local address by appending its interface identifier to the link-local prefix.
56 IPv6 Technology Stateful Address Autoconfiguration
Uses Dynamic Host Configuration Protocol 3315 DHCPv6 [July 2003] (Updated by RFC4361 and RFC5494) similar to DHCP for IPv4 can provide other configuration information Its usage is indicated by the "Managed address configuration" flag (set) in the Router Advertisements (RAs) RFC 3633 IPv6 Prefix Options for DHCP version 6 defines a new provider to customer scheme DHCP-PD (Prefix Delegation) adds new options for DHCPv6 Delegating RouterDHCP-PDRequesting RouterDHCPv6IPv6 Clients
57 IPv6 Technology Topics Overview
IPv6 Overview IPv6 Addressing IPv6 Header Structure ICMPv6 Overview Neighbor Discovery IPv4/IPv6 Transition IPv6 Routing Protocols
58 IPv6 Technology Ethernet Encapsulation RFC 2464
LINK Layer Frame
EtherType
Destination Source IPv6 Address Address 0x86DD Header Data FCS 6 Bytes 6 Bytes2 Bytes 40 Bytes Variable 4 Bytes
• IPv4 is indicated by EtherType 0x0800 • IPv6 is indicated by EtherType 0x86DD • The datagram size from is the same for both: 46 - 1,500 Bytes + 18 Bytes for Ethernet Frame
59 IPv6 Technology Headers: v4 Compared to v6
60 IPv6 Technology Header Changes: IPv6 versus IPv4 IPv6 Header Length is fixed at 40-bytes versus IPv4* 20-bytes+ IPv4 Header Length eliminated IPv4 Total Length becomes the IPv6 Payload Length IPv4 Precedence & TOS becomes IPv6 Traffic Class (DiffServ) IPv4 Flags and Flag Offset eliminated IPv4 TTL (Time To Live) becomes IPv6 Hop Limit IPv4 Protocol becomes IPv6 Next header IPv4 Header Checksum eliminated Addresses increased from 32-bits for IPv4 to 128-bits for IPv6 Address length increased by 4x but header length only 2x *IPv4 Options becomes IPv6 Extension Headers 61 IPv6 Technology IPv6 Extension Headers
Extension Headers provide both efficiency and flexibility in the creation and forwarding of IPv6 datagrams From an efficiency standpoint, they allow the IPv6 header to be fixed at 40 bytes From an flexibility standpoint, they can support common functions using a specific structure of fields From an flexibility standpoint, they can also support future functions using Options Options are a special type of Extension Header and provide even more flexibility by providing variable-length fields that can be used for any purpose If included, Extension Headers appear one after the other following the main header
62 IPv6 Technology IPv6 Next Header Field
For most packets it just specifies the upper layer protocol Can also be used as pointers to additional Extension Headers
63 IPv6 Technology Extension Headers Pointers The IPv6 Next Header field is used to “chain together” the headers in an IPv6 datagram. The last header in the datagram contains the number of the encapsulated protocol (such as 6 for TCP).
64 IPv6 Technology Extension Headers Example
65 IPv6 Technology Extension Header Types Extension Headers, if present, should be in this order and only appear once* in each datagram: IPv6 header (RFC 2460) Hop-by-Hop Options header (Next Header (NH) = 0, RFC 2460) Routing header (NH = 43, RFC 2460 Type 0 Deprecated by RFC 5095) Fragment header (NH = 44, RFC 2460) Encapsulating Security Payload header (NH = 50, RFC 2406) Authentication header (NH = 51, RFC 2402) *Destination Options header (NH = 60, RFC 2460) No Next header (NH = 59, RFC 2460) Upper-layer header (NH = 6 & 17 for TCP/UDP respectively) *The Destination Options header may actually appear twice; near the start and at the end of the extension headers. The Hop-By-Hop Options are normally examined by all intermediate devices and is used specifically to convey management information to all routers in a route. 66 IPv6 Technology Extension Header Types Table
Value (Hexadecimal) Value (Decimal) Protocol / Extension Header
00 0 Hop-By-Hop Options 01 1 ICMPv4 02 2 IGMPv4 04 4 IP in IP Encapsulation 06 6 TCP 08 8 EGP 11 17 UDP 29 41 IPv6 2B 43 Routing Extension Header 2C 44 Fragmentation Extension Header Resource Reservation Protocol 2E 46 (RSVP) Encrypted Security Payload (ESP) 32 50 Extension Header Authentication Header (AH) 33 51 Extension Header 3A 58 ICMPv6 3B 59 No Next Header Destination Options Extension 3C 60 Header
67 IPv6 Technology Extension Headers Explained
Hop-By-Hop Options (variable length): Defines an arbitrary set of options that are intended to be examined by all devices on the path from the source to destination device(s). Routing (variable length): Defines a method for allowing a source device to specify the route for a datagram. This header type actually allows the definition of multiple routing types. The IPv6 standard defines the Type 0 Routing extension header, which is equivalent to the “loose” source routing option in IPv4 and used in a similar way. Fragment (length 8 bytes): When a datagram contains only a fragment of the original message, this extension header is included. It contains the Fragment Offset, Identification and More Fragment fields that were removed from the main header. Encapsulating Security Payload (ESP) (variable length): Carries encrypted data for secure communications. This header is described in detail in the IPSec RFC 2406. Authentication Header (AH) (variable length): Contains information used to verify the authenticity of encrypted data. This header is described in detail in the IPSec RFC 2402. Destination Options (variable length): Defines an arbitrary set of options that are intended to be examined only by the destination(s) of the datagram. 68 IPv6 Technology IPv6 Routing Extension Header Format Next Header (1 byte): Contains the protocol number of the next header after the Routing header. Used to link headers together as described above. Hdr Ext Length (1 byte): The length of the Routing header in 8-byte units, not including the first 8 bytes of the header. For a Routing Type of 0, this value is thus two times the number addresses embedded in the header. Routing Type (1 byte): This field allows multiple routing types to be defined; at present, the only value used is 0. Segments Left (1 byte): Specifies the number of explicitly-named nodes remaining in the route until the destination. Reserved (4 bytes): Not used; set to zeroes. Address1 … AddressN (multiple of 16): A set of IPv6 addresses that specify the route to be used.
69 IPv6 Technology Fragmentation Header Next Header (1 byte): Contains the protocol number of the next header after the Fragment header. Used to link headers together as described above. Reserved (1 byte): Not used; set to zeroes. Fragment Offset (13 bits): Specifies the offset, or position, in the overall message where the data in this fragment goes. It is specified in units of 8 bytes (64 bits) and used in a manner very similar to the field of the same name in the IPv4 header. Reserved (2 bits): Not used; set to zeroes. M (More Fragments) Flag (1 bit): Same as the flag of the same name in the IPv4 header— when set to 0, indicates the last fragment in a message; when set to 1, indicates that more fragments are yet to come in the fragmented message. Identification (4 bits): Same as the field of the same name in the IPv4 header, but expanded to 32 bits. It contains a specific value that is common to each of the fragments belonging to a particular message, to ensure that pieces from different fragmented messages are not mixed together.
70 IPv6 Technology Fragmentation Example
Unfragmentable Fragmentable
Fragment Unfragmentable Fragment 1 Header
Fragment Fragments Unfragmentable Fragment 2 Header
Fragment Unfragmentable Last Fragment Header
71 IPv6 Technology Security AH and ESP Extension Headers
IP Security (IPSec) is defined as part of IPv6 and is essentially identical in both IPv4 and IPv6 However, IPv6 can be deployed end to end, whereas, Typically IPSec in IPv4 is deployed between border routers Internet Key Exchange (IKE), Authentication Header (AH), and Encapsulating Security Payload (ESP) AH is optional IKE using the Diffie-Hellman algorithm IKE and IPSec Security Associations (SAs) ESP in Tunnel or Transport mode
72 IPv6 Technology Hop-By-Hop and Destination Options
Used to carry arbitrary optional information in IPv6 datagrams (i.e., sets of information that aren't defined in the regular extension headers) Provides maximum flexibility, allowing the basic IPv6 protocol to be extended in ways the designers never anticipated, with the goal of reducing the chances of the protocol becoming obsolete. Option are actually implemented as extension headers. There are two different ones used to encode options. These two headers only differ in terms of how the options they contain are to be processed by devices; otherwise, they are formatted the same and used in the same way. The two extension header types are: Destination Options: Contains options that are intended only for the ultimate destination of the datagram (and perhaps a set of routers specified in a Routing header, if present). Hop-By-Hop Options: Contains options that carry information for every device (router) between the source and destination
73 IPv6 Technology Hop-By-Hop and Destination Options Format Contains 1 or more Options as implied by the Extension Length field Each Option is TLV encoded
74 IPv6 Technology Option Type Field
75 IPv6 Technology Jumbograms are defined in RFC 2675
Defined by the Hop-by-Hop Options Extension Header Because the IPv6 Payload Length (16 bits) "only" supports up to 65,535 bytes The Payload Length field in the IPv6 header must be set to zero in every packet that carries the Jumbo Payload option. Jumbograms support packets up to 4GB in length Uses a 32 bit Jumbo Payload Length field Link MTU greater than 65,575 octets Provides for more efficient transfers with fewer interrupts to the communicating hosts RFC 2675 also describes the changes needed to TCP and UDP to make use of jumbograms UDP packets longer than 65,535 octets may be sent by setting the UDP Length field to zero With TCP, an MSS of 65,535 is to be treated as infinity
76 IPv6 Technology Critical Router Loop
The set of instructions that must be executed to determine how to forward a packet. You can compare IPv4 vs. IPv6 processing. The result of the new IPv6 header is a reduction in the critical router loop. IPv6 routers do not have to verify and recalculate a header checksum, perform fragmentation, or process options not intended for them. Each instruction is a different process that you can exercise while testing the performance of the device. A Conformance test would determine if the device responds appropriately under varying conditions taking the entire suite under consideration. A Functional test would determine if your router can do a particular instruction. A Performance test would determine the effect a particular instruction has on throughput.
77 IPv6 Technology IPv4 Critical Router Loop 1. Verify the IP Header Checksum field. 2. Verify that the value of the Version field is 4. 3. Decrement the value of the TTL field. If its new value is less than 1, send an ICMPv4 Time to Live Exceeded message to the source 4. Check for the presence of IPv4 header options and if present, process them. 5. Use the Destination Address field to determine a forwarding interface and a next-hop. If a route is not found, send an ICMPv4 Destination Unreachable message to the source. 6. Potentially perform IPv4 fragmentation. Or if the DF flag is set to 1, send an ICMPv4 Destination Unreachable- Fragmentation Needed And DF Set message to the source 7. Recalculate the new header checksum and place its new value in the Header Checksum field. 8. Forward the packet by using the appropriate forwarding interface. 78 IPv6 Technology IPv6 Critical Router Loop
1. Verify that the value of the Version field is 6. 2. Decrement the value of the Hop Limit field. If its new value is less than 1, send an ICMPv6 Time Exceeded-Hop Limit Exceeded message to the source. 3. Check the Next Header field for a value of 0. If 0, process the Hop-by-Hop Options header. 4. Use the Destination Address to determine a forwarding interface and a next-hop. If a route is not found, send an ICMPv6 Destination Unreachable message to the source 5. If the link MTU of the forwarding interface is less than (40 + the value of the Payload Length field), drop the packet and send an ICMPv6 Packet Too Big message to the source. 6. Forward the packet by using the appropriate forwarding interface.
79 IPv6 Technology Topics Overview
IPv6 Overview IPv6 Addressing IPv6 Header Structure ICMPv6 Overview Neighbor Discovery IPv4/IPv6 Transition IPv6 Routing Protocols
80 IPv6 Technology ICMPv6 Overview – RFC 4443
Updated version of the Internet Control Message Protocol (ICMP) for IPv6 Reports delivery or forwarding errors and a simple echo service for troubleshooting Provides a framework for: Multicast Listener Discovery (MLD) Neighbor Discovery (ND) IPv6 mobility Future applications
81 IPv6 Technology ICMPv6 Header
Similar structure as was ICMP for IPv4 Different Type and Code values defined Uses IPv6 Next Header value 58
82 IPv6 Technology ICMPv6 Message Types
Error messages Sent for errors encountered in forwarding or delivery by the destination node or an intermediate router The high order bit of the Type field is set to 0 . Type field is in the range of 0 - 127 Informational messages Provide diagnostic functions and additional host functionality The high order bit of the Type field is set to 1 . Type field is in the range of 128 - 255
83 IPv6 Technology ICMPv6 Error Messages
Type 1: Destination Unreachable Code 0: no route to destination Code 1: communication administratively prohibited Code 3: address unreachable Code 4: port unreachable Type 2: Packet Too Big Message contains MTU Type 3: Time Exceeded Code 0: hop limit exceeded Code 1: fragment reassembly time exceeded Type 4: Parameter Problem Code 0: erroneous header field Code 1: unrecognized Next Header type Code 2: unrecognized IPv6 option
84 IPv6 Technology ICMPv6 Information Messages
Request(Solicitation ) / Reply(Advertisement) messages Contains Identifier and Sequence number Type 128: Echo request Type 129: Echo reply
85 IPv6 Technology ICMPv6 for Neighbor Discovery Router Solicitation Type 133 Host requests routers to send Router Advertisement immediately Router Advertisement Type 134 Contains one or more prefixes Prefixes have lifetime Stateless or stateful autoconfiguration to be used Neighbor Solicitation Type 135 Used by node to get Link-layer address of neighbor Neighbor Advertisement Type 136 Response to a Neighbor Solicitation Redirect Type 137 Sent by routers to inform a host of a better first-hop node
86 IPv6 Technology ICMPv4 vs. ICMPv6 Message Equivalents
87 IPv6 Technology Multicast Listener Discovery (MLD)
Its how clients express their interest in receiving multicast traffic; uses ICMPv6 Type 131 message 2 versions: MLDv1 (RFC 2710) and MLDv2 (RFC 3810) MLDv2 supports source-specific requests similar to IGMPv2 and IGMPv3 respectively A node sends out an ICMP type 131 Multicast Listener Report using it's SNM address to "register" with a L3 infrastructure when it boots up
88 IPv6 Technology Topics Overview
IPv6 Overview IPv6 Addressing IPv6 Header Structure ICMPv6 Overview Neighbor Discovery IPv4/IPv6 Transition IPv6 Routing Protocols
89 IPv6 Technology Neighbor Discovery (RFC 4861)
Replaces IPv4 ARP, plus new features Uses Internet Control Message Protocol (ICMPv6) messages Uses Hop Count of 255 to disallow remote hacking Used to: Find link-layer address of neighbor Find neighboring routers Actively keep track of neighbor reachability Send network information from routers to hosts Protocol used for host autoconfiguration Duplicate Address Detection (DAD)
90 IPv6 Technology Neighbor Discovery Usage Set of messages and processes that determine relationships between neighboring nodes Replaces IPv4 ARP, ICMPv4 Router Discovery, and ICMPv4 Redirect ND is used by nodes: For address resolution and DAD To determine link-layer address changes To determine neighbor reachability ND is used by hosts: To discover neighboring routers Autoconfigure addresses, address prefixes, and other configuration parameters ND is used by routers: To advertise their presence, host configuration parameters, and on-link prefixes To inform hosts of a better next-hop address to forward packets for a specific destination 91 IPv6 Technology Neighbor Discovery using ICMPv6
Version Class Flow Label Payload Length 58 Hop Limit
Source Address
Destination Address
ICMPv6 Type (133-137) ICMPv6 Code Checksum
ICMPv6 Data
92 IPv6 Technology ICMPv6 for Neighbor Discovery Router Solicitation Type 133 Host requests routers to send Router Advertisement immediately Router Advertisement Type 134 Contains one or more prefixes Prefixes have lifetime Stateless or stateful autoconfiguration to be used Neighbor Solicitation Type 135 Used by node to get Link-layer address of neighbor Neighbor Advertisement Type 136 Response to a Neighbor Solicitation Redirect Type 137 Sent by routers to inform a host of a better first-hop node
93 IPv6 Technology Neighbor Discovery Messages Router Solicitation Messages: Sent by hosts to request that any local routers send a Router Advertisement message so they don't have to wait for the next regular advertisement message. Router Advertisement Messages: Sent regularly by routers to tell hosts that they exist and provide important prefix and parameter information to them. Neighbor Solicitation Messages: Sent to verify the existence of another host and to ask it to transmit a Neighbor Advertisement. Neighbor Advertisement Messages: Sent by hosts to indicate the existence of the host and provide information about it. Redirect Messages: Sent by a router to tell a host of a better method to route data to a particular destination.
94 IPv6 Technology Neighbor Discovery Example 4 Steps The next four slides will demonstrate a 4 step process: 1. Assume that Host A wants to communicate with Host B 2. Host A determines a valid multicast MAC address for Host B 3. Host A sends the Multicast Neighbor Solicitation on the wire 4. Host B sends a Unicast Neighbor Advertisement to Host A
Host A
Host C
Host B 95 IPv6 Technology Neighbor Discovery Example Step 1 Assume that Host A wants to communicate with Host B Host A does know Host B's Unicast IP address (item 1) Determined that using DNS??? Probably... It is actually Host B's Link-Local address in this example But, Host A does not know Host B's unicast MAC address Host A
Unicast IP: FE80::210:5AFF:FEAA:20A2 Unicast MAC: 00-10-5A-AA-20-A2
NOTE: SNM = Solicited Node Multicast address
Unicast IP: FE80::260:97FF:FE02:6EA5 (item 1) SNM IP: FF02::1:FF02:6EA5 Unicast MAC: 00-60-97-02-6E-A5 Host C Multicast MAC: 33-33-FF-02-6E-A5 Host B 96 IPv6 Technology Neighbor Discovery Example Step 2
Host A determines a valid multicast MAC address for Host B Host A first converts Host B's Unicast Address (1) to its SNM Address (2) Host A then maps Host B's SNM address to a multicast MAC address (3)
Ethernet Header • Source MAC is 00-10-5A-AA-20-A2 • Destination MAC is 33-33-FF-02-6E-A5 (3) IPv6 Header • Source Address is FE80::210:5AFF:FEAA:20A2 Host A • Destination Address is FF02::1:FF02:6EA5 (2) • Hop limit is 255 Unicast IP: FE80::210:5AFF:FEAA:20A2 Neighbor Solicitation Header Unicast MAC: 00-10-5A-AA-20-A2 • Target Address is FE80::260:97FF:FE02:6EA5 Neighbor Discovery Option • Source Link-Layer Address is 00-10-5A-AA-20-A2
Unicast IP: FE80::260:97FF:FE02:6EA5 (1) SNM IP: FF02::1:FF02:6EA5 (2) Unicast MAC: 00-60-97-02-6E-A5 Host C Multicast MAC: 33-33-FF-02-6E-A5 (3) Host B 97 IPv6 Technology Neighbor Discovery Example Step 3 Host A sends the Multicast Neighbor Solicitation on the wire Host C and others can ignore it since it is not sent to broadcast Host B confirms it is for it via the Neighbor Solicitation Target Address (1) Ethernet Header • Source MAC is 00-10-5A-AA-20-A2 • Destination MAC is 33-33-FF-02-6E-A5 IPv6 Header • Source Address is FE80::210:5AFF:FEAA:20A2 • Destination Address is FF02::1:FF02:6EA5 • Hop limit is 255 Host A Neighbor Solicitation Header • Target Address is FE80::260:97FF:FE02:6EA5 (1) Unicast IP: FE80::210:5AFF:FEAA:20A2 Neighbor Discovery Option Unicast MAC: 00-10-5A-AA-20-A2 • Source Link-Layer Address is 00-10-5A-AA-20-A2
Neighbor Solicitation
Unicast IP: FE80::260:97FF:FE02:6EA5 (1) SNM IP: FF02::1:FF02:6EA5 Unicast MAC: 00-60-97-02-6E-A5 Host C Multicast MAC: 33-33-FF-02-6E-A5 Host B 98 IPv6 Technology Neighbor Discovery Example Step 4 Host B sends a Unicast Neighbor Advertisement to Host A It is sent directly to Host A using unicast MAC and IPv6 addresses Of course from it Host A determines Host B's unicast MAC address (1) Ethernet Header • Source MAC is 00-60-97-02-6E-A5 (1) • Destination MAC is 00-10-5A-AA-20-A2 IPv6 Header • Source Address is FE80::260:97FF:FE02:6EA5 • Destination Address is FE80::210:5AFF:FEAA:20A2 • Hop limit is 255 Host A Neighbor Advertisement Header • Target Address is FE80::260:97FF:FE02:6EA5 Neighbor Discovery Option MAC: 00-10-5A-AA-20-A2 • Target Link-Layer Address is 00-60-97-02-6E-A5 (1) IP: FE80::210:5AFF:FEAA:20A2
Neighbor Advertisement
Unicast IP: FE80::260:97FF:FE02:6EA5 Host C SNM IP: FF02::1:FF02:6EA5 Unicast MAC: 00-60-97-02-6E-A5 (1) Multicast MAC: 33-33-FF-02-6E-A5 99 Host B IPv6 Technology Neighbor Unreachability States How nodes determine that a neighbor is no longer reachable For neighbors used as routers, alternate default routers can be tried For both routers and hosts, address resolution can be performed again
NO ENTRY EXISTS Send multicast Neighbor Solicitation INCOMPLETE
Multicast Neighbor Solicitation retries exceeded Receive solicited Neighbor Advertisement REACHABLE Reachable Time exceeded Reachability confirmed or unsolicited by sending unicast Neighbor Reachability Neighbor Advertisement confirmed by Solicitation and receiving received upper layer protocol solicited Neighbor Advertisement
STALE DELAY PROBE Send packet Delay time exceeded
Unicast Neighbor Solicitation retries exceeded
100 IPv6 Technology Duplicate Address Detection Send a Neighbor Solicitation to yourself In this example Host B would answer
Ethernet Header • Dest MAC is 33-33-FF-52-F9-D8 IPv6 Header • Source Address is :: • Destination Address is FF02::1:FF52:F9D8 • Hop limit is 255 Host A Neighbor Solicitation Header • Target Address is FEC0::2:260:8FF:FE52:F9D8 Tentative IP: FEC0::2:260:8FF:FE52:F9D8
Neighbor Solicitation
IP: FEC0::2:260:8FF:FE52:F9D8 Host C
Host B 101 IPv6 Technology Router Advertisement Message Format This slide depicts a Router Advertisement Message Many of the fields are broken out on the following slide The "M" and "O" bits are used for host auto configuration Managed Address and Other Configuration flags respectively The options contain the configuration parameters for M = 0
ICMP TYPE = 134 ICMP CODE CHECKSUM
HOP LIMIT M O H PRF P R R ROUTER LIFETIME
REACHABLE TIME
RETRANSMIT TIME
OPTIONS
102 IPv6 Technology Multicast Router Advertisement
Ethernet Header • Destination MAC is 33-33-00-00-00-01 IPv6 Header • Source Address is FE80::210:FFFF:FED6:58C0 • Destination Address is FF02::1 • Hop limit is 255 Router Advertisement Header • Current Hop Limit, Flags, Router Lifetime, Reachable and Retransmission Timers Neighbor Discovery Options • Source Link-Layer Address is 00-10-FF-D6-58-C0 Host A • MTU is 1500 • Prefix Information is for FEC0:0:0:F282::/64 MAC: 00-B0-D0-E9-41-43 IP: none
Router Advertisement
MAC: 00-10-FF-D6-58-C0 IP: FE80::210:FFFF:FED6:58C0 Host C
103 IPv6 Technology IPv4 ARP vs. IPv6 Neighbor Discovery
IPv4 Neighbor Function IPv6 Neighbor Function ARP Request message Neighbor Solicitation message ARP Reply message Neighbor Advertisement message ARP cache Neighbor cache Gratuitous ARP Duplicate Address Detection Router Solicitation message (optional) Router Solicitation (required) Router Advertisement message (optional) Router Advertisement (required) Redirect message Redirect message Stateless (15 minute aging time) Stateful (or at least pseudo stateful)
104 IPv6 Technology Topics Overview
IPv6 Overview IPv6 Addressing IPv6 Header Structure ICMPv6 Overview Neighbor Discovery IPv4/IPv6 Transition IPv6 Routing Protocols
105 IPv6 Technology IPv4/IPv6 Transition Criteria The designers of IPv6 recognize that the transition from IPv4 to IPv6 will take years to complete. “The Recommendation for the IP Next Generation Protocol” specification (RFC 1752, January 1995) defined the following transition criteria: Existing IPv4 hosts can be upgraded at any time, independent of the upgrade of other hosts or routers. New hosts, using only IPv6, can be added at any time, without dependencies on other hosts or routing infrastructure. Existing IPv4 hosts, with IPv6 installed, can continue to use their IPv4 addresses and do not need additional addresses. Little preparation is required to either upgrade existing IPv4 nodes to IPv6 or deploy new IPv6 nodes. The inherent lack of dependencies between IPv4 and IPv6 hosts, IPv4 routing infrastructure, and IPv6 routing infrastructure requires a number of mechanisms that allow seamless 106coexistence. IPv6 Technology Transition Mechanisms
To coexist with an IPv4 infrastructure and to provide an eventual transition to an IPv6-only infrastructure, the following mechanisms are used: Dual Stack or IP Layer DNS infrastructure IPv6 over IPv4 tunneling Compatibility Addressing Translation mechanisms
107 IPv6 Technology Dual Stack (RFC 4213)
Dual stack nodes interoperate directly with both IPv4 and IPv6 nodes. They must provide a DNS resolver library capable of dealing with the IPv4 A records as well as the IPv6 AAAA records. IPv4 IPv4 IPv6/IPv4
IPv6 IPv6
108 IPv6 Technology Dual Stack Architecture Dual-stack implementations may have a separate TCP/UDP implementation. However, the appellation "Dual Stack" in itself is somehow misleading. Most implementations of IPv6 do not offer two completely distinct TCP/IP stacks, one for IPv4 and one for IPv6, but a hybrid stack in which most of the code is shared between the two protocol suites.
Application Layer
TCP/UDP TCP/UDP
IPv6 IPv4
Network Interface Layer
109 IPv6 Technology Dual IP Layer Architecture
A dual IP layer contains a single implementation of Host-to- Host layer protocols such as TCP and UDP with IP version aware APIs
Application Layer
Transport Layer (TCP/UDP)
IPv6 IPv4
Network Interface Layer
110 IPv6 Technology Dual Stack versus Dual IP Layer
An implementation of the TCP/IP suite of protocols that includes both an IPv4 Internet layer and an IPv6 Internet layer. This is the mechanism used by IPv6/IPv4 nodes. Some IPv6 protocol drivers also contain a separate implementation of TCP and UDP too aka Dual Stack The question: where is the burden of picking which stack to use?
111 IPv6 Technology Dual IP Layer with Windows Server 2008
Dual IP layer architecture for IPv6 in the TCP/IP stack for Windows Server 2008 The implementation of IPv6 in Windows XP and Windows Server 2003 is a dual stack architecture. For IPv6 support, you have to install a separate protocol through the Network Connections folder. The separate IPv6 protocol stack had its own Transport layer that included Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) and its own Framing layer. Changes to protocols in either the Transport or Framing layers had to be done to two Windows drivers; Tcpip.sys for the IPv4 protocol stack and Tcpip6.sys for the IPv6 protocol stack. The Next Generation TCP/IP stack supports the dual IP layer architecture in which the IPv4 and IPv6 implementations share common Transport and Framing layers. The Next Generation TCP/IP stack has both IPv4 and IPv6 enabled by default. There is no need to install a separate component to obtain IPv6 support.
112 IPv6 Technology DNS Infrastructure
A Domain Name System (DNS) infrastructure is needed for successful coexistence because of the prevalent use of names (rather than addresses) to refer to network resources. Upgrading the DNS infrastructure consists of populating the DNS servers with records to support IPv6 name-to-address and address-to-name resolutions. After the addresses are obtained using a DNS name query, the sending node must select which addresses are used for communication.
113 IPv6 Technology Address Records
A new resource record type named "AAAA" (Quad A) has been defined for IPv6 addresses per RFC 3596 The DNS infrastructure must contain the following resource records (populated either manually or dynamically) for the successful resolution of domain names to addresses: A records for IPv4-only and IPv6/IPv4 nodes AAAA records for IPv6-only and IPv6/IPv4 nodes When a query locates an AAAA record holding an IPv6 address, and an A record holding an IPv4 address, the resolver library MAY order the results returned to the application in order to influence the version of IP packets used to communicate with that specific node
114 IPv6 Technology Pointer Records
The DNS infrastructure must contain the following resource records (populated either manually or dynamically) for the successful resolution of address to domain names (reverse queries): PTR records in the IN-ADDR.ARPA domain for IPv4-only and IPv6/IPv4 nodes PTR records in the IP6.ARPA domain for IPv6-only and IPv6/IPv4 nodes (optional)
115 IPv6 Technology Address Selection Rules
Default address selection rules are described in RFC 3484. For name-to-address resolution, after the querying node obtains the set of addresses corresponding to the name, the node must determine the set of addresses to choose as source and destination for outbound packets. In an environment in which IPv4 and IPv6 coexist, the set of addresses returned in a DNS query may contain multiple IPv4 and IPv6 addresses. Typically by default, IPv6 addresses in DNS query responses are preferred over IPv4 addresses.
116 IPv6 Technology IPv6 over IPv4 Tunneling
IPv6 over IPv4 tunneling is the encapsulation of IPv6 packets with an IPv4 header so that IPv6 packets can be sent over an IPv4 infrastructure. Within the IPv4 header: The IPv4 Protocol field is set to 41 to indicate an encapsulated IPv6 packet. The Source and Destination fields are set to IPv4 addresses of the tunnel endpoints. The tunnel endpoints are either manually configured as part of the tunnel interface or are automatically derived from the sending interface, the next-hop address of the matching route, or the source and destination IPv6 addresses in the IPv6 header.
117 IPv6 Technology IPv6 Tunneling: Basic Theory
Table in Router A: 2085:1:EF:0:66:500:100E:216B = 163.101.18.5 Address for Router B: Address for Router A: 163.101.18.5 58.67.232.14 IPv4 B A
Payload IPv6 IPv4 DA = 163.101.18.5 SA = 58.67.232.14
IPv6 IPv6 Payload IPv6 Payload IPv6
2085:1:EF:0:66:500:100E:216B 2085:1:EF:0:66:500:100E:216B
• Host 1 sends IPv6 packet to Host 2 (normal IPv6 routing) • Router A interprets the destination IPv6 address • Router A encapsulates the IPv6 within IPv4 1 • Router A forwards packet to router B (normal IPv4 routing) 2 • Router B strips off the IPv4 header • Router B forwards the IPv6 packet (normal IPv6 routing) 118 IPv6 Technology IPv6 Tunneling Format
The packet is created with a standard IPv4 header protocol number 41 for IPv6.
IPv6 Packet
Extension Upper Layer Protocol IPv6 Header Headers Data Unit
IPv4 Header Extension Upper Layer Protocol IPv6 Header Protocol = 41 Headers Data Unit
IPv4 Packet
Watch out for MTU issues!
119 IPv6 Technology Path Maximum Transmission Unit (MTU)
For IPv6 over IPv4 tunneling, the IPv6 path maximum transmission unit (MTU) for the destination is typically 20 less than the IPv4 path MTU for the destination. However, if the IPv4 path MTU is not stored for each tunnel, there are instances where the IPv4 packet will need to be fragmented at an intermediate IPv4 router. As per RFC 4213; if the IPv6 MTU size proves to be too large for some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While undesirable, this is not necessarily disastrous, unless the fragments are delivered to different IPv4 destinations due to some form of IPv4 anycast. The IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulating IPv4 header.
120 IPv6 Technology Types of Tunnels Configured Tunnels require manual configuration of tunnel endpoints. In a configured tunnel, the IPv4 addresses of tunnel endpoints are not derived from addresses that are encoded in the IPv6 source or destination addresses or the next-hop address of the matching route. The following are types of Manual tunneling technologies: . Manually Configured Tunnels . GRE/IPv4 Tunnels Automatic Tunnels do not require manual configuration. Tunnel endpoints are determined by the source and destination IPv6 addresses. The following are types of Automatic tunneling technologies: . 6over4 (obsolete) . ISATAP . 6to4 . 6rd . Teredo
121 IPv6 Technology Compatibility Addresses
IPv4-compatible addresses ::w.x.y.z/128 an IPv4 address padded out with zero bits to 128 bits where "w.x.y.z" is the dotted decimal representation of a public IPv4 address was originally thought to be a useful technique in the IPv4 to IPv6 transition, but no technique has been devised to use this form of mapped IPv4 address 6over4 addresses use a 64-bit prefix + Inteface ID of ::wwxx:yyzz WWXX:YYZZ is the colon-hexadecimal representation of w.x.y.z; a unicast IPv4 address assigned to an interface it is deprecated since this technique relied on a multicast IPv4 infrastructure IPv4-mapped addresses ::FFFF:w.x.y.z/96 used to embed IPv4 addresses in an IPv6 address e.g., in a dual stack transition scenario where IPv4 addresses can be mapped into an IPv6 address used internally by the IPv6 application; however, IPv4 packets are exchanged between the nodes (see RFC 4038; not to be confused with RFC 4380)
122 IPv6 Technology Compatibility Addresses continued
6to4 addresses use a prefix of 2002:WWXX:YYZZ::/48 where WWXX:YYZZ is the colon-hexadecimal representation of w.x.y.z; a public IPv4 address assigned to an interface used with the automatic tunneling mechanism defined in RFC 3056 Intra-site Automatic Tunnel Addressing Protocol (ISATAP) addresses are composed of a valid 64-bit unicast address prefix and the interface ID ::0:5EFE:w.x.y.z where w.x.y.z is a unicast IPv4 address assigned to an interface Teredo addresses 2001:0000:/32 used to represent a host when using the automatic tunneling mechanism defined in RFC 4380 "Teredo: Tunneling IPv6 over UDP through NATs"
123 IPv6 Technology Requirements for Unmanaged Networks RFC 3750 Unmanaged Networks IPv6 Transition Scenarios Unmanaged scope typically corresponds to a home or small office network The requirements for unmanaged networks are expressed by analyzing four classes of applications: local applications client applications peer to peer applications Server applications They also consider four cases of deployment: a gateway which does not provide IPv6 at all a dual-stack gateway connected to a dual-stack ISP a dual-stack gateway connected to an IPv4-only ISP a gateway connected to an IPv6-only ISP
124 IPv6 Technology Two Requirements
This analysis outlines two types of requirements: Connectivity requirements, i.e., how to ensure that nodes can exchange IP packets The connectivity requirements often require tunneling solutions These will be discussed on the following slides... Naming requirements, i.e., how to ensure that nodes can resolve each-other's names The naming requirements often require DNS solutions These were discussed on Previous slides....
125 IPv6 Technology Tunneling IPv6 Through an IPv4 Service
There have been multiple proposals on different ways to tunnel IPv6 through an IPv4 service. These proposals can be categorized according to two important properties: Is the deployment automatic, or does it require explicit configuration or service provisioning (i.e., manual)? Does the proposal allow for the traversal of a NAT? These two questions divide the solution space into four broad classes.
126 IPv6 Technology Four Broad Classes of Tunneling
1. Configured tunnel over IPv4 in the absence of NAT 2. Automatic tunnel over IPv4 in the absence of NAT 3. Configured tunnel across a NAT 4. Automatic tunnel across a NAT
Configured Tunnels only operate point-to-point Automatic Tunnels can operate point-to-multipoint 6to4 and 6rd are examples of a solution for automatic tunnel over IPv4 in the absence of NAT Teredo is an example of a solution for automatic tunnel over IPv4 across a NAT
127 IPv6 Technology RFC 4213 (obsoletes RFC 2893)
Basic Transition Mechanisms for IPv6 Hosts and Routers RFC 2893 contains a mechanism called automatic tunneling but a much more general mechanism is specified in RFC 3056 (6to4) RFC 5569 IPv6 rapid deployment (aka 6rd) is now often preferred instead RFC 4213 now only defines Dual IP Layer and Configured Tunnels Is also defines Node Types and Tunnel Types
128 IPv6 Technology Node Types
RFC 4213 defines the following node types: IPv4-only node – implements only IPv4 and does not support IPv6. Many hosts and routers installed today still are IPv4-only nodes. IPv6-only node – implements only IPv6 and is only able to communicate with IPv6 nodes and applications. This type of node is still not common today. IPv6/IPv4 node – that has both IPv4 and IPv6 implemented. IPv4 node can be an IPv4-only node or an IPv6/IPv4 node. IPv6 node can be an IPv6-only node or an IPv6/IPv4 node.
129 IPv6 Technology Node Types Continued
The key to a successful IPv6 transition is compatibility with the large installed base of IPv4 hosts and routers. Maintaining compatibility with IPv4 while deploying IPv6 will streamline the task of transitioning the Internet to IPv6. True migration is achieved when all IPv4 nodes are converted to IPv6-only nodes. However, for the foreseeable future, practical migration is achieved when as many IPv4-only nodes as possible are converted to IPv6/IPv4 nodes (i.e., Dual Stack). IPv4-only nodes can communicate with IPv6-only nodes only when using an IPv4-to-IPv6 proxy or translation gateway.
130 IPv6 Technology Tunneling Configurations
RFC 4213 defines the following tunneling configurations with which to tunnel IPv6 traffic between IPv6/IPv4 nodes over an IPv4 infrastructure: Router-to-Router Host-to-Router or Router-to-Host Host-to-Host IPv6 over IPv4 tunneling only describes an encapsulation of IPv6 packets with an IPv4 header so that IPv6 nodes are reachable across an IPv4 infrastructure. There is no exchange of messages for tunnel setup, maintenance, or termination. Also, IPv6 over IPv4 tunneling does not provide security for tunneled IPv6 packets.
131 IPv6 Technology Router-to-Router Tunneling
Two IPv6/IPv4 routers connect two IPv4 or IPv6 infrastructures over an IPv4 infrastructure. The tunnel endpoints span a logical link in the path between the source and destination and acts as a single hop. Routes within each IPv4 or IPv6 infrastructure point to the IPv6/IPv4 router on the edge.
IPv4 Infrastructure IPv4 or IPv6 IPv4 or IPv6 Infrastructure Infrastructure
IPv6 over IPv4 Tunnel IPv6 IPv6 Node Node IPv6/IPv4 Router IPv6/IPv4 Router
132 IPv6 Technology Router-to-Router Tunneling Examples
Examples of this tunneling configuration are: An IPv6-only test lab that tunnels across an organization’s IPv4 infrastructure to reach the IPv6 Internet. Two IPv6-only routing domains that tunnel across the IPv4 Internet. A 6to4/6rd router that tunnels across the IPv4 Internet to reach another 6to4/6rd router or a 6to4 relay or 6rd gateway. A DS-Lite implementation to tunnel private IPv4 CPEs across a Service Provider's IPv6 infrastructure to an Large Scale NAT44.
133 IPv6 Technology Host-to-Router and Router-to-Host Tunneling
In the host-to-router tunneling configuration, an IPv6/IPv4 node that resides within an IPv4 infrastructure creates an IPv6 over IPv4 tunnel to reach an IPv6/IPv4 router. On the IPv6/IPv4 node, a tunnel interface representing the IPv6 over IPv4 tunnel is created and a route (typically a default route) is added using the tunnel interface. In the router-to-host tunneling configuration, an IPv6/IPv4 router creates an IPv6 over IPv4 tunnel across an IPv4 infrastructure to reach an IPv6/IPv4 node.
IPv4 Infrastructure IPv4 or IPv6 Node A Infrastructure Node B
IPv6 over IPv4 Tunnel IPv6/IPv4 IPv6
IPv6/IPv4 Router
134 IPv6 Technology Host-to-Router and Router-to-Host Tunneling Examples
Examples of host-to-router and router-to-host tunneling are: An IPv6/IPv4 host that tunnels across an organization’s IPv4 infrastructure to reach the IPv6 Internet. An ISATAP host that tunnels across an IPv4 network to an ISATAP router to reach the IPv4 Internet, another IPv4 network, or an IPv6 network. An ISATAP router that tunnels across an IPv4 network to reach an ISATAP host. Teredo too in the presence of a NAT
135 IPv6 Technology Host-to-Host Tunneling
In the host-to-host tunneling configuration, an IPv6/IPv4 node that resides within an IPv4 infrastructure creates an IPv6 over IPv4 tunnel to reach another IPv6/IPv4 node that resides within the same IPv4 infrastructure. The tunnel endpoints span the entire path between the source and destination nodes.
IPv4 Infrastructure
IPv6 over IPv4 Tunnel IPv6/IPv4 IPv6/IPv4 Node Node
136 IPv6 Technology Host-to-Host Tunneling Examples
Examples of this tunneling configuration are: IPv6/IPv4 hosts that use ISATAP addresses to tunnel across an organization’s IPv4 infrastructure IPv6/IPv4 hosts that use IPv4-compatible addresses to tunnel across an organization’s IPv4 infrastructure.
137 IPv6 Technology Implementing IPv4 Tunneling for IPv6
Overlay Tunnels for IPv6 Manually Configured Tunnels Manual GRE/IPv4 Tunnels Automatic IPv4-Compatible IPv6 Tunnels Automatic ISATAP Tunnels Automatic 6to4 Tunnels Automatic 6rd Tunnels
138 IPv6 Technology Overlay Tunnels for IPv6
IPv6 packets are encapsulated in IPv4 packets for delivery across an IPv4 infrastructure. Allows communication between isolated IPv6 networks without upgrading the IPv4 infrastructure between them. Can be configured between border routers or between a border router and a host Both tunnel endpoints must support both the IPv4 and IPv6 protocol stacks Reduce the maximum transmission unit (MTU) of an interface by 20 octets Should only be considered as a transition technique toward a network that supports both the IPv4 and IPv6 protocol stacks or just the IPv6 protocol stack
139 IPv6 Technology Tunneling Type and Suggested Usage Manually Configured Tunnels Simple point-to-point tunnels that can be used within a site or between sites Can carry IPv6 packets only Manual GRE/IPv4 Tunnels Simple point-to-point tunnels that can be used within a site or between sites Can carry IPv6, Connectionless Network Service (CLNS), and others Automatic IPv4-Compatible IPv6 Tunnels Point-to-multipoint tunnels that use the ::/96 prefix No longer recommended Automatic ISATAP Tunnels Point-to-multipoint tunnels used to connect systems (i.e., hosts) within a site Sites can use any IPv6 unicast addresses Automatic 6to4 Tunnels Point-to-multipoint tunnels that used to connect isolated IPv6 sites Sites use addresses from the 2002::/16 prefix Automatic 6rd Tunnels Point-to-multipoint tunnels that used to connect isolated IPv6 sites Sites can use any IPv6 unicast addresses
140 IPv6 Technology Manually Configured Tunnels
Equivalent to a permanent link between two IPv6 domains over an IPv4 backbone. A point-to-point tunnel configured between border routers or between a border router and a host. An IPv6 address is manually configured on a tunnel interface, and manually configured IPv4 addresses are assigned to the tunnel source and the tunnel destination. The host or router at each end of a configured tunnel must support both the IPv4 and IPv6 protocol stacks.
141 IPv6 Technology Manual GRE/IPv4 Tunnels
Provides the services necessary to implement any standard point-to-point encapsulation scheme. GRE tunnels are not tied to a specific passenger or transport protocol. The GRE header has a protocol field that identifies the passenger protocol. The encapsulation is as follows: L2 Header---Tunnel IPv4 Header---GRE Header---Original IPv6 Packet The edge routers and the end systems must be dual-stack implementations.
142 IPv6 Technology Automatic IPv4-Compatible IPv6 Tunnels
These use IPv4-compatible IPv6 addresses. They are IPv6 unicast addresses that have zeros in the high-order 96 bits of the address, and an IPv4 address in the low-order 32 bits. They can be written as 0:0:0:0:0:0:A.B.C.D or ::A.B.C.D “A.B.C.D” represents the embedded IPv4 address The tunnel destination is automatically determined by the IPv4 address in the low-order 32 bits of IPv4-compatible IPv6 addresses. This technique does not scale for large networks. Therefore, IPv4-compatible tunnels have been deprecated. Now it is recommended that you use the ISATAP tunneling technique within sites and/or 6to4/6rd tunnels between sites.
143 IPv6 Technology Automatic ISATAP Tunnels
Intra-site Automatic Tunnel Addressing Protocol An automatic overlay tunneling mechanism that uses the underlying IPv4 network as a NBMA link layer for IPv6. Designed for transporting IPv6 packets within a site (hence the intra- site designation), not between sites as with 6to4. The ISATAP router provides standard router advertisement network configuration support for the ISATAP site (albeit via a unicast solicitation). The ISATAP Address Format is composed of: a 64 Bit unicast prefix (could be link local or global IPv6) an interface identifier composed of . 0000:5EFE in the upper 32 bits . the IPv4 address of the ISATAP link in the lower 32 bits (configured IPv4 address of the device). For Example: 2001:0DB8:1234:5678:0000:5EFE:0AAD:8108
144 IPv6 Technology ISATAP – Intra-site Automatic Tunnel Addressing Protocol RFC 5214
Host-to-host, host-to-router, and router-to-host automatic tunneling technology. Provides unicast IPv6 connectivity between IPv6 hosts across an IPv4 intranet. Uses a valid 64-bit prefix + Interface ID ::0:5EFE:w.x.y.z. ISATAP hosts do not require any manual configuration and create ISATAP addresses using standard address autoconfiguration mechanisms. Hosts create link local IPv6 address from configured IPv4 addresses.
145 IPv6 Technology Additional ISATAP information
Hosts using ISATAP may have a globally unique IPv6 address even if their IPv4 address is a private one. To enable a network for ISATAP, an ISATAP gateway has to be installed that is connected to both the IPv6 Internet and the IPv4 private Intranet. It serves as default gateway for all IPv6 traffic from the Intranet. Dual-stack nodes use ISATAP IPv6 in IPv4 tunnels terminated by the ISATAP gateway for IPv6 connectivity. To do so they need to find the IPv4 address of the ISATAP gateway. A simple mechanism is used in this situation; a special entry in the DNS server for the ISATAP gateway. ISATAP clients query the DNS server for the address of the ISATAP gateway and send a router solicitation to this address. The gateway replies with a router advertisement that contains the globally routable IPv6 prefix, allowing the enquiring clients to auto-configure their IPv6 addresses.
146 IPv6 Technology ISATAP Addresses
ISATAP addresses are composed of a valid 64-bit unicast address prefix and the interface identifier ::0:5EFE:w.x.y.z In which w.x.y.z is any unicast IPv4 address, which includes both public and private addresses. The ISATAP interface identifier can be combined with any 64-bit prefix that is valid for IPv6 unicast addresses. This includes the link-local address prefix (FE80::/64) and global prefixes (including 6to4 prefixes). Like IPv4-compatible addresses, 6over4 addresses, and 6to4 addresses, ISATAP addresses contain an embedded IPv4 address that is used to determine either the source or destination IPv4 addresses within the IPv4 header when ISATAP-addressed IPv6 traffic is tunneled across an IPv4 network.
147 IPv6 Technology ISATAP Components
148 IPv6 Technology Automatic 6to4 Tunnels
Allows isolated IPv6 domains to be connected over an IPv4 network to remote IPv6 networks. They are point-to-multipoint (hence the term "automatic"). They treat the IPv4 infrastructure as a virtual nonbroadcast multiaccess (NBMA) link (unlike 6over4 which relied on IPv4 multicast). The IPv4 address of the tunnel endpoints are embedded in the IPv6 addresses. The tunnel endpoints are determined by the IPv4 address of the border router extracted from the IPv6 address that starts with the prefix 2002::/16 Where the format is 2002:border-router-IPv4-address::/48. Following the embedded IPv4 address are 16 bits that can be used to number networks within the site. 6to4 tunnels are configured between border routers or between a border router and a host.
149 IPv6 Technology RFC 3056 (6to4) Introduction Router-to-router automatic tunneling technology. Provides unicast IPv6 connectivity between IPv6 sites and hosts across the IPv4 Internet. Uses a specific prefix of 2002:WWXX:YYZZ::/48 Requiring a 2002::/16 prefix is its major drawback! Embedding an IPv4 address is its second major drawback (remember, we are running out of these) Gives a full /48 to a site based on its external IPv4 address IPv4 external address embedded: 2002:
150 IPv6 Technology RFC 3056 (6to4) Introduction continued
Interim mechanism for IPv6 sites to communicate with each other over an IPv4 network without explicit tunnel setup. Also, for them to communicate with native IPv6 domains via relay routers. Treats the wide area IPv4 network as a unicast point-to- point link layer. Defines a method for assigning an interim unique IPv6 address prefix to any site that currently has at least one globally unique IPv4 address. Specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network.
151 IPv6 Technology 6to4 Components 21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A
2002:12.0.0.1:SID:InterfaceID IPv6 Internet 13.0.0.1
IPv4 12.0.0.1 Internet IPv6 6to4 Net 11.0.0.1
2002:11.0.0.1:SID:InterfaceID IPv6 6to4 Net
152 IPv6 Technology 6to4 Components continued
6to4 Host is an IPv6 host that is configured with at least one 6to4 address (a global address with the 2002::/16 prefix). In all other respects it is a standard IPv6 host. They create 6to4 addresses using standard address autoconfiguration mechanisms. 6to4 Router is the border router between an IPv6 site and an IPv4 network. Is also used to forward 6to4-addressed traffic between the 6to4 hosts within a site and/or other 6to4 routers or 6to4 relay routers on an IPv4 network. 6to4 Relay Router is an IPv6/IPv4 router that forwards 6to4-addressed traffic between 6to4 routers on the Internet and hosts on the IPv6 Internet. Uses 6to4 anycast address of 192.88.99.1
153 IPv6 Technology Address Selection and 6to4
Consult RFC 3484 "Default Address Selection for IPv6" Subject to those general mechanisms, the principle that will normally allow correct operation of 6to4 is this: If one host has only a 6to4 address, and the other one has both a 6to4 and a native IPv6 address, then the 6to4 address should be used for both. If both hosts have a 6to4 address and a native IPv6 address, then either the 6to4 address should be used for both, or the native IPv6 address should be used for both. The choice should be configurable. The default configuration should be native IPv6 for both.
154 IPv6 Technology 6to4 Encapsulation in IPv4
IPv6 packets from a 6to4 site are encapsulated in IPv4 packets when they leave the site via its external IPv4 connection. The IPv4 interface that is carrying the 6to4 traffic is notionally equivalent to an IPv6 interface, and is referred to as a pseudo-interface. IPv6 packets are transmitted in IPv4 packets with an IPv4 protocol type of 41. The IPv4 header contains the Destination and Source IPv4 tunnel addresses. One or both of these will be identical to the V4ADDR field of an IPv6 6to4 prefix. The IPv4 packet body contains the IPv6 header and payload. 155 IPv6 Technology ISATAP and 6to4 Example
The graphic shows two ISATAP hosts using 6to4 prefixes that are communicating across the ISATP Router & Internet even though each site is using the 192.168.0.0/16 private IPv4 address space internally.
ISATP Router& 6to4 Relay Router
IPv6 Internet
156 IPv6 Technology RFC 5569 IPv6 rapid deployment (aka 6rd)
IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Facilitates IPv6 rapid deployment across IPv4 infrastructures of ISPs Derived from 6to4, but it only operates within a single ISP RFC 5569 only 9 pages! 2 of them are just accolades to Free 6rd is a reference to both: IPv6 rapid deployments it makes possible, and... Informally the initials (RD) of its inventor, Rémi Després
157 IPv6 Technology History of 6rd In November 2007 Rémi Després proposed to Free, the second largest ISP in France, to use the 6rd mechanism he had invented to rapidly deploy IPv6. Rani Assaf, the CTO of Free, immediately decided to implement the solution. Five weeks later, Free released a press release announcing that IPv6 was available to Free's customers was issued. The first draft describing the 6rd mechanism and Free's deployment was submitted to IETF on 9 February 2008. After improvements, it was published on 24 January 2010 as informational RFC 5569. In March 2010 a Working Group of the IETF approved that its latest draft on 6rd should become, after some more modifications, a Standards-track RFC. In August 2010 the Standards Track RFC 5969 was published. In October 2010 Comcast made 6rd software for home gateway devices available via open source for free.
158 IPv6 Technology 6rd Specification
6to4 functions are modified to replace the standard 6to4 prefix 2002::/16 by an IPv6 prefix that belongs to the ISP- assigned address space Also, the 6to4 anycast address is replaced by another anycast address chosen by the ISP. The ISP operates one or several 6rd gateways (upgraded 6to4 routers) at its border between its IPv4 infrastructure and the IPv6 Internet. CPEs support IPv6 on their customer-site side and support 6rd (upgraded 6to4 function) on their provider side.
159 IPv6 Technology Before 6rd
CPE Router ISP IPv4 Network IPv4 CPE
If CPE uses private IPv4 then NAT Carrier Router
IPv4 Internet
160 IPv6 Technology After 6rd
CPE 6rd Carrier Grade Router ISP IPv4 Network 6rd Gateway IPv4/IPv6 CPE IPv6 over IPv4 Tunnel
If CPE uses private IPv6 IPv4 then NAT Internet Carrier Router
IPv4 Internet
161 IPv6 Technology 6rd Components and Addressing
IPv4 route to 6rd gateway; or other 6rd CPE if same IPv6 prefix
IPv6 ISP Internet IPv6 CPE 6rd ISP IPv4 Client Client Router Gateway infrastructure IPv6 Internet IPv6 IPv6 over link IPv4 Tunnel
IPv4 address of IPv4 anycast address (ISP assigned) the customer site: IPv6 prefix of the ISP: 10.1.1.1/24 2045:3D5B::/32 ISP IPv6 Client 6rd address: 2045:3D5B:10.1.1.1:
162 IPv6 Technology Comparison to 6to4 With 6to4, connectivity to the IPv6 Internet is best effort. there is no guarantee that there will be working routes toward a 6to4 relay a 6to4 host is not guaranteed to be reachable by all native IPv6 hosts an operator of a 6to4 relay has no control of which hosts use it operators have little incentive to maintain a good quality of service as traffic grows With 6rd, each ISP use one of its own IPv6 prefixes instead of the special 2002::/16 prefix standardized for 6to4. therefore, a provider is guaranteed that its 6rd hosts will be reachable from all native IPv6 addresses there is no relay server to be used outside of its own control therefore, it keeps full responsibility for the quality of service experienced by its own customers 6rd it also reduces the scope for traffic anonymization attacks such as those possible with 6to4
163 IPv6 Technology Current 6rd Usage Free has used 6rd since December 2007. In 2008, a report from Google on its visibility of IPv6 use showed France as having the second highest IPv6 penetration in the world, with 95% of its IPv6 being with native IPv6 addresses, almost all from Free. Comcast began a 6rd trial on June 30, 2010 and have tested 2 different home gateways with 6rd, one of which they have made available via open source. They also distribute 6rd configuration instructions for any user on their network that wishes to use their 6rd Border Relays. AT&T is planning 6rd trials for their broadband network in Q1 2011 and says it will have a full-production launch of residential IPv6 services in the fourth quarter of 2011. The Japanese company SoftBank have announced that they will begin rolling out IPv6 using 6rd. Swisscom has conducted tests of 6rd, but have no roll out plans yet.
164 IPv6 Technology Address Space Consumption
The most simple 6rd deployment, which uses 32 bits of IPv6 address space to map the entire IPv4 address space, consumes more address space than typical with IPv6 natively supported in all ISP routers. This can however be mitigated by omitting redundant parts of the IPv4 address space, and in some cases by deploying multiple 6rd domains. The default allocation of IPv6 space by an RIR is a 32-bit prefix. Since it takes 32 bits to map IPv4 addresses with 6rd, this implies an ISP would only be able to allocate 64-bit IPv6 prefixes to its customers. Although these 64-bit prefixes are sufficient for sites that have only one LAN, it does not allow for multiple subnets without introducing a Network Address Translation function to IPv6. Free originally assigned 64-bit IPv6 prefixes to its customers but was able to assign them shorter prefixes once it obtained a larger allocation of IPv6 space (a 26-bit prefix) from the RIPE NCC.
165 IPv6 Technology Network Address Translation (NAT) Private IPv4 NAT to public IPv4: NAT44 SP infrastructure uses public IP CPE only performs the NAT Private IPv4 NAT to private IPv4 to public IPv4: NAT444 SP infrastructure uses private IP but has public facing interface Requires Large Scale NAT (LSN) architectures since Provider has to NAT too (i.e., not just home modem) Private IPv4 NAT to private/public IPv6 to IPv4 public: NAT464 Would require CPE to translate from IPv4 to IPv6 Would require LSN to also translate from IPv6 to IPv4 Therefore, DS-Lite CPE only has to tunnel IP4 in IPV6 towards provider; no NAT even LSN only have to perform NAT44; of course it is a tunnel endpoint too
166 IPv6 Technology Dual Stack Lite (DS-Lite)
draft-ietf-softwire-dual-stack-lite-06: Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion Allows IPv4 CPE hosts to reach an IPv4 NAT at the SPs edge over an IPv6 tunnel between the CPE modem and an SP router A better way to share IPv4 addresses among customers Public IPv4 addresses on internet side of SPs edge not in SPs network Combines two well-known technologies: IP in IP (IPv4-in- IPv6) and Network Address Translation (NAT) Enable both continued support for IPv4 services and incentives for the deployment of IPv6
167 IPv6 Technology DS-Lite Diagram: Before and After
Home IPv4 B4 AFTR Service Provider's Link IPv4 Internet IPv6 Network Private IPv4 CPE LSN Public IPv4 IPv4 over IPv6 Tunnel Address Address
B4 = Basic Bridging BroadBand element ("before") CPE = Customer Premise Equipment AFTR = Address Family Transition Router element ("after") LSN = Large Scale NAT
168 IPv6 Technology Scenario 1: Existing IPv4 Customer
DS-Lite tunnels IPv4 packets over IPv6 from the CPE to LSN
169 IPv6 Technology Scenario 2: Dual IP Customer IPv6 packets are routed normally while IPv4 packets are routed to the LSN
170 IPv6 Technology Scenario 3: Dual Stack Customer
The IPv6 Link can be extended to the dual stacked device
171 IPv6 Technology Other Tunneling Mechanisms
RFC 4380 – Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) RFC 2473 – Generic packet tunneling in IPv6 RFC 3053 – IPv6 Tunnel Broker IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) draft-blanchet-v6ops-tunnelbroker-tsp-04 (RFC editor Que) RFC 2529 – Transmission of IPv6 over IPv4 Domains without Explicit Tunnels (aka 6over4)
172 IPv6 Technology Teredo RFC 4380 (aka “Shipworm”)
Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) Updated-By RFC5991 Teredo Security Updates Teredo is a tunneling protocol designed to grant IPv6 connectivity to nodes that are located behind IPv6-unaware NAT devices. It defines a way of encapsulating IPv6 packets within IPv4 UDP datagrams that can be routed through NAT devices and on the IPv4 internet. The Teredo protocol performs several functions: Diagnoses UDP over IPv4 (UDPv4) connectivity and discovers the kind of NAT present (using a simplified replacement to the STUN protocol) assigns a globally-routable unique IPv6 address to each host using it encapsulates IPv6 packets inside UDPv4 datagrams for transmission over an IPv4 network (this includes NAT traversal) routes traffic between Teredo hosts and native (or otherwise non- Teredo) IPv6 hosts
173 IPv6 Technology Teredo Overview
For tunneling IPv6 through one or several NATs Other tunneling solutions require global IPv4 address, and so do not work from behind NAT Can be stateless or stateful using Tunnel Setup Protocol (TSP) Tunnels over UDP (port 3544) rather than IP protocol #41 Basic components: Teredo Client: Dual-stacked node Teredo Server: Node with globally routable IPv4 Internet access, provides IPv6 connectivity to client Teredo Relay: Dual-stacked router providing connectivity to client Teredo Bubble: IPv6 packet with no payload (NH #59) for maintaining mapping in the NAT Teredo Service Prefix: Prefix originated by TS for creating client IPv6 address (2001:0000:/32)
174 IPv6 Technology Teredo Purpose 6to4 requires the tunnel endpoint to have a public IPv4 address However, many hosts are assigned a private IPv4 address and must traverse a NAT This would require the tunnel endpoint to be implemented on the NAT device itself Though many NAT devices cannot be upgraded to implement a tunnel endpoint, Teredo alleviates this problem by encapsulating IPv6 packets within UDP/IPv4 datagrams for NAT traversal. This allows a host implementing Teredo to gain IPv6 connectivity with no cooperation from the local network environment. Teredo is intended to be a temporary measure Therefore Teredo protocol includes provisions for a sunset procedure
175 IPv6 Technology Teredo IPv6 Addressing
Prefix – IANA assigned value of 2001:0000::/32 Teredo Server IPv4 - The primary IPv4 address of the Teredo server that is used. Flags - Currently only the higher order bit is used; set to 1 if the Teredo client is located behind a cone NAT, 0 otherwise. UDP port number* - UDP port number that is mapped by the NAT to the Teredo client with all bits inverted. IPv4 address* - The public IPv4 address of the NAT with all bits inverted. *Obfuscation is used to prevent NATs from rewriting the payload when it also contains an IP address and/or UDP port.
176 IPv6 Technology Teredo Architecture Teredo Server
IPv6-only Teredo IPv4 Client Client NAT IPv4 Internet Teredo Relay IPv6 Internet IPv6 over Private IPv4 IPv4/UDP Tunnel Address
Teredo Host-specific Relay • Teredo Client - Supports Teredo Tunneling; tunnel and data endpoint • Teredo Server - Provides initial config to Teredo Clients; initial proxy • Teredo Relay - Provides IPv4/IPv6 connectivity; primary data path • Teredo Host-specific Relay - Host that has direct links to both the IPv4 and IPv6 Internets; tunnel and data endpoint • IPv6 Client - Operates normally; data endpoint 177 IPv6 Technology Initial Configuration for Teredo Clients
Teredo IPv4 Client NAT IPv4 Internet Teredo Server 1
teredo.ipv6.microsoft.com IPv6 over Private IPv4 IPv4/UDP Tunnel Teredo Server 2 Address
1. Teredo Client sends a Router Solicitation to the Teredo Server 1; Cone flag is set 2. Teredo Server 1 sends a Router Advertisement; with a different IPv4 source to detect a Cone NAT; if received proceed to step 5, otherwise to step 3 3. Teredo Client sends another Router Solicitation to the Teredo Server 1; Cone flag is not set 4. Teredo Server 1 sends a Router Advertisement; with the same IPv4 source to detect non-Cone NAT (aka Restricted NAT) 5. Teredo Client sends a Router Solicitation to the Teredo Server 2 6. Teredo Server 2 send a Router Advertisement; used to detect a Symmetric NAT 7. If Teredo Server 2's Router Advertisement is received, the Teredo Client cannot use Teredo to communicate 178 IPv6 Technology Initial Configuration: Teredo Client Address During the initial configuration process the Teredo Client utilized its link-local address. Based on the received RA (step 2 or 4 in the previous process), the Teredo Client constructs its Teredo address from the following: The first 64 bits are set to the value included in the Prefix Information option of the received RA . The 64-bit prefix advertised by the Teredo server consists of the Teredo prefix (32 bits) and the IPv4 address of the Teredo server (32 bits) The next 16 bits are the Flags field The next 16 bits are set to the external UDP port number from the Origin indicator in the RA The last 32 bits are set to the external IP address from the Origin indicator in the RA
179 IPv6 Technology Maintaining the NAT Mapping
Teredo IPv4 Client NAT IPv4 Internet
Teredo Server IPv6 over Private IPv4 IPv4/UDP Tunnel Address
1. On a periodic basis (by default every 30 seconds), Teredo clients send a single bubble packet to the Teredo Server (IPv6 Packet NH = 59). 2. The Teredo Server discards the bubble packet and sends a response. 3. The periodic bubble packet refreshes the IP address/UDP port mapping in the NAT's translation table; otherwise, the mapping becomes stale and is removed. 4. If the mapping is not present, all inbound Teredo traffic (for a cone NAT) or inbound Teredo traffic from the Teredo server (restricted NAT) to the Teredo host is silently discarded by the NAT. 5. From the response, the Teredo client can determine if the external address and port number for its Teredo traffic have changed.
180 IPv6 Technology Initial Communication from a Teredo Client to an IPv6-only Host Teredo Server
IPv4 IPv6-only Teredo Cone Client Client NAT IPv4 Internet Teredo Relay IPv6 Internet IPv6 over Private IPv4 IPv4/UDP Tunnel Address The Teredo Client needs to Discover the IPv4 address & UDP port number of the Teredo relay that is nearest the IPv6-only Client: 1. Teredo Client sends a Ping6 to the IPv6-only Client via the Teredo Server 2. Teredo Server forwards the echo request to the IPv6 Client 3. IPv6-only Client sends the echo reply to the Teredo Client via the Teredo Relay; due to the IPv6 routing infrastructure, this is sent to the nearest Teredo relay. 4. Teredo Relay forwards the echo reply to the Teredo Client 5. Teredo client determines the IPv4 address of the Teredo Relay (derived from the IPv4 source IP address and UDP port of the ICMPv6 Echo Reply) and can now forward packets directly to the IPv6-only Client of course via the Teredo Relay 181 IPv6 Technology Initial Communication from a Teredo Client to an IPv6-only Host Teredo Server
IPv4 IPv6-only Teredo Restricted Client Client NAT IPv4 Internet Teredo Relay IPv6 Internet IPv6 over Private IPv4 IPv4/UDP Tunnel Address
1. Teredo Client sends a Ping6 to the IPv6-only Client via the Teredo Server 2. Teredo Server forwards the echo request to the IPv6 Client 3. IPv6-only Client sends the echo reply to the Teredo Client via the Teredo Relay 4. Teredo Relay sends a bubble packet to Teredo Client via the Teredo Server 5. Teredo Server sends a bubble packet with origin indication to the Teredo Client 6. Teredo Client sends a bubble packet to the Teredo Relay 7. Teredo Relay now forwards echo reply to the Teredo Client 8. Teredo Client can now forward packets directly to the IPv6-only Client via the Teredo Relay 182 IPv6 Technology Generic packet tunneling in IPv6 RFC 2473
Specifies a method and generic mechanisms by which a packet is encapsulated and carried as payload within an IPv6 packet. The resulting packet is called an IPv6 tunnel packet. The forwarding path between the source and destination of the tunnel packet is called an IPv6 tunnel. The technique is called IPv6 tunneling. In addition to the description of generic IPv6 tunneling mechanisms, specific mechanisms for tunneling IPv6 and IPv4 packets are also described herein.
183 IPv6 Technology Tunnel Broker RFC 3053
Tunnel brokers can be seen as virtual IPv6 ISPs, providing IPv6 connectivity to users already connected to the IPv4 Internet. There many tunnel brokers available so that the user will just have to pick one see gogo6 at http://www.gogo6.com/4105/gogo6-takeover.asp Requires special application software to be installed on the Client Uses a Tunnel Broker and Tunnel Server model The Tunnel Broker provides the Client with a global IPv6 address and the IPv4 address of the Tunnel Server Client uses the Tunnel Setup Protocol The Tunnel Server acts as the gateway between the IPv6 and IPvy6 internets Client connected to IPv4 networks encapsulate their IPv6 packets in IPv4 for transport to the Tunnel server via normally routed IPv4 mechanisms
184 IPv6 Technology Tunnel Broker Diagram
Tunnel Broker
TSP V4
IPv6 DNS Client Dual Stack IPv4 Tunnel Server IPv6
185 IPv6 Technology RFC 2529 (6over4) Deprecated
Host-to-host, host-to-router, and router-to-host automatic tunneling technology. Also known as IPv4 multicast tunneling Provides unicast and multicast IPv6 connectivity between IPv6 nodes across an IPv4 intranet. Uses a valid 64-bit prefix + Inteface ID ::wwxx:yyzz By default, 6over4 hosts automatically configure the link- local address FE80::WWXX:YYZZ on each 6over4 interface. 6over4 treats an IPv4 infrastructure as a single link with multicast capabilities. This means that Neighbor Discovery processes work as they do over a physical link with multicast capabilities.
186 IPv6 Technology Translators
Actually re-write to IP and possibly application layers Network level translators Stateless IP/ICMP Translation Algorithm (SIIT) (RFC 2765) NAT-PT (RFC 2766) NAT64 + DNS64 Bump in the Stack (BIS) (RFC 2767) Transport level translators Transport Relay Translator (TRT) (RFC 3142) Application level translators Bump in the API (BIA)(RFC 3338) SOCKS64 (RFC 3089) Application Level Gateways (ALG)
187 IPv6 Technology Stateless IP/ICMP Translation (SIIT)
Translator replaces packet headers IPv4 IPv6 Translates ICMP messages Contents of message translated ICMP pseudo-header checksum added Fragments IPv4 messages to fit IPv6 MTU when necessary Uses IPv4-translated addresses to refer to IPv6-enabled nodes 0:0:ffff:0:0:0/96 + 32-bit IPv4 address Uses IPv4-mapped addresses to refer to IPv4-only nodes 0:0:0:0:0:ffff/96 + 32-bit IPv4 address Requires IPv6 hosts to acquire an IPv4 address SIIT must know these addresses
188 IPv6 Technology SIIT Diagram
204.127.202.4 IPv4 Network Source = 216.148.227.68 Dest = 204.127.202.4 IPv6 Network Source = 204.127.202.4 SIIT Dest = 216.148.227.68 Source = ::ffff:0:216.148.227.68 Dest = ::ffff:204.127.202.4
Source = ::ffff:204.127.202.4 Dest = ::ffff:0:216.148.227.68 SIIT also changes: •Traffic Class TOS 3ffe:3700:1100:1:210:a4ff:fea0:bc97 •Payload length 216.148.227.68 •Protocol Number NH Number •TTL Hop Limit
189 IPv6 Technology Network Address Translation - Protocol Translation (NAT-PT) Stateful address translation - tracks supported sessions Inbound and outbound session packets must traverse the same NAT Uses SIIT for protocol translation As some data cannot be translated, this is a best effort. Two variations: Basic NAT-PT provides translation of IPv6 addresses to a pool of IPv4 addresses (like IPv4 NAT) NAPT-PT manipulates IPv6 port numbers so that multiple IPv6 sources can share a single IPv4 address (like IPv4 PAT) IPv4 address translation to IPv6 is relatively easy. The NAT-PT adds an IPv6 prefix to the upper 96 bits of the IPv6 address. The IPv4 address is added as the lower 32 bits of the address. IPv6 address translation to IPv4 is achieved using the NAT-PT IPv4 pool. Each IPv4 pool address can be used as an alias for an IPv6 address. Replies that arrive at NAT-PT from the IPv4 network are translated back to the associated IPv6 address.
190 IPv6 Technology NAT-PT Example: DNS Lookup
IPv6 IPv4 IPv4 Pool: 120.130.26/24 Network Network IPv6 prefix: 3ffe:3700:1100:2/64
DNS
v4host.4net.org v4host.4net.org? NAT-PT A 204.127.202.4
v4host.4net.org v4host.4net.org AAAA 3ffe:3700:1100:2::204.127.202.4 204.127.202.4
v6host.6net.com 3ffe:3700:1100:1:210:a4ff:fea0:bc97
191 IPv6 Technology NAT-PT Example: Address Translation
IPv6 IPv4 IPv4 Pool: 120.130.26/24 Network Network IPv6 prefix: 3ffe:3700:1100:2/64 Mapping Table DNS Inside Outside 3ffe:3700:1100:1:210:a4ff:fea0:bc97 120.130.26.10
Source = 120.130.26.10 Source = 3ffe:3700:1100:1:210:a4ff:fea0:bc97 Dest = 204.127.202.4 Dest = 3ffe:3700:1100:2::204.127.202.4 NAT-PT
Source = 204.127.202.4 Dest = 120.130.26.10 v4host.4net.org Source = 3ffe:3700:1100:2::204.127.202.4 204.127.202.4 Dest = 3ffe:3700:1100:1:210:a4ff:fea0:bc97
v6host.6net.com 3ffe:3700:1100:1:210:a4ff:fea0:bc97
192 IPv6 Technology NAT64 + DNS64 (Internet Drafts)
Because NAT-PT is dead (security concerns) The replacement for NAT-PT is now called NAT64 and offers a translation between IPv6 and IPv4 in much of the same ways as NAT-PT. draft-ietf-behave-v6v4-xlate-stateful-01 NAT64 is combined with DNS64 to create the complete translation package to allow IPv6 clients to access IPv4 servers. One major issue with NAT-PT was the fact that it broke DNSSec. This has been addressed with DNS64 which moves the generation of IPv6 addresses into the clients trusted domain.
193 IPv6 Technology Bump-In-the-Stack (BIS) RFC 2767
Translator resides in host Allows IPv4 applications to run on IPv6 host Consists of Three components: Translator IPv4 IPv6 IPv4 Application Uses SIIT Address mapper TCP/IPv4 Extension Maintains IPv4 address pool Address Translator Name Mapper Maps IPv6 addresses to Resolver IPv6 IPv4 addresses Extension Name Resolver Network Card Drivers Manages DNS queries Converts AAAA records to Network Cards A records Similar to NAT-PT DNS ALG
194 IPv6 Technology Transport Relay Translator (TRT)
aka TCP/UDP Relay translates {TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, or vice versa Designed to require no extra modification on IPv6-only initiating hosts nor that on IPv4-only destination hosts. some other translation mechanisms need extra modifications on IPv6-only initiating hosts, thus limiting their possibility of deployment. The IPv6-to-IPv4 header converters have to take care of path MTU and fragmentation issues. However, TRT is free from this problem. TRT supports bidirectional traffic only. TRT needs a stateful TRT system between the communicating peers, just like NAT systems. Whereas SIIT use stateless translator systems which can avoid this single point of failure. Special code is necessary to relay NAT-unfriendly protocols. IPsec, cannot be used across TRT system. Covers the case when traffic is initiated by an IPv6-only host destined to an IPv4-only host only; i.e., not in the opposite direction.
195 IPv6 Technology TRT Diagram
Query to “special” DNS from v6host for v4host.4net.org returns: IPv4 AAAA fec0:0:0:1::204.127.202.4 v4host.4net.org Network 204.127.202.4
TCP/IPv4 Session Source = 216.148.227.68 Dest = 204.127.202.4
TCP/IPv4 Session Source = 204.127.202.4 TCP/IPv6 Session TRT Dest = 216.148.227.68 Source = 3ffe:3700:1100:1:210:a4ff:fea0:bc97 Dest = fec0:0:0:1::204.127.202.4 “Dummy” IPv6 Prefix = fec0:0:0:1::/64 IPv4 Address = 216.148.227.68 TCP/IPv6 Session Source = fec0:0:0:1::204.127.202.4 Dest = 3ffe:3700:1100:1:210:a4ff:fea0:bc97
v6host.6net.com IPv6 3ffe:3700:1100:1:210:a4ff:fea0:bc97 Network
196 IPv6 Technology Bump in the API (BIA) RFC 3338
Allows dual-stacked IPv6 hosts to use IPv4 applications Same goal as BIS, but translation is between IPv4 and IPv6 APIs API Translator resides between socket API module and IPv4/IPv6 TCP/IP modules No header translation required Uses SIIT for conversion mechanism
197 IPv6 Technology Bump in the API (BIA) continued
API Translator consists of three modules: Name Resolver intercepts IPv4 DNS calls uses IPv6 calls instead IPv4 Applications
Address Mapper Socket API (IPv4, IPv6)
maintains mappings of internal API Translator pool unassigned of IPv4 addresses (0.0.0.1 ~ 0.0.0.255) Name Address Function to IPv6 addresses Resolver Mapper Mapper
Function Mapper TCP (UDP)/IPv4 TCP (UDP)/IPv6
translates IPV4 socket API Network Card Drivers functions to IPv6 socket API functions and vice versa Network Cards
198 IPv6 Technology Application Level Gateways (ALG)
Necessary when application layer contains IP address. used for SIP or FTP for example Similar to ALGs used in firewalls and some NATs As we saw, NAT-PT must contain an ALG for DNS This allows end users to identify other hosts by domain name The DNS ALG translates addresses in DNS answer messages For example, if the originating host is IPv6 the IP address of the destination will be presented as an IPv6 address regardless of whether the destination is IPv4 or IPv6 Provides no DNS-security and is vulnerable to DoS attacks by depletion of address pools
199 IPv6 Technology Topics Overview
IPv6 Overview IPv6 Addressing IPv6 Header Structure ICMPv6 Overview Neighbor Discovery IPv4/IPv6 Transition IPv6 Routing Protocols
200 IPv6 Technology RIP for IPv6 RIPng
IPv6 Routing Protocols RIPng Overview RFC 2080 describes the RIPng IGP routing protocol for IPv6 RFC 2081 is the RIPng Protocol Applicability Statement It operates essentially the same as RIPv2 for IPv4 Although it is not backward compatible to RIPv2 It uses UDP port 521 (instead of 520) and has maximum 15 hops Operational procedures, timers and stability functions are the same Message format changed to carry larger IPv6 addresses Supports Triggered Updates and Split Horizon with Poison Reverse (hops=16)
A=16, B=1, C=2 A=1, B=16, C=16
Network A Network B Network C
A=16, B=16, C=1 A=2, B=1, C=16
202 IPv6 Technology IPv6 Related Functionality
It is an IPv6 only protocol and uses IPv6 for transport In a dual-stack environment you’ll need RIP (IPv4) and RIPng (IPv6) running as "ships in the night" It updates contain IPv6 prefix(s) and next-hop IPv6 address Although there is only a single next-hop field for all RTEs (route table entry) Each RTE also includes a route tag, prefix length, and metric (hop count) The source of the datagram, and next-hop if present, must be a link-local address RIP updates are sent to multicast address FF02::9
203 IPv6 Technology The RIPng packet format
Carried in IP + UDP Port 521
204 IPv6 Technology Route Table Entry (RTE) and Next Hop
Route Table Entry (RTE):
Next Hop Route Table Entry (RTE):
205 IPv6 Technology BGP for IPv6 BGP4+
IPv6 Routing Protocols What is BGP? RFC 4271
E-BGP is an exterior routing protocol spoken between BGP peers in different Autonomous Systems (ASs). I-BGP is interior routing protocol spoken between BGP peers in the same Autonomous System (AS).
E-BGP I-BGP
AS 1
E-BGP AS 3 E-BGP link I-BGP link AS 2 Physical link
NOTE: Each BGP link requires a separate TCP connection
207 IPv6 Technology BGP Protocol Operation
Each BGP session consists of exactly 2 BGP peers. If you wish to “Peer” with N routers then, you will establish N BGP sessions. Each BGP session uses TCP as the transport protocol. At the outset of a BGP session, each router will advertise the routes it wishes to share. Routes are not refreshed and are assumed to be good if they are not specifically withdrawn. Each route that is advertised includes attributes that describe the following: How the prefix (i.e., the network) came to be routed by BGP. The path of ASs through which the prefix has been advertised until this point. Metrics expressing degrees of preference for this prefix. Except for the prefixes themselves, the attributes carry the important information. Routing policies are used to enforce business agreements and affect the decisions about which routes to accept from and advertise to various BGP neighbors.
208 IPv6 Technology BGP Decision Process
Input Policy – Filtering based on IP prefixes, AS path information, and attribute information. Decision Process – Decide which routes to use to a certain destination based on the input policy. Routes – Are those identified by the decision process as usable and may also be advertised. Output Policy – Similar to input to determine which routes are advertised.
Routes Filtering Choose Best Routing Filtering Routes Received Route Table Sent Input Decision Output Routes Policy Process Policy
209 IPv6 Technology BGP vs. the OSI Model
RIP BGP
UDP TCP port 179 OSPF
IP Protocol 6
Data Link
Physical
210 IPv6 Technology BGP Message Types
A common header precedes all BGP messages. There are 4 types of BGP Messages: Open (1) is the first message sent after a TCP connection is established for each endpoint to identify itself and agree on protocol parameters. Update (2) is the primary message used to advertise and/or withdraw routes. Notification (3) is used to signal the presence of a errored condition before terminating the TCP (and therefore the BGP) session. Keepalive (4) messages are exchanges between BGP peers to confirm the connection is still alive. Route-refresh (5) messages facilitates non-disruptive routing policy changes.
IP TCP Marker Length Type BGP Message Type 20B 20B 16B 2B 1B Variable
BGP Common Header NOTE: The use of the Marker field for BGP Authentication has been deprecated.
211 IPv6 Technology BGP Session Establishment and Maintenance
AS 100 AS 200 Peer Peer Link Layer UP Initial TCP Syn Establish Establish TCP Syn/Ack TCP Session TCP Session TCP Ack Establish BGP Open Establish BGP Session BGP Open BGP Session TCP Ack BGP Session BGP Keepalive BGP Session Maintenance BGP Keepalive Maintenance TCP Ack BGP Update Send Routes BGP Update BGP Update Send Routes BGP Update TCP Ack BGP Keepalive BGP Session BGP Session Maintenance Maintenance BGP Keepalive TCP Ack
212 IPv6 Technology OPEN Message Format
After a TCP connection is established, the first message sent by each side is an OPEN message (BGP message Type=1). If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged. In addition to the BGP header, the OPEN message contains the following fields:
1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Version My Autonomous System Hold Time BGP Identifier Opt Parm Len
Optional Parameters
213 IPv6 Technology OPEN Message – Optional Parameters
Optional Parameters – This field may contain a list of optional parameters, where each parameter is encoded as a Parameter Type, Parameter Length, Parameter Value (TLV) triplet:
1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Parm. Type Parm. Length Parameter Value (variable)
RFC 1771 defines only a single Optional Parameters: Authentication Information (Parameter Type 1): 1 0 1 2 3 4 5 6 7 Deprecated Auth. Code
Authentication Data
214 IPv6 Technology Capabilities Advertisement with BGP-4 RFC 3392
The Optional Capabilities Parameter parameter lists the capabilities supported by the BGP speaker (Parameter Type 2). A BGP speaker includes this parameter in its OPEN message to its BGP peer. A BGP speaker that supports a particular capability may use this capability with its peer after the speaker determines that the peer supports this capability. A BGP speaker determines that its peer doesn't support capabilities advertisement, if in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter.
1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Capability Code Cap. Length Capability Value (variable)
215 IPv6 Technology Capability Codes
Value Description Reference 0 Reserved RFC 3392 1 Multiprotocol Extensions for BGP-4 RFC 2858 2 Route Refresh Capability for BGP-4 RFC 2918 3 Cooperative Route Filtering Capability Draft 4 Multiple routes to a destination capability RFC 3107 5-63 Unassigned 64 Graceful Restart Capability Draft 65 Support for 4-octet AS number capability Draft 66 Deprecated (2003-03-06) 67 Support for Dynamic Capability (capability specific) Draft 68-127 Unassigned 128-255 Vendor Specific
216 IPv6 Technology Multiprotocol Extensions RFC 2858 A BGP speaker that uses Multiprotocol Extensions should use the Capabilities Optional Parameter (Parameter Type 2). Uses of Multiprotocol BGP (BGP4+) include carrying IPv6 routes, MPLS labels, and VPN route information. Carried in the “Parameter Value” field is one or more of: 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Capability Code Cap. Length Capability Value (variable) 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Value: Address Family Identifier AFI Reserved SAFI
Capability Code = 1 for Multiprotocol Extensions Capability Length = 4 AFI = 1 for IPv4 and 2 for IPv6 SAFI = 1 for unicast forwarding, 2 for multicast, 3 for both
217 IPv6 Technology Update Message Format UPDATE messages are used to transfer routing information between BGP peers (BGP message Type=2). The information in the UPDATE packet can be used to construct a graph describing the relationships of the various Autonomous Systems. An UPDATE message is used to advertise a single feasible route to a peer, or to withdraw multiple unfeasible routes from service. An UPDATE message may simultaneously advertise a feasible route and withdraw multiple unfeasible routes from service. The UPDATE message always includes the fixed-size BGP header, and can optionally include the other fields as shown below:
1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Unfeasible Routes Length Unreachable Routes Withdrawn Routes (variable) Total Path Attribute Length Path Attributes Path Attributes (variable) Reachable Routes Network Layer Reachability Info (variable)
218 IPv6 Technology Update Message – Withdrawn Routes
This is a variable length field that contains a list of IP address prefixes for the routes that are being withdrawn from service. Each IP address prefix is encoded as a 2-tuple of the form (length and prefix).
Length (1octet) 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Prefix (variable) Unfeasible Routes Length Length (1octet) Withdrawn Routes (variable) Prefix (variable) Total Path Attribute Length Path Attributes (variable) Length (1octet) Network Layer Reachability Info (variable) Prefix (variable)
219 IPv6 Technology Update Message – Path Attributes
A variable length sequence of path attributes is present in every UPDATE. Each path attribute is TLV encoded as attribute type, attribute length, and attribute value of variable length. Attribute Type is a two-octet field that consists of the Attribute Flags octet followed by the Attribute Type Code octet. 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Unfeasible Routes Length 2 bytes 1-2 bytes variable Withdrawn Routes (variable) Attr. Type Attr. Length Attr. Value Total Path Attribute Length Path Attributes (variable) Attr. Type Attr. Length Attr. Value Network Layer Reachability Info (variable) Attr. Type Attr. Length Attr. Value
1 byte 1 byte Attr. Flags Attr. Type Code
220 IPv6 Technology Update Message – Network Layer Reachability Information (NLRI) This variable length field contains a list of IPv4 address prefixes that are being advertises as reachable (IPv6 addresses are carried in the attributes). The length in octets of the Network Layer Reachability Information is not encoded explicitly. Reachability information is encoded as one or more 2-tuples of the form (length and prefix). An initial UPDATE message will contain mostly NLRIs. Later updates may contain a mixture of withdrawn routes and NLRIs. 1 2 Length (1octet) NLRI 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Prefix (variable) Unfeasible Routes Length Withdrawn Routes (variable) Length (1octet) Total Path Attribute Length Prefix (variable) Path Attributes (variable) Length (1octet) Network Layer Reachability Info (variable) Prefix (variable)
221 IPv6 Technology Notification Message Format
A NOTIFICATION message is sent when an error condition is detected (BGP message Type=3). The BGP connection is closed immediately after sending it. In addition to the fixed-size BGP header, the NOTIFICATION message contains the following fields:
1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Error Code Error subcode Data Data Continued ...
222 IPv6 Technology Keepalive Message Format
BGP does not use any transport protocol-based keep-alive mechanism (i.e., TCP has no keepalives) to determine if peers are reachable. Instead, BGP KEEPALIVE messages are exchanged between peers often enough as not to cause the Hold Timer to expire. A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more frequently than one per second. If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent. NOTE: If the negotiated Hold Time value is zero, then the Hold Time timer and KeepAlive timers are not started. KEEPALIVE message consists of only message header and has a length of 19 octets.
IP TCP Marker Length Type=4 20B 20B 16B 2B 1B
BGP Common Header
223 IPv6 Technology Update Message – Path Attributes
Path attributes are carried in the UPDATE message. Path attributes fall into four separate categories: 1. Well-known mandatory. 2. Well-known discretionary. 3. Optional transitive. 4. Optional non-transitive.
1 2 2 bytes 1-2 bytes variable 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Attr. Type Attr. Length Attr. Value Unfeasible Routes Length Withdrawn Routes (variable) Attr. Type Attr. Length Attr. Value Total Path Attribute Length Attr. Type Attr. Length Attr. Value Path Attributes (variable) 1 byte 1 byte Network Layer Reachability Info (variable) Attr. Flags Attr. Type Code
224 IPv6 Technology Path Attributes – Attribute Flags
The Attribute Flags octet is defined as follows: Optional bit (O) defines whether the attribute is optional (set to 1) or well-known. Transitive bit (T) defines whether an optional attribute is transitive (set to 1) or non-transitive (set to 0). Partial bit (P) defines whether the information contained in the optional transitive attribute is partial (set to 1) Attr. Type Attr. Length Attr. Value or complete (set to 0). 1 byte 1 byte Extended Length bit (E) defines whether the Attribute Length is Attr. Flags Attr. Type Code one octet (if set to 0) or two octets (if set to 1). The low 4 bits of the Attribute Flags octet are unused and 0 1 2 3 4 5 6 7 must be zero (MBZ). O T P E MBZ
225 IPv6 Technology Path Attributes – Types
# Code Reference Comment Length 1 ORIGIN RFC 1771 Well-known, mandatory 1 2 AS_PATH RFC 1771 Well-known, mandatory 2 + 2 x n 3 NEXT_HOP RFC 1771 Well-known, mandatory 4 4 MULTI_EXIT_DISC RFC 1771 Optional, non-transitive 4 5 LOCAL_PREF RFC 1771 Well-known, discretionary 4 6 ATOMIC_AGGREGATE RFC 1771 Well-known, discretionary 0 7 AGGREGATOR RFC 1771 Optional, transitive 6 8 COMMUNITY RFC 1997 Optional, transitive # x 4 9 ORIGINATOR_ID RFC 2796 Optional, non-transitive 4 10 CLUSTER_LIST RFC 2796 Optional, non-transitive # x 4
226 IPv6 Technology Path Attributes – Types Continued
# Code Reference Comment Length 11 DPA Draft 12 ADVERTISER RFC 1863 13 RCID_PATH/CLUSTER_ID RFC 1863 14 MP_REACH_NLRI RFC 2858 Optional, non-transitive 4+ 15 MP_UNREACH_NLRI RFC 2858 Optional, non-transitive 3+ 16 EXTENDED COMMUNITIES Draft Optional, transitive # x 8 17 NEW_AS_PATH Draft 18 NEW_AGGREGATOR Draft 19 SAFI Specific Attribute Draft 20 Connector Attribute Draft 21-254 Unassigned 255reserved for development
227 IPv6 Technology Multiprotocol Extensions for BGP-4 RFC 2858
Defines two new attributes to carry other (IPv6 too) NRLIs: Multiprotocol Reachable NLRI (MP_REACH_NLRI) is Type Code 14 Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI) is Type Code 15 Both of these attributes are optional and non-transitive The MP_REACH_NLRI attribute is encoded as shown below:
Address Family Identifier (2 octets) Subsequent Address Family Identifier (1 octet) Length of Next Hop Network Address (1 octet) Network Address of Next Hop (variable) Subnetwork Points of Attachment(s) (variable) Network Layer Reachability Information (variable)
NLRI = Network Layer Reachability Information
228 IPv6 Technology MP_REACH_NLRI Field Definitions
Address Family Identifier (AFI) carries the identity of the Network Layer protocol associated with the Network Address that follows (2 = IPv6). Subsequent Address Family Identifier provides additional information about the type of NLRI carried in the attribute. Network Address of Next Hop contains the Network Address of the router that should be used as the next hop to the destination(s) listed in the MP_NLRI attribute. SNPAs is some or all of the Subnetwork Points of Attachment(s) that exist within the local system. NLRIs are the feasible routes that are being advertised in this attribute (the format is determined by the Subsequent Address Family Identifier field).
229 IPv6 Technology IPv6 Address Scopes
IPv6 defines 3 unicast address scopes: global, site-local and link-local BGP-4 makes no distinction between global and site-local addresses Network administrators must however respect address scope restrictions Only link-local address can be used when generating ICMP Redirect Messages Link-local addresses are not, however, well suited to be used as next hop attributes in BGP-4 Therefore, with BGP-4 it is sometimes necessary to announce a next hop attribute that consists of a global address and a link-local address.
230 IPv6 Technology Constructing the Next Hop field w/IPv6
A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop. The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field. The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. As a consequence, a BGP speaker that advertises a route to an internal peer may modify the Network Address of Next Hop field by removing the link-local IPv6 address of the next hop.
231 IPv6 Technology Rules for Carrying Other Attributes
An UPDATE message that carries the MP_REACH_NLRI must also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Also, in IBGP exchanges such a message must also carry the LOCAL_PREF attribute. An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute.
232 IPv6 Technology NLRI Encoding
The Network Layer Reachability information is encoded as one or more tuples of the form
Length (1 octet) Prefix (variable)
233 IPv6 Technology Subsequent Address Family Identifier
0 - reserved 1 - used for unicast forwarding 2 - used for multicast forwarding 3 - used for both unicast and multicast forwarding 4 to 63 assigned by IANA using the IETF consensus policy 4 - used for MPLS Labels 64 to 127 assigned by IANA using the first come first served policy 128 to 255 are for "private use" (i.e., not assigned by IANA) 128 - used for VPN-IPv4 Route Distinguisher
234 IPv6 Technology Transport Considerations
TCP connections, on top of which BGP-4 messages are exchanged, can be established either over IPv4 or IPv6. Although when using TCP over IPv4 as a transport for IPv6 reachability information, additional explicit configuration of the peer's network address is required. The BGP Identifier is a 32 bit unsigned integer exchanged between two peers at session establishment time, within an OPEN message. The use of TCP over IPv6 as transport protocol for IPv6 reachability information also has the advantage of providing explicit confirmation of IPv6 network reachability between two peers.
235 IPv6 Technology OSPF for IPv6 OSPFv3
IPv6 Routing Protocols OSPF for IPv6 RFC 5340 (OSPFv3)
Operates very similar to IPv4 OSPFv2 (link-state protocol) Sends topology and prefix information separately New LSA Types defined Protocol processing per-link, not per-subnet IPv6 uses the term "link" to indicate communication; instead of network and subnet Interfaces connect to links; Multiple IP subnets can be assigned to a single link; and two nodes can talk directly over a single link, even if they do not share a common IP subnet
237 IPv6 Technology Differences with IPv4
Authentication changes Packet format changes LSA format changes Handling unknown LSA types Stub area support Identifying neighbors by Router ID Protocol processing per-link, not per-subnet Removal of addressing semantics Addition of Flooding scope Explicit support for multiple instances per link Use of link-local addresses
238 IPv6 Technology OSPFv3 and OSPFv2 Similarities
Basic packet types Hello, DBD, LSR, LSU, LSA Mechanisms for neighbor discovery and adjacency formation Interface types P2P, P2MP, Broadcast, NBMA, Virtual LSA flooding and aging Nearly identical LSA types Both use DRs and BDRs for transit links
239 IPv6 Technology OSPFv3 Packet Types
OSPFv3 has the same 5 packet types but some fields have been changed. All OSPFv3 packets have a 16 byte common header vs. the 24 byte header in OSPFv2
Packet Type Description 1 Hello 2 Database Description 3 Link State Request 4 Link State Update 5 Link State Acknowledgement
240 IPv6 Technology The Designated Router (DR)
Turns this Into this
Of course there could be a Backup DR too (BDR) 241 IPv6 Technology OSPF Protocol Exchange (Simplified)
0 secs. Interface Interface Router B Router A
InitHello Init
2-WayHello 2-Way ExStartData Base Description ExStart
ExchangeData Base Description Exchange Loading LS Req/LS Advertisement Loading
LoadingLS Req/LS Advertisement Loading
FullLS Ack Full
242 IPv6 Technology OSPF Common Header
Version Type Packet Length Router ID OSPFv2 Area ID Checksum AuType Authentication Authentication
Version Type Packet Length OSPFv3 Router ID Area ID Checksum Instance ID 0
243 IPv6 Technology OSPFv3 Common Header
Size of the header is reduced from 24 bytes to 16 Router ID is still a 32 bit number uniquely identifying a router in the domain Instance ID is a new field that is used to have multiple OSPF process instance per link. In order that 2 instance talk to each other they need to have the same instance ID. By default it is 0 and for any additional instance it is increased, Instance ID has local link significance only Authentication fields have been suppressed
244 IPv6 Technology Hello Packet: v2 vs. v3 (OSPF common header is not represented)
Network Mask Hello Interval Options Priority OSPFv2 Router Dead Interval Designated Router Backup Designated Router Neighbor ID Neighbor ID
Interface ID Priority Options OSPFv3 Hello Interval Dead Interval Designated Router Backup Designated Router Neighbor ID Neighbor ID 245 IPv6 Technology OSPFv3 Hello Packet
Mask field has been replaced by Interface ID which is a 32- bit number uniquely identify an interface, virtual link gets its own interface ID Option field has been increased to 24-bit from 8-bits Hello and Dead intervals have been reduced to 16-bits from 32 DR and BDR are still 32-bit field and contain the Router ID of DR /BDR instead of IP address. Router ID and Link ID uniquely identify the DR on an interface
246 IPv6 Technology Processing a Hello Packet in v3
Interface ID is copied into the hello packet Network mask is not needed adjacency is formed on the link local as v6 runs on per link instead of per subnet The choice of DR and BDR in hello is indicated by the router ID instead of their IP interface address on the link Neighbors IP address is set to the IPv6 source address in the IPv6 header of the received hello packet.
247 IPv6 Technology IPv6 multicast address used in OSPFv3
The multicast address AllSPFRouters is FF02::5 Note that 02 means that this is a permanent address and has link scope. The multicast address ALLDRouters is FF02::6 Used for communication with DR & BDR
248 IPv6 Technology Database Description Packet (OSPF common header is not represented)
MTU Options 00000IMMS OSPFv2 DD Sequence Number LSA Headers LSA Headers
0Options OSPFv3 MTU 0 00000IMMS DD Sequence Number LSA Headers LSA Headers
249 IPv6 Technology Link State Request Packet (OSPF common header is not represented)
LS Type OSPFv2 Link State ID Advertising Router
0LS Type OSPFv3 Link State ID Advertising Router
250 IPv6 Technology Link State Request
Every LSA is uniquely identified by: LS type, Link State ID, Advertising router OSPFv3 has the same field as OSPFv2 Note that LS Type field is now 2 bytes and it has different coding as for OSPFv2 since there are 2 bits that indicates the flooding scope. (later on flooding)
251 IPv6 Technology Link State Update Packet (OSPF common header is not represented)
Nothing has changed
Number of LSAs
LSA Header & Body
LSA Header & Body
252 IPv6 Technology Link State Update
For IPv6, the eligible interfaces are selected based on the following factors: The LSA's flooding scope (will talk more later) Whether the LSA has a recognized LS type. The setting of the U-bit in the LS type. If the U-bit is set to 0, unrecognized LS types are treated as having link-local scope. If set to 1, unrecognized LS types are stored and flooded as if they were recognized.
253 IPv6 Technology Link Sate Acknowledgement (OSPF common header is not represented)
Each newly received LSA must be acknowledged. This is usually done by sending Link State Acknowledgment packets. Acknowledgments can also be accomplished implicitly by sending Link State Update packets
254 IPv6 Technology OSPF Options Field
The OSPF Options field is present in OSPF Hello packets, Database Description packets and all LSAs. The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers
OSPFv2 ODCEAN/PMCE
OSPFv3 01623 …**DCRNXEV6
255 IPv6 Technology OSPF Options
In OSPFv2 Option field was a 8-bit field in Hello packet, DD packet and LSA header ( we will talk separately about this in the LSA section). In OSPFv3 option field has been increased into 24-bit and moved to the body of certain LSA (see detail later) The option field in Hello and DD packet has been also increased to 24-bit. Unused bits have been suppressed and two new bit have been introduced.
256 IPv6 Technology Option Bits Details
V6-bit - If this bit is clear, the router/link should be excluded from IPv6 routing calculations. E-bit - describes the way AS-external-LSAs are flooded. x-bit - was previously used by MOSPF which has now been deprecated. N-bit - indicates whether or not the router is attached to an NSSA. R-bit - Indicates whether the originator is an active router. Could be used by a multi-homed host that wants to participate in routing, but does not want to forward non-locally addressed packets. DC-bit - This bit describes the router's handling of demand circuits. *bits - reserved for migration of OSPFv2 protocol extensions.
01623 …**DCRNXEV6
257 IPv6 Technology OSPF Flooding
OSPFv2 originally had two flooding scopes, AS wide and area wide. In OSPFv3 there are three flooding scopes AS scope - LSA is flooded through out the AS Area scope - LSA is flooded only within an area Link-local scope - LSA is flooded only on the local link. We will come back to flooding after the LSA discussion
258 IPv6 Technology OSPF LSA Header
LS Age Options LS Type OSPFv2 Link State ID Advertising Router Sequence Number Checksum Length
LS Age LS Type OSPFv3 Link State ID Advertising Router Sequence Number Checksum Length
259 IPv6 Technology LSA Header Details
All LSAs begin with a common 20 byte header just like OSPFv2 OSPFv3 increased the LS Type field from 1 byte to 2 bytes, since option field is now removed to the body of the LSA and three new bit have been defined LS Age: The time in seconds since the LSA was originated LS Type: The LS type field indicates the function performed by the LSA The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality (more later) Link state ID: This field identifies the piece of the routing domain that is being described by the LSA Depending on the LSA's LS type, the Link State ID takes on its value The behavior of assigning this value has changed from v4 to v6, we will talk about the change of behavior as we go to each of the LSAs Advertising Router: ID of the router originating the packet
260 IPv6 Technology LSA Type Bits & Function Codes
The LS Type Field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA Function Code) indicate the LSA's specific functionality. For example Router LSA is not coded as Type 1, but Type 0x2001 (since S1 is set, it has an area flooding scope)
U S2 S1 Function Code 0 0 1 0 0000 0000 0001 Basically the Function Code matches the same LSA type as in OSPFv2.
261 IPv6 Technology LSA Type Bits continued
S2 / S1 bit indicates the three flooding scopes:
S2 S1 Flooding Scope 00Link-Local 0 1 Area 1 0 Autonomous System 11Reserved U (Unrecognized) bit is used to indicate a router how to handle a LSA if it doesn’t recognize it:
U-bit LSA Handling 0 Treat this LSA as if it has link-local scope Store and flood this LSA as if type was 1 understood
262 IPv6 Technology List of LSA Types
Here is the list of LSA types in OSPFv3:
LSA Name LS Type Code Flooding Scope Function Code Router LSA 0x2001 Area 1 Network LSA 0x2002 Area 2 Inter-Area Prefix LSA 0x2003 Area 3 Inter-Area Router LSA 0x2004 Area 4 AS-External LSA 0x4005 AS 5 Group Membership LSA 0x2006 Area 6 NSSA External LSA 0x2007 Area 7 Link LSA 0x0008 Link-local 8 Intra-Area Prefix LSA 0x2009 Area 9
263 IPv6 Technology OSPF Router LSA OSPFv2: 0 0 0 0 0 V E B 0 Number of Links Link ID Link Data Type # ToS Metric … TOS 0 TOS Metric OSPFv3: 0 0 0 Nt W V E B Options Type 0 Metric Interface ID Neighbor Interface ID Neighbor Router ID
264 IPv6 Technology Router LSA Field Descriptions
LS Type 0x2001; now announces only topology information Each router in an area originates one or more router-LSAs which describes the state and cost of the router's interfaces to the area. An IPv6 router sends a separate Router LSA for each of its links which are distinguished by their Link-State IDs. Interface ID has shed any addressing semantics. Now they are assigned arbitrarily (generally the MIB II IfIndex). For example, an An IPv6 router originating multiple Router-LSAs could start by assigning the first a Link State ID of 0.0.0.1, the second a Link State ID of 0.0.0.2 . Type field descriptions: Bit V - virtual link endpoint 1 - Point-to-point Bit E - is an AS boundary router (ASBR) 2 - Connection to a transit network Bit B - is an area border router (ABR) 3 - Reserved Bit x - was previously used by MOSPF 4 - Virtual link Bit Nt- is an NSSA border router OSPFv2 link type 3 (Stub link) has been suppressed Neighbor Interface ID - the Interface ID the neighbor router (or the attached link's DR for Type 2); Neighbor Router ID - the Router ID the neighbor router
265 IPv6 Technology OSPF Router LSA of R3 for Area
R1 DR R3#show ip ospf database router R4 Router Link States (Area 1) 1 Area 0 64 LS age: 0 Always 0 at origination Options: (V6-Bit E-Bit R-bit DC-Bit) This is an IPv6 router R3 LS Type: Router Links This is a router LSA Link State ID: 0 Advertising Router: 26.50.0.2 Router ID of R3 Area Border Router bit B = 1 Number of Links: 1
Link connected to: a Transit Network Link Metric: 1 Cost to reach the interface Local Interface ID: 3 IfIndex Neighbor (DR) Interface ID: 3 IfIndex Neighbor (DR) Router ID: 26.50.0.1 Router ID of R1
266 IPv6 Technology OSPF Network LSA
OSPFv2: Network Mask Attached Router Attached Router
OSPFv3: 0Options Attached Router Attached Router
267 IPv6 Technology Network LSA Field Descriptions
LS Type 0x2002; still have area flooding scope Originated by the DR for every broadcast or NBMA link having two or more attached routers Lists all router's Router IDs attached to the link including the DR's; does not contain a Network Mask All addressing information formerly contained in the IPv4 Network LSA has now been consigned to Intra-Area Prefix-LSAs Link State ID of the common header is set to the Interface ID of the DR The Options field is set to the logical OR of the Options fields contained within the associated link. In this way the network link exhibits a capability when at least one of the link's routers requests that the capability be asserted.
268 IPv6 Technology OSPF Network LSA
R3#show ip ospf database network
LS age: 992 Options: (V6-Bit E-Bit R-bit DC-Bit) LS Type: Network Links Link State ID: 3 (Interface ID of Designated Router) Advertising Router: 26.50.0.1
Attached Router: 26.50.0.1 Attached Router: 26.50.0.2 DR 26.50.0. Attached Router: 26.50.0.4 4 26.50.0. 3 Attached Router: 26.50.0.3 1 R4 Area 0 R1 26.50.0. 3 26.50.0. 64 2 R3 R2 R6
269 IPv6 Technology OSPF Intra-Area Prefix LSA
270 IPv6 Technology OSPF Intra-Area Prefix LSA Description
LS Type 0x2009; this is a new LSA in OSPFv3 Used in order to advertise one or more IPv6 prefixes. The prefixes are associated with router segment, Stub network segment or transit network segment. Whereas with OSPFv2 link address information was carried directly in Router and Network LSAs # Prefixes is the number of prefixes advertised Each IPv6 address is associate with: Address Prefix, Prefix Length, and Prefix Options The three fields Referenced LS type, Referenced Link State ID, Referenced Advertising Router identifies the Router LSA or Network LSA that the Intra-Area-Prefix-LSA should be associated with
271 IPv6 Technology OSPF Intra-Area Prefix LSA Options
PMCLANU
This 8 bit field serves as input to the various routing calculations NU-bit: The "no unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculations, otherwise it should be included. LA: "local address" capability bit. If set, the /128 prefix is actually an IPv6 interface address of the advertising router. MC: the "multicast" capability bit. If set, the prefix should be included in IPv6 multicast routing calculations. P: The "propagate" bit. Set on NSSA area prefixes that should be re- advertised at the NSSA area border.
272 IPv6 Technology OSPF Intra-Area Prefix LSA Transit
R3#show ip ospf database prefix
Net Link States (Area 1)
Routing Bit Set on this LSA DR 26.50.0. LS age: 428 26.50.0. 3 4 LS Type: Intra-Area-Prefix-LSA 1 R4 Link State ID: 1003 Area 0 Advertising Router: 26.50.0.1 R1 26.50.0. 3 26.50.0. 64 LS Seq Number: 80000009 2 Checksum: 0x5899 R3 R6 Length: 44 R2 3ffe:ffff:1::/64 Referenced LSA Type: 2002 Referenced Link State ID: 3 Referenced Advertising Router: 26.50.0.1 Number of Prefixes: 1 Prefix Address: 3FFE:FFFF:1:: Prefix Length: 64, Options: None, Metric: 0
273 IPv6 Technology OSPF Link LSA
Router Priority Options
Link Local Interface Address
Number of Prefixes Prefix Length Prefix Options 0
Address Prefix
Prefix Length Prefix Options 0
Address Prefix
274 IPv6 Technology OSPF Link LSA Field Descriptions
LS Type 0x2008; this is a new LSA in OSPFv3 Generated for every link, and flooded only on a given link. It has the following three purposes: 1. Since Router and Network LSAs only announce topology information, the Link-LSA announces the link-local address of a router to all other routers attached to the link. This is needed for next hop calculation. 2. Link LSAs announce to other routers attached to the link a list of IPv6 prefixes associated with the link; a link can have more than one IPv6 address. 3. On a Multi-access networks, Link LSAs will announce the options capability of a given router to DR this will allow the DR to sets it’s options capabilities in Network LSA as OR'd options of all attached routers. Link local interface address is used for next hop calculation # Prefixes is the number of prefix advertised Link LSAs can also advertise a list of IPv6 prefixes identified by Address prefix, PrefixLength, and PrefixOptions to other attached routers. For example a DR will include this list of IPv6 prefix advertised by a router in its Intra-area Prefix LSA Link State ID in the common header of the Link LSA is set to router’s Interface ID on the link.
275 IPv6 Technology Link LSA of R3 For LAN1
R3#show ip ospf database link DR
Link (Type-8) Link States (Area 0) R4 R1 1 Area 0 LS age: 1936 64 Options: (V6-Bit E-Bit R-bit DC-Bit) LS Type: Link-LSA (Interface: FastEthernet0/0) R2 R3 Link State ID: 3 (Interface ID) 3ffe:ffff:1::/64 Advertising Router: 26.50.0.3 LS Seq Number: 8000002E Checksum: 0xD7B3 Length: 68 Router Priority: 1 Link Local Address: FE80::204:C1FF:FEDB:2FA0 Number of Prefixes: 2 Prefix Address: 3FFE:FFFF:1:: Prefix Length: 64, Options: None
276 IPv6 Technology OSPF Inter-Area Prefix LSA
Network Mask OSPFv2 0Metric TOS TOS Metric
0Metric OSPFv3 Prefix Length Prefix Options 0
Address Prefix
277 IPv6 Technology OSPF Inter-Area Prefix LSA Description
LS Type 0x2003; similar to an OSPFv2 inter-area LSA Type 3 Announced by ABRs of destinations outside of the area All TOS field have been suppressed In OSPFv2 Link State ID in the LSA header contained IP destination out side of the area and the mask is in the body of the LSA In OSPFv3 Link State ID is just a fragment number and the prefix is moved into the body of the LSA All Prefix in OSPFv3 is defined by 3 fields: Address Prefix, Prefix Length, and Prefix Options
278 IPv6 Technology OSPF Inter-Area Prefix LSA
R6#sh ipv6 ospf database inter-area prefix 3FFE:FFFF:2::/64
Inter Area Prefix Link States (Area 0) Routing Bit Set on this LSA LS age: 81 LS Type: Inter Area Prefix Links Link State ID: 5 Advertising Router: 26.50.0.3 Metric: 65 Prefix Address: 3FFE:FFFF:2:: ABR Prefix Length: 64, Options: None 26.50.0. DR 3ffe:ffff:2:/64 1 R4 64 R1 ABR Area 0 26.50.0. 1 2 64 R2 R3 R6 3ffe:ffff:2::/64 metric 11 279 IPv6 Technology OSPF Inter-Area Router LSA
Network Mask OSPFv2 0Metric TOS TOS Metric
0Options OSPFv3 0Metric Destination Router ID LS Type 0x2004; announces the location of ASBR (Type 4 in OSPFv2) In OSPFv2 Link State ID in the header contain the Router ID of the ASBR In OSPFv3 Link State ID is just a fragment number and ASBR Router ID is inside the body of LSA The OSPFv2 the mask field is suppressed in OSPFv3 (was not used OSPFv2 either)
280 IPv6 Technology OSPF Inter-Area Router LSA Details on R3
R3#show ipv6 ospf database inter-area router
Inter Area Router Link States (Area 1) LS age: 60 Options: (V6-Bit E-Bit R-bit DC-Bit) LS Type: Inter Area Router Links Link State ID: 1207959556 Advertising Router: 26.50.0.3 Metric: 128 Destination Router ID: 72.0.0.4 Type 0x2004 External Route 3ffe:ffff:a::/64 R4 64 R1 ABR Area 0 ASBR RID 1 1 64 72.0.0.4 R3 64 R2 R3 R6 R8
281 IPv6 Technology OSPF External LSA
Network Mask . OSPFv2 E0000000 Metric Forwarding Address External Route Tag ETOS TOS Metric
00000EFT Metric Prefix Len Options Referenced LS Type . OSPFv3 Address Prefix (128 bits) Forwarding Address (128 bits, optional) External Route Tag (optional) Referenced Link State ID (optional)
282 IPv6 Technology OSPF External LSA Description
LS Type equal to 0x4005; has AS flooding scope (ABR does not modify them) NSSA External uses 0x2007 (area flooding scope) Describe destinations external to the AS (similar to Type 5 in OSPFv2) Here are some changes from OSPFv2: The Link State ID of an AS-external-LSA has lost all of its addressing semantics, it is used just to distinguish between multiple external LSA originated by the same ASBR The prefix is described by the Prefix Length, Prefix Options and Address Prefix fields embedded within the LSA body. Link-local addresses can never be advertised in AS-external-LSAs
283 IPv6 Technology OSPF External LSA continued
bit E - Type 1 and 2 as with OSPFv2; the type of external metric. set, the metric specified is a Type 2 external metric; the metric is considered larger than any intra-AS path. zero, the specified metric is a Type 1 external metric; it is expressed in the same units as other LSAs bit F - if set, a Forwarding Address has been included in the LSA bit T - if set, an External Route Tag has been included in the LSA Referenced LS type is normally set to zero and Referenced LS ID is not used If a router advertising an AS External LSA wants to announce additional information regarding external route that is not used by OSPF itself (for example BGP external route attribute) it sets Referenced LS type and Referenced Link State ID in order to announce additional information.
284 IPv6 Technology OSPF External LSA Details
R3#show ip ospf database external
Type-5 AS External Link States
Routing Bit Set on this LSA External Route LS age: 473 3ffe:ffff:a::/64 LS Type: AS External Link 64 Link State ID: 5 R4 RID ASBR Advertising Router: 72.0.0.4 Area 0 72.0.0.4 LS Seq Number: 80000001 64 64 Checksum: 0x77AB Length: 36 R3 R6 R8 Prefix Address: 3FFE:FFFF:A:: External Type 5 Prefix Length: 64, Metric Type: 2 Metric: 20
285 IPv6 Technology Thank You www.spirentcampus.com