On Mon, May 16, 2011 at 01:46:24PM +0200, Bjørn Mork wrote: > > 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
The argument is basically: our setup doesn't support this, and we won't change it to just accomodate you. Want another /56, rent another rack. Unfortunately, switching to a different colo is not feasible for me at the moment. > minimum allocation for end user sites. > > You do really need more than 256 subnets for each rack? I have 3x /24 at the moment, so that alone would require 3x /56. I could dish out smaller units than /64 for each end user vserver guest, but that would break too many assumption so I need to figure out another way. What options other than 6to4 with a local relay router with native IPv6 do I have? Tunnels (HE, SixXT) are just as deprecated, right? > > 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 Well, if my hoster won't give me enough space, and I can't get PI space (my hoster won't let me speak BGP) I don't have too many choices. > >> 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 Thanks, I'll keep that in mind. -- Eugen* Leitl <a href="http://leitl.org";>leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
