|
xen-users
Re: [Xen-users] IPV4 is nearly depleted, are you ready for IPV6?
See the answers within the quote:
Am 07.12.2010 12:44, schrieb Jonathan Tripathy:
Re: [Xen-users] IPV4 is nearly depleted, are you ready for
IPV6?
Thanks for this :)
Looks like I need to do a lot of reading on how
IPv6 works regarding NDP.
Not sure if static ARP is the way to go for me, as
I have many customer DomUs on the same subnet, which are being
added on a daily basis. Once a new DomU goes live, all other
DomUs' static ARP tables would need updating which would be
impossible.
It is sufficient if the Dom0 holds all static ARP/NDP entries for
its own DomUs. They can be added by the vif-script easily. The
propagation to other hosts can be one of the following:
- All other hosts use the dom0 as a gateway even for connections to
other domUs
- You can use arp-proxy or ndp-proxy, your dom0 will start to
propagate its static ARP/NDP entries in behalf of the domUs which in
turn don't send any ARP answers.
- static ARP entries are not disabling the dom0 from answering ARP
packages or from resending them on a bridge. So you could use static
ARP entries in addition to a bridge that does not filter arp. This
will be less secure as the arp tables of other domUs can be spoofed,
but the dom0 itself will be protected (This should be rather seen as
a part of the ARP security concept).
Which method is best heavily depends on how far you can force domUs
to do (little) advanced network setup. For example, the safest way
would be if all clients have a static /32 route to the dom0 and a
static ARP entry for dom0 (this is usually with MAC address
fe:ff:ff:ff:ff:ff) and route all network traffic - no matter whether
it's local or to the internet via the Dom0 (it will pass the dom0
anyway so this doesn't really change the path of any packets).
Afterwards, the domU can disable ARP completely if the Dom0 has a
static arp entry for the domU.
Of course there are ways where domUs need less configuration, but
they usually come with some tradeoffs... There is no unique solution
for all XEN servers that fits all situation.
(All those things apply to NDP equally)
AFAIK, ebtables (which I use currently for my IPv4
setup) cannot filter the content of NDP messages. Since I don't
think I can use static ARP, I still need to use NDP - just need
the actual content of the NDP packets filtered.
Don't know how to filter NDP message *content*, the messages
themselves are lots easier...
As for the NAT issue, indeed a really do love NAT.
I find it a huge culture shock and unsettling that in an IPv6
world, all internal machines will have public routable IP
addresses. Does this mean that the traditional "Edge
Firewalls/NAT routers" would become filtering bridges? As surly
the world couldn't depend solely on host-bases firewalls...
(could we?!)
Well NAT for UDP (see VoIP or some appliances like that) is really
dirty... But indeed, routers will become filtering gateways - not
really bridges, because they will still do routing, but they won't
change any source or destination addresses for IPv6. This will mean
that each machine is directly accessible through the Internet, as
long as the router or local firewall does not interfere.
I guess if each "internal" network in the world had
it's own IPv6 subnet, then we could just use a standard
firewall-router (in no-NAT mode). However it just seems like
extra trouble to go and obtain an IPv6 block from the
responsible body. For example, I spin up many test internal
networks on a daily basis just to play around with them - I
don't really want to "register" these networks.
It would be nice if routers could nativly route
between IPv6 and IPv4, however I understand that this is just
not possible. Application specific dual-stack proxy servers are
required.
Well I think many IPv6 issues already have been fixed - the biggest
problem is, that too few servers are supporting it... just imagine
private customers being forced to use IPv6 only right now... They
would be blocked out of most parts of the Internet.
I would not like a solution that keeps us on IPv4 forever, because
many problems of IPv4 or unofficial extensions are now solved /
fully integrated into IPv6 - the protocol is cleaner and (without
any filtering) more secure than IPv4.
Cheers
Well arptables is officially deprecated
anyway. I don't know whether its
successor, ebtables, supports filtering of the content of
NDP messages,
but you can filter NDP messages themselves with iptables
just as any
other icmpv6 message - for example, denying them at all. Or
you add
static neighbor entries, which cannot be overwritten by
neighbor
solicitations.
In addition, the neighbor proxy serves as a replacement for
the arp
proxy in routed scenarios.
A good point to start is using static ARP + neighbor entries
for all
domUs and the gateway at eth0. This will effectively
prohibit most
working ARP / NDP attacks.
What I'm personally missing is NAT. I know it has been
dropped for good
reasons, but NAT has some cool advantages like hiding a
webserver domU
and a mailserver domU behind a single IP address - which
will obfuscate
your virtual server structure.
We use an own private internal network within our server,
which is dual
stack with IPv4 + IPv6, using a routed setup with static ARP
+ neighbor
entries, but however, I do not yet route external IPv6
addresses to the
domUs (not for an explicit reason, rather because of too
less time /
interest). I think XEN as a software is ready for IPv6,
although the
default vif-scripts do not really do much about that. But
bridges and
routing works finde with both of them, it's just a question
of the setup.
Am 07.12.2010 00:11, schrieb Simon Hobson:
> Jonathan Tripathy wrote:
>
>> A problem with using IPv6 at the minute is that
netfilter doesn't
>> have as-advanced filtering capabilities as it does
with IPv4. This is
>> important when your DomUs are for customers on an
unmanaged basis.
>>
>> The main issue is that IPv6 doesn't use ARP
anymore, so all MAC
>> address detection is done in the IP layer and
AFAIK, netfilter
>> doesn't have the proper filtering for IPv6 to
prevent MAC spoofing.
>> What we really need is an IPv6 equivalent to
arptables.
>
> Since you clearly know quite a bit more than I do about
IPv6 - can you
> recommend a good guide/primer for getting going ? At
the moment I know
> a little bit - but mostly what I know is that it's
quite a bit
> different from IPv4 and it's not a case of "the same
but more bits".
>
> It's really about time I started looking at this for
work.
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
Home