Szokatlan IPv6 kérdések

Informatikus vagyok, de kevésbé vagyok tájékozott IPv6-ban. Fenntartással kezeld a válaszaimat.

1) Dehogy lesz minden szerverének külön, publikus IP címe. Továbbra is meg fognak maradni azok a gépek amelyek a terheléselosztást végzik. Te nem fogod tudni hogy a háttérben milyen belső szerverekkel vált bármilyen adatot a frontend szerver.
Igen, IPv6 több IP címet tesz lehetővé a világon mint az IPv4.
Egyébként ha monitorozod a hálózati forgalmadat, akkor már most észreveheted hogy a mail.google.com pl milyen egyéb google.com -os szerverek felé irányít el téged (megjelenő képek, stíluslapok, ...).

2) Lehet, hogy több IPv6-os címe lesz. Most is vannak olyan szerverek amelyeknek több IPv4-es címe van.

3) Kevésbé értem a kérdést. Munkahelyi hálózatokat mindig is védeni fog egy tűzfal, frontend szerver. Azon keresztül fognak kijutni az internetre és kívülről azok nem fognak látszódni (jobb helyeken).

4) Broadcast cím? Szerintem IPv6-on is lehet hogy van vagy lesz.

5) Ez alatt mit értesz?

6) A MAC cím a hálózati interfész egyedi, gyári száma. Az nem teszi lehetővé az internetes kommunikációt, ahhoz az IPv[46] cím szükséges.
Két különböző dolog és mindkettő szükséges egy hálózatban.
MAC cím az internetes kommunikáció legalja, a fizikai réteg. Alhálózaton belül ez azonosítja a kártyát. Felsőbb rétegek, amelyek az útvonalválasztást végzik, azok az IPv[46] címre épülnek. Ez utóbbi adja meg hogy merre található a teljes hálózatban egy eszköz.

7) Nem foglalkoztam IPsec-el, de a titkosítás lényege mindig az, csak a feladó és a címzett tudja dekódolni a kommunikációt és a többiek ne lássanak bele.

8) Lásd előző pont, nem foglalkoztam még vele. De szerintem nem, az IPsec egy megoldás lehet. Ettől még a https vagy ssh mást fog használni.

9) Kevered az átviteli, kommunikáció védelmét és titkosítását a tartalom azonosíthatóságával és védelmével. Előző az adatforgalom védelmét végzi, közbenső elemek ne tudják lehallgatni az adatcserét.
PGP és GnuPG egy digitális aláírás. Lehet hogy mindenki által olvasható az email. De a digitális aláírás biztosítja hogy valóban az aláíró küldte azt. Persze titkosíthatja is, ami azt jelenti hogy mégha valakinek oda is adod az adott email-t, akkor is csak a címzett tudja azt a PGP/GnuPG kulcsával elolvasni azt.

10) Úgy érted a TLS és POP3S? Az IPv6-tal nem, ezek megint a kommunikáció titkosítását végzik. IPv6 esetén is meglesz az útvonalválasztás, azaz továbbra is keresztül fog menni több eszközön a kommunikáció mire eléri azt a gépet amivel kapcsolatot létesítesz.

11) Ismétlődő kérdésed. Ne keverd a hálózati részt és az adatfolyam titkosítását, védelmét.

subscribe

Informatikus vagyok, én sem praktizáltam még IPv6-tal, de próbálok nem hülyeséget beszélni :)

> 1.) Az IPv6-al pl.: a Google és a Facebook minden egyes szerverének különböző lesz
> a címe? (Tudni lehet, hogy melyikkel kommunikálok? Nem tudom, hogy IPv4 alatt
> mennyi címet használnak, de több lesz?)

Elsőre picit zavaros a kérdés. A Google és a Facebook minden egyes szerverének most is különböző címe van, elvégre nem lehet két azonos című gép az Interneten :)

Nyilván arra gondolhatsz, hogy most több backend gépük valószínűleg nincs publikus IP címmel ellátva, hanem mondjuk NAT mögött csücsül, esetleg egyáltalán ki sem lát közvetlenül a netre. Ez változhat, de hogy a felhasználók számára elérhetőek lesznek-e olyan gépek, amik eddig nem voltak, az főként üzemeltetői döntés (és tűzfal) kérdése.

> 2.) A nagyobb honlapoknak több IPv6-os címe lesz?

Ezt a kérdést vagy nem értem, vagy az előző kérdésre adott válaszom megválaszolja.

> 3.) Az eddig elméletig felderíthetetlen munkahelyi hálózatok sérülékenyebbek
> lesznek? Látszani fog, melyek a hálózathoz tartozó gépek vagy csak az adott
> gépnek az IP címe?

A jelenlegi, tipikus NAT megoldás önmagában ad egy kellemes védelmet a privát IP-vel rendelkező gépek számára. Ha nem lesz nat, akkor nyilvánvalóan jobban oda kell figyelni a tűzfal megfelelő beállítására, így azt hiszem, a gondatlan rendszergazdáknál a "mindenki publikus címmel rendelkezik" felállás hordoz egy kis veszélyt magában.

> 4.) Lesz olyan közös hálózati cím, amivel az összes hálózatban jelenlevő gép
> elérhető?

IP szintű broadcastra gondolsz? Nem pontosan ugyanúgy, de lesz. IPv4 esetében van közvetlen broadcast cím (míg a multicast támogatás csak opcionális) addíg IPv6 esetében a multicast szériatartozék, ott nézz körül.

> 5.) Hogy oldják meg, hogy több különböző otthoni hálózatokat ne lehessen egyszerre
> megcímezni?

Ezt a kérdést nem értem. Mit értesz azalatt, hogy egyszerre megcímezni?

> 6.) Az IPv6 kiválthatja a MAC address-t? Ez is egyértelműen jelzi a elektronikai
> terméket, nem? Ha nem váltható ki, akkor miért?

A MAC address Layer2 szintű címzés, az IP cím pedig Layer3. Nézz körül az ISO/OSI rétegek körül.

> 7.) Az IPv6 IPsec esetében a kezdeti küldő és a végső fogadó tudja csak feloldani a
> titkosítást?

A világ összes titkosításának ez a lényege, IP-től függetlenül :)

> 8.) Az IPv6 IPsec előbb-utóbb kiváltja a jelenleg használt titkosított
> adatátvitelt? Ha nem, miért?

Ha a jelenlegi IPsec, illetve egyéb VPN megoldásokra gondolsz, akkor talán, de nem valószínű. Ha TLS-re gondolsz, azt nyilván nem fogja kiváltani.

> 9.) Nem kell majd használni PGP titkosítást a levelezésben? (Ez eddig képeslaphoz
> hasonlított e-mail küldés zárt borítékra változik?)

Az IP szintű titkosítás nem védi ki azt, hogy pl. a levelezőszerveren ne tudják illetéktelenek elolvasni a levelet. Arra a PGP való.

> 10.) Kiválható lesz az SMTPS és a POP3S?

Mivel az IP szintű kommunikációban az IPSec továbbra is csak egy lehetőség, ezért a hostok kommunikációjának 99+%-ában nem lesz IPsec, így a levélszolgáltatódtól továbbra is TLS-sel fogod szippantani a spameket, ha biztonságot akarsz.

> 11.) Kiváltja az IPv6 a https-t, a SSL-est és a TLS-est? Minden gépnek lesz
> valamilyen tanúsítványa?

Nem, lásd fent.

1. Most is különböző címe van minden szervernek. Hogy azonosítanád őkét másképp a hálózaton? Az más kérdés, hogy egy részüket te sosem látod kívülről, a legtöbb helyen jelenleg privát címtartományokat használnak, illetve különböző terhelés elosztó rendszerek mögött vannak a farmok, amiről persze neked fogalmad nincs (és nem is kell), te csak a load balancer külsőjét látod.
2. Miért lenne? Vagy miért ne? Ahogy most több ipje van pl. a googlenak vagy gmailnek (ezek a földrajzilag legközelebb lévő load balancerek ip-i), ugyanúgy lehet v6-tal is. De semmi köze ahhoz, hogy milyen oldal, nagy vagy kicsi, ugyanúgy lehet.
3. A tűzfalak nyilvánvalóan ugyanúgy megmaradnak, annyi, hogy a cím nem lesz natolva, így kint a gép tényleges ipje fog látszódni. Azt meg felejtsétek el, hogy a NAT egy security solution.
4. Broadcast nincs, unicast, multicast és anycast van.
5. Miért, most meg lehet?
6. A mac egy fizikai (layer2) hardveres cím, az ip cím (legyen az v4 vagy v6) pedig hálózati (layer3). Egyébként nem, soha.
7. Mert v4 esetén nem? Régen rossz, ha bárki közbenső lehallgathatja.
8. Nem, a kettő nem függ össze.
9. Nem változik semmi semmit. Az IPsec egy tunnel, ami azt biztosítja, hogy a végpontok között titkosított kapcsolaton keresztül megy a forgalom, függetlenül attól, hogy mi megy a tunnelbe.
10. Nem.
11. Továbbra is "Nem". Annak lesz tanúsítványa, aki csinál magának self signedet, vagy kér/vesz hivatalos tanúsítványkiállító cégtől, mint eddig.
--
Discover It - Have a lot of fun!

Én látnám értelmét NAT-nak IPv6 felett, hiszen a forrás IP-k (darabszámának, értékének) el nem rejtése olyan plusz információt tartalmazhat, amit lehet, hogy valaki nem kíván publikálni.

Kedves jeti

Természetesen nem csak neked szól, de ez egyértelmű lesz remélem.
Szóval mi rendszergazdák ( remélem senki nem veszi zokon, aki többnek tartja magát vagy engem kevesebbnek) de legalább mi próbáljunk meg rendszerben gondolkozni, és úgy dolgozni. Ez a fórum szerintem több mint hasznos, ennek már szót is adtam ( így már elég nagy hogy bodzasfanta is rá tudjon kattintani :)), de akár milyen jó a fórum, vannak olyan dolgok amik nem tökéletesek még a hupper kiegészítővel sem ( btw mindenkinek ajánlom, bár sajna chrome alatt nekem nem meg a droid filter).

Tehát, és most már a lényeg, egy ilyen többkérdéses topic teljesen áttekinthetetlen lesz , főleg ha valaki később csatlakozik be a témába akkor esélye sincs.

Bár nem sokat, de lehet javítani rajta egy kis formázással.
Topic leírás: röviden hogy ez ipv6 lesz és hogy nem szokványos kérdések meg stb.
Aztán hozzászólásonként beírni a kérdéseket, mert így remélhetőleg az egy adott kérdésre válaszoló emberkék válaszai egy csomóban lesznek. Ez nyilván csak egy példa, de valamit ezzel jó lenne kezdeni, javára válna a fórumnak.

és most
/offtopic on
az állást kereső topicból hol érezzük magunkat jól topic lett,a codra kft bakijából meg önözési vagy Önözési topic, stb. A lényeg hogy, elégé el tudunk szaladni a témától ami sokszor ront az áttekinthetőségen/hasznosságon. Erre lehetne jó mondjuk ha egységesítenénk az offtopic hozzászóláskat elkülönítő tageket aztán elég a hupperben lekezelni, de ha az ember a lényeget keresi egyszerűsítsük meg a dolgát. Köszönöm hogy szólhattam
/offtopic off

Szia Jeti,

Elég sok kérdésednek nincs köze az IPv6-hoz, és eléggé eltérő dolgokra kérdeztél rá.
Az 1, 2 , 3, 5, 9, 10, 11 olyan kérdések amelyeknek még megerőszakolva sincs köze magához az IPv6-hoz, illetve maga a megválaszolásban nem kell külön használni az IPv6 kifejezést (nincs kapcsolat)
ezek egy része hálózati kérdés (1, 2, 3) ami hálózati ismereteket igényel. (ezek inkább papírbázisú könyvekből (javasolni nem tudok) vagy wikiből innen kezdve tudsz mélyebb ismereteket szerezni) a kérdéseidre specifikusan már előbb többektől megkaptad a választ.
A 4-es kérdés valódi IPv6 kérdés. Jelentős különbség lesz az IPv4-hez képest. Broadcast fogalma megszűnik helyette az Anycast és a Multicast veszi át ezt a szerepet, a kérdésedre igen a válasz.
Az 5-ös kérdés nem érthető számomra, tippelni sem tudok mit akartál kérdezni, azonos címeket felkonfigurálni? vagy mi ez?
A 6, os kérdés trükkös, mert itt áthallás van IPv4/ARP tekintetében. Az fog változni, hogy hogyan kommunikálnak az IP-vel ellátott eszközök illetve, ha lehet akkor a MAC helyére helyettesítsd be a EUI-64-et (au OUI-król Itt a MAC addressről (EUI-48/MAC-48/EUI-64) Itt olvashatsz. Vagy az IETF idevonatkozó szabványai doksijai adnak részletesebb képet.
A 7-8 az IPSec kérdés és csak annyiban érdekes az IPv6 hogy az IPv6 "kötelező" eleme az IPSec létezése (stack szintjén) de egyébként a kérdések a titkosítás, azonosítás és a IPSec ismeretének hiányára vezet vissza
A 9, 10 ,11 kérdés adat és kapcsolat titkosítással foglalkozó kérdés amit többen kiveséztek.

Semmiképp nem szerettem volna bántásnak szánni semmilyen hivatkozást arra, hogy esetleg nem elégséges a jelenlegi ismereted, csak épp nehéz lett volna enélkül válaszolni.

Annyit még: annak ellenére hogy sok éves bevezetésre kész stádiumban van az IPv6 néhány problémára semmilyen megoldás nincs. Azzal hogy az IPv4 címek igénylése megnehezül azáltal reflektorfénybe került az IPv6 bevezetése ismét, de a problémák még mindig léteznek, és maguktól nem fognak megoldódni

Az egyik ilyen probléma (migrációs jellegű gond):

A szálban elburjánzott az IPv6 NAT kapcsolata, amelynek én nem nyitnék külön topicot, sőt külön hozzászólást sem írnék.
Itt egyesek részéről a NAT úgy van kezelve: Ez egy tévesen security megoldásnak beállított megoldás, amelynek az IPv6 címtartomány méretéből fakadóan semmi értelme. Ez jól van így és nem is kell ez nekünk és nagyon gáz hogy egyáltalán létezik. Aki mást mond minimum "képzetlen".

Én ezzel valamilyen szinten nem értek egyet. Természetesen a NAT NEM egy biztonsági megoldás. Ez egy címfordítás amelynek a megvalósításából ered pár tulajdonság, amely az elterjedtségéből, a felhasználói rétegéből és a jelenlegi környezetből fakadóan fájdalmat fog okozni váltáskor. ezek a következőek:

Renumbering:

Jelenleg PA címeket használ a világ nagy része, így NAT nélkül szolgáltató váltásnál a saját belső hálózat újracímezése és a használt eszközök elérése gondot jelenthet. Erre a NAT kiváló megoldást adott. Most sem egységes a megoldás.

Otthoni (kis méretű hálózat szabvány környezet) felhasználók esetén eszközcserével és némi plusz technológiával ezt át fogják vészelni (bár nem fájdalom nélkül)
A nagyobb hálózatok ahol nat van (nem szolgáltató, hanem vállalkozás) példáúl PI címtartomány igénylésével kerülheti el ezt a problémát. Persze a RIR-ek ezentúl sem fognak örülni a PI kérésnek tehát marad a trükközés.

Több szolgáltató probléma (site multi-homing)

Vannak olyanok akiknek nem elégséges valamilyen okból ha 1 kijáratuk van az internet felé, és nem annyira nagyok, vagy a NAT többi előnyél fogva nem kívántak külön erre a célra szolgáló megoldást találni. Továbbra is lesznek olyanok akik ebbe a státuszba fognak tartozni. Nekik a megoldás jelenleg nem létezik. Az IPv4 megoldás sem volt persze erre tökéletes de most egyszerűen kiváltó alternatíva hiánya lesz. Erre lenne majd kitalálva a Locator/ID Separation Protocol (LISP) IETF LISP draft
Ami még nincs.

Topológia elrejtés

NAT-ot használva elrejthető a mögötte lévő hálózat topológiája, és mérete (persze ez nagyon sok hátránnyal is jár a különböző hálózati alkalmazásoknál)
Nincs alternatíva jelenleg RFC által. A sugalmazott megoldások (host route-ok menedzselése, vagy mobil ipv6 tunnellel nekem picit nevetséges)

(és a kedvenc emlegetett) Egyszerű biztonság

A NAT sokszor van így alkalmazva, és a hatása jó, mivel a képzetlen és tanulni nem is akaró embereket valamint a default konfiggal kiadott (és 4 évig úgy használt) hálózati eszközöket valamennyire megvédi.
Ennek azonban van alternatívája a stateful filtering. Ebből a szempontból szinte ugyanaz( a többi probléma megmarad), csak nincs címfordítás.

Igen lehet úgy tekinteni továbbra is, hogy a világ kis (és tudatlan) részét foglalkoztató probléma. Ettől ezekkel a problémákkal az IAB is foglalkozik RFC5902 ennek kifejtésére született. Persze ők is csak cipőfelsőrész készítők.
Aki pedig nem így gondolja, remélem ez jó vitaindítónak.