As more and more cool IPv6 applications and services are becoming
available, I converted the former FAQ entry we had on this into a more
easily found/remembered page.
I am spamming this to NANOG, as there is bound to be ISP's out there
and other service providers who might have something cool to add to
that list. In case you do have some, don't hesitate to spam me back
with them and I'll add them to the list so that everybody can enjoy them.
As a current special, for the folks who are politically inclined, you
might be interested in the G8, try:
vlc http://g8tv.etherkiller.de:8000/g8-tv.ogg
For a nice TV stream of the event.
I am spamming this to NANOG, as there is bound to be ISP's out there
and other service providers who might have something cool to add to
I have plans to use IPv6 on people's ADSL so they can subscribe to
multicast music streaming from the major label catalogues we have
licensed for playlouder msp.
From the page I spammed:
8<--------------------
Multicast IPv6
Some of the SixXS PoPs support Multicast IPv6, see the separate
Multicast Support FAQ for more information. More information and the
possibilities of Multicast can be found on m6bone. One could also take
a look at Radio.Unfix.
---------------------->8
And of course never forget the marvelous VideoLAN Client (VLC) and
there are a lot of other tools available that can do similar things.
It is one of the main reasons why we have, at least experimental,
multicast supported by various SixXS PoPs. The overlay nature of
Tunnel Broker setups, and relatively small scale, make that possible.
Larger setups, like at ISP's, will be quite a bit more troublesome,
which is also one of the reasons that Multicast is still marked
experimental, as I still need to finalize the code for doing it in a
scalable manner...
Using ECMH (http://unfix.org/projects/ecmh/) or mrd6, which copied
that same system, getting IPv6 Multicast connectivity is relatively
easy. Hooking up to the m6bone can be a bit difficult, but definitely
possible. Talk to the folks at the m6bone lists
(http://www.m6bone.net) and they will get you sorted for sure.
Something quite cool is that the Holy See (aka The Vatican is
streaming various things onto the m6bone reaching a lot of people that
way.
I was doing some searching and came across the following slides
from Gert on his operational experiences with IPv6. Not sure if others
are interested, but it's worthwhile to take a few moments to look at.
As more and more cool IPv6 applications and services are becoming
available, I converted the former FAQ entry we had on this into a more
easily found/remembered page.
I was doing some searching and came across the following slides
from Gert on his operational experiences with IPv6. Not sure if others
are interested, but it's worthwhile to take a few moments to look at.
In answer to two questions at the end of this document:
� what are enterprises waiting for?
� should we ditch IPv6, and live with IPv4 + NAT forever?
Personally I hate NAT. But I currently work in a large enterprise environment and NAT is suprisingly popular. I came from a service provider background and some of the attitudes I've discovered towards private addresses in enterprise environments are quite surprising. Aside for the usual proponents of using NAT to hide your internal address infrastructure (which security always seem to insist upon) quite a popular design rule of from seems to be "Only carry public addresses on the public Internet and only carry private addresses on your private network"
If an Enterprise doesn't have a great deal for IP addresses that need to be routed on the public internet, and they thing that NAT is a _good_ design choice, it seems to me that they don't have a great deal of pressure to move to IPv6.
In fact, and call me crazy, but I can't help but wonder how many enterprises
out there will see IPv6 and its concept of "real IPs for all machines,
internal and external!" and respond with "Hell No."
Anyone got any numbers for that? I'm happy to admit I don't.
In fact, and call me crazy, but I can't help but wonder how many enterprises
out there will see IPv6 and its concept of "real IPs for all machines,
internal and external!" and respond with "Hell No."
Anyone got any numbers for that? I'm happy to admit I don't.
No numbers, but the customers I talked to usually have the feeling that
public IP addresses on their machines seems to imply publicly (and thus
unprotected) reachability for those machines. They don't understand the
difference between NAT and stateful firewalls...
This is what leads to the "Hell No" attitude in my case. Educating them
about security seems the only solution.
I think that rather than attempting to educate their customers about security firewall vendors will probably just sell a NAT capable IPv6 firewall. It's the path of least resistance to profit. (A lot of mainstream vendors have helped push the idea that NAT is synonymous with firewalling. Take the Cisco PIX as an example, where up until very recently you had to configure NAT to allow traffic through the device.)
Even people I have spoken that understand the difference between firewalling/reachability and NATing are still in favour of NAT. The argument basically goes "Yes, I understand that have a public address does not neccessarily mean being publically reachable. But having a private address means that [inbound] public reachability is simply not possible without explicit configuration to enable it". i.e. NAT is seen as a extra layer of security.
Personally I hate NAT. But I currently work in a large enterprise
environment and NAT is suprisingly popular. I came from a service
provider background and some of the attitudes I've discovered towards
private addresses in enterprise environments are quite surprising. Aside
for the usual proponents of using NAT to hide your internal address
infrastructure (which security always seem to insist upon) quite a
popular design rule of from seems to be "Only carry public addresses on
the public Internet and only carry private addresses on your private
network"
If an Enterprise doesn't have a great deal for IP addresses that need to
be routed on the public internet, and they thing that NAT is a _good_
design choice, it seems to me that they don't have a great deal of
pressure to move to IPv6.
In fact, and call me crazy, but I can't help but wonder how many enterprises
out there will see IPv6 and its concept of "real IPs for all machines,
internal and external!" and respond with "Hell No."
Anyone got any numbers for that? I'm happy to admit I don't.
Hence the discussion of site-local (dead), ula, ula-c etc.
However widespread use of private address space in ipv4 costs people
huge amounts of money when you have to merge the business processes of
two or more large enterprise networks.
Even people I have spoken that understand the difference between firewalling/reachability and NATing are still in favour of NAT. The argument basically goes "Yes, I understand that have a public address does not neccessarily mean being publically reachable. But having a private address means that [inbound] public reachability is simply not possible without explicit configuration to enable it". i.e. NAT is seen as a extra layer of security.
I want NAT to die but I think it won't.
Far too many "security" folks are dictating actual implementation details and that's fundamentally wrong.
A security policy should read "no external access to the network" and it should be up to the network/firewall folks to determine how best to make that happen. Unfortunately many security policies go so far as to explicitly require NAT.
Don't forget that the reason NAT works to the degree that it does today is because of all the workarounds in applications or protocol-specific workarounds in the NATs (ALGs). In IPv6, you don't have any of this stuff, so IPv6 NAT gets you nowhere fast with any protocol that does more than something HTTP-like. (Yes, I've tried it.)
If people want to have their boxes on unroutable IPv6 space, my advice would be to forget NAT and do proxying instead. Proxying also has the advantage that doesn't care about the difference between IPv4 and IPv6, a dual stack proxy gives you access to both. Obviously proxying doesn't work for certain classes of applications, but I should hope that's the point. If you want to be on private address space and still enjoy a good deal of (peer-to-peer) connectivity (= NAT), PLEASE do yourself and the people you want to communicate with a favor and stay in IPv4.
In fact, and call me crazy, but I can't help but wonder how many enterprises
out there will see IPv6 and its concept of "real IPs for all machines,
internal and external!" and respond with "Hell No."
That's an education problem. There's no security gain from not having real
IPs on machines. Any belief that there is results from a lack of understanding.
Anyone got any numbers for that? I'm happy to admit I don't.
Nope.
Hence the discussion of site-local (dead), ula, ula-c etc.
Site-Local sort of provided that, but, as pointed out, dead.
ULA-random sort of provides it, except that ULA-random only provides
likely uniqueness and so really is the worst of both problems. There's not
enough guarantee of collision to really prevent it from getting routed, and,
there's not enough of a guarantee of uniqueness to make organizations
worried about such things comfortable with it.
ULA-C is just Provider-Independent Real addresses with a label stuck
on them that says "These aren't the droids you're looking for, move along".
Really, the only thing that distinguishes ULA-C from PI is mindset and
router configuration. The former is known to vary in unpredictable manners.
The latter is known to vary with the application of $$$.
However widespread use of private address space in ipv4 costs people
huge amounts of money when you have to merge the business processes of
two or more large enterprise networks.
Yep. Hence the v6 concept of real addresses everywhere. People seem to
have forgotten that private addresses and NAT were a hack designed to
cope with a situation that v6 is supposed to actually solve. I admit v6 does
not completely solve the problem (at least not yet), but, it solves enough of
it that we shouldn't be clinging to the v4 hacks that got us by as we move to
v6.
There's no security gain from not having real IPs on machines.
Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people
are liable to start believing it's true :-).
*No* security gain? No protection against port scans from Bucharest?
No protection for a machine that is used in practice only on the
local, office LAN? Or to access a single, corporate Web site?
Shall I do the experiment again where I set up a Linux box
at an RFC1918 address, behind a NAT device, publish the root
password of the Linux box and its RFC1918 address, and invite
all comers to prove me wrong by showing evidence that they've
successfully logged into the Linux box? When I last did this,
I got a handful of emails, some quite snide, suggesting I was
some combination of ignorant, stupid, and reckless; the Linux
box for some reason remained unmolested.
Perhaps you should run a corresponding experiment whereby you set up a linux box with a globally-unique address, put it behind a firewall which blocks all incoming traffic to that box, and issue a similar invitation.
There's no security gain from not having real IPs on machines.
Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people
are liable to start believing it's true :-).
Maybe because it _IS_ true.
*No* security gain? No protection against port scans from Bucharest?
No protection for a machine that is used in practice only on the
local, office LAN? Or to access a single, corporate Web site?
Correct. There's nothing you get from NAT in that respect that you do
not get from good stateful inspection firewalls. NONE whatsoever.
Shall I do the experiment again where I set up a Linux box
at an RFC1918 address, behind a NAT device, publish the root
password of the Linux box and its RFC1918 address, and invite
all comers to prove me wrong by showing evidence that they've
successfully logged into the Linux box? When I last did this,
I got a handful of emails, some quite snide, suggesting I was
some combination of ignorant, stupid, and reckless; the Linux
box for some reason remained unmolested.
That doesn't prove that NAT had anything to do with the security.
NAT implies stateful inspection. I could conduct the exact same
experiment with a Linux box behind a stateful inspection firewall
with legitimate addresses and achieve the exact same result.
NAT did nothing for you. Stateful inspection is where you got your
security. I'm so tired of people who fail to understand that NAT has
nothing to do with security, because they forget that stateful inspection
is required in order to make NAT work. However, NAT is not required
for stateful inspection to work.
Shall I do the experiment again where I set up a Linux box
at an RFC1918 address, behind a NAT device, publish the root
password of the Linux box and its RFC1918 address, and invite
all comers to prove me wrong by showing evidence that they've
successfully logged into the Linux box?
Perhaps you should run a corresponding experiment whereby you set up a linux box with a globally-unique address, put it behind a firewall which blocks all incoming traffic to that box, and issue a similar invitation.
Do you think the results will be different?
I fear a somewhat more cynical person could interpret the results of such an experiment to mean that NAT is as good as a firewall
There's no security gain from not having real IPs on machines.
Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people
are liable to start believing it's true :-).
*No* security gain? No protection against port scans from Bucharest?
No protection for a machine that is used in practice only on the
local, office LAN? Or to access a single, corporate Web site?
Shall I do the experiment again where I set up a Linux box
at an RFC1918 address, behind a NAT device, publish the root
password of the Linux box and its RFC1918 address, and invite
all comers to prove me wrong by showing evidence that they've
successfully logged into the Linux box? When I last did this,
I got a handful of emails, some quite snide, suggesting I was
some combination of ignorant, stupid, and reckless; the Linux
box for some reason remained unmolested.
Jim Shankland
Not so. NATing source addresses from multiple source hosts towards the Internet anonymises the source machines so they can not be 'looked at' individually.
Additionally, NATing services on separate machines behind a single NATed address anonymises the services behind a single address.
Also, it is good to control the Internet addressable devices on your network by putting them behind a NAT device. That way you have less devices to concern yourself about that are directly addressable when they most likely need not be. You can argue that you can do the same with a firewall and a default deny policy but it's a hell of a lot easier to sneak packets past a firewall when you have a directly addressable target behind it than when it's all anonymous because it's NATed and the real boxes are on RFC1918.
So really, those who do not think there is a security gain from NATing don't see the big picture.
Owen DeLong <owen@delong.com> writes:
> There's no security gain from not having real IPs on machines.
> Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people
are liable to start believing it's true :-).
*No* security gain? No protection against port scans from Bucharest?
No protection for a machine that is used in practice only on the
local, office LAN? Or to access a single, corporate Web site?
Shall I do the experiment again where I set up a Linux box
at an RFC1918 address, behind a NAT device, publish the root
password of the Linux box and its RFC1918 address, and invite
all comers to prove me wrong by showing evidence that they've
successfully logged into the Linux box? When I last did this,
I got a handful of emails, some quite snide, suggesting I was
some combination of ignorant, stupid, and reckless; the Linux
box for some reason remained unmolested.
Jim Shankland
Mangling the header did nothing for 'security'. The lack of state at the
network edge is the security tool here. A firewall provides that state
function without the side effect of header mangling.
If you really believe in your 1918/nat providing security, do the experiment
you propose above, but put in a state mapping for the public address of the
nat to the 1918 address of your Linux box.
Argueably the instant hit of IP source anononymity you get with NAT is a
security benefit (from the point of view of the user). Of course these
days there all sorts of fragment and timing analyses that will allow you
to determine origin commonality behind NAT, but it's nowhere near as
convenient as a public IP address.
A non-NAT stateful firewall can't simulate that, you need high-rotation
dhcp or similar to get close. Although IPv6 privacy addresses rock
The argument can go either way, you can spin it as a benefit for the
network operator ("wow, user activity and problems are now more readily
identifiable and trackable") or you can see it as an organisational
privacy issue ("crap, now macrumors can tell that the CEO follows them
obsessively").
NAT is still evil though, the problems it causes operationally are
just plain not worth it.
> *No* security gain? No protection against port scans from Bucharest?
> No protection for a machine that is used in practice only on the
> local, office LAN? Or to access a single, corporate Web site?
Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly
configured stateful *non*-NAT firewall should be doing for you already.
Thanks for the clarification, Owen and Valdis. We are, of course,
100% in agreement that it is stateful inspection that provides
(a measure of) security, and that stateful inspection can be had
without NAT.
But NAT *requires* stateful inspection; and the many-to-one, port
translating NAT in common use all but requires affirmative steps
to be taken to relay inbound connections to a designated, internal
host -- the default ends up being to drop them. All this can be
done without NAT, but with NAT you get it "for free".
I can't pass over Valdis's statement that a "good properly configured
stateful firewall should be doing [this] already" without noting
that on today's Internet, the gap between "should" and "is" is
often large.
If what you meant to say is that NAT provides no security benefits
that can't also be provided by other means, then I completely
agree.
What the firewall *should* be doing? The end devices *should* not need protection in the first place, because they *should* be secure as individual devices. But they are not. So you put a firewall in front of them, and that device *should* give them all the protection they need. But sometimes, it doesn't. So you make end devices unaddressable by normal means, and while it shouldn't give them more security, it turns out it does. No matter how much it shouldn't, and how much we wish it didn't, it does.
The difference between theory and practice is that in theory, there is no difference, but in practice, there is.
