Hlavní navigace

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

Rita Pužmanová

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í jejich vlastních pracovních návrhů (Internet drafts). Současně bylo schváleno RFC 3275 a několik dokumentů, které by záhy měly být k dispozici jako informační RFC.

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:

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.

Našli jste v článku chybu?

20. 3. 2002 9:16

Jan Hobza (neregistrovaný)
Dobrý den,
ETSI TS 101903 vychází z XMLDSIG verze 2.01. Souhlasím, že porovnávání obou verzí je práce nelidská. Proto se omezím na to, zda případné změny mohou být fatální. Pravděpodobně ne. ETSI TS 101903 v zásadě staví na definici Objektů, Podpisů (běžných) a Transformací z 2.01. Účelem TS je definovat požadavky na tři drumy XAdES a na jejich zpracování. Jelikož výše zmíněné definice jsou stavebním kamenem XMLDSIG, myslím že k zásadním změnám zde nedošlo. TS zároveň prezentuje kódy objektů ci…

20. 3. 2002 0:45

Rita Pužmanová (neregistrovaný)
Podle info v ETSI TS 101 903 (2/02) se vychazelo z W3C 08-2001(W3C/IETF Proposed Recommendation, August 2001): "XML-Signature Syntax and Processing", tj. navrhu RFC 3275. Specifikace by se tedy nemely podstatne lisit. Formalne vzato byl pro RFC 3275 nakonec prijat draft-ietf-xmldsig-core-2-03.txt, takze treti verze (z ledna 2002). Dohledat vsak informace o zmenach v navrhu mezi srpnem a koncem roku je prakticky nemozne. V archivu je pouze tato posledni verze I-D.

Doporucuji bud prohledat archiv …

Měšec.cz: U levneELEKTRO.cz už reklamaci nevyřídíte

U levneELEKTRO.cz už reklamaci nevyřídíte

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Vitalia.cz: Vychytané vály a válečky na vánoční cukroví

Vychytané vály a válečky na vánoční cukroví

Měšec.cz: Air Bank zruší TOP3 garanci a zdražuje kurzy

Air Bank zruší TOP3 garanci a zdražuje kurzy

Root.cz: Mirai má nový cíl 5 milionů routerů

Mirai má nový cíl 5 milionů routerů

Root.cz: Telegram spustil anonymní blog Telegraph

Telegram spustil anonymní blog Telegraph

Měšec.cz: Jak levně odeslat balík přímo z domu?

Jak levně odeslat balík přímo z domu?

Podnikatel.cz: Vládu obejde, kvůli EET rovnou do sněmovny

Vládu obejde, kvůli EET rovnou do sněmovny

Vitalia.cz: To nejhorší při horečce u dětí: Febrilní křeče

To nejhorší při horečce u dětí: Febrilní křeče

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Podnikatel.cz: Udávání kvůli EET začalo

Udávání kvůli EET začalo

Podnikatel.cz: K EET. Štamgast už peníze na stole nenechá

K EET. Štamgast už peníze na stole nenechá

Vitalia.cz: Když přijdete o oko, přijdete na rok o řidičák

Když přijdete o oko, přijdete na rok o řidičák

Vitalia.cz: Analýza letáků: Na co lákají do prodejen?

Analýza letáků: Na co lákají do prodejen?

120na80.cz: 5 nejčastějších mýtů o kondomech

5 nejčastějších mýtů o kondomech

Podnikatel.cz: 3, 2, 1..EET startuje. Na co nezapomenout?

3, 2, 1..EET startuje. Na co nezapomenout?

DigiZone.cz: Co chtějí operátoři při přechodu na DVB-T2?

Co chtějí operátoři při přechodu na DVB-T2?

Vitalia.cz: Spor o mortadelu: podle Lidlu falšovaná nebyla

Spor o mortadelu: podle Lidlu falšovaná nebyla

Podnikatel.cz: Chtějte údaje k dani z nemovitostí do mailu

Chtějte údaje k dani z nemovitostí do mailu

DigiZone.cz: Vedení ČRo: personální změny od ledna

Vedení ČRo: personální změny od ledna