PDA

Bekijk Volledige Versie : IPv6 uitdelen van IP-adressen



justinG
12/07/10, 11:17
Wij zijn bezig met het voorbereiden van IPv6 om het in gebruik te nemen binnenkort.
Onze Cisco's en firewalls zijn allemaal Ipv6 ready.

Nu nog een indeling voor de IPV6-adressen. Daar loop ik een beetje vast.

Wat delen jullie uit bij 1/4 rack bijvoorbeeld? /48 of minder?
En bij 1 server?

Ik zat er aan te denken voor elke losse server gewoon het ipv4adres om te zetten naar Ipv6.

::ffff:192.168.89.9 bijvoorbeeld


Ik ben benieuwd hoe jullie dit doen of gaan doen:)

xserve
12/07/10, 11:30
Wij geven onze eigen servers gewoon 1 IPv6 adres, daarbij gebruiken we wel per soort dienst een aparte reeks.

Klanten met colocatie (ook voor 1U) krijgen gewoon een /64 bij ons.

Freakingme
12/07/10, 12:46
Hier kriijgt ieder domeinnaam z'n eigen adres. Mocht er dan ooit wat geblocked worden op /128 niveau dan blijft de rest van de sites 't gewoon doen. En hoeven we ons nooit meer druk te maken over klanten die een certificaat aan hun site willen hangen. Daarnaast zouden we makkelijker DDOS's aan moeten kunnen pakken wanneer 1 specifieke site onder vuur genomen wordt.

Hiervoor krijgt bij ons iedere server een /64 (volgens de specs zou dit 't kleinte deelbare blok moeten zijn). Het is dat we geen kasten verhuren, maar die zou ik gewoon een /56 (of /48, maar wat je daar dan weer mee moet...) geven. Wat we met resellers gaan doen weten we nog niet (die zouden we natuurlijk een eigen /108 kunnen geven ofzo waar ze zelf uit kunnen uitdelen)...

Ik zou in ieder geval niet voor je ipv4 notatie gaan. Nu heb je een kans om alles op een logische manier in 1 range in te delen; en daar zou ik dan ook zeker gebruik van maken. Daarnaast werkt je plan niet meer op het moment dat je een server hebt die alleen nog maar een ipv6 adres heeft (en die gaan er komen - ooit).

GC-Hosting
12/07/10, 13:20
Heerlijk, omdat het niet op kan zijn we al weer aan het verspillen?

Ik denk dat we gewoon IPv6 hetzelfde moeten behandelen als IPv4 bij het uitdelen. Is toch onzin "nu hebben we veel eten dus laten we alles opeten want over paar maanden heb ik toch geen honger" ? :thumbdown:

Freakingme
12/07/10, 13:26
Ja, laten we iedereen ook weer achter NAT zetten, ging immers prima bij ipv4...

Daarnaast is een /64 per server inderdaad fors, maar ja, we hebben dan ook een hoop, en een /64 is volgens de specs 't smallest distributable block.

Wido
12/07/10, 14:01
Hier kriijgt ieder domeinnaam z'n eigen adres. Mocht er dan ooit wat geblocked worden op /128 niveau dan blijft de rest van de sites 't gewoon doen. En hoeven we ons nooit meer druk te maken over klanten die een certificaat aan hun site willen hangen. Daarnaast zouden we makkelijker DDOS's aan moeten kunnen pakken wanneer 1 specifieke site onder vuur genomen wordt.Redenatie snap ik, maar hoe doe je dit in je servers!?

Wij hebben het ook overwogen, maar in een cluster omgeving is het een drama, ik zie de "ifconfig" output al voor me.

Welke software gebruiken jullie op de hosting omgeving?

Freakingme
12/07/10, 14:20
Wij draaien (momenteel) een redelijk standaard DA setup dus per server valt het aantal ip adressen wat daadwerkelijk gebruikt wordt (en geconfigged) wel mee. We hebben wel overwogen om meteen een /64 te configgen, maar het aantal kernel objecten zou vragen om een investering in ram die onbetaalbaar zou zijn.

Wat je eventueel wel zou kunnen doen is kijken of je met iptables address translation slechts op 1 ip te luisteren, en toch inkomende verbindingen op je hele /64 te accepteren. Of wellicht realistischer/praktischer is 't om een /64 te routen naar een tun/tap device, en van daar uit te fixen. Moet je alleen nog iets hacken waardoor je services 't originele ip voorgeschoteld krijgen. Mocht dat lukken zie ik graag hoe je 't gedaan hebt :P

Freakingme
12/07/10, 15:14
Dit (http://www.mjmwired.net/kernel/Documentation/networking/tproxy.txt) lijkt btw wat je zoekt.

Wido
12/07/10, 16:33
Dit (http://www.mjmwired.net/kernel/Documentation/networking/tproxy.txt) lijkt btw wat je zoekt.Als ik het zo lees, is dat alleen voor IPv4

t.bloo
12/07/10, 16:40
Hier kriijgt ieder domeinnaam z'n eigen adres

Ik ken servers met meer dan 500 domeinnamen, ik ben benieuwd wat voor extra resources 500 IP adressen zouden vragen.

Freakingme
12/07/10, 16:54
Als ik het zo lees, is dat alleen voor IPv4

iptables doet inderdaad alleen ipv4, maar met ip6tables zou dat ook moeten kunnen denk ik.

@T.bloo one way to find out: Gewoon uitproberen. Per ip waar je op luistert (zonder TPROXY dus) wordt 1 kernel object gebruikt. Met 500 ip's ofzo is dat prima te doen (zal een paar mb kosten). Heb je echter 2^64 kernel objecten nodig; dan moet je veel, heel veel ram gaan bijprikken.

ichosting
12/07/10, 16:58
Ik ken servers met meer dan 500 domeinnamen, ik ben benieuwd wat voor extra resources 500 IP adressen zouden vragen.

Het lijkt mij ook niet echt handig om alle domeinen een eigen IPv6 te geven. Je vraagt hier veel extra resources mee. Apache zal het ook niet echt fijn vinden uiteindelijk denk ik ;)

Freakingme
12/07/10, 17:06
Het lijkt mij ook niet echt handig om alle domeinen een eigen IPv6 te geven. Je vraagt hier veel extra resources mee. Apache zal het ook niet echt fijn vinden uiteindelijk denk ik ;)

Sinds wanneer? Ip-based virtualhosting is nog altijd sneller dan namebased virtualhosting, in ieder geval in Apache...

Apoc
13/07/10, 15:23
Heerlijk, omdat het niet op kan zijn we al weer aan het verspillen?

Ik denk dat we gewoon IPv6 hetzelfde moeten behandelen als IPv4 bij het uitdelen. Is toch onzin "nu hebben we veel eten dus laten we alles opeten want over paar maanden heb ik toch geen honger" ? :thumbdown:

Onzin redenatie. Er zijn praktisch oneindig IPv6 adressen.

Mikey
13/07/10, 15:44
Wij draaien (momenteel) een redelijk standaard DA setup dus per server valt het aantal ip adressen wat daadwerkelijk gebruikt wordt (en geconfigged) wel mee. We hebben wel overwogen om meteen een /64 te configgen, maar het aantal kernel objecten zou vragen om een investering in ram die onbetaalbaar zou zijn.


Geef je een range op, of config je alle virtuele adapters in de config files ?

Freakingme
13/07/10, 16:20
Momenteel doen we het op de DA-manier, dus worden de ip's in DA toegevoegd via 'ip management' om uiteindelijk aan domains geassigned te worden. Dus vooralsnog gewoon losse ip's, maar dat komt ook omdat we niet zo gek veel sites op 1 server hebben.

En ja, daar moet nog een keer iets slims voor gescript worden, en ja, dat gaat in DA omslachtig.

Ben wel benieuwd hoe het ip plan er bij anderen uit ziet... ;)

bartjanm
16/07/10, 11:35
Heerlijk, omdat het niet op kan zijn we al weer aan het verspillen?

Ik denk dat we gewoon IPv6 hetzelfde moeten behandelen als IPv4 bij het uitdelen. Is toch onzin "nu hebben we veel eten dus laten we alles opeten want over paar maanden heb ik toch geen honger" ? :thumbdown:

ipv6 is ontworpen voor "waste" waste in adressen, om meer efficientie op andere vlakken te krijgen (forwarding, subnetting etc.) Ook wordt nu slechts een klein deel van de totale IPv6 space gebruikt (ik dacht 1/8e). Met die 1/8e, met alle waste van nu, is het voor zover onze guru's het kunnen voorzien voldoende. Mocht iedereen in de IPv6 wereld het mis hebben, en de critici (zoal jij :) ) gelijk hebben dan hebben we nog 7/8e over om zuinig aan te doen.

kortom: weg met de IPv4 kruideniersmentaliteit en genieten van de adresvrijheid die IPv6 bied :)

Wido
16/07/10, 12:51
ipv6 is ontworpen voor "waste" waste in adressen, om meer efficientie op andere vlakken te krijgen (forwarding, subnetting etc.) Ook wordt nu slechts een klein deel van de totale IPv6 space gebruikt (ik dacht 1/8e). Met die 1/8e, met alle waste van nu, is het voor zover onze guru's het kunnen voorzien voldoende. Mocht iedereen in de IPv6 wereld het mis hebben, en de critici (zoal jij :) ) gelijk hebben dan hebben we nog 7/8e over om zuinig aan te doen.

kortom: weg met de IPv4 kruideniersmentaliteit en genieten van de adresvrijheid die IPv6 bied :)True! Gevaar is wel wat je je subnets intern niet goed verdeeld waardoor je dan een probleem krijgt, maar dat speelt alleen voor de gene die hun eigen netwerk beheren.

Maar in een /64, doe je best en geef zo veel mogelijk IP's!

Tim.Bracquez
16/07/10, 16:03
Heerlijk, omdat het niet op kan zijn we al weer aan het verspillen?
Moet je ook kijken wat de RIPE voorschrijft, deze geeft aan om in blokken te verdelen en uit te geven.

SHQ
17/07/10, 13:25
Je bent als IP verstrekker verplicht vanuit Ripe om blokken van een /64 toe te kennen aan je klanten.

pierce
17/07/10, 13:30
Je bent als IP verstrekker verplicht vanuit Ripe om blokken van een /64 toe te kennen aan je klanten.

Waar kan ik dat terugvinden? Heb je een linkje toevallig?

SHQ
19/07/10, 09:47
Waar kan ik dat terugvinden? Heb je een linkje toevallig?

http://www.ripe.net/info/faq/rs/ipv6.html#15


However, the minimum assignment is a /64.

ichosting
19/07/10, 10:28
http://www.ripe.net/info/faq/rs/ipv6.html#15

Dit gaat over de END USER. De end user is de gebruiker van de range welke door de LIR wordt uitgedeeld.

Apoc
19/07/10, 13:47
Je bent als IP verstrekker verplicht vanuit Ripe om blokken van een /64 toe te kennen aan je klanten.

Nee, de minimale assignment is een /64. Je hoeft niet iedere klant een eigen assignment te geven (dat doe je met IPv4 ook niet).

Voordat je dergelijke opmerkingen maakt, zou ik eerst eens nalezen wat assignment en allocation precies inhouden.

vDong
21/07/10, 20:51
Nee, de minimale assignment is een /64. Je hoeft niet iedere klant een eigen assignment te geven (dat doe je met IPv4 ook niet).

Voordat je dergelijke opmerkingen maakt, zou ik eerst eens nalezen wat assignment en allocation precies inhouden.

Voor colocatie (incl rackklanten) en volgens sommigen ook dedi klanten was dat wel de gedachte er achter.
Uiteraard is het niet de bedoeling om elke shared klant een /64 te geven

Mikey
22/07/10, 10:48
Nee, de minimale assignment is een /64. Je hoeft niet iedere klant een eigen assignment te geven (dat doe je met IPv4 ook niet).

Voordat je dergelijke opmerkingen maakt, zou ik eerst eens nalezen wat assignment en allocation precies inhouden.

en dan via de rbl lijsten je hele /64 geblocked krijgen, en je hele klanten portfolio heeft er last van.... Ook hier is een thread over geweest.

Apoc
22/07/10, 10:58
en dan via de rbl lijsten je hele /64 geblocked krijgen, en je hele klanten portfolio heeft er last van.... Ook hier is een thread over geweest.

Dat is inderdaad een issue, maar lijkt me geen reden om dan iedere klant maar een eigen /64 te geven.

vDong
22/07/10, 13:19
en dan via de rbl lijsten je hele /64 geblocked krijgen, en je hele klanten portfolio heeft er last van.... Ook hier is een thread over geweest.

Er worden nu ook hele /24 en /16s geblocked.....ik mis je punt een beetje.

Qweb
28/07/10, 22:10
Het is toch zo dat RIPE je verplicht om minimaal een /64 te assignen aan elke 'end' user?

vDong
29/07/10, 14:01
Het is toch zo dat RIPE je verplicht om minimaal een /64 te assignen aan elke 'end' user?

Dat klopt, echter je end user kan in geval van shared hosting de volgende dingen zijn:

- Hele shared platform
- Een shared server
- een reseller

Ik zou het niet lezen als een /64 per shared klant, mijn voorkeur gaat zelfs uit naar de 1e van de 3.