Ipv6 course

Oct 19, 2015 Roberto Innocente inno@sissa.it 1
ipv6
● History and motivations
● Introduction to ipv6 : addressing and prefixes
● Proposal for gradual deployment
● Transition technologies: tunnels (6to4, teredo)
● Multicast, Control protocols : ICMPv6 ( ND, RD)
● Booting (SLAAC/DHCPv6), naming (DNSv6,
mDNS)
● Routing : RIPng, OSPFv3, IS-IS, BGP4+

IPv6 history
● Well , probably all of you know that since the '90 the Internet governing bodies thought about a
technical way out from the foreseeable moment of IPv4 address consumption.
● First named IPng and then IPv6 a new protocol was finalized between '94 and 2000.
● The main feature of it was ( impressive at that time) the increase of the address size from 32
bits(up to 2^32 ~ 10^10 addresses) to 128 bits (4 times more bits up to 2^128 ~ 10^40
addresses). Explanation for physicists : 30 orders of magnitude more, Millions of Avogadro's
number IPv4 address spaces ( sic! )
● Don't be astonished. Many think that if it would be developed now the address would be at least
256 bits.
● In fact there was before IPv6 an ISO protocol that to be smart implemented variable length
addresses (up to 20 bytes, 160 bits) ISO 8473/1998 CLNP (Connectionless Network Protocol
RFC1162). Their supporters proposed to solve the IPv4 problem by the substitution of IP by
CLNP with a solution called TUBA (TCP and UDP with Bigger Addresses RFC1437)
● The NSFNET backbone in US and some GARR parts( bologna – trieste) supported CLNP for
some time from 1990 to 1993. The nsfnet together with ip, ts-bo encapsulating ip in clnp (“routing
pass like ships in the night”).
● Soon it was realized that Variable Length Addresses were a really bad idea from the point of view
of routing and switching efficiency. This was of course also giving variable offsets to options : a
nightmare for hardware switching.

CLNP address
Variable Length Address till 20 bytes, for TUBA 20 bytes

Why ? Why now ?
The IPv4 address prefixes are finished at IANA (Internet Assigned Numbers
Authority) and at ARIN (Canada, USA registry ) some remain in the hands of ISPs.
Therefore soon some islands of IPv6 only will appear and it will be necessary to
speak IPv6 to reach them.
The vision that is behind the Internet Of Things (IOT) is pushing hard to have an IP
address for everything :
● Washing machines, dish-washers, fridges, ovens .. smartphones, TV top boxes, ..
Mobile 4G (LTE) provides voice as the service Voice over IP.
In the orig 3GPP spec it was only requested to be available and IPv4 optional, but
most operators now use IPv6 for this.
There is another difficult problem that afflicts today IPv4 Internet at large: the
routing prefix explosion (now routers in the Default Free Zone have over 500.000
prefixes). With IPv6 there is the hope to aggregate prefixes by LIR/ISP , RIRs.
Last but not least IPv6 will give to people now constrained behind a NAT, End-to-
End Transparency (some nonetheless consider this a threat ) : RFC2775 Internet
Transparency, RFC4924 Reflexions on Internet Transparency.

We want to avoid the chaos :
Dagen H (hå), 5 am. Stockholm 1967
when traffic switched from left to right
Benjamin Edelman,
Running out of numbers
http://www.benedelman.org/publications/runningout-draft.pdf

Ipv4 address exhaustion

Routing explosion
IPv6 prefixes announced over the DFZIPv4 prefix explosion : prefixes announced
over the Default-Free Zone DFZ
From apnic.net
NB. Instabilities on DFZ routing due to reaching the 512K prefix limit of some routers
RFC4984 “routing scalability is the most important problem facing the Internet today and must be
solved”

End-to-End transparency
RFC4924
It is not often cited as a
motive for the adoption of
IPv6, but the new protocol
will give back to the current
Internet and the
forthcoming Internet of
Things (IOT) end-to-end
transparency.
This at the same time is a
threat for some and an
essential tool for others.
“Two ports Internet”
Today Internet is filtered
and NATted everywhere,
except for the web ports.
Therefore whoever today is
developing new things
doesn't care to use new
ports and register them, but
uses exclusively :
● Port 80 http
● Port 443 https

Ipv6 adoption
Amsterdam traffic Exchange
amsix ipv6 traffic :
Adoption by operator(percentage of
requests to akamai servers made over IPv6):

Distribution
of
addresses
Min
Allocated
To LIR /32
Minimum Allocated
To EndUsers /64
Universities usually
/48
eg RIPE
eg GARR
eg SISSA
IANA
RIR RIR
NIR
ISP/LIRISP/LIR
EU EU EU End Users
Local Internet
Registries
(LIR,ISP..)
National Internet
Registries
(APNIC region)
Regional Internet
Registries
(ARIN,RIPE,APNIC..)

RIR - Regional Internet Registers
Pic from IANA

PI (Provider Independent)
PA (Provider Assigned) prefixes
There have been lots of discussion about ipv6 addresses deployment. 3 methods were
proposed :
● PA provider assigned or aggregatable : specified in the RFC's, usually
universities in italy got their ipv6 /48 prefix from GARR. These addresses will stay
with provider and if you change provider you have to change addresses.
● PI provider independent : these addresses will be announced independently over
the whole Internet and will stay with you. Registries are now providing also these
● Geographically
In 2009 RIPE accepted a policy proposal on this topic :
● RIPE will assign directly to organization PI prefixes that should be at least /48 or /32.
The request can be addressed directly to RIPE or trough a sponsoring LIR
● This will make possible for an organization to move to another provider without
renumbering
● On the other side this poses a burden on global routing because it blocks the
possibility of an efficient route aggregation.

Sparsest address allocation using
bit-reversal permutation
How to assign from a finite
number of ordered adjacent
boxes in the sparsest way ?
Such that you leave the max free
space among the occupied
boxes ? ( RFC3531 sparse
allocation)
Using as you can see on the
right a bit-reversal involution
( involution f(f(x)) = x ). It is one
of the damn parts of the FFT
algorithm especially for its
trashing effects on the cache.
001 → 100 = 4
010 → 010 = 2
011 → 110 = 6
100 → 001 = 1
101 → 101 = 5
110 → 011 = 3
It is used for address allocation by registries to permit to give new allocations
adjacent to the old ones given to the same requestor.
000 → 000 = 0
1 2 3 4 5 6 70

IPv6 address textual representation
● IPv4 address textual representation is the well known quad decimal dotted
representation : 147.122.24.71 a decimal number (0-255) for each byte of the address,
separated by dots. The address representation becomes from 7 to 15 characters.
● In IPv6 this is not possible because with 128 bits(16 bytes) the length would be from 31
to 63 characters.
● It was chosen to use half of the punctuation (one colon every 4 hex digits: 2 bytes) and
to use 2 hex digits to represent a byte. Still the representation is long : from 15 to 39
characters. You can compress it omitting leading zeroes in each quad hex, replacing at
most once multiple 0 quadhexes with :: .
● Curiosity : trying to obtain a compact representation someone proposed a base85
representation (there are 94 ASCII characters utilizable for the representation, in
base84, 21 chars would be required, in base85 to 94 only 20 characters because 8520
> 2128 ! ) RFC1924 (A compact representation of IPv6 addresses)
Eg. 1080:0:0:0:8:800:200C:417A
In decimal : 21932261930451111902915077091070067066
Remainders dividing by 85 : 51, 34, 65, 57, 58, 0, 75, 53, 37, 4, 19, 61, 31, 63, 12, 66, 46, 70, 68, 4
Therefore in base 85 it is : 4-68-70-46-66-12-63-31-61-19-4-37-53-75-0-58-57-65-34-51
That becomes : 4)+k&C#VzJ4br>0wv%Yp

IPv6 address representation :
compressed quadhex
128 bits :
1111110100000000000000000000000000000000000000110000000000000010
0000000000000000000000000000000000000000000000000000000000000001
32 hex digits:
FD000000000300020000000000000001
8 quadhex colon separated :
FD00:0000:0003:0002:0000:0000:0000:0001
FD00:0:3:2:0:0:0:1
FD00:0:3:2::1
Replace every nibble (4
bits) with an hex digit
Take the left most
sequence of multiple 0s
quad-hexes and replace
it with a double colon ::
In each quad-hex
cancel leading 0s
Every 4 hex digits insert
a colon

IPv6 prefix text representation
RFC4291 Text Representation of Address Prefixes
The text representation of IPv6 address prefixes is similar to the way IPv4 address prefixes are
written in Classless Inter-Domain Routing (CIDR) notation [CIDR]. An IPv6 address prefix is
represented by the notation:
ipv6-address/prefix-length
where
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 20010DB80000CD3
(hexadecimal):
2001:0DB8:0000:CD30:0000:0000:0000:0000/60
2001:0DB8::CD30:0:0:0:0/60
2001:0DB8:0:CD30::/60
The following are NOT legal representations of the above prefix:
2001:0DB8:0:CD3/60 may drop leading zeros, but not trailing
zeros, within any 16-bit chunk of the address
2001:0DB8::CD30/60 address to left of "/" expands to
2001:0DB8:0000:0000:0000:0000:0000:CD30
2001:0DB8::CD3/60 address to left of "/" expands to
2001:0DB8:0000:0000:0000:0000:0000:0CD3

IPv6 Variable Length Prefix
● Full address : 128 bits
● Global prefix : n bits , Subnet ID : m bits
● Interface ID : (128 – n - m) bits
But .. many following specs require intID at 64 bits
Subnet ID Interface ID
128 bits
Global prefix
n bits m bits 128 – n - m bits
1st
three bits have special meaning :
000 no constraint on IID
001 currently assigned global unicast prefixes
….. unassigned
111 multicast etc.
It should be clear from this that
most of the space remains
unallocated :
5/8 of it is unallocated

Practical IPv6
Global Unicast Address Indicator
Region(AFRINIC,RIPE,..)
LIR or ISP
Customer
Subnet
2 001: 0db8: 4321: 012a: 0219:99ff:fe79:ff02
64 bits mEUI-64
Derived from MAC
RFC4291 : For all unicast addresses,
except those that start with the
binary value 000, Interface IDs are
required to be 64 bits long and to be
constructed in Modified EUI-64 format.
But see RFC7136 (2014) that updates
this with other common formats.

Put out of your mind ..
the idea that one of the things to know for a
subnet plan is the possible number of hosts !!
e.g. We were used to think that if maybe 300/400
hosts would at the end populate a subnet then we
had to give to this subnet a /22 subnet address
and a coupled netmask of 255.255.252.0.
Using 8 bytes for the interface identifier there
will never be problems with this part of the
address : it allows 264 ~ 1020 different hosts !

Ipv6 address types
IPv6 addresses types
– Unicast, single interface on single node. Pkt sent to it is delivered to that interface.
● Global Unicast 2000::/3
● Link Local fe80::/10
● Loopback ::1/128
● Unspecified ::/128
● Unique Local fc00::/7
● Embedded Ipv4 ::/80 (deprecated)
● Compatible Ipv4 ::fff0:x.y.z.w/96
– Multicast: multitude of interfaces on a multitude of nodes. Pkt sent to it is sent to all these
interfaces.
● Assigned ff00::/8
● Solicited Node ff02::1:ff00:0000/104
– Anycast : a set of interfaces usually on different nodes. Pkt sent to it is sent only to the nearest
interface with that address.
● Any Unicast can be used as anycast
● Reserved : Subnet-router anycast

IPv6 scoped addresses/1
Interface local : ::1/128
scope
Global scope : 2000::/3
Link-Local : fe80::/10
scope
Site-local : fec0::/10
deprecated by rfc3879
Unique-LocalAddress(ULA)
: fd00::/8
replaces site-local.
In RFC4193 ,ULA globalID is a
generated pseudorandom
number, subnetID is assigned
administratevely, L=1 making
prefix fd00::/8.
fe80 0 Interface ID
1111 1110 10
fe80::/10
1111 110 L global ID subnet ID Interface ID
1 locally assigned
0 globally assigned
7 bits 1 40bits 16bits 64bits
Link-local address LLA
fe80::/10
Unique Local Address ULA
fd00::/8
RFC4007 IPv6 Scoped address
10 bits 54 bits 64 bits
x

IPv6 scoped addresses/2
Interface local scope
Link-Local scope
Site-local
Unique-Local-Address(ULA)
Global scope
x
::1/128
fec0::/10
fd00::/8
2000::/3
fe80::/10

IPv6 address scopes
or simply zones
● The address tells you the scope : interface, link-local, site-local, global:
– ::1/128, fe80::/64, fd00::/8,2000::/3
● A zone is a concrete instance of a scope.
● fe80::2 tells you the scope : Link Local, but not the zone.
● 2100:760::2 tells you the scope : Global, and the zone : Internet.
● Zone : a connected region of a given scope.
● Global scope has only 1 zone : all Internet
● There are as many Link-local zones as links
When an app needs to communicate with lower layers about a link-local address, it has to
communicate a zone identifier (on linux an interface name or index on windows an interface
index), this zone identifier has only local meaning.
RFC4007 prescribes to use the percent % sign to add the zone to the address :
fe80::1%eth0 fe80::2%4
● In linux fe80::2%eth0 tells you the scope link-local and the zone : eth0 of the node.
In windows use: netsh interface ipv6 show interface
Also ipconfig shows zoneid of linklocal addresses.
In linux use : ip -6 link
RFC4007 Ipv6 Scoped address

Ipv6 anycast - RFC3513
● Anycast are explicitly contemplated by IPv6.
● An anycast address is taken from the unicast addresses and assigned to multiple
interfaces (RFC4921), it has the same scope as the unicast family from which is taken.
The node to which an anycast is assigned should be explicitly configured to recognize
the address.
● The routing infrastructure, that should be aware of it, will deliver a packet having as
destination an anycast address to the nearest of the instances of that address.
● Usage examples :
– TLD anycast dns servers
– Reserve Subnet-router anycast address (RFC4291)
– 6to4 relay anycast address RFC3068
This is accomplished trough the propagation of host routes for the anycasts in all the
parts of the network that can't summarize the anycast with a route prefix.
There is a longest prefix P that is common to the region of all these interfaces … in the
worst case this prefix P can be null and the region be then the whole Internet.
In this case the host route should be maintained over all Internet.

128 – n Bitsn bits
Required anycast :
Subnet-Router anycast
From rfc4291, required. It is
built from prefix of a subnet
zeroing remaining bits. All
routers attached to a subnet
need to listen to this anycast
that is used to communicate
with the nearest router.
NB. use of /127 prefix on pt to pt links
was discouraged (rfc3627) and
deprecated because of conflict with
special use addresses like this. Look
RFC6164 for a discussion about it, but is
still recommended to use /64 for pt-to-pt
links even if this raises security issues
(ping pong issue on SDN that don't use
ND). /126 is recommended by rfc3627
so that the 2 interfaces don't need to
use the 0 suffix (reserved for subnet
router anycast)
Subnet Prefix 000...000

IPv6 addresses
Multicast AnycastUnicastUnicast
Unique Local
fc00::/7
Assigned
ff00::/8
Global Unicast
2000::/3
Link Local
fe80::/10
Loopback
::1/128
Embedded IPv4
::/80
Unspecified address
::/0
Assigned
unicast
Subnet
Anycast
Subnet::0
Solicited node
ff02::1:ff00:0:0/104

Ipv4-ipv6 correspondence
IPv4 IPv6
Multicast address(224.0.0.0/4) Multicast address (ff00::/8)
Loopback (127.0.0.1) Loopback (::1)
Unspecified address (0.0.0.0) Unspecified address (::)
Broadcast address Not applicable in IPv6
Public Ipv4 address Global Unicast Address (2000::/3)
Private IP address(10.0.0.0/8,
172.16.0.0/12,192.168.0.0/16)
Unique Local Address (fd00::/8)
APIPA address(169.254.0.0/16)
Automatic Private IP addressing
Link Local address (fe80::/64)

IPv6
prefixes
assigned
by
IANA
● 2001:0000::/23 IANA
● 2001:0200::/23 APNIC 1999-07-01 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
● 2001:0400::/23 ARIN 1999-07-01 whois.arin.net https://rdap.arin.net/registry
●
2001:0600::/23 RIPE NCC 1999-07-01 whois.ripe.net https://rdap.db.ripe.net/ ALLOCATED
● 2001:0800::/23 RIPE NCC 2002-05-02 whois.ripe.net https://rdap.db.ripe.net/ ALLOCATED
● 2001:0a00::/23 RIPE NCC 2002-11-02 whois.ripe.net https://rdap.db.ripe.net/ ALLOCATED
● 2001:0c00::/23 APNIC 2002-05-02 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
●
2001:0e00::/23 APNIC 2003-01-01 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
● 2001:1200::/23 LACNIC 2002-11-01 whois.lacnic.net https://rdap.lacnic.net/rdap/ ALLOCATED
●
2001:1a00::/23 RIPE NCC 2004-01-01 whois.ripe.net https://rdap.db.ripe.net/ ALLOCATED
● 2001:1c00::/22 RIPE NCC 2004-05-04 whois.ripe.net https://rdap.db.ripe.net/ ALLOCATED
●
● 2001:4200::/23 AFRINIC 2004-06-01 whois.afrinic.net https://rdap.afrinic.net/rdap/
● 2001:4400::/23 APNIC 2004-06-11 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
●
● 2001:4a00::/23 RIPE NCC 2004-10-15 whois.ripe.net https://rdap.db.ripe.net/ ALLOCATED
● 2001:4c00::/23 RIPE NCC 2004-12-17 whois.ripe.net https://rdap.db.ripe.net/ ALLOCATED
●
2001:8000::/19 APNIC 2004-11-30 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
● 2001:a000::/20 APNIC 2004-11-30 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
● 2001:b000::/20 APNIC 2006-03-08 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
●
2400:0000::/12 APNIC 2006-10-03 whois.apnic.net https://rdap.apnic.net/ ALLOCATED
● 2600:0000::/12 ARIN 2006-10-03 whois.arin.net https://rdap.arin.net/registry.
● 2a00:0000::/12 RIPE NCC 2006-10-03 whois.ripe.net https://rdap.db.ripe.net/ ALLOCATED
● 2c00:0000::/12 AFRINIC 2006-10-03 whois.afrinic.net https://rdap.afrinic.net/rdap
●
●
●

RIPE prefixes
Prefix obtained Will be given away with nets of prefix ...
2001:600::/23 /64 /48
2001:800::/23 /32
2001:a00::/23 /32
2001:1400::/23 /32
2001:1600::/23 /32
2001:1a00::/23 /32
2001:1c00::/22 /32
2001:2000::/20 /32
2001:3000::/21 /32
2001:3800::/22 /32
2001:4000::/23 /32
2001:4600::/23 /32
2001:4a00::/23 /32
2001:4c00::/23 /32
2001:5000::/20 /32
2003::/18 /32
2a00::/12 /32

GARR IPv6 assignements
● /40 for each POP eg :
– 2001:760:0::/40 POP Roma
– 2001:760:200::/40 POP Bologna
● Backbone links and networks use 2001:760:ffff::/48 addresses
– /64 for each router from the /56 of principal POP eg:
● ts.garr.net 2001:760:ffff:1200::/56
● router 2001:760:1200::/64
– /48 for each customer of the /40 of the POP :
Pop trieste 2001:760:2800::/40
Uni Pavia 2001:760:2000::/48
– /128 for loopback interfaces
– /127 for point to point links
● Naming :
– Loopback interface : pop_name.6net.garr.net
●

Country Prefixes ASNs
1.UnitedStates 9,261 2,385
2.Brazil 1,984 893
3.Germany 1,346 735
4.United King 1,195 530
5.Russian Feder 872 604
6.Netherlands 869 391
7.Australia 854 282
Top IPv6 prefix announcements
Country Prefixes ASNs
8. India 844 167
9.Singapore 700 125
10.Canada 582 266
11.France 567 307
12.Italy 563 160
13.Austria 496 208
14.Sweden 490 249

● ARIN 2001:0400::/23
● Columbia 2001:0468:0904::/48
● University of Nebraska 2607:f320::/32
● LuisianaUniversity 2620:105:B000::/40
● Internet2 2001:468::/16
● TIM 2a03:8980::/32
● Wind Italia 2a02:b000::/23
● MessageNet 2a01:9300::/32
● SeeWeb 2001:4b78::/29
● GARR LIR 2001:760::/32
– Caspur 2001:760:2::/48
– Roma Tre 2001:760:4::/48
– Univ.Bologna 2001:760:202::/48
– PoliTo 2001:760:400::/48
– Universita' di trieste 2001:760:2e03::/48
Some prefixes
● Vodafone italia 2a01:820::/32
2a01:827::/32
2a01:8d0::/32
● Telecomitalia 2a01:2000::/20
● CNR 2a00:1620::/32

Ipv6 special addresses
Prefix Length Description
2001:db8:: /32 Addresses to be used for
Documentation
2001:: /32 Teredo
2002:: /16 6to4
5f00:: /8 6bone
3ffe:: /16 6bone
fc00:: /7 Unique Local Address ULA
fe80:: /16 Link Local unicast addresses
::1 /128 Loopback

Improper / Martian IPv6 routes
These are routes that some governing body has declared reserved
for special purposes and that should not be globally routed on the
IPv6 internet.
Prefix
::/0 Unspecified address, default
::/96 Unspecified address, IPv4 compatible
::/128 Unspecified address
::1/128 Loopback address
::224.0.0.0/100 Compatible ipv4 multicast
::127.0.0.0/104 Compatible ipv4 loopback
::0.0.0.0/104 Ipv4 compatbile default
::255.0.0.0/104 Ipv4 comp. broadcast
0000::/8 Pool used for unspec and embedded addr
0200::/7 OSI NSAP deprecated
3ffe::/16 Former 6bone decommissioned
2001:db8::/32 Reserved IANA for doc
Prefix
2002:e000::/20 Invalid 6to4
2002:7f00::/24 Invalid 6to4
2002:0a00::/24 Invalid 6to4
2002:ac10::/28 Invalid 6to4
2002:c0a8::/32 Ipv4 compatible default
fc00::/7 Unicast Unique local address
rfc4193
fe80::/10 Link local addresses
fec0::/10 Site local unicast addresses
ff00::/8 Multicast range

Bogon routes
Probably you know
already the meaning of
the word : in hacker's
jargon it is the quantum
of bogosity (the property
of being bogus : fake).
They are net prefixes
not yet allocated by
IANA and that therefore
should never be
announced.
# last updated 1443512101
(Tue Sep 29 07:35:01 2015
GMT)
::/8
100::/8
200::/7
400::/6
800::/5
1000::/4
2000::/16
2001:201::/32
2001:202::/31
2001:204::/30
2001:209::/32
2001:20a::/31
2001:20c::/30
2001:210:2000::/35
2001:210:4000::/34
2001:210:8000::/33
2001:211::/32
2001:212::/31
2001:214::/30
2001:219::/32
2001:21a::/31
2001:21c::/30
2001:221::/32
2001:222::/31
2001:224::/30
2001:228:2000::/35
2001:228:4000::/34
2001:228:8000::/33
2001:229::/32
2001:22a::/31
2001:22c::/30
2001:231::/32
2001:232::/31
2001:234::/30
2001:239::/32
2001:23a::/31
2001:23c::/30
2001:241::/32
2001:242::/31
2001:244::/30
2001:248:2000::/35
2001:248:4000::/34
2001:248:8000::/33
.
2001:249::/32
2001:24a::/31
2001:24c::/30
2001:253::/32
2001:255::/32
2001:257::/32
2001:259::/32
2001:25a::/31
2001:25c::/30
2001:261::/32
2001:262::/31
2001:264::/30
2001:269::/32
2001:26a::/31
2001:26c::/30
2001:271::/32
2001:272::/31
2001:274::/30
2001:279::/32
2001:27a::/31
2001:27c::/30
2001:281::/32
2001:282::/31
2001:284::/30
2001:289::/32
2001:28a::/31
2001:28c::/30
2001:291::/32
2001:292::/31
2001:294::/30
2001:299::/32
2001:29a::/31
2001:29c::/30
2001:2a1::/32
2001:2a2::/31
2001:2a4::/30
2001:2a9::/32
2001:2aa::/31
2001:2ac::/30
2001:2b1::/32
2001:2b2::/31
2001:2b4::/30
2001:2b9::/32
2001:2ba::/31
2001:2bc::/30
2001:2c1::/32
2001:2c2::/31
2001:2c4::/30
2001:2c9::/32
2001:2ca::/31
2001:2cc::/30
.
.
.
.
.
2001:2d0:2000::/35
2001:2d0:4000::/34
2001:2d0:8000::/33
2001:2d1::/32
2001:2d2::/31
2001:2d4::/30
2001:2d9::/32
2001:2da::/31
2001:2dc::/30
2001:2e1::/32
2001:2e2::/31
2001:2e4::/30
2001:2e9::/32
2001:2ea::/31
2001:2ec::/30
2001:2f1::/32
2001:2f2::/31
2001:2f4::/30
2001:2f9::/32
2001:2fa::/31
2001:2fc::/30
2001:301::/32
2001:302::/31
2001:304::/30
2001:309::/32
2001:30a::/31
2001:30c::/30
2001:311::/32
2001:312::/31
2001:314::/30
2001:319::/32
2001:31a::/31
2001:31c::/30
2001:321::/32
2001:322::/31
2001:324::/30
2001:329::/32
2001:32a::/31
2001:32c::/30
2001:331::/32
2001:332::/31
2001:334::/30
2001:339::/32
2001:33a::/31
2001:33c::/30
2001:341::/32
2001:342::/31
2001:344::/30
2001:349::/32
2001:34a::/31
2001:34c::/30
.
.
.
.
.
.
.
.
.
.
( available at http://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt )

Measuring IPv6 address
consumption RFC3194
HD=
log(NumberOfAllocatedObjects)
log(NumberOfAllocatableObjects)
To recognize the reason for an allocation
larger than a /56 often is required to have a
75% HD :
Eg. out of the 256 subnets you can have you
should already have 64 :
HD = log2(64)/log2(256)=6/8= 0.75
eg. if you are given a 48 with a 2^16 subnet
space , your HD will require new allocation
when you have allocated 2^12=4096
subnets :
HD = log2(4096)/log2(65536)=12/16=0.75
HD(US 10 digits telephone) = log(10^8) /
log(10^10) = 0.8 = 80%
HD(SPAN/HEPNET decnet IV ) = log(15000) /
log(2^16) =0.867 = 86.7 % !!!!!!!!!!!!
A measure often employed in
measuring IPv6 address
consumption is Durand-Huitema
Host Density :
HD is a real number between 0 and
1, often expressed as a percentage
0% to 100%. Using log2
or log10
or ln
is indifferent cause :
log10
(x) =log2
(x)*log10
(2)
From experience : 80% is
reasonable, 85% painful, 86% very
painful, 87% maximum.

Using HD to plan an IPv6 net
2 levels : Sites, vlans
Sites < 8 = 2^3 => all at least 2^4 = 1 hex
HD=0.75
Vlans < 256= 2^8 => all at least 2^11 = 3 hex
HD=0.66
● 2001:760:xxxx::/48 assigned
● 2001:760:xxxx:y000::/52 sites
● 2001:760:xxxx:yzzz::/64 vlans
2
3

48 bits of Site Prefix
IPv6 has variable mask lengths and so there is no
predetermined division between subnets like in CIDR IPv4.
● 3 bits assigned by IETF : 2000::/3 to mean global
unicast
● 9 bits assigned by IANA : e.g. 2620::/12 assigned to the
RIR ARIN, 2a00::/12 to RIPE(12 bits are 3 hex digits)
● 12-20 RIR
● 16-24 RIR or ISP
● Universities are often assigned a /48 prefix, leaving
them a 16 bits subnet field to be used for the internal
topology
12+24 = 36 bits
20+16 = 36 bits

Gradual deployment. How ?
● First : it will be given to the IT personnel the
possibility to browse IPv6 trough a tunnel to
create appropriate skills
● Second : an IPv6 island will be configured on
the router interface for the IT personnel vlan or
the DMZ
● Third : it will be configured on all routers and
switches and given to the users

Transition technologies
Tunnels (poor men IPv6) :
● 6to4 doesn't work behind our fw,
encapsulates IPv6 pkt in IPv4 pkt using IPv6-in-
IPv4 protocol type
● ISATAP
● Teredo encapsulates Ipv6 in IPv4 UDP
● ...

Teredo tunnel
Ipv6
Internet
IPv4
Internet
IPv4 Teredo server
Miredo...mucip.net
Ipv4 UDP
3545
Ipv4 UDP
3544
Ipv4/ipv6
Teredo Relay
…. .he.net
Ipv6 only
host
Ipv6
Ipv6
Teredo Client
Ipv6/ipv4
IPv4 UDP

Teredo address and data packets
Teredo prefix
2001 : 0000
Teredo Server IPv4
address
Obscured
External Address
Flags Obscured
External Port
32 bits 32 bits 16bits 16bits 32 bits
2001:0::/32 83.170.6.76
RFC4380 teredo.remlab.net
IPv4 header UDP header IPv6 payload
IPv6 header
Client address :
Data Packet :
Client address :
Teredo bubble Packet : Data packet with an IPv6 packet without payload.
Sent regularly to keep warm the connection (usually the NAT association).

Teredo generated traffic
root@geist:~# tcpdump port 3544 or port 3545
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:49:13.679161 IP geist.local.3545 > miredo.svr01.mucip.net.3544: UDP, length 61
12:49:13.701575 IP miredo.svr01.mucip.net.3544 > geist.local.3545: UDP, length 117
12:49:13.727435 IP geist.local.3545 > miredo.svr01.mucip.net.3544: UDP, length 66
12:49:13.772224 IP miredo.svr01.mucip.net.3544 > geist.local.3545: UDP, length 48
12:49:13.772313 IP geist.local.3545 > 6to4.lon1.he.net.60298: UDP, length 40
12:49:13.804079 IP 6to4.lon1.he.net.60298 > geist.local.3545: UDP, length 66
Exchange
With Teredo server
Exchange with
Teredo Relay

Configure Teredo on Linux
$sudo aptget install miredo
$sudo echo “InterfaceName teredo
ServerAddress teredodebian.remlab.net
” >/etc/miredo.conf
$sudo /etc/init.d/miredo restart #or usingsystemd
Code from Rémi Denis-Courmont (remlab.net), relays courtesy of
Hurricane Electric (a wholsesale provider) that distributed around
the world 14 teredo relays. The microsoft relay since long is not in
operation anymore.

Configure Teredo on Windows
Run as administrator at the command prompt :
C:> netsh interface teredo
Netsh>interface>teredo> show all
..
Netsh>interface>teredo> set servername=teredo.remlab.net
..

Ipv6-test.com after teredo from
firefox
Score 18/20 = teredo tunneled ipv6 / no hostname in dns

Ipv6-test.com after teredo with
konqueror
Score 15/20 because konqueror doesnt fast-fallback on ipv4 (red : -3) !

Ipv6 test sites
● ipv6.google.com
● ipv6-test.com
● test-ipv6.com
● [2001:200:dff:fff1:216:3eff:feb1:44d7]
(www.kame.net : turtle swimms if your reach
the site using ipv6)
● http://ip.bieringer.de/

Questions/1
●
How many bits in an IPv6 address ? How many bits in the interface part ?
– 128, 64
●
Protocol with longer addresses ?
– ISO CLNP (Connectionless protocol) addresses up to 160 bits
●
Chain of control for IPv6 addresses ?
– IANA, RIRs, ISPs/LIRs
●
In which case end users should renumber if they change provider ?
– Provider aggregatable address
●
How long will be normally the IPv6 prefix assigned to an institution or a company ? How many
bits for the site topology will remain ?
– /48, 16
●
Algorithm for assigning addresses in the sparsest way, an example ?
– Bit reversal, 0 8 4 12 2 10 6 14 1 9 5 7 3 11 7 15
●
Objective measure of being “short of addresses” ?
– Host density = log(allocated)/log(allocateable) > 0.75, hd=log(23)/log(24)=3/4=0.75
● Prefix for Link local addresses ? Unique Local ? Teredo ?
– Fe80::/10, fd00::/8, 2001:0::/32

Ipv6 addresses : a recap
repetita iuvant :)
64 bits 64 bits
Interface idNetwork id
128 bits
001 global routing prefix subnet id interface id
45 bits3 bits 16 bits 64 bits
IANA→RIR RIR→LIR 128-/48=80 bits for the end user
2001:0db8:2344: 004d: 74de:0e5d:00ca:0001
Site prefix /48 Subnet ID Interface ID
mEUI64 or Random or DHCPv6 or manual
Public topology Private Topology Token
Global Unicast
Addresses

How to use a numeric IPv6 address
in a URL ?
For reasons that you'll understand , often if you access this site with its name the
turtle will not swimm. Use : nslookup www.kame.net to get the address.
NB. firefox in previous release supported the IPv6 zone id: %eth0 or %7, in
later releases it does'nt anymore. There is a clash with the use of characters
in hex : %20.

aptget
You are using a tunnel technology and apt-get over IPv6 is a
snail ?
1. Valid for the single command , add the option :
aptget install log4cplus o Acquire::ForceIPv4=true
2. Valid forever, create
/etc/apt/apt.conf.d/99forceipv4 and
put in it the line :
Acquire::ForceIPv4 “true”;

ping
There is a separate version for pinging on ipv6 on linux : ping6, on Windows use ping -6
inno@geist:~$ ping6 google.com
PING google.com(mia07s24inx0e.1e100.net) 56 data bytes
64 bytes from mia07s24inx0e.1e100.net: icmp_seq=1 ttl=57 time=367 ms
64 bytes from mia07s24inx0e.1e100.net: icmp_seq=2 ttl=57 time=126 ms
Link local addresses should be specified together with interface :
inno@geist:~$ ping6 I eth0 ghost.local
PING ghost.local(ghost.local) from fe80::219:99ff:fe79:ff0 eth0: 56 data bytes
64 bytes from ghost.local: icmp_seq=1 ttl=64 time=0.460 ms
64 bytes from ghost.local: icmp_seq=2 ttl=64 time=0.458 ms
Ping6 consults the neighbour cache to find the LinkLayer Address (MAC) of the next-hop
address and if it is there and still valid then it sends an ICMPv6 EchoRequest = 128 to the node
and waits to receive an ICMPv6 EchoReply = 129. If the entry doesnt exists or it is expired then
the kernel itself sends an ICMPv6 NeighborSolicitation = 135 packet and waits for an ICMPv6
NeighborAdvertisement = 136 from the other node.
NeighborSolicitation usually happens every 60 seconds.

IPv6 Node Information
● Rfc4620 (experimental)
● NIC (Node Information Query)
● Implemented in the original KAME on bsd :
ping6 as client and ninfod as server.
● On Ubuntu Linux ping6 implements the client,
but no server (daemon) for it (security
concerns)
● A server ninfod exists in the iputils of the
USAGI/WIDE project, in fedora iputils-ninfod

Ping as rfc4620/NIQ
client
ping N ...
In this case ping will send a Network Information query (rfc4620).
Flag Description
-N X Sends a Node Addresses query. X can be the following character.
help – show help for NI
name – query for node names
ipv6 – query addresses
ipv6-global query global scope unicast addresses
ipv6-sitelocal query site-local addressses
ipv6-linklocal query link local addresses
ipv6-all query all addresses
ipv4 query ipv4 addresses
ipv4-all on all interfaces
subject-ipv6=ipv6addr
subject-ipv4=ipv4addr
subject-name=nodename
subject-fqdn=fullyqualifieddomainname

ssh to link local ipv6 address
inno@geist:~$ avahi-resolve -6n ghost.local
ghost.local fe80::b6b6:76ff:fe60:588c
inno@geist:~$ ssh -6 inno@fe80::b6b6:76ff:fe60:588c%eth0 #doesn't
work with .local%eth0
Welcome to Ubuntu 15.04 (GNU/Linux 3.19.3-031903-generic x86_64)
* Documentation: https://help.ubuntu.com/
Last login: Thu Sep 17 09:59:42 2015 from fe80::219:99ff:fe79:ff0%eth0
inno@ghost:~$ tail /var/log/auth.log
Sep 17 10:05:55 ghost sshd[4245]: Address fe80::219:99ff:fe79:ff0%eth0
maps to geist.local, but this does not map back to the address -
POSSIBLE BREAK-IN ATTEMPT!
Sep 17 10:05:55 ghost sshd[4245]: Accepted publickey for inno from
fe80::219:99ff:fe79:ff0%eth0 port 59205 ssh2: RSA
fe:6b:ef:53:f7:78:fe:55:5e:b8:b8:60:d1:d2:90:ab

cccccc0g|cccccccc|mmmmmmmm|mmmmmmmm|mmmmmmmm
Generation of modified EUI64
Extended Unique ID(64 bits suffix)
1. Get 48 bit MAC of interface   00:19:99:79:0f:f0
2. Split into 2 24bit groups   001999       790ff0
3. Insert 0xfffe in the middle    001999fffe790ff0
4. Flip 7th bit of 1st byte         021999fffe790ff0
5. Represent it as an Ipv6     ::219:99ff:fe79:ff0
   suffix
To get the LinkLocal EUI64 address, prefix it with 0xfe80 :
LinkLocal Address: fe80::219:99ff:fe79:ff0
An IPv6 node can be configured to get an EUI64 or a Randomized LinkLocal Address.
7th bit of 1st byte is U/L (Universally/Locally assigned) MAC address bit.
If the MAC was Universally assigned =1, then the modified EUI64 is a Locally assigned =0
address.

48 bits MAC address details
14 bits manufacturer code : c
0=universally assigned
g individual/group bit
24 bits assigned by manufacturer : m
.
.

mEUI64 modified EUI64
00 f00f799919
19 0f79feff99 f000
19 0f79feff99 f002
00000000
00000010
MAC 48 bits
mEUI64 bits
EUI 64 bits
The 7th
bit of 1st
byte is the Universal(=0), Local(=1) bit. In this way the Universal MAC
assigned by the producer, becomes a Locally assigned 64 bits mEUI.
48 bits
64 bits
64 bits

IPv4 header
Version IHL Type of Service
Identification (Fragment ID)
Total Lenght
M
F
D
F Fragment offset
ProtocolTime-To-Live Header Checksum
0
4
8
12
16
20
20bytes
| 0 3 | 4 7 | 8 15 | 16 31 |
32 bits
In IPv4 the header is common to all protcols. There is no IP only packet, but ICMPv4, TCP, UDP and
IPSEC are top level entities at same level (signalled by the Protocol field) :
1 ICMPv4 Internet Control Message Protocol for IPv4 (RFC 792)
2 IGMP Internet Group Management Protocol (RFCs 1112, 2236 and 3376)
4 IPv4 IPv4 in IPv4 encapsulation, "IP in IP" tunneling (RFC 2003)
6 TCP Transmission Control Protocol (RFC 793)
8 EGP Exterior Gatgeway Protocol (RFC 888)
Pic Courtesy
G. Radeka
17 UDP User Datagram Protocol (RFC 768)
41 IPv6 IPv6 tunneled over IPv4, "6in4" tunneling (RFC 2473)
50 IPSec ESP Header (RFC 2406)
51 IPSec AH Header (RFC 2402)
89 OSPF Open Shortest Path First routing (RFC 1583)
132 SCTP Streams Control Transmission Protocol (RFC 4960)

Header checksum,
Upper Layer Checksum
● A major decision for IPv6 was to eliminate the header checksum : it was due
to the fact that most of the errors revealed were due to the memory of
routers when this checksum is in any case recalculated and so it was not of
any help.
● UDP and TCP provide a checksum by themselves that covers not the real
header (that changes along the way [ think about the HopLimit] and would
require expensive recalculations, but a pseudo header (that doesn't change,
same strategy as IPv4) that will be checked only by the destination.
Source address
16 bytes
Destination address
16 bytes
Upper layer packet-length (4 bytes)
Zeroes (3 bytes) Next Header
0 31
IPv6
pseudo-header

IPv6 header
In IPv6:
● IPv4 IHL is missing. Header is always 40 bytes
(quite more efficient for routers on the path)
● IPv4 TotalLength is replaced by IPv6
PayloadLength
● IPv4 Fragment ID, Fragment offset, DF, MF
are part of a special fragment header: only
sending node can fragment in IPv6
● Header checksum is missing : most errors
happen in memory when headers are
recalculated
● IPv4 options are missing : header is fixed
length, eventually Next Header field can specify
a list of other headers
● IPv6 flowlabel is new and gives the possibility
to give a label to the flow. Label that will be
processed by routers on the way
● IPv4 TTL is now more properly called Hop
Limit
Version Traffic Class Flow Label (20 bits)
Payload Length Next Header Hop Limit
Source Address (128 bits)
Destination Address (128 bits)
|0 3| 11| 15|16 31|
40bytes
04812162024283236

IPv6 Next Header
NextHeader codes :
A new Hop-by-Hop extension
header is defined in RFC 2675, "IP
Jumbograms", August 1999. If this
extension header is present, it
overrides the Payload Length field
with a 32 bit value. This allows the
payload length to be up to 4
gigabytes.
They can be found mixed with IPv4
analogous protocol values in
/etc/protocols.
0 Hop-by-Hop extension header
6 TCP - Transmission Control Protocol (RFC
793)
17 UDP - User Datagram Protocol (RFC 768)
43 Routing Extension Header : ipv6-route
44 Fragment Extension Header : ipv6-frag
50 IPSec ESP Header (RFC 2406) : esp
51 IPSec AH Header (RFC 2402) : ah
58 ICMPv6 (Internet Control Message Protocol
for IPv6 (RFC 4443) : ipv6-icmp
59 No next header (packet ends after this
header or extension header): ipv6-nonxt
60 Destination Options extension header: ipv6-
opts
89 OSPF - Open Shortest Path First routing
(RFC 1583): ospf
132 SCTP - Streams Control Transmission
Protocol (RFC 4960): sctp

IPv6 header chains
Header chains in IPv6 :
IPv6
TCP
TCP
Header Data
IPv6
ICMPv6
ICMPv6
Header Data
IPv6
Rout Hdr
Routing
Extension hdr Data
IPv6
Fragment
Header
1st
fragment
Data
TCP
Header
Routing
Extension hdr
Frag H TCPRout Hdr
TCP
Header
TCP
NoNxt
Next Header Labels
RFC2460 order of hdrs :
- Hop-by-Hop
- Destination Opt hdr
- Routing Header
- Fragment Header
- Auth hdr
- ESP hdr
- UpperLayer protocol hdr

IPv6 fragmentation/1
● Routers can't perform
fragmentation along the
path like in IPv4
● Only the source
node,after performing
PathMTU discovery or
receving a Packet Too
Big ICMPv6 error msg,
can fragment the packets
(How can this happen ?)
Fragment Header :
NextHeader: 8 bits header type of the
payload
Reserved : 8 bits
Fragment offset : 13 bits unsigned, offset
into fragmentable part in multiples of 8 bytes.
Therefore can indicate an offset up to 8191*8
= 65,528. You can't use it for jumbograms.
Res : 2 bits
M : 1=more frags, 0=last fragment
Identification : 32 bits unique integer
Next Hdr Reserved Fragment Offset Res M
Identification
8 bits 8 bits 13 bits 2 1

The sending node for each packet to be
fragmented generates a unique integer
Identifier for the packet.
Then selects the
UnfragmentableHeader part (till those
headers that have to be processed on
route : Routing Header or HopByHop
Header) , and divides the rest in
fragments up to PathMTU or less than
the used MTU (1280 should be safe).
The segments are then forwarded
prepending to all of them the
Unfragmentable Header part and a
proper FH (Fragment Header).
If fragments are not received completely
in 60 seconds then they are discarded.
Unfragmentable
Header Part
1
Fragmentable part
432
Unfragmentable
Header Part
3
4
Original packet
Unfragmentable
Header Part
Unfragmentable
Header Part
Unfragmentable
Header Part
2
Fragment 1Fragment 1Fragment 1
Fragment 2
Unfragmentable
Header Part
Unfragmentable
Header Part
Unfragmentable
Header Part
Unfragmentable
Header Part
1
Unfragmentable
Header Part
Unfragmentable
Header Part
Fragment 4
Fragment 3
Unfragmentable
Header Part
FH
FH
FH
FH

Security risk :
With fragments the upper layer protocol can finish
in next packets, hidden in the fragmentable part :
● Extension headers tricks : reorder, long chains,
overlapping fragments (forbidden recently by
RFC5722)
● Impossible to filter without stateful firewall
Only possible stateless remedy (eg on Cisco) :
● deny ipv6 any any log undetermined transport

IPv6 jumbograms (RFC2675)
● The Hop-by-Hop header is used to specify delivery
parameters for hops on the path (it is specified by a
previous next-header=0)
Next Hdr Hdr Ext length Options ….
1 byte 1 byte
Number
of 8 bytes groups
other than 1st
Options in TLV format and padding to
8x
Option type Option length Data
Jumbo
payload opt
=194
4 4 bytes
Jumbo payload length
Up to 232
-1
Hop-by-hop
Ext Header
Jumbogram
option
NB. This is an IPv6 jumbogram (that in principle can cross the whole Internet), not a “jumbogram frame”,
those used on Ethernet with an MTU of just 9000. Rumors : “terrible academic idea” :)

Routing extension header/1
Next header Segments leftRouting typeHdr ext len
0 24168 31
type specific data
Type 0 : evil. Provides the same loose route mechanism as in IPv4. Should
be filtered.
Type 1 : unused now. Defined by the Nimrod project for ipng. Should be
filtered also.
Type 2 : used by mobile MIPv6 and understood only by mobile stacks.
Inoffensive. Should be allowed.
OS host router deactivate
Linux >2.6.20 drop process no
MacOS X >10.4.10drop process No
Cisco IOS N/a process yes
Windows >Vista drop N/a N/a
What OS do with
source route type 0
Headers ?

Routing extension type 0/2
Next header Segments leftRouting type=0Hdr ext len = N
0 24168 31
Address 1 (16 bytes)
Reserved 32 bits (4 bytes)
Address N/2 (16 bytes)
.
.
.
RH0 security threat : with an MTU of 1500 you can inject packets with up to
90 waypoints (it means traversing all internet for 45 times back and forth),
because the waypoints don't need to be contiguous. With a 2 mbit/s
connection you amplificate your DoS attack till 180 mbit/s. That's why
processing of RH0 headers should by default be avoided. (RFC5722)

Routing extension type 0/3
Packet Initial Src : fd00:18::1:0 and Dst : fd00:18:3:5
fd00:18::1:0 fd00:18::4:2fd00:18::3:5fd00:18::1:1
Dst: fd00:18::1:1 Dst: fd00:18::6:4Dst: fd00:18::4:2Dst: fd00:18::3:5

Cisco and RH0
#conf t
(config)#no ipv6 sourceroute
All source route packets can be blocked in this way, but this would also block
RH2 required by MIPv6(Mobile Ipv6). To avoid this we need to apply on each
interface :
(config)#ipv6 accesslist denysourcerouted
(configipv6acl)#deny ipv6 any any routingtype 0
(configipv6acl)#permit ipv6 any any
(configipv6acl)#int gi0/0
(configif)#ipv6 sourceroute
(configif)#ipv6 trafficfilter denysourcerouted in

IPv6 on Ethernet
Max size of ethernet frames was since the beginning established in 1518 bytes.
IPv4 was encapsulated on Ethernet II using a 16 bits ether-type of 0x0800 (look at
/etc/ethertypes).
NB. IPv4 Arp uses a different ethertype of 0x0806.
IPv6 uses the 0x86dd ethertype for all its functions ICMPv6, Neighbor Discovery, Router
Discovery, …
08:44:54.554797 f0:79:59:62:02:42 (oui Unknown) > 00:19:99:79:0f:f0 (oui Unknown), ethertype IPv6 (0x86dd), length 118: (hlim 64,
nextheader ICMPv6 (58) payload length: 64) linux.local > geist.local: [icmp6 sum ok] ICMP6, echo reply, seq 1
Ethernet II header = 14 bytes + 4 bytes FrameCheckSequence = RFC894 encapsulation 18 bytes
IPv6 packets sent over Ethernet II have a maximum transmission unit of 1500 (9000 for ethernet jumbograms)
and a minimum size of 46 (to comply with the minimum ethernet frame size of 64 bytes: eventually should be
padded to 46 bytes).
Ethernet 802.3 header = 14 bytes + 8 bytes LLC/SNAP hdr + 4 bytes FCS = RFC1042 encapsulation 26 bytes
IPv6 over 802.3 Ethernet (very rare now) and LLC/SNAP encapsulation has an MTU of 1492 bytes due to the 8
bytes of the LLC/SNAP header.
IEEE 802.11 Wireless has an MTU of 2312 bytes
FDDI has an MTU of 4352 bytes
With the large diffusion of VLANs use the max size of Ethernet frames has been increased for the purpose of
including the VLAN tag (4 bytes) to 1522 bytes, Leaving the MTU to 1500 and 1492.

Transition addresses
● IPv4-compatible address : used by IPv4/6 nodes that are
communicating in IPv6 over an IPv4 structure 0.0.0.0.0.0.w.x.y.z
or ::w.x.y.z for the IPv4 address in dotted decimal notation w.x.y.z,
deprecated in RFC4291
● IPv4-mapped address: used to represent an IPv4 address as an
IPv6 address (same socket6 address struct) ::ffff:x.y.w.z.
Should not be seen on a wire. Appears if you program in an ip-
agnostic way and the connection is from an ipv4 node.
●
6to4 address : a 2002:wwxx:yyzz:subnetID:interfaceID for the
IPv4 node in hex notation ww.xx.yy.zz
● ISATAP address
● Teredo address : 2001:0::/32
●

Network programming/1
Is it possible to build network programs that can work
transparently with ipv4 or ipv6 ?
● The latest socket API can support transparently IPv4
and IPv6 together.
● The oldest gethostbyname() has been replaced by
getaddrinfo() with which to query DNS servers and get
indifferently ipv4 or ipv6 address structures.
● inet_addr() and inet_toa() are replaced by :
– inet_pton() : convert ipv4/6 text to binary for both stacks
– inet_ntop() : convert ipv4/6 binary addr to text for both
stacks

sockets
struct in_addr {
        __be32  s_addr;
};
#define __SOCK_SIZE__ 16/*
sizeof(structsockaddr) */
struct sockaddr_in {
__kernel_sa_family_t
sin_family; /*Addressfamily*/
  __be16 sin_port; /* Port number */
  struct in_addr
sin_addr; /*Internet
address*/
  /* Pad to size of `struct
sockaddr'. */
  unsigned char __pad[__SOCK_SIZE__
sizeof(short int)sizeof(unsigned
short int) sizeof(struct
in_addr)];
};
struct sockaddr_in6 {
sa_family_t     sin6_family;
/*AF_INET6 */
in_port_t       sin6_port;     /*port
number*/
uint32_t        sin6_flowinfo; /*IPv6
flow */
struct in6_addr
sin6_addr;   /*IPv6 address*/
uint32_t        sin6_scope_id; /*Scope
ID*/
};
struct in6_addr {
unsigned char   s6_addr[16]; /* IPv6
address*/
};
struct addrinfo {
  int          ai_flags;
  int         ai_family;
  int       ai_socktype;
  int       ai_protocol;
  socklen_t   ai_addrlen;
  struct sockaddr
*ai_addr;
  char       *ai_canonname;
  struct addrinfo *ai_next;
};
family
flags
*next
*addr
addrlen
type

IPv4/IPv6 network programming/2
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#define RECEIVEBUFFERLENGTH 1024
void main(int argc, char *argv[])
{
int SocketFileDescriptor;
int ReturnValue;
struct in6_addr ServerAddress;
struct addrinfo *LinkedListOfResultingAi=NULL;
char ServerName[255];
char ServerPort[] = "80";
char QueryString[] = "GET / HTTP/1.0nn";
char ReceiveBuffer[RECEIVEBUFFERLENGTH];
strcpy(ServerName, argv[1]);
ReturnValue = getaddrinfo(ServerName,
ServerPort, NULL, &LinkedListOfResultingAi);
SocketFileDescriptor = socket
(LinkedListOfResultingAi->ai_family,
LinkedListOfResultingAi->ai_socktype,
LinkedListOfResultingAi->ai_protocol);
ReturnValue = connect
(SocketFileDescriptor, LinkedListOfResultingAi-
>ai_addr, LinkedListOfResultingAi->ai_addrlen);
ReturnValue = send(SocketFileDescriptor,
QueryString, sizeof(QueryString), 0);
ReturnValue = recv(SocketFileDescriptor,
ReceiveBuffer, RECEIVEBUFFERLENGTH, 0);
printf(ReceiveBuffer,"%sn");
}
All checks and close and free removed, don't use as a pattern for real work !
getaddrinfo()
recv()
send()
connect()
socket()

IPv4/IPv6 network programming/3
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
#define RECEIVEBUFFERLENGTH 1024
void main(int argc, char* argv[])
{
int SocketFileDescriptor;
int DescriptorOfAcceptedSocket;
int ReturnValue;
int on, ReturnValuedsize=RECEIVEBUFFERLENGTH;
char ReceiveBuffer[RECEIVEBUFFERLENGTH];
struct sockaddr_in6 ServerAddress, ClientAddress;
int AddressLength=sizeof(ClientAddress);
char IPv6Address[INET6_ADDRSTRLEN];
char* StringToSend = "HTTP/1.1 200 OKrnDate: Thu, 22
Oct 2015 08:17:45 GMTinServer: ApachenConnection:
closenContent-Type: text/htmlnn<!DOCTYPE HTML
PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">n<html>n<head></head><body>hello !
</body></html>n";
uint16_t ServerPort;
sscanf(argv[1],"%hd",&ServerPort);
printf("Listening on port %dn",ServerPort);
SocketFileDescriptor = socket(AF_INET6, SOCK_STREAM, 0);
setsockopt(SocketFileDescriptor, SOL_SOCKET, SO_REUSEADDR,
(char *)&on,
sizeof(on));
memset((void*)&ServerAddress, 0, sizeof(ServerAddress));
ServerAddress.sin6_family = AF_INET6;
ServerAddress.sin6_port = htons(ServerPort);
ServerAddress.sin6_addr = in6addr_any;
bind(SocketFileDescriptor,(struct sockaddr *)
&ServerAddress,
sizeof(ServerAddress));
listen(SocketFileDescriptor, 10);
printf("Waiting client connectionsn");
DescriptorOfAcceptedSocket=accept(SocketFileDescriptor,
NULL, NULL);
getpeername(DescriptorOfAcceptedSocket,(struct sockaddr
*)&ClientAddress,
&AddressLength);
if(inet_ntop(AF_INET6, &ClientAddress.sin6_addr,
IPv6Address,
sizeof(IPv6Address)))
{
printf("Address client %s, port%dn",IPv6Address,
ntohs(ClientAddress.sin6_port));
}
ReturnValue = recv(DescriptorOfAcceptedSocket,
ReceiveBuffer,
sizeof(ReceiveBuffer)-1, 0);
if (ReturnValue>0) ReceiveBuffer[ReturnValue]= '0';
printf(ReceiveBuffer,"%sn");
printf("We received %d bytesn", ReturnValue);
printf("Sending %d bytesn", (int)strlen(StringToSend));
printf(StringToSend,"%sn");
ReturnValue = send(DescriptorOfAcceptedSocket, StringToSend,
(int)strlen(StringToSend),0);
}
All checks and close and free removed, don't use as a working example !
socket()
recv()
accept()
listen()
bind()
IPv4 client addr printed as ::ffff:x.y.z.w

IPv6 Multicast addresses
and their Ethernet mapping
Group ID
8
bits
4
bits
4
bits
112 bits
ScopeFlag0xff
Multicast IPv6 addresses have the
prefix ff00::/8.
Flag:
0 Permanent well know address
By IANA
1 Transient, dynamic multicast
address, RendezVous
2 Without prefix info, take it by net
3 Transient, dynamic. Assigned
Ethernet destination addresses for
IPv6 multicasts :
33-33+last 32 bits of Group ID
e.g. ff02::101 all ntp servers on LAN
ff08::101 all ntp servers in
organization
Ethernet dest equivalent :
33-33-00-00-01-01
.
.
Scope :
• 0: Reserved
• 1: Interface-Local scope
• 2: Link-Local scope
• 3: IPv4 local scope
• 4: Admin-Local scope
• 5: Site-Local scope
• 6: Unassigned
• 7: Rendezvous Point flag
• 8: Organization-Local scope
• E: Global Scope
IPv4 multicasts were instead mapped to the
ethernet destinations :
● 01:00:5E:00:00:00 – 01:00:5E:7F:FF:FF (23 bits
available for Group ID)

Multicast Scopes
Internet
E - GlobalE - Global
1 – Interface
Local
2 – Link Local
5 – Site Local
8 – Organization Local

Multicast groups
IPv6 tries to be minimal in resources it consumes so it replaced
broadcast messages (as used by IPv4 : eg. arp) with multicast
messages. There are 2 well known groups (that can be usually
used with literals because they appear in /etc/hosts ) :
● ff02::1 ip6-allnodes
● ff02::2 ip6-allrouters
E.g. : ping6 -I eth0 ip6-allnodes
ping6 -I eth0 ip6-allrouters
All nodes should be listen on the ip6-allnodes multicast
address and all routers should be listen to the ip6-allrouters
address. Therefore a node can easily discover its neighbours
nodes, and the routers in its broadcast domain.

Multicast groups/2
well known
Well known multicast groups :
● ff02::1 All nodes on the local network segment
● ff02::2 All routers on the local network segment
● ff02::5 OSPFv3 All SPF routers
● ff02::6 OSPFv3 All DR routers
● ff02::8 IS-IS for IPv6 routers
● ff02::9 RIP routers
● ff02::a EIGRP routers
● ff02::d PIM routers
● ff02::16 MLDv2 reports (defined in RFC 3810)
● ff02::1:2 All DHCP servers and relay agents on the local network segment (defined in RFC 3315)
● ff02::1:3 All LLMNR hosts on the local network segment (defined in RFC 4795)
● ff05::1:3 All DHCP servers on the local network site (defined in RFC 3315)
● ff0x::c Simple Service Discovery Protocol
● ff0x::fb Multicast DNS
● ff0x::101 Network Time Protocol
● ff0x::108 Network Information Service
● ff0x::181 Precision Time Protocol (PTP) version 2 messages
● ff02::6b Precision Time Protocol (PTP) version 2 peer delay measurement messages

RFC 2464
IPv6 Solicited-Node Multicast Address
In adddition to all unicast addresses assigned to an interface, a device will
have an IPv6 Solicited-Node Multicast Address (remember that IPv6
doesn't use broadcasts ) created mapping the device unicast addr with
the special multicast prefix :
So the device having :
● LL address : fe80::374:12f8:8a7e:54d2/64
● Global Unicast address: 2001:db8:bb:10:374:12f8:8a7e:54d2
Will listen also to ff02:0:0:0:0:1:ff7e:54d2
multicast address formed adding to the well known prefix the last 3 bytes of
the IPv6 unicast address.
Copy 24 bits
(3 bytes)
ff02::1:ff00:0/104
Ff02:0:0:0:0:1:ff00:0/104

IPv4-IPv6 control protocols
IPv4 control protocols:
● ARP
● ICMPv4
● IGMPv4
Parts of ICMPv4 and
IGMPv4 are not required
to be implemented. IGMP
is part of IP multicast and
is not usually available.
IPv6 control protocols :
● Only ICMPv6
ICMPv6 needs to be
fully implemented and
every node needs to
implement multicast.

ICMPv6
ICMPv6 is not just the transposition of ICMP to IPv6,
but it collects in itself many different functionalities :
● NDP (Network Discovery Protocol, RFC 4861), it
replaces arp of IPv4
● MRD (Multicast Router Discovery, RFC4286)
● MLD2 (Multicast Listener Discovery, RFC3810)
● SEND (Secure Network Discovery Protocol,
RFC3971) an extension of NDP
NextHeader type for ICMPv6 is 58.

ICMPv6/2
1 Destination Unreachable
2 Packet Too Big
3 Time Exceeded
4 Parameter Problem
128 Echo Request
129 Echo Reply
130 Multicast Listener Query
131 Multicast Listener Report
132 Multicast Listener Done
133 Router Solicitation (NDP)
134 Router Advertisement (NDP)
135 Neighbor Solicitation (NDP)
136 Neighbor Advertisement (NDP)
137 Redirect Message (NDP)
138 Router Renumbering
139 ICMP Node Information Query
140 ICMP Node Information Response
141 Inverse Neighbor Discovery Solicitation Message
142 Inverse Neighbor Discovery Advertisement Message
143 Multicast Listener Discovery (MLDv2) reports (RFC 3810)
144 Home Agent Address Discovery Request Message
145 Home Agent Address Discovery Reply Message
146 Mobile Prefix Solicitation
147 Mobile Prefix Advertisement
148 Certification Path Solicitation (SEND)
149 Certification Path Advertisement (SEND)
151 Multicast Router Advertisement (MRD)
152 Multicast Router Solicitation (MRD)
153 Multicast Router Termination (MRD)
155 RPL Control Message
58 = ICMPv6
PING
ROUTER
PING
NEIGHBOR
MULTICAST
Bit offset 0-7 8-15 16-31
0 Type Code checksum
32 Message Body
Version
4 bits
Traffic Class
8 bits Flow Label (20 bits)
Payload Length(16bits)
Next Header
8 bits
Hop Limit
8 bits
Source Address (128 bits)
Destination Address (128 bits)
|0 3| 11| 15|16 31|
40bytes
04812162024283236
ICMPmsgTypes
ERRORS

ICMPv6/3
NDP (RFC4861) Network Discovery
Protocol ( replaces arp), discovers
LinkLayer addresses :
● Show neighbours in neighbour
cache (NC) :
ip -6 neigh
You can populate the cache with a ping to ip-allnodes
ping6 -I eth0 ip-allnodes
● Add a neighbour in NC :
Ip -6 neigh add fe80::be5f:f4ff:fecb:742f dev eth0
lladdr bc:5f:f4:cb:74:2f
● Delete a neighbour in NC :
Ip -6 neigh dele fe80::be5f:f4ff:fecb:742f dev eth0
lladdr bc:5f:f4:cb:74:2f
● You can use ndisc6 to manually
perform network discovery of nodes :
ndisc6 fe80::be5f:f4ff:fecb:742f eth0
ND is usually done automatically by
the kernel when entries do not exist
or are expired. To see it at work :
1.Launch in a window ndpmon
2.Launch in another window a
ping6 to a LinkLocal node
fe80::...
3.You will see every minute or so
that the kernel refreshes the
entry in the NC sending a
NeighborSolicitation and
receiving a
NeighborAdvertisement

ICMPv6/4
Routers on the LAN are discovered
with simply a different ICMPv6 type :
RouterSolicitation = 133 and
RouterAdvertisement = 134 :
● Show routes in tables :
ip -6 route
You can populate the table with a ping to ip-allrouters
ping6 -I eth0 ip-allrouters
● Add a route :
Ip -6 route add fe80::/64 dev eth0 proto kernel metric
256
● Delete a route :
Ip -6 neigh dele fe80::/64 dev eth0 proto kernel metric
256
● Discover manually :
rdisc6
● You can list ipv6 routes also with :
netstat -6r
ndpmon monitors also Router Solicitation /
Advertisement traffic. Routers are supposed to
send an advertisement every 60 seconds to the
multicast address ff02::2 (ip6-allrouters) in this
way all nodes learn about the routers on the
LAN and create their dispatch table. When
nodes start ipv6 on an interface they try to solicit
a router advertisement after 1 second and they
try for 3 times every 4 seconds (default timers in
net.ipv6.conf.... )
In linux the router advertisement is done by the
service radvd (Router Advertisement Daemon)
configured by the file /etc/radvd.conf.
Should not be activated on end nodes : in fact
the daemon dies if it is not configured to send
RA.
On routers the router advertisement is activated
by default when you assign an interface an ipv6
address.

ICMPv6 Router Advertisement pkt/1
Current Hop Limit :
The value the router
suggests hosts on the
LAN
to use as Hop Limit
Router Lifetime :
expiration lifetime in
seconds for the router
being used as default
router only, 0 means
don't
use this router as
default
router
Rechable Time :
Tells hosts how long in
ms
they should consider
reachable a neighbor
after
a reachable msg
Retransmission
timer :
The time in ms a host
should wait to retxmit a
Neighbor Solicitation
message
Options :
MTU
Prefix
Reserved
ICMPv6 Options
Reachable Time
Retransmission Timer
Autoconfig Flags Router LifetimeCurrent Hop Limit
Code=0 ChecksumType=134
0 8 16 32
M
managd
Addr
conf
O
Other
conf

Type Length Value...Options TLV format :
Source/Target LL Address (contains
the LL address of source or target)
Type Length Value...
1=Source LL
2=Target LL
Length LL address
3=prefix info
0-128 bits
Of prefix
Prefix information L A Reserved 1
Valid Lifetime in sec for on-link
Preferred lifetime in sec for validity of
derived addresses
Reserved1 must be =0
Prefix
L = on-link flag : this prefix can
be used for on-link
determination
A = autonomous address
configuration flag : when set
indicates that this prefix can be
used for stateless address
configuration

Type Length Value...Options TLV format : Type Length Value...
5=MTU
1 x
8 bytes
...
5=MTU
1 x
8 bytes
Reserved 1
set to 0
MTU 32 bits
MTU (Maximum Transmission Unit)
The MTU option is sent in Router
Advertisement to be sure that all nodes
on a link use the same MTU.

RA flags
An host can perform dynamic address
configuration in a stateful or stateless manner.
Both are indipendent and can also be used
together.
1) Stateless :
● Using prefix discovery SLAAC
● Using DHCPv6 stateless
● Manually
2) Stateful :
– Using DHCPv6 stateful
The A flag (Autonomous Address
Configuration) in RA tells if the
prefix advertised in the Router
Advertisement can be used in
SLAAC, by default is set to 1=yes.
IPv6 host behaviour
Depends on 2 flags the router sets in its Route
Advertisement messages:
● M flag or Managed Address Configuration flag
●
O flag or Other Stateful Configuration flag
M,O are 0,0 : net w/o DHCPv6 server, host
configures address from RA, other parameters are
set manually
M,O are 1,1 : DHCPv6 is used for addresses and
other parameters (DHCP stateful)
M,O are 0,1 : hosts get node addresses from RAs,
DHCPv6 is used to get other conf parameters
(DHCPv6 stateless)
M,O are 1,0 : DHCPv6 is used for address
configuration but not for other settings (unlikely
because hosts need other parameters like DNS
servers)
I

Questions 2
● How do you use a numeric address in an URL ?
– [2001:760:……]
● Length of IPv4 header ? Length of IPv6 header ?
– Variable 20.. , fixed 40 bytes
● Why header checksum was abandoned in IPv6 ?
– Because errors were mostly caused by bad memory in routers were header checksum is in any case recalculated
●
Is there any remnant of fragment management in the IPv6 header ?
– No, it is part of an extension header
● If in an extension header the next header field =TCP , what will be the nextheader field in the TCP header ?
– Tcp header is just the normal tcp header, it is not an ipv6 extension header and has no next header field
● Components of ICMPv6 ?
– ND neighbour discovery, RD router discovery , MLD multicast listener discovery
● Fragmentation can manage packets up to how many bytes ?
– 64 K
● What is a jumbogram in IPv6 lingo ? how many bytes in it ?
–
A packet with the jumbo payload option in an icmpv6 header, up to 232 -1 bytes
● Important flags of Router Advertisement packets ?
– Managed stateful flag, Other stateful flag . Options of prefixes : On-link prefix, Autonomous Address configuration prefix

IPv6 DAD Duplicate Address Detection
A device uses Duplicate
Address Detection(DAD) to
discover if an address that it
wants to use is already used by
some other device on the LAN.
RFC4861 recommends that DAD
be performed for every unicast
address : link local or global,
manually assigned or assigned
by SLAAC or DHCPv6. If a
duplicate address is discovered it
cannot be used by the device.
1. A device builts its own LinkLocal
address using the modified EUI64
algorithm : fe80::219:99ff:fe79:ff0
2. It sends an ICMPv4 Neighbor
Solicitation Message source mac
its MAC address, destination mac
the (ipv6-mapped multicast) 33-33-
fe-79-0f-f0, source ipv6
unspecified(::), dest ipv6
fe80::219:99ff:fe79:ff0
3. The device waits for some seconds
for a Neighbor Advertisement
answer. If no answer it uses the
address calculated.

IPv6 NUD Neighbor Unreachability Detection
RFC4861
Devices monitor the reachability of neighbors to which they are sending
traffic. The reachability is confirmed by a response to a Neighbor
Solicitation or an ACK in a TCP connection for instance.
When a path seems to be failing :
1. If the neighbor is the ultimate destination : address resolution should
be performed again :
1. Send a NeighborSolicitation msg
2. Wait for a NeighborAdvertisement msg
2. If the neighbor is a router try to use a different default gateway
NUD, of course, is performed only for neighbors to which unicast packets
are sent

IPv6 MLDv2 (RFC3810)
Multicast Listener Discovery
Based on IGMPv3, compatible with MLDv1
extends MLDv1 with support of Source Specific
Multicast (SSM).

IPv6 MLDv2/2
● Multicast Listener Query
type=130
– General Query
– Multicast-Address-specific
query
● Multicast Listener Report
type=131
● Multicast Listener Done
type=132
With these messages the routers on
the LAN learn which channels
(multicast addresses) should be re-
txmitted on the LAN.
1. The router priodically sends a General Query
to the ip6-allnodes multicast address
2. A host member of the multicast group
ff3e:0060:2002:0DB8:ccc:1:0000:2222 receives the
query, waits a random amount of time and if it
doesn't hear another host to report for the same
group, it sends a Multicast Listener Report for it to the
multicast address all MLDv2 capable router ff02::16
3. Another host member of a different group waits also a rnd
amount of time and sends its Multicast Listener Report
also to ff02::16
4. When a host wants to stop listening to a multicast
address it sends a Multicast Listener Done msg to
the ff02::16
5. The router doesn't maintain a list of nodes listening
on an address so when it receives the Done message
it needs to send a Multicast-Address-specific query to
the multicast address of the group to see if there are
nodes still listening to the address and if not to clear
it from the listened mcast addresses on the LAN

Path MTU
In IPv4 routers can fragment a
packet along the path. These
fragments pose some security risks
and usually security appliances will
re-assemble them.
In IPv6 only the sender can
fragment a packet, routers do not
fragment it. For this reason it is
recommended to discover the
maximum Path MTU to have a more
efficient transmission.
IPv6 dictates that all links support
an MTU of at least 1280 bytes, in
IPv4 this was 64 bytes.
Path MTU discovery
The sender supposes the path has a
PathMTU equal to the one of the
first hop and tries to send a packet of
that size. If the packet is ack then it
sets that as the PMTU, otherwise a
router will refuse to forward the pkt
and sends back an ICMPv6 Error
Message : Packet too big that
contains a supported smaller MTU
that the sender will now try to use.
This is one of the reasons why
ICMPv6 should not be blocked. They
are essential for normal behaviour.

Multihoming in IPv6
To deploy a fault tolerant
connection to the Internet
many connect to 2 different
ISPs. In this case the idea of
the IPv6 Provider
Aggregatable addresses
does'nt work well.
The initial answer from IPv6
specs was that the company
should get a different prefix
from both providers and its host
should configure in both networks.
In reality today, despite the initial
aims, companies that want to be
multihomed get a Provider
Independent prefix from RIRs. It
is hoped that before an IPv6 route
explosion something different will
be devised (~20.000 IPv6 prefixes
announced as of today).

RFCs
More than 100 RFCs are available for IPv6. In the Rfcs Node is a host or
router.
Therefore rfc6434 applies to both.
● Rfc2460 Internet Protocol, Version6, Specification
● Rfc6434 IPv6 node requirements
● Rfc6204 Basic requirements for IPv6 customer edge routers
● RIPE-554 Requirements for IPv6 in ICT equipment
● Rfc4291 IPv6 addressing architecture
● Rfc4007 IPv6 scoped address architecture
● Rfc3879 Deprecating Site-Local addresses
● Rfc4193 Unique Local IPv6 unicast addresses
● Rfc5942 IPv6 subnet model : the relationship between subnet and link
prefixes
● Rfc4941 Privacy extension for stateless address autoconfiguration in IPv6
● Rfc3971 Secure Neighbor Discovery (SEND)

Linux tools for ipv6/1
● ifconfig
● ip -6 route
● Ip -6 addr
● ip -6 maddr
● iip -6 neigh
● ip -6 ntable
● ip -6 neigh show nup all

● ipv6calc
● ipv6loganon
● ipv6logconv
● ipv6logstats

● ndisc6 ICMPv6 Neighbour Discovery tool
● rdisc6 ICMPv6 Route Discovery tool
● tracepath6 Trace path using UDP and discovering path MTU
● ip6tables ipv6 version of iptables
● traceroute6 / tcptraceroute6 Equivalent to : traceroute -6
●
● Install with : sudo apt-get install ndisc6
inno@geist:~$ traceroute6 google.com
traceroute to 2607:f8b0:4008:804::200e (2607:f8b0:4008:804::200e) from 2001:0:53aa:64c:3422:f226:6c85:e7b5, 30 hops max, 60
bytes packets
1 2001:0:53aa:64c:2ccf:708d:27bd:bf75 (2001:0:53aa:64c:2ccf:708d:27bd:bf75) 234.680 ms 101.461 ms 100.401 ms
2 gigabitethernet5-2.core1.ash1.he.net (2001:470:0:136::1) 209.740 ms 100.546 ms 108.117 ms
3 * * *
4 2001:4860::1:0:9ff (2001:4860::1:0:9ff) 212.682 ms 113.411 ms 107.457 ms
5 2001:4860::8:0:6374 (2001:4860::8:0:6374) 210.626 ms 103.878 ms 235.942 ms
6 2001:4860::8:0:5b13 (2001:4860::8:0:5b13) 263.756 ms 246.549 ms 117.172 ms
7 2001:4860::1:0:245b (2001:4860::1:0:245b) 398.464 ms 139.171 ms 126.571 ms
8 2001:4860:0:1::f3 (2001:4860:0:1::f3) 268.305 ms 126.539 ms 126.867 ms
9 mia07s24-in-x0e.1e100.net (2607:f8b0:4008:804::200e) 126.467 ms 125.864 ms 125.758 ms

ifconfig
inno@ghost:~/ipv6$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr b4:b6:76:60:58:8c
inet addr:147.122.24.71 Bcast:147.122.24.255 Mask:255.255.255.0
inet6 addr: fe80::b6b6:76ff:fe60:588c/64
Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12862876 errors:0 dropped:0 overruns:0 frame:0
TX packets:19512845 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11451349683 (11.4 GB) TX bytes:26499471613 (26.4 GB)
inno@ghost:~/ipv6$ ifconfig teredo
teredo Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: 2001:0:53aa:64c:38a9:399e:6c85:e7b8/32
Scope:Global
inet6 addr: fe80::ffff:ffff:ffff/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1
RX packets:48992 errors:0 dropped:0 overruns:0 frame:0
TX packets:41757 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:19399443 (19.3 MB) TX bytes:8271112 (8.2 MB)
inno@ghost:~/ipv6$ sudo ifconfig eth0 add 2001:db8:0204::1
inno@ghost:~/ipv6$ sudo ifconfig eth0 del 2001:db8:0205::1
Adding and deleting an Unicast Global address from an interface

Windows commands for IPv6
● Netsh inter ipv6 show address
● Netsh inter ipv6 show neighbor
● Netsh inter ipv6 show route
● Netsh inter ipv6 show dnsserv
● Netsh inter ipv6 show global
● Netsh inter ipv6 show interf
● Netsh inter ipv6 show privacy
● Netsh inter ipv6 show siteprefix
● Netsh inter ipv6 add address
● Netsh inter ipv6 del address
● Netsh inter ipv6 show joins

Linux/Windows commands
Linux Windows
Ping6 ip6-localhost Ping -6 ::1
Ping6 -I eth0 ip6-allnodes Ping -6 fe02::1%7
Ping6 -I eth0 ip6-allrouters Ping -6 fe02::1%7
Ip -6 addr Netsh inter ipv6 show addr
Ip -6 maddr Netsh inter ipv6 show joins
Ip -6 neigh Netsh inter ipv6 show neigh
Ip -6 route Netsh inter ipv6 show route
For windows add the literal names in c:windowssystem32driversetchosts

Multicast and
unicast addresses
in practice/1
C:>netsh inter ipv6 show joins
Interface 21: Wi-Fi
Scope References Last Address
---------- ---------- ---- --------------------------
0 0 Yes ff01::1
0 0 Yes ff02::1
0 4 Yes ff02::c
0 1 Yes ff02::fb
0 1 Yes ff02::1:3
0 1 Yes ff02::1:ff52:8f8c
Interface 1: Loopback Pseudo-Interface 1
Scope References Last Address
---------- ---------- ---- ------------------------
0 4 Yes ff02::c
Interface 19: Teredo Tunneling Pseudo-Interface
Scope Ref Last Address
---------- ------ ---- ---------
0 0 Yes ff01::1
0 0 Yes ff02::1
0 2 Yes ff02::1:ff02:45
Interface 7: Ethernet
Scope Ref Last Address
---------- ----- ---- -----------
0 0 Yes ff01::1
0 0 Yes ff02::1
0 1 Yes ff02::1:ff7f:c528
C:>netsh inter ipv6 show addr
Interface 21: Wi-Fi
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- --------------------
Other Preferred infinite infinite fe80::517c:baca:1852:8f8c%21
Interface 1: Loopback Pseudo-Interface 1
--------- ----------- ---------- ---------- ------------------------
Other Preferred infinite infinite ::1
Interface 19: Teredo Tunneling Pseudo-Interface
--------- ----------- ---------- ---------- ------------------------
Public Preferred infinite infinite 2001:0:53aa:64c:a5:8bbe:a402:45
Other Preferred infinite infinite fe80::a5:8bbe:a402:45%19
Interface 7: Ethernet
--------- ----------- ---------- ---------- ------------------------
Other Deprecated infinite infinitefe80::e12f:2f9a:a07f:c528%7

Multicast and
unicast
addresses in
practice/2
cisco@onepk:~$ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qlen 1000
inet6 fe80::a00:27ff:fe25:ce0a/64 scope link
3: eth1:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu
1500 qlen 1000
inet6 fe80::a00:27ff:fe09:d95a/64 scope link
9: teredo:
<POINTOPOINT,MULTICAST,NOARP,UP,LOWER
_UP> mtu 1280 qlen 500
inet6 2001:0:53aa:64c:499:88fb:a402:45/32
scope global
inet6 fe80::ffff:ffff:ffff/64 scope link
cisco@onepk:~$
cisco@onepk:~$ ip -6 maddr
1: lo
inet6 ff02::1
2: eth0
inet6 ff02::fb
inet6 ff02::1:ff25:ce0a
inet6 ff02::1
3: eth1
inet6 ff02::fb
inet6 ff02::1:ff09:d95a
inet6 ff02::1
5: virbr0
inet6 ff02::1
7: teredo
inet6 ff02::1
cisco@onepk:~$

ndisc6
Neighbor discovery :
root@geist:~# ndisc6 hawx.local eth0
Soliciting hawx.local (fe80::219:99ff:fe7b:feab) on eth0...
Target linklayer address: 00:19:99:7B:FE:AB
from fe80::219:99ff:fe7b:feab
Trace of it :
root@geist:~# tcpdump i eth0 e ip6
tcpdump: verbose output suppressed, use v or vv for full protocol decode
listening on eth0, linktype EN10MB (Ethernet), capture size 262144 bytes
11:27:27.847150 00:19:99:79:0f:f0 (oui Unknown) > 33:33:00:00:00:fb (oui Unknown), ethertype IPv6 (0x86dd),
length 90: geist.local.mdns > ff02::fb.mdns: 0 AAAA (QM)? hawx.local. (28)
11:27:27.847541 00:19:99:7b:fe:ab (oui Unknown) > 33:33:00:00:00:fb (oui Unknown), ethertype IPv6 (0x86dd),
length 112: hawx.local.mdns > ff02::fb.mdns: 0* [0q] 1/0/0 (Cache flush) AAAA fe80::219:99ff:fe7b:feab (50)
11:27:27.848084 00:19:99:79:0f:f0 (oui Unknown) > 33:33:ff:7b:fe:ab (oui Unknown), ethertype IPv6 (0x86dd),
length 86: geist.local > ff02::1:ff7b:feab: ICMP6, neighbor solicitation, who has hawx.local, length 32
11:27:27.848337 00:19:99:7b:fe:ab (oui Unknown) > 00:19:99:79:0f:f0 (oui Unknown), ethertype IPv6 (0x86dd),
length 86: hawx.local > geist.local: ICMP6, neighbor advertisement, tgt is hawx.local, length 32
length 152: geist.local.mdns > ff02::fb.mdns: 0 PTR (QM)?
0.f.f.0.9.7.e.f.f.f.9.9.9.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
length 171: geist.local.mdns > ff02::fb.mdns: 0* [0q] 1/0/0 (Cache flush) PTR geist.local. (109)
length 152: geist.local.mdns > ff02::fb.mdns: 0 PTR (QM)?
b.a.e.f.b.7.e.f.f.f.9.9.9.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
11:27:29.023796 00:19:99:7b:fe:ab (oui Unknown) > 33:33:00:00:00:fb (oui Unknown), ethertype IPv6 (0x86dd),
length 170: hawx.local.mdns > ff02::fb.mdns: 0* [0q] 1/0/0 (Cache flush) PTR hawx.local. (108)
11:27:32.853122 00:19:99:7b:fe:ab (oui Unknown) > 00:19:99:79:0f:f0 (oui Unknown), ethertype IPv6 (0x86dd),
length 86: hawx.local > geist.local: ICMP6, neighbor solicitation, who has geist.local, length 32
11:27:32.853163 00:19:99:79:0f:f0 (oui Unknown) > 00:19:99:7b:fe:ab (oui Unknown), ethertype IPv6 (0x86dd),
length 78: geist.local > hawx.local: ICMP6, neighbor advertisement, tgt is geist.local, length 24
Solicited-node-multicast address

rdisc6
Discover routers on the LAN :
root@geist:~# rdisc6 m  eth0
Soliciting ff02::2 (ff02::2) on eth0...
Hop limit                 :           64 (      0x40)
Stateful address conf.    :           No
Stateful other conf.      :           No
Router preference         :       medium
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
Prefix                   : fd00:b3:18::/64
  Valid time              :        86400 (0x00015180) seconds
  Pref. time              :        14400 (0x00003840) seconds
MTU                      :         1280 bytes (valid)
Source linklayer address: 00:19:99:79:0F:F0
from fe80::219:99ff:fe79:ff0
Trace of it :
root@geist:~# tcpdump e i eth0 ip6
tcpdump: verbose output suppressed, use v or vv for full protocol decode
listening on eth0, linktype EN10MB (Ethernet), capture size 262144 bytes
12:57:17.164777 00:19:99:79:0f:f0 (oui Unknown) > 33:33:00:00:00:02 (oui Unknown), ethertype IPv6
(0x86dd), length 62: geist.local > ip6allrouters: ICMP6, router solicitation, length 8
12:57:17.164996 00:19:99:79:0f:f0 (oui Unknown) > 33:33:00:00:00:01 (oui Unknown), ethertype IPv6
(0x86dd), length 118: geist.local > ip6allnodes: ICMP6, router advertisement, length 64
12:57:18.247996 00:19:99:79:0f:f0 (oui Unknown) > 33:33:00:00:00:fb (oui Unknown), ethertype IPv6
(0x86dd), length 152: geist.local.mdns > ff02::fb.mdns: 0 PTR (QM)?
0.f.f.0.9.7.e.f.f.f.9.9.9.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
12:57:18.248221 00:19:99:79:0f:f0 (oui Unknown) > 33:33:00:00:00:fb (oui Unknown), ethertype IPv6
(0x86dd), length 171: geist.local.mdns > ff02::fb.mdns: 0* [0q] 1/0/0 (Cache flush) PTR
geist.local. (109)
Router Advertisement Flags :
M=0, O=0 no dhcpv6
ip6-allrouters multicast

tracepath6
Discovers hops and Path MTU :
root@geist:~# tracepath6  b www.tudelft.nl
1?: [LOCALHOST]                        0.058ms pmtu 1280
1:  miredo.surfnet.nl (2001:610:168:a:145:220:0:46)     101.349ms
1:  miredo.surfnet.nl (2001:610:168:a:145:220:0:46)      32.535ms
2:  onweer.as1101.net (2001:610:168:a::1)                77.222ms
3:  XE116.JNR01.Asd001A.surf.net (2001:610:f01:8152::153)
77.039ms
4:  AE0.500.JNR01.Asd002A.surf.net (2001:610:e08:80::81)
67.500ms
5:  2001:610:f02:6096::98 (2001:610:f02:6096::98)        70.445ms
6:  2001:610:908:112:131:180:77:102
(2001:610:908:112:131:180:77:102)  34.837ms reached
     Resume: pmtu 1280 hops 6 back 6

tracert6/traceroute6/tcptraceroute6
traceroute6 by default sends UDP packets while increasing their Hop Limit (similar to
what traceroute does for IPv4), it can also send ICMPv6 Echo Request like the windows
implementation does (tracert6 does this). tcptraceroute6 uses tcp packets (SYN/ACK).
root@geist:~# tracert6 ipv6.google.com
traceroute to ipv6.l.google.com (2a00:1450:4002:803::1000) from 2001:0:53aa:64c:86f:f226:6c85:e7b5, 30 hops max, 60 bytes packets
1 6to4.fra1.he.net (2001:470:0:150::2) 99.130 ms 17.012 ms 16.992 ms
2 10gigabitethernet6.switch2.fra1.he.net (2001:470:0:150::1) 98.886 ms 22.923 ms 26.685 ms
3 de-cix10.net.google.com (2001:7f8::3b41:0:1) 5046.514 ms 41.821 ms 17.838 ms
4 2001:4860::1:0:abf5 (2001:4860::1:0:abf5) 155.991 ms 42.605 ms 23.773 ms
5 2001:4860::8:0:5038 (2001:4860::8:0:5038) 42.525 ms 18.071 ms 18.040 ms
6 2001:4860::1:0:ab33 (2001:4860::1:0:ab33) 599.687 ms 42.877 ms *
7 2001:4860:0:1::207 (2001:4860:0:1::207) 91.442 ms 33.767 ms 33.954 ms
8 mil02s05-in-x00.1e100.net (2a00:1450:4002:803::1000) 27.220 ms 27.124 ms 26.911 ms
root@geist:~# traceroute6 www.tudelft.nl
traceroute to www.tudelft.nl (2001:610:908:112:131:180:77:102) from 2001:0:53aa:64c:86f:f226:6c85:e7b5, port 33434, from port 55020, 30 hops max, 60 bytes packets
1 miredo.surfnet.nl (2001:610:168:a:145:220:0:46) 134.457 ms 32.323 ms 32.379 ms
2 onweer.as1101.net (2001:610:168:a::1) 84.721 ms 32.683 ms 32.503 ms
3 XE1-1-6.JNR01.Asd001A.surf.net (2001:610:f01:8152::153) 84.171 ms 33.115 ms 32.701 ms
4 AE0.500.JNR01.Asd002A.surf.net (2001:610:e08:80::81) 71.039 ms 32.797 ms 32.673 ms
5 2001:610:f02:6096::98 (2001:610:f02:6096::98) 69.960 ms * *
6 2001:610:908:112:131:180:77:102 (2001:610:908:112:131:180:77:102) 34.390 ms 34.608 ms 34.257 ms
root@geist:~# tcptraceroute6 www.tudelft.nl
traceroute to www.tudelft.nl (2001:610:908:112:131:180:77:102) from 2001:0:53aa:64c:86f:f226:6c85:e7b5, port 80, from port 54914, 30 hops max, 60 bytes packets
1 * * miredo.surfnet.nl (2001:610:168:a:145:220:0:46) 65.961 ms
2 onweer.as1101.net (2001:610:168:a::1) 101.656 ms 32.520 ms 32.738 ms
3 XE1-1-6.JNR01.Asd001A.surf.net (2001:610:f01:8152::153) 90.450 ms 43.507 ms 32.813 ms
4 AE0.500.JNR01.Asd002A.surf.net (2001:610:e08:80::81) 32.800 ms 40.499 ms 33.255 ms 5

Conceptual model of a host/1
rfc4861
Data structures :
Neighbor cache : on-link unicast address, LL
address, R/H, neighbor reachability, unanswered
probes, next scheduled NUD
Destination cache : includes both on-link and off-
link destinations. It maps the IPv6 address to the
next-hop neighbor (an entry in the neighbor
cache). This cache is update by ICMPv6 redirects.
It can contain PMTU and RTT informations.
Prefix list : a list of the prefixes received in
Router Advertisements with the on-link flag on.
The link local (fe80::) prefix is considered to be
on the list with an infinite validity timer.
Default Router List : a list of routers to which
packets can be send. Entries can be added
manually, trough router advertisements, or
DHCPv6.
Neighbor cache reachability state :
INCOMPLETE address resolution in progress
REACHABLE it is know it was reachable
STALE it is not known anymore, but nothing
will be done till new pkts sent
DELAY is no longer known to be reachable, pkt
were sent not long ago, waiting for an ULP
confirmation
PROBE is no longer known to be reachable and
NS packets are sent to verify

Conceptual model of a host/2
Next hop determination:
1. Longest prefix match against Prefix List, if
found determine if it is on-link or not,
otherwise is off-link.
2. If dest on-link then next-hop=destination,
otherwise next-hop is a router choosen from
Default Router List. Next-hop for efficiency
is not performed for every packet but its
results are stored in the Destination Cache.
Next time 1st the destination cache will be
searched for next-hop and only if not found
the normal prefix search will be started.
3. When the next-hop is known it will be
searched in the Neighbor Cache and if no
entry exist an Address Resolution (Neighbor
Solicitation) will be performed entering the
next-hop in the cache as an entry in state
INCOMPLETE.
For multicast pkts :
The destination is considered the same multicast
address and supposed on-link. The pkt is simply
sent to the multicast address on the interface.
The LL destination address is computed from the
IPv6 multicast address.

Destination
Cache
Next hop determination
Neighbour
Cache
(2)
Longest prefix
match. On-link ?
(3)
Search next-hop in NC.
If onlink, next-hop =
destination. If not found
initiates Address Resolution.
(1)
Search Destination
Cache, if found don't
perform next-hop
determination
(4)
Destination OffLink,
Select a router
Next hop determination
Default
Router List
Next-hop determination is not
performed for every connection,
but only when there is no entry in
the Destionation Cache. After
next-hop determination the entry
is inserted in the Destination
Cache.

NDP functions
1.Router discovery:host
discover router that are on an
attached link
2.Prefix discovery: nodes
discover which prefixes denote
nodes on-link
3.Parameter discovery: nodes
learn about MTU, hop limits,
etc ..
4.Address autoconfiguration:
nodes discover prefixes to be
used for address
autoconfiguation
5.Address resolution: node
discover the Link Layer address
(like ARP)
6.Next hop determination: node
determine next hop
7.Neighbor Unreachability
Detection(NUD): node can
determine if a node is still
reachable
8.Duplicate Address
Detection(DAD): node can
determine if an address is in use
9.Redirect : routers can tell nodes
a better next-hop for a destination

Different subnet model: RFC5942
IPv6 has a subnet model that is slightly different from IPv4 in
subtle ways and this resulted in some implementations not
able to interoperate. The most important difference is that
an IPv6 address isn't automatically related to an
on-link prefix ! .
In IPv4 an interface is assigned an address and a
netmask. Based on that info nodes decide which addresses
are on-link and should be contacted directly.
In IPv6 address assignement and on-link determination
are separate :
● A host can have IPv6 addresses not related to any on-
link prefix, or without knowing on-link prefixes (think
about anycasts).
● A host can have IPv6 prefixes not related to any other
address it has.
By default only the Linklocal fe80::/16 prefix is
treated as on-link.
The reception of a Prefix Information Option (PIO)
(rfc4861 on RD) with the L bit (on-Link bit) set and with a
nonzero lifetime creates an entry in the Prefix List of a node
for that interface. The same the manual configuration of an
on-link prefix (can be a /128 : host route).
All prefixes on a Prefix List of a node are considered on-link
by that node. Pkt for destinations that are considered on-link
by sender, trigger name resolution, pkt for other destinations
are forwarded to a default router (if the Default Router List is
empty then an ICMPv6 dest unreachable is sent back).
In this way Non-Broadcast Multi-Access (NBMA) is
supported.
A link can have multiple prefixes, a prefix can be assigned to
multiple links.
Host rule :
If a host gets an address trough one of the many methods, it
should not suppose a prefix derived arbitrarily from it be
treated as on-link.
E.g. : a link is assigned 2 prefixes by 2 different routers. 2
nodes can use the different prefixes for SLAAC : in IPv4
those nodes would not speak each other, in IPv6 yes, using
their link-local addresses.
.

IPv6 addreses for a ...
Router :
●
Unicast addresses
– A link-local address for each interface
– Additional global or ULA for each interface
– The loopback address ::1 for the loopback
interface
●
Anycast addresses
– A subnet router anycast for each subnet
– Additional optional anycast
● Multicast addresses
– Interface-local scope multicast all-nodes ff01::1
– Interface-local scope multicast all-routers
ff01::2
– Link-local scope multicast all-nodes ff02::1
– Link-local scope multicast all-routers ff02::2
– Site-local scope multicast all-routers ff05::2
Host:
● Unicast addresses
– A link-local address for each interface
– Additional global or ULA for each interface
– The loopback ::1 for the loopback interface
●
Anycast addresses
– Any anycast address assigned to the node
●
Multicast addresses
– Interface-local scope multicast all-nodes
ff01::1
– Link-local scope multicast all-nodes ff02::1
– The solicited node multicast for each
unicast address
– The multicast groups to which the node
subscribed

Happy eyeballs algorithm
aka FastFallback RFC6555
During the passage to IPv6, tunnels, not reliable IPv6 connections, etc can
prejudicate user experience. Therefore an algorithm was devised to mitigate the
drawbacks of dual stack users.
DNS Server Client Server
| | |
1. |<--www.example.com A?-----| |
2. |<--www.example.com AAAA?--| |
3. |---192.0.2.1------------->| |
4. |---2001:db8::1----------->| |
5. | | |
6. | |==TCP SYN, IPv6===>X |
7. | |==TCP SYN, IPv6===>X |
8. | |==TCP SYN, IPv6===>X |
9. | | |
10. | |--TCP SYN, IPv4------->|
11. | |<-TCP SYN+ACK, IPv4----|
12. | |--TCP ACK, IPv4------->|
Figure 1: Existing Behavior Message Flow
Typical browser behaviour pre rfc6555 : many seconds
wasted to try IPv6 SYNs repeatedly.
NB. konqueror works this way. At least the one now in ubuntu 15.04

Happy eyeballs/2
| | |
3. |---192.0.2.1------------->| |
4. |---2001:db8::1----------->| |
5. | | |
6. | |==TCP SYN, IPv6===>X |
7. | |--TCP SYN, IPv4------->|
8. | |<-TCP SYN+ACK, IPv4----|
9. | |--TCP ACK, IPv4------->|
10. | |==TCP SYN, IPv6===>X |
Figure 2: Happy Eyeballs Flow 1, IPv6 Broken
Solution : try both addresses at SYN time and take IPv4 if IPv6 broken :
Firefox 13, MacOSX Lion, Chrome implement it

Happy eyeballs/3
| | |
3. |---192.0.2.1------------->| |
4. |---2001:db8::1----------->| |
5. | | |
6. | |==TCP SYN, IPv6=======>|
7. | |--TCP SYN, IPv4------->|
8. | |<=TCP SYN+ACK, IPv6====|
9. | |<-TCP SYN+ACK, IPv4----|
10. | |==TCP ACK, IPv6=======>|
11. | |--TCP ACK, IPv4------->|
12. | |--TCP RST, IPv4------->|
Figure 3: Happy Eyeballs Flow 2, IPv6 Working
Try both : prefer IPv6 if it works and reset IPv4 connection
NB. On firefox you can disable the algorithm with : Enter about:config, unset
network.http.fast-fallback-to-IPv4

Coexistence of IPv4/IPv6 in DNS
This is the standard way to declare a double stack host :
ghost IN A 147.122.24.71
IN AAAA 2001:db8:12::213:45ea:3aef
Unfortunately there are many broken resolvers out there that
despite not being able to reach the Ipv6 Internet at large would try
to contact only the IPv6 address without falling back to the IPv4.
In the past many used the trick to put the ipv6 under a different
name or domain :
ghost IN A 147.122.24.71
ghost.ipv6 IN AAAA 2001:db8:12::213:45ea:3aef

IPv6 routing
Routing on the LAN :
● Is done using Router Advertisement instead of a routing protocol
– Router Discovery
– Prefix discovery

Ipv6 course

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Ipv6 course

Similaire à Ipv6 course (20)

Plus de rinnocente

Plus de rinnocente (16)

Dernier

Dernier (20)

Ipv6 course