Ch 07. Network Layer

7.1.1 패킷화

• 네트워크 계층의 첫 번째 임무는 당연히 패킷화입니다: 소스에서 네트워크 계층 패킷에 페이로드를 캡슐화하고, 목적지에서 네트워크 계층 패킷에서 페이로드를 디캡슐화합니다.

• 다시 말해, 네트워크 계층의 임무 중 하나는 소스에서 목적지까지 페이로드를 변경하거나 사용하지 않고 전달하는 것입니다.

7.1.2 라우팅

• 첫 번째와 마찬가지로 중요한 네트워크 계층의 다른 임무들은 라우팅과 포워딩이며, 이 둘은 서로 밀접하게 관련되어 있습니다.

7.1.3 오류 제어

• 네트워크 계층에서 오류 제어를 구현할 수 있지만, 인터넷의 네트워크 계층 설계자들은 이 문제를 무시했습니다.

• 각 라우터에서 패킷이 분할될 수 있으므로, 이 계층에서의 오류 검사는 비효율적입니다.

• 헤더의 손상을 제어하기 위해 데이터그램에 체크섬 필드가 추가되었지만, 전체 데이터그램은 아닙니다.

7.1.4 흐름 제어

• 흐름 제어는 소스가 수신자를 압도하지 않고 데이터를 전송할 수 있는 양을 조절합니다.

• 소스 컴퓨터의 상위 계층이 목적지 컴퓨터의 상위 계층이 소비할 수 있는 것보다 빠르게 데이터를 생성하는 경우, 수신자는 데이터에 압도당하게 됩니다.

• 데이터 흐름을 제어하기 위해, 수신자는 송신자에게 데이터로 압도당하고 있음을 알리기 위한 피드백을 보내야 합니다.

7.1.5 혼잡 제어

• 네트워크 계층의 혼잡은 인터넷의 특정 영역에 너무 많은 데이터그램이 존재하는 상황입니다.

• 소스 컴퓨터가 네트워크 또는 라우터의 용량을 초과하는 데이터그램을 전송할 경우 혼잡이 발생할 수 있습니다.

7.1.6 서비스 품질

• 인터넷이 멀티미디어 통신(특히 오디오 및 비디오의 실시간 통신)과 같은 새로운 애플리케이션을 허용함에 따라, 통신의 서비스 품질(QoS)이 점점 더 중요해지고 있습니다.

• 인터넷은 이러한 애플리케이션을 지원하기 위해 더 나은 QoS를 제공함으로써 번창하고 있습니다.

• 그러나 네트워크 계층을 그대로 유지하기 위해, 이러한 조치들은 대부분 상위 계층에서 구현됩니다.

7.1.7 보안

• 인터넷이 처음 설계되었을 때 사용자 수가 적었기 때문에 보안은 걱정거리가 아니었습니다.

• 네트워크 계층은 보안 조치 없이 설계되었습니다.

• 그러나 오늘날 보안은 큰 문제입니다.

• 연결 없는 네트워크 계층에 보안을 제공하기 위해서는 연결 서비스로 바꾸는 또 다른 가상 수준이 필요합니다.

• 이전 섹션에서 라우팅 및 포워딩에 대한 논의에서, 네트워크 계층에서 어떤 종류의 스위칭이 발생한다는 것을 추론할 수 있습니다.

• 라우터는 입력 포트와 출력 포트(또는 일련의 출력 포트) 사이의 연결을 생성하는 스위치와 같으며, 전기 스위치가 입력을 출력에 연결하여 전기가 흐르게 하는 것과 같습니다.

• 데이터그램 접근법: 연결 없는 서비스

• 가상-회로 접근법: 연결 지향 서비스

네트워크 계층에서의 스위칭

• 이전 섹션에서 라우팅과 포워딩에 대한 논의를 통해, 네트워크 계층에서 어떤 종류의 스위칭이 발생한다는 것을 추론할 수 있습니다.

• 라우터는 입력 포트와 출력 포트(또는 일련의 출력 포트) 사이의 연결을 생성하는 스위치와 같으며, 전기 스위치가 입력을 출력에 연결하여 전기가 흐르게 하는 것과 같습니다.

• 데이터그램 접근법: 연결 없는 서비스

• 가상-회로 접근법: 연결 지향 서비스

7.3 성능

• 네트워크 계층의 서비스를 사용하는 상위 계층 프로토콜은 이상적인 서비스를 기대하지만, 네트워크 계층은 완벽하지 않습니다.

• 네트워크의 성능은 지연, 처리량 및 패킷 손실 측면에서 측정될 수 있습니다.

• 혼잡 제어는 성능을 개선할 수 있는 이슈입니다.

7.3.1 지연

• 우리 모두는 네트워크에서 즉각적인 응답을 기대하지만, 패킷은 소스에서 목적지까지 이동하는 동안 지연을 경험합니다.

• 네트워크의 지연은 네 가지 유형으로 나눌 수 있습니다: 전송 지연, 전파 지연, 처리 지연, 대기열 지연

• 각각의 지연 유형에 대해 논의한 다음 소스에서 목적지까지의 패킷 지연을 계산하는 방법을 보여줍니다.

• 전송 지연: 송신자는 패킷의 비트를 하나씩 라인에 올려야 합니다.

• 전송 지연은 Delaytr = (패킷 길이) / (전송 속도)로 계산됩니다.

• 전파 지연: 전파 지연은 비트가 전송 매체에서 점 A에서 점 B로 이동하는 데 걸리는 시간입니다.

• 전파 지연은 Delaypg = (거리) / (전파 속도)로 계산됩니다.

• 처리 지연: 라우터나 목적지 호스트가 입력 포트에서 패킷을 받아 헤더를 제거하고 오류 검출 절차를 수행하고 출력 포트(라우터의 경우) 또는 상위 계층 프로토콜(목적지 호스트의 경우)로 패킷을 전달하는 데 필요한 시간입니다.

• 처리 지연은 Delaypr = 라우터나 목적지 호스트에서 패킷을 처리하는 데 필요한 시간으로 계산됩니다.

• 대기열 지연: 대기열 지연은 일반적으로 라우터에서 발생합니다.

• 대기열 지연은 Delayqu = 라우터의 입력 및 출력 대기열에서 패킷이 대기하는 시간으로 측정됩니다.

• 총 지연: 송신자, 라우터 및 수신자에 대해 동일한 지연을 가정할 때, 전체 경로에서 n개의 라우터가 있는 경우, 패킷이 겪는 총 지연(소스에서 목적지까지의 지연)을 계산할 수 있습니다.

• 총 지연 = (n + 1) (delaytr + delaypg + delaypr) + (n) (delayqu)

7.3.2 처리량

• 네트워크의 어떤 지점에서의 처리량은 그 지점에서 1초에 지나가는 비트 수로 정의되며, 실제로 그 지점의 데이터 전송 속도입니다.

• 소스에서 목적지까지의 경로에서 패킷은 다른 전송 속도를 가진 여러 링크(네트워크)를 통과할 수 있습니다.

• 전체 경로의 처리량은 어떻게 결정할 수 있을까요? 처리량 = 최소 {TR1, TR2, ..., TRn}

인터넷에서의 실제 상황

• 일반적으로 데이터는 두 개의 접속 네트워크와 인터넷 백본을 통과합니다.

7.3.3 패킷 손실

• 전송 중 패킷이 손실되는 수는 통신의 성능에 영향을 미칩니다.

• 라우터가 다른 패킷을 처리하는 동안 패킷을 수신하면, 수신된 패킷은 차례가 올 때까지 입력 버퍼에 저장되어야 합니다.

• 그러나 라우터에는 제한된 크기의 입력 버퍼가 있습니다.

• 버퍼가 가득 차 다음 패킷이 삭제될 수 있는 시점이 올 수 있습니다.

• 인터넷 네트워크 계층에서 패킷 손실의 영향은 패킷이 재전송되어야 하며, 이는 차례로 오버플로를 생성하여 더 많은 패킷 손실을 일으킬 수 있습니다.

7.4 인터넷 프로토콜 버전 4

• 인터넷의 네트워크 계층은 여러 버전을 거쳤지만, IP 버전 4 (IPv4)와 IP 버전 6 (IPv6)만이 살아남았습니다.

• IPv4는 거의 고갈되었지만, 여전히 일부 지역에서 이 버전을 사용하고 있으며 IPv6의 기반이기 때문에 이에 대해 논의합니다.

7.4.1 IPv4 주소 지정

• TCP/IP 프로토콜 스위트의 IP 계층에서 각 장치의 인터넷 연결을 식별하는 데 사용되는 식별자를 인터넷 주소 또는 IP 주소라고 합니다.

• IPv4 주소는 호스트나 라우터의 인터넷 연결을 고유하고 보편적으로 정의하는 32비트 주소입니다.

• IP 주소는 호스트나 라우터의 주소가 아니라 연결의 주소입니다. 따라서 장치가 다른 네트워크로 이동하면 IP 주소가 변경될 수 있습니다.

• 주소 공간: 주소 공간은 프로토콜이 사용하는 총 주소 수입니다.

• 주소 표기법: IPv4 주소를 나타내는 세 가지 일반적인 표기법은 이진 표기법(기수 2), 점표기법(기수 256), 16진 표기법(기수 16)입니다.

• 주소 지정의 계층성: 32비트 IPv4 주소는 계층적이지만 네트워크를 정의하는 접두사와 노드를 정의하는 접미사로만 나누어집니다.

• 주소의 첫 번째 부분은 접두사라고 하며 네트워크를 정의합니다.

• 주소의 두 번째 부분은 접미사라고 하며 노드를 정의합니다.

클래스풀 주소 지정

• 인터넷이 시작될 때, IPv4 주소는 고정된 길이의 접두사를 가지고 설계되었으나, 작은 네트워크와 큰 네트워크를 모두 수용하기 위해 하나의 고정된 길이의 접두사 대신 세 가지(n = 8, n = 16, n = 24)가 설계되었습니다.

• 전체 주소 공간은 다섯 클래스(A, B, C, D, E)로 나뉘었으며, 이 방식을 클래스풀 주소 지정이라고 합니다.

• 인터넷의 성장과 함께 더 큰 주소 공간이 필요해졌습니다.

• 장기적인 해결책은 IPv6이며, IPv6는 더 큰 주소 공간을 가집니다.

• 단기적인 해결책은 같은 주소 공간을 사용하지만, 각 기관에 공정한 비율로 주소를 분배하기 위해 주소의 분포를 변경하는 클래스리스 주소 지정입니다.

• 이 해결책은 여전히 IPv4 주소를 사용하며, 클래스리스 주소 지정이라고 합니다.

• 클래스리스 주소 지정은 CIDR(클래스리스 인터도메인 라우팅)을 사용하여 접두사 길이를 슬래시(/)로 명시합니다.

예시 7.1

주소 마스크

• 블록 내 첫 번째와 마지막 주소를 찾는 또 다른 방법은 주소 마스크를 사용하는 것입니다.

• 주소 마스크는 32비트 숫자로서 왼쪽 n비트가 1로 설정되고 나머지 비트(32 – n)가 0으로 설정됩니다.

• 컴퓨터는 주소 마스크를 쉽게 찾을 수 있습니다. 왜냐하면 이것은 (232 – n – 1)의 보수이기 때문입니다.

1. 블록 내 주소 수 N = NOT (마스크) + 1

2. 블록의 첫 번째 주소 = (블록 내 임의의 주소) AND (마스크)

3. 블록의 마지막 주소 = (블록 내 임의의 주소) OR [NOT (마스크)]

예시 7.2

예시 7.3

네트워크 주소

• 첫 번째 주소, 즉 네트워크 주소는 패킷을 목적지 네트워크로 라우팅하는 데 사용되기 때문에 특히 중요합니다.

블록 할당

• 블록 할당의 최종 책임은 인터넷 주소와 번호 할당을 위한 글로벌 기관인 인터넷 기업체 및 번호 할당 기관(ICANN)에 부여됩니다.

• 그러나 ICANN은 일반적으로 개별 인터넷 사용자에게 주소를 할당하지 않습니다.

• 대신, ICANN은 ISP(인터넷 서비스 제공자)에게 대규모의 주소 블록을 할당합니다.

1. 요청된 주소의 수, N,은 2의 거듭제곱이어야 합니다. 이유는 N = 2^n 또는 n = log₂N 이기 때문입니다. N이 2의 거듭제곱이 아니면, n에 대해 정수 값을 가질 수 없습니다.

2. 요청된 블록은 주소 공간에서 연속적인 사용 가능 주소 수가 있는 곳에 할당되어야 합니다. 그러나 블록의 첫 번째 주소를 선택하는 데 제한이 있습니다. 첫 번째 주소는 블록 내 주소 수로 나눌 수 있어야 합니다. 이유는 첫 번째 주소가 접두사 다음에 (32 - n)개의 0이 오도록 해야 하기 때문입니다. 첫 번째 주소의 십진수 값은 다음과 같습니다. 첫 번째 주소 = (십진수 접두사) × 2^(32-n) = (십진수 접두사) × N

예시 7.4

예시 7.5

주소 집계

• CIDR 전략의 장점 중 하나는 주소 집계(또는 주소 요약 또는 라우트 요약이라고도 함)입니다.

• 주소 블록을 결합하여 더 큰 블록을 만들면, 더 큰 블록의 접두사를 기반으로 라우팅을 수행할 수 있습니다.

• ICANN은 ISP에게 대규모의 주소 블록을 할당합니다.

• 각 ISP는 할당받은 블록을 더 작은 서브블록으로 나누어 고객에게 부여합니다.

• 그림 7.11은 ISP가 네 개의 조직에 네 개의 작은 주소 블록을 할당하는 방법을 보여줍니다. ISP는 이 네 개의 블록을 하나의 단일 블록으로 결합하여 전 세계에 더 큰 블록을 광고합니다. 이 더 큰 블록으로 향하는 모든 패킷은 이 ISP로 보내져야 합니다. 이 ISP는 적절한 조직으로 패킷을 전달하는 책임이 있습니다. 이것은 우편 네트워크에서 찾을 수 있는 라우팅과 유사합니다. 외국에서 오는 모든 패키지는 먼저 수도로 보내진 후 해당 목적지로 분배됩니다.

7.4.2 주요 및 보조 프로토콜

• 버전 4의 네트워크 계층은 하나의 주요 프로토콜과 세 가지 보조 프로토콜로 생각할 수 있습니다.

• 주요 프로토콜인 IPv4는 패킷화, 전달, 그리고 패킷의 배달을 담당합니다.

• ICMPv4는 IPv4가 배달 중 발생할 수 있는 일부 오류를 처리하는 데 도움을 줍니다.

• IGMP는 IPv4가 멀티캐스팅을 지원하는 데 사용됩니다.

• ARP는 주소 매핑에 사용됩니다.

데이터그램 형식

• IP가 사용하는 패킷은 데이터그램이라고 불립니다.

• 데이터그램은 헤더와 페이로드(데이터)로 구성된 가변 길이 패킷입니다.

• 헤더는 20~60바이트 길이이며 라우팅과 배달에 필요한 정보를 포함합니다 (첫 20바이트는 주요 헤더).
• VER: 4비트 버전 번호 필드는 IPv4 프로토콜의 버전을 정의하며, 값은 4입니다.
• HLEN: 4비트 헤더 길이 필드는 데이터그램 헤더의 총 길이를 4바이트 단어로 정의합니다.
• 서비스 유형: 이 필드는 원래 서비스 유형(TOS)으로 불렸습니다. 1990년대 후반 IETF는 이 필드를 재정의하여 우선 순위에 따라 다른 클래스로 애플리케이션을 분할하는 DiffServ를 제공합니다.
• 총 길이: 이 16비트 필드는 IP 데이터그램의 총 길이(헤더 + 데이터)를 바이트 단위로 정의합니다.
• 식별자, 플래그, 조각화 오프셋: 이 세 필드는 데이터그램의 크기가 기본 네트워크가 수용할 수 있는 것보다 클 때 IP 데이터그램의 조각화와 관련이 있습니다.
• 생존 시간(TTL): 데이터그램이 인터넷에서 목적지에 도달하지 않고 일부 네트워크를 반복적으로 방문하는 경우가 있습니다. TTL 필드는 데이터그램이 방문할 수 있는 최대 홉(라우터) 수를 제어하는 데 사용됩니다.
• 프로토콜: 데이터그램은 UDP나 TCP와 같은 어떤 전송 계층 프로토콜에 속하는 패킷을 운반할 수 있습니다. 데이터그램은 또한 IP의 서비스를 직접 사용하는 다른 프로토콜의 패킷을 운반할 수도 있습니다, 예를 들어 일부 라우팅 프로토콜이나 몇 가지 보조 프로토콜들이 있습니다. 인터넷 권한은 IP 서비스를 사용하는 모든 프로토콜에 고유한 8비트 숫자를 할당하며, 이 숫자는 프로토콜 필드에 삽입됩니다. 페이로드가 소스 IP에서 데이터그램에 캡슐화될 때, 해당 프로토콜 번호가 이 필드에 삽입됩니다.
• 헤더 체크섬: IP는 신뢰할 수 있는 프로토콜이 아니며, 데이터그램에 의해 운반되는 페이로드가 전송 중에 손상되었는지 확인하지 않습니다. IP는 페이로드의 오류 검사 부담을 페이로드를 소유한 프로토콜에게 맡깁니다, 예를 들어 UDP나 TCP와 같은 프로토콜입니다. 헤더 체크섬 필드는 페이로드가 아닌 헤더를 검사합니다.
• 소스 및 목적지 주소: 이 32비트 소스 및 목적지 주소 필드는 각각 소스와 목적지의 IP 주소를 정의합니다. 목적지 IP 주소는 DNS에 의해 제공됩니다.
• 옵션
• 페이로드

예시 7.7

예시 7.8

예시 7.9

예시 7.10

예시 7.11

조각화

• 데이터그램은 다양한 네트워크를 통과할 수 있습니다.

• 각 라우터는 받은 프레임에서 IP 데이터그램을 벗겨내어 처리한 후 다른 프레임에 싸서 보냅니다.

• 받은 프레임의 형식과 크기는 프레임이 방금 통과한 물리 네트워크에서 사용하는 프로토콜에 따라 달라집니다.

• 보내는 프레임의 형식과 크기는 프레임이 통과할 물리 네트워크에서 사용하는 프로토콜에 따라 달라집니다.

최대 전송 단위(MTU)

• 각 링크 계층 프로토콜은 고유한 프레임 형식을 가지고 있습니다.

• 각 형식의 특징 중 하나는 캡슐화할 수 있는 페이로드의 최대 크기입니다.
• 데이터그램이 프레임에 캡슐화될 때, 데이터그램의 총 크기는 최대 크기보다 작아야 합니다.
• MTU 값은 물리 네트워크 프로토콜마다 다릅니다 (LAN: 일반적으로 1500바이트, WAN: LAN보다 크거나 작음).

• IP 프로토콜을 물리 네트워크와 독립적으로 만들기 위해 IP 데이터그램의 최대 길이를 65,535바이트로 설정합니다.
• 물리 계층이 더 작은 MTU를 사용하는 경우 데이터그램은 조각화되어야 합니다.

• 데이터그램이 조각화될 때, 각 조각은 대부분의 필드가 반복되지만 일부는 변경된 고유한 헤더를 가집니다.

• 데이터그램이 더 작은 MTU를 가진 네트워크를 만나면 자체적으로 조각화될 수 있습니다.
• 즉, 데이터그램은 최종 목적지에 도달하기 전에 여러 번 조각화될 수 있습니다.

• 재조합 및 다양한 경로
• 데이터그램의 재조합은 목적지 호스트에서만 수행되며, 소스 호스트나 경로상의 어떤 라우터에 의해서도 데이터그램이 조각화될 수 있습니다.
• 조각화된 데이터그램은 다양한 경로를 통해 이동할 수 있으며, 조각화된 데이터그램이 어떤 경로를 거칠지 제어하거나 보장할 수 없습니다.
• 동일한 데이터그램에 속하는 모든 조각은 결국 목적지 호스트에 도달해야 합니다.
• 데이터그램을 조각화하는 호스트나 라우터는 플래그, 조각화 오프셋, 총 길이 및 체크섬의 값을 변경해야 합니다.
• 나머지 필드는 복사되어야 합니다.
• 체크섬은 다시 계산되어야 합니다.

조각화와 관련된 필드

• 식별자, 플래그, 조각화 오프셋 필드가 관련이 있습니다.

• 16비트 식별자 필드
• 이 필드는 소스 호스트에서 발생한 데이터그램을 식별합니다.
• 고유성을 보장하기 위해 IP 프로토콜은 카운터의 현재 값을 식별자 필드에 복사하고 카운터를 하나 증가시킵니다.
• 데이터그램이 조각화될 때 식별자 필드의 값은 모든 조각에 복사됩니다.
• 모든 조각은 동일한 식별 번호를 가집니다.
• 동일한 식별 값을 가진 모든 조각은 하나의 데이터그램으로 조립되어야 합니다.

• 3비트 플래그 필드
• 이 필드는 세 가지 플래그를 정의합니다:
• 첫 번째 비트(가장 왼쪽 비트)는 예약되어 있으며 사용되지 않습니다.
• 두 번째 비트(D 비트)는 '조각화 금지 비트'라고 합니다.
• 이 값이 1이면, 기계는 데이터그램을 조각화해서는 안 됩니다.
• 사용 가능한 물리적 네트워크를 통해 데이터그램을 전달할 수 없는 경우, 데이터그램을 폐기하고 소스 호스트에 ICMP 오류 메시지를 보냅니다.
• 이 값이 0이면, 필요한 경우 데이터그램을 조각화할 수 있습니다.
• 세 번째 비트(M 비트)는 '추가 조각 비트'라고 합니다.
• 이 값이 1이면, 이 데이터그램이 마지막 조각이 아니며, 이후에 더 많은 조각이 있음을 의미합니다.
• 이 값이 0이면, 이것이 마지막 또는 유일한 조각임을 의미합니다.

• 13비트 조각화 오프셋 필드
• 이 필드는 데이터그램 내에서 이 조각의 상대적 위치를 보여줍니다.
• 이는 원래 데이터그램에서 8바이트 단위로 측정된 오프셋입니다.
• 예) 그림 7.17에서 4000바이트의 데이터그램은 세 조각으로 나뉩니다
• 원본 데이터그램의 바이트는 0부터 3999까지 번호가 매겨집니다.
• 첫 번째 조각은 0부터 1399까지의 바이트를 운반하므로, 이 데이터그램의 오프셋은 0/8 = 0입니
• 두 번째 조각은 1400부터 2799까지의 바이트를 운반하므로, 이 조각의 오프셋 값은 1400/8 = 175입니다.
• 세 번째 조각은 2800부터 3999까지의 바이트를 운반하므로, 이 조각의 오프셋 값은 2800/8 = 350입니다.
• 조각은 서버에서 재조합됩니다.
• 식별 필드는 모든 조각에서 동일하며, 마지막 조각을 제외한 모든 조각에 설정된 더 많은 조각 비트(M 비트)를 가진 플래그 필드도 마찬가지입니다.
• 조각이 목적지에서 순서대로 도착하지 않더라도 올바르게 재조립될 수 있습니다.
• 조각 자체가 조각화된 경우
• 오프셋 필드는 항상 원래 데이터그램에 상대적입니다.
• 두 번째 조각은 나중에 800바이트와 600바이트의 두 조각으로 나뉘지만, 오프셋은 원래 데이터에 대한 조각의 상대적 위치를 나타냅니다.
• 최종 목적지 호스트는 다음 전략을 사용하여 받은 조각에서 원래 데이터그램을 재조립할 수 있습니다.
1. 첫 번째 조각의 오프셋 필드 값은 0입니다.
2. 첫 번째 조각의 길이를 8로 나눕니다. 두 번째 조각의 오프셋 값은 그 결과와 같습니다.
3. 첫 번째와 두 번째 조각의 총 길이를 8로 나눕니다. 세 번째 조각의 오프셋 값은 그 결과와 같습니다.
4. 이 과정을 계속합니다. 마지막 조각의 M 비트는 0으로 설정됩니다.
5. 프로세스를 계속합니다. 마지막 조각의 M 비트 값은 0입니다.

예시 7.12

예시 7.13

예시 7.14

예시 7.15

예시 7.16

IPv4의 오류 보고 및 오류 수정 메커니즘 부재

• IPv4는 오류 보고 메시지나 오류 수정 메커니즘이 없습니다.

• IP 프로토콜은 또한 호스트 및 관리 쿼리를 위한 메커니즘이 부족합니다.

• 인터넷 제어 메시지 프로토콜 버전 4 (ICMPv4)는 위의 두 가지 결점을 보완하기 위해 설계되었습니다.

메시지

• ICMP 메시지는 두 가지 넓은 범주로 나뉩니다: 오류 보고 메시지와 쿼리 메시지

• 오류 보고 메시지는 라우터나 호스트(목적지)가 IP 패킷을 처리할 때 마주칠 수 있는 문제를 보고합니다.

• 쿼리 메시지는 한 쌍으로 발생하며, 호스트나 네트워크 관리자가 라우터나 다른 호스트로부터 특정 정보를 얻는 데 도움을 줍니다.

• 예를 들어, 노드는 이웃을 발견할 수 있습니다.

• 또한 호스트는 자신의 네트워크에 있는 라우터를 발견하고 알아볼 수 있으며, 라우터는 노드가 메시지를 재전송하는 데 도움을 줄 수 있습니다.

• ICMP 메시지에는 8바이트의 헤더와 가변 크기의 데이터 섹션이 있습니다.
• 첫 4바이트는 모든 메시지에 공통입니다 (Type, Code, Checksum).
• Type: ICMP 유형 (메시지의 유형).
• Code: 특정 메시지 유형의 이유.
• Checksum.
• 헤더의 나머지 부분은 각 메시지 유형에 특정합니다.

• 오류 메시지의 데이터 섹션에는 오류가 발생한 원래 패킷을 찾는 데 필요한 정보가 포함됩니다.

메시지 - 오류 보고 메시지

• IP가 신뢰할 수 없는 프로토콜이므로, ICMP의 주요 책임 중 하나는 일부 오류를 보고하는 것입니다.
• ICMP는 오류를 수정하지 않고 단순히 보고합니다.
• 오류 수정은 상위 레벨 프로토콜에 맡겨집니다.

• 오류 메시지는 항상 원본 소스로 전송됩니다.
• ICMP는 오류 메시지를 보내기 위해 소스 IP 주소를 사용합니다.

• 오류 보고 프로세스를 단순화하기 위해, ICMP는 메시지 보고 시 일부 규칙을 따릅니다.
• 첫째, 멀티캐스트 주소나 특별 주소(예: 이 호스트 또는 루프백)가 있는 데이터그램에 대해서는 오류 메시지가 생성되지 않습니다.
• 둘째, ICMP 오류 메시지를 운반하는 데이터그램에 대한 응답으로는 ICMP 오류 메시지가 생성되지 않습니다.
• 셋째, 첫 번째 조각이 아닌 조각화된 데이터그램에 대해서는 ICMP 오류 메시지가 생성되지 않습니다.

• 모든 오류 메시지에는 다음이 포함된 데이터 섹션이 있습니다:
• 원본 데이터그램의 IP 헤더
• 원본 데이터그램 헤더는 오류 메시지를 받는 원본 소스에게 데이터그램 자체에 대한 정보를 제공하기 위해 추가됩니다.
• 해당 데이터그램의 처음 8바이트 데이터
• 8바이트 데이터는 포트 번호(UDP 및 TCP)와 시퀀스 번호(TCP)에 대한 정보를 제공하기 때문에 포함됩니다.
• 이 정보는 소스가 프로토콜(TCP 또는 UDP)에 오류에 대해 알리는 데 필요합니다.

메시지 - 목적지 도달 불가

• 가장 널리 사용되는 오류 메시지는 목적지 도달 불가능(type 3) 메시지입니다.

• 이 메시지는 다양한 코드(0에서 15까지)를 사용하여 오류 메시지의 유형과 데이터그램이 최종 목적지에 도달하지 못한 이유를 정의합니다.
• 예) 코드 0은 소스에게 호스트가 도달할 수 없음을 알립니다.

메시지 - 쿼리 메시지

• 쿼리 메시지는 데이터그램에 캡슐화되어야 합니다.

• 쿼리 메시지(요청 및 응답)는 다음을 위해 사용됩니다:
• 인터넷 상의 호스트 또는 라우터의 생존성을 조사하거나 테스트하기 위해
• 두 장치 간의 일방향 또는 왕복 시간을 찾기 위해
• 두 장치의 시계가 동기화되어 있는지 알아내기 위해

• 에코 요청(type 8) 및 에코 응답(type 0) 메시지
• 호스트/라우터가 다른 호스트/라우터의 생존성을 테스트하기 위해 사용됩니다.
• 이 쌍의 두 디버깅 도구에서의 응용: 핑(Ping)과 트레이스 라우트(Traceroute)

• 타임스탬프 요청(type 13) 및 타임스탬프 응답(type 14) 메시지
• 두 장치 간의 왕복 시간(RTT)을 찾기 위해 사용됩니다.
• 두 장치의 시계가 동기화되어 있는지 확인하기 위해
• 타임스탬프 요청 메시지는 32비트 숫자를 보내며, 이는 1) 메시지가 보내진 시간을 정의합니다.
• 타임스탬프 응답 메시지는 해당 숫자를 다시 보내지만, 2) 요청이 수신된 시간과 3) 응답이 보내진 시간을 나타내는 두 개의 새로운 32비트 숫자도 포함합니다.
• 모든 타임스탬프가 세계 표준시를 나타내는 경우, 발신자는 일방향 및 왕복 시간을 계산할 수 있습니다.

디버깅 도구

• ICMP를 사용하는 두 가지 디버깅 도구: ping과 traceroute(tracert)

디버깅 도구 - Ping

• 호스트가 살아있고 응답하는지 확인하기 위해 ping 프로그램을 사용할 수 있습니다.

• 소스 호스트는 ICMP 에코 요청 메시지를 보내고, 대상 호스트가 살아있다면 ICMP 에코 응답 메시지로 응답합니다.

• ping 프로그램은 에코 요청 및 에코 응답 메시지의 식별자 필드를 설정하고 시퀀스 번호를 0에서 시작하여 새 메시지가 전송될 때마다 1씩 증가시킵니다.

• ping은 RTT를 계산할 수 있다는 점을 유의하세요.

디버깅 도구 - Traceroute 또는 Tracert

• 예시 7.17

• 다음은 auniversity.edu 사이트로 ping 메시지를 보내는 방법을 보여줍니다. $ ping auniversity.edu PING auniversity.edu (152.181.8.3) 56(84) 바이트의 데이터. 64 바이트 from auniversity.edu (152.181.8.3): icmp_seq=0 64 바이트 from auniversity.edu (152.181.8.3): icmp_seq=1 64 바이트 from auniversity.edu (152.181.8.3): icmp_seq=2 64 바이트 from auniversity.edu (152.181.8.3): icmp_seq=3 64 바이트 from auniversity.edu (152.181.8.3): icmp_seq=4 64 바이트 from auniversity.edu (152.181.8.3): icmp_seq=5 -- auniversity.edu 통계 --- 6 패킷 전송, 6 수신, 0% 패킷 손실 최소/평균/최대 = 1.90/1.95/2.04 ms

디버깅 도구 - Traceroute 또는 Tracert

• 유닉스의 Traceroute 또는 윈도우의 Tracert (애플리케이션 계층 프로그램)

• 소스에서 목적지까지 패킷의 경로를 추적하기 위해 사용됩니다.

• 경로상의 모든 라우터의 IP 주소를 찾을 수 있습니다.

• 프로그램은 일반적으로 최대 30 홉까지 확인하도록 설정됩니다.

트레이스 라우트(Traceroute)

• 트레이스 라우트는 두 가지 오류 보고 메시지의 도움을 받습니다: 시간 초과와 목적지 도달 불가능 (핑: 두 가지 쿼리 메시지)

• 서버 프로그램은 필요 없습니다. 오직 클라이언트 프로그램만 필요하며, 이는 목적지 호스트의 응용 계층에 도달하지 않기 때문입니다.

• 트레이스 라우트는 UDP 사용자 데이터그램에 캡슐화되지만, 트레이스 라우트는 의도적으로 목적지에서 사용할 수 없는 포트 번호를 사용합니다.

• 경로에 n개의 라우터가 있다면, 트레이스 라우트는 (n + 1)개의 메시지를 보냅니다.
• 처음 n개의 메시지는 n개의 라우터에 의해 각각 폐기됩니다.
• 마지막 메시지는 목적지 호스트에 의해 폐기됩니다. n의 값은 알 필요가 없습니다.

• 첫 번째 트레이스 라우트 메시지
• TTL이 1로 설정되어 전송됩니다.
• 첫 번째 라우터는 이 메시지를 폐기하고 시간 초과 ICMP 오류 메시지를 보냅니다. 이 메시지에는 첫 번째 라우터의 IP 주소와 이름이 포함됩니다.
• IP 주소(오류 메시지의 소스 IP 주소)
• 라우터 이름(메시지의 데이터 섹션에 포함)

• 반복적으로, n번째 트레이스 라우트 메시지
• TTL이 n으로 설정되어 전송됩니다.
• n번째 라우터는 이 메시지를 폐기하고 시간 초과 ICMP 오류 메시지를 보냅니다. 이 메시지에는 n번째 라우터의 IP 주소와 이름이 포함됩니다.

• 그러나 (n + 1)번째 메시지는 목적지 호스트에 도달합니다.
• 이 호스트도 폐기되지만, 다른 이유로 인해(UDP 사용자 데이터그램에서 지정된 포트 번호를 찾을 수 없음) 폐기됩니다.
• ICMP는 포트 번호를 찾을 수 없음을 보여주는 코드 3을 가진 목적지 도달 불가능 메시지를 보냅니다.
• 이 다른 ICMP 메시지를 받은 후, 트레이스 라우트 프로그램은 최종 목적지에 도달했음을 알게 됩니다.

ICMP 체크섬

• ICMP에서 체크섬은 전체 메시지(헤더 및 데이터)에 대해 계산됩니다.

• 예시 7.18
• 그림 7.22는 간단한 에코 요청 메시지에 대한 체크섬 계산 예를 보여줍니다. 식별자를 1, 시퀀스 번호를 9로 임의로 선택했습니다. 메시지는 16비트(2바이트) 단어로 나뉩니다. 이 단어들을 더하고 합계를 보완합니다. 이제 발신자는 이 값을 체크섬 필드에 넣을 수 있습니다.

7.4.5 모바일 IP

• 노트북과 같은 모바일 및 개인용 컴퓨터가 점점 인기를 얻으면서, 어디서든 연결이 가능한 곳에서 인터넷에 연결될 수 있도록 IP 프로토콜을 확장한 모바일 IP에 대해 생각해야 합니다.

• 주소 지정 – 고정 호스트
• IP를 사용한 모바일 통신을 제공하는 데 해결해야 할 주요 문제는 주소 지정입니다.
• 원래의 IP 주소 지정은 호스트가 고정되어 특정 네트워크에 연결되어 있다는 가정에 기반을 두고 있었습니다.
• 라우터는 접두사를 사용하여 호스트가 연결된 네트워크로 패킷을 전달합니다.
• IP 주소는 호스트가 연결된 네트워크를 정의하는 부분을 포함하여 고정 호스트와 함께 작동하도록 설계되었습니다.

• 주소 지정 – 모바일 호스트
• 호스트가 한 네트워크에서 다른 네트워크로 이동할 때, IP 주소 구조는 수정되어야 합니다.
• 모바일 IP는 모바일 호스트에 대해 두 개의 주소를 가집니다: 하나는 고정 주소이고 다른 하나는 케어-오프 주소입니다. 고정 주소는 영구적이며, 케어-오프 주소는 모바일 호스트가 한 네트워크에서 다른 네트워크로 이동할 때마다 변경됩니다.

• 두 개의 주소
• 호스트는 원래 주소인 고정 주소와 임시 주소인 케어-오프 주소를 가집니다.
• 고정 주소는 영구적이며 호스트를 고정 네트워크에 연결합니다.
• 호스트가 한 네트워크에서 다른 네트워크로 이동할 때, 케어-오프 주소가 변경됩니다. 이는 호스트가 이동한 외부 네트워크와 연관됩니다.
• 모바일 호스트가 외부 네트워크를 방문할 때, 에이전트 발견 및 등록 단계 중에 케어-오프 주소를 받습니다.

• 에이전트
• 주소 변경을 인터넷의 나머지 부분에 투명하게 만들기 위해 고정 에이전트와 외부 에이전트가 필요합니다.
• 그림 7.24는 고정 네트워크에 대한 고정 에이전트의 위치와 외부 네트워크에 대한 외부 에이전트의 위치를 보여줍니다.

• 세 단계
• 원격 호스트와 통신하기 위해 모바일 호스트는 세 단계를 거칩니다: 에이전트 발견, 등록, 데이터 전송.

세 단계 - 1. 에이전트 발견

• 에이전트 발견은 두 하위 단계로 구성됩니다.
• 모바일 호스트는 자신의 고정 네트워크를 떠나기 전에 고정 에이전트를 발견해야 합니다.
• 모바일 호스트는 외부 네트워크로 이동한 후에도 외부 에이전트를 발견해야 합니다.

• 이 발견은 케어-오프 주소(CoA)와 외부 에이전트의 주소를 알아내는 것을 포함합니다.

• 발견에는 광고 및 요청의 두 가지 유형의 메시지가 관련됩니다.

• 라우터가 ICMP 광고 메시지를 사용하여 네트워크에서 자신의 존재를 광고할 때, 에이전트로서 행동한다면 패킷에 에이전트 광고를 추가할 수 있습니다.
• 그림 7.26 에이전트 광고
• 유형: 8비트 필드 (ICMP 광고 메시지의 경우 16)
• 길이: 전체 확장 메시지의 총 길이를 나타내는 8비트 필드 (ICMP 광고 메시지의 길이가 아님)
• 시퀀스 번호: 16비트 필드
• 수명: 에이전트가 요청을 수락할 초 단위 숫자
• 코드: 각 비트가 설정(1) 또는 해제(0)된 8비트 플래그
• 케어-오프 주소: 사용 가능한 케어-오프 주소 목록. 모바일 호스트는 이 중 하나를 선택할 수 있습니다. 이 케어-오프 주소 선택은 등록 요청에서 발표됩니다 (이 필드는 외부 에이전트에 의해서만 사용됨)

• 새 네트워크로 이동한 모바일 호스트가 에이전트 광고를 받지 못한 경우, 에이전트 솔리시테이션을 시작할 수 있습니다.

• ICMP 솔리시테이션 메시지를 사용하여 에이전트에게 도움이 필요함을 알릴 수 있습니다.

세 단계 - 2. 등록

• 모바일 통신의 두 번째 단계는 등록입니다.

• 모바일 호스트가 외부 네트워크로 이동하여 외부 에이전트를 발견한 후, 등록해야 합니다.

• 등록의 네 가지 측면:
1. 모바일 호스트는 외부 에이전트에 자신을 등록해야 합니다.
2. 모바일 호스트는 고정 에이전트에 자신을 등록해야 합니다.
3. 모바일 호스트는 만료된 경우 등록을 갱신해야 합니다.
4. 모바일 호스트는 돌아올 때 등록을 취소해야 합니다.

세 단계 - 2. 등록 (등록 요청)

• 등록 요청 메시지는 모바일 호스트로부터 외부 에이전트(FA)에게 보내져 케어-오프 주소를 등록하고 자신의 고정 주소 및 고정 에이전트(HA) 주소를 알립니다.

• FA는 요청을 받고 등록한 후 해당 메시지를 고정 에이전트에게 전달합니다.
• HA는 이제 FA의 IP 주소를 알고 있습니다.
• 유형: 8비트 필드 (요청 메시지의 경우 1)
• 플래그: 전달 정보를 정의하는 8비트 필드
• 수명: 에이전트가 요청을 수락할 초 단위 숫자
• 식별자: 64비트 필드는 모바일 호스트에 의해 요청에 삽입되고 응답 메시지에서 반복됩니다.
• 확장: 인증을 위한 가변 길이 확장 사용

세 단계 - 2. 등록 (등록 응답)

• 등록 응답은 HA로부터 FA에게 보내지며, 그 후 모바일 호스트에게 전달됩니다.

• 응답은 등록 요청을 확인하거나 거부합니다.
• 그림 7.28 등록 응답 형식

세 단계 - 2. 등록 (캡슐화)

• 등록 요청 또는 응답은 알려진 포트 434를 사용하여 UDP를 통해 전송됩니다.

세 단계 - 3. 데이터 전송

• 에이전트 발견 및 등록 후 모바일 호스트는 원격 호스트와 통신할 수 있습니다.
• 원격 호스트에서 HA로
• HA에서 FA로
• FA에서 모바일 호스트로
• 모바일 호스트에서 원격 호스트로

• 모바일 IP에서 비효율적인 두 가지 경우: 이중 교차, 삼각 라우팅

• 이중 교차는 원격 호스트가 동일한 네트워크로 이동한 모바일 호스트와 통신할 때 발생합니다.
• 원격 호스트가 모바일 호스트에 패킷을 보낼 때, 패킷은 인터넷을 두 번 건넙니다.

• 삼각 라우팅은 원격 호스트가 동일한 네트워크에 연결되지 않은 모바일 호스트와 통신할 때 발생합니다.
• 원격 호스트가 모바일 호스트에 패킷을 보낼 때, 패킷은 원격 호스트에서 HA로, 그리고 모바일 호스트로 이동합니다.
• 패킷은 삼각형의 두 변을 따라 이동하는데, 이는 한 변만을 따라 이동하는 것보다 멀리 이동합니다.

7.4.6 IP 패킷들의 전달

• 이 섹션에서는 전달에 IP 주소의 역할을 포함하는 개념을 확장합니다.
• 이전에 논의한 바와 같이, 전달은 패킷을 목적지로의 경로에 배치하는 것을 의미합니다.
• 오늘날의 인터넷이 링크(네트워크)의 조합으로 구성되어 있기 때문에, 전달은 패킷을 다음 홉(최종 목적지 또는 중간 연결 장치)으로 전달하는 것을 의미합니다.
• 원래 IP 프로토콜은 연결 없는 프로토콜로 설계되었지만, 오늘날의 경향은 이를 연결 지향 프로토콜로 변경하는 것입니다.

• 목적지 주소에 기반한 전달
• 이것은 오늘날 널리 사용되는 전통적인 접근 방식입니다.
• 전달을 위해서는 호스트 또는 라우터가 전달 테이블을 가지고 있어야 합니다.
• 호스트가 패킷을 보내거나 라우터가 전달할 패킷을 받았을 때, 이 테이블을 확인하여 패킷을 전달할 다음 홉을 찾습니다.

• 예시 7.19
• 그림 7.33의 구성을 사용하여 라우터 R1의 전달 테이블을 만듭니다.

• 예시 7.20
• 표 7.3 대신 비트 단위로 네트워크 주소/마스크가 주어진 표 7.4를 사용할 수 있습니다.

• 예시 7.21
• 목적지 주소가 180.70.65.140인 패킷이 그림 7.33의 R1에 도착하면 전달 과정을 보여줍니다.
• 솔루션) 라우터는 다음 단계를 수행합니다.
1. 첫 번째 마스크(/26)가 목적지 주소에 적용됩니다. 결과는 180.70.65.128이며, 해당 네트워크 주소와 일치하지 않습니다.
2. 두 번째 마스크(/25)가 목적지 주소에 적용됩니다. 결과는 180.70.65.128이며, 해당 네트워크 주소와 일치합니다. 다음 홉 주소와 인터페이스 번호 m0이 패킷 전달을 위해 추출됩니다.

• 주소 집계
• 클래스풀 주소 지정을 사용할 때, 조직 외부의 각 사이트에 대해 전달 테이블에 하나의 항목만 있습니다.
• 항목은 해당 사이트가 서브넷으로 나뉘어져 있더라도 사이트를 정의합니다.
• 패킷이 라우터에 도착하면, 라우터는 해당 항목을 확인하고 패킷을 그에 따라 전달합니다.
• 클래스리스 주소 지정을 사용할 때, 전달 테이블 항목 수가 증가할 가능성이 높습니다.
• 이 문제를 완화하기 위해 주소 집계 개념이 설계되었습니다.

예시 7.22 – 계층적 라우팅의 예

• 지역 ISP에게 120.14.64.0부터 시작하는 16,384개의 주소가 할당되었습니다.
• 지역 ISP는 이 블록을 4,096개 주소를 갖는 4개의 서브블록으로 나누기로 결정했습니다.
• 이 서브블록 중 세 개는 세 개의 지역 ISP에 할당되고, 두 번째 서브블록은 미래 사용을 위해 예약되었습니다.
• 각 블록의 마스크가 /20인 이유는 원래 /18 마스크를 가진 블록이 4개의 블록으로 나뉘었기 때문입니다.
• 4개의 지역 ISP는 네트워크 주소 지정을 위해 2비트 더 필요합니다 (18→20).
• 8개의 소규모 ISP는 네트워크 주소 지정을 위해 3비트 더 필요합니다 (20→23).
• 128개의 호스트는 네트워크 주소 지정을 위해 7비트 더 필요합니다 (23→30).

전달 테이블 검색 알고리즘

• 클래스리스 주소 지정에서는 목적지 주소에 네트워크 정보가 없습니다.

• 가장 간단하지만 가장 효율적이지 않은 검색 방법은 최장 접두사 일치입니다.
• 전달 테이블은 각 접두사마다 버킷으로 나눌 수 있습니다.
• 라우터는 먼저 가장 긴 접두사를 시도합니다.
• 목적지 주소가 이 버킷에서 발견되면 검색이 완료됩니다.
• 주소를 찾을 수 없다면 다음 접두사를 검색하고 이런 식으로 계속됩니다.

• 이러한 검색 유형은 시간이 오래 걸린다는 것이 분명합니다.

라벨 기반 전달

• 1980년대에 IP를 스위칭 방식으로 변경하는 노력이 시작되었습니다.

• 라우팅은 일반적으로 테이블 내용을 검색하는 것을 기반으로 하며; 스위칭은 인덱스를 사용하여 테이블에 접근할 수 있습니다.
• 연결 없는 네트워크(데이터그램 접근)에서는 라우터가 패킷 헤더의 목적지 주소를 기반으로 패킷을 전달합니다.
• 연결 지향 네트워크(가상 회로 접근)에서는 스위치가 패킷에 첨부된 라벨을 기반으로 패킷을 전달합니다.

• 즉, 라우팅은 검색을 포함하며; 스위칭은 접근을 포함합니다.

예시 7.23

• 그림 7.37은 최장 마스크 알고리즘을 사용한 전달 테이블에서 검색의 간단한 예를 보여줍니다.

예시 7.24

• 그림 7.38은 라벨을 사용하여 스위칭 테이블에 접근하는 간단한 예를 보여줍니다.

• 라벨이 테이블의 인덱스로 사용되기 때문에 테이블에서 정보를 찾는 것은 즉각적입니다.

새 헤더

• IP와 같은 프로토콜을 사용하여 연결 지향 스위칭을 모방하려면, 먼저 패킷에 라벨을 실을 수 있는 필드를 추가해야 합니다. IPv4 패킷 형식은 이 확장을 허용하지 않습니다. 해결책은 IPv4 패킷을 MPLS 패킷에 캡슐화하는 것입니다.

• MPLS 헤더는 곧 논의할 다단계 계층적 스위칭을 위해 사용되는 서브헤더의 스택입니다. 그림 7.40은 각 서브헤더가 32비트(4바이트) 길이인 MPLS 헤더의 형식을 보여줍니다.

• 그림 7.39 IP 패킷에 추가된 MPLS 헤더

7.4.7 라우터는 패킷 스위치

• 계층적 스위칭
• MPLS의 라벨 스택은 계층적 스위칭을 가능하게 합니다.
• 이것은 전통적인 계층적 라우팅과 유사합니다.
• 예를 들어, 두 라벨을 가진 패킷은 상위 라벨을 사용하여 조직 외부의 스위치를 통해 패킷을 전달할 수 있으며, 하위 라벨은 조직 내에서 패킷을 목적지 서브넷으로 라우팅하는 데 사용될 수 있습니다.

7.5 차세대 IP (IPv6)

• IPv4의 주소 고갈과 이 프로토콜의 다른 단점은 1990년대 초 인터넷 프로토콜 버전 6(IPv6) 또는 IP 차세대(IPng)라고 불리는 IP 프로토콜의 새로운 버전을 촉진했습니다.

7.5.1 IPv6 주소 지정

• FDEC::BBFF:0:FFFF

• FDEC:0000:0000:0000:0000:BBFF:0000:FFFF

• FDEC:0:0:0:0:BBFF:0:FFFF

• IPv4에서 IPv6로의 이전의 주요 이유는 IPv4의 주소 공간이 작았기 때문입니다.

• 표현
• IPv6 주소는 128비트(16바이트)로, IPv4의 주소 길이의 4배입니다.

- 이진 표현 (128비트): 11111110111101101011 ... 1111111100000000
- 콜론 16진수: FEF6:BA98:7654:3210:ADEF:BBFF:2922:FF00

• 줄임말
• IPv6 주소는 매우 길지만, 대부분의 숫자는 0입니다.
• 섹션의 선행 0은 생략할 수 있습니다.
• 예) 0074 → 74, 000F → F, 0000 → 0, 3210 → 3210 (줄일 수 없음)
• 0 압축: 콜론 16진수 표기법에 연속적인 0 섹션만 있을 경우 적용됩니다 (모든 0이 제거되고 두 개의 세미콜론(::)으로 대체됨).
• 예)
• 이러한 유형의 줄임은 주소당 한 번만 허용됩니다.

• 주소 공간
• IPv6의 주소 공간은 2^128 주소를 포함합니다.
• 이 주소 공간은 IPv4 주소의 2^96배입니다 — 확실히 주소 고갈은 없습니다.

• 세 가지 주소 유형
• 유니캐스트 주소
• 애니캐스트 주소
• 하나의 주소를 공유하는 컴퓨터 그룹을 정의합니다.
• 애니캐스트 주소를 가진 패킷은 그룹의 가장 접근 가능한 멤버에게만 전달됩니다.
• 여러 서버가 조회에 응답할 수 있을 때 애니캐스트 통신이 사용됩니다.
• 멀티캐스트 주소

• 주소 공간 할당
• IPv4의 주소 공간과 마찬가지로, IPv6의 주소 공간은 특별한 목적을 위해 다양한 크기의 여러 블록으로 나뉩니다.
• 대부분의 블록은 아직 할당되지 않았으며 미래 사용을 위해 예약되었습니다.
• 표 7.5는 할당된 블록만 보여줍니다. 이 표에서 마지막 열은 각 블록이 전체 주소 공간에서 차지하는 비율을 보여줍니다.

• CIDR 및 글로벌 유니캐스트 주소 블록은 2000::/3 (크기: 2^125 비트)
• 이 블록의 주소는 세 부분으로 나뉩니다.
• 글로벌 라우팅 접두사(n비트)는 인터넷을 통해 패킷을 라우팅하는 데 사용됩니다.
• 조직 사이트(예: ISP)가 이 블록을 소유합니다.
• n = 48: 3비트(고정 001) + 45비트(2^45 사이트용)
• 서브넷 식별자(m비트)
• 인터페이스 식별자(q비트)
• IPv6 주소 지정은 호스트 ID와 링크 계층 주소 간의 특정 관계를 허용합니다.
• IPv4 주소 지정에서는 링크 계층 주소가 일반적으로 호스트 ID보다 훨씬 길기 때문에 이러한 관계가 없습니다.
• 64비트보다 작은 링크 계층 주소는 인터페이스 식별자의 전체 또는 일부로 포함될 수 있습니다.
• 두 가지 일반적인 링크 계층 주소 지정 방식을 고려할 수 있습니다.
• IEEE가 정의한 64비트 확장 고유 식별자(EUI-64)
• 이더넷이 정의한 48비트 링크 계층 주소

• EUI-64 매핑
• 64비트 물리 주소를 매핑하려면 이 형식의 글로벌/로컬 비트를 0에서 1(로컬에서 글로벌로)로 변경하여 인터페이스 주소를 정의해야 합니다.

• 이더넷 MAC 주소 매핑
• 48비트 이더넷 주소를 64비트 인터페이스 식별자로 매핑하는 것
• 로컬/글로벌 비트를 1로 변경하고 추가적인 16비트를 삽입해야 합니다.
• 추가 비트는 15개의 1 뒤에 하나의 0, 즉 FFFE16으로 정의됩니다.

• 예시 7.25
• 조직에 2000:1456:2474/48 블록이 할당되었습니다. 이 조직의 첫 번째 및 두 번째 서브넷에서 블록의 CIDR 표기법은 무엇입니까?
• 솔루션
• 이론적으로, 첫 번째 및 두 번째 서브넷은 서브넷 식별자 000116 및 000216을 사용하는 블록을 사용해야 합니다.
• 이는 블록이 2000:1456:247

예시 7.25

• 한 조직에 2000:1456:2474/48 블록이 할당되었습니다. 이 조직의 첫 번째 및 두 번째 서브넷에서 블록의 CIDR 표기법은 무엇인가요?

• 해결책
• 이론적으로, 첫 번째 및 두 번째 서브넷은 서브넷 식별자 000116 및 000216을 사용하는 블록을 사용해야 합니다. 이는 블록이
• 2000:1456:2474:0001/64 및
• 2000:1456:2474:0002/64임을 의미합니다.

예시 7.26

• EUI에서 물리적 주소가 (F5-A9-23-EF-07-14-7A-D2)16인 경우, 이더넷 주소에 대해 정의한 형식을 사용하여 인터페이스 식별자를 찾으세요.

• 해결책
• 첫 번째 옥텟의 일곱 번째 비트를 0에서 1로 변경하고 형식을 콜론 16진수 표기법으로 변경하기만 하면 됩니다. 결과는 F7A9:23EF:0714:7AD2입니다.

예시 7.27

• 이더넷 물리적 주소가 (F5-A9-23-14-7A-D2)16인 경우, 이더넷 주소에 대해 정의한 형식을 사용하여 인터페이스 식별자를 찾으세요.

• 해결책
• 첫 번째 옥텟의 일곱 번째 비트를 0에서 1로 변경하고, FFFE16 옥텟 두 개를 삽입한 후 형식을 콜론 16진수 표기법으로 변경하기만 하면 됩니다. 결과는 콜론 16진수로 F7A9:23FF:FE14:7AD2입니다.

예시 7.28

• 한 조직에 2000:1456:2474/48 블록이 할당되었습니다. 컴퓨터의 IEEE 물리적 주소가 (F5-A9-23-14-7A-D2)16인 경우, 세 번째 서브넷의 인터페이스의 IPv6 주소는 무엇인가요?

• 해결책
• 이 인터페이스의 인터페이스 식별자는
• F7A9:23FF:FE14:7AD2입니다.
• 이 식별자를 글로벌 접두사와 서브넷 식별자에 할당하면,
• 2000:1456:2474:0003:F7A9:23FF:FE14:7AD2/128을 얻습니다.

특별한 주소

• (0000::/8) 접두사를 가진 주소
1. 미지정 주소: 하나의 주소 (모든 0, 0000::/128)
• 호스트가 자신의 주소를 모르고 찾기 위해 문의를 보낼 때 부트스트랩 중에 사용됩니다.
2. 루프백 주소: 하나의 주소 (0000::1/128)
3. 호환 주소 (0000::/96)
• IPv6를 사용하는 컴퓨터가 IPv6를 사용하는 다른 컴퓨터에 메시지를 보낼 때 사용됩니다.
4. 매핑 주소 (0000::FFFF/96)
• IPv6로 마이그레이션된 컴퓨터가 여전히 IPv4를 사용하는 컴퓨터에 주소를 보낼 때 사용됩니다.

링크 로컬 주소

• 링크 로컬 주소는 네트워크 내에서 사설 주소로 사용됩니다.

• 이 유형의 주소는 블록 식별자로 1111111010 (10비트)를 가집니다.

• 다음 54비트는 0으로 설정됩니다.

• 마지막 64비트는 각 컴퓨터의 인터페이스를 정의하는 데 변경할 수 있습니다.

멀티캐스트 주소

• 호스트 그룹을 정의하는 데 사용됩니다.

• 모든 이러한 주소는 접두사 11111111 (8비트)를 사용합니다.

• 플래그는 그룹 주소를 영구적 또는 일시적으로 정의합니다.

• 영구적 그룹 주소는 인터넷 기관에 의해 정의되며 언제든지 접근할 수 있습니다.

• 일시적 그룹 주소는 일시적으로만 사용됩니다(예: 텔레컨퍼런스).

자동 구성

• IPv4에서는 호스트와 라우터가 원래 네트워크 관리자에 의해 수동으로 구성되거나 네트워크에 가입하는 호스트에게 IPv4 주소를 할당하기 위해 동적 호스트 구성 프로토콜(DHCP)에 의해 자동으로 구성됩니다.

• IPv6에서는 호스트가 DHCP 프로토콜을 사용하여 IPv6 주소를 할당받을 수 있지만, 호스트는 스스로 구성할 수도 있습니다.

• IPv6에서 네트워크에 가입하는 호스트는 다음 과정을 사용하여 스스로 구성할 수 있습니다:
1. 호스트는 먼저 자신에게 링크 로컬 주소를 생성합니다.
2. 호스트는 링크 로컬 주소가 유일하고 다른 호스트에 의해 사용되지 않는지 테스트합니다.
3. 유일성이 확인되면, 호스트는 이 주소를 사설 통신을 위한 링크 로컬 주소로 저장하지만, 여전히 전역 유니캐스트 주소가 필요합니다.

• 호스트는 로컬 라우터에 메시지를 보냅니다.

• 네트워크에서 라우터가 실행 중이면, 호스트는 전역 유니캐스트 접두사와 서브넷 접두사를 포함한 메시지를 받습니다.

• 호스트는 자신의 인터페이스 식별자에 이 접두사를 추가하여 자신의 전역 유니캐스트 주소를 생성하고 저장합니다.

예시 7.29

• 이더넷 주소 (F5-A9-23-11-9B-E2)16을 가진 호스트가 네트워크에 가입했다고 가정합니다. 조직의 전역 유니캐스트 접두사가 3A21:1216:2165이고 서브넷 식별자가 A245인 경우, 해당 호스트의 전역 유니캐스트 주소는 무엇입니까?

• 해결책
• 호스트는 먼저 이더넷 주소를 사용하여 F7A9:23FF:FE11:9BE2로 인터페이스 식별자를 생성합니다.
• 호스트는 링크 로컬 주소를 FE80::F7A9:23FF:FE11:9BE2로 생성합니다.
• 이 주소가 유일하다고 가정하고 라우터 솔리시테이션 메시지를 보내면, 호스트는 전역 유니캐스트 접두사와 서브넷 식별자의 조합을 발표하는 라우터 광고 메시지를 받습니다.
• 호스트는 자신의 인터페이스 식별자에 이 접두사를 추가하여 자신의 전역 유니캐스트 주소를 찾고 저장합니다:
• 3A21:1216:2165:A245:F7A9:23FF:FE11:9BE2
• 이 주소가 고유하다고 가정하면, 호스트는 라우터 요청 메시지를 보내고 글로벌 유니캐스트 접두사와 서브넷 식별자의 조합을 발표하는 라우터 광고 메시지를 받습니다:
• 3A21:1216:2165:A245.
• 호스트는 그 후에 이 접두사에 자신의 인터페이스 식별자를 추가하여 자신의 글로벌 유니캐스트 주소를 다음과 같이 찾아 저장합니다:
• 3A21:1216:2165:A245:F7A9:23FF:FE11:9BE2

재번호화

• 사이트가 서비스 제공자를 변경할 수 있도록 하기 위해, IPv6 주소 지정에 주소 접두사(n)의 재번호화 기능이 내장되었습니다.

• 이전에 논의한 바와 같이, 각 사이트는 연결된 서비스 제공자로부터 접두사를 받습니다.

• 사이트가 제공자를 변경하는 경우, 주소 접두사도 변경해야 합니다.

• 사이트에 연결된 라우터는 새 접두사를 광고하고 사이트가 짧은 시간 동안 구 접두사를 사용한 후 비활성화하도록 할 수 있습니다.

• 즉, 전환 기간 동안 사이트는 두 개의 접두사를 가집니다.

• 재번호화 메커니즘을 사용하는 주요 문제는 DNS의 지원입니다.

• 이 메커니즘을 지원하기 위해 Next Generation DNS라고 불리는 DNS의 새로운 프로토콜이 연구 중입니다.

7.5.2 IPv6 프로토콜

• IPv6 주소 크기의 변경은 IPv4 패킷 형식의 변경을 요구합니다.

• IPv6의 설계자들은 변경이 불가피한 지금 다른 단점들에 대한 해결책을 구현하기로 결정했습니다.

• 주소 크기와 형식 변경 외에 프로토콜에서 구현된 다른 변경 사항은 다음과 같습니다.

• 패킷 형식
• 각 패킷은 기본 헤더와 그 뒤에 오는 페이로드로 구성됩니다.
• 그림 7.46 IPv6 데이터그램
• 버전: IP 버전 번호 (IPv6의 경우 6)
• 트래픽 클래스: 다양한 전달 요구 사항을 가진 다른 페이로드를 구분하기 위함 (IPv4의 서비스 유형 필드)
• 플로우 라벨: 특정 데이터 흐름에 대한 특별한 처리를 제공하기 위해 설계된 20비트 필드
• 페이로드 길이: 헤더를 제외한 IP 데이터그램의 길이를 정의하는 2바이트 필드 (IPv4의 헤더 길이 및 총 길이. IPv6 헤더 길이는 고정됨)
• 다음 헤더: 첫 번째 확장 헤더의 유형을 정의하는 8비트 필드 (있는 경우) 또는 데이터그램의 기본 헤더 뒤에 오는 데이터의 유형 (IPv4의 프로토콜 필드)
• 홉 제한: 이 필드는 IPv4의 TTL 필드와 동일한 목적으로 사용됩니다.

• IPv6의 페이로드 필드는 다른 형식과 의미를 가집니다.
• 페이로드는 0개 이상의 확장 헤더를 가질 수 있습니다.
• 각 확장 헤더는 다음 헤더와 길이라는 두 필수 필드를 가지며, 특정 옵션과 관련된 정보를 뒤따릅니다.
• 각 다음 헤더 필드 값(코드)은 다음 헤더의 유형을 정의합니다 (홉별 옵션, 소스 라우팅 옵션 등).
• 마지막 다음 헤더 필드는 데이터그램에 의해 운반되는 프로토콜(UDP, TCP 등)을 정의합니다.

• IPv6에서 흐름과 우선순위의 개념
• IP 프로토콜은 원래 연결 없는 프로토콜로 설계되었습니다.
• 그러나 IP 프로토콜을 연결 지향 프로토콜로 사용하는 경향이 있습니다.
• 앞서 설명한 MPLS 기술은 라벨 필드를 사용하여 IPv4 패킷을 MPLS 헤더에 캡슐화할 수 있게 합니다.
• 버전 6에서는 IPv6를 연결 지향 프로토콜로 사용할 수 있도록 플로우 라벨을 직접 IPv6 데이터그램 형식에 추가했습니다.

• 조각화 및 재조합
• IPv6 프로토콜에서 여전히 데이터그램의 조각화 및 재조합이 있습니다.
• IPv4와의 주요 차이점은 IPv6 데이터그램은 소스에 의해서만 조각화될 수 있으며, 재조합은 목적지에서 이루어진다는 것입니다.

• 확장 헤더
• IPv6 패킷은 기본 헤더와 일부 확장 헤더로 구성됩니다.
• 기본 헤더의 길이는 40바이트로 고정되어 있습니다.
• 홉별 옵션, 소스 라우팅, 조각화, 인증, 암호화된 보안 페이로드, 목적지 옵션 등 6가지 유형의 확장 헤더가 정의되었습니다.
• 이들 헤더 중 많은 것은 IPv4에서 옵션입니다.

7.5.3 ICMPv6 프로토콜

• ICMPv6은 ICMPv4보다 복잡합니다.

• 일부 프로토콜은 ICMPv6의 일부이며, 더 유용하게 만들기 위해 새로운 메시지가 추가되었습니다.

• 네 가지 유형의 오류에 대한 오류 보고 메시지 (목적지 도달 불가, 패킷 너무 큼, 시간 초과, 매개변수 문제)

• 이웃 발견 메시지

• 두 가지 새로운 프로토콜: 이웃 발견(ND) 프로토콜과 역이웃 발견(IND) 프로토콜

• 멀티캐스트 리스너 딜리버리(MLD) 프로토콜을 위한 그룹 멤버십 메시지

• 멤버십 쿼리 메시지와 멤버십 보고 메시지

7.6 IPv4에서 IPv6로의 전환

• IPv4 사용을 중단하고 IPv6 사용을 시작하기 위해 어떻게 전환할 수 있을까요?

• IPv4와 IPv6 시스템 간의 문제를 방지하기 위해 전환은 부드러워야 합니다.

• 전환을 위해 세 가지 전략이 고안되었습니다: 듀얼 스택, 터널링, 헤더 변환

• 이 세 가지 전략 중 하나 또는 전부가 전환 기간 동안 구현될 수 있습니다.

• 듀얼 스택
• 버전 6으로 완전히 이주하기 전에 모든 호스트가 전환 기간 동안 듀얼 프로토콜 스택을 가지는 것이 권장됩니다.
• 다시 말해, 모든 인터넷이 IPv6를 사용할 때까지 스테이션은 IPv4와 IPv6을 동시에 실행해야 합니다.

• 터널링
• 터널링은 IPv6를 사용하는 두 컴퓨터가 서로 통신하려고 하고 패킷이 IPv4를 사용하는 지역을 통과해야 할 때 사용되는 전략입니다.
• 이 지역을 통과하기 위해 패킷은 IPv4 주소를 가져야 합니다.
• IPv6 패킷은 이 지역에 들어갈 때 IPv4 패킷에 캡슐화되며, 이 지역을 벗어날 때 캡슐에서 벗어납니다.
• IPv6 패킷이 한쪽 끝의 터널을 통과하여 다른 쪽 끝에서 나타나는 것처럼 보입니다.
• IPv4 패킷이 데이터로 IPv6 패킷을 운반하고 있다는 것을 명확히 하기 위해 프로토콜 값은 41(41: IPv6 캡슐화, RFC2473)으로 설정됩니다.

• 헤더 변환
• 대부분의 인터넷이 IPv6로 이동했지만 일부 시스템은 여전히 IPv4를 사용할 때 헤더 변환이 필요합니다.
• 발신자는 IPv6를 사용하고자 하지만 수신자는 IPv6를 이해하지 못합니다.
• 수신자가 이해할 수 있는 IPv4 형식으로 패킷이 있어야 하기 때문에 이 상황에서 터널링은 작동하지 않습니다.
• 이 경우 헤더 형식은 헤더 변환을 통해 완전히 변경되어야 합니다.
• IPv6 패킷의 헤더는 IPv4 헤더로 변환됩니다.