pocitac s adresou z rozsahu definovanym RFC 1918 klidne z Internetu dostupny byt muze. Staci spatna konfigurace na strane zakaznika a spatny nebo zadny filtr na rozhrani u ISP.
To, ze si nekdo neumi naklikat pravidla do firewallu by nemelo byt zaminkou k tomu, aby se preklad adres vydaval za (nebo dokonce pouzival jako) bezpecnostni opatreni.
Hloupe je, ze s opustenim site-local adres odpadl jeden ze zpuspobu, jak inteligentne provozovat IPv6 v CZfree.Net bez toho, ze by ta sit byla zavisla na jednom ISP nebo musela sama platit za LIR.
Ale kdyz se kaci les a znasilnuji spravkyne, holt litaji trisky.
K tomuto tvrzeni mam dve vyhrady.
Jinak k tomu nasilneni spravkyn... nepripada mi to jako dobry napad ciste proto, ze z podstaty nasilneni se na antikoncepci prilis nehledi a takovi "nehodni" spravci, pouzivajici nepovolene mechanismy by se tedy mohli spis mnozit. Na druhou stranu nasilneni spravcu taky neni asi to z orechu.
Honza
Jinak nevim proc se tak rozohnujete proti NATu (ne 1:M, ale 1:1) - ja si naopak dovedu dobre predstavit tehcnologie, ktere toho budou schopny efektivne vyuzit od rozkladu zateze, pres jednoduchy presun destinace v ramci firemni infrastruktury apod... - on NAT 1:1 (reps. abych byl presnejsi, zamerny a vedomy prepis src nebo dst adresy/portu) ve sve podstate tak spatny neni...
Z toho vseho pak plynou nektere problemy s "chybejicim NATem v IPv6" - nekteri se proste hrozi toho, ze to znamena, ze tam nemohou existovat firewally (cimz nerikam, ze to je zrovna tvuj problem)...
Myslenka NATu je neslucitelna s integraci end-to-end autentizace do sitove vrstvy. A jakkoli lze souhlasit s tim, ze NAT 1:1 (myslim ten pravy, ne jen stavovy filtr) tak spatny neni, to co poskytuje neni tak nepostradatelne (a je to pomerne snadno dosazitelne jinymi prostredky) aby stalo zato kvuli nemu odmitnout integraci autentizace ...
A co se tech slusnych ISP s ADSL - jestli jich je moc nevim. Me staci kdyz je jeden a ma jen trochu prijatelne ceny. GTS mi k tomu nejlacinejsimu ADSL dalo verejnou adresu automaticky. Dokonce povazovali za samozrejme, ze to bude pevna IP a byli bez problemu srozumeni i s tim, ze pozaduji nastaveni konkretniho reverzniho zaznamu k takove adrese (tedy, ze tam nechci ten jejich "defautlni"). Tim se rozhodne vyrazne lisili od Telecomu, ktery mi celkem jasne sdelil, ze k nejlacinejsimu ADSL verejnou adresu nedostanu. Ani za priplatek (takze na pevnou jsem se ani neptal).
Zřejmě jste dosud neslyšel o automaticky přidělovaných link-local adresách a bezstavové autokonfiguraci (router advertisement). Jinak byste věděl, proč je nejmenší delegovaný rozsah /64 a proč by 64-bitové adresy nestačily.
Mimochodem, občas s trochou nadsázky tvrdím, že IPv4 adresy už pravděpodobně došly, jen jsme si toho pro samé maškarády zatím nevšimli...
IPv6 vyzaduje aktivni ucast routeru pro autokonfiguraci, proto je IM(NS)HO ekvivalentni DHCPku.
Za prvé: bezstavová autokonfigurace sice vyžaduje aktivní účast routeru, ale na rozdíl od DHCP ale nevyžaduje aktivní účast klienta. Za druhé: slovo bezstavová vyjadřuje skutečnost, že na rozdíl DHCP serveru nepotřebuje router udržovat žádné tabulky toho, co a na jak dlouho komu přidělil a co má ještě volné. Router neví a ani nepotřebuje vědět, kdo si co autokonfiguroval (klienti se mu nehlásí). Takže ekvivalentní to rozhodně není, radvd je naprosto triviální, přesněji řečeno, byl by, kdyby zároveň neimplementoval ještě další věci, např. podporu pro mobilní klienty.
Implementace přidělení nameserverů by byla hodně nesystémovým krokem, protože by se tím otevřela pandořina skříňka. Za půl roku by někdo přišel s tím, že stejným způsobem by se mohly šířit i informace o přidělených MTA, za dalších půl roku POP3 servery a nezastavilo by se to nejspíš nikdy. Proto je IMHO lépe, že bezstavová autokonfigurace řeší pouze přidělení adresy a směrování, tedy informace podstatné pro síťovou vrstvu. Problém s konfigurací DNS by se dal řešit jinak, napadá mne třeba vyhrazená anycast adresa pro tyto účely (ale detaily jsem nerozmýšlel, možná tam bude nějaký háček).
Pokud se nejedná o dynamické směrování, pak nemusí udržovat žádné stavové informace. A i v případě, že se routuje dynamicky, je množství těchto informací dáno množstvím routerů, ne množstvím klientských stanic. Spousta stavových informací naopak odpadne díky tomu, že nebude potřeba stavový NAT.
Co je u routeru hlavně důležité je routování. A to je při daném počtu uzlů tím pomalejší, čím je adresní prostor řidší.
Můžete tuhle úvahu nějak blíže vysvětlit? Nenapadá mne jediný důvod, proč by to měla být pravda.
Ano, určitá část operací s paketem bude trvat čtyřikrát déle. Ale bude to jen velmi malá část. V žádném případě to nebude tak, že by routing běhal čtyřikrát pomaleji. Spíš bych se hodně divil, kdyby to zpomalení bylo více než v řádu jednotek procent. Dokonce přímo jeden z vámi zmíněných odkazů uvádí, že při použití vhodného algoritmu je například časová náročnost vyhledání nejvhodnější položky úměrná logaritmu délky adresy, tj. i tato specifická operace se prodlouží v poměru 7:5, ne vámi uváděných 4:1.
Doufám, že jste to myslel úplně jinak, než jak jste to napsal. Z takového přístupu by mi totiž docela běhal mráz po zádech. Stačí, že je většině autorů webových stránek lhostejné, co je ve specifikacích HTML, CSS, DOM apod. Neláká mne představa, že by stejně měly dopadnout síťové komunikační protokoly.
ČLÁNKY DO MAILU