Hlavní navigace

Zpravodaj (5): ve znamení SNMP a skupinových adres IPv6

2. 4. 2002
Doba čtení: 8 minut

Sdílet

Po 53. jednání IETF se všichni vrátili k běžné práci a s novými RFC i jejich návrhy se roztrhl pytel. Takže se společně podívejme na nejdůležitější novinky: RFC pro DiffServ; schválení RFC pro SNMPv3 a pro nový formát skupinových adres IPv6; dokumenty pro IMAP a SSH v posledním kole veřejných připomínek atd.

Fakta: nová RFC

V posledním březnovém týdnu 2002 byla publikována následující RFC:

QoS (Quality of Service)

RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior), 2002 (16 stran) (Proposed Standard) (nahrazuje RFC 2598): Návrh normy je součástí specifikace Differentiated Services (DiffServ), rámce architektury TCP/IP pro podporu různých typů služeb (QoS) [Podrobnější popis principů implementace QoS do sítí s TCP/IP lze nalézt v mé nejnovější knize Routing and Switching: Time of Convergence?].

Konkrétně definuje jeden typ chování PHB (Per-Hop Behavior), a to Expedited Forwarding (EF), který je určen pro provoz vyžadující krátké zpoždění, drobné kolísání zpoždění (jitter) a malou ztrátu datagramů. EF bylo navrženo již v roce 1999, ale jeho specifikace nebyla v internetové komunitě přijata, takže od roku 2000 se pracovalo v rámci skupiny Differentiated Services Working Group na definici nové.

RFC 3247 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior) (25 stran) (Informational): Doprovodný dokument k RFC 3246, který podává podrobné informace ke způsobu revize definování Expedited Forwarding PHB. Dokument obsahuje příklady implementace EF.

RFC 3248 A Delay Bound Alternative Revision of RFC 2598 (11 stran) (Informational): Další doprovodný dokument k RFC 3246, který se věnuje původně navržené (nepřijaté) definici EF, založené na porovnání předávání datagramů (forwarding) v nezatížené síti. Experimentální Delay Bound (DB) PHB se váže ke zpoždění datagramů kvůli dalšímu provozu v síti.

Fakta: právě schváleno IESG

Schválené nové normy (Internet Standard):

IESG schválila pět nových RFC jako Internet Standard v oblasti protokolu SNMPv3 (více podrobností viz článek Normalizace Internetu – předběžné varování o SNMP). Jedná se o aktualizaci RFC 2571–2575 s mírnými editačními změnami:

An Architecture for Describing SNMP Management Frameworks (nahrazuje RFC 2571): modulární architektura pro popis rámce managementu, která má dovolovat další vývoj protokolu SNMP (Simple Network Management Protocol). Její základní součásti jsou následující: Message Processing Subsystem, Security Subsystem a Access Control Subsystem, případně další aplikace, které jsou určeny pro specifické zpracování dat pro management.

Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) (nahrazuje RFC 2572): popisuje zpracování zpráv SNMP (SNMPv3 Message Processing Model) a jejich rozesílání; definuje postupy možného rozesílání více verzí zpráv.

SNMP Applications (Standard, nahrazuje RFC 2573): popisuje pět typů aplikací SNMP (Command Generators, Command Responders, Notification Originators, Notification Receivers, Proxy Forwarders) a současně definuje moduly báze MIB (Management Information Base) pro specifikaci cílových objektů operací managementu, pro filtraci oznámení (notification) a pro proxy forwarding.

User-based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3) (nahrazuje RFC 2574): popisuje bezpečnostní model založený na uživateli (User-based Security Model, USM) pro SNMPv3; definuje postup pro zabezpečení zpráv SNMP; specifikuje MIB pro vzdálené monitorování a management parametrů konfigurace pro bezpečnostní model USM.

View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) (nahrazuje RFC 2575): popisuje model řízení přístupu na základě povoleného zobrazení informací v MIB a přístupu k nim (View-based Access Control Model, VACM) [view lze chápat jako soubor řízených objektů, tj. informací pro management (podmnožina MIB), na nichž je možno provádět specifikované operace oprávněnými entitami]; definuje postup řízení přístupu k informacím pro management; specifikuje MIB pro vzdálený management parametrů konfigurace bezpečnostního modelu VACM.

Schválené návrhy norem (Proposed Standard):

IPv6 a skupinové adresy:

Unicast-Prefix-based IPv6 Multicast Addresses (Proposed Standard) a Dynamic Allocation Guidelines for IPv6 Multicast Addresses (Proposed Standard): oba dokumenty spolu souvisí, i když jsou produktem různých pracovních skupin v rámci IETF. První RFC popisuje nový formát prefixu adresy IPv6 pro skupinové adresování, který rozšiřuje dosavadní a je založen na prefixu individuální IPv6 adresy – začleněním prefixu individuální adresy do prefixu skupinové adresy.

Nový formát skupinové adresy IPv6 vypadá následovně:


+--------+----+----+--------+--------+----------------+----------+
|   8    |  4 |  4 |   8    |    8   |       64       |    32    |
+--------+----+----+--------+--------+----------------+----------+
|11111111|flgs|scop|reserved|  plen  | network prefix | group ID |
+--------+----+----+--------+--------+----------------+----------+

Druhý dokument se zaobírá přidělováním skupinových adres IPv6. Jejich dynamické přidělování popisuje formát identifikátoru skupiny (nejnižších 32 bitů adresy). Cílem je omezit pravděpodobnost kolizí skupinových adres IPv6, a to nejen na síťové vrstvě (IPv6), ale i na vrstvě spojové v případech, kdy se část skupinové adresy IPv6 začleňuje do adresy MAC (Media Access Control). IANA (Internet Assigned Numbers Authority) již definovala prostor pro stálé skupinové adresy IPv6 a stálé identifikátory skupin (sledujte informace o přidělování skupinových adres pro IPv6 zde).

DNS a bezpečnost:

GSS [Generic Security Service] Algorithm for TSIG (GSS-TSIG) (Proposed Standard): protokol TSIG (Transaction SIGnature) je určen k autentizaci na úrovni transakcí pro DNS (Domain Name Service). Dokument popisuje rozšíření TSIG pomocí algoritmu založeného na Application Program Interface (GSS-API) (RFC 2743 Generic Security Service Application Program Interface Version 2, 2000).

Adresářové služby:

Named Subordinate References in LDAP Directories (Proposed Standard): popisuje postup a prvky protokolu pro reprezentaci a manipulaci pojmenovaných podřízených odkazů v adresářích LDAP (Lightweight Directory Access Protocol).

Nový informační dokument:

Applicability Statement for Traffic Engineering with MPLS [MultiProtocol Label Switching] (Informational)

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

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

Individuální návrhy (nikoli výsledek práce pracovní skupiny):

Internet Message Access Protocol – Multiappend Extension (Proposed Standard; možné připomínky je třeba zaslat na iesg@ietf.org nebo ietf@ietf.org do 24.4.2002)

The LDAP [Lightweight Directory Access Protocol] controlError Result Code (Proposed Standard; možné připomínky je třeba zaslat na iesg@ietf.org nebo ietf@ietf.org do 27.4.2002)

Internet Message Access Protocol – Version 4rev1 (Proposed Standard; možné připomínky je třeba zaslat na iesg@ietf.org nebo ietf@ietf.org do 24.4.2002)

Enhanced Alerting Packages for Megaco/H.248 (Proposed Standard; možné připomínky je třeba zaslat na iesg@ietf.org nebo ietf@ietf.org do 29.4.2002)

Megaco/H.248 Basic CAS Packages (Proposed Standard; možné připomínky je třeba zaslat na iesg@ietf.org nebo ietf@ietf.org do 29.4.2002)

Návrhy pocházející z pracovních skupin IETF:
Internet Printing Protocol (IPP): Job and Printer Administrative Operations (Proposed Standard; možné připomínky je třeba zaslat na iesg@ietf.org nebo ietf@ietf.org do 7.4.2002)

SSH [Secure Shell] Protocol Architecture, SSH Connection Protocol, SSH Transport Layer Protocol, SSH Authentication Protocol (všechna RFC se mají stát Proposed Standard; možné připomínky ke všem čtyřem návrhům v oblasti SSH je třeba zaslat na iesg@ietf.org nebo ietf@ietf.org do 10.4.2002)

Následující dokument by měl být přijat jako informační RFC:

Voice Messaging Client Behaviour (Informational; možné připomínky je třeba zaslat na iesg@ietf.org nebo ietf@ietf.org do 7.4.2002)

V přípravě: Internet Drafts

Z desítek návrhů Internet Drafts, které se v posledním týdnu objevily, vybírám některé, které mě zaujaly:

Terminal Independent Mobile IP (TIMIP) (10 stran): TIMIP by měl umožnit podporu mobility i terminálů jako laptopy, PDA, které používají běžnou protokolovou architekturu TCP/IP, bez jakéhokoli rozšíření pro podporu mobilního IP. Protokol TIMIP by těmto koncovým zařízením měl dovolit normální komunikaci i při přesunech mezi sítěmi IP. Dosud totiž tato zařízení byla omezena v pohybu pouze na jedinou podsíť, protože mobilita fungovala pouze na druhé vrstvě, tedy mezi přístupovými body (Access Points, AP) připojenými k jednomu směrovači.

Fast Handovers for Mobile IPv6 (62 stran): Mobile IPv6 (MIPv6) popisuje, jak mobilní uzel může změnit svoje připojení k přístupovému směrovači, tedy jak mezi nimi probíhá předávání (handover). Při předávání vzniká hluchá doba, kdy uzel nemůže přijímat ani vysílat datagramy (handover latency). Nový návrh se zaobírá urychlením samotného předávání a zkrácením latence prostřednictvím dvou mechanizmů: Anticipated Handover a Tunnel-based Handover.

Mobility Support in IPv6 (146 stran): mobilita v rámci IPv6 je založena na domácí adrese uzlu (home address), která se s jeho pohybem nemění, a adrese propůjčené (care-of address), jež identifikuje momentální pozici uzlu v síti. V IPv6 jsou všechny datagramy s cílovou adresou odpovídající domácí adrese uzly transparentně směrovány na adresu propůjčenou. Protokol podporuje ukládání vazby domácí adresy s propůjčenou do cache, aby se mohly datagramy směrovat přímo na současnou adresu uzlu.

Survey of IPv4 Addresses in Currently Deployed IETF Standards: návrh se zabývá zkoumáním všech stávajících RFC (zejména v rámci Standards Track, ale i experimentálních RFC) z hlediska jejich vazeb na adresy IPv4. Cílem je umožnit snazší přechod k IPv6 pro protokoly, které mají nějaké závislosti na adresách IPv4.

SNMP over TCP Transport Mapping (rozšíření transportního mapování definovaného v RFC 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2), 1996, Draft Standard): neodpustím si zmínku o tomto návrhu, protože již před deseti lety jsem se ve své disertační práci zabývala možnostmi práce SNMP (Simple Network Management Protocol) nad spolehlivým transportním protokolem, tedy TCP. Podpora pouze nespolehlivého UDP jej tehdy (na první pohled) činila poněkud „slabším“ oproti přímé konkurenci, protokolu CMIP (Common Management Information Protocol) z pera OSI komunity, jenž používal výhradně spolehlivý transportní protokol (TP) OSI. Internetová komunita také proto vyvinula CMOT (CMIP over TCP, RFC 1189 Common Management Information Services and Protocols for the Internet (CMOT and CMIP), 1990, dnes historický) jako – dnes pochopitelně slepou – větev vývoje TCP/IP směrem k OSI.

Fakta: konec pracovní skupiny

Pracovní skupina IETF – Blocks Extensible Exchange Protocol (beep) – v rámci oblasti aplikací skončila svoji práci.

BRAND24

Nominace: Jonathan B. Postel Service Award

ISOC oznamuje zahájení nominací pro udělení ceny jednotlivci, který měl vynikající přínos v rámci služby komunitě datových komunikací. Cena je pojmenovaná po jedné z velkých osobností Internetu, která (nejen) komunitu Internetu nenávratně opustila koncem roku 1998.

Dr. Jonathan B. Postel byl skutečný služebník internetové komunity po celých 30 let a zasloužil se významně o rozvoj Internetu. Jon fungoval jako editor všech RFC od jejich vzniku v roce 1969 až do své smrti roku 1998. Byl také „carem“ přes internetová „čísla“ (čísla protokolů, portů a jiné významné přidělované hodnoty) a jedním z usilovných pracovníků úřadu IANA (Internet Assigned Numbers Authority). Byl zakladatelem IAB (tenkrát Internet Activities Board, dnes Internet Architecture Board, viz minulý Zpravodaj) a také prvním individuálním členem internetové společnosti (ISOC, Internet Society). Z jeho výroků se následující vyplatí stále připomínat: „Be conservative in what you send; be liberal in what you accept from others.“

Aktuální seznam všech publikovaných RFC (Request for Comments) a jejich současný status je k dispozici zde. Pokud je RFC normou, má přiděleno číslo STD (standard, viz RFC 3000 Internet Official Protocol Standards); pokud je RFC doporučenou praxí, má přiděleno číslo BCP (best current practice). RFC jsou veřejně dostupná např. zde. Návrhy, Internet drafts, jsou k dispozici zde.

Byl pro vás článek přínosný?

Autor článku

Ing. Rita Pužmanová, CSc., MBA je nezávislá síťová specialistka. Okusila český, španělský i kanadský vzdělávací systém. Vedla kurzy v 7 zemích a ve 4 jazycích, školila on-line pro UCLA.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).