Re: problem configuring squeeze
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
Reply to: