RFC sklizeň: IPv6, HTTP, Greylisting

RFC 6586: Zkušenosti s provozem IPv6-only sítě

Informační RFC 6586 popisuje praktické zkušenosti z poskytování přístupu k internetu pouze prostřednictvím protokolu IPv6. Bylo testováno jako domácí, tak kancelářské prostředí a pro propojení s IPv4 světem byla použita technologie NAT64/DNS64. Zkušenosti ukazují, že obecně je možné žít (a pracovat) pouze s IPv6; jeden z autorů tak žije již více než rok. Problémy obecně nemají běžné webové prohlížeče, e-mailoví klienti, nebo aktualizace operačního systému. Bez problému na IPv6-only pracovaly mobilní telefony platformy Symbian, platforma Android vyžadovala doinstalování programu DNS Discovery Daemon, aby byl operační systém schopen získat IPv6 adresu DNS serveru. Problémy na IPv6 autoři rozdělili do několika kategorií:

• Vady Spousta programů a komponent operačních systémů sice je schopna pracovat na IPv6, avšak vývojáři nepočítali s možností, že IPv4 nebude k dispozici. Program pak na takové síti vykazuje podivné chování.
• Chybějící podpora IPv6 Stále existuje spousta aplikací, které IPv6 jednoduše nepodporují. Kromě různých archeologických vykopávek se jedná i o některé vcelku moderní aplikace, jako Skype, ICQ, nebo drtivá většina newebových her.
• Přenášení adres v aplikační vrstvě Tento bod do velké míry souvisí s předchozím. Nejde jen o protokoly jako FTP, SIP, či Skype, které musí být upraveny, ale například také o odkazy přímo na IPv4 adresy na webových stránkách.
• Problémy s firewallem Spousta firewallů dosud není vyspělá natolik, aby dokázala správně detekovat fragmentovaný IPv6 provoz, který generuje NAT64 brána. Také je riziko problémů s MTU v případě, že nějaký horlivý administrátor zakáže na firewallu veškerý ICMPv6 provoz. S problémy MTU se však autoři dokumentu nesetkali.

Pozitivní na celém dokumentu je, že autoři nezaznamenali prakticky žádné problémy s technologií NAT64/DNS64 jako takovou. Pokud se časem zlepší situace s aplikacemi a hrami, bude možné považovat IPv6-only sítě vybavené NAT64 za rovnocenné konkurenty dual-stacku.

RFC 6598: Sdílený IPv4 adresní prostor pro potřeby Carrier Grade NAT

Jak se svět stále více blíží kompletnímu vyčerpání adresního prostoru IPv4, začíná se víc a víc poskytovatelů připojení poohlížet po implementaci Carrier Grade NATu (CGN). Jedním z problémů, které CGN při provozu v režimu NAT 444 přináší, je potenciální konflikt adresních rozsahů. Protože NATy uvnitř domácích směrovačů používají libovolné privátní adresy podle RFC 1918, není použití jakéhokoli z těchto rozsahů pro CGN bezpečné. Aby se zabránilo adresovému squattingu, kdy si provozovatel svévolně obsadí dosud nepřidělený nebo cizí adresní rozsah, byl výlučně pro potřeby CGN vyhrazen nový privátní rozsah adres 100.64.0.0/10, tedy celkem 64 sítí třídy B.

Zajímavou komplikací nově zavedeného rozsahu je problém s 6to4. Existuje spousta domácích směrovačů (mimo jiné i všechny počítače s MS Windows a službou Sdílení připojení k Internetu), které pokud detekují na vnějším rozhraní veřejnou IPv4 adresu, zprovozní automaticky 6to4 tunel a začnou nabízet do lokální sítě tunelované IPv6. Protože takovéto směrovače správně nerozpoznají nově vyhrazený sdílený adresní prostor, budou se jej snažit použít k navázání 6to4 tunelu, což se kvůli CGN nezdaří. Poměrně kontroverzní řešení problému nabízí vznikající návrh 6to4 Provider Managed Tunnels. Ten počítá s tím, že na úrovni CGN dojde zároveň k bezestavovému přemapování 6to4 prefixu do nativního IPv6 prefixu poskytovatele. Dá se říct, že jde o takový kočkopes technologií 6to4 a 6rd. Že takové NATování rozbije všechny protokoly, které přenášejí adresy v aplikační vrstvě, není třeba zdůrazňovat.

RFC 6603: Volba vyloučení prefixu z DHCPv6 delegace

RFC 6603 definuje novou možnost, jak může DHCPv6 server přidělit domácímu routeru IPv6 prefix, ze kterého je jeden delší prefix vyhrazen pro spojovací linku mezi domácím routerem a routerem poskytovatele. Díky tomu je možné agregovat provoz jednoho zákazníka do jednoho prefixu namísto stávající situace, kdy každý zákazník kromě vlastního prefixu používal ještě spojovací adresu pro komunikaci s routerem poskytovatele.

RFC 6585: Nové stavové kódy HTTP protokolu

I když to lidé z IETF jistě nevidí rádi, stále se na světě objevuje spousta implementací captive portálů. Jde o zařízení, která zneužívají HTTP protokol pro účely autentizace uživatele. Ten se připojí do sítě, otevře libovolnou stránku a je přesměrován na autentizační bránu, kde prostřednictvím formuláře zadá přihlašovací údaje a je vpuštěn do sítě. Pokud je přesměrování realizováno pomocí stavového kódu 302 a hlavičky Location, nedokáže prohlížeč ani jiný HTTP klient poznat, zda jde o legitimní akci cílového serveru, nebo „podvrženou“ odpověď od internetové brány. K vyřešení této víceznačnosti RFC 6585 zavádí nový stavový kód 511 Network Authentication Required. Tento stavový kód by neměl být nikdy odeslán koncovým serverem, ale pouze mezilehlou bránou. Stránka s tímto stavovým kódem by neměla obsahovat přihlašovací formulář, na ten by měl být uživatel přesměrován pomocí standardního HTML přesměrování, tak aby takové přesměrování následoval pouze webový prohlížeč a nikoli jiné aplikace, využívající protokol HTTP k transportu jiných dat. Tím se minimalizují škody, které jinak captive portály způsobují HTTP provozu.

Ke stavovému kódu 511 přidává dokument ještě tři další stavové kódy:

• 428 Precondition Required Tento stavový kód má řešit problém konfliktů nejen v REST, kdy klientský systém nejprve pomocí GET získá data, ta modifikuje a pomocí PUT odesílá. Tímto stavovým kódem server vyžaduje, aby požadavky na uložení byly doplněny hlavičkou If-Match. Tak je možné vyvarovat se ztrátě dat, pokud byla mezi načtením a uložením modifikována.
• 429 Too Many Requests Jak již titulek napovídá, tento stavový kód informuje klienta, že přesáhl administrativní omezení počtu požadavků a/nebo přenesených dat za dané období. Odpověď může být vhodně doplněna hlavičkou  Retry-After.
• 431 Request Header Fields Too Large Tímto kódem server informuje, že se požadavkem nebude zabývat, neboť velikost hlaviček odeslaných klientem přesáhla povolenou mez. Může jít jak o limit všech hlaviček dohromady, tak i o limit velikosti jednotlivé hlavičky; v takovém případě by měla odpověď obsahovat informaci, která hlavička problém způsobuje.

RFC 6647: SMTP Greylisting

Greylisting je poměrně známá účinná metoda, jak snížit množství nevyžádané pošty. Využívá prostého faktu, že spousta spambotů se nesnaží opakovat pokus o doručení, pokud první pokus z nějakého důvodu selhal. Poštovní server, který provádí greylisting, proto každou zprávu z neznámého zdroje dočasně odmítne a teprve pokud se odesílající server pokusí zprávu odeslat znovu, je zpráva přijata. RFC 6647 detailně popisuje možnosti realizace, stejně jako možná úskalí (zdržení legitimní pošty). Obsahuje i sedm praktických doporučení, jak greylisting nastavit a jak měřit jeho účinnost.

RFC 6592: The Null Packet (apríl)

Spousta dokumentů RFC se zmiňuje o nulovém paketu, aniž by byl explicitně definován. To má napravit RFC 6592, které vyšlo letos, prvního dubna.