[Openswan dev] Qustion about Nat-t
Michael H. Warfield
mhw at WittsEnd.com
Tue Mar 3 13:52:06 EST 2009
On Sun, 2009-03-01 at 16:38 -0500, Paul Wouters wrote:
> On Sun, 1 Mar 2009, John Denker wrote:
> > *) NAT is a kludgey way of extending the IPv4 address space.
> > IPv6 is an incomparably better way of extending the IPv4
> > address space.
> > *) A basic principle of engineering is to aim for the moving
> > target. NAT is the way of the past. The future will be
> > more and more IPv6.
> The move to more ipv6 will only happen with more 6to4 and 4to6
> NAT's, and horribly DNS kludges to make ipv4-only systems talk
> to ipv6-only systems and visa versa.
According to a recent Goggle experiment, where they "enrolled" a random
sampling of visitors to their site into an IPv6 experiment, the US now
ranks 5th in percentage of clients who will preferentially and
successfully use IPv6 if offered. That was behind Russia, Norway,
France, and the Ukraine. This was largely thanks to Mac's and Airport
Extreme base stations which comprised half of the US traffic that worked
and utilized IPv6. I'm sure the client users never even recognized it
was happening. Admittedly, the absolute percentages were very small
(.45% of US clients) but still not bad for clients who have no idea what
it is and no incentive to turn it on and it's just there out of the box
in arbitrary environments. And that's client side. That says nothing
of servers deployed with IPv6 enabled.
As far as DNS kludges go, totd (the Trick Or Treat Daemon) appeared on
the survey of DNS servers as far back as 2005 with over 600
instantiations detected on the net. Totd is notable that it is only
used for IPv6 only networks to provide the DNS kludge you describe.
Proxy servers of varying types take care of the connect side of the
> Welcome to the real world, Neo.
Real world (these are from my active BGP peering sessions)....
BGP IPv4 right now:
Sooo... The core gateways on the Internet are currently routing 1.36
billion IPv4 unicast host addresses (some of which can be NAT'ed
networks) and requiring almost 170,000 routes to do it (the blocks are
the routes aggregated down to the minimum routing set - IPv4 doesn't
like to aggregate very well).
BGP IPv6 right now:
Total networks: 1941173944
Total routes: 1497
Those are full /48 networks. The core gateways are routing 1.94
billion IPv6 /48 networks and requiring only a tad less that 1500 routes
to do it.
More IPv6 /48 networks currently routable (whether they exist or not)
than IPv4 /32 routable host addresses (whether they exist or not). Oh,
and I should note, those IPv6 networks are production space only. I
don't include the 2002::/16 6to4 space or the 2001::/32 Teredo space, or
any other transition space or address space outside of the global
Those are from live BGP feeds (obviously, that from my peering view and
may vary depending on what BGP peer you are accessing or looking glass
you are querying).
Obviously, not all of those IPv6 networks are in use. In fact, it's
probably a small percentage (or the providers would have already
requested more - they're cheap and plentiful). But, not all of those
IPv4 addresses are populated either. It's very hard to tell just what
the utilization percentage is on either and I will concede the
percentage is very likely to be significantly higher on v4 that v6.
Still... This is real world. It really is out there and it really
does work and people really are using it.
> > Really? Do you actually know of any home gateways that will
> > a) forward IKE and ESPinUDP, but
> > b) not properly terminate SIT tunnels, and
> > c) not even forward SIT packets?
> > If you know of any such, I'd like to hear about it. I don't
> > actually know of any. I'd be astonished if they made up 90%
> > of the market. I'd be mildly surprised if they covered even
> > 10% of the Openswan users.
> How do you set this up on a Windows laptop or Windows Mobile
> telephone, without installing additional software and
> Administrative permissions? 90% of Openswan users have an
> openswan server with incoming Windows and OSX clients.
1) Most Windows users (unfortunately) have administrative rights and
IPv6 is trivial to set up on Windows if it isn't already set up (below).
Native IPv6 autoconfigs (stateless autoconf) where it is available.
6to4 autoconfs based on its IPv4 address. Teredo negotiates its address
from the Miscrosoft Teredo servers (which are active and working VERY
well at this time). No user setup required on Windows. If it's there,
it sets itself up.
2) Several ISP's in the US have IPv6 now available for some degree of
difficulty (Verio, Sprint, MCI, Speakeasy). Not sure why Comcast isn't
providing IPv6 yet, since it's using IPv6 to control settop boxes and
cablemodems (Nanog presentation from a couple years ago) so they've got
it in their infrastructure.
3) You can enable IPv6 on Windows XP (SP1 or higher) with a few mouse
clicks (no more that 6) and you don't have to reboot the system. IPv6
is enabled, 6to4 is enabled, and Teredo is enabled.
4) What puzzles a LOT of us security folks is that too many XP boxes
are turning up with IPv6 enabled for no apparent reason. Technotard
users have no idea how it became enabled but there it is and they swear
THEY DIDN'T DO IT. It isn't something coming down from Microsoft that
way. This is a puzzle that's been going on for several years with no
5) Windows Vista has it enabled and you can not turn it off. It breaks
things if you do.
6) Windows 7 will have it enabled and you will not be able to turn it
off. Things will break and it will not be supported.
7) Most (if not all) Linux distros have IPv6 enabled and it's getting
harder and harder (intentionally) to disable it or remove it. I would
rate it above the average end users (even average Linux end users)
technical ability to remove IPv6 from their Linux systems.
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/dev/attachments/20090303/d99d2dfd/attachment.bin
More information about the Dev