IPv6 Basics


    The post is a brief summary of Wiki , TechNet , FreeBSD’s handbook , Serverfault , many RFCs and IANA documents , as well as courses from Specialist.ru for Yandex employees.

    The post can be seen as a piggy bank of links on the current IPv6 specification for 2012. However, it does not describe in any way possible ways to establish an IPv6 connection to the Internet and is not tied to any particular OS.
    Note that reading this habrastaty will take you no more than half an hour, but it is highly recommended that you familiarize yourself with all the links provided in the article ... The latter may take several weeks.


    Although the article is called “IPv6 Basics”, it still implies the presence of basic knowledge of IP networks and at least a little practical experience with IPv6, otherwise habrastatia will be very difficult.
    It is also recommended that you read Cisco Implementing IPv6 Addressing and Basic Connectivity .
    It is also worth noting that the links provided on Wikipedia are often more noteworthy in the References section than in their content.

    IPv6 Addresses

    Anatomy of IPv6 Addresses

    In the first version of this hub there was a lot of text, but from that moment on Wikipedia, an excellent article grew up: IPv6 Address .

    Subnet masks

    Masks are now only set 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 Allocation

    As with IPv4, IPv6 addresses are allocated through a hierarchy of organizations :
    RIR (/ 12- / 23) -> NIR (??) -> LIR (/ 19- / 32) -> ISP (/ 48- / 56) -> LAN (=> / 64)
    ISPs already allocate addresses to networks as they want. However, there is Best-Practice from IPv6 Task Force: Guidelines for ISPs on IPv6 Assignment to Customers .
    In general, wishes for IPv6 allocation are described in RFC5375 IPv6 Unicast Address Assignment Considerations
    Also an interesting detail: IPv6 routing tables were originally planned to be made as "as aggregate" as possible, which implied the absence of Provider-Independent (PI)addresses. However, large corporations (apparently wishing to do BGP-failover) in 2009 still “pushed” RIPE , so now it is possible to get PI addresses in IPv6.

    Types of Addresses and Their Prefixes

    IPv6 addressing is described in detail in RFC4291 . Next, I will describe the most common types of IPv6 addresses, their purpose and prefixes.
    • ::/128 - Unspecified - must not belong to any node in the network;
    • ::/0 - Default route;
    • ::1/128 - Loopback;
    • fe80::/10 - Link-Local- unique addresses on the link. Creating the IPv6 link-localaddress from the prefix fe80::and MAC address of the network card, as well as much more is described in the presentation from Microsoft and in the document Introduction to IP Version 6 , the procedure for creating the modified EUI-64 identifier on the fingers is explained in Appendix A of RFC4291 );
    • fec0::/10 - Site-Local- Deprecated judging by RFC3879 ;
    • fc00::/7 - Unique Site-Local- came to replace Site-Local in RFC4193 . It is currently divided into two parts: fc00 :: / 8 and fd00 :: / 8. Unique within the organization , not routed to Internet addresses. However, they can be routed inside the site and between sites;
    • ff00::/8 - Multicast- I’ll talk about the multicast in more detail below. The full list of multicast addresses can be found here: IANA IPv6 Multicast Addresses ;
    • ::0000/96 - IPv4-Compatible IPv6 Address- out of date ;
    • ::ffff/96 - IPv4-Mapped IPv6 Address- Addresses designed primarily for the Socket API. Their purpose is described in more detail in RFC4038 . Reading this RFC will be useful to programmers who are going to write dual-stack applications;

    All "non-special" addresses relate to:
    Global Unicast- global addresses that are unique throughout the Internet. So far, however, judging by this document , only global space is available 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, and not optional as in IPv4. IGMP has been replaced with MLD ( Multicast Listener Discovery ). And the procedure for obtaining a global multicast prefix has become trivial - now when you receive a / 64 prefix, the provider automatically receives 4.2 billion global multicast groups. The procedure is described in detail in RFC3306 , and is also complemented by embedding the RP address directly in 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 view the list of groups for interfaces in FreeBSD via ifmcstator through ip maddrLinux);
    • 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 provides optimal routing protocol in terms of routing protocol;
    • Broadcast- in IPv6 broadcast does not exist. In place of it, you can use All Nodes Address . Packets sent to it will be sent only to hosts with a configured IPv6 address (with MLD snooping enabled); Also, some of the protocols that used Broadcast in the IPv6 version also got their own multicast group;

    Address scope

    In IPv6, there was such a thing as Scope , aka Zone ID Microsoft terminology. In fact, it was also in IPv4, but it was not explicitly defined: 10/8, 172.16 / 12 and 192.168 / 16 networks are vivid examples of this.

    For Unicast / Anycast addresses, the following applies:
    Each IPv6 enabled interface has its own Link-local address. Its scope, suddenly, local. These addresses are unique within the link, but are not required to be relevant within the same host. So, for example, a VLAN created on an interface will have the same link-local address as the parent interface (since without using IPv6 Privacy Extensions it will be generated from the same Link Layer address). In order to explicitly indicate the interface to which the IPv6 address belongs, you must either specify it in the manual interface for outgoing packets or use a special suffix when writing the address:% Interface Index on Windows (fe80 :: 2b0: d0ff: fee9: 4143% 3) or% Interface Name in * BSD / Linux (fe80 :: 2b0: d0ff: fee9: 4143% em0).
    In the case of Multicast addresses, scope is indicated in the last four bits of the second octet of the IPv6 address: ff0 s:: and can be interface-local, link-local, admin-local, site-local, organization-local or global.
    Additionally, check out 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 - The main 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 Packet

    IPv6 packet header

    Significant changes in package header format
    • Fixed header size
    • There is no Checksum header, therefore, it does not need to be checked, and also recounted for each packet when changing TTL Hop Limit. Since checksum is no longer there, the entire responsibility for the integrity of information should 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 called Hop Limit (most likely because earlier one of the conditions of the router was to reduce TTL by one every second a packet arrives in the queue, 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 change;
    • Routers are no longer involved in packet fragmentation. Hosts must conduct Path MTU discovery themselves and break packets. The minimum MTU is now 1280.
    • Stream Labels have been added , they are used to offload routers, more accurately prioritize traffic and balance. More details can be found in RFC6437 - IPv6 Flow Label Specification . There are still battles about using this IPv6 header field in practice. Epic threads can be read in RFC6294 - Survey of Proposed Use Cases for the IPv6 Flow Label , RFC6436 - Rationale for Update to the IPv6 Flow Label Specification and RFC6438 - Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels . The only operating system (of those we tested) that does not set the default flow labels is 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 nicrophilia, you can read the rest of the Historical notes on the wiki;
    • IPSec support is now required;

    Extension headers

    The packet header is now fixed in length and noticeably simplified, but thanks to Extension Headers , more flexibility is provided than IPv4 Options , which, due to the 40-byte size limit, were 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, it 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. The following types of Extension Headers are currently available:
    • Hop-by-Hop Options- any router on the route of the 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 look at it, and if there is one, it should go immediately after the IPv6 header.
    • Routing- RFC5095 cancels Type 0 Routing Headers, which contain DoS in their definition of vulnerability (even more serious than source routing in IPv4). The topic of security in IPv6 is discussed in more detail in RFC4942 and in the presentation of Security Implications of IPv6 .
    • Fragment- The fragmented packet header. As I already mentioned, routers no longer deal with fragmentation, so the sender himself must take care of the optimal packet size, otherwise he will get Packet too big from one of the routers on the way. By the way, MTU for IPv6 should not be less than 1280.
    • Destination Options - Options intended only for the recipient.

    There are also IPSec authentication and encryption headers :

    IPv6 Protocols


    ICMP in IPv6 has been replaced by ICMPv6 . Read about ICMPv6 in the RFC4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification .
    ICMPv6 itself is quite simple, but a lot of rather non-trivial protocols have been made on its basis, which we will talk about below.


    Multicast Listener Discovery is an ICMPv6-based protocol. An analogue of IGMP for IPv6. See details in RFC3810 - Multicast Listener Discovery Version 2 (MLDv2) for IPv6 .


    A description of the Neighbor Discovery Protocol , which replaced ARP, is available in RFC4861 . Now this is not a separate protocol, but an add-on to ICMPv6 adding several new types of messages.
    The main purpose of NDP is to map between link-layer and IPv6 addresses, however this is only a small part of the functionality.

    What else can NDP do:
    • Neigbour Unreachability Detection, which allows you to determine host availability using one of two methods:
      • Using a higher level protocol;
      • Using unicast solicitation, to which the host should respond with a Neighbor Advertisement message;
    • Duplicate address detection
    • Sending and processing redirects
    • Definition of link parameters (e.g. MTU)
    • Defining network services (e.g. DNS: RFC6106 IPv6 Router Advertisement Options for DNS Configuration )
    • Stateless autoconfiguration (more on that below)

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



    As mentioned above, hosts can automatically generate an IPv6 link-local address from a link layer address. So without any configuration, any IPv6-enabled host connected to the network gives itself a network layer address.
    In IPv4, this technology uses the 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's 2462).


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


    In addition to stateful configuration in IPv6, there is also 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 set the prefix which it will announce through the Router Advertisement of the rest of the network. Hosts will receive RA and configure IPv6 address based on the prefix and their link-layer address.
    A couple of comments:
    • Stateless addressing is possible only if there is a router / roters sending out RA;
    • Each router has priority: high / medium / low. The operating system should consider it when choosing the default route;
    • RFC6106 - IPv6 Router Advertisement Options for DNS Configuration explains how to embed DNS server addresses directly in RA, which eliminates the need for DHCPv6 for this purpose. However, this is not supported by all vendors;
    • Generating an IPv6 address using your link-layer is not very secure in terms of privacy. Your movements around the world and sometimes the model of equipment will be available throughout the Internet. The solution was described in RFC4941 - Privacy Extensions for Stateless Address Autoconfiguration in IPv6 . All modern operating systems support Privacy Extensions;


    Both types of autoconfiguration can be used simultaneously, for example, stateless for receiving IPv6 prefix and stateful for obtaining addresses of DNS servers and / or other parameters that cannot be transmitted using Router Advertisement.


    Little attention has been paid to this point in the IPv6 documentation, but judging by the number of RFCs on this topic, the changes are enormous.
    To fully support IPv6, a lot of changes have been introduced in the DNS system ( RFC3152 , RFC3226 , RFC3363 ) and still there are 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 of them are described in RFC3364. In short, A6 provides more flexibility and less zone dependency on the prefix, and AAAA is just a special case of A6 with a long prefix of 0. A6 was later 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. A PTR record may also be required. Reverse DNS records for IPv6 look horrific. So, for example, the return for the address 4321:0:1:2:3:4:567:89abwill look like b.a. This spectacle is not for the faint of heart, however, it is likely to encourage people to automatically generate returns. For manual generation, I would recommend sipcalc with the -r switch or something similar.


    Higher layer protocols

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

    Tuning IPv6 traffic over IPv4 networks

    Here, quite casually about some possible technologies :
    • Static point-to-point MCT / GRE tunnels;
    • 6to4 . Uses the 2002 :: / 16 range. There is also a variant of it for customer devices that on the “other” side do not have a dedicated server for de-encapsulating packets: they send encapsulated packets to anycast address which is advertised from multiple 6to4 gateways using dynamic routing protocols;
    • Teredo / Miredo. It does not work with all types of NATs;
    • ISATAP - Intra-Site Automatic Tunnel Addressing Protocol. Usually tied to the use of DNS (Through resolution isatap.example.com);

    Mobile IPv6

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

    IPv6 address as a repository of information

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

    Socket API

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


    Despite all my attempts to structure everything, the article 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 directory of IPv6 links, both for me and for the entire habrasociety.
    However, it is possible, before burying your head in RFC and tcpdumps, you can first read books, for example, IP'6 Essentials from O'Reilly should greatly help the assimilation of the material described in this article.

    Also popular now: