Szokatlan IPv6 kérdések

 ( jeti | 2011. március 19., szombat - 8:20 )

Sziasztok!

Lenne néhány szokatlan gyakorlati kérdésem az IPv6-al kapcsolatosan. Már régóta elgondolkoztatnak. Átnéztem néhány magyar nyelvű leírást. Elolvastam az első bejegyzést a http://hup.hu/node/71645 fórum témából, átlapoztam a többit és rákerestem néhány kulcsszóra de nem találtam rájuk választ. (Még az elején leszögezem, hogy nem vagyok informatikus...)
Kérdések:
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?)
2.) A nagyobb honlapoknak több IPv6-os címe lesz?
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?
4.) Lesz olyan közös hálózati cím, amivel az összes hálózatban jelenlevő gép elérhető?
5.) Hogy oldják meg, hogy több különböző otthoni hálózatokat ne lehessen 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?
7.) Az IPv6 IPsec esetében a kezdeti küldő és a végső fogadó tudja csak feloldani a titkosítást?
8.) Az IPv6 IPsec előbb-utóbb kiváltja a jelenleg használt titkosított adatátvitelt? Ha nem, miért?
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?)
10.) Kiválható lesz az SMTPS és a POP3S?
11.) Kiváltja az IPv6 a https-t, a SSL-est és a TLS-est? Minden gépnek lesz valamilyen tanúsítványa?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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.

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

Wikipedia írta:
IPv6 does not implement traditional IP broadcast, i.e. the transmission of a packet to all hosts on the attached link using a special broadcast address, and therefore does not define broadcast addresses. In IPv6, the same result can be achieved by sending a packet to the link-local all nodes multicast group at address ff02::1, which is analogous to IPv4 multicast to address 224.0.0.1. IPv6 also supports new multicast solutions, including embedding rendezvous point addresses in an IPv6 multicast group address which simplifies the deployment of inter-domain solutions.

3. Szerintem arra gondol, hogy az IPv6-tal el fog tűnni a NAT-olás

Miert tunne el? Maga a NAT lehet hogy el fog tunni, de vele ekvivalens megoldas biztos hogy lesz, ez az egyik legjobb modja a belso halozat vedelmenek.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

el fog tűnni a NAT. a megoldást úgy hívják: csomagszűrő :)

biztos, hogy a NAT védelmet "ad" a hálózathoz?

Hadde eltéved benne a hekker!!! Elvégre Naon Athatolhatatlan Terulet.
--
Solaris Express, Opera, OpenOffice.org, Yebol

Nem, nem ad védelmet

Ez így van! A tűzfal teljesen túl van értékelve, a NAT a legjobb hálózatvédelem! xD :D :D :D

Nem, a nat most sem ad védelmet

He?
Felejtsétek már el, hogy a NAT önmagába hú de secure és tűzfal megoldás..
A NAT el fog tűnni, mivel v6-on nincsen. A Cisconak van jelenleg egy NAT64 nevű förmedvénye, ami annyit tesz, hogy v6 címeket natol v4-re. Nem kommentálnám...
--
Discover It - Have a lot of fun!

Figy, én nem szeretnélek megbántani, van a vasúti lassító, azt is át lehet ugrani, sőt nagyon nem is kell erőlködni, de pont a nagymamák és a 3 éves gyerekek nem fogják átugrálni maguktól. Nem kellene dérrel dúrral harsogni: a nat nem védelem. De az. De facto elég kényelmes és hasznos, ha nem lennének az "internet routernek" csúfolt förmedvények akkor sokkal több problémával küzdenénk mint jelenleg. Ezért hasznos a NAT.
Senki nem mondta hogy tűzfal. A címfordítás ettől még ebből a szempontból jó dolog.
A NAT implementációjának a hiánya csak az átállás bonyolultságát növeli, ha részt veszel majd migrációba rájössz...
Amúgy személyesen tele van a tököm azzal, hogy ha biztonságról van szó, akkor semmi nem elég.
Pontosan egyfajta biztonság van: a kifizethető és megtérülő biztonság. Ez a minimális védőháló fog eltűnni mivel a felhasználói hálózatokat a kutya nem fogja védeni, ha nem terjed el valami okos megoldás.
A migráció folyamatát (4->6) gondold végig, meg hogy ki lesz benne érdekelt.

Természetesen igaza van willy-nek: neki, és mindazoknak akiknek egy csomagszűrő tűzfal bonyolult, hatalamas problémáik lesznek később tudatlanságuk miatt.

Hohoho tudtam :) Trolljunk akkor:)
Ha már itt vagy, elmondhatnád a tudatlanoknak ki fog kimenni a juzerhez csomagszűrő tűzfalat telepíteni és ha megjön a rokon Piripócsról beállítani? Hmm.....
Ja megvan, valaki leszűri az arra routeolt összes IPre a használt portokat, sőt! protokollanalízert telepít az összes felhasznált protokollra. Vagy csak egyszerűen conntrack-el elkezdi szűrni a kapcsolatokat. Hoppá majdnem nat lite :)
De egy biztos. Te nagyon jó vagy ebben. Látható. Ismered és érted a probléma lényegi részét. Komolyra fordítva a szót: nem az a kérdés _lehet-e_ jobban, hanem az hogy _megéri-e_ jobban, és _valaki_ megcsinálja-e.

Nyilvánvalóan nem te fogsz router firmwaret készíteni az otthoni felhasználóknak, hanem nálad hozzáértőbb emberek, akik ugyanúgy beállítják az inbound szűrést ahogy jelenleg is megteszik, plusz most még a NAT-ot is. Neked mint egyszerű felhasználónak nem kell aggódnod, csak bemész a boltba, leveszel egy IPv6-ready linksys vackot a polcról, és biztonságban leszel default.

Ne félj.

Megnyugodtam, most hogy te mondod.
Sikeresen visszajutottunk oda, hogy a NAT hasznos, és szükséges biztonsági szempontból, és ki kell találni valamit helyette ha nem lesz. Nekem ennyi elég, hogy elismerted.
Mivel elképzelésed nem tér ki arra, hogy előbb lesz e a váltás kényszere, mint hogy ilyen eszköz tömegesen a felhasználók részére elérhető legyen valamint elmegy a mellett, hogy vizsgálná mostaninál van e egyszerűbb és váltás szempontjából optimális inbound szűrés amit most úgy oldanak meg: NAT és kész. (nem elfelejteni migráció nem 1 eszköz cseréjét jelenti)
Lehetőség beállítható szűrésre a normálisabb hwben most is van (ez az amiről azt fantáziálod, hogy valaki is használja). Most mindent megoldva csak arra kell várnunk nem létező eszközök (vagy legyen neked csak cserefirmwarek) kinőnek a földből.
(igen megpróbálok végig elmenni amellett. hogy segghülyének nézel. egyszerűen ismerlek, élvezd. én nem bosszankodok)

Ez egy vicces thread, de ide vonatkozik egy kérdés, ami igen csak elgondolkoztat, és ha már mindenki nagyon érti itt az ipv6-ot, hát nosza rajta.

NAT jó tulajdonságai:
-Elrejti a belső hálót a publikus tartományokról.
-Migrálhatóvá válik a belső tartomány.
-Okos routing protokoll/redundáns gateway protokollal, akkora redundanciát viszek a rendszerbe, amit nem szégyellek, esetleg enged a pénztárcám/képzelőerőm.

Na erre most jön az IPv6 jön, hogy mindenkinek lesz szép publikus címe. Akkor hogy is lesz megoldva, hogy 2 szolgáltatóm legyen és a klienseimnek ne legyen kiesése 1 szolgáltató kimaradása esetén?

Lehet, hogy a protokoll kész és várja a bevezetést, de hol vannak a felkészített RG-k, UTM-ek amik el is viselik ezt a megálmodást?!

Most is ugyanúgy redundássá teheted, a legkisebb kiosztható tartomány /64, az enduserek is ezt kapják, azaz egyetlen user a jelenlegi teljes v4 tartomány többszörösét kapja... De akinek ez nem elég, annak ott vannak a link local-os fe80::/8 címek, amit ugyanúgy bedughatsz egy load balancer vagy proxy mögé, és kifele nem fognak látszani.

A routing egyszerű, ugyanis ha nincs route, akkor nincs route. Nyilván nem egyforma preferenciával van a kettő. Ha lehal az elsődleges, akkor az a gateway, ami nem tudja továbbítani a csomagot, icmp-vel visszaüzen, hogy no route, így a kliens megy a másik, nagyobb metric számú default gatewayre.
--
Discover It - Have a lot of fun!

Ez egy igen szép mondat, hogy a jelenlegi teljes címtartomány többszörösét kapja, igaz is. Csak a gondolkodásmód más kicsit mögötte.

A link local-ról átmegyek global-ra megoldást fontolóra vettem már akkor, mikor írtam a bejegyzést. Sőt multi-home-ra is keresgétem megoldást. De a te válaszod sem állt itt eddig. Köszi.

Az igaz hogy NAT PAT formájában nincs jelen ip6tables-ben, de ami van ua tojások csak felülnézetben. :)

  1. RFC 2766 NAT-PT
  2. RFC 4864 Local Network Protection for IPv6
  3. RFC 5902 IPv6 NAT Considerations

--
Solaris Express, Opera, OpenOffice.org, Yebol

Köszi, ezeket átolvasom. :)

Ne siesd el. Inkább ez a jellemző.
Mindenki rendelkezik valamilyen infóval.
Nem tudja eldönteni, az megvalósítás vagy agyalás.
pl. RFC2766 obsolate mivelhogy RFC4966 ...

Azért nem olvasok ilyen gyrosan. Egyelőre a címzéssel / címekkel ismerkedem. Az már ( már amennyire ) biztos.

sub

Ugyanúgy lesz megoldva, ahogy az internet IPv4 routolása működik idestova 30 éve (nem túl meglepő módon).

Szerintem az lehet, hogy még soha nem láttál hálózati interface-t, és ezért nem tudod, hogy mindegyikre fel lehet húzni több IPv4 vagy IPv6 hálózati címet is.

Ó hát persze. Nyilván erről van szó. :)

De ha már secundary címről beszélünk, akkor el kell, hogy mondjam, hogy egyáltalán nem szellemes és szép megoldás.
El kell ,hogy keserítselek és kiábrándítsalak a write only módból, feljebb már kerestük / találtunk tiszta megoldást. A tiéd minden csak nem az. Ha te minden hosztot duplán akarsz autokonfigoltatni, felügyelni az a te szíved joga, csak a fellengzősséget és a lekezelést hagyd otthon a szakmai vitákból mert más szálon is estél már magas lóról pofára.

Semmiféle "secundary" címről nem volt szó, mesterem ;(

Nos, ezzel a "secondary címmel" nem nagyon tudsz mit kezdeni, ugyanis az fe80 link local cím már akkor megjelenik az interfészen, amikor a kernel modult betöltöd.
--
Discover It - Have a lot of fun!

Igen, és a OS network stack nem szellemes, és ebből kifolyólag pofára estél. ;(

Nyilvánvalóan.
Viszont, én egy kifejezett problémára kerestem a választ. :)

Ó, dehogyis vagy te segghülye, mindössze van néhány megmosolyogtató feltételezésed:

- aki consumer-grade IPv6 routert dob a piacra, az kifelejti belőle a bekapcsolt tűzfalat ("meh! mesterségesen generált igény.")

- a desktop OS-ekben nincs tűzfal

- forradalmi hirtelenséggel (lásd Líbia) fog fellépni az IPv6 igénye az otthoni egységsugarú felhasználóknál, az ISP-k pedig inkább a tömegbe lövetnek (nem hallottál a Carrier-grade NAT-ról, de ez nem a te hibád hiszen más a szakterületed, egy cipőfelsőrész-készítőtől sem várható ez el például)

- aki most IPv4 hálózatokkal foglalkozik, az az IPv6 konfigurációjakor mágikus hirtelenséggel elfelejti mik azok a tűzfalak

Kétségkívül valós veszélyforrások ezek. *nod*

Ismétlem: nem kell rettegned, becsületes kétkezi munkád internetes részét (meg a fészbukkolást) ugyanúgy folytathatod biztonsággal az IPv6 mellett is, hála nekünk, akik ezzel foglalkozunk.

- aki consumer-grade IPv6 routert dob a piacra, az kifelejti belőle a bekapcsolt tűzfalat ("meh! mesterségesen generált igény.")

Az a baj a te fejtegetéseddel, hogy te sugallod: a megoldás kész van. Mivel láthatólag halovány lila gőzöd nincs arról, hogy milyen buktatók vannak egy hálózati migrációról. Ez azon nyilatkozataidból szűrhető le amikor a clean és a "majd létrejön és működni fog, megoldják". Az IPv6-al ez a fázis 2004-óta tart folyamatosan. Nem azért nem állt át a világ mert "nem volt kedve", hanem mert nem volt lehetősége.
Senki nem állította: "nem lehet megoldani" "senki nem akarja megoldani" "direkt szabotálják" csak azt "nem olyan egyszerű nagy méretben" "nem kompatibilis" "kitaláljuk hogy legyen fázisban van"

Sokszor hallom ezt, fel kellene fogni: az elejéről építkezek és meglévő rendszert állítok át az nem ugyanaz. Erre léteznek mechanizmusok, amelyek között lévő döntés sem egyszrű (A+P, NAT64, DSLite).
Nem is neked írom persze, tudom elvi problémád van sok mindennel, ez személyes dolog amit veled ellentétben megpróbálom kihagyni egy szakmai vitából.

- a desktop OS-ekben nincs tűzfal
Mint ahogy most is van. És van még rengeteg "Internet security" meg "3dparty firewall" megoldás. Ennek ellenére (sőt) mégis jó ha a klienspc el van dugva nat mögé. Ennek nagyon sok oka van, főleg a pc irányítójának erre alkalmatlansága.

- forradalmi hirtelenséggel (lásd Líbia) fog fellépni az IPv6 igénye az otthoni egységsugarú felhasználóknál, az ISP-k pedig inkább a tömegbe lövetnek (nem hallottál a Carrier-grade NAT-ról, de ez nem a te hibád hiszen más a szakterületed, egy cipőfelsőrész-készítőtől sem várható ez el például)

Nem tudom mennyire fog forradalmian előfordulni, csak azt tudom nagyjából mit szeretnének a rir-ek. Azt meg nem tudom miért hozod ide az LSNAT kérdését, mivel a jelenlegi fejtegetéstől teljesen eltérő probléma.
Ott a szolgáltató kontrollja alatt van az egész egyedül a klienskészülék ipv6 támogatásán múlik a megoldás, meg pénzen. Míg amiről mi beszélünk, emberek 100millióit érinti, és nincs kontroll rá.
Ha ez olyan lassan történik, hogy fel tud készülni rá az ipar (azaz 1 éven belül a forgalomban léteznek majd ipv6 hálózatot ilyen módon támogató és közös felkiáltással elfogadott elven működő igd-k ) akkor van esély hogy fájdalom nélkül 4-5 éven belül váltás legyen).
Amennyire rálátok egyik időpont sem 100%-os, és valószínű hogy a migrációnak hamarabb kell lezajlania. Az LSNAT-ot hagyjuk ki ebből, tudatos zaj csak ebben a beszélgetésben.

- aki most IPv4 hálózatokkal foglalkozik, az az IPv6 konfigurációjakor mágikus hirtelenséggel elfelejti mik azok a tűzfalak
Mégegyszer: senki nem kifogásolta, hogy nem lehet megoldani. Csak azt, hogy mennyire lesz ez kiváltása a mostani működésnek és milyen kompromisszumokkal jár. Valamint, mennyi időt fog igényelni.

"Ismétlem: nem kell rettegned, becsületes kétkezi munkád internetes részét (meg a fészbukkolást) ugyanúgy folytathatod biztonsággal az IPv6 mellett is, hála nekünk, akik ezzel foglalkozunk." G.

Ki fogom tenni papírlapon (csak addig míg valami normális módját nem találok, e felbecsülhetetlen analízis méltó megtartására) az irodám falára, tanulságos lesz, és megint lehetőség hogy beszélgessük az emberi mentalitással a hozzám érkező partnerekkel. Köszi

örülök hogy segíthettem Az Irodának

Partnereidnek gyakran eladod a NAT-ot mint biztonsági megoldást?

"Mint ahogy most is van. És van még rengeteg "Internet security" meg "3dparty firewall" megoldás. Ennek ellenére (sőt) mégis jó ha a klienspc el van dugva nat mögé. Ennek nagyon sok oka van, főleg a pc irányítójának erre alkalmatlanság"

Ha van egy gatewayed, és azon egy firewall. A firewall SZŰRI a kintről befele menő forgalmat, akkor a kliensen édes mindegy, hogy milyen tűzfal van, mert ha jó a külső tűzfal, el se fog jutni odáig a kintről jövő forgalom. Legyen itt most akár NAT-olt belső hálóról, publikus v6, vagy akár publikus v4 címmel rendelkező egyszerű kliens desktopról szó. Amit a belső hálózat határpontján, a gatewayen vagy a tűzfalon tiltasz forgalmat, egyik esetben sem juthat el a kliensre.
Az, hogy a klienseken is van tűzfal, csak növeli a biztonságot, illetve a hálózaton belülről érkező támadások ellen véd (mert ugye nem csak kívülről lehet támadni...).
--
Discover It - Have a lot of fun!

Mint ahogy a NAT is noveli a biztonsagot, leven en ugyan tamadhatom a 10.0.20.15-os gepet, csak pofara fogok esni, mert ez a range nem routolodik semerre se.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem bírtam megállni, hogy ne linkeljem be.
Tessék végigolvasni! Cisco-s forrás, talán értenek hozzá valamit.

http://www.6diss.org/publications/presentations/hain-security.pdf

Jó összefoglaló, tetszett.
--
Discover It - Have a lot of fun!

Persze. A RFC 4864 anyagát demózza (hisz ő az egyik szerző)
Akkor most légyszi nyilatkozz a lentebb említett RFC 5902 vel kapcsolatban.

Neked semmit sem kell tenned. Ugyanúgy megveszed a boltba a routert, vagy frissítesz firmwaret a jelenlegin, beállítod a pppoe-t vagy amit kell, és működni fog.
Ugyanúgy van most is minden szappantartón tűzfal, ami a bejövő forgalmat eldobja vagy továbbküldi (port forward résznél ezt állítod), emellett PLUSZBAN van nat funkció.
--
Discover It - Have a lot of fun!

Loop.
Kijelented: "NAT nem használható biztonságra. Felejsd el." Felhívom a figyelmedet, hogy de bizony sokat köszönhetünk neki, mert prompt jellegű biztonságra és szeparációra jó és nélküle ma káosz lenne.
Erre elmagyarázod nekem, mint "usernek" hogy majd bemegyek a boltba és kicserélem a routert egy másikra, vagy lefrissítem ahhoz hogy (ha ilyet egyáltalán lehet) ne vegyek észre semmi és ugyanolyan legyen minden mint eddig.
(majd persze mindent ismét beállítok)
Kérdés: Van tapasztalatod felhasználókkal? Mert látszólag semmi.
Azon a port forward részen jót mosolyogtam, jó is így, a beírásod komolyságát megalapozza.

Igen, van.
1. a felhasználó be fog menni a boltba, venni egy routert. Adnak neki valamit.
* Hazamegy, bedugja, beállítja weben, vagy a hozzá kapott cdvel, ez most mindegy.
# ha megy, boldog.
# ha nem, vissza fogja vinni a boltba, hogy ez nem megy az ő netjével, cseréljék ki, vagy adjanak másikat
* Hazamegy, felhív, hogy vett egy ilyet, gyere és állítsd be. Elmész, beállítod.
2. a felhasználó szól neked, hogy kell neki egy ilyen. Megveszed, elviszed, beállítod.
3. a felhasználó szól, hogy nem megy rendesen a netje.
* elmész, megnézed, frissítesz firmwaret, és megy tovább.
* elmondod neki, hogy ez a sokéves cucc nem fogja ezt tudni, venni kell újat

Kb. ennyi a lehetőség.

Nem értem mi olyan mosolyogtató a port forwardon... De legyen.

--
Discover It - Have a lot of fun!

willy-nél az a probléma hogy nem az informatika a szakterülete, ezért még nem látta hogyan semmisül meg a NAT-ra alapozott "védelme" egy UPnP/NAT-PnP-s portforward létrehozásától.

Cisconak van jelenleg egy NAT64 nevű förmedvénye, ami annyit tesz, hogy v6 címeket natol v4-re. Nem kommentálnám...

Volt egy ilyen mondatod, ekkor arra gondoltam: van már valami olvasmányos tapasztalatod erről, de nem igazán kellett ilyennel foglalkoznod. Légyszi nézz körül IPv6 transitions témában a neten. Nem csak a cisconak fáj a feje ettől hanem nagyon sok embernek. Mint ahogy ez sem egy "cisconak a förmedvénye"

A fenti szkenáriókkal az a gond hogy az eszköz jelenleg nem létezik, ezért nem tudsz példát mondani, hogy majd azzal és úgy. Nem számolsz az otthoni eszközök élettartamával, illetve az átállási költséggel. Illetve hogy mikor teheti meg a szolgáltató hogy váltson.

A NAT amellett, hogy most elrejtvén a kliens gépeit ad némi prompt jellegű védelmet sok minden mást hozott be a "party"-ba aminek sok köze nincs ahhoz amit beszélünk, pár ilyen meg lett említve más által.

Akkor csak a beszélgetés hitelessége miatt itt egy ábra hogy mi a javasolt megoldás mi helyett (elég jó összefoglaló ábra): RFC4864 4. oldala lehet tanulmányozni a megoldási javaslatokat.

A NAT64-re azért van szükség, mert főleg a távolkeleten már teljesen elfogytak a v4 címek. Az eszközök csak v6 címeket kapnak. Lehet bármilyen technikai kütyüre gondolni, de elsősorban azokról van szó, amikből sok van, és internetezésre alkalmasak. Pl. telefonok, tvk, settopboxok. Az iptv-vel nincs probléma, v6-on elmegy az egész, a saját, területen/régión belüli böngészéssel sincs, mert szintén elérik v6-on a legtöbb tartalmat. De használni akarnak mást is, akár egy facebook, amazon, vagy bármi, ahhoz van szükség erre.

Ez a förmedvény "szükségből" született, de attól még egyáltalán nem elegáns. Ennek az az oka, hogy a fejlesztéseknek, átállásoknak évekkel ezelőtt el kellett volna kezdődnie azért, hogy legyen idő mindenhol fejleszteni, bevezetni. A zökkenőmentes átállás akkor valósult volna meg, ha mindenhol, jópár évig párhuzamosan megy a v4 és a v6. Fentebb említetted, hogy jelenleg nem nagyon lehet olyan SOHO routert kapni, ami v6 capable... Ennek is ez az oka. De hidd el, ha majd azért fogod A gyártó eszközét venni, mert tudja a v6-ot, B gyártó azonnal ki fog dobni firmware-eket és új eszközöket, amik tudják, mert akkor már profittól esnek el.
--
Discover It - Have a lot of fun!

A nat mellet ott a csomagszűrő és az adja a védelmet.
A nat nem.

>a NAT az egyik legjobb modja a belso halozat vedelmenek

i wanna cry

Nem, a nat nem ad védelmet.

MAC cím az internetes kommunikáció legalja, a fizikai réteg.

Helyesen:

A MAC cím az internetes kommunikáció 2. rétegében, az adatkapcsolati rétegben lakik. (_HA_ a TCP/IP által az OSI modellből használt négy darab rétegre szorítkozunk.)

Fizikai réteg: bitek (elektromos jelek)
Adatkapcsolati réteg: keretek
Hálózati réteg: csomagok (IP cím)
Szállítási réteg (TCP protokoll)

--------------------------------------------------------------------------
színes

I stand corrected. Köszi a pontosítást.

"...MAC cím az internetes kommunikáció legalja, a fizikai réteg."

NEM. a MAC az L2 adatkapcsolati/Data Link layer.

subscribe

én is

en nem. oh wait.

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.

Igen, a kerdezo keveri az IPsec es a SSL/TLS fogalmat. Az elobbi egy tunnelezesi megoldas, ekkor minden forgalom (fuggetlenul a protokolljatol) titkositva kozlekedik, a SSL/TLS eseteben viszont egy egyszeri kiszolgalo/ugyfel kommunikaciorol beszelunk. Nem hinnem, hogy azert az atlag nyolcvan kilobajtert, amit egy atlagos user letolt a levelezoszerverrol, erdemes lenne connection-onkent IPsec kapcsolatot felepiteni. Eroforraspazarlo es felesleges.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Arra kiváncsi vagyok, hogy miként fog történni az otthoni routerek árusítása és beüzemelése.

A NAT-nak rengeteg hasznos alkalmazása van, például tesztrendszerek esetén nem kell átírni IP címeket stb.

Miaz, hogy nem kell átírni IP-ket? Mert amúgy miért kéne?
Nem értem mit akarsz ezzel mondani.
--
Discover It - Have a lot of fun!

Valószínűleg arra gondol, hogy jelenleg fog a belső hálózatán egy tetszőleges privát tartományt, beállítja a gépét mondjuk 192.168.1.1-nek, aztán észrevétlenül váltogathat WAN IP címet, a belső háló szempontjából minden változatlan.

IPv6 esetében - NAT hiányában - azonban az aktuális WAN kapcsolat által biztosított prefixszet kell behoznia a belső gépeire is.

Magyarul, a belső gépek címei függenek a pillanatnyi netkapcsolattól, hacsak nem használ házon belül link-local vagy IPv6 privát tartományú IP címeket, ezen esetben azonban minden belső gépének legalább 2 darab IP címe lesz. Márpedig, kénytelen lesz ez utóbbira, mert a belső hálózata csak nem állhat meg, ha mondjuk lepukkan a WAN kapcsolata, amikor a háza előtt elmarkolják az útépítők a kanócot.

Nem "kénytelen lesz", hanem ez a default ezer éve.

Olyan fogalmatlanság van itt IPv6 témakörben, hogy lefonom a szakállam.

Mily véletlen, hogy pont egy olyan IPv6 topicban szólsz hozzá ahol a nyitó posztban a kérdések 90% nincs köze az IPv6-nak, ezért blikkre megmondható, hogy offtopic lesz belőle, vagy elhal. Mi lenne (ha már kijelentésed szerint te vagy itt a master), ha feltárnád hatalmas tudásod a kérdezőnek? Ahelyett hogy nyomod az offtopic dumát.

Felesleges lenne itt IPv6-tal foglalkozni, lévén a kérdezőnek vajmi kevés fogalma van a hálózatokról úgy általában, sőt bevallása szerint is a hupról szerzett csak "ismereteket".

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!

A 6. "MAC v. IPv6"-ra nem mondanák ilyen egyértelmű nemet. Persze a jelenlegi modell szerinte nem ugyan az, de ha előre felé is tekintünk, nem annyira lehetetlen (bármikor megváltozhat a jelenlegi modell). Sőt a jelenlegi felállás szerint, a MAC address címtartománya kisebb, mint az IPv6, mi lesz ha az is elfogy?

Semmi különös, elkezdik elölről... Azért azt ne felejtsd, míg egy IP címnek worldwide van szerepe, és routeolható/azonosítható, addig a mac csak a hálózat egy szegmensébe van (az első routerig). Arra, hogy egy hálózatban két egyforma mac találkozik nagyon kicsi esély van, de ha mégis, mindegyik oprendszer alatt megvan a lehetőség 10 másodperc alatt módosítani.
Annyi összefüggés van a mac és v6 között, hogy ugye auto konfigurálásnál a mac címből csinál magának a kliens ipt. De ettől még nem valósítható az meg, hogy minden hálókártyához gyárilag hozzárendelt v6 cím legyen, és úgy vegyél mint mondjuk sim kártyát. Akkor kb. az egész jelenlegi hálózati struktúrát, protokollokat, routing algoritmusokat ki lehetne hajítani... Mobil hálózat kicsit másképp működik.
--
Discover It - Have a lot of fun!

Anno talán a SIS-nek volt egy olyan chipset sorozata, ahol a mac address (gondolom vmi hiba miatt) ugyanaz volt.

A UPC ügyfelek, akik olyan alaplapot vettek, amin ilyen NIC volt, meg rendesen szívtak emiatt, mert a mac address alapú regisztráció miatt szépen felülregisztrálták egymás adatait. (egészen addig, amíg kézzel meg nem változtatták a mac addresst)
(Persze ez csak azokat érintett, akiknek nem volt routerük, vagy a routerben klónozták a gép mac addressét...)

É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.

A nagy többség látná értelmét. :) IPv4-es ismeretekből kiindulva a már jól megismert és nagyon hatásos technológia az, hogy csak azt engedem ki-be vele, amit akarok. ( meg még itt van egy rakás másik protokoll ).

Több nagy hálózati eszközgyártó tananyában szerepel a mai napig, hogy a NAT jó. A nat alapvető feladata elsőkörben az ipv4 címek drasztikus fogyásának elkerülése volt. Aztán befutott egy olyan karrier-t amire senki sem gondolt.

Visszatértünk oda, ahonnan az ipv4 indult. Van tartomány, adok ki /8-at ( csak most maga a host azonosító rész következményeként létrejövő /64-es tartománnyal nagyobb címteret kapsz, a szabvány pedig legrosszabb esetben /56-ot ajánl az usernek, ami önmagában vicces ). De akkor nem volt mindenki ennyire szerencsés. Így jött be a NAT, és egy ráépült protokolltömeg, mint jól megszokott hálózati és alapvető védelmi elemek. és persze a zónázás. ami ilyen formában tiszta volt.

Lesz változás egy céges hálózat kialakításában?! Lesz. A hardveres tűzfalak/ips-ek piaca pezsdülni fog egyértelműen. De ez még egy nyitott, kevésbé átlátható piac.

Hála a magasságosnak, az itt a hwsw-n fellelhető "nagy többség" hálózati elképzelése borzasztóan fontos, ezért is lett az IPv6-ban NAT :)

Ha nem lenne fontos a nagytöbbség véleménye és ismeretanyaga, akkor a cisco cli nem maradt volna meg a 80-as évekbeli designnél.

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.

Én, mint IPv6 terén amatör, de talán már nem a cipőfelsőrészkészítő kategória, úgy látom, hogy NAT helyett "jobb" megoldás a külső és a belső hálót elrekeszteni egymástól. Hogy ne legyen mégse elvágva a felhasználó, NAT helyett vannak proxy szerverek, amúgy is a forgalom nagy része már weben folyik, de vannak más protokolhoz is proxy-k vagy egyszerűbb szerverek (DNS, SIP, SMTP/IMAP). Táveléréshez meg ott a jó öreg VPN. Persze így is van sok alkalmazás, aminek ez nem fog tetszeni.

Így a hozzászólás után 6 évvel és hol tartunk okoskodásnak van némi pikantériája :) Nekromanciának van foka?