Re: problem configuring squeeze
Eugen Leitl <eugen@leitl.org> writes:
> On Mon, May 16, 2011 at 10:30:11AM +0200, Bjørn Mork wrote:
>
>> >> IMO the prefix length for any local prefix should always be /64. The
>> >> purpose of a /56 prefix is to be divided into multiple /64 prefixes.
>>
>> Yes.
>
> This is exactly the plan. The /56 is parceled into /64s for
> each invididual vserver gust.
>
> There's a problem, however. My hoster won't (can't) give me
> more than a /56 for each rack. I need at least two /56
> however (one IPv4 /32 for each IPv6 /64).
I fail to see your hosters arguments against giving you e.g. a /48 if
you really need it. Some of us still argue that that should be the
minimum allocation for end user sites.
You do really need more than 256 subnets for each rack?
> It just occured to me that I can set up a local 6to4 relay
> router http://wiki.debian.org/DebianIPv6 and produce private
> IPv6 space for each public IPv4 /32.
>
> Are there problems associated with this, or can I go ahead
> with it?
No. Well, you can of course, but... IMHO, 6to4 should die now. Don't
use it. Note that there's work going on in the IETF trying to move it
to historic:
http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic-00
>> And the whole /56 should also be terminated in a null route by doing
>> something like
>>
>> ip route add unreachable 2a01:4f8:7d:300::/56
>>
>> or you may cause a routing loop which can be used to DoS your upstream
>> link.
>
> I don't understand that remark yet, as I'm pretty new to IPv6 and
> networking in general.
It's not really IPv6 specific but related to having more addresses
routed towards you than you actually use. Which sort of makes it IPv6
anyway, since that's rarely a proble with IPv4 :-)
The issue is that you need to drop packets destined for any of your
unused adresses instead of sending them back to your ISP.
Let's use the documentation prefix instead of yours for this example:
Your upstream ISP has a route for 2001:db8:7d:300::/56 pointing towards
you:
2001:db8:7d:300::/56 via YOU dev INT
You have a default route pointing towards your ISP, and let's say three
/64 interface routes carved out of the /56:
default via ISP dev WAN
2001:db8:7d:300::/64 dev ETH1
2001:db8:7d:301::/64 dev ETH2
2001:db8:7d:302::/64 dev ETH3
So what will happen to a packet for e.g. 2001:db8:7d:303::1? Your ISP
will send it to you since it matches the /56 route. But you will send
it back because it only matches your default route. And so on, and so
on...
To break the loop, you do need to have a catch-all route for the whole
prefix. This can, and should be, of type "unreachable", which will make
your router drop the packets and possibly return an appropriate icmp
error message. Note that this catch-all route won't interfere with any
of the interface routes you define, as they will be more explicit (64 >
56) and therefore preferred.
Your modified routing table will then look like:
default via ISP dev WAN
unreachable 2001:db8:7d:300::/56 dev lo
2001:db8:7d:300::/64 dev ETH1
2001:db8:7d:301::/64 dev ETH2
2001:db8:7d:302::/64 dev ETH3
Bjørn
Reply to: