Certified IPv6 Engineer (MTCIPv6E)

Extra resources

IPv6 address
Designed as the successor to IPv4
Development started in 1996
First IPv6 specification in 1998 (RFC 2460)

Address distribution

Only one eighth of the total address space is currently allocated for use on the
Internet, 2000::/3, in order to provide efficient route aggregation, thereby
reducing the size of the Internet routing tables; the rest of the IPv6 address
space is reserved for future use or for special purposes.

/3 - Earth
/12 - RIR
/32 - LIR
/48 and /56 Provider aggregatable (PA) assignment
/48 Provider independent (PI) assignment

Address notation (From RFC5952)

A single IPv6 address can be text represented in many ways. Examples are shown
below.

2001:db8:0:0:1:0:0:1
2001:0db8:0:0:1:0:0:1
2001:db8::1:0:0:1
2001:db8::0:1:0:0:1
2001:0db8::1:0:0:1
2001:db8:0:0:1::1
2001:db8:0000:0:1::1
2001:DB8:0:0:1::1

All of the above examples represent the same IPv6 address.

'It is not necessary to write the leading zeros in an individual field.'

Conversely, it is also not necessary to omit leading zeros. This

means that it is possible to select from representations such as
those in the following example. The final 16-bit field is different,
but all of these addresses represent the same address.

2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
2001:db8:aaaa:bbbb:cccc:dddd:eeee:1

Zero Compression

'A special syntax is available to compress the zeros. The use of

"::" indicates one or more groups of 16 bits of zeros.'

It is possible to select whether or not to omit just one 16-bit 0

field.

2001:db8:aaaa:bbbb:cccc:dddd::1
2001:db8:aaaa:bbbb:cccc:dddd:0:1

In cases where there is more than one field of only zeros, there is a
choice of how many fields can be shortened.
 2001:db8:0:0:0::1
2001:db8:0:0::1
2001:db8:0::1
2001:db8::1

In addition, Section 2.2 of [RFC4291] notes,

'The "::" can only appear once in an address.'

This gives a choice on where in a single address to compress the

zero.

2001:db8::aaaa:0:0:1
2001:db8:0:0:aaaa::1

Uppercase or Lowercase

[RFC4291] does not mention any preference of uppercase or lowercase.

2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa

A Recommendation for IPv6 Text Representation

A recommendation for a canonical text representation format of IPv6

addresses is presented in this section. The recommendation in this
document is one that complies fully with [RFC4291], is implemented by
various operating systems, and is human friendly. The recommendation
in this section SHOULD be followed by systems when generating an
address to be represented as text, but all implementations MUST
accept and be able to handle any legitimate [RFC4291] format. It is
advised that humans also follow these recommendations when spelling
an address.

Handling Leading Zeros in a 16-Bit Field

Leading zeros MUST be suppressed. For example, 2001:0db8::0001 is

not acceptable and must be represented as 2001:db8::1. A single 16-
bit 0000 field MUST be represented as 0.

"::" Usage
Shorten as Much as Possible

The use of the symbol "::" MUST be used to its maximum capability.
For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1.
Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::"
could have been used to produce a shorter representation 2001:db8::1.

Handling One 16-Bit 0 Field

The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
2001:db8::1:1:1:1:1 is not correct.

Choice in Placement of "::"

When there is an alternative choice in the placement of a "::", the

longest run of consecutive 16-bit 0 fields MUST be shortened (i.e.,
the sequence with three consecutive zero fields is shortened in 2001:
0:0:1:0:0:0:1). When the length of the consecutive 16-bit 0 fields
are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero
bits MUST be shortened. For example, 2001:db8::1:0:0:1 is correct
representation.

Lowercase
 The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
MUST be represented in lowercase.

SLAAC IPv6 address creation (EUI-64) From RFC4291

Creating Modified EUI-64 Format Interface Identifiers

Links or Nodes with IEEE EUI-64 Identifiers

The only change needed to transform an IEEE EUI-64 identifier to an

interface identifier is to invert the "u" (universal/local) bit. An
example is a globally unique IEEE EUI-64 identifier of the form:

|0 1|1 3|3 4|4 6|

|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+

where "c" is the bits of the assigned company_id, "0" is the value of
the universal/local bit to indicate universal scope, "g" is
individual/group bit, and "m" is the bits of the manufacturer-
selected extension identifier. The IPv6 interface identifier would
be of the form:

|0 1|1 3|3 4|4 6|

|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+

The only change is inverting the value of the universal/local bit.

Address types (From RFC4291)

Address type Binary prefix IPv6 notation Section
------------ ------------- ------------- -------
Unspecified 00...0 (128 bits) ::/128 2.5.2
Loopback 00...1 (128 bits) ::1/128 2.5.3
Multicast 11111111 FF00::/8 2.7
Link-Local unicast 1111111010 FE80::/10 2.5.6
Global Unicast (everything else)

Link-local

Link-Local addresses are for use on a single link. Link-Local

addresses have the following format:

| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111010| 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.

Multicast
ff00::/8 are multicast addresses [RFC4291]. They contain a 4-bit
scope in the address field where only some values are of global scope
[RFC4291]. Only addresses with global scope in this block may appear
on the public Internet.

Multicast routes must not appear in unicast routing tables.

 All Nodes Addresses: FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1

The above multicast addresses identify the group of all IPv6 nodes,
within scope 1 (interface-local) or 2 (link-local).

All Routers Addresses: FF01:0:0:0:0:0:0:2

FF02:0:0:0:0:0:0:2
FF05:0:0:0:0:0:0:2

The above multicast addresses identify the group of all IPv6 routers,
within scope 1 (interface-local), 2 (link-local), or 5 (site-local).

Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX

Solicited-Node multicast address are computed as a function of a

node's unicast and anycast addresses. A Solicited-Node multicast
address is formed by taking the low-order 24 bits of an 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

FF02:0:0:0:0:1:FF00:0000
to
FF02:0:0:0:0:1:FFFF:FFFF

Anycast (RFC4291)
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.

Special addresses (RFC5156)

Loopback address
The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
It may be used by a node to send an IPv6 packet to itself. It must
not be assigned to any physical interface. It is treated as having
Link-Local scope, and may be thought of as the Link-Local unicast
address of a virtual interface (typically called the "loopback
interface") to an imaginary link that goes nowhere.

The loopback address must not be used as the source address in IPv6
packets that are sent outside of a single node. An IPv6 packet with
a destination address of loopback must never be sent outside of a
single node and must never be forwarded by an IPv6 router. A packet
received on an interface with a destination address of loopback must
be dropped.

Reserved IPv6 addresses

::1/128 is the loopback address [RFC4291].

::/128 is the unspecified address [RFC4291].
These two addresses should not appear on the public Internet.

Unique-Local

fc00::/7 are the unique-local addresses [RFC4193]. Addresses within

 this block should not appear by default on the public Internet.

ULA is not meant to be used same way as IPv4 private addresses (as in
RFC1918) like 192.168/16 prefix together with NAT.

ULA was designed for labs or other resources like internal networks at
remote sites that never need to (or should ever) talk to the Internet

Documentation Prefix
The 2001:db8::/32 are the documentation addresses [RFC3849]. They
are used for documentation purposes such as user manuals, RFCs, etc.
Addresses within this block should not appear on the public Internet.

Default Route
::/0 is the default unicast route address.

Address Auto-configuration

Stateless – SLAAC, DHCPv6 (From RFC4862)

The IPv6 stateless autoconfiguration mechanism requires no manual
configuration of hosts, minimal (if any) configuration of routers,
and no additional servers. The stateless mechanism allows a host to
generate its own addresses using a combination of locally available
information and information advertised by routers. Routers advertise
prefixes that identify the subnet(s) associated with a link, while
hosts generate an "interface identifier" that uniquely identifies an
interface on a subnet. An address is formed by combining the two.
In the absence of routers, a host can only generate link-local
addresses. However, link-local addresses are sufficient for allowing
communication among nodes attached to the same link.

The stateless approach is used when a site is not particularly

concerned with the exact addresses hosts use, so long as they are
unique and properly routable. On the other hand, Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is used when a
site requires tighter control over exact address assignments. Both
stateless address autoconfiguration and DHCPv6 may be used
simultaneously.

Stateful – DHCPv6
DHCP can provide a device with addresses assigned by a DHCP server
and other configuration information, which are carried in options.
DHCP can be extended through the definition of new options to carry
configuration information not specified in this document.

IPv6 routing basics - http://wiki.mikrotik.com/wiki/Manual:IPv6/Route

IPv6 prefix (From RFC3513)

The text representation of IPv6 address prefixes is similar to the

way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An
IPv6 address prefix is represented by the notation:

ipv6-address/prefix-length

ipv6-address is an IPv6 address in any of the notations listed

in section 2.2.

prefix-length is a decimal value specifying how many of the

leftmost contiguous bits of the address comprise
the prefix.

For example, the following are legal representations of the 60-bit

prefix 12AB00000000CD3 (hexadecimal):

12AB:0000:0000:CD30:0000:0000:0000:0000/60
 12AB::CD30:0:0:0:0/60
12AB:0:0:CD30::/60

The following are NOT legal representations of the above prefix:

12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros,

within any 16-bit chunk of the address

12AB::CD30/60 address to left of "/" expands to

12AB:0000:0000:0000:0000:000:0000:CD30

12AB::CD3/60 address to left of "/" expands to

12AB:0000:0000:0000:0000:000:0000:0CD3

When writing both a node address and a prefix of that node address
(e.g., the node's subnet prefix), the two can combined as follows:

the node address 12AB:0:0:CD30:123:4567:89AB:CDEF

and its subnet number 12AB:0:0:CD30::/60

can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60

---
IPv6 header (From RFC2460)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version 4-bit Internet Protocol version number = 6.

Traffic Class 8-bit traffic class field. See section 7.

Flow Label 20-bit flow label. See section 6.

Payload Length 16-bit unsigned integer. Length of the IPv6

payload, i.e., the rest of the packet following
this IPv6 header, in octets. (Note that any
extension headers [section 4] present are
considered part of the payload, i.e., included
in the length count.)

Next Header 8-bit selector. Identifies the type of header

immediately following the IPv6 header. Uses the
same values as the IPv4 Protocol field [RFC-1700
et seq.].

Hop Limit 8-bit unsigned integer. Decremented by 1 by

each node that forwards the packet. The packet
is discarded if Hop Limit is decremented to
 zero.

Source Address 128-bit address of the originator of the packet.

See [ADDRARCH].

Destination Address 128-bit address of the intended recipient of the

packet (possibly not the ultimate recipient, if
a Routing header is present). See [ADDRARCH]
and section 4.4.

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. As
illustrated in these examples, an IPv6 packet may carry zero, one, or
more extension headers, each identified by the Next Header field of
the preceding header:

+---------------+------------------------
| IPv6 header | TCP header + data
| |
| Next Header = |
| TCP |
+---------------+------------------------

+---------------+----------------+------------------------
| IPv6 header | Routing header | TCP header + data
| | |
| Next Header = | Next Header = |
| Routing | TCP |
+---------------+----------------+------------------------

+---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data
| Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP |
+---------------+----------------+-----------------+-----------------

With one exception, extension headers are not examined or processed

by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header.
There, normal demultiplexing on the Next Header field of the IPv6
header invokes the module to process the first extension header, or
the upper-layer header if no extension header is present. The
contents and semantics of each extension header determine whether or
not to proceed to the next header. Therefore, extension headers must
be processed strictly in the order they appear in the packet; a
receiver must not, for example, scan through a packet looking for a
particular kind of extension header and process that header prior to
processing all preceding ones.

The exception referred to in the preceding paragraph is the 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. The Hop-by-Hop Options header,
when present, must immediately follow the IPv6 header. Its presence
is indicated by the value zero in the Next Header field of the IPv6
header.

A full implementation of IPv6 includes implementation of the

following extension headers:

Hop-by-Hop Options
Routing (Type 0)
Fragment
 Destination Options
Authentication
Encapsulating Security Payload

The first four are specified in this document; the last two are
specified in [RFC-2402] and [RFC-2406], respectively.

When more than one extension header is used in the same packet, it is
recommended that those headers appear in the following order:

IPv6 header
Hop-by-Hop Options header
Destination Options header (note 1)
Routing header
Fragment header
Authentication header (note 2)
Encapsulating Security Payload header (note 2)
Destination Options header (note 3)
upper-layer header

note 1: 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.

note 2: additional recommendations regarding the relative

order of the Authentication and Encapsulating
Security Payload headers are given in [RFC-2406].

note 3: for options to be processed only by the final

destination of the packet.

The Fragment header is used by an IPv6 source to send a packet larger

than would fit in the path MTU to its destination. (Note: unlike
IPv4, fragmentation in IPv6 is performed only by source nodes, not by
routers along a packet's delivery path -- see section 5.) The
Fragment header is identified by a Next Header value of 44 in the
immediately preceding header

Path MTU discovery (From RFC 1981)

When one IPv6 node has a large amount of data to send to another
node, the data is transmitted in a series of IPv6 packets. It is
usually preferable that these packets be of the largest size that can
successfully traverse the path from the source node to the
destination node. This packet size is referred to as the Path MTU
(PMTU), and it is equal to the minimum link MTU of all the links in a
path. IPv6 defines a standard mechanism for a node to discover the
PMTU of an arbitrary path.

IPv6 nodes SHOULD implement Path MTU Discovery in order to discover

and take advantage of paths with PMTU greater than the IPv6 minimum
link MTU [IPv6-SPEC]. A minimal IPv6 implementation (e.g., in a boot
ROM) may choose to omit implementation of Path MTU Discovery.

ICMPv6
ICMPv6 is an integral part of IPv6, and the base protocol (all the
messages and behavior required by this specification) MUST be fully
implemented by every IPv6 node.

ICMPv6 messages are grouped into two classes: error messages and
informational messages. Error messages are identified as such by a
zero in the high-order bit of their message Type field values. Thus,
error messages have message types from 0 to 127; informational
messages have message types from 128 to 255.
Neighbor discovery protocol (From RFC 4861)

Neighbor Discovery makes use of a number of different addresses

defined in [ADDR-ARCH], including:

all-nodes multicast address

- the link-local scope address to reach all nodes,
FF02::1.

all-routers multicast address

- the link-local scope address to reach all routers,
FF02::2.

Router Solicitation: When an interface becomes enabled, hosts may

send out Router Solicitations that request routers to
generate Router Advertisements immediately rather than
at their next scheduled time.

Hosts send Router Solicitations in order to prompt routers to

generate Router Advertisements quickly

Router Advertisement: Routers advertise their presence together

with various link and Internet parameters either
periodically, or in response to a Router Solicitation
message. Router Advertisements contain prefixes that
are used for determining whether another address shares
the same link (on-link determination) and/or address
configuration, a suggested hop limit value, etc.

Routers can advertise an MTU for hosts to use on the link, ensuring that
all nodes use the same MTU value on links lacking a well-defined MTU.

Neighbor Solicitation: Sent by a node to determine the link-layer

address of a neighbor, or to verify that a neighbor is
still reachable via a cached link-layer address.
Neighbor Solicitations are also used for Duplicate
Address Detection.

Neighbor Advertisement: A response to a Neighbor Solicitation

message. A node may also send unsolicited Neighbor
Advertisements to announce a link-layer address change.

Redirect: Used by routers to inform hosts of a better first hop

for a destination.

Redirects contain the link-layer address of the new first hop;

separate address resolution is not needed upon receiving a redirect.

Routers send Redirect packets to inform a host of a better first-hop node on the
path to a destination. Hosts can be redirected to a better first-hop router but
can also be informed by a redirect that the destination is in fact a neighbor.
The latter is accomplished by setting the ICMP Target Address equal to the ICMP
Destination Address.

Target Address
An IP address that is a better first hop to use for
the ICMP Destination Address. When the target is
the actual endpoint of communication, i.e., the
destination is a neighbor, the Target Address field
MUST contain the same value as the ICMP Destination
Address field. Otherwise, the target is a better
first-hop router and the Target Address MUST be the
router's link-local address so that hosts can
uniquely identify routers.
On multicast-capable links, each router periodically multicasts a
Router Advertisement packet announcing its availability. A host
receives Router Advertisements from all routers, building a list of
default routers. Routers generate Router Advertisements frequently
enough that hosts will learn of their presence within a few minutes,
but not frequently enough to rely on an absence of advertisements to
detect router failure; a separate Neighbor Unreachability Detection
algorithm provides failure detection.

Router Advertisements contain a list of prefixes used for on-link

determination and/or autonomous address configuration; flags
associated with the prefixes specify the intended uses of a
particular prefix. Hosts use the advertised on-link prefixes to
build and maintain a list that is used in deciding when a packet's
destination is on-link or beyond a router. Note that a destination
can be on-link even though it is not covered by any advertised on-
link prefix. In such cases, a router can send a Redirect informing
the sender that the destination is a neighbor.

Router Advertisements (and per-prefix flags) allow routers to inform

hosts how to perform Address Autoconfiguration. For example, routers
can specify whether hosts should use DHCPv6 and/or autonomous
(stateless) address configuration.

Router Advertisement messages also contain Internet parameters such

as the hop limit that hosts should use in outgoing packets and,
optionally, link parameters such as the link MTU. This facilitates
centralized administration of critical parameters that can be set on
routers and automatically propagated to all attached hosts.

Neighbor Unreachability Detection detects the failure of a neighbor

or the failure of the forward path to the neighbor.

Neighbor Unreachability Detection is part of the base, which

significantly improves the robustness of packet delivery in the
presence of failing routers, partially failing or partitioned
links, or nodes that change their link-layer addresses. For
instance, mobile nodes can move off-link without losing any
connectivity due to stale ARP caches.

Unlike ARP, Neighbor Discovery detects half-link failures (using

Neighbor Unreachability Detection) and avoids sending traffic to
neighbors with which two-way connectivity is absent.

The use of link-local addresses to uniquely identify routers (for

Router Advertisement and Redirect messages) makes it possible for
hosts to maintain the router associations in the event of the site
renumbering to use new global prefixes.

M 1-bit "Managed address configuration" flag. When

set, it indicates that addresses are available via
Dynamic Host Configuration Protocol [DHCPv6].

If the M flag is set, the O flag is redundant and

can be ignored because DHCPv6 will return all
available configuration information.

O 1-bit "Other 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.

Note: If neither M nor O flags are set, this indicates that no

information is available via DHCPv6.
MLD (Multicast Listener Discovery) From RFC3810

The Multicast Listener Discovery Protocol (MLD) is used by IPv6

routers to discover the presence of multicast listeners (i.e., nodes
that wish to receive multicast packets) on their directly attached
links, and to discover specifically which multicast addresses are of
interest to those neighboring nodes. Note that a multicast router
may itself be a listener of one or more multicast addresses; in this
case it performs both the "multicast router part" and the "multicast
address listener part" of the protocol, to collect the multicast
listener information needed by its multicast routing protocol on the
one hand, and to inform itself and other neighboring multicast
routers of its listening state on the other hand.

The purpose of MLD is to

enable each multicast router to learn, for each of its directly
attached links, which multicast addresses and which sources have
interested listeners on that link. The information gathered by MLD
is provided to whichever multicast routing protocol is used by the
router, in order to ensure that multicast packets are delivered to
all links where there are listeners interested in such packets.

All multicast routers on the subnet listen to the messages sent by

multicast address listeners, and maintain the same multicast
listening information state, so that they can take over the
querier role, should the present Querier fail. Nevertheless, only
the Querier sends periodical or triggered query messages on the subnet

Temporary addresses (From RFC4941)

Stateless address autoconfiguration [ADDRCONF] defines how an IPv6

node generates addresses without the need for a Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) server. Some types of
network interfaces come with an embedded IEEE Identifier (i.e., a
link-layer MAC address), and in those cases, stateless address
autoconfiguration uses the IEEE identifier to generate a 64-bit
interface identifier [ADDRARCH]. By design, the interface identifier
is likely to be globally unique when generated in this fashion. The
interface identifier is in turn appended to a prefix to form a
128-bit IPv6 address. Note that an IPv6 identifier does not
necessarily have to be 64 bits in length, but the algorithm specified
in this document is targeted towards 64-bit interface identifiers.

Addresses generated using stateless address autoconfiguration

[ADDRCONF] contain an embedded interface identifier, which remains
constant over time. Anytime a fixed identifier is used in multiple
contexts, it becomes possible to correlate seemingly unrelated
activity using this identifier.

The correlation can be performed by

o An attacker who is in the path between the node in question and

the peer(s) to which it is communicating, and who can view the
IPv6 addresses present in the datagrams.

o An attacker who can access the communication logs of the peers

with which the node has communicated.

Since the identifier is embedded within the IPv6 address, which is a

fundamental requirement of communication, it cannot be easily hidden.
This document proposes a solution to this issue by generating
interface identifiers that vary over time.

Note that an attacker, who is on path, may be able to perform

significant correlation based on
 o The payload contents of the packets on the wire

o The characteristics of the packets such as packet size and timing

Use of temporary addresses will not prevent such payload-based

correlation.

IPsec

IPsec is a set of protocols to support secure communication at the IP layer

IPSec tunnel mode is the default mode. With tunnel mode, the entire original IP
packet is protected by IPSec. This means IPSec wraps the original packet,
encrypts it, adds a new IP header and sends it to the other side of the VPN
tunnel (IPSec peer).

IPsec RFC6434 Section 11

Previously, IPv6 mandated implementation of IPsec and recommended the

key management approach of IKE. This document updates that
recommendation by making support of the IPsec Architecture [RFC4301]
a SHOULD for all IPv6 nodes. Note that the IPsec Architecture
requires (e.g., Section 4.5 of RFC 4301) the implementation of both
manual and automatic key management. Currently, the default
automated key management protocol to implement is IKEv2 [RFC5996].

This document recognizes that there exists a range of device types

and environments where approaches to security other than IPsec can be
justified. For example, special-purpose devices may support only a
very limited number or type of applications, and an application-
specific security approach may be sufficient for limited management
or configuration capabilities. Alternatively, some devices may run
on extremely constrained hardware (e.g., sensors) where the full
IPsec Architecture is not justified.

SHOULD - This word, or the adjective "RECOMMENDED", mean that there may exist
valid reasons in particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before choosing a
different course.

Transition Mechanisms

The key to a successful IPv6 transition is compatibility with the

large installed base of IPv4 hosts and routers. Maintaining
compatibility with IPv4 while deploying IPv6 will streamline the task
of transitioning the Internet to IPv6.

Dual IP layer (also known as dual stack): A technique for

providing complete support for both Internet protocols -- IPv4 and
IPv6 -- in hosts and routers.

6to4 (From RFC3056)

The document defines a method for assigning an interim unique IPv6

address prefix to any site that currently has at least one globally
unique IPv4 address, and specifies an encapsulation mechanism for
transmitting IPv6 packets using such a prefix over the global IPv4
network. It also describes scenarios for using such prefixes during
the co-existence phase of IPv4 to IPv6 transition. Note that these
scenarios are only part of the total picture of transition to IPv6.
Also note that this is considered to be an interim solution and that
sites should migrate when possible to native IPv6 prefixes and native
IPv6 connectivity. This will be possible as soon as the site's ISP
offers native IPv6 connectivity.

6to4 example on RouterOS:

wiki.mikrotik.com/wiki/Manual:Hurricane_Electric_Tunnel_Broker_Example_for_Home
6RD (From RFC5569)

IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon

mechanisms of 6to4 to enable a service provider to rapidly deploy
IPv6 unicast service to IPv4 sites to which it provides customer
premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4
encapsulation in order to transit IPv4-only network infrastructure.
Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in
place of the fixed 6to4 prefix.

The principle of 6rd is that, to build on 6to4 and suppress its

limitation, it is sufficient that:

1. 6to4 functions are modified to replace the standard 6to4 prefix

2002::/16 by an IPv6 prefix that belongs to the ISP-assigned
address space, and to replace the 6to4 anycast address by another
anycast address chosen by the ISP.

2. The ISP operates one or several 6rd gateways (upgraded 6to4

routers) at its border between its IPv4 infrastructure and the
IPv6 Internet.

3. CPEs support IPv6 on their customer-site side and support 6rd

(upgraded 6to4 function) on their provider side.

Teredo (From RFC4380)

Teredo is meant as a short-term solution to the specific problem of

providing IPv6 service to nodes located behind a NAT. The problem is
expected to be resolved over time by transforming the "IPv4 NAT" into
an "IPv6 router". This can be done in one of two ways: upgrading
the NAT to provide 6to4 functions or upgrading the Internet
connection used by the NAT to a native IPv6 service, and then adding
IPv6 router functionality in the NAT. In either case, the former NAT
can present itself as an IPv6 router to the systems behind it. These
systems will start receiving the "router advertisements"; they will
notice that they have IPv6 connectivity and will stop using Teredo.

DS-lite (Dual stack lite)

Dual-Stack Lite enables a broadband service provider to share IPv4

addresses among customers by combining two well-known technologies:
IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT).

This technology decouples the deployment of IPv6 in the service

provider network (up to the customer premise equipment or CPE)
from the deployment of IPv6 in the global Internet and in customer
applications and devices.
---
DHCP PD server (From RFC3633)

The Prefix Delegation options provide a mechanism for automated

delegation of IPv6 prefixes using the Dynamic Host Configuration
Protocol (DHCP). This mechanism is intended for delegating a long-
lived prefix from a delegating router to a requesting router, across
an administrative boundary, where the delegating router does not
require knowledge about the topology of the links in the network to
which the prefixes will be assigned.

A delegating router is provided IPv6 prefixes to be delegated to

requesting routers. Examples of ways in which the delegating router
may be provided these prefixes are given in Section 12.2. A
requesting router requests prefix(es) from the delegating router, as
described in Section 12.1. The delegating router chooses prefix(es)
for delegation, and responds with prefix(es) to the requesting
router. The requesting router is then responsible for the delegated
 prefix(es). For example, the requesting router might assign a subnet
from a delegated prefix to one of its interfaces, and begin sending
router advertisements for the prefix on that link.

Each prefix has an associated valid and preferred lifetime, which

constitutes an agreement about the length of time over which the
requesting router is allowed to use the prefix. A requesting router
can request an extension of the lifetimes on a delegated prefix and
is required to terminate the use of a delegated prefix if the valid
lifetime of the prefix expires.

This prefix delegation mechanism would be appropriate for use by an

ISP to delegate a prefix to a subscriber, where the delegated prefix
would possibly be subnetted and assigned to the links within the
subscriber's network.

IPv6 tunnels

IPIPv6 - http://wiki.mikrotik.com/wiki/Manual:Interface/IPIP
EoIPv6 - http://wiki.mikrotik.com/wiki/Manual:Interface/EoIP
GRE6 - http://wiki.mikrotik.com/wiki/Manual:Interface/Gre6

Reverse DNS (From RFC3596)

A special domain is defined to look up a record given an IPv6

address. The intent of this domain is to provide a way of mapping an
IPv6 address to a host name, although it may be used for other
purposes as well. The domain is rooted at IP6.ARPA.

An IPv6 address is represented as a name in the IP6.ARPA domain by a

sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
The sequence of nibbles is encoded in reverse order, i.e., the
low-order nibble is encoded first, followed by the next low-order
nibble and so on. Each nibble is represented by a hexadecimal digit.
For example, the reverse lookup domain name corresponding to the
address

4321:0:1:2:3:4:567:89ab

would be

b.a.9.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.

Using link-local addresses as in IPv6 (From RFC7404)

An infrastructure link between a set of routers typically does not

require global or unique local addresses [RFC4193]. Using only link-
local addressing on such links has a number of advantages; for
example, routing tables do not need to carry link addressing and can
therefore be significantly smaller. This helps to decrease failover
times in certain routing convergence events. An interface of a
router is also not reachable beyond the link boundaries, therefore
reducing the attack surface.

In this approach, neither globally routed IPv6 addresses nor unique

local addresses are configured on infrastructure links. In the
absence of specific global or unique local address definitions, the
default behavior of routers is to use link-local addresses, notably
for routing protocols.

The sending of ICMPv6 [RFC4443] error messages ("packet-too-big",

"time-exceeded", etc.) is required for routers. Therefore, another
interface must be configured with an IPv6 address that has a greater
scope than link-local. This address will usually be a loopback
interface with a global scope address belonging to the operator and
part of an announced prefix (with a suitable prefix length) to avoid
being dropped by other routers implementing ingress filtering
[RFC3704]. This is implementation dependent. For the remainder of
this document, we will refer to this interface as a "loopback
interface".