Internettkontrollmeldingsprotokoll - Internet Control Message Protocol
| Kommunikasjonsprotokoll | |
 En generell topptekst for ICMPv4
| |
| Hensikt | Hjelpeprotokoll for IPv4 |
|---|---|
| Utvikler (er) | DARPA |
| Introdusert | 1981 |
| OSI -lag | Nettverkslag |
| RFC (r) | RFC 792 |
Den Internet Control Message Protocol ( ICMP ) er en støtte protokoll i Internet-protokollpakken . Den brukes av nettverksenheter , inkludert rutere , til å sende feilmeldinger og driftsinformasjon som indikerer suksess eller fiasko når du kommuniserer med en annen IP -adresse , for eksempel når en feil indikeres når en forespurt tjeneste ikke er tilgjengelig eller som en vert eller ruter kan ikke nås. ICMP skiller seg fra transportprotokoller som TCP og UDP ved at den vanligvis ikke brukes til å utveksle data mellom systemer, og den brukes heller ikke regelmessig av sluttbrukernettverksapplikasjoner (med unntak av noen diagnostiske verktøy som ping og traceroute ).
ICMP for IPv4 er definert i RFC 792. En egen ICMPv6 , definert av RFC 4443, brukes med IPv6 .
| Internettprotokollpakke |
|---|
| Påføringslag |
| Transportlag |
| Internett -lag |
| Linklag |
Tekniske detaljer
ICMP er en del av Internett -protokollpakken som definert i RFC 792. ICMP -meldinger brukes vanligvis til diagnostiske eller kontrollformål eller genereres som svar på feil i IP -operasjoner (som spesifisert i RFC 1122). ICMP -feil rettes til kilde -IP -adressen til den opprinnelige pakken.
For eksempel reduserer hver enhet (for eksempel en mellomliggende ruter ) som videresender et IP -datagram først feltet til levetid (TTL) i IP -hodet med en. Hvis den resulterende TTL er 0, blir pakken kastet og en ICMP -tid overskredet i transittmelding sendes til datagrammets kildeadresse.
Mange vanlige nettverksverktøy er basert på ICMP -meldinger. Den trace Kommandoen kan implementeres ved å sende IP-datagrammer med spesielt angitt IP TTL-topptekstfeltene, og leter etter ICMP tid overskrides i transitt, og målet ikke nås meldinger generert i respons. Det relaterte ping -verktøyet implementeres ved bruk av ICMP -ekkoforespørsel og ekkosvarmeldinger .
ICMP bruker den grunnleggende støtten til IP som om den var en høyere protokoll, men ICMP er faktisk en integrert del av IP. Selv om ICMP -meldinger finnes i standard IP -pakker, blir ICMP -meldinger vanligvis behandlet som et spesialtilfelle, skilt fra vanlig IP -behandling. I mange tilfeller er det nødvendig å inspisere innholdet i ICMP -meldingen og levere den riktige feilmeldingen til applikasjonen som er ansvarlig for overføring av IP -pakken som førte til at ICMP -meldingen ble sendt.
ICMP er en nettverkslagsprotokoll . Det er ikke noe TCP- eller UDP -portnummer tilknyttet ICMP -pakker, ettersom disse tallene er knyttet til transportlaget ovenfor.
Datagramstruktur
ICMP -pakken er innkapslet i en IPv4 -pakke. Pakken består av topp- og dataseksjoner.
Overskrift
ICMP -hodet starter etter IPv4 -hodet og identifiseres med IP -protokollnummer '1'. Alle ICMP-pakker har en 8-byte topptekst og datadel med variabel størrelse. De fire første byte i overskriften har fast format, mens de siste 4 byte avhenger av typen/koden til den ICMP -pakken.
| Forskyvninger | Oktett | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Oktett | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 1. 3 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Type | Kode | Sjekksum | |||||||||||||||||||||||||||||
| 4 | 32 | Resten av overskriften | |||||||||||||||||||||||||||||||
- Type
- ICMP -type, se Kontrollmeldinger .
- Kode
- ICMP -undertype, se Kontrollmeldinger .
- Sjekksum
- Internett -kontrollsum (RFC 1071) for feilkontroll, beregnet fra ICMP -overskriften og data med verdi 0 erstattet av dette feltet.
- Resten av overskriften
- Fire-byte felt, innholdet varierer basert på ICMP-typen og -koden.
Data
ICMP -feilmeldinger inneholder en dataseksjon som inkluderer en kopi av hele IPv4 -overskriften, pluss minst de første åtte byte med data fra IPv4 -pakken som forårsaket feilmeldingen. Lengden på ICMP -feilmeldinger bør ikke overstige 576 byte. Disse dataene brukes av verten for å matche meldingen til den riktige prosessen. Hvis en høyere nivå -protokoll bruker portnumre, antas de å være i de første åtte byte av dataene til det opprinnelige datagrammet.
Den variable størrelsen på ICMP -pakkedataseksjonen har blitt utnyttet . I " dødens ping " brukes store eller fragmenterte ICMP-pakker for angrep mot tjenestenekt . ICMP -data kan også brukes til å lage skjulte kanaler for kommunikasjon. Disse kanalene er kjent som ICMP -tunneler .
Kontroller meldinger
Styremeldinger som er identifisert med verdien i typen felt. The code feltet gir ytterligere kontekstinformasjon for meldingen. Noen kontrollmeldinger har blitt utdatert siden protokollen først ble introdusert.
| Type | Kode | Status | Beskrivelse |
|---|---|---|---|
| 0 - Ekkosvar | 0 | Ekkosvar (vant til å pinge ) | |
| 1 og 2 | uten tildeling | Reservert | |
| 3 - Destinasjonen er ikke tilgjengelig | 0 | Destinasjonsnettverk er ikke tilgjengelig | |
| 1 | Destinasjonsverten er ikke tilgjengelig | ||
| 2 | Destinasjonsprotokollen er ikke tilgjengelig | ||
| 3 | Destinasjonsporten er ikke tilgjengelig | ||
| 4 | Fragmentering kreves, og DF -flagg sett | ||
| 5 | Kilderuten mislyktes | ||
| 6 | Destinasjonsnettverk ukjent | ||
| 7 | Destinasjonsvert ukjent | ||
| 8 | Kildevert isolert | ||
| 9 | Administrativt forbudt nettverk | ||
| 10 | Vert administrativt forbudt | ||
| 11 | Nettverket kan ikke nås for ToS | ||
| 12 | Verten er utilgjengelig for vilkårene | ||
| 1. 3 | Kommunikasjon administrativt forbudt | ||
| 14 | Brudd på vertsprioritet | ||
| 15 | Avgrensning av prioritet gjelder | ||
| 4 - Source Quench | 0 | Kildedemping (overbelastningskontroll) | |
| 5 - Viderekoblingsmelding | 0 | Omdiriger datagram for nettverket | |
| 1 | Omdiriger datagram for verten | ||
| 2 | Omdiriger datagram for bruksvilkårene og nettverket | ||
| 3 | Omdiriger datagram for bruksanvisningen og verten | ||
| 6 | Alternativ vertsadresse | ||
| 7 | uten tildeling | Reservert | |
| 8 - ekkoforespørsel | 0 | Ekkoforespørsel (pleide å pinge) | |
| 9 - Ruterannonse | 0 | Ruterannonse | |
| 10 - Ruteroppfordring | 0 | Ruteroppdagelse/valg/oppfordring | |
| 11 - Tiden gikk ut | 0 | TTL utløp under transport | |
| 1 | Fragmentmonteringstiden er overskredet | ||
| 12 - Parameterproblem: Dårlig IP -overskrift | 0 | Pekeren angir feilen | |
| 1 | Mangler et nødvendig alternativ | ||
| 2 | Dårlig lengde | ||
| 13 - Tidsstempel | 0 | Tidsstempel | |
| 14 - Svar på tidsstempel | 0 | Tidsstempel svar | |
| 15 - Informasjonsforespørsel | 0 | Informasjonsforespørsel | |
| 16 - Informasjonssvar | 0 | Informasjonssvar | |
| 17 - Forespørsel om adressemaske | 0 | Adressemaske forespørsel | |
| 18 - Svar på adressemaske | 0 | Adressemaske svar | |
| 19 | reservert | Reservert for sikkerhet | |
| 20 til 29 | reservert | Reservert for robusthetseksperiment | |
| 30 - Traceroute | 0 | Informasjonsforespørsel | |
| 31 | Datagram konverteringsfeil | ||
| 32 | Viderekobling av mobilverten | ||
| 33 | Where-Are-You (opprinnelig ment for IPv6 ) | ||
| 34 | Here-I-Am (opprinnelig ment for IPv6) | ||
| 35 | Forespørsel om mobil registrering | ||
| 36 | Svar på mobilregistrering | ||
| 37 | Forespørsel om domenenavn | ||
| 38 | Svar på domenenavn | ||
| 39 | SKIP Algorithm Discovery Protocol, Simple Key-Management for Internet Protocol | ||
| 40 | Photuris , Sikkerhetsfeil | ||
| 41 | Eksperimentell | ICMP for eksperimentelle mobilitetsprotokoller som Seamoby [RFC4065] | |
| 42 - Utvidet ekkoforespørsel | 0 | Be om utvidet ekko (XPing - se utvidet ping (Xping) ) | |
| 43 - Utvidet ekkosvar | 0 | Ingen feil | |
| 1 | Misformet spørring | ||
| 2 | Ikke noe slikt grensesnitt | ||
| 3 | Ingen slik tabelloppføring | ||
| 4 | Flere grensesnitt tilfredsstiller forespørsel | ||
| 44 til 252 | uten tildeling | Reservert | |
| 253 | Eksperimentell | Eksperiment 1 i RFC3692-stil (RFC 4727) | |
| 254 | Eksperimentell | Eksperiment 2 i RFC3692-stil (RFC 4727) | |
| 255 | reservert | Reservert |
Kildedemping
Source Quench ber om at avsenderen reduserer meldingshastigheten som sendes til en ruter eller vert. Denne meldingen kan genereres hvis en ruter eller vert ikke har tilstrekkelig bufferplass til å behandle forespørselen, eller kan oppstå hvis ruteren eller vertsbufferen nærmer seg grensen.
Data sendes med svært høy hastighet fra en vert eller fra flere verter samtidig til en bestemt ruter på et nettverk. Selv om en ruter har buffermuligheter, er bufferen begrenset til innenfor et spesifisert område. Ruteren kan ikke stille flere data i kø enn kapasiteten til det begrensede bufferområdet. Hvis køen blir fylt opp, blir innkommende data forkastet til køen ikke lenger er full. Men siden det ikke er noen bekreftelsesmekanisme i nettverkslaget, vet ikke klienten om dataene har nådd destinasjonen. Derfor bør noen av tiltakene tas av nettverkslaget for å unngå slike situasjoner. Disse tiltakene omtales som kildeslukking. I en kildeutkoblingsmekanisme ser ruteren at den innkommende datahastigheten er mye raskere enn den utgående datahastigheten, og sender en ICMP -melding til klientene som informerer dem om at de bør senke dataoverføringshastigheten eller vente på en viss mengde tid før du prøver å sende mer data. Når en klient mottar denne meldingen, vil den automatisk senke utgående datahastighet eller vente i tilstrekkelig tid, noe som gjør at ruteren kan tømme køen. Dermed fungerer kildeslukkende ICMP -melding som strømningskontroll i nettverkslaget.
Siden forskning antydet at "ICMP Source Quench [var] en ineffektiv (og urettferdig) motgift for overbelastning", ble ruterenes opprettelse av kildeslukkemeldinger avskrevet i 1995 av RFC 1812. Videre ble videresending av og enhver form for reaksjon på (strømningskontroll) actions) kildeslukkemeldinger ble avskrevet fra 2012 av RFC 6633.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 1. 3 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 4 | Kode = 0 | Sjekksum | |||||||||||||||||||||||||||||
| ubrukt | |||||||||||||||||||||||||||||||
| IP -topptekst og de første 8 byte av originale datagramdata | |||||||||||||||||||||||||||||||
Hvor:
- Type må settes til 4
- Koden må settes til 0
- IP -topptekst og tilleggsdata brukes av avsenderen for å matche svaret med den tilhørende forespørselen
Viderekobling
Omdirigering ber om at datapakker sendes på en alternativ rute. ICMP Redirect er en mekanisme for rutere for å formidle rutinginformasjon til verter. Meldingen informerer en vert om å oppdatere rutinginformasjonen (for å sende pakker på en alternativ rute). Hvis en vert prøver å sende data gjennom en ruter (R1) og R1 sender dataene på en annen ruter (R2) og en direkte bane fra verten til R2 er tilgjengelig (det vil si at verten og R2 er på samme Ethernet -segment) , vil R1 sende en omdirigeringsmelding for å informere verten om at den beste ruten for destinasjonen er via R2. Verten bør deretter endre ruteinformasjonen og sende pakker for destinasjonen direkte til R2. Ruteren vil fortsatt sende det originale datagrammet til den tiltenkte destinasjonen. Imidlertid, hvis datagrammet inneholder ruteinformasjon, blir denne meldingen ikke sendt selv om en bedre rute er tilgjengelig. RFC 1122 sier at viderekoblinger bare skal sendes via gateways og ikke skal sendes av Internett -verter.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 1. 3 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 5 | Kode | Sjekksum | |||||||||||||||||||||||||||||
| IP adresse | |||||||||||||||||||||||||||||||
| IP -topptekst og de første 8 byte av originale datagramdata | |||||||||||||||||||||||||||||||
Hvor:
- Type må settes til 5.
- Koden angir årsaken til omdirigering, og kan være en av følgende:
Kode Beskrivelse 0 Viderekobling for nettverk 1 Viderekobling for vert 2 Viderekobling for type tjeneste og nettverk 3 Viderekobling for type tjeneste og vert
- IP-adresse er 32-biters adressen til gatewayen som viderekoblingen skal sendes til.
- IP -topptekst og tilleggsdata er inkludert for at verten skal kunne matche svaret med forespørselen som forårsaket omdirigeringssvaret.
Tiden overskredet
Time Exceeded genereres av en gateway for å informere kilden til et forkastet datagram på grunn av at tiden for å leve feltet når null. En melding som overskrider tiden kan også bli sendt av en vert hvis den ikke klarer å sette sammen et fragmentert datagram innen tidsfristen.
Tidsoverskredede meldinger brukes av traceroute -verktøyet til å identifisere gateways på banen mellom to verter.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 1. 3 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 11 | Kode | Sjekksum | |||||||||||||||||||||||||||||
| ubrukt | |||||||||||||||||||||||||||||||
| IP -topptekst og de første 8 byte av originale datagramdata | |||||||||||||||||||||||||||||||
Hvor:
- Type må settes til 11
- Koden angir årsaken til meldingen som er overskredet , inkludert følgende:
Kode Beskrivelse 0 Levetid overskredet under transport. 1 Fragmentmonteringstiden er overskredet.
- IP -topptekst og de første 64 bitene av den opprinnelige nyttelasten brukes av kildeverten for å matche den overskredede meldingen til det forkastede datagrammet. For protokoller på høyere nivå som UDP og TCP vil 64-biters nyttelast inkludere kilde- og destinasjonsportene til den forkastede pakken.
Tidsstempel
Tidsstempel brukes til tidssynkronisering. Den opprinnelige tidsstemplet er satt til tiden (i millisekunder siden midnatt) avsenderen berørte pakken sist. Tidsstemplene for mottak og overføring brukes ikke.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 1. 3 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 13 | Kode = 0 | Sjekksum | |||||||||||||||||||||||||||||
| Identifikator | Sekvensnummer | ||||||||||||||||||||||||||||||
| Opprinnelse tidsstempel | |||||||||||||||||||||||||||||||
| Motta tidsstempel | |||||||||||||||||||||||||||||||
| Overfør tidsstempel | |||||||||||||||||||||||||||||||
Hvor:
- Type må settes til 13
- Koden må settes til 0
- Identifikator og sekvensnummer kan brukes av klienten for å matche tidsstempelsvaret med tidsstempelforespørselen.
- Opprinnelig tidsstempel er antall millisekunder siden midnatt Universal Time (UT). Hvis en UT-referanse ikke er tilgjengelig, kan den mest signifikante biten settes til å indikere en ikke-standard tidsverdi.
Tidsstempel svar
Tidsstempel Svar på en tidsstempelmelding . Den består av den opprinnelige tidsstemplet som sendes av avsenderen av tidsstemplet , samt en mottakende tidsstempel som indikerer når tidsstempelet ble mottatt og et tidsstempel for overføring som indikerte når tidsstempelsvaret ble sendt.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 1. 3 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 14 | Kode = 0 | Sjekksum | |||||||||||||||||||||||||||||
| Identifikator | Sekvensnummer | ||||||||||||||||||||||||||||||
| Opprinnelse tidsstempel | |||||||||||||||||||||||||||||||
| Motta tidsstempel | |||||||||||||||||||||||||||||||
| Overfør tidsstempel | |||||||||||||||||||||||||||||||
Hvor:
- Type må settes til 14
- Koden må settes til 0
- Identifikator og sekvensnummer kan brukes av klienten for å matche svaret med forespørselen som forårsaket svaret.
- Opprinnelig tidsstempel er tiden avsenderen berørte meldingen sist før den ble sendt.
- Tidsstempel for mottak er tiden ekkoeren først rørte ved mottakelsen.
- Tidsstempel for overføring er tiden ekko sist berørte meldingen da den ble sendt.
- Alle tidsstempler er i millisekunder siden midnatt UT. Hvis tiden ikke er tilgjengelig i millisekunder eller ikke kan angis med hensyn til midnatt UT, kan en hvilken som helst tid settes inn i et tidsstempel, forutsatt at høyordensbiten i tidsstemplet også er angitt for denne ikke-standardverdien.
Bruken av Tidsstempel og Tidsstempel svar-meldinger for å synkronisere klokkene til Internett-noder har i stor grad blitt erstattet av den UDP-baserte Network Time Protocol og Precision Time Protocol .
Adressemaske forespørsel
Adressemaskeforespørsel sendes vanligvis av en vert til en ruter for å få en passende nettverksmaske .
Mottakere bør svare på denne meldingen med en adressemasksvaremelding .
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 1. 3 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 17 | Kode = 0 | Sjekksum | |||||||||||||||||||||||||||||
| Identifikator | Sekvensnummer | ||||||||||||||||||||||||||||||
| Adressemaske | |||||||||||||||||||||||||||||||
Hvor:
- Type må settes til 17
- Koden må settes til 0
- Adressemaske kan settes til 0
ICMP Address Mask Request kan brukes som en del av rekognoseringsangrep for å samle informasjon om målnettverket, derfor er ICMP Address Mask Reply deaktivert som standard på Cisco IOS.
Adressemaske svar
Adressemasksvar brukes til å svare på en forespørselsmelding fra en adressemaske med en passende nettverksmaske.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 1. 3 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 18 | Kode = 0 | Sjekksum | |||||||||||||||||||||||||||||
| Identifikator | Sekvensnummer | ||||||||||||||||||||||||||||||
| Adressemaske | |||||||||||||||||||||||||||||||
Hvor:
- Type må settes til 18
- Koden må settes til 0
- Adressemaske bør settes til nettverksmasken
Destinasjonen er ikke tilgjengelig
Destinasjon utilgjengelig genereres av verten eller den inngående gatewayen for å informere klienten om at destinasjonen av en eller annen grunn ikke er tilgjengelig. Årsakene til denne meldingen kan omfatte: den fysiske forbindelsen til verten eksisterer ikke (avstanden er uendelig); den angitte protokollen eller porten ikke er aktiv; dataene må være fragmentert, men ikke -fragment -flagget er på. Uoppnåelige TCP -porter reagerer spesielt med TCP RST i stedet for en destinasjon som ikke er tilgjengelig type 3, som man kan forvente. Destinasjon som ikke er tilgjengelig, rapporteres aldri for IP Multicast -overføringer.
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 1. 3 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Type = 3 | Kode | Sjekksum | |||||||||||||||||||||||||||||
| ubrukt | Neste-hop MTU | ||||||||||||||||||||||||||||||
| IP -topptekst og de første 8 byte av originale datagramdata | |||||||||||||||||||||||||||||||
Hvor:
- Type- feltet (bits 0-7) må settes til 3
- Kodefelt (bits 8-15) brukes til å spesifisere feiltypen, og kan være ett av følgende:
Kode Beskrivelse 0 Nettverksfeil. 1 Feil for verten som ikke kan nås. 2 Feil i protokollen som ikke kan nås (den angitte transportprotokollen støttes ikke). 3 Port utilgjengelig feil (den angitte protokollen kan ikke informere verten om den innkommende meldingen). 4 Datagrammet er for stort. Pakkefragmentering er påkrevd, men flagget "ikke -fragment" (DF) er på. 5 Kilde rute mislyktes feil. 6 Destinasjonsnettverk ukjent feil. 7 Destinasjonsvert ukjent feil. 8 Kildevertsisolert feil. 9 Målnettverket er administrativt forbudt. 10 Destinasjonsverten er administrativt forbudt. 11 Nettverket er utilgjengelig for tjenestetype. 12 Verten er utilgjengelig for type tjeneste. 1. 3 Kommunikasjon administrativt forbudt (administrativ filtrering forhindrer pakken i å bli videresendt). 14 Brudd på vertsforrang (indikerer at forespurt fortrinnsrett ikke er tillatt for kombinasjonen av vert eller nettverk og port). 15 Forstyrrelsesavbrudd i kraft (forrang for datagram er under nivået som er angitt av nettverksadministratorene).
- Next-hop MTU- feltet (bits 48-63) inneholder MTU for next-hop-nettverket hvis en kode 4-feil oppstår.
- IP -topptekst og tilleggsdata er inkludert, slik at klienten kan matche svaret med forespørselen som forårsaket destinasjonen utilgjengelig.
Se også
Referanser
RFC -er
- RFC 792 , Internet Control Message Protocol
- RFC 950 , Internett standardprosedyre for nettnett
- RFC 1016 , noe en vert kan gjøre med kildeslukking: kildefrøken introdusert forsinkelse (SQuID)
- RFC 1122 , Krav til internettverter - kommunikasjonslag
- RFC 1716 , Mot krav for IP -rutere
- RFC 1812 , Krav til IP -versjon 4 -rutere
- RFC 4884 , utvidet ICMP for å støtte meldinger i flere deler
Eksterne linker
- IANA ICMP -parametere
- IANA -protokollnumre
- Forklaring av ICMP-omdirigeringsatferd på Wayback-maskinen (arkivert 2015-01-10)