일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- CS
- 라우팅
- icmp
- 노마드코더
- 데이터 통신과 컴퓨터 네트워크
- 리스트
- 기억장치
- 자료형
- 쿠키
- data type
- 파이썬 자료형
- ARP
- 이코테
- RARP
- 데이터통신
- 컴퓨터 동작방식
- 이것이 취업을 위한 코딩 테스트다
- 북클럽
- GIT
- sort()
- 쉽게 배우는 데이터 통신과 컴퓨터 네트워크
- 이것이 취업을 위한 코딩테스트다
- 시스템 소프트웨어
- IT5분잡학사전
- 파이썬 정렬
- 컴퓨터네트워크
- 파이썬 연산자
- OSI7계층모델
- DP
- 노개북
Archives
- Today
- Total
뚝딱햄 탈출기
[인터넷공학] Chap8. 네트워크 계층 본문
인터넷 공학(2) 수업에 사용되는
쉽게 배우는 데이터 통신과 컴퓨터 네트워크 [3판] / 박기현 / 한빛 아카데미
교재에 대한 연습문제를 정리한 내용이다.
IPv6 프로토콜 장점
- IPv4 프로토콜과 비교해 IPv6 프로토콜이 제공하는 주요 기능 ⇒ 주소 공간 확장, 헤더 구조 단순화, 흐름 제어 기능 지원
- 호스트의 주소 공간 대폭 확장. → 기존 인터넷 환경에서 사용하는 IPv4를 대체하기 위한 차세대 프로토콜.
- 송신 호스트와 수신 호스트의 주소를 표시하는 공간이 32비트에서 128비트로 확장.
- IPv6 이용한 인터넷 환경에선 이론적으로 호스트를 최대 2^128개까지 지원. → 무한으로 확장되는 인터넷 접속자 모두 수용 가능.
- IPv6 헤더는 불필요한 필드가 제외되거나 확장 헤더 형식으로 변경되었음.(→ 필요할 때 그때그때 헤더 추가) // 헤더 구조 단순화
- 흐름 제어 기능을 지원할 수 있는 Flow Label 필드를 도입해 일정 범위 내에서 예측 가능한 데이터 흐름 지원. 따라서 하나의 연속 스트림으로 전송해야 하는 연관 패킷의 전송 기능을 지원 (실시간 연속 전송 기능 지원) → 실시간 기능이 필요한 멀티미디어 응용 환경 수용 가능.
IPv6 헤더 구조
- 총 40바이트 중 32바이트는 주소 공간으로 할당, 8바이트만 프로토콜 기능 위해 사용.
- IPv6 패킷 헤더는 기본 헤더와 확장 헤더로 나뉨. 기본 헤더 바로 뒤에 하나 이상의 확장 헤더 둘 수 있음.
- Destination Options Header는 수신 호스트가 확인 가능한 옵션 정보를 제공함.
- Fragment Header는 IPv4 프로토콜 헤더에 정의된 Fragment Offset, Identification, MF 필드처럼 패킷 분할과 관련된 정보를 포함함.
- Authentication Header는 패킷 인증 관련 기능 제공.
- 글 하단 그림 참고 (IPv6 헤더 구조)
IPv6 헤더 필드
- Flow Label 필드 이용해 특정 송수신 호스트 사이에 전송되는 데이터를 하나의 흐름으로 정의 → 중간 라우터가 이 패킷을 특별한 기준으로 처리할 수 있도록 지원.
- Payload Length 필드는 헤더를 제외한 패킷의 크기. (Payload: 실질적 데이터)
- Next Header 필드는 기본 헤더 다음에 이어지는 헤더의 유형을 수신 호스트에 알려줌.
- Hop Limit 필드 값은 패킷이 라우터에 의해 중개될 때 마다 감소, 0이 되면 해당 패킷은 네트워크에서 사라짐. ⇒ IPv4의 Time To Live 필드와 동일 역할 수행.
- Source Address / Destination Address 필드는 송수신 호스트의 IP 주소를 나타냄.
- Version Number 필드는 IP 프로토콜의 버전 번호로, 기존 IPv6와 구분을 위해 6으로 지정됨.
- DS/ECN 필드는 차등 서비스가 도입되면서 6비트의 DS 필드와 2비트의 ECN 필드가 정의됨.
IPv6 프로토콜 주소 표현 방법
- 128비트의 주소 공간을 콜론으로 구분된 16비트의 숫자 8개로 표현.
- IPv4와 함께 사용하는 환경에서 IPv4 주소를 캡슐화 해 X:X:X:X:X:X:d,d,d,d 로 표현하기도 함. (X는 16비트이므로 총 96비트, d는 8비트이므로 총 32비트. 전체 크기는 128비트.)
터널링
- 이동 IP 프로토콜에서 홈 에이전트와 이동 에이전트 사이에 설정되는 터널은 원래 IP 패킷을 목적지까지 전송하기 위한 중간 단계의 새로운 경로. 송신 호스트와 수신 호스트 사이에서 동작하는 IP 프로토콜과는 별도로 추가적인 IP 프로토콜을 사용해 패킷을 중개해야 함. // 이동 IP 프로토콜에서 터널링 원리
- 터널 구간을 지나는 과정에서 라우팅 처리가 필요한데, 여기서는 IP 프로토콜을 사용해야 함. 원래 IP 패킷을 데이터로 취급하는 새로운 형태의 IP 캡슐 패킷이 구성되어 전달됨. // IP 패킷 캡슐화 관점에서 IP 터널링 원리
ARP 프로토콜
- 임의의 호스트가 다른 호스트에 데이터 전송하려면 수신 호스트의 IP 주소와 MAC 주소를 모두 알아야 함. // 필요성
- 수신 호스트의 IP 주소는 보통 응용프로그램 사용자가 프로그램 실행 과정에서 직접 입력. ⇒ IP 주소 통해 수신 호스트 MAC 주소 얻는 작업 추가로 필요. // 필요성
- 수신 호스트의 MAC 주소는 수신 호스트의 IP 주소를 매개변수로 하여 ARP 기능을 통해 얻어야 함. // 원리
- 송신 호스트의 MAC 주소는 자신의 LAN 카드에 내장되므로 이 값을 읽으면 됨.
- 타 호스트의 MAC 주소를 얻으려면 ARP request 라는 특수 패킷을 브로드캐스팅해야 함.
RARP 프로토콜
- ARP 프로토콜은 수신 호스트와 관련해 MAC 주소 얻는 기능이고, RARP 프로토콜은 송신 호스트와 관련해 IP 주소 얻는 기능임.
- ARP는 IP 주소를 이용해 해당 호스트의 MAC 주소를 제공하는 역할을 하고, RARP는 반대로 MAC 주소를 이용해 IP 주소를 제공함.
- 자신의 MAC 주소와 IP 주소의 매핑 값을 보관하는 서버 호스트로부터 IP 주소 얻어야 함.
- IP 주소를 얻고자 하는 호스트는 자신의 MAC 주소를 매개변수로 하여 패킷을 브로드캐스팅함.
- 파일 시스템이 없는 호스트는 자신의 IP 주소를 보관할 방법이 없으므로, IP 주소를 얻고자 하는 호스트는 LAN 카드에 내장된 자신의 MAC 주소를 매개변수로 하여 RARP 기능 수행함으로써 자신의 IP 주소 얻어야 함. // 필요성
- 보통 네트워크에는 RARP 기능 전담 수행하는 서버가 하나 이상 존재함. → 모든 호스트가 RARP 변환 요청을 받아도 (브로드캐스팅해도) 해당 정보를 보관하고 있는 RARP 서버만 응답 수행. // 원리
ICMP 프로토콜
- 제어 프로토콜의 대표적 예시. 데이터 전송 과정에서 오류를 제어.
- 인터넷 환경에서 오류에 관한 처리 지원.
- 인터넷에서 사용자 데이터는 IP 프로토콜에 의해 전송되지만, 제어 메세지는 ICMP에 의해 전송됨.
- IP 프로토콜은 데이터 전송 과정에서 패킷 폐기 등의 오류가 발생해도 이를 보고하는 기능 X → 이를 대체 지원하기 위해 네트워크 계층 프로토콜인 ICMP가 오류 발생한 IP 패킷에 대해 오류 원인 송신 호스트에 전달.
- TCP/IP 기반 통신망에서 전송 과정에 문제 발생시 라우터에 의해 ICMP 메시지 자동 발생.
- ICMP에 의해 발생하는 메시지의 종류는 오류 보고 메시지와 질의 메시지.
- 송신 호스트에 전달되는 오류 보고 메세지는 IP 패킷을 전송하는 과정에서 발생하는 문제를 보고하는 것이 목적.
- ICMP는 단순 오류 발생 사실 통보 → 오류 해결은 상위 계층의 몫.
ICMP 헤더
- ICMP 오류 보고 메시지에서 첫 줄의 4바이트는 질의 메시지와 동일한 구조를 보이나, 이어지는 메시지의 내용은 서로 다름. 오류 발생한 IP 패킷의 일부,즉 IP 헤더와 추가적인 8바이트의 정보가 ICMP 메세지로 송신 호스트에 전달됨.
- Type 필드는 1바이트(8비트) 크기로, 메세지 종류를 구분.
- Checksum 필드는 ICMP 전체 메세지에 대한 체크섬 기능 지원.
- Code 필드는 메세지 내용에 대한 자세한 정보를 제공하는 매개변수 값.
- ICMP의 주요 임무는 전송 오류 보고. → 오류 발생 패킷에 대한 정보 제공해야 함.
- 글 하단 그림 참고 (ICMP 헤더 구조_오류 보고 메세지)
ICMP 메세지
- DESTINATION UNREACHABLE은 수신 호스트가 존재하지 않거나, 존재해도 필요한 프로토콜이나 포트번호 등이 없어 수신 호스트에 접근이 불가능한 경우에 발생. // 오류 보고 메세지
- SOURCE QUENCH는 네트워크에 필요한 자원이 부족해 패킷이 버려지는 경우에 발생. // 오류 보고 메세지
- TIME EXCEEDED은 패킷의 TTL 필드 값이 0이 되어 패킷이 버려진 경우에 발생. // 오류 보고 메세지
- ECHO REQUEST, ECHO REPLY는 특정 호스트가 인터넷에서 활성화되어 동작하는지 확인하는 목적으로 사용. // 질의 메세지
- TIMESTAMP REQUEST, TIMESTAMP REPLY는 두 호스트 간의 네트워크 지연 계산 목적으로 사용됨. // 질의 메세지
IGMP 프로토콜
- 멀티캐스팅이란 특정 그룹에 속하는 모든 호스트에 메시지를 전송하는 방식. 이 때 필요한 라우팅 알고리즘을 멀티캐스트 라우팅이라 함.
- 멀티캐스트 라우팅에서는 다수의 호스트를 논리적인 하나의 단위로 관리하기 위한 그룹 관리 기능이 필요.
- 그룹 관리의 주요 기능에는 그룹의 생성 및 제거, 전송 호스트의 그룹 참가 및 탈퇴 등이 있음.
- 다중 수신 호스트를 표시하는 멀티캐스트 그룹 주소 표시 방법(v4 or v6)을 통일해야 함.
- 라우터에서 IP 멀티캐스트 주소와 이 그룹에 속하는 멤버 호스트의 네트워크 주소 사이 연관성 처리 가능.
- 개발 라우터가 특정 그룹의 호스트에 패킷 전송하려면 어느 그룹에 어떤 호스트가 존재하는지 알아야 함.
- IGMP는 임의의 호스트가 멀티캐스트 주소로 정의된 멀티캐스트 그룹에 가입 또는 탈퇴할 때 사용하는 프로토콜. // 역할
- 멀티캐스트 그룹에 가입한 호스트와 라우터 사이 멤버 정보 교환 목적으로도 사용하며, 자신이 IGMP 메세지에 표시된 멀티캐스트 주소의 멤버임을 다른 호스트와 라우터에 알리기 위해 사용. // 역할
- 질의 메시지는 멀티 캐스트 라우터가 그룹에 대한 정보 얻기 위해 호스트에 전달하며, 이에 대한 응답으로 호스트가 보고 메시지 회신.
- (동작 과정) 그룹에 가입하려면 해당 멀티캐스트 주소를 표기한 IGMP 보고 메세지를 전송하는데, IGMP 헤더의 Group Address 필드에 가입을 원하는 멀티캐스트 주소를 기록한다. 멀티캐스트 라우터가 그룹에 속한 멤버 목록을 유효하게 관리하려면 IGMP 질의 메세지를 사용해 주기적으로 확인하는 과정이 필요한데, 개별 호스트가 자신의 그룹 멤버를 유지하려면 IGMP 보고 메세지를 사용해 IGMP 질의에 응답해야 하며 라우터의 질의 메세지에 대해 호스트의 보고 메세지 응답이 이루어지지 않으면 그룹에서 탈퇴한 것으로 간주된다.
- 글 하단 그림 참고 (IGMP 동작 과정)
IGMP 헤더
- IGMP 메세지는 ICMP 메세지처럼 IP 패킷에 캡슐화되어 전달됨.
- Type 필드 이용해 질의 메세지(0x11), 보고메세지(0x16) 구분.
- Max Response Time 필드는 질의 메세지에서만 사용됨. (질의에 대한 보고 메세지가 전송되어야 하는 최대 응답 시간을 나타내는 필드.)
- Checksum 필드는 오류 검출용으로 이용됨.
- Group Address 필드는 보고 메세지에서 호스트가 가입을 원하는 그룹 주소를 표기하고, 질의 메세지는 0으로 채움. 특정 그룹 관련 질의 메세지에는 해당 그룹 주소 표기.
- 헤더의 Group Address 필드인 IPv4의 D 클래스 주소는 멀티캐스트 주소임.
- 글 하단 그림 참고 (IGMP 헤더 구조)
'데이터 통신 & 컴퓨터 네트워크' 카테고리의 다른 글
[인터넷공학] Chap10. 전송 계층 : UDP, RTP, OSI TP의 서비스 프리미티브 (0) | 2023.06.21 |
---|---|
[인터넷공학] Chap9. TCP 프로토콜 : 전송 계층, 혼잡 제어, 포트 번호 (0) | 2023.06.21 |
[인터넷공학] Chap7. IP 프로토콜 (0) | 2023.06.21 |
[인터넷공학] Chap5. MAC 계층 (0) | 2023.05.04 |
[인터넷공학] Chap4. 데이터 전송 (0) | 2023.05.04 |
Comments