The Basics of IPv6

Foreword

The post is a brief summary of the Wiki , TechNet , FreeBSD handbook , Serverfault , a variety of RFCs and IANA documents, as well as courses from Specialist.Ru for Yandex employees.



The post can be viewed as a piggy bank of links on the current IPv6 specification for 2012. However, it does not describe in any way possible ways of establishing an IPv6 connection to the Internet and is not tied to any particular OS.

Consider that reading this habrastation will take you no more than half an hour, however, it is highly recommended that you read all the links in the article ... The latter may take several weeks.

Prerequisites

Although the article is called “IPv6 Basics”, it still implies basic knowledge of IP networks and at least some practical experience with IPv6, otherwise habrastat will not be very easy.

It is also recommended to read the document Implementing IPv6 Addressing and Basic Connectivity from Cisco.

It is also worth noting that the links to Wikipedia are often more remarkable in the References section than with their content.

IPv6 Addresses

Anatomy of IPv6 addresses

In the first version of this site, there was a lot of text here, but from that moment on Wikipedia a great article has grown: IPv6 Address .

')

Subnet masks

Masks are now set only by / prefix ( CIDR ), there is no class addressing and standard decimal dotted notation in IPv6. Also, now the first and last network addresses are not reserved for the network identifier and broadcast respectively.

IPv6 address allocation

As in the case of IPv4, IPv6 addresses are allocated through a whole hierarchy of organizations :

RIR (/ 12- / 23) -> NIR (??) -> LIR (/ 19- / 32) -> ISP (/ 48- / 56) -> LAN (=> / 64)

ISPs are already allocating addresses to networks as they wish. However, there is also the Best-Practice from IPv6 Task Force: Guidelines for ISPs on IPv6 Assignment to Customers .

In general, requests for IPv6 address allocation are described in RFC5375 IPv6 Unicast Address Assignment Considerations

Also an interesting detail: The routing tables in IPv6 were initially planned to be made as aggrimmeable as possible, which implied the absence of Provider-Independent (PI) addresses. However, large corporations (apparently willing to do BGP-failover) in 2009 still “pushed” RIPE , so getting PI addresses in IPv6 is now realistic.

Address types and their prefixes

IPv6 addressing is detailed in RFC4291 . Next, I will describe the most common types of IPv6 addresses, their destination and prefixes.

• ::/128 - Unspecified - should not belong to any node in the network;
• ::/0 - Default route ;
• ::1/128 - Loopback ;
• fe80::/10 - Link-Local - addresses unique on the link. Creating an IPv6 link-local address from the fe80:: prefix and the MAC address of the network card, as well as much more, is described in the Microsoft presentation and in the Introduction to IP Version 6 document. The procedure for creating a modified EUI-64 identifier on fingers is explained in Appendix A of RFC4291 );
• fec0::/10 - Site-Local - expired judging by RFC3879 ;
• fc00::/7 - Unique Site-Local - Replaced Site-Local in RFC4193 . Currently divided into two parts: fc00 :: / 8 and fd00 :: / 8. Unique within the organization , not routed to the Internet address. However, they can be routed inside the site and between sites;
• ff00::/8 - Multicast - I'll tell you more about multicaste below. A full list of multicast addresses can be found here: IANA IPv6 Multicast Addresses ;
• ::0000/96 - IPv4-Compatible IPv6 Address - deprecated ;
• ::ffff/96 - IPv4-Mapped IPv6 Address - Addresses intended ::ffff/96 - IPv4-Mapped IPv6 Address for the Socket API. Their purpose is described in more detail in RFC4038 . Reading this RFC will be useful for programmers who are going to write Dual-Stack applications;

All “non-special” addresses refer to:

Global Unicast - global addresses, unique in the whole Internet. So far, however, judging by this document , only global space 2000::/3 (Addresses from 2000:: to 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff )

Types of traffic

• Unicast - Good old unicast;
• Multicast - Multicast is now a necessary extension, not an optional IPv4 version. IGMP has been replaced by MLD ( Multicast Listener Discovery ). And the procedure for obtaining a global multicast prefix has become trivial - now when receiving a / 64 prefix, the provider automatically receives 4.2 billion global multicast groups. The procedure is described in detail in RFC3306 , as well as complemented by the implementation of the RP address directly into the IPv6 address in RFC3956 . Obtaining a global multicast prefix for IPv4 and IPv6 is described in RFC6308 . It is also worth noting that in IPv4 Multicast link-layer the prefix was 01: 00: 5e, in IPv6 it became 33: 33: ff (you can see the list of groups for interfaces in FreeBSD via ifmcstat or via ip maddr in Linux);
• Anycast - The same anycast as in IPv4. This type of address is usually announced by a dynamic routing protocol (for example, BGP) from several places at once. This ensures optimal routing routing;
• Broadcast - there is no broadcast in IPv6. In place of it, you can use All Nodes Address . Packets sent to it will be sent only to hosts with an IPv6 -configured address (with MLD snooping enabled); Also, some of the protocols that used Broadcast in the IPv6 version even got their own multicast group;

Address scope

In IPv6, a concept such as Scope , also known as Microsoft's Microsoft Zone ID, appeared. In fact, it was in IPv4, but it was not explicitly specified: 10/8, 172.16 / 12 and 192.168 / 16 networks are vivid examples of this.



In the case of Unicast / Anycast addresses, the following is applicable:

Each IPv6 enabled interface has a Link-local address. Its scope is, suddenly, local. These addresses are unique within the link, but not required to be relevant within the same host. So, for example, the VLAN created on the interface will have the same link-local address as the parent interface (since without IPv6 Privacy Extensions it will be generated from the same Link Layer address). In order to explicitly specify the interface to which the IPv6 address belongs, you need to either specify the manual interface for outgoing packets or use a special suffix when writing the address:% Index of the Interface in Windows (fe80 :: 2b0: d0ff: fee9: 4143% 3) or% Name of the Interface in * BSD / Linux (fe80 :: 2b0: d0ff: fee9: 4143% em0).

In the case of Multicast, the scope addresses are specified in the last four bits of the IPv6 address octet of the address: ff0 s :: and can be interface-local, link-local, admin-local, site-local, organization-local, or global.

Additionally, you should familiarize yourself with RFC4007 IPv6 Scoped Address Architecture

IPv6 address life cycle

The following states of an IPv6 address are possible throughout its life cycle:

• Tentative - The address is still checked for uniqueness;
• Valid - Traffic to this address will be received by the host, divided into 2 substates:
  
  
  • Prefered state - Basic state, unlimited use of the address;
  • Deprecated state - The address can still be used for old connections, but you cannot create new connections;
  
  
  
• Invalid - The address cannot be used to receive / send packets.

IPv6 Package

IPv6 packet header

Significant changes in package header format

• Fixed header size;
• There is no Checksum header, accordingly, it does not need to be checked, and also recalculated for each packet when the TTL Hop Limit changes. Since the checksum is no longer present, the entire responsibility for the integrity of the information must lie with the lower level protocol, for example, Ethernet frames have their own honest CRC32. Also for UDP packets, checksum is now mandatory and UDP / IPv6 packets with Checksum 0000 will simply be discarded by the receiving host;
• TTL itself is now referred to as Hop Limit (most likely because earlier one of the conditions of the router was to reduce TTL by one every second when a packet was queued, therefore TIME-to-live). In connection with the latest trend with the widespread introduction of MPLS / TE, it is worth noting that when an IP packet passes through MPLS, its TTL / HopLimit cloud may not and does not change;
• Routers are no longer involved in packet fragmentation. Hosts must themselves conduct Path MTU discovery and split packets. The minimum MTU is now 1280.
• Flow Marks have been added, used to unload routers, more accurately prioritize traffic and balancing. More detail can be found in RFC6437 - IPv6 Flow Label Specification . There are still battles about using this IPv6 header field in practice. You can read Epic threads in RFC6294 - Survey of Proprietary Flow Labels , RFC6436 - Rationale for IPv6 Flow Label Specification and RFC6438 - Using the IPv6 Flow Label for Multipath Routing and Link Aggregation in Tunnels . The only operating system (from those we tested) that does not set the default flow labels to be FreeBSD;
• Initially (in obsoleted RFC1883 ), the Traffic Class field was called Priority and occupied 4 bits, and the flow label was 24 bits. In RFC2460, they became 8 and 20 bits, respectively. If anyone is interested in nicrofilia, you can read the rest of the Historical notes on the wiki;
• IPSec support is now mandatory;

Extension headers

The packet header is now fixed in length and noticeably simplified, however, thanks to the Extension Header, greater flexibility is provided than with IPv4 Options , which, thanks to the 40-byte size limit, was generally not usable. The structure of the IPv6 packet is described in detail in RFC2460 , here I will describe only the most basic.

Each packet contains an eight bit field called Next Header, which contains the identifier of the next header . Extension Headers can go immediately after the IPv6 header (between the header and the payload of the IPv6 packet) and include additional network layer information. Currently the following types of extension headers are available:

• Hop-by-Hop Options - any router on its way to a packet should view only the IPv6 header, all other headers are intended exclusively for the recipient of the packet. However, the Hop-by-Hop header is an exception - all routers view it and, if there is one, it should go right after the IPv6 header.
• Routing - RFC5095 cancels Type 0 Routing Headers, which contain DoS vulnerability in their definition (even more serious than source routing in IPv4). More on the topic of security in IPv6 is discussed in RFC4942 and in the presentation of Security Implications of IPv6 .
• Fragment - The header of the fragmented packet. As I already mentioned, routers are no longer involved in fragmentation, so the sender himself should take care of the optimal packet size, otherwise he will receive Packet too big from one of the routers on the way. By the way, the MTU for IPv6 operation should not be less than 1280.
• Destination Options - Options intended only for the recipient.

There are also headers for IPsec encryption and encryption:

• Authentication - RFC4302
• Encapsulating Security Payload - RFC4303

IPv6 Protocols

ICMPv6

ICMP to IPv6 has been replaced by ICMPv6 . You can read about ICMPv6 in the RFC4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification .

By itself, ICMPv6 is quite simple, but based on it, a number of rather non-trivial protocols have been made, which we will discuss below.

Mld

Multicast Listener Discovery is an ICMPv6 based protocol. Analogue IGMP for IPv6. More in RFC3810 - Multicast Listener Discovery Version 2 (MLDv2) for IPv6 .

NDP

A description of the Neighbor Discovery Protocol that replaced the ARP protocol is available in RFC4861 . Now this is not a separate protocol, but an add-on over ICMPv6 that adds several new message types.

The main purpose of NDP is to produce mapping between the link-layer and IPv6 addresses, but this is only a small part of the functionality.



What else can NDP:

• Neigbour Unreachability Detection, which allows you to determine the availability of a host by one of two methods:
  
  
  • Using a higher level protocol;
  • With the help of unicast solicitation, to which the host must respond to the Neighbor Advertisement message;
• Duplicate Address Detection
• Sending and processing redirect
• Determination of link parameters (for example, MTU)
• Identify network services (for example, DNS: RFC6106 IPv6 Router Advertisement Options for DNS Configuration )
• Stateless autoconfiguration (more on this below)

There is also a cryptographically protected analogue of the NDP - SEcure Neighbor Discovery (SEND) described in RFC3971 . SEND, in turn, uses the Cryptographically Generated Address described next in RFC3972 .

Autoconfiguration

Zeroconf

As already mentioned above, hosts are able to automatically generate their IPv6 link-local address from the link-level address. So without any configuration, any IPv6-enabled host connected to the network will give itself the address of the network layer.

In IPv4, this technology uses a reserved IPv4 range of 169.254 / 16. The technology is described in detail in RFC3927 Dynamic Configuration of IPv4 Link-Local Addresses (Note that this RFC came out after IPv6 of the 2462).

Stateful

In IPv4, autoconfiguration is only possible using a DHCP server. In IPv6, this feature was left: you can configure the network using a DHCPv6 server and client. However, support from vendors of DHCPv6 does not yet shine, for example, dhclient in FreeBSD does not know IPv6 out of the box.

Stateless

In addition to stateful configuration, IPv6 also has a stateless autoconfiguration, which allows hosts to automatically obtain IPv6 addresses on a network without a DHCP server through the use of NDP. It is enough for the router to specify the prefix that it will announce through the Router Advertisement for the rest of the network. Hosts will receive RAs and configure them based on the prefix and their link-layer IPv6 address.

A couple of comments:

• Stateless address determination is possible only if there is a router / roters sending out RA;
• Each router has a priority: high / medium / low. The operating system should consider it when choosing a default route;
• RFC6106 - IPv6 Router Advertisement Options for DNS Configuration explains how to embed DNS server addresses directly into RA, which eliminates the need for using DHCPv6 for this case. However, this is not supported by all vendors;
• Generating an IPv6 address using your link-layer is not very safe in terms of privacy. Your movements around the world and sometimes the equipment model will be available to the entire Internet. The solution to the problem was described in RFC4941 - Privacy Extensions for Stateless Address Autoconfiguration in IPv6 . All modern operating systems support Privacy Extensions;

Combined

Both types of autoconfiguration can be used at the same time, for example, stateless to get an IPv6 prefix and stateful to get DNS server addresses and / or other parameters that cannot be passed using the Router Advertisement.

DNS

This moment in the IPv6 documentation has received little attention, but judging by the number of RFCs on this topic, the changes are colossal.

To fully support IPv6, many changes were made to the DNS system ( RFC3152 , RFC3226 , RFC3363 ) and there are still a number of unresolved problems — RFC4472 .

For a while, there were even two standards for describing IPv6 addresses in DNS: A6 and AAAA , the pros and cons of each one are described in RFC3364 . In short, A6 provides greater flexibility and less zone dependency on the prefix, and AAAA is only a special case of A6 with a long prefix of 0. A6 was subsequently transferred to Experimental status in RFC3363 - Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)

For minimal IPv6 support, only one AAAA record is required. PTR recording may also be required. Reverse DNS records for IPv6 look terrifying. So, for example, the return for address 4321:0:1:2:3:4:567:89ab will look like ba9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.ARPA. . This spectacle is not for the faint of heart, however, it is likely to encourage people to automatically generate redraws. For manual generation, I would recommend sipcalc with the –r key or something similar.

Other

Higher protocols

Some of the protocols that use the network-layer address in their work required that they be made certain of changes in order to start working on IPv6. A good example of such a protocol is FTP .

Tunneling IPv6 traffic over IPv4 networks

There is a very casual way about some possible technologies :

• Static point-to-point MCT / GRE tunnels;
• 6to4 . Uses the 2002 :: / 16 range. There is also a variation of it for customer devices that do not have a dedicated server for de-encapsulating packets from the “other” side: they send encapsulated packets to anycast address 192.88.99.1, which is advertised from a variety of 6to4 gateways using dynamic routing protocols;
• Teredo / Miredo. Does not work with all types of NATs;
• ISATAP - Intra-Site Automatic Tunnel Addressing Protocol. Usually tied to the use of DNS (via rezolv isatap.example.com);

Mobile IPv6

I don’t know anything about him, so I’ll just leave it here: Mobile IP .

IPv6 address as a repository of information

Agree 128bit is a huge scope for imagination. There are many technologies that are trying to use these same 128bit. From coding there IPv4 addresses and cryptographic signatures to determining the distance between nodes (here, by the way, even we thought in this direction, but for now let's look at ALTO: Application-Layer Traffic Optimization (ALTO) Problem Statement ).

Socket API

Habratopik describes IPv6 from the point of view of the NOC / system administrator, but not from the point of view of the programmer. If someone is interested in the features of IPv6 programming, I recommend referring to the RFC3493 - Basic Socket Interface Extensions for IPv6 and the IPv6 Network Programming book

Afterword

Despite all my attempts to structure the article, it turned out to be rather messy. Perhaps this is due to its purely theoretical orientation, perhaps due to the fact that he himself has not yet settled everything in his head. In any case, I hope it will serve as a good reminder and reference directory for IPv6, both for me and for the entire hardware community.

However, it is possible that before you bury your head in RFC and tcpdump, you can first read the books, for example, O'Reilly's IPv6 Essentials should greatly assist in the assimilation of the material described in this article.