IPv6 Foundation Part 12: IPv6 Security & Tunneling

IPv6 Foundation Part 12 - IPv6 Security and Tunneling
IPv6 Secu­ri­ty explained in-depth, includ­ing Best Prac­tices for your Net­work! IPv6 Attacks, Tun­nel­ing, Fire­wall! All your answers right here!

Table of Con­tents

About this course

So you are inter­est­ed in IPv6, which is absolute­ly great!

IPv6 is not only the future of net­work­ing, it is already here today! All the big play­ers on the Inter­net are already IPv6 enabled and it is now time for you to join the par­ty!

This course cov­ers all major aspects of the new Inter­net Pro­to­col and what changed, com­pared to IPv4. You will under­stand the fun­da­men­tals and be ahead of your peers that are still on the sink­ing ship of IPv4! As of today, there are no IPv4 address­es left and we have no oth­er option but to go ahead and deploy IPv6.

IPv6 Act Now

IPv6 Foun­da­tion Part 12: IPv6 Secu­ri­ty & Tun­nel­ing

This sec­tion cov­ers all the crit­i­cal things you need to know about IPv6 secu­ri­ty. Some things are com­mon sense, some are iden­ti­cal to mea­sures for IPv4 and some are new. Read through the fol­low­ing chap­ters care­ful­ly and make sure you fol­low all best prac­tices.

IPv4 Secu­ri­ty Best Prac­tices you need to fol­low

  1. Always dis­able all net­work ser­vices that are not need­ed.
  2. Always dis­able all net­work inter­faces that are not need­ed.
  3. Only use switch­es with hard­ware for­ward­ing, as soft­ware for­ward­ing can fail
in case of a DDOS.
  4. Lim­it all net­work man­age­ment access to your net­work infra­struc­ture (use Access Lists etc.)
  5. Always Lim­it man­age­ment pro­to­cols like SNMP as much as pos­si­ble to only the need­ed des­ti­na­tions.

IPv6 Secu­ri­ty Best Prac­tices you need to fol­low

The first rules are shared between IPv4 and IPv6, so they might ring a bell. Always make sure to imple­ment cur­rent soft­ware ver­sions, check for bug fix­es and keep con­fig­u­ra­tion on a lev­el you ful­ly under­stand and can main­tain and trou­bleshoot. Addi­tion­al­ly:

  • Always dis­able all net­work ser­vices that are not need­ed.
  • Always dis­able all net­work inter­faces that are not need­ed.
  • Only use switch­es with hard­ware for­ward­ing, as soft­ware for­ward­ing can fail
in case of a DDOS.
  • Lim­it all net­work man­age­ment access to your net­work infra­struc­ture (use Access Lists etc.)
  • Always Lim­it man­age­ment pro­to­cols like SNMP as much as pos­si­ble to only the need­ed des­ti­na­tions.
  • Dis­able router adver­tise­ments on links that are not direct­ly con­nect­ed to clients.

IPsec and its Inte­gra­tion into IPv6

The Inter­net Pro­to­col Secu­ri­ty suite, in short IPsec han­dles encryp­tion for IPv6.

It is avail­able for IPv4 and IPv6.

With IPv4, the imple­men­ta­tion of IPsec was option­al
 but with IPv6 it is now manda­to­ry and the nec­es­sary fields are reserved in the head­er.

Oth­er than before, IPsec VPN is now pos­si­ble on all IPv6-capa­ble devices!

IPsec also han­dles authen­ti­ca­tion of rout­ing pro­to­cols as you have learned before.

This Wikipedia arti­cle on IPsec is well-writ­ten and goes in depth.

All the Rec­om­mend­ed IPv6 Secu­ri­ty Fea­tures you should imple­ment to stay safe!

  • Fire­walls in gen­er­al work like with IPv4 and have to be
planned and engi­neered with just the same care!
  • The fol­low­ing ICMP mes­sage types should always be per­mit­ted
as of RFC4890 (Rec­om­men­da­tions for Fil­ter­ing ICMPv6 Mes­sages in Fire­walls):
    • Des­ti­na­tion Unreach­able (Type 1)
    • Pack­et Too Big (Type 2) -> need­ed for Path MTU Dis­cov­ery (PMTUD)
    • Time Exceed­ed (Type 3, Code 0) -> need­ed for tracer­oute
    • Para­me­ter Prob­lem (Type 4, Code 1+2) -> Des­ti­na­tion Options, Exten­sion Head­ers
    • Echo Request (Type 128) -> Ping
    • Echo Response (Type 129) -> Ping Reply
Rec­om­mend­ed IPv6 Secu­ri­ty Fea­tures for Cam­pus Net­works


IPv6 Recommended Security Features

Rout­ing Authen­ti­ca­tion


Rout­ing Authen­ti­ca­tion
Uni­cast RPF (Reverse Path For­ward­ing)
Default Gate­way Authen­ti­ca­tion
IPv6 ND Bind­ing Lim­it
IPv6 Device Track­ing


IPv6 Snoop­ing
IPv6 ND Inspec­tion
IPv6 ND Bind­ing Lim­it
IPv6 Device Track­ing
IPv6 RA Guard
DHCPv6 Guard
IPv6 Port-Based ACLs
Traf­fic Storm Con­trol
Port Secu­ri­ty
Pri­vate VLANs

Secu­ri­ty Attacks against IPv6 you need to know about

In order to secure your net­work, you need to know what com­mon IPv6 attacks can be used against IPv6 and how to mit­i­gate them.

Let’s jump right in:

IPv6 Neigh­bor Dis­cov­ery ND cache exhaus­tion Attack

Attack vec­tor #1:

A host sends traf­fic to many dif­fer­ent tar­get address­es in the same net­work or pre­fix (e.g. with an nmap port scan) and caus­es a neigh­bor cache over­flow!

IPv6 Secu­ri­ty fix:

The IPv6 Neigh­bor Dis­cov­ery ND res­o­lu­tion cache should be lim­it­ed, sim­i­lar to rate lim­it­ing


Attack vec­tor #2:

A mali­cious host announces a lot of IPv6 address­es via Neigh­bor Adver­tise­ment (NA). This can cause a neigh­bor cache over­flow.

IPv6 Secu­ri­ty fix:

Most cur­rent oper­at­ing sys­tems ignore unso­licit­ed Neigh­bor Adver­tise­ment (NA) mes­sages already.

IPv6 Mali­cious Router Adver­tise­ments Attack

Attack vec­tor:

A mali­cious host sends Router Adver­tise­ments (RA) and announces itself as the (pre­ferred) router. This can lead to a man in the mid­dle attack, if all traf­fic is sent via the mali­cious host and can be altered or record­ed by the attack­er.

IPv6 Secu­ri­ty fix:

Enable Router Adver­tise­ment Guard “RA Guard” (RFC6105) on the access switch toward clients. Switch ports become role based by RA Guard, so the switch drops Router Adver­tise­ments on non-marked non-router ports.

IPv6 DHCPv6 spoof­ing Attack

Attack vec­tor:

A mali­cious host dis­trib­utes DHCPv6 address­es to clients. This can harm net­work secu­ri­ty and can cre­ate a man in the mid­dle attack, if wrong infor­ma­tion is pre­sent­ed to real clients.

IPv6 Secu­ri­ty fix:

Enable DNS Shield (RFC7610) or “DHCPv6 Guard” (Cis­co pro­pri­etary) on the access switch fac­ing all clients. The switch ports become role based and the switch will drop all DHCPv6 adver­tise­ments on non-marked non-serv­er ports.

IPv6 source address spoof­ing (backscat­ter) Attack

Attack vec­tor:

A mali­cious host sends pack­ets with a spoofed (incor­rect) source address. This can cause reply pack­ets to be sent to this fake source address, which might be the address of a real host. This is some­times called backscat­ter attack, because the vic­tim’s host can receive over­whelm­ing traf­fic from those un solicit­ed replies.

IPv6 Secu­ri­ty fix:

Enable Reverse Path For­ward­ing (RPF) on your Lay­er 3 switch­es and routers. This will dis­card pack­ets that are com­ing in on an inter­face where the source address is not reach­able from.

IPv6 Rout­ing Pro­to­col Attacks

Attack vec­tor:

A mali­cious host injects wrong rout­ing infor­ma­tion into the rout­ing domain. This can cause all kinds of prob­lems, from man in the mid­dle attacks to just bro­ken net­work­ing over­all, with poor chances to trou­bleshoot and find.

IPv6 Secu­ri­ty fix:

  1. Secure the rout­ing pro­to­cols OSPFv3, PIM (Mul­ti­cast Rout­ing Pro­to­col) and RIP­ng using IPsec (with IPv6 Exten­sion Head­ers).
  2. Secure the rout­ing pro­to­cols EIGRP, BGP, IS-IS, HSRP, and VRRP using MD5 authen­ti­ca­tion.

IPv6 Unwant­ed Tun­nel­ing Attacks

Attack vec­tor:

A mali­cious host builds an unwant­ed tun­nel into the Inter­net and opens the net­work to the out­side, bypass­ing all IPv6 fire­walls. This can also mean oth­er hosts from the out­side are able to gain full access to the inter­nal net­work, bypass­ing all fire­walls.

IPv6 Secu­ri­ty fix:

  1. Fil­ter IP pro­to­col 41 on your fire­walls. This dis­ables all tun­nel­ing for 6in4, 6to4, 6rd and ISATAP tun­nels. In my opin­ion, this kind of tun­nel­ing is not need­ed any­more, def­i­nite­ly not in an enter­prise or pro­duc­tion envi­ron­ment.
  2. Fil­ter access to the offi­cial 6to4 relay address: on your fire­walls.
  3. Fil­ter the Tere­do pro­to­col using UDP/3544 and Tun­nel Set­up Pro­to­col using UDP/3653 on your fire­walls.

Tun­nel­ing IPv6 Gate­way to Gate­way

Tun­nel­ing was a major fea­ture in the ear­ly days of IPv6 because the Inter­net was not end-to-end IPv6 capa­ble, since most providers imple­ment­ed IPv6 late.

To con­nect the many IPv6 islands, it was nec­es­sary to imple­ment some tun­nels over IPv4.

Today this is nei­ther nec­es­sary nor rec­om­mend­ed, because native IPv6 con­nec­tiv­i­ty is work­ing well and should be pre­ferred. If there is no native IPv6 con­nec­tiv­i­ty, then native IPv4 con­nec­tiv­i­ty should strong­ly be pre­ferred over tun­nel­ing.

The fol­low­ing part is short­ened because I find IPv6 tun­nel­ing dep­re­cat­ed but want you to still know what kinds were avail­able:

  • sta­t­ic IPv6-in-IPv4 (6in4) tun­nel
  • sta­t­ic GRE tun­nel
  • 6to4
  • IPv6 Rapid Deploy­ment (6rd)
  • DS-Lite
  • LISP

IPv6-in-IPv4 (6in4) Tun­nel­ing

  • IPv6-in-IPv4, com­mon­ly called 6in4 is a sta­t­ic tun­nel.
  • Both tun­nel ends have IPv4 address­es con­fig­ured.
  • IPv6 address­es are sta­t­i­cal­ly con­fig­ured on the tun­nel.
  • IPv6 pack­ets are encap­su­lat­ed in IPv4 before being sent via the IPv4-only infra­struc­ture.

GRE Tun­nel for IPv6 (Gener­ic Rout­ing Encap­su­la­tion) explained

A GRE Tun­nel (Gener­ic Rout­ing Encap­su­la­tion) is a com­mon way to tun­nel all kinds of traf­fic. It is still used today.

  • GRE is a sta­t­ic tun­nel.
  • Both Tun­nel ends have IPv4 address­es con­fig­ured.
  • IPv6 address­es are con­fig­ured on top of the tun­nel
  • IPv6 pack­ets are encap­su­lat­ed in GRE pack­ets (pro­to­col 47) before being sent over the IPv4-only tran­sit path
GRE IPv6 Tunneling

6to4 IPv6 Tun­nel­ing

6to4 is an auto­mat­ic tun­nel. It can offer access to the pub­lic IPv6 Inter­net via IPv4-only infra­struc­ture.

  • Pub­lic 6to4 relay servers are avail­able
  • There are major risks, such as no sup­port for and no con­trol over the pub­lic tun­nel end­points. This can lead to seri­ous IPv6 secu­ri­ty issues (man in the mid­dle, traf­fic log­ging, …)
  • The oper­a­tor of a pub­lic relay is unknown.
  • Per­for­mance is not known and not guar­an­teed.
  • Sub­op­ti­mal rout­ing is pos­si­ble and even prob­a­ble

Sum­ma­ry: don’t do it. Read RFC3964 Secu­ri­ty Con­sid­er­a­tions for 6to4 for more infor­ma­tion.

6rd — IPv6 Rapid Deploy­ment Tun­nel­ing

6rd — IPv6 Rapid Deploy­ment is anoth­er migra­tion strat­e­gy for fast IPv6 deploy­ments over IPv4 only back­end or tran­sit infra­struc­ture.

The 6rd mech­a­nism was defined in RFC5569 and is based on 6to4 meth­ods.

It enables Inter­net Ser­vice Providers or ISPs to deploy IPv6 quick­ly to cus­tomers, with­out the need for full end-to-end IPv6 sup­port in Access and Aggre­ga­tion Lay­ers.

The 6rd pre­fix is addressed from the provider’s own IPv6 pre­fix.

Tun­nel­ing IPv6 Host to Gate­way

The fol­low­ing Host to Gate­way Tun­nel­ing meth­ods enable IPv4-only clients to auto­mat­i­cal­ly estab­lish con­nec­tiv­i­ty to an IPv6 gate­way serv­er and enable IPv6 con­nec­tiv­i­ty over this tun­nel.

These meth­ods were avail­able:

  • Tere­do
  • Tun­nel Bro­ker

Tere­do IPv6 Tun­nel­ing for Clients

Tere­do was devel­oped by Microsoft and defined in RFC4380.

  • It was imple­ment­ed since Win­dows XP and Win­dows Serv­er 2008.
  • Tere­do clients are addressed from sta­t­ic pre­fix 2001::/32.
  • IPv6 pack­ets are encap­su­lat­ed in UDP to enable sup­port for NAT that might be in place between client and gate­way serv­er. NAT was com­mon in IPv4 deploy­ments espe­cial­ly in res­i­den­tial access sce­nar­ios such as DSL.
Teredo IPv6 Tunneling

ISATAP (Intra-Site Auto­mat­ic Tun­nel Address­ing Pro­to­col) for Clients

ISATAP or in long form the Intra-Site Auto­mat­ic Tun­nel Address­ing Pro­to­col enables host to router com­mu­ni­ca­tion and was defined in RFC5214.

  • IPv6 pack­ets are encap­su­lat­ed in IPv4 pack­ets to be sent over IPv4-only infra­struc­ture.
  • There is no sup­port for IPv6 mul­ti­cast.


Steps for ISATAP:

  1. The ISATAP client gen­er­ates a Link-Local IPv6 address from its IPv4 address.
  2. The ISATAP clients sends a Router Solic­i­ta­tion (RS) mes­sage to the upstream ISATAP router. The ISATAP serv­er address is either sta­t­i­cal­ly con­fig­ured or received by DNS lookup of isatap.${domain}.
  3. The ISATAP serv­er sends a Router Adver­tise­ment mes­sage (RA) to the learned IPv4 address of the client.
  4. The ISATAP client gen­er­ates an IPv6 address from the Router Adver­tise­ment mes­sage.
  5. IPv6 traf­fic is always sent via the ISATAP router (includ­ing traf­fic to oth­er ISATAP clients) -> This can lead to a seri­ous bot­tle­neck and poor per­for­mance.
ISATAP IPv6 Tunneling

Tun­nel Bro­ker & SixXS IPv6 Tun­nel­ing for Test­ing

Most­ly for pow­er users at home, or to try out IPv6, there were two Tun­nel Bro­ker options avail­able in the past:

  1. tunnelbroker.net by Inter­net ser­vice provider Hur­ri­cane Elec­tric (HE) and
  2. SixXS

Both sites had dif­fer­ent tun­nel­ing mech­a­nisms avail­able. SixXS has since been shut down as of 2017-06-06.

The Tun­nel from client to tun­nel bro­ker serv­er is
 estab­lished over the exist­ing IPv4 net­work. Instal­la­tion was fair­ly sim­ple and the ser­vice was (and is in the case of tunnelbroker.net) good enough to test dri­ve IPv6 from home, if you have no native con­nec­tiv­i­ty from your ISP yet.

SixXS IPv6 Tunnel Broker

Tun­nel­ing IPv6 over IPv6 — Just use GRE

To tun­nel IPv6 traf­fic over IPv6 infra­struc­ture, the most com­mon and best prac­tice approach is to use a sta­t­ic GRE (Gener­ic Rout­ing Encap­su­la­tion) tun­nel.

  • Both tun­nel ends are con­fig­ured with IPv6 address­es.
  • IPv6 address­es are con­fig­ured on top of the tun­nel.
  • You can secure the tun­nel option­al­ly with IPsec.
GRE Tunneling IPv6 over IPv6

Tun­nel­ing IPv4 over IPv6 — GRE is best

The last tun­nel­ing option is maybe for future use. Imag­ing an IPv6 Inter­net, which still has some old IPv4 islands, which are not con­nect­ed to each oth­er any­more. Poor them!

They should be con­nect­ed via IPv4 over IPv6 using a sta­t­ic Gener­ic Rout­ing Encap­su­la­tion (GRE) tun­nel:

  • The tun­nel ends are con­fig­ured with IPv6 address­es.
  • IPv4 address­es are con­fig­ured on top of the tun­nel.
  • You can secure the tun­nel option­al­ly with IPsec.
GRE Tunneling IPv4 over IPv6

Thank You

Thank you for attend­ing the Orig­i­nal IPv6 Foun­da­tion Mas­ter Class! You can book­mark this site to use it as a quick ref­er­ence in case you need to re-read some­thing and you can share this page to social media and your friends and col­leagues. Stay tuned to this blog for more in-depth sto­ries like this one.

Rec­om­mend­ed Resources for addi­tion­al read­ing

Apart from the links through­out this course I rec­om­mend the fol­low­ing resources for addi­tion­al infor­ma­tion:

  1. The Inter­net Soci­ety (ISOC) IPv6 Por­tal
  2. Test your IPv6 con­nec­tiv­i­ty on test-ipv6.com
  3. The offi­cial IANA list of assigned IPv6 address space is very inter­est­ing
  4. The Google IPv6 deploy­ment sta­tis­tics
  5. The RIPE NCC IPv6 work­ing group and mail­ing list

Book rec­om­men­da­tions on IPv6

I can rec­om­mend the fol­low­ing 3 books (Ama­zon refer­ral links) which I enjoyed read­ing:

This con­cludes IPv6 Foun­da­tion Part 12: IPv6 Secu­ri­ty & Tun­nel­ing of the orig­i­nal IPv6 Foun­da­tion Mas­ter Class.

Pre­vi­ous Part: IPv6 Foun­da­tion Part 11: IPv6 Rout­ing

Next Part: IPv6 Foun­da­tion Part 13: IPv6 Inter­net Con­nec­tion Plan­ning

Share this post

Share on pocket
Share on reddit
Share on facebook
Share on twitter
Share on linkedin
Share on xing