Eugen Leitl <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
