IPv6 Tutorial
Gianluca Reali
1 IPv6 - Important changes
• Expanded Address Space – Address length quadrupled to 16 bytes • Header Format Simplification – Fixed length, optional headers are daisy-chained – IPv6 header is twice as long (40 bytes) as IPv4 header without options (20 bytes) • No checksumming at the IP network layer • No hop-by-hop segmentation – Path MTU discovery •Authentication and Privacy Capabilities – IPsec is mandated • No more broadcast
2 IPv4- Datagram
0 15 16 31
Version (4) IHL (4) Type of Service (8) Total Length (16) •Version = 4 • IHL - Internet Header Length = 5 with Identifier (16) Flag(3) Fragment Offset (13) no header options [min = 160 bits] [max = 512 bits] Protocol (8) Header Checksum (16) Time To Live (8) • Type of service , desired quality service Source Address (32) Prec. D T R 0 0 Destination Address (32) 0 1 2 3 4 5 6 7 0- 2 Precedence 3 Normal delay low delay Options & Padding (multiple of 32) 4 Normal throughput High throughput 5 Normal Reliability High reliability Data 6- 7 Reserved . •Option and Padding - additional info to control functions such as routing and •Identification, Flags, Fragmentation Offset- use to segmentation and security reassembly packet
Bit 0 = Reserved; must be 0 Bit 1 = DF ( 0 = May fragment; 1 = do not fragment ) Bit 2 = MF (0 = last fragment; 1 = more fragments )
3 Issue on header format vers hlen TOS total length identification flag frag offset TTL protocol header checksum source address destination address options and padding • Checksum in header format will calculate only the header checksum. Computation will be done if there are changes in header value. TTL value is decrement at every hop. Therefore, computation will be done at every router hop. • Options and Padding Field will be checked at every router hop and this use up router processing time which will degrade router performance.
4 Address space • IPv4 with only 32 bits gave approximately 4.3 x109 • More connected devices • More management costs • More demanding applications
- Communications appliances (e.g. phone, pager) - Information appliances(e.g. electronic books) - Entertainment appliances (e.g. set-top boxes)
LARGE ADDRESS SPACE NEEDED Facts : With current world populations 2 persons need to share an IP address 5 Limitation to IPv4 addressing
• Decision to stick with 32-bit address space meant that there were only 232 (4,294,967,296) IPv4 addresses available • Classful A, B, and C octet boundaries are easy to understand but inefficient to deploy in the real world. A /24 is too small for an average organization, while a /16 is too big!
IP 4
Internet gowth
6 Fragmentation flag vers hlen TOS total length identification flag frag offset TTL protocol header checksum source address destination address • Identification Number options and padding 16 bits integer value used to identify all fragments. This id is not a sequence number! • Flags - 3 bits control fragmentation
0=may fragment 1=don’t fragment
R DF MF 0=last fragment 1=more fragment reserved, must be 0
• Fragment offset - indicate the distance of fragment data from the start of the original datagram, measure in 8 octets unit
7 Problems in fragmentation
• The end node has no way to know how many fragments there be. • Every node will travel independently.If any fragment lost, all datagram must be discarded • If any fragment fails to arrive (timer) all datagram must be discarded • IP will make no attempt to recover these situations (connectionless). Only give ICMP error e.g “Packet too big” • Security problems!
8 Routing problems • Large Backbone Routing Table backbone routing table explosion ~ 90K routes . Problem with legacy IPv4 • Routing Performance At every hop router will need to check and verify header checksum.This will increase processing time and degrade routing performance. Fragmentation of packets are also done by router. Might need to be fragmented several times. This will also effect routing performance.
Hierarchical addressing scheme should be adopted and simplified header field can ease router burden.
9 IP layer security
• Security at Network Layer. • Confidentiality, Integrity, and Authentication are key services used to protect against these threats • If data is encrypted while in transit, it is impossible for a perpetrator to observe or modify. • Security in IPv4 is not mandated. We have to run IPSec on top of IP.
Strong Network-Layer authentication, identity spoofing and denial-of service can be prevented
10 Host auto-configuration
Stateful Server Mode
Via DHCP
DHCP request DHCP host Server DHCP respond
Stateless Server mode will be a better solution and can save cost
11 Quality of Service
• Quality of Service in IPv4 is using best effort delivery services, for data to arrive its destination as soon as possible. • No reservation for bandwidth. This is adequate for traditional applications such as Telnet and FTP. But nowadays, multimedia applications need real-time and sensitive data transfer to the network. Therefore, better QOS is needed.
An improved Quality of service need to be implemented.
12 What are IPv6 advantages?
• scalable IP address with streamlined IP header • optimized routing table size (<10K routes) • better real time support • self-configuration of workstations • security features
Note: IPv6 was designed to re-build and re-engineer IPv4; thus still inherit some IPv4’s characteristics but rejects its flaws
13 Header comparison
0 15 16 31 Removed (6) vers hlen TOS total length • ID, flags, frag offset
20 identification flags frag offset • TOS, hlen bytes TTL protocol header checksum • header checksum
source address destination address Changed (3) options and padding • total length=> payload IPv4 • protocol=>next header • TTL=>hop limit
vers traffic class flow label Added (2) payload length next header hop limit • traffic class 40 bytes source address • flow label
destination address Expanded • address 32 to 128 bits IPv6
14 Major improvement
1- No Options. Options field is replaced with extension header. The removal of the options results in a fixed length, 40 byte IP header.
2- No header checksum. Transport and data link layer have already performed checksumming.The removal of this feature leads to fast IP packet’s processing.
3- No segmentation procedure by routers. With path MTU discovery in IPv6, only source host performs fragmentation process. Removal of this procedure will speed up IP forwarding in routers.
4- Eliminated IPv4’s 40-octet limit on options in IPv6, limit is total packet size, or Path MTU in some cases.
15 Packet size issues
IPv6 requires that every link in the internet have an MTU of 1280 octets or greater.
On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.
Links that have a configurable MTU (for example, PPP links) must be configured to have an MTU of at least 1280 octets; it is recommended that they be configured with an MTU of 1500 octets or greater, to accommodate possible encapsulations (i.e., tunneling) without incurring IPv6-layer fragmentation.
From each link to which a node is directly attached, the node must be able to accept packets as large as that link's MTU.
16 Fragmentation
• IPv6 fragmentation & reassembly is an end-to-end function
• Routers do not fragment packets BUT only send the ICMP “message too big”(with the new MTU size) using the Path MTU Discovery feature
• Advantage: - better router performance; that is intermediate routers don’t have to check for the fragmentation fields (identification + flags + fragment offset fields) every time the packets pass through them
17 Path MTU discovery
ICMP “packet too big”
Destination Source Ethernet FDDI MTU=1500 FDDI FDDI MTU=4500 MTU=4500 MTU=4500 A B For packets bigger than 1280 bytes, path MTU discovery is expected:
• start by assuming MTU of the first-hop link • if a packet reaches a link which couldn’t fit, an ICMP “packet too big” is generated and sent back to the source • then the source will fragmentize the packet into smaller chunks (following this new MTU size) and start this process all over again
18 IPv6 packet structure
IPv6 Extension Higher-level protocol header Header Headers + application content
header payload
IPv6 packet
Definitions: IP header provides addressing and control IP payload carries information and error/control protocols
• Extension headers(optional): In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper- layer header in a packet. There are a small number of such extension headers, each identified by a distinct Next Header value (RFC 2460).
• Higher-level protocol header:
ICMPv6, UDP & TCP 19 Higher-level protocol header Extension Headers Extension headers IPv6 Header + application content
IPv6 packet
IPv6 header TCP header + data next header=TCP
IP header IP Payload
IPv6 header Routing header TCP header + data next header=routing next header=TCP
IP header Extension header IP Payload
IPv6 header Routing header Fragment header fragment of next header=routing next header=fragment next header=TCP TCP header + data
IP header Extension headers IP Payload Each extension header is an integer multiple of 8 octets long, in order to retain 8-octet alignment for subsequent headers.
A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop, Options Routing, Fragment Destination, Options, Authentication Encapsulating Security Payload 20 Extension headers
• Processed only by node identified in IPv6 Destination Address field => much lower overhead than IPv4 options exception: Hop-by-Hop Options header, which carries information that must be examined and processed by every node along a packet's delivery path, including the source and destination nodes (value zero in the Next Header field).
Currently defined Headers should appear in the following order: –IPv6 header –Hop-by-Hop Options header –Destination Options header (for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header) –Routing header –Fragment header –Authentication header –Encapsulating Security Payload header –Destination Options header (for options to be processed only by the final destination of the packet.) –upper-layer header 21 Hop-by-Hop Options Header The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path.
Next Header Hdr Ext Len
Options
Next Header: 8-bit selector. Identifies the type of header immediately following the Hop- by-Hop Options header. Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.].
Hdr Ext Len: 8-bit unsigned integer. Length of the Hop-by- Hop Options header in 8- octet units, not including the first 8 octets.
Options: variable-length field, of length such that the complete Hop-by-Hop Options header is an integer multiple of 8 octets long. Contains one or more TLV-encoded options. 22 Options the Hop-by-Hop Options header and the Destination Options header -- carry a variable number of type-length-value (TLV) encoded "options", of the following format:
Option Type Opt Data Len Option Data
Option Type: 8-bit identifier of the type of option.
Opt Data Len: 8-bit unsigned integer. Length of the Option Data field of this option, in octets.
Option Data: Variable-length field. Option-Type-specific data.
23 Options The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: - 00 - skip over this option and continue processing the header. - 01 - discard the packet. - 10 - discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. - 11 - discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type.
The third-highest-order bit of the Option Type specifies whether or not the Option Data of that option can change en-route to the packet's final destination. 0 - Option Data does not change en-route
1 - Option Data may change en-route 24 Options The 8-bit Option Type field contains the value 194 to indicate the Jumbo Payload option.
A “jumbogram” is an IPv6 packet containing a payload larger than 65,535 octets. The regular IPv6 header has a 16-bit Payload Length field and, therefore, supports payloads up to 65,535 octets long. However, the Jumbo Payload option uses an IPv6 hop-by-hop option, which carries a 32-bit length field, in order to allow transmission of IPv6 packets with payloads between 65,536 and 4,294,967,295 octets (232-1) in length.
In order for a network to support jumbograms, all the nodes in the network should implement Jumbo Payload option. Furthermore, the UDP and TCP protocols in those nodes also have to be enhanced.
The payload length field of the IPv6 header must be set to 0 in every packet that carries the Jumbo Payload Option. The Jumbo Payload Option is not consistent with the Fragment header, therefore they cannot be present in the same IPv6 packet. 25 Routing Header The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. The Routing header is identified by a Next Header value of 43 in the immediately preceding header. Next Header Hdr Ext Len Routing Type Segments Left
Type-specific data
Next Header: 8-bit selector. Identifies the type of header immediately following the Routing header. Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.].
Hdr Ext Len: 8-bit unsigned integer. Length of the Routing header in 8-octet units, not including the first 8 octets.
Routing Type: 8-bit identifier of a particular Routing header variant.
Segments Left: 8-bit unsigned integer. Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination.
Type-specific: data Variable-length field, of format determined by the Routing Type, and of length such that the complete Routing header is an integer multiple of 8 octets long.26 Fragment Header The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. The Fragment header is identified by a Next Header value of 44 in the immediately preceding header, and has the following format:
Next Header Reserved Fragment Offset Res M
Identification
Next Header 8-bit selector. Identifies the initial header type of the Fragmentable Part of the original packet. Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.].
Reserved: 8-bit reserved field. Initialized to zero for transmission; ignored on reception.
Fragment Offset: 13-bit unsigned integer. The offset, in 8-octet units, of the data following this header, relative to the start of the Fragmentable Part of the original packet.
Res: 2-bit reserved field. Initialized to zero for transmission; ignored on reception.
M flag 1 = more fragments; 0 = last fragment.
Identification 32 bits. Identification of fragmented original packet, which must be different than that of any other fragmented packet sent recently. 27 Fragmentation rivisited The initial, large, unfragmented packet is referred to as the "original packet", and it is considered to consist of two parts, as illustrated:
Unfragmentable Part Fragmentable Part
The Unfragmentable Part consists of the IPv6 header plus any extension headers that must be processed by nodes en-route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers.
The Fragmentable Part consists of the rest of the packet, that is, any extension headers that need be processed only by the final destination node(s), plus the upper-layer header and data.
28 Fragmentation rivisited The Fragmentable Part of the original packet is divided into fragments, each, except possibly the last ("rightmost") one, being an integer multiple of 8 octets long. The fragments are transmitted in separate "fragment packets" as illustrated:
First Last Unfragmentable Part … fragment fragment
Unfragmentable Part Fragment First
Header fragment
…
Unfragmentable Part Fragment Last Header fragment
The last header of the Unfragmentable Part changed to 44.
29 Destination Options Header The Destination Options header is used to carry optional information that need be examined only by a packet's destination node(s). The Destination Options header is identified by a Next Header value of 60 in the immediately preceding header, and has the following format:
Next Header Hdr Ext Len
Options
Next Header: 8-bit selector. Identifies the type of header immediately following the Destination Options header. Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.].
Hdr Ext Len: 8-bit unsigned integer. Length of the Destination Options header in 8-octet units, not including the first 8 octets.
Options: Variable-length field, of length such that the complete Destination Options header is an integer multiple of 8 octets long. Contains one or more TLV-encoded options. 30 Security Issues
Use of AH and ESP headers
Two operative modes can be selected:
Transport mode In transport mode, only the payload of the IP packet is usually encrypted and/or authenticated. The routing is intact, since the IP header is neither modified nor encrypted; however, when the authentication header is used, the IP addresses cannot be translated, as this will invalidate the hash value. The transport and application layers are always secured by hash, so they cannot be modified in any way (for example by translating the port numbers). Transport mode is used for host-to-host communications.
Tunnel mode In tunnel mode, the entire IP packet is encrypted and/or authenticated. It is then encapsulated into a new IP packet with a new IP header. Tunnel mode is used to create virtual private networks for network-to-network communications (e.g. between routers to link sites), host-to-network communications (e.g. remote user access), and host-to-host communications (e.g. private chat).
31 Authentication Header
Next Header (8 bits) : it indicates the protected upper-layer protocol. The value is taken from the list of IP protocol numbers. Hdr Ext Len (8 bits): length of the Authentication Header in 4-octet units, minus 2 (a value of 0 means 8 octets, 1 means 12 octets, etcetera). The header length must be a multiple of 8 octets if carried in an IPv6 packet. This restriction does not apply to an Authentication Header carried in an IPv4 packet. Reserved (16 bits): reserved for future use (all zeroes if not used). Security Parameters Index (32 bits): Arbitrary value which is used (together with the source IP address) to identify the security association of the sending party. Sequence Number (32 bits): A monotonic strictly increasing sequence number (incremented by 1 for every packet sent), used also to prevent replay attacks. Integrity Check Value (multiple of 32 bits): variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.
32 AH Modes
Transport Mode
Tunnel Mode
33 Encapsulating Security Payload (ESP)
Security Parameters Index (32 bits) : arbitrary value which is used (together with the source IP address) to identify the security association of the sending party.
Sequence Number (32 bits) : a monotonically increasing sequence number (incremented by 1 for every packet sent) used also to protect against replay attacks.
Payload data (variable): the protected contents of the original IP packet, including any data used to protect the contents (e.g. an Initialization Vector for the cryptographic algorithm). The type of content that was protected is indicated by the Next Header field.
34 Encapsulating Security Payload (ESP)
Padding (0-255 octets): padding for encryption, to extend the payload data to a size that fits the encryption's cypher block size, and to align the next field.
Pad Length (8 bits): size of the padding in octets.
Next Header (8 bits): type of the next header. The value is taken from the list of IP protocol numbers.
Authentication Data (multiple of 32 bits): variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.
35 Encryption and Authentication Algorithms • Encryption: – Three-key triple DES – RC5 – IDEA – Three-key triple IDEA – CAST – Blowfish • Authentication: – HMAC-MD5-96 – HMAC-SHA-1-96
36 ESP Modes
Transport Mode
Tunnel Mode
37 Combinations of Security Associations
38 IPsec modes and combinations
Transport Mode Tunnel Mode
AH Authenticates IP payload and Authenticates entire inner IP selected portions of IP datagram (header and header payload) and selected portions of the outer IP header
ESP Encrypts IP payload Encrypts inner IP datagram
ESP with Encrypts IP payload and Encrypts and authenticates authenticates IP payload but inner IP datagram Authentication not IP header
39 Summary of Extension Headers
If the upper-layer header is another IPv6 header (in the case of IPv6 being tunneled over or encapsulated in IPv6), it may be followed by its own extension headers, which are separately subject to the same ordering recommendations.
40 No Next Header
The value 59 in the Next Header field of an IPv6 header or any extension header indicates that there is nothing following that header. i.e. the payload should be empty.
If the Payload Length field of the IPv6 header indicates the presence of octets past the end of a header whose Next Header field contains 59, those octets must be ignored, and passed on unchanged if the packet is forwarded (RFC 2460)
41 Flow label
The 20-bit Flow Label field in the IPv6 header may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service.
This aspect of IPv6 is subject to change as the requirements for flow support in the Internet is modified. Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet.
42 Traffic Class
The 8-bit Traffic Class field in the IPv6 header is available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets.
There are a number of proposals in the use of the IPv4 Type of Service and/or Precedence bits to provide various forms of "differentiated service" for IP packets, other than through the use of explicit flow set-up. The Traffic Class field in the IPv6 header is intended to allow similar functionality to be supported in IPv6.
-The service interface to the IPv6 service within a node must provide a means for an upper-layer protocol to supply the value of the Traffic Class bits in packets originated by that upper- layer protocol. The default value must be zero for all 8 bits.
- Nodes that support a specific (experimental or eventual standard) use of some or all of the Traffic Class bits are permitted to change the value of those bits in packets that they originate, forward, or receive, as required for that specific use. Nodes should ignore and leave unchanged any bits of the Traffic Class field for which they do not support a specific use.
- An upper-layer protocol must not assume that the value of the Traffic Class bits in a received packet are the same as the value sent by the packet's source. 43 Upper-Layer Protocol Issues
Any transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation must be modified for use over IPv6, to include the 128-bit IPv6 addresses instead of 32-bit IPv4 addresses.
The Next Header value in the pseudo-header identifies the upper-layer protocol (e.g., 6 for TCP, or 17 for UDP). It will differ from the Next Header value in the IPv6 header if there are extension headers between the IPv6 header and the upper- layer header.
Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, it must be changed to hex FFFF for placement in the UDP header. IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error.
When computing the maximum payload size available for upper-layer data, an upper- layer protocol must take into account the larger size of the IPv6 header relative to the IPv4 header.
44 How Was IPv6 Address Size Chosen?
• Some wanted fixed-length, 64-bit addresses – Easily good for 1012 sites, 1015 nodes, at .0001 allocation efficiency (3 orders of magnitude more than IPv6 requirement) – Minimizes growth of per-packet header overhead – Efficient for software processing • Some wanted variable-length, up to 160 bits – Compatible with OSI NSAP addressing plans – Big enough for auto-configuration using IEEE 802 addresses – Could start with addresses shorter than 64 bits & grow later • Settled on fixed-length, 128-bit addresses
45 Address space IPv4 Address space IPv6 Address Space 192.228.134.34 3FFE:90:AD:23:112:9:56:210
32-bit 128-bit • 128-bit or 16 bytes
• 2^128=340,282,366,920,938,463,463,374,607,431,768,211,456
• 4.2 x 10^9 versus 3.4 x 10^38 addresses
IPv4 IPv6
Note: IPv4 allows 1 IP for every 2 persons, but IPv6 offers ~5.6 x 10^28 per person(out of 6 billions population -- 6 x 10^9)
46 Address syntax: preferred
• Hexadecimal values of the eight 16-bit pieces, separated by colon X:X:X:X:X:X:X:X
X = 16-bit numbers e.g. A3BF or FFFE
• Example: FE78:3450:BED8:9542:FEDC:BA09:1236:763C 3FFE:0:0:0:13:45D:432:1A
47 Address syntax: compressed
• Compressed form=> “::” indicates multiple groups of 16- bits of zeros, but only once in an address
4A80:0:0:0:5:800:50CA:290D => 4A80::5:800:50CA:290D FE80:0:0:0:0:0:0:349 => FE80::349 4D0A:0:0:89:0:0:236:8009 => 4D0A::89:0:0:23:8009 or 4D0A:0:0:89::23:8009 0:0:0:0:0:0:0:1 => ::1
48 Address type • There are 3 types of addresses:
Unicast : defines a single recipient A packet sent to a unicast address is delivered to the interface identified by that address
Anycast : defines a number of recipients A packet sent to an anycast address is delivered to one of the interfaces (the working nearest interface)
Multicast : defines a number of recipients A packet sent to a muticast address is delivered to all of the interfaces identified by that address
A single interface may be assigned multiple IPv6 addresses of any type (unicast, anycast, multicast) 49 Address allocation
Prefix is used to identify type of IPv6 address; normally the first 16 bits (or first 2 bytes) Address Type Binary prefix IPv6 notation
Unspecified 00…0 (128 bits) ::/128 Loopback 00...1 (128 bits) ::1/128 Multicast 11111111 FF00::/8 Link-Local unicast 1111111010 FE80::/10 Global Unicast (everything else)
Anycast addresses are taken from the unicast address spaces and are not syntactically distinguishable from unicast addresses.
50 Global Unicast Addresses (RFC 3587)
128 bit
n bits m bits 128-n-m bits
global routing prefix Subnet-ID Interface-ID
The global routing prefix is a (typically hierarchically- structured) value assigned to a site (a cluster of subnets/links), the subnet ID is an identifier of a link within the site, and the interface ID is configurable in different ways
All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64). Global Unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field. They are special addresses shown in what follows.
51 Allocation Binary Prefix Example IPv4-compatible IPv4-compatible 00..(96 bits of zero) 0:0:0:0:0:0:n.n.n.n
& IPv4-mapped IPv4-mapped 00..ffff(80 bits of zero) 0:0:0:0:0:ffff:n.n.n.n • These addresses have a mixed environment of IPv4 and IPv6 addresses: 1) IPv4-compatible IPv6 address technique for hosts and routers to dynamically tunnel IPv6 packets over IPv4 routing infrastructure – dual stack 0:0:0:0:0:0:192.226.124.45 => ::192.226.124.45
2) IPv4-mapped IPv6 address Never src/dest of IPv6 packets.
0:0:0:0:0:FFFF:192.226.124.45 => ::FFFF:192.226.124.45
52 IPv4-mapped addresses
IPv6-only applications
TCP / UDP / others (SCTP, DCCP, etc.)
IPv4-mapped IPv6 addresses IPv6 addresses IPv4 IPv6
IPv4 packets IPv6 packets
53 Link Local Addresses
128 bit
10 bits 54 bits 64 bits
1111 1110 10 0 Interface-ID
Link-Local addresses are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present.
Routers must not forward any packets with Link-Local source or destination addresses to other links.
54 Site Local Addresses
128 bit
10 bits 54 bits 64 bits
1111 1110 11 subnet ID Interface-ID
Site-Local addresses were originally designed to be used for addressing inside of a site without the need for a global prefix. Site-local addresses are now deprecated.
The special behavior of this prefix defined in [RFC3513] must no longer be supported in new implementations (i.e., new implementations must treat this prefix as Global Unicast).
Existing implementations and deployments may continue to use this prefix. 55 Unique Local IPv6 Unicast Addresses (RFC 4193) IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. 128 bit
7 bits 1 40bits 16 bits 64 bits
Prefix L Global ID Subnet ID Interface-ID
Prefix: FC00::/7 prefix to identify Local IPv6 unicast addresses.
L Set to 1 if the prefix is locally assigned. Set to 0 may be defined in the future.
Global ID 40-bit global identifier used to create a globally unique prefix.
Subnet ID 16-bit Subnet ID is an identifier of a subnet within the site.
Interface ID 64-bit Interface ID.
56 Unique Local IPv6 Unicast Addresses
128 bit
7 bits 1 40bits 16 bits 64 bits
Prefix L Global ID Subnet ID Interface-ID
The allocation of Global IDs is pseudo-random . They MUST NOT be assigned sequentially or with well-known numbers. This is to ensure that there is not any relationship between allocations and to help clarify that these prefixes are not intended to be routed globally.
The use of a pseudo-random algorithm to generate Global IDs in the locally assigned prefix gives an assurance that any network numbered using such a prefix is highly unlikely to have that address space clash with any other network that has another locally assigned prefix allocated to it. This is a particularly useful property when considering a number of scenarios including networks that merge, overlapping VPN address space, or hosts mobile between such networks. 57 Anycast Addresses
An IPv6 anycast address is an address that is assigned to more than one interface (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance.
Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats. Thus, anycast addresses are syntactically indistinguishable from unicast addresses. When a unicast address is assigned to more than one interface, thus turning it into an anycast address, the nodes to which the address is assigned must be explicitly configured to know that it is an anycast address.
58 Required Anycast Address
128 bit
n bits 121-n bits 7 bits
Subnet prefix 111…..1111 anycast ID
The Subnet-Router anycast address is predefined. The "subnet prefix" in an anycast address is the prefix that identifies a specific link. Within each subnet, the highest 27=128 interface identifier values are reserved for assignment as subnet anycast addresses.
Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets to which they have interfaces. The Subnet-Router anycast address is intended to be used for applications where a node needs to communicate with any one of the set of routers. 59 Multicast Addresses (RFC 4291)
128 bit
8 4 4 112
11111111 flags scope Group-ID
Defines address scope 0 Reserved 1 Node-local scope 3 Link-local scope 4 Admin Local Scope 5 Site-local scope 8 Organization local scope E Global scope F Reserved
First 3 bits set to 0 Last bit defines address type (T flag): 0 = Permanent (or well-known) 1 = Locally assigned (or transient)
60 Multicast Addresses Interface-Local scope spans only a single interface on a node and is useful only for loopback transmission of multicast.
Link-Local multicast scope spans the same topological region as the corresponding unicast scope.
Admin-Local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration.
Site-Local scope is intended to span a single site.
Organization-Local scope is intended to span multiple sites belonging to a single organization.
Scopes unassigned are available for administrators to define additional multicast regions.
61 Multicast Addresses
Reserved Multicast Addresses:
FF00:0:0:0:0:0:0:0 FF01:0:0:0:0:0:0:0 FF02:0:0:0:0:0:0:0 FF03:0:0:0:0:0:0:0 FF04:0:0:0:0:0:0:0 FF05:0:0:0:0:0:0:0 FF06:0:0:0:0:0:0:0 FF07:0:0:0:0:0:0:0 FF08:0:0:0:0:0:0:0 FF09:0:0:0:0:0:0:0 FF0A:0:0:0:0:0:0:0 FF0B:0:0:0:0:0:0:0 FF0C:0:0:0:0:0:0:0 FF0D:0:0:0:0:0:0:0 FF0E:0:0:0:0:0:0:0 FF0F:0:0:0:0:0:0:0
The above multicast addresses are reserved and shall never be assigned to any multicast group.
62 Multicast Addresses
Some well-known multicast addresses are pre-defined. The group IDs shown are defined for explicit scope values. Use of these group IDs for any other scope values, with the T flag equal to 0, is not allowed. All Nodes Addresses: multicast addresses that identify the group of all FF01:0:0:0:0:0:0:1 IPv6 nodes, within scope 1 (interface-local) or 2 FF02:0:0:0:0:0:0:1 (link-local).
All Routers Addresses: FF01:0:0:0:0:0:0:2 multicast addresses that identify the group of all FF02:0:0:0:0:0:0:2 IPv6 routers, within scope 1 (interface-local), 2 FF05:0:0:0:0:0:0:2 (link-local), or 5 (site-local).
Solicited-Node Address: Solicited-Node multicast address are computed FF02:0:0:0:0:1:FF as a function of a node's unicast and anycast XX:XXXX addresses. A Solicited-Node multicast address is formed by taking the low-order 24 bits of an ARP-like address (unicast or anycast) and appending those bits to the prefix FF02:0:0:0:0:1:FF00::/104
resulting in a multicast address in the range 63 Interface Identifiers
• A host is required to recognize the following addresses as identifying itself: – Its Link-Local Address for each interface – Assigned Unicast Addresses – Loopback Address – All-Nodes Multicast Addresses – Solicited-Node Multicast Address for each of its assigned unicast and anycast addresses – Multicast Addresses of all other groups to which the host belongs.
64 Interface Identifiers
• Routers are required to recognize: – The Subnet-Router anycast addresses for the interfaces it is configured to act as a router on. – All other Anycast addresses with which the router has been configured. – All-Routers Multicast Addresses – All valid host addresses – Multicast Addresses of all other groups to which the router belongs.
65 Hierarchical Addressing & Aggregation
Only Customer announces no 1 the /32 ISP prefix 2001:0410:0001:/48 2001:0410::/32
Customer IPv6 Internet no 2 2001::/16 2001:0410:0002:/48
–Larger address space enables: •Aggregation of prefixes announced in the global routing table. •Efficient and scalable routing. –But current Multi-Homing schemes break the model
(note: no masks in IPv6!) 66 Address Allocation Policy IANA allocates addresses to Regional Internet Registry, or RIR. Currently, there are four RIR: APNIC (Asia Pacific Network Information Centre), ARIN for North America, RIPE NCC (Reseaux IP Europeans Network Coordination Centre) mainly for Europe, and LACNIC (Latin American and Caribbean Internet Addresses Registry) for South America and Caribbean regions.
RIR (or National IR - NIR) allocates address to organizations called LIR (Local Internet Registry). An LIR is an organization which is delegated by RIR or NIR to allocate address to users. LIR usually is a service provider. An LIR allocates acquired address to end user
organizations, or other ISP. 67 Address Allocation Policy
Ex: 2001::/16 0010 0000 0000 0001 Global Unicast Assignments [RFC3513]
Each registry gets a /23 prefix from IANA, within the 2001::/16 space Registry allocates an initial /32 prefix to a new IPv6 ISP ISP allocates a /48 prefix (out of the /32) to each customer
68 Interface IDs
Lowest-order 64-bit field of unicast address may be assigned in several different ways: – auto-configured from a 64-bit EUI-64, or expanded from a 48-bit MAC address (e.g., Ethernet address) – auto-generated pseudo-random number (to address privacy concerns) – assigned via DHCP – manually configured
69 MAC-to-EUI-64 conversion example
MAC Address: 0000:0B0A:2D51 • In binary: 00000000 00000000 00001011 00001010 00101101 01010001
U/L Bit
Company-ID Individual Node-ID Insert FFFE between Company-ID and Node-ID 00000000 00000000 00001011 11111111 11111110 00001010 00101101 01010001 Set U/L bit to 1 = FFFE 00000010 00000000 00001011 11111111 11111110 00001010 00101101 01010001 U/L Bit Resulting EUI-64 Address: 0200:0BFF:FE0A:2D51
70 Types of Transition to IPv6 Mechanisms
• Dual Stacks – IPv4/IPv6 coexistence on one device • Tunnels – For tunneling IPv6 across IPv4 clouds – Later, for tunneling IPv4 across IPv6 clouds • Translators – IPv6 <-> IPv4
71 Dual Stacks
Network, Transport, and Application layers do not necessarily interact without further modification or translation
IPv6 IPv4 Applications Applications
TCP/UDPv6 TCP/UDPv4 IPv6 IPv4 0x86dd 0x0800
Physical/Data Link
72 Tunnel Applications
IPv4 IPv6 IPv6 IPv6
Router to Router
IPv4 IPv6
Host to Host
IPv4 IPv6 IPv6
Host to Router / Router to Host
73 Tunnels to Get Through IPv6-Ignorant Routers
• encapsulate IPv6 packets inside IPv4 packets (or MPLS frames) • can view this as: – IPv6 using IPv4 as a virtual link-layer, or – an IPv6 VPN (virtual public network), over the IPv4 Internet
74 Tunnel Types
• Configured or automated tunneling – Ex: Router to router: raw encapsulation of IPv6 packets using IPv4 protocol number 41 is recommended for configured tunneling (aka 6in4 tunneling). – The tunnel endpoints are explicitly configured, either by an administrator manually or the operating system's configuration mechanisms, or by a tunnel broker service. – It is recommended for large, well-administered networks.
• Automatic tunneling, the routing infrastructure automatically determines the tunnel endpoints. – 6to4 (RFC 3056), widely deployed protocol 41 encapsulation. – ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) • Host to router, router to host • Maybe host to host – 6over4 (RFC 2529) • Host to router, router to host – Teredo • For tunneling through IPv4 NAT – IPv64 • For mixed IPv4/IPv6 environments
75 Configured tunneling
IPv6 host IPv4 network IPv6 host 2001::A:A:B 2001::B:B:C
• Encapsulate IPv6 …… R1 IPv4 IPv6 IPv4 IPv6 R2 packet in Ipv4
• IPv6 only 2001::B:B:C 2001::B:B:C address 4 hl TOS len ident frag off 6 traffic flow label TTL 41 checksum 6 traffic flow label src = R1 payload len next hops payload len next hops src = 2001::A:A:B dst = R2 dst = 2001::B:B:C (IPv6 adr) 6 traffic flow label (IPv6 adr) dst = 2001::B:B:C src = 2001::A:A:B payload len next hops (IPv6 adr) (IPv6 adr) src = 2001::A:A:B payload (IPv6 adr) payload
dst = 2001::B:B:C (IPv6 adr) payload
76 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) (RFC 5572)
A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6, or UDP over IPv4 for IPv4 NAT traversal.
The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker.
A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only.
A tunnel broker may terminate the tunnels on remote tunnel servers or on itself.
77 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) (RFC 5572)
TSP is a signaling protocol to set up tunnel parameters between two tunnel endpoints. TSP is implemented as a tiny client code in the requesting tunnel endpoint. The other endpoint is the server that will set up the tunnel service. TSP uses XML basic messaging over TCP or UDP.
TSP negotiates tunnel parameters between the two tunnel endpoints. Parameters that are always negotiated are:
- Authentication of the users, - Tunnel encapsulation: IPv6 over IPv4 tunnels [RFC4213] IPv4 over IPv6 tunnels [RFC2473] IPv6 over UDP-IPv4 tunnels for NAT traversal - IP address assignment for the tunnel endpoints - DNS registration of the IP endpoint address (AAAA)
78
IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) (RFC 5572) • Three basic components: 1. TSP Client: Dual-stacked host or router 2. Client Tunnel Endpoint 3. TSP Server (Tunnel Broker) 4. Server Tunnel Endpoint
• A few tunnel brokers: – Freenet6 [Canada] (www.freenet6.net) – CERNET/Nokia [China] (www.tb.6test.edu.cn) – Internet Initiative Japan (www.iij.ad.jp) – Hurricane Electric [USA] (www.tunnelbroker.com) – BTexacT [UK] (www.tb.ipv6.btexact.com) – Many others…
• 1,3, and 4 form the tunnel broker model (RFC 3053), where 3 is the tunnel broker and 4 is the tunnel server. The tunnel broker may control one or many tunnel servers. 79
TSP Used on Tunnel Broker Model
1. AAA Authorization 2. Configuration request 3. TB chooses: • TS • IPv6 addresses • Tunnel lifetime TSP 4. TB registers tunnel IPv6 addresses Server 3 5. Config info sent to TS 6. Config info sent to client: 4 Tunnel DNS • Tunnel parameters Broker • DNS name 1 7. Tunnel enabled 2 6 5 TSP IPv4 Tunnel Client Network Server IPv6 7 Network IPv6 Tunnel
80 Automatic tunneling IPv6 host IPv4 network IPv4/6 host ::1.2.3.4 2.3.4.5 • Encapsulate IPv6 ……IPv4 IPv6 IPv4IPv6 packet in Ipv4
• rely on IPv4- 2.3.4.5 2.3.4.5 2.3.4.5 compatible IPv6 4 hl TOS len 4 hl TOS len address ident frag off ident frag off 6 traffic flow label TTL prot checksum TTL prot checksum src = 1.2.3.4 src = 1.2.3.4 payload len next hops src = ::1.2.3.4 dst = 2.3.4.5 dst = 2.3.4.5 (IPv4-compatible IPv6 adr) 6 traffic flow label 6 traffic flow label dst = ::2.3.4.5 payload len next hops payload len next hops (IPv4-compatible IPv6 adr) src = ::1.2.3.4 src = ::1.2.3.4 payload (IPv4-compatible IPv6 adr) (IPv4-compatible IPv6 adr)
dst = ::2.3.4.5 dst = ::2.3.4.5 (IPv4-compatible IPv6 adr) (IPv4-compatible IPv6 adr) payload payload
81 6to4 (RFC 3056) – WAN tunneling • Designed for site-to-site and site to existing IPv6 network connectivity • Site border router must have at least one globally-unique IPv4 address • Uses IPv4 embedded address /16 /48 /64 Public IPv4 Subnet- 2002 address ID Interface ID Example:
Reserved 6to4 prefix: 2002::/16
IPv4 address: 138.14.85.210 = 8a0e:55d2 Resulting 6to4 prefix: 2002:8a0e:55d2::/48
• Router advertises 6to4 prefix to hosts via RAs • Embedded IPv4 address allows discovery of tunnel endpoints
82 6to4
IPv6 Public Internet IPv4 address: 138.14.85.210 IPv4 address: 65.114.168.91 6to4 prefix: 2002:8a0e:55d2::/48 6to4 prefix: 2002:4172:a85b::/48
6to4 Relay Router
IPv4 Network IPv6 IPv6 Site IPv6 Site
6to4 Router 6to4 Router
6to4 address: 6to4 address: 2002:8a0e:55d2::8a0e:55d2 2002:4172:a85b::4172:a85b
83 6over4 • aka “Virtual Ethernet”: transmit IPv6 packets between dual-stack nodes on top of a multicast-enabled IPv4 network. IPv4 is used as a virtual data link layer (virtual Ethernet) on which IPv6 can be run. • Early proposed tunnel solution: 6over4 defines a trivial method for generating a link-local IPv6 address from an IPv4 address, and a mechanism to perform Neighbor Discovery on top of IPv4.
84 6over4 • Encapsulates IPv6 packets in IPv4 (protocol type 41)
Starting from fe80:: 192.0.2.142, C000028e in hexadecimal notation link-local IPv6 address: fe80::C000:28e
To facilitate IPv6 multicast communications over an IPv4 multicast- enabled infrastructure, RFC 2529 defines the following mapping to translate an IPv6 multicast address to an IPv4 multicast address: 239.192.[ second to last byte of IPv6 address ].[ last byte of IPv6 address ]
Example: To perform ICMPv6 Neighbor Discovery, multicast must be used. Any IPv6 multicast packet gets encapsulated in an IPv4 multicast packet with destination 239.192.x.y, where x and y are the penultimate and last bytes of the IPv6 multicast address respectively.
85 ISATAP Addresses (RFC 5214)
• ISATAP (Intra-Site Automatic Tunnel Access Protocol) – Campus tunneling – It is a transition mechanism which can be used within a site to connect isolated IPv6/IPv4-dualstack hosts to the IPv6 internet. – Within a site usually only one ISATAP router is needed. The host/router functioning as an ISATAP server should be dualstack and have a connection to the IPv6 internet in order for it to become a gateway for all clients in the ISATAP subnet it serves. An ISATAP client using a certain server as gateway also needs a valid global- scope IPv6 prefix to build its address with. This prefix should therefore be advertised by the router which also needs to have this prefix routed to it from the outside.
86 ISATAP
IPv4/IPv6 Router IPv6 IPv4
IPv6 6to4 IPv4 Router
ISATAP hosts must be configured with a potential routers list (PRL). Each of these routers is infrequently probed by an ICMPv6 Router Discovery message, to determine which of them are functioning. 87 ISATAP
Example 1 : Global IPv4 address: 65.114.168.91 Global IPv6 prefix: 2001:468:1100:1::/64
Link-local address: fe80::0200:5efe:65.114.168.91 Global IPv6 address: 2001:468:1100:1::0200:5efe:65.114….. Example 2: Private IPv4 address: 172.18.133.14 Global IPv6 prefix: 2001:468:1100:1::/64
Link-local address: fe80::5efe: 172.18.133.14 Global IPv6 address: 2001:468:1100:1::5efe:172.18.133.14 88 Teredo (RFC4380)
• aka “Shipworm” • 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 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 creating mapping in NAT – Teredo Service Prefix: Prefix originated by TS for creating client IPv6 address
Teredo navalis
89 1. RS to server Teredo 2. NAT maps inside address/port to outside address/port 3. TS notes: • source address/port TSP can be used in place of RS/RA for: • NAT type Stateful tunnel 4. RA to client containing: Authentication • Service prefix • origin indication 5. Client creates IPv6 address from: • Server prefix • “Obfusticated” origin IPv4 IPv4 =1.2.3.4 IPv6 prefix = 3ffe:831f::/32 indication"mapped IPv4 address" Network Teredo 6. IPv6 packets Server tunneled to relay 2 3 Source: 9.0.0.1:4096 Destination: 1.2.3.4:3544 4 Source: 1.2.3.4 1 Destination: 9.0.0.1:4096 Source: 10.0.0.1:2716 Prefix:3ffe:831f:0102:0304::/64 Destination: 1.2.3.4:3544 Origin Indication: 9.0.0.1:4096 IPv6 Network Client NAT 10.0.0.2 IPv6 over UDP tunnel 5 6 Teredo 3ffe:831f:102:304::efff:f6ff:fffe Inside Address: 10.0.0.1 Relay Outside Address: 9.0.0.1
4096:9.0.0.1=00010000000000000:00001001.00000000.00000000.00000001 111011111111111111110110.11111111.11111111.11111110 efff:f6ff:fffe 90 IPv64
• Proposed for highly interconnected IPv4 and IPv6 networks (mid-
Ver. transition) HL TOS Datagram Length 4 • IPv64 packets: IPv6 encapsulated in IPv4 Datagram-ID Flag Frag Offset – bit 48 (numbering from 0) TTL Protocol Header Checksum Source IPv4 Address
of IPv4 header indicates IPv64 packet Destination IPv4 Address
• IPv64 routers: IP Options
Ver. Traffic – Process IPv64 packets as IPv6 Flow label 6 class IPv64 bit Next Hop – Process IPv4 packets as IPv4 Payload Length 1 = IPv64 Hdr. Limit – Process IPv6 packets as IPv6 0 = IPv4 Source IPv6 Address • IPv4 routers: – Process IPv64 packets as IPv4 • IPv6 routers: Destination IPv6 Address – Cannot process IPv64 packets – IPv64-to-IPv4 translation required at IPv64 routers – Proposed IPv6 Extension Header carries necessary IPv4 information for re-translating back to IPv64, if necessary
91 Dual-Stack Transition Mechanism (DSTM)
• aka 4over6 – Tunnels IPv4 over IPv6 networks – Next-Header Number for IPv4 = 4 • Three basic components: – Tunnel End Point: Border router between IPv6-only network and IPv4 Internet or intranet – DSTM Clients: Dual-stacked nodes, create tunnels to Tunnel End Pont (TEP) – DSTM Address Server: Allocates IPv4 addresses to clients • Uses existing protocols – DSTM Server can communicate with Client or TEP via DHCPv6 or TSP • Server can optionally assign port range for IPv4 address conservation – Multiple clients have same IPv4 address, different port ranges
92 DSTM
1. Client needs IPv4 connectivity 2. Client requests tunnel info 3. Server sends IPv4 tunnel endpoint addresses 1 4. Tunnel set up
jeff.juniper.net = 192.168.1.2
DSTM Server 2 IPv6 3 3 Network IPv4 4 Network IPv4 in IPv6 Tunnel
Client Tunnel End-Point
93 Translators
• Network level translators – Stateless IP/ICMP Translation Algorithm (SIIT)(RFC 6145) – NAT-PT (RFC 2766) - deprecated – 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) – Application Level Gateways (ALG)
94 Stateless IP/ICMP Translation (SIIT)
• Translator replaces 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 – ::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
95 Stateless IP/ICMP Translation (SIIT) 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: 3ffe:3700:1100:1:210:a4ff:fea0:bc97 •Traffic Class TOS 216.148.227.68 •Payload length •Protocol Number NH Number •TTL Hop Limit
96 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 • Two variations: – Basic NAT-PT provides translation of IPv6 addresses to a pool of IPv4 addresses – NAT-PT manipulates IPv6 port numbers so that multiple IPv6 sources can share a single IPv4 address • DNS Application Level Gateway (DNS-ALG) is also specified, but has some problems – Internal A queries might return AAAA record – Possible problems for internal zone transfers, mixed v4/v6 networks, etc. – Possible problems resolving to external dual-stacked hosts – Assumes DNS traffic traverses NAT-PT box (topology limitation) – No DNS-sec – Vulnerable to DoS attacks by depletion of address pools
97 Network Address Translation - Protocol Translation (NAT-PT) 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
98 Network Address Translation - Protocol Translation (NAT-PT) 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
99 Transport Relay Translator (TRT)
• aka TCP/UDP Relay. It enables IPv6-only hosts to exchange {TCP,UDP} traffic with IPv4-only hosts. • Based on proxy firewall concept • No IP packets transit the TRT • Two connections established: – Initiator to TRT – TRT to target node • Requires “special” DNS to translate IPv4 addresses into IPv6 and vice versa – TRT does not translate DNS queries/records • Only works with TCP and UDP
100 Transport Relay Translator (TRT) IPv4 Query to “special” DNS from v6host Network v4host.4net.org for v4host.4net.org returns: 204.127.202.4 AAAA fec0:0:0:1::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
101 Application Layer Gateways
• Application-specific translator • Needed when application layer contains IP address • Similar to ALGs used in firewalls, some NATs
102 ICMPv6
Some important ICMPv6 message types:
1 Destination unreachable 2 Packet too big 3 Time exceeded 4 Parameter problem 128 Echo request 129 Echo reply
103 ICMPv6: Destination Unreachable 32 bits
Type=1 Code Checksum IPv6 Header Destination Address: Unused Copied from the Source Address field of the invoking As much of invoking packet packet. as will fit without the ICMPv6 packet exceeding the minimum IPv6 MTU
Unused This field is unused for all code Code 0 - no route to destination values. It must be initialized to zero 1 - communication with destination by the sender and ignored by the administratively prohibited receiver. 2 - (not assigned) 3 - address unreachable 4 - port unreachable
104 ICMPv6: Packet too big 32 bits
Type=2 Code Checksum IPv6 Header Destination Address: MTU Copied from the Source Address field of the invoking As much of invoking packet packet. as will fit without the ICMPv6 packet exceeding the minimum IPv6 MTU
Code Set to 0 by the sender and ignored by the receiver MTU The maximum transmission unit of the next-hop link
105 ICMPv6: Time exceeded 32 bits
Type=3 Code Checksum IPv6 Header Destination Address: Unused Copied from the Source Address field of the invoking As much of invoking packet packet. as will fit without the ICMPv6 packet exceeding the minimum IPv6 MTU
Unused This field is unused for all code Code 0 – Hop limit exceeded in transit values. It must be initialized to zero 1 – Fragment reassembly time by the sender and ignored by the exceeded receiver.
106 ICMPv6: Parameter problem 32 bits
Type=4 Code Checksum IPv6 Header Destination Address: Pointer Copied from the Source Address field of the invoking As much of invoking packet packet. as will fit without the ICMPv6 packet exceeding the minimum IPv6 MTU
Pointer Identifies the octet offset within the Code 0 - erroneous header field invoking packet where the error was encountered detected. 1 - unrecognized Next Header type The pointer will point beyond the end encountered of the ICMPv6 packet if the field in 2 - unrecognized IPv6 option error is beyond what can fit in the encountered maximum size of an ICMPv6 error message.
107 ICMPv6: Echo request 32 bits
Type=128 Code=0 Checksum IPv6 Header Destination Address: Identifier Sequence Number Any legal IPv6 address.
Data
Code 0 Identifier An identifier to aid in matching Echo Replies to this Echo Request. May be zero. Sequence Number A sequence number to aid in matching Echo Replies to this Echo Request. May be zero. Data Zero or more octets of arbitrary data.
108 ICMPv6: Echo reply 32 bits
Type=129 Code=0 Checksum IPv6 Header Destination Address: Identifier Sequence Number Copied from the Source Address field of the invoking Echo Request packet. Data
Code 0 Identifier The identifier from the invoking Echo Request message. Sequence Number The sequence number from the invoking Echo Request message Data The data from the invoking Echo Request message.
109 Neighbor discovery
Provides functionality for • Serverless autoconfiguration • Router discovery • Prefix discovery • Address resolution • Neighbor unreachability detection • Link MTU discovery • Next-hop determination • Duplicate address detection
110 Neighbor discovery
ND makes use of five ICMPv6 packets to provide IPv6 nodes with the information they need before communicating
133 Router solicitation (RS) 134 Router advertisement (RA) 135 Neighbor solicitation (NS) 136 Neighbor advertisement (NA) 5 Redirect
111 Router solicitation (RS)
ICMP packet type 133 Sent by host to speed up learning of link-local routers Source address is sending host‘s address or 0:0:0:0:0:0:0:0 (if no address is assigned to the sending interface) Destination address is typically all-routers multicast address: FF02::2 May contain sender‘s link layer address (MUST NOT be included if the Source Address is the unspecified address. Otherwise, it SHOULD be included on link layers that have addresses.) Reply is a Router Advertisement (RA) 112 Router solicitation (RS) format
32 bits
Type=133 Code=0 Checksum
Reserved (unused, initialized to zero by the sender)
Options....
The only valid option is the Source Link-Layer which MUST be included if known e.g. the EUI-64 value of the interface else no option field should be included.
113 Router advertisement (RA)
ICMP packet type 134 Sent by routers periodically or in response to a solicitation to provide information necessary for a node to configure itself Source address is link-local address of the sending router Destination address is either – unicast address of a node that sent an RS, or – link-scope all-nodes multicast address: FF02::1 Hop-limit MUST be set to 255 Possible options contained in RA: – Source link layer address of the router – MTU – Prefix information about on-link prefixes
114 Router advertisement (RA) format 32 bits
Type=134 Code=0 Checksum
Cur. Hop Limit M O Reserved Router lifetime
Reachable Time
Retransmit Timer
Options....
Cur Hop Limit 8-bit unsigned integer. The default value that should be placed in the Hop Count field of the IP header for outgoing IP packets. A value of zero means unspecified (by this router). M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. O 1-bit "Other stateful configuration" flag. When set, it indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network. 115 Neighbor discovery: Router solicitation Default GW-List E A B C
D
C A
RS B F G
RA
116 Neighbor discovery: Router advertisement Default GW-List E A
D
C A
B F G
RA
117 Neighbor solicitation (NS)
• ICMP packet type 135 • Used to provide/obtain link-layer address to/of a neighbor • Used to verify neighbor reachability • IPv6 Source-address is link-local address of soliciting node • IPv6 Destination-address is either – solicited-node multicast address associated with target IP address (link layer determination) FF02:0:0:0:0:1:FF XX:XXXX – Unicast address of the target (reachability verification) • Hop-limit MUST be set to 255 • Reply is a Neighbor advertisement (NA)
118 Neighbor solicitation (NS) format
32 bits
Type=135 Code=0 Checksum
Reserved
Target address
Options....
Target Address: The IP address of the target of the solicitation. It MUST NOT be a multicast address. Possible options: Source link-layer address, which is the link-layer address for the sender. MUST NOT be included when the source IP address is the unspecified address. Otherwise, on link layers that have addresses this option MUST be included in multicast solicitations and SHOULD be included in unicast solicitations. 119 Neighbor advertisement (NA)
• ICMP packet type 136 • Sent in response to NS or unsolicited to immediately propagate new information • Source address is any valid unicast address assigned to sending node • Destination address is – For solicited advertisements • Source address of the solicitation • If address of NS is unspecified: all-nodes multicast address – For unsolicited advertisements • All-nodes multicast • Hop-limit MUST be set to 255
120 Neighbor advertisement (NA) format 32 bits
Type=136 Code=0 Checksum
R S O Reserved
Target address
Options....
R Router flag. When set, the R-bit indicates that the sender is a router. S Solicited flag. When set, the S-bit indicates that the advertisement was sent in response to a Neighbor Solicitation from the Destination address. The S-bit is used as a reachability confirmation for Neighbor Unreachability Detection. It MUST NOT be set in multicast advertisements or in unsolicited unicast advertisements. O Override flag indicates that the information of the message should override an existing Neighbor chache for which no link layer address exists 121 Redirect
32 bits
Type=137 Code=0 Checksum
Reserved
Target address
Destination address
Options....
122 Redirect Default GW-List E ICMP Redirect to A Router B B C
D Sent data to Host 3 using Default GW "A" C A
Path used with Default Gateway "A" Redirect traffic via Router B B F G
Host 3
123 Next-hop discovery The neighbor cache is the IPv6equivalent of the Address Resolution Protocol (ARP) cache on an IPv4 host. A host that has a packet to send must first determine what next hop to use. If a packet was previously sent to the destination, the next hop might be stored in a destination cache. Check neighbor cache, kept updated from previous packet transmissios, for existing next-hop entry for particular destination. If not in cache, longest prefix match is done. Check whether destination is on- or off-link On-link: Sent directly to destination Off-link: Sent to default router. Possible redirect. Identify link-layer address of next-hop
124 Default router selection
A Host selects one router from it‘s default router list, if – destination is off-link AND no cache entry exists for the destination OR – Exisiting default router appears to be failing • Default router is selected the first time traffic is sent to an off-link destination. This selection is cached and used for subsequent transmission. • REACHABLE routers have coarse preference metric (low, medium, or high). • If multiple reachable routers exist, selection process depends on vendor‘s implementation
125 Neighbor unreachability detection The process by which a node determines that IPv6 packets cannot be exchaged with a neighboring node. After the link-layer address for a neighbor has been determined, the state of the entry in the neighbor cache is tracked. If the neighbor is no longer exchanging packets, the neighbor cache entry is eventually removed.
2 ways to verify neighbor reachability: – Using hints from upper-layer protocols – From responses to neighbor solicitations Forward direction communication (FDC) must be possible for a neighbor to be REACHABLE FDC is verified if forward progress is being made by an upper-layer protocol (i.e. TCP, reception of TCP acks)
126 Neighbor unreachability detection
• If no verification can be received from upper-layer protocols (like UDP): – Node actively probes neighbors to determine reachability state • Probes are sent in conjunction with traffic. No traffic, no probes! • Probe is neighbor solicitation (NS) • Neighbor advertisement (NA) reply is expected to establish FDC
127 Neighbor unreachability detection
• Neighbor cache stores information about neighbors – IP address – Link-layer address – Reachability state • Neighbor reachability states (RFC 4861, updated by RFC 7048) – INCOMPLETE: Address resolution is being performed on the entry. Specifically, a NS has been sent to the solicited-node multicast address of the target, but the corresponding NA has not yet been received. – REACHABLE: Forward-direction communication has been verified within the past (e.g.) 30 seconds. – STALE: An entry in the neighbor cache has not been verified as reachable within the past 30 seconds. An unsolicited NA message will add an entry to the cache for the sender of the message, with the state STALE. No action is required until traffic is sent to the STALE entry. – DELAY: No reachable verification has been received within the past 30 seconds, and a packet has been sent to the specified neighbor within the past 5 seconds. If no positive confirmation is received within 5 seconds of entering DELAY state, send an NS and change state to PROBE. – PROBE: An NS has been sent to verifiy reachability. No NA has yet been received. After N unsuccessful attempts discart entity (RFC 4861).
– UNREACHABLE (RFC 7048). Increase timeout and send multicast NS. 128 Stateless Autoconfiguration
1. RS 2. RA 2. RA
1 - ICMP Type = 133 (RS) 2 - ICMP Type = 134 (RA) Src = :: Src = Router Link-local Address Dst = All-Routers multicast Address Dst = All-nodes multicast address query= please send RA Data= options, prefix, lifetime, autoconfig flag
Router solicitations are sent by booting nodes to request RAs for configuring the interfaces.
129 Auto configuration
“Plug and play” feature
Stateless mode : via ICMP (no server required) Prefix Link Address = IPv6 Address 3ffe:89::/64 + 00:A87:C09:1BE:CC7:BA 3ffe:89::A87:C09:1BE:CC7:BA
router advertisement
Stateful server mode : via DHCP
DHCP server DHCP response DHCP request 3ffe:89::A87:C09:1BE:CC7:BA 00:A87:C09:1BE:CC7:BA
130 Auto configuration
Renumbering SUBNET PREFIX + Hosts renumbering is done by RA indicates MAC ADDRESS SUBNET modifying the RA to announce PREFIX the old prefix with a short lifetime and the new prefix.
Router renumbering protocol (RFC 2894), to allow domain- SUBNET PREFIX + MAC ADDRESS interior routers to learn of At boot time, an IPv6 host prefix introduction / build a Link-Local address, withdrawal then its global IPv6 address(es) from RA
131 IPv6 Addressing Examples
LAN: 3ffe:b00:c18:1::/64
Ethernet0
interface Ethernet0 ipv6 address 2001:410:213:1::/64 eui-64 MAC address: 0060.3e47.1530
router# show ipv6 interface Ethernet0 Ethernet0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::260:3EFF:FE47:1530 Global unicast address(es): 2001:410:213:1:260:3EFF:FE47:1530, subnet is 2001:410:213:1::/64 Joined group address(es): FF02::1:FF47:1530 FF02::1 FF02::2 MTU is 1500 bytes
132 Duplicate address detection
Must be performed by all nodes Performed before assigning a unicast address to an interface Performed on interface initialization Not performed for anycast addresses Link must be multicast capable New address is called "tentative" as long as duplicate address detection takes place
133 Duplicate Address Detection
A B
ICMP type = 135 Src = 0 (::) Dst = Solicited-node multicast of A Data = link-layer address of A Query = what is your link address?
Duplicate Address Detection (DAD) uses neighbor solicitation to verify the existence of an address to be configured.
134 Duplicate address detection
• If address already exists, the particular node sends a NA reply with – Target address = tentative IP address – Destination address = tentative solicited-node address • If soliciting node receives NA reply with target address set to the tentative IP address, the address must be duplicate
135 Overview of Mobile IPv6
CN
4. 3.
HA
1. 2. MN
• 1. MN obtains Local IP address using stateless or stateful autoconfiguration – Neighbor Discovery • 2. MN registers with HA by sending a Binding Update • 3. HA intercepts traffic for registered MN and tunnels packets from CN to MN • 4. MN sends packets from CN directly or via HA using Tunnel
136 Route Optimization Correspondent Home Host Agent
CN to MN
Mobile Node
• Traffic is routed directly from the CN to the MN • Binding Update SHOULD be part of every IPv6 node implementation • IPv4 also has route optimization but CN needs enhanced IP stack and Key management is a problem • Security Issues – – Shared Key or PKI Problem and We need a Scalable Solution
137