Zpravodaj (3): Ve znamení zasedání IETF a IPv6

IETF se tento týden (17.-22.3.) schází ke svému již 53. zasedání, a to v Minneapolis. Setká se zde téměř 70 skupin, zejména k projednání svých vlastních pracovních návrhů (Internet drafts, I-D). Kromě plánovaných diskusí se sejdou také následující skupiny zájmové, Birds of Feather (BOF):

• Cross-Registry Information Service Protocol
• Extensible Authentication Protocol
• Incident Handling
• Keywords Naming Services
• Mobile Networks
• Network Data Management Protocol
• Next Generation Structure of Management Information
• Packet Sampling
• Protocol for carrying Authentication for Network Access
• Secure Internet Key Distribution

Fakta: nová RFC

Pro odkazy na RFC používám aktuální a autoritativní zdroj – RFC Editor. Kdo chce, může použít také zdroje lokální, o kterých ví.

V druhém březnovém týdnu 2002 bylo publikována jediné RFC:

APLIKAČNÍ VRSTVA:

RFC 3275 (Extensible Markup Language) XML-Signature Syntax and Processing, 2002 (Draft Standard, 73 stran): specifikuje pravidla zpracování a syntaxi digitálních podpisů XML. Ty poskytují službu integrity, autentizace zpráv a autentizace podepsaného, a to pro data jakéhokoli typu, ať jsou umístěna v XML zahrnujícím daný podpis nebo jinde.

Fakta: právě schváleno IESG
IESG (Internet Engineering Steering Group) schválila následující dokumenty, které budou záhy k dispozici jako informační RFC:

• Middlebox Communication Architecture and Framework (Informational)
• Middlebox Communications (MIDCOM) Protocol Requirements (Informational)
• URIs, URLs and URNs: Clarifications and Recommendations Report from the Joint W3C/IETF URI Planning Interest Group(Informa­tional)

Schvaluje se: místo pro vaše připomínky

IESG vyhlásila poslední kolo připomínek před schválením následujících dvou dokumentů, návrhů de facto norem (Last call):

Implicitní výběr adres pro IPv6

Default Address Selection for IPv6 (Proposed Standard, 23 stran; možné připomínky je třeba zaslat na iesg@ietf.org nebo ietf@ietf.org do 4.4.2002): specifikuje algoritmy pro implicitní výběr zdrojové a cílové adresy IPv6. Adresování v IPv6 dovoluje přidělovat více individuálních adres jednomu rozhraní (RFC 2373 IP Version 6 Addressing Architecture, 1998), které mohou být globálně jednoznačné (global), lokální (site-local) nebo rozeznatelné v dané síti (link-local). Adresy v rámci IPv6 lze kategorizovat podle stavu konfigurace (RFC 2462 IPv6 Stateless Address Autoconfiguration) na preferované (preferred) nebo potlačované (deprecated); nebo podle RFC 3041 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6, 2001) na veřejné (public addresses) či dočasné (temporary addresses). Připojení k více ISP (multihoming) vede k přidělení více adres jednomu uzlu, i pro virtuální rozhraní nebo rozhraní tunelu.

To znamená, že při zahajování komunikace se implementace IPv6 často setkávají s nutností výběru mezi několika zdrojovými a cílovými adresami. Proto je vhodné stanovit implicitní mechanismus jejich výběru, společný všem. U duálních implementací (IPv4 a IPv6) je navíc třeba rozhodnout, který z typů adres použít.

Algoritmy pro implicitní výběr adres budou implementovat jak koncové uzly, tak směrovače v IPv6 síti. Tento implicitní výběr nemá přednost před výběrem adres stanoveným aplikacemi.

IPv6 adresy v DNS

Representing IPv6 addresses in DNS (Proposed Standard, 6 stran; možné připomínky je třeba zaslat na iesg@ietf.org nebo ietf@ietf.org do 2.4.2002): aktualizuje stav RFC, která definují přímé a zpětné mapování adres IPv6 v rámci DNS. IETF původně přijala dva návrhy norem pro formát zápisů adres (resource records, RR) IPv6: AAAA (RFC 1886 DNS Extensions to support IP version 6) a A6 (RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering, 2000).

Zápisy AAAA se jeví jako přijatelnější pro rychlejší zavádění IPv6, včetně bezpečnostního mechanismu DNSSEC. Záznamy typu A6 mají sice zajímavé vlastnosti, ale je třeba jim ještě lépe porozumět. Důvody pro tyto změny jsou popsány v návrhu Tradeoffs in DNS Support for IPv6 (2001). Specifikace A6 a Bit label tak přecházejí do stavu experimentů (RFC 2673 Binary Labels in the Domain Name System, 1999, a RFC 2874 se tímto návrhem z Proposed standard stávají Experimental). Záležitosti kořenových serverů (root server) nejsou tímto dokumentem nijak dotčeny (RFC 3152 Delegation of IP6.ARPA).

Názory:

Zjistila jsem, že je docela poučné a zajímavé sledovat nejen oficiální dění na půdě IETF/IESG, ale také názorové přestřelky na ietf@ietf.org na nejrůznější technická témata. Mnohé názory se asi nebudou lišit od všeobecných, však se také jedná o diskusní skupinu, do které se může přihlásit každý. Přesto si je dovolím občas trochu parafrázovat a shrnout. Nejedná se o výklad RFC, ale přesto se lze čas od času dostat na kobylku některým méně zřejmým věcem s ohledem na správné fungování TCP/IP.

Názory v této podrubrice jsou parafrází názorů, které se objevily na ietf@ietf.org, nikoli moje vlastní. Lze ověřit zde. Další informace o diskusních skupinách se nachází zde.

NAT

Kolem překladu adres (Network Address Translation, NAT) bylo nedávno hodně živo. Někdo si postěžoval, že „NAT nepodporuje Netmeeting“ od Microsoftu. Netmeeting používá H.323 s IP adresami a dynamicky přidělovanými porty v rámci daného spojení (in-band). NAT si neporadí s překladem jiných než vnějších adres, dovnitř dané komunikace nevidí. Netmeeting také dynamicky volí port, který využije pro zpětné připojení, ale to neodpovídá tomu, jak svět Internetu vidí NAT, tj. komunikace probíhá mezi stejným párem zdrojového a cílového portu, pouze prohozených v opačném směru komunikace. Proto Netmeeting potřebuje skutečné IP adresy.

Samozřejmě se ozvala spousta ohlasů: NAT neladí s mnoha funkčními záměry a principy IP. Proto je nerealistické očekávat, že nejrůznější aplikace budou pracovat v jeho přítomnosti správně tak, jak byly navrženy. Mohlo by se zdát žádoucí, aby jej všechny aplikace tolerovaly. Ale taková tolerance často znamená významnou bariéru s ohledem na výkonnost, škálovatelnost (scalability – nemá někdo lepší české slovo?) i implementaci aplikací kvůli potřebě mezilehlých prvků pro tunelování skrze NAT.

Nejradikálněji v diskusi zaznělo následující zhodnocení NAT: NAT boří základní princip fungování TCP/IP, a to minimální intervenci, tedy „don't mess with stuff that's none of your business and is just passing through“ (lépe to snad ani vyjádřit nelze).

Humor:

Dnešní koutek humoru nemá nic společného ani s normami, ani se sítěmi, ale s technikou, nebo spíše s vítězstvím přírodních zákonů nad technikou. Série autentických fotografií sice spíše zpočátku vypadá, ale konec dobrý všechno dobré. Určitě si všichni zúčastnění na závěr zhluboka oddychli… a mohli se zasmát.