Xen project Mailing List

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

From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx on behalf of Felix Kuperjans
Sent: Tue 07/12/2010 00:06
To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] IPV4 is nearly depleted, are you ready for IPV6?

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