isc.sans.edu Open in urlscan Pro
45.60.31.34  Public Scan

Form analysis
2 forms found in the DOM

Name: searchform — POST /search.html

<form id="headerSearch" name="searchform" action="/search.html" method="post">
  <input type="text" name="q" placeholder="Keyword, Domain, Port, IP or Header">
  <input type="submit" value="Search"><input type="hidden" name="token" value="769c6fd4d44f8c87e451905f5a125e7421195d04">
</form>

Name: loginform — POST /login.html

<form id="headerLogin" method="post" action="/login.html" name="loginform">
  <input type="hidden" name="token" value="769c6fd4d44f8c87e451905f5a125e7421195d04">
  <input type="text" name="email" placeholder="Email">
  <input type="password" name="pw" autocomplete="off" placeholder="Password">
  <input type="submit" value="Log In"><br>
  <a href="/register.html">Sign Up for Free!</a> &nbsp; <a href="/resetpassword.html">Forgot Password?</a>
</form>

Text Content

Threat Level: green Handler on Duty: Didier Stevens



SANS ISC: INFOSEC HANDLERS DIARY BLOG
 * SANS SITE NETWORK
   * CURRENT SITE
   * SANS INTERNET STORM CENTER
   * OTHER SANS SITES HELP
   * GRADUATE DEGREE PROGRAMS
   * SECURITY TRAINING
   * SECURITY CERTIFICATION
   * SECURITY AWARENESS TRAINING
   * PENETRATION TESTING
   * INDUSTRIAL CONTROL SYSTEMS
   * CYBER DEFENSE FOUNDATIONS
   * DFIR
   * SOFTWARE SECURITY
   * GOVERNMENT ONSITE TRAINING

INFOSEC HANDLERS DIARY BLOG



Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!


WHY I GAVE UP ON IPV6. AND NO, IT IS NOT BECAUSE OF SECURITY ISSUES.

 * 
 * 
 * 

Published: 2021-09-07
Last Updated: 2021-09-07 12:26:48 UTC
by Johannes Ullrich (Version: 1)

7 comment(s)

IPv6 adoption is growing. Around 30% of the Alexa Top 1000 websites support
IPv6. Comcast, the ISP I am using, rolled out IPv6 to every customer, and
according to some statistics, around 70% are actually using it [1]. About 35% of
traffic reaching Google uses IPv6 [2]. I have been using IPv6 myself for
probably over a decade by now. Initially via Hurricane Electric tunnels, and
later as Comcast made IPv6 available, I used the allocation provided by Comcast.
So why stop using it now?

To better understand who is using IPv6, let's "zoom in" on Google's IPv6
statistic. The graph is notably "noisy." But the reason it looks so broad isn't
noise: IPv6 usage is higher on Weekends compared to Weekdays.



The reason is pretty simple. For ISPs, IPv6 is needed in case they run out of
IPv4 address space. Currently, not a lot of enterprises or businesses are adding
IP address space. Actually, the opposite is happening: Enterprises are
dismantling datacenters and are moving them into the cloud. 

This leaves home users, particularly mobile users, as the main growth area for
IP addresses and, with that, the sole use case for IPv6. But ISPs still have to
support IPv4 access as well, often via carrier-grade NAT (cgNAT). By having to
support both IPv4 and IPv6, ISPs have not really been able to take advantage of
everything IPv6 has to offer, and implementations have been "messy."


HOW IPV6 IS SUPPOSED TO WORK

IPv6 has a lot of promise. Or should I say: IPv6 promises a lot of features. One
of the big ones is end-to-end connectivity and the end of NAT. For a home user,
NAT isn't really a bit problem. But for carriers, NAT is getting complex and
expensive. Some estimates talk about up to $40/year/user [3]. IPv6 also has the
potential to be faster, but real-world results are mixed at this point. IPv6
works best if end-user networks are assigned a /48. This may sound like an
excessive amount of addresses, but there is a reason for /48s being the "sweet
spot." First of all, the minimum network size in IPv6 is a /64. Your ISP will
typically assign you at least a /64. But this allocation can not be split into
various subnets, making it impossible to, for example, set up a distinct IoT
subnet. With IPv4, we can use NAT to create various subnets. But with IPv6, we
do not really have NAT as an option. 

Unless: If you have a /48!. A/48 is so "magic" because you have 16 bits to play
with. This allows for the use of "Prefix Translation." Yes! NAT for IPv6. The
main advantage of this over plain old NAT is that each internal IP address will
be mapped to a unique external address. But why do "NAT" in IPv6? Because you
may need to renumber... For IPv4, having your external IP address change isn't a
big deal. NAT will make the change transparent to your network. But in IPv6,
renumbering may have to happen too, and with all hosts in your network using
publicly routed IP addresses, you will need to renumber every single host in
your network. Sure... some of this can be automated... if it works.

RIPE, the European regional internet registry, suggests a "/48 for everybody" in
its "Best Current Operational Practice" document [4] . From this document:

> 4.2.1. /48 FOR EVERYBODY
> 
> This is probably the most practical way to assign IPv6 prefixes to end
> customer CPE devices. In this case everyone has a /48 prefix and advanced
> end-users are less likely to make mistakes when addressing their networks and
> devices, resulting in much less call-centre time to sort out problems. It also
> has the advantage of sharing the same prefix size as ULAs and some transition
> mechanisms, so this facilitates a direct mapping of existing customer
> addressing plans to the delegated prefix.

Sadly, ISPs have made extra money selling IP address allocations and are
unwilling to hand out /48s. IPv6 is a beautiful protocol. It removes many of the
rough edges of IPv4 and turns IPv4, a research experiment that essentially was
left running by mistake, into a global business network.

So let's look at some current IPv6 implementations I have had first-hand
experience with and why they fail.


AT&T MOBILE

All AT&T mobile phones will be assigned a /64. Devices tethered to a mobile
phone will receive addresses from this /64. This works well for mobile phones as
you are not likely to run a complex network from a mobile phone. But AT&T has a
special treat for you: NAT! All IPv6 traffic from the phone appears to be
NAT'ed. This will remove the biggest advantage of IPv6 immediately. No idea why
IPv6 would do that.


T-MOBILE MOBILE PHONE

Again, your phone will receive an IPv6 /64. T-Mobile may also take advantage of
"464 XLAT" if your phone supports it [5]. This protocol will encapsulate all
your IPv4 traffic into IPv6. T-Mobile will only "see" IPv6 traffic on its
network and NAT IPv4 at its border. Pretty neat set up but can be "messy" in
that your phone no longer has a unique IPv4 address within T-Mobile's network
(not even a unique unroutable address, but instead, 464XLAT uses a small
netblock set aside for 464-XLAT, so essentially all phones use the same IPv4
address) [6].

But from my own experience, neither T-Mobile nor AT&T allows inbound traffic to
the phone's IPv6 address. This negates some of the advantages of having a
globally routable IPv6 address.


T-MOBILE 5G HOME INTERNET

This service is still rather new, and I have only been experimenting with it for
a couple of days. But it appears to work pretty much like the T-Mobile
phone-based internet service. Your T-Mobile gateway is assigned a NAT'ed IPv4
address and a single /64. You cannot use IPv6 if you are using your own
router/firewall connected to the 5G access point, and for IPv4, you have to deal
with double/tribble NAT. Unless all of your devices are directly connected to
the access point, IPv6 is useless.

T-Mobiles gateway is also locked down and not allowing any "bridge mode" or
other configuration options.


COMCAST/XFINITY BUSINESS SERVICE

Comcast will assign business users a /56. You may connect a router to the modem,
and it may request a /59 allowing for multiple routers to be connected. But be
aware that the modem doesn't really track which router gets what /59, so after a
reboot, your router may get a different /59 (out of the /56 assigned to the
modem). Also, Comcast currently does not offer static IPv6 assignments. If you
change your modem, you will get a new /59 even if your IPv4 address range
remains the same (if you paid for a static IPv4 address). In the past, Comcast
also changed its allocation policies without notice. For example, it used to be
that the router received a /60 from the modem. Now it does receive a /59. The
route MUST request the address via DHCP, or the modem will not know how to route
it. Expiring DHCP leases or a modem reboot will break IPv6. (Comcast sometimes
reboots modems without notice for firmware upgrades). Only obtaining a /56 and
not having the ability to use special IPv6 features like mobile IP, failover to
another carrier will not work.

By default, the Comcast supplied modem will block inbound IPv6, but this is
easily adjusted (so actually a good thing to set it up secure by default). The
firewall in the modem is a bit of a joke, but well, it blocks some packets...


Comcast IPv6 Firewall Configuration Options


ALL CARRIERS: SUPPORT

So far, I have not had a successful support call regarding IPv6 with any ISP. As
far as the ISP is concerned: If IPv4 is working for you, your connection is
working, and there is no reason for them to fix anything. 


FINAL WORDS

No static IPv6 addresses, no /48 allocations, inability to do fail over to a
different carrier, stability issues, and lack of support are why I now, after
10+ years, no longer use IPv6 in my network. There are pockets where I may still
use it, but so far, there isn't really a good reason to keep IPv6 enabled.
Nothing "broke" so far. Lackluster implementations by ISPs that fix the current
issue and no/limited use of ISPs by enterprise networks and cloud providers make
it difficult to justify the time it takes. And maybe I am getting too old to
play with my network configuration all the time.

Please comment if you had your own experience with IPv6 you would like to share.

[1] https://www.worldipv6launch.org/measurements/
[2] https://www.google.com/intl/en/ipv6/statistics.html
[3] https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf
[4] https://www.ripe.net/publications/docs/ripe-690
[5] https://datatracker.ietf.org/doc/html/rfc6877
[6] https://www.internetsociety.org/resources/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Keywords: att comcast ipv6 tmobile xfinity
7 comment(s)
Join us at SANS! Attend Intrusion Detection In-Depth with Johannes Ullrich in
Online starting Oct 11 2021

   
 * previous
 * next

Top of page
×

Diary Archives
   
 * Contact Us
   * Contact Us
   * About Us
   * Handlers
 * Diary
 * Podcasts
 * Jobs
 * Tools
   * DShield Sensor
   * DNS Looking Glass
   * Honeypot (RPi/AWS)
   * InfoSec Glossary
   * Fightback
 * Data
   * HTTP Header Activity
   * TCP/UDP Port Activity
   * Port Trends
   * Presentations & Papers
   * SSH Scanning Activity
   * SSL CRL Activity
   * Suspicious Domains
   * Threat Feeds Activity
   * Threat Feeds Map
   * Useful InfoSec Links
   * Weblogs
   * Research Papers
 * Forums
   * Auditing
   * Diary Discussions
   * Forensics
   * General Discussions
   * Industry News
   * Network Security
   * Penetration Testing
   * Software Security

--------------------------------------------------------------------------------

Questions? Feedback?
Use our contact form or
report bugs here
For interactive help and to chat with other users, try our Slack group.



 * YouTube
 * Twitter
 * LinkedIn
 * ISC Feed

 * Shop
 * Link To Us
 * About Us
 * Handlers
 * Privacy Policy
 * Back To Top

Developers: We have an API for you!