IPv6 fejlesztőknek
Itt a jövő internet protokollja, a nagy hosting centrumok egymás után kapcsolják be a gépeiken az IPv6-ot. Itt az ideje, hogy felkészítsük az alkalmazásainkat az IPv6 kezelésére. Szerencsére a feladat nem bonyolult, a legtöbb munkát elvégzi helyettünk a webszerver. Nekünk csak a címek kezelését kell megoldani.
Egy kis elmélet
Az IPv6 egyik lényege, hogy sokkal több IP cím van, mint az IPv4 esetén, ezért a címek tárolására sokkal több helyre van szükség. Az IPv6 cím 128 biten tárolható, azaz 16 bájton. Ha a webes fejlesztéshez használt nyelveket nézzük, akkor ez MySQL-ben két Unsigned BigInt, PHP-ban 32 bites platformokon 4 db integer, 64 bites platformokon 2 db integer. Ez a megoldás ugyan helytakarékos, de nem túl praktikus programozási szempontból.
Ahhoz, hogy jobban tárolhassuk az ilyen címeket, nézzük meg egy kicsit közelebbről őket:
2001:0db8:85a3:0000:0000:8a2e:0370:7334Az első szembetűnő változás, hogy az IPv4-nél megszokott pont helyett itt kettősponttal választjuk el a szegmenseket. A második, hogy a szegmensek maximum négy hexadecimális számot tartalmazhatnak. Az IPv6-os címben mindig 8 szegmens található. Az IPv6-os címre illeszkedő reguláris kifejezés tehát:
/^([a-fA-F0-9]{1,4}):([a-fA-F0-9]{1,4}):([a-fA-F0-9]{1,4}):([a-fA-F0-9]{1,4}):([a-fA-F0-9]{1,4}):([a-fA-F0-9]{1,4}):([a-fA-F0-9]{1,4}):([a-fA-F0-9]{1,4})$/Az IPv4-gyel ellentétben itt egyetlen egy regexppel száz százalékosan lehet validálni a címet, ha az gépi forrásból (pl. REMOTE_ADDR változóból) jön.
Rövidített írásformák
Ha a felhasználótól kérünk be IPv6-os címet (például egy DNS szerkesztő felületen), könnyen előfordulhat, hogy a rövidített írásformák egyikét fogja használni. Nézzük meg ezeket.
Nullák rövidítése
IPv6-os felírásban a leghosszabb nullákból álló szegmens halmazt ki lehet cserélni egy dupla kettőspontra. Így tehát a fenti példa címből ez lesz:
2001:0db8:85a3::8a2e:0370:7334A címfeldolgozásnál érdemes arra figyelni, hogy a dupla kettőspont állhat a cím elején vagy végén is.
IPv4-es címek felírása IPv6-os notációval
Az IPv6 definiál egy un. IPv4-mapped IPv6 addresses tartományt, ami arra szolgál, hogy IPv4-es címeket fel tudjunk írni IPv6 notációval is. Ez a tartomány a ::ffff:0000:0000/96, tehát az IPv4-es címet a példa utolsó két szegmensébe írjuk bele hexadecimális formátumban.
Azért, hogy a konverziót ne kelljen fejben elvégezni, megengedett a hibrid notáció használata is:
::ffff:192.168.1.1Ez utóbbi írásforma helyett javasolt egy külön IPv4-es mező készítése, mert a felhasználónak sokkal egyszerűbb, ha a számára megszokott formában tudja megadni a címet.
Címtartományok
Az IPv6 órási címtartományokkal dolgozik, ezért általános szabály a kiosztásban, hogy az első három szegmens jelöli azt a szolgáltatót, aki közvetlenül kapta az IPv6-os tartományt (LIR, Local Internet Registry), a negyedik szegmens az ún. subnet ID, a többi pedig a gép címét. A szolgáltatók az utóbbi két szabálytól eltérhetnek, de az első három szegmens mindig fix.
Ezt azért fontos tudni, mert pont a címtartományok mérete miatt az IP cím szerinti spam szűrés gyakorlatilag lehetetlenné válik, viszont a címtartományokat továbbra is figyelemmel kísérhetjük.
Támogatás a programnyelvekben
A modern webes programnyelvek szinte mindegyike támogat IPv6-ot (lásd PHP, Java), viszont érdemes arra odafigyelni, hogy nem biztos, hogy azon a gépen, amelyen a PHP fut, van IPv6. Több szolgáltató dolgozik olyan megoldással, hogy az IPv6-ot egy proxy szerveren végződteti, a webkiszolgálóra pedig IPv4-en hozza be a lekérdezést.
Kész programkód PHP-ra
Az IPv6-os és IPv4-es címek egységes kezelésére indítottam egy open source projektet, ami mindkét címet fel tudja dolgozni és egységes formára tudja használni. A funkció kéréseket, hibajegyeket a GitHub issue rendszerében várom.
Egy kis figyelmezetetés, további olvasmányok
Ha szervert üzemeltetsz, rendkívül körültekintően járj el! Ha nincs külön IPv6-os tűzfalad, akkor az IPv6 véletlen bekapcsolása védtelenül hagyja a gépedet!
Ha az IPv6 bevezetés rendszergazdai oldaláról szeretnél bővebben tájékozódni, melegen ajánlom Benedikt Stockebrand – IPv6 in Practice című könyvét.
■Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
Hojtsy Gábor:
"Karaktersorozatok sebessége" PHP-ben
Balogh Tibor:
Három kiterjesztés a Zend motor működésének megismeréséhez
dtaylor:
PostgreSQL telepítése és beállítása
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 1 | 2 | 3 | 4 | 5 |
PHP IPv6 támogatás
Így van
for the record: --enable-ipv6
Tyrael
Hasznos volt olvasni,
Tűzfal
Ha semmi mást nem csináltok, akkor ezt mindenképpen alkalmazzátok a tűzfalatok elején:
ip6tables -A INPUT -s 2002::/16 -j REJECT --reject-with icmp6-port-unreachable
iptables -A INPUT -p 41 -j REJECT --reject-with icmp-port-unreachable
Update
Ennel azert egy picit
Gondoljatok egy picit bele, hogy innentol kezdve teljesen ujra kell gondolni a felhasznalok tiltasanak modszereit. Amikor te kapni fogsz a szolgaltatotol egy ip cimet, akkor gyakorlatilag nem egy ip cimet fogsz kapni, hanem egy tartomanyt, ami nagyobb lesz, mint a jelenlegi teljes ipv4 tartomany. Vagyis a felhasznalo - ha rossz szandeku - barmikor megvaltoztathatja az ip cimet, mivel o rendelkezik teljeskoruen a szamara kiosztott tartomannyal. Igy az ip cim szuresnek eltunik az ertelme.
Egyebkent nem az osszes php-s fuggveny ipv6 kompatibilis. A kovetkezoek pl nem:
gethostby*
socket_create_listen
ip2long/long2ip
Az idei DPC-n volt egy eloadas az ipv6-rol es volt szerencsem reszt venni rajta. Mondott eleg sok erdekes dolgot az eloado. Tobbek kozott azt is, hogy ha a portszamot szeretned elkuloniteni az ipv6-os ip cimtol, akkor azt igy kell megtenned:
[ipv6cim]:portszam
Tehat hasznalni kell a szogletes zarojeleket az ip cim kore.
Az eloadas dia anyaga megtalalhato itt: http://prezi.com/qlso4kn-iil7/ipv6-for-php-developer/
Van neki egy github acc-ja is, amin keresztul megosztott nehany ipv6-tal kapcsolatos hasznos programot is: https://github.com/dsp/v6tools
Ez így nem egészen igaz
Ha globális szolgáltatásban gondolkozol, eddig sem tehetted meg, hogy IP cím szerint tiltottál bárkit is, mert lehet, hogy egy egész NAT-olt hálózatot tiltottál ki, extrém esetben egy egész netszolgáltatót vagy mondjuk egy akkora céget, mint az Oracle. (Ők ugyanis céges szinten valami proxy szervereken jönnek ki, tehát ugyanazt az IP-t használja fél Európa.)
Azt is érdemes itt figyelembe venni, hogy a jelek szerint sem otthoni felhasználóként, sem alsó kategóriás szerver hostingban nem kapsz önálló tartományt, hanem az előbbi esetben DHCPv6-tal, az utóbbi esetben MAC cím szerint Router Advertisementtel kapod a címedet. (Lásd ezt a hozzászólást.)
Ez azt jelenti, hogy pontosan ugyanolyan bonyolult új címet kérni, mint eddig: semennyire. Újra csatlakozol a netre és viszont látásra.
Önálló tartományra jelenleg nem nagyon van mód a hosting centrumokban és a jövőben is valszeg azért jelentős adminisztratív macera lesz ilyet szerezni. (RIPE bejegyzés készítése, stb.)
Ami a portszámmal együttes felírást illeti, azt valóban kihagytam, jogos. Ha IPv6-os szerverre csatlakozol IP szerint, akkor így kell felírni. Viszont IP cím szerint csatlakozni valahová nem vall jó programozási taktikára, hiszen egy adott szolgáltatás címe bármikor megváltozhat és az jól is van így, mert könnyebb átalakítani az infrastruktúrát.
DSP IPv6-os cuccai tök jók, viszont mind építenek arra, hogy az IPv6 bele van forgatva a PHP-ba, ami bizonyos esetekben nehézzé teheti a fejlesztő életét. Hogy egy példát mondjak, az olyan szolgáltatások, ahol az összes frontend átállítása nagy munkát jelent és ezért csak végzőztetik egy reverse proxyn az IPv6-ot, de magukat a webszervereket nem állítják még át.
Az előadásában pedig érzek némi csúsztatást (vagy utána nem nézést), /64-es tartomány beszerzéséhez egészen biztosan LIR-től kell címet kérned, home userként garantáltan nem kapsz ekkora tartományt. A LIR-es assignmenttel az adataid pedig bekerülnek a RIPE adatbázisba, tehát ugyanúgy működik, mint amikor hivatalosan igényelsz mondjuk egy /24-es IPv4-es tartományt.
Globalis szolgaltatasban
DSP jelenleg egy ingyenes szolgaltatason keresztul ipv6-ozik, es ott fix tartomanyt kapott. Tobben is voltak az eloadason (elsosorban Nemetorszagbol) es ok is azt mondtak, hogy /64-es tartomanyt kaptak. Elkepzelheto, hogy az egyes orszagokban mas lesz a gyakorlat, bar ketlem. Oszinten megmondom, fogalmam sincs, hogy a technikai oldala hogyan nez ki a szolgaltato felol, de ha az o esetukben megoldhato volt, akkor biztosan megoldhato lesz Magyarorszagon is. Ha belegondolsz, tobb ertelme van egy tartomanynak, mint egy ip cimnek, hiszen igy megszunik a dinamikus cimek kiosztasanak gyakorlata, ami sokszor akadalyozta a vegpont tenyleges helyenek megallapitasat problema eseten. Mivel ipv6 alatt mar nem letezik NAT-olas, ezert a tartomany segitsegevel az egyes eszkozeidnek te adhatsz ip cimet.
Szerintem megette a fene az egeszet, ha ugy akarsz php-bol ipv6-ozni, hogy nincs beleforgatva a php-be az ipv6 tamogatas... Ertem en, hogy nem minden esetben szokas beleforgatni alapbol, azonban a nagyobb disztribuciok csomagjaban alapbol benne van, ha meg kezzel forditod, akkor a szokasos frissitesi eljaras kereteben bele lehet forgatni gond nelkul. (Bele se merek gondolni, hogy nincs frissitve a PHP)
Az ip cim vagy hostnev szerinti csatlakozasrol szerintem ne nyissunk vitat (nem latom ertelmet), mindketto mellett es ellen is szolnak ervek. Ezt mindenki dontse el sajat maga az adott alkalmazas eseteben, hogy melyiket szeretne hasznalni.
Meg mielott felreerted, nem lehuzni akartam a cikkedet, csak egy picit kiegesziteni azzal, amit lattam/hallottam. Nagyon jonak tartom, hiszen ez egy hianypotlo volt mar nagyon sok fejleszto szamara.
Tovabbi jo cikkszerzest!
Hogyan?
Jelenleg 5000 HUF / hó általában ha az ADSL szolgáltatómtól fix IP címet szeretnék, kb ugyanennyi, ha a szerveremnek szeretnék egy másodikat. Logikus lenne hogy v6 cím esetén az ár 5000 / 2 ^ 96 legyen, de van egy érzésem, hogy ennél drágább lesz :)
Foglalkozik cég szolgáltatófüggetlen címek "értékesítésével"?
Kialakulatlan
Ha a szolgáltatófüggetlen címek alatt a v4-es PI tartományokat érted, azok olyan formában megszűntek, viszont helyette legjobb tudomásom szerint fordulhatsz közvetlenül a RIRhez (RIPE). Ha hazaértem, utána ások kicsit jobban. Sajnos erre nem volt szükség eddig, mert a cégcsoportba tartozó DoclerWeb egy LIR, úgyhogy baromi egyszerű volt az ügyintézés, nem is merült fel a PI, mint megoldás.
Update: megtaláltam a leírást, itt lehet elolvasni: http://www.ripe.net/ripe/docs/ripe-481#_8._IPv6_Provider
Röviden ennyi van benne:
Köszi
Egy apró tartomány birtoklásával máris biztosítani lehetne, hogy ne legyen ütközés. Persze v6 címeknél eleve kisebb az esély az ütközésre...
Igen