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


-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]