netwhat

netwhat는 코드를 작성하는 프로젝트가 아닙니다. 프로젝트를 시작하면 10분간 컴퓨터 네트워크의 기본을 묻는 20문제들이 제시됩니다. 계산 문제가 특히 많기 때문에 Slack 등에 게시되어 있는 IP Calculator를 사용이 반 필수적입니다.

문제를 다 풀고 평가를 받게 되었을 때, GitHub 레포를 클론하게 되면 answer.txt에는 키 값이 들어있습니다. 이 키 값을 netwhat.42.fr에 들어가서 로그인 후 입력하면, 풀었던 문제들의 정답 체크 및 본인의 답안을 확인할 수 있습니다.

실제로 평가를 받을 때는 지수에 대한 연산도 필요하므로 공학용 계산기를 같이 이용하는 것이 좋습니다.

내용을 읽다보면 가끔 어려운 단어들이 등장합니다. 이 때, 차근차근 읽어 내려가다 보면 설명이 되어있습니다! 만약 설명이 되어 있지 않은데다가, 특정 용어를 몰라서 넘어가지 못하고 있다면 구글링을 통해 단어를 찾아보면서 학습하시면 됩니다!

한 번 읽고 모두 이해하는 것은 불가능 합니다. 모든 것을 이해하고 넘어가는 것 보다 다회독으로 공부하하는 것을 추천합니다.

그래도 모르면 일단 넘어가고 차차 익혀가시길 바라요. (원래 어렵습니다.)

또한 아래의 글에서는 IP Packet이 Routing되어 전송되는 과정 및 TCP, UDP에 대해서는 구체적으로 다루지 않습니다. 이 부분이 궁금하다면 jseo()에게 물어봐주세요. (자세히 아는 건 아니지만... 같이 찾아보면서 열심히 해볼게요 ㅎㅎㅎ...)

정확히 3가지를 기억하면 된다.

많은 블로그에서는 Protocol이란 Sender, Receiver의 상호 간의 규약 (통신을 효율적으로 혹은 특정 목적을 달성하기 위한) 이라고 명시를 해둔다. 그렇다면 그 규약이 무엇을 정의하고 있는지가 중요할텐데, 그것이 위의 3가지 키워드이다.

를 명시한 것이 Protocol이다.

결과적으로,

특정 Protocol로 사용자와 통신을 하는 과정에서 메세지의 Delivery가 발생했다고 하면, Delivery외의 잡다한 일을 한 장치에서 모두 수행하지 않는다. 이 때 Protocol이 수행하는 특정 행위 외의 모든 것들을 하위 계층의 Protocol에게 맡긴다.

구조를 살펴보면, 하위 계층의 Protocol 다시 하위 계층의 Protocol에게 위임하는 Recursive Relationship이 발생하는데, 이 때의 논리 구조를 Protocol Stack이라고 부른다. (층층이 둔다는 Layering의 의미와 동일)

Layering이 필요한 이유에 대해서 Single Layer 구조와 Triple Layer 구조를 통해 살펴보자.

이 때의 요구 조건은 서로가 만났을 때 인사를 해야하며, 서로의 관계에 따른 할 말을 골라야하며, 상대가 말할 때는 침묵을 해야 하고, 서로가 헤어질 때는 잘가라는 인사를 해줘야 한다.

이 때의 요구 조건은 만나지 않아도 (육체적으로 멀어도) 소통이 가능하고, 서로가 하고 싶은 말이 있다면 동시에 소통을 해도 되며, 암호화 덕에 둘 외에 다른 사람들은 소통에 참여를 할 수가 없으며, 내가 쓰고 싶은 말을 쓰기만 하면 직접 전달하지 않아도 전달이 보장된다.

즉, Layering을 하게 되면 한 층에서 Protocol이 수행해야하는 행동 범위가 많이 줄어들면서 각자 자신의 임무만 명확히 수행하게 될 수 있는 장점이 생긴다. 따라서 Protocol Layering이라는 것은 복잡한 업무를 작은 일의 단위로 나누어 간단한 업무를 부담하게 하는 것으로 볼 수 있다.

비록 간단한 업무가 복잡해질 수는 있더라도 Protocol Layering을 했을 때 다음과 같은 기대 효과를 얻을 수 있다.

OSI 7 계층은 매우 잘 정의 (Well-Defined)된 개념적 구조라고 보면 된다. 각 Protocol의 보편적인 역할을 설명하기 위해 사용된다. OSI 7 계층는 ISO (International Organization for Standardization)에서 만들었으며, 이름 그대로 7개의 계층을 이룬다. 각 계층별 역할은 다음과 같다.

간혹 편의를 위해 아래 계층들을 4개의 Layer로 보기도 하는데, 1계층과 2계층을 묶은 Link Layer, Network Layer, Transport Layer, 5계층과 6계층 그리고 7계층을 묶은 Application Layer로 표현하기도 한다.

매채를 통해 비트 데이터를 Stream의 형태로 전송하고 받는 역할을 수행하여 기계적 전기적인 특성을 제공하는 Layer이다.

Data Link Layer로부터 받은 Frame을 실제 비트로 해석할 수 있도록 비트 스트림으로 만들어서 역할을 수행한다.

역할을 수행할 때는 비트를 Electrical Signal, Light Signal, Radio Signal 등으로 처리를 한다. 이 때 처리의 단위가 비트가 아닌 Signal인 이유는 여러 비트를 한 Signal에 넣어서 이용하고 이를 통해 처리 횟수를 줄일 수 있기 때문이다.

비트 데이터 혹은 Packet을 Frame화 하여 기기 간 Hop-to-Hop 전달하는 역할을 하는 Layer이다.

Hop-to-Hop으로 전달한다는 의미는 서로 속한 네트워크가 같으면서 인접한 기기 (Adjacent Node)에게 데이터를 전달한다는 것이다. 이 때 기기가 가진 실제 주소(MAC 주소)를 이용한다.

Data Link Layer는 Network Layer의 인터페이스로 작용된다. (즉, 성공적으로 데이터를 보내기 위해선 Network Layer는 목적지에 대한 명확한 Data Link Layer의 주소를 명시할 수 있어야 한다는 것이다.)

또한 Hop-to-Hop으로 인접한 기기에 전송된 데이터들은 Error가 없도록 전달된다. 즉, 수신 측 기기에서는 이미 올바른 데이터들을 무조건 받게되어 있다는 것이다. 이 덕에 수신 측에서는 수신한 데이터를 상위 Layer로 올릴 때 Error Free를 가정할 수 있다.

Transport Layer와 같이 Flow Control, Error Detection, Error Correction이 가능하다. 하지만 이는 Transport Layer의 것과는 조금은 다르다. Tranposrt Layer는 인터넷 상에서 Logical Connection 상태에서의 Layer 간 전달에서 일어나는 것이고, Data Link Layer에서는 네트워크 내의 기기간 전달에서 일어나는 것이다.

상호 간의 네트워킹을 위해 Packet의 형태로 Source에서 Destination으로 운송하는 역할을 수행하는 Layer이다.

단순히 Destination까지의 운송 역할만 수행하는 것이 아니라 정확히 따지자면, Network Layer는 Routing과 관련이 있다.

IP에 해당하는 것들이 Network Layer에 해당하는데, 이 때 IP는 Connectionless이며 단순히 Destination을 찾아가기 위한 용도의 Internetworking 서비스라고 보면 된다.

IP는 기본적으로 End-to-End의 Reliable Delivery를 보장해주진 않는다. 그렇다고 최선을 다하지 않는 것은 아닌데, 이를 Best Effort Delivery라고 한다.

Network Layer에서 사용하는 주소는 IP 주소로 일종의 Logical Address이다. (말 그대로 기기에 대한 실질적인 주소는 아니다.) Public IP와 같이 사용되는 IP 주소는 사용자에 대해서 Uniquely, Universally Distinguishable하게 해준다.

신뢰성 보장 등을 위해 정해진 순서대로 메세지를 구성하여 넘겨주어 Error Detection 혹은 Error Correction등을 수행할 수 있는 Layer이다.

Transport Layer의 가장 기본적인 기능은 Unreliable Data Delivery이다. (신뢰성을 보장해주지 않은채로 전달하는 것이 가장 기본적인 기능이다.) 즉, Connection-Oriented Protocol (TCP, SCTP, RTP 등)과 Connectionless Protocol (UDP) 중에서 후자가 Transport Layer의 가장 기본적인 기능을 수행하는 Protocol이라고 보면 된다.

다음은 Connectionless Protocol과 달리 Connection-Oriented Protocol의 주된 5가지 기능이다.

Session 대한 생성, 관리, 종료를 담당하는 Layer이다.

Endpoint를 사용하는 사용자 간의 Application Process들 사이에 Session을 열고 닫고 관리하는 메커니즘을 수행한다. 따라서 두 Host 사이에 첫 Connection을 열기도 하고, 이렇게 열린 Session을 통해서 정해진 시간동안 데이터 송신과 수신을 가능하게 해준다.

예를 들면, VoIP(Voice over IP)에서 사용되는 SIP (Session Initiate Protocol)가 이에 해당한다.

이러한 Session Layer가 중요한 이유는, Endpoint간 메세지 송신 수신을 진행하면서 Dialog Control (Endpoint의 Token을 이용하여 누가 전송할 차례인지에 대한 순서 조정 및 관리)과 Synchronization (Stream으로 들어오는 데이터에 대해서 동기화 지점을 기록)이 가능하도록 만들어주기 때문이다.

Session Layer에는 여러 경우들이 있는데.

One to Many의 경우 가장 일반적인 경우라고 보면 된다.

데이터에 대한 Translate, Encrypt (Decrypt), Compress (Decompress) 등을 수행하는 Layer이다. (참고로 네트워크에서는 Big Endian을 사용한다.)

데이터를 Network Format에서 Application Format으로 바꾸거나, Application Format에서 Network Format으로 바꾸는 역할을 한다.

예를 들어서 송신 시에 Encoding, Compressing을 작업 했다면, 수신 측에서는 Decoding, Decompressing 작업을 수행한다.

네트워크 자원에 접근할 수 있도록 해주는 Layer이다. 네트워크 자원에 접근할 수 있기 때문에, 송신과 수신을 위한 데이터를 네트워크에 제공하는 역할을 수행한다.

7개의 Layer 중에서 가장 위에 있는 Layer로써, 사용자와 직접 상호작용을 하며 동작하기 때문에 사용자에게 보이는 부분이다.

예를 들면 Internet Explorer 혹은 Google Chrome과 같은 Browser가 있을 수 있고, Gmail과 같은 Email Client가 있다.

송, 수신 시에 송신 측에서는 7 ~ 1 계층을 거쳐 수신 측의 1 ~ 7 계층을 지나서 메세지가 전달된다. 이 때의 주고 받는 메세지의 데이터 형식은 아래와 같다.

주 목표는 존재하는 서로 연결된 네트워크들의 Multiplexed Utilization (다중 활용)을 위해 효율적인 기법을 만들어 내고자 하는 것이다.

부가적인 목표로는 다음과 같은 것들이 있다.

통신은 Endpoint와 Endpoint 간에 일어나는 것이고, 통신에 있어서 필요한 복잡한 기능들은 Endpoint에 위치하고 있어야 한다.

즉, Transport Layer와 Application Layer는 (5, 6, 7 계층을 보통 크게 묶어서 Application Layer라고 하기도 함) Host의 컴퓨터에만 존재하며, Router는 Network Layer, Data Link Layer, Physical Layer의 기능만 수행하게 된다. (Switch는 Data Link Layer 및 Physical Layer에 대한 기능을 지원한다.)

End-to-End 원칙을 고수하는 이유는 여러 기술을 쉽게 수용할 수 있도록 하여 확장성을 높이기 위함이다. 이런 이유 때문에 End-to-End 원칙은 네트워크 계층 설계에 핵심적으로 작용하지만, 실제로는 의도적으로 무시하는 경우들이 존재한다.

사용자들이 광고를 보는 조건으로 무료 WiFi를 제공 받는 상황이라고 할 때, 광고를 끼워넣기 위해서는 Endpoint 간의 통신에서 무선 공유기가 끼어들 수 있어야 한다. 또한 게임 서비스를 제공할 때 로드밸런서를 이용한다면, Client라는 Endpoint와 Server라는 Endpoint 중간에 로드밸런서라는 장비를 넣는 것도 일종의 End-to-End 원칙을 의도적으로 깬 것이라고 볼 수 있다. (보안 장비 혹은 토렌트의 트래픽을 별도로 처리하기 위한 QoS 장비들도 이에 해당할 수 있다.)

"IP위의 모든 것, 모든 것 위의 IP" (IP over anything, anything over IP)라는 말이 있을 정도로 IP 위 아래로의 기술 발전이 많이 있었다. 때문에 IP에 대한 수정은 굉장한 어려움이 따른다.

Internet Architecture 목표들 중 다양한 네트워크 수용을 위한 대부분의 Independent한 기술들이(아무리 Independent하게 짜려고 해도), IP를 기반으로 개발을 진행해왔기 때문이다. 이로 인한 문제는 수정 어렵다는 것이고, 이 뿐 아니라 근간이되는 최하위 레벨에서는 굉장히 소량의 정보들만 이용할 수 밖에 없다는 어려움도 있다. (무선과 같이 말이다.)

Identity란 무엇일까? 바로 내가 누구인지 (Identifier), 내가 어디에 있는지(Locator)를 밝히는 것이라고 볼 수 있다. 이러한 Identity는 통신 시 요구되는 기본 사항이다.

통신에서 Identity를 요구하기 때문에 유선, 무선에 대해서도 각각 표준이 존재하며, 당연하게도 네트워크 통신에서도 이런 개념이 존재한다.

네트워크에서의 Identity는 NAI라고 하며 이는 RFC2486 (Obsoleted by RFC4282) → RFC4282 (Obsoleted by RFC7542) → RFC7542 순으로 발전해왔다.

RFC7542는 Domain간 로밍(인증) 서비스를 지원하기 위해 사용자를 구분할 수 있는 표준이 필요하다는 규정이다. RFC4282에 NAI에 대해 아래와 같은 예제가 등록되어 있다.

이러한 NAI에 대한 RFC7542에서 나타나는 Identifier는 RFC5322 + RFC6532를 따르며 Application Layer에서 일반적으로 사용된다.

RFC5322는 Internet Message Format을 기반으로 한 사용자에 대한 부분(User Portion / username)이고, RFC6532는 위치에 대한 부분(Local Portion / realm)으로써 Internationalized Email Header의 연장선인 이메일 형식으로 나타난다.

이렇게 정의된 Identifier는 대체로 utf8을 기반으로 작성되는데, 이런 utf8으로 작성된 realm 부분에 대해서는 Internationalized Domain Names (IDNs)에 맞는 호환성을 갖는 식으로 의도되어 있다. 따라서 RFC5890을 따른다.

RFC5890은 Internationalized Domain Names에 대한 Syntax 정의 규약이라고 볼 수 있다. 기본적으로는 RFC1034(LDH라고 하여 Letters, Digits, Hyphen를 사용하는 Syntax)를 선호하고 따르는 분위기이지만, Symmetry Constraint만 지킨다면 A-label (ASCII), U-label (UNICODE)에 대한 이용이 가능하다.

Application Layer에서 NAI를 통해서 사용자들과 Domain에 대한 구분을 지었듯이, 다른 계층에서도 각자만의 Identifier로 구분을 짓는다.

Internet Protocol Stack에 대해서 명확히 알아야 한다.

적어도 이 세가지를 무난하고 정확하게 답할 수 있다면, 컴퓨터 네트워크에 대한 기본 지식은 깔려있다고 보면 되겠다.

RFC791 (IP 표준에 대한 규약)을 따른다.

후에는 CIDR이라고 해서 Classless Inter-Domain Routing으로 주소를 할당하고 집계 전략을 펼쳤다. (RFC1519)

Private Internet에 대한 주소 할당 규약이 있다. (RFC1918) Address Mask를 이용한 Internet Standard Subnetting Procedure (RFC950)가 존재한다. IP Multicasting을 위한 Host Extension (RFC1112)이 존재한다.

IPv4 주소의 형태는

와 같은 형태인데, Subnet을 이용하는 경우의 Mask 주소 형태는

가 된다. Masking 비트들은 1로 채워져서 & 연산을 통해 Host를 분별해낼 수 있다.

(이 때 채워진 모든 1 값들은 비트가 꽉 차있는 형태므로 -1로 표현하는 것이다.

현재 네트워크에서 가장 많이 사용되는 방식이다. Unicast 방식은 하나의 송신자가 다른 하나의 수신자로 데이터를 전송하는 방식으로 일반적인 인터넷 응용 프로그램이 모두 Unicast 방식을 사용한다. Unicast 통신은 목적지를 제외한 다른 네트워크상의 PC들의 CPU성능을 저하시키지 않는다! 그 이유는 자신에게 온 Packet이 아니라고 판단되면 해당 Frame을 버리기 때문이다!

만약 동일한 데이터를 여러 수신자에게 보내고 싶다면, Unicast 통신을 사용하면 데이터를 여러번 전송해야 하며 동일한 Packet의 중복 전송으로 인해 네트워크 효율이 저하된다!

여기서 Local이란 Router에 의해서 구분되어진 공간, 즉 Broadcast Domain이라고 하는 공간을 뜻한다. Broadcast 주소로 Packet이 오면 자신의 MAC 주소와 같지 않아도 무조건 읽어서 CPU로 전달한다.

반드시 필요한 통신 방식이지만, 데이터 수신이 필요없는 Host들에게도 데이터가 전송되기 때문에 불필요한 인터럽트가 발생된다. 또한 자신이 속한 네트워크에만 한정된고, Router를 경유하지 못한다는 단점이 있다.

Multicast의 경우 자신이 데이터를 받기 원하는 특정 Host들에게만 보내는 것이 가능하지만, Switch나 Router가 이 기능을 지원해주어야 한다! Multicast 전송을 위한 그룹 주소는 D Class IP 주소 (224.0.0.0 ~ 239.255.255.255)로 실제 Host를 나타내는 주소가 아니며 그룹 주소를 이용한다.

예를 들어, 네트워크 상에 200명의 사용자가 있을 때, 150명에게만 정보를 보내고 싶을 때 사용하는 통신이다. Broadcast를 사용하면 해당 데이터가 필요하지 않은 50명의 PC성능이 저하된다, Unicast를 사용하면 같은 Packet을 150번 전송해야 해서 비효율적이다. 즉 이러한 문제를 해결하기 위한 통신 방법인 것이다.

Multicast는 네트워크 상에서 One-to-Many 통신을 위한 기법이다. Multicast는 (많은 수신자를 목표로 하더라도) Packet이 한 번만 전송될 수 있도록 자원을 끌어모으는 식으로 네트워크 인프라를 효율적으로 사용한다. 즉, Unicast를 기반으로 한다.

IPv4 Packet을 전송하려는 컴퓨터에서 Source IP 주소를 모르는 경우에 자신의 IPv4 주소로 0.0.0.0이 이용된다.

예를 들면, DHCPDISCOVER와 같은 작업에 이용되는데 아래 그림과 같이 IPv4 Packet을 날리면 DHCP Server로 부터 답을 받을 수 있다.

모든 비트가 1인 IPv4 주소는 Broadcast에 이용된다. 또한 특정 네트워크 전체에 보내는 Broadcast가 아닌 아래 그림과 같이 특정 Subnet에만 보내는 Broadcast의 경우, 정해진 전체 네트워크에 Broadcast Packet을 뿌리는 것이 아니라 특정 Subnet에 Broadcast Packet을 뿌리는 것도 가능하다. 이를 IP Directed Broadcast라고 한다.

이와 같이 IP Directed Broadcast로 Packet을 날리게 되어서 Target Subnet을 향해 경로 타고 가면, 네트워크는 이 Packet을 Unicast Packet을 전송할 때와 동일한 방법으로 Forwarding 한다. (즉, Unicast Packet과 동일한 취급을 한다.) 이렇게 Target Subnet에 연결된 Switch까지 Unicast처럼 전송된 Packet은 해당 Switch에 도착하면, Switch가 알아서 Subnet에 해당한 모든 Endpoint 단말에게 Packet을 Broadcast해준다.

자기 자신(Local Host)을 나타내는 Loopback 주소이다.

사설망과 통신할 때 사용되는 주소이다. (기관 등에서 전화 회선 연장을 위해 사용하는 것과 비슷하다.)

클래스 C에서의 2개의 Host → (2 / 254 = 0.78% Efficient) ($2^8 - 2 = 254)$

클래스 B에서의 256개의 Host → (256 / 65536 = 0.39% Efficient) ($2^8 * 2^8 - 2 = 65534)$

IPv4 주소가 차지하는 공간의 수가 굉장히 빠르게 소모되는 것을 볼 수 있다.

Routing Table은 확장되지 않는다.

Routing Propagation Protocol 역시 확장 되지 않는다.

Forwarding을 위한 큰 Routing Table을 Router가 스캔할 때 굉장히 느려진다.

그래서..? 클래스에 대해서만 인식하던 인터넷에 대해 클래스 개념을 없애보는 쪽으로 2006년 08월에 CIDR (Classless Inter-Domain Routing (RFC4632))이 제시되었다. (IPv4 주소에 대한 자유도가 올라감)

CIDR은 클래스 A, B, C의 Network Part 개념을 Classless한 Prefix로 바꾼 것을 말한다. (기존 클래스 A, B, C에 대해서 Class를 없애면 어디 부분까지가 Network Part이고, 어디 부분까지가 Host Part인지 구분이 불가능하므로 Subnet Mask에 대한 필요성이 등장하게 된다.) 이 때, Network Part는 특정 범주 내에서 사용되는 Endpoint 단말의 Network Part를 이용한다. (Subnet Mask는 다음 파트에서 다룬다.)

CIDR 표기법에서 Prefix는 기존 IPv4 주소처럼 4개의 Octet으로 표기되며 그 뒤에 / 가 붙으면서 이어서 특정 비트 수에 대해서 명시한다. IPv4 주소의 경우 32 비트의 길이를 갖기 때문에, / 뒤에는 0 ~ 32 사이의 10진수 값이 표기 된다.

암묵적으로 255.255.0.0의 네트워크 주소 Mask를 이용하는 기존 클래스 B 네트워크의 172.16.0.0 IPv4 주소는 CIDR 표기법으로 172.16.0.0/16이 된다.

Subnetwork 혹은 Subnet이라고 부르는 것은 IP 네트워크에 대한 논리적 분할이다.

Subnet Mask 혹은 Subnetwork에 대해서 알아내고자 계산을 할 때는, Logicial Multiplication을 이용한다. 예를 들어서 192.168.0.1/24라는 CIDR 표기법으로 나타낸 IPv4 주소가 주어졌다고 해보자. 이에 따른 Subnetwork 주소 구할 때는 IPv4 주소에 Subnet Mask 주소를 & 연산을 취하면 되고, Subnet Mask 주소를 구할 때는 IPv4 주소에 Subnetwork 주소를 & 연산을 취하면 된다.

IPv4 by Binary → $1100 0000$ . $1010 1000$ . $0000 0000$ . $0000 0001$

Subnet Mask → $11111111$ . $11111111$ . $11111111$ . $0000 0000$

Subnetwork → $11000000$ . $1010 1000$ . $00000000$ . $00000000$

이 때의 추가로 사용할 수 있는 Host수는 253개이다. (자기 자신 IP, 네트워크 자체에 대한 IP {<Network>, 0}, 네트워크의 Broadcast IP {<Network>, -1}을 제외한 253개이다.)

Subnet Mask 값의 목적은 Host Part 부분에 대한 유동적인 분할에 대한 명시이다. Subnet 자체는 해당 네트워크 내부에서만 확인이 가능하다. 단순히 IPv4 주소만 주어진 상태에서는 Subnet이 어떻게 되는지 알 수 없다. 따라서 아래와 같이 클래스 B의 IPv4 주소가 주어졌을 때는 어떤 Subnet인지 알 수 없지만, Subnet Mask가 주어지면 어느 Subnet을 이용하고 있는지 알 수 있다. (계산할 때는 항상 2진수!)

두 Netting 모두 Network Mask를 사용한다.

큰 네트워크를 작은 여러 개의 네트워크로 나누는 기법이다. 네트워크 구조를 계층적으로 둘 수 있다. Supernetting과 마찬가지로 Routing에 도움을 준다. 기존 네트워크 Prefix에서 추가적으로 그룹을 형성하여 나눴기 때문에 그룹에 따라서 네트워크 Prefix를 위한 비트 수가 증가한다.

예를 들어서 클래스 B 네트워크의 경우, 256개의 클래스 C 네트워크로 나눌 수 있다. 이 때의 Network Part의 Prefix는 16 비트에서 24 비트로 증가한다.

다음을 풀어보자

작은 여러 개의 네트워크를 하나의 큰 네트워크로 묶는 기법이다. 그루핑을 도와주기 때문에 Routing Entry가 좋아지게 되고 이를 통해 Router의 Lookup이 편해진다. 기존에 여러 네트워크를 하나의 그룹으로 묶어냈기 때문에 기존에 이용하던 네트워크 Prefix의 비트 수가 감소한다.

예를 들어서 4개의 클래스 C 네트워크를 하나의 네트워크로 Supernetting한 경우, Network Part의 Prefix는 24 비트를 사용하다가 2 비트 (4개의 클래스 → $2^2$ → 2 비트) 만큼 줄어서 Network Part의 Prefix는 22 비트로 이용하게 된다.

Supernetting에 대한 표현은 Supernetting된 네트워크 IPv4 주소와 묶을 수에 대한 소괄호 쌍인

와 같이 표기한다.

예를 들어서 (192.5.48.0, 3)이라고 하면 실제로는 192.5.48.0, 192.5.49.0, 192.5.50.0 이렇게 3개가 묶인 것이다. 이에 대한 풀이는 아래와 같다.

→ 48.0으로 Supernetting 된 것이니 이를 2진수로 변환 해보면 00110000.00000000 인데, 여기서 3개를 묶기 위해선 2 비트 (4개의 사용자에 대한 커버리지 → $2^2$ → 2 비트)가 필요하다는 사실을 알 수 있다. 클래스 C IPv4 주소에 대해서 2 비트를 이용한 Supernetting을 한 것이니, 24 비트에서 2 비트가 줄어서 22 비트로 그루핑을 한 것이라고 볼 수 있다는 것이다. 그럼 그루핑 된 3개의 IPv4 주소는 00110000.00000000 (48.0), 00110001.00000000 (49.0), 00110010.00000000 (50.0) 3개가 됨을 알 수 있다.

비슷한 예로 X.Y.32.1 ~ X.Y.32.254 (첫 번째 클래스 C 주소들), X.Y.33.1 ~ X.Y.33.254 (두 번째 클래스 C 주소들), X.Y.34.1 ~ X.Y.34.254 (세 번째 클래스 C 주소들), X.Y.35.1 ~ X.Y.35.254 (네 번째 클래스 C 주소들)이 주어졌을 때, 4그룹을 모두 묶을 수 있는 Supernetting 주소는 (X.Y.32.0, 4)가 된다.

→ 32.0은 00100000.00000000, 33.0은 00100001.00000000, 34.0은 00100010.00000000, 35.0은 00100011.00000000이다.이 때 클래스 C에 대한 Network Prefix는 24 비트인데 4개의 그룹을 묶어야 하므로 위의 예제와 마찬가지로 2 비트가 감소되어 그루핑 된다. 즉 22 비트에 대해서 Masking을 하면, 00100000.00000000이 되어 32.0이 최종 Supernetting 결과가 된다.

다음 예시도 위와 똑같은 방식으로 이뤄지는 것을 볼 수 있다.

RFC4291 (IPv6 주소에 대한 표준 규약)을 따른다. IPv4 주소와는 Incomptiable 한 형식이므로 서로에 대한 Translator가 있어야 IPv4 주소와 통신이 가능하다. 이렇게 Translator를 두는 방식은 굉장한 불편함이 따르기 때문에 해결 방법을 위해 IPv4 주소에 대해서 IPv6 주소를 겹치는 오버레이 방식을 통해서 해결하는 방법이 선호된다.

IPv6 주소는 아래와 같은 통신 형태에 따라 여러 주소를 가질 수 있다.

하나의 Interface를 나타내기 위한 Identifier

Unicast와 크게 다를 것이 없이 Unicast 특성을 가진다. 다만 대표 전화와 같이 한 Interface에서만 수신할 수 있으면 된다.) 여러 Interface들에 대한 대표 Identifier

Anycast와 같이 여러 Interface들에게 전송되었을 때 받을 수 있는 Idenfier이다. Anycast는 여러 Interface들에게 전송했을 때 하나의 Interface만 받을 수 있으면 되었다면, Multicast는 Identifier를 가진 모든 Interface가 Packet을 받게 된다.

Mutlicast는 그닥 좋은 통신은 아니다. Multicast를 받기 위해 그룹에 소속된 Node들이 쓸데없는 일을 하게될 수도 있다. 그럼에도 Broadcast보다는 낫다.

IPv6 의 Unicast 주소에는 Link에서 Interface를 확인할 수 있는 Interface Identifier가 사용된다고 했었다. 이 때 Interface Identifier는 64 비트의 길이이며, Modified EUI-64 Format을 따른다.

IPv6 주소에 IID (Interface Identifier)가 사용되기 위해선, Subnet Prefix 범위 내에서 Unique 해야한다. (IID의 Unique함은 IPv6 주소의 Unique와 독립적이다.)

IPv6 주소의 형태는 아래 그림과 같다. 만일 Global Unicast Address로써 IPv6 주소를 나타내면, IID는 64 비트로 고정이고 $n + m$ 역시 64 비트가 된다.

IID는 Modified EUI-64 Format을 따른다고 했었는데, 이에 대해서 알아보자. EUI라는 말은 Extended Unique Identifier의 약어이다.

Modified EUI-64 Format에서의 EUI는 IPv6 주소에서 사용되는 IID에 대해서 64 비트의 길이의 Unique함을 보장해준다. IPv4 주소와 달리 IPv6 주소에서의 주요한 장점이 바로 EUI에 있다. 바로 IPv4 주소 체계에서 IPv4 주소 할당을 위한 수동 설정 및 DHCP의 필요성을 없애주기 때문이다.

IPv6 주소 체계에서는 DHCP 없이도 주소를 알 수 있다는 소리인데, 그럼 IPv6 주소는 어떻게 생성되는걸까? Node 자체가 MAC 주소를 이용하여 IPv6 주소를 생성하여 할당하게 된다.

EUI-64 Format을 지키기 위해선 어떤 형식을 만족해야 하는지 조금 더 자세히 알아보자. 모든 기기들은 같은 네트워크 위에선 같은 Mapping 기법을 사용해야하는데, 대체적으로 Data Link Layer에서의 보편적인 방법은 IEEE 802 MAC 주소를 사용한다. 이 때 Data Link Layer에서 사용하는 MAC 주소는 48 비트의 길이이고 EUI-64는 이 MAC 주소를 이용하여 64 비트를 이룬다고 했는데, 부족한 16 비트는 어떻게 메꾸어 IPv6 주소를 만들어 낼까?

Data Link Layer의 48 비트 길이의 주소는 24 비트 씩 쪼개서 Upper 24 비트, Lower 24 비트로 볼 수 있다. Upper 24 비트는 OUI (Organizationally Unique Identifier)를 의미하고 Lower 24 비트는 기기의 Identifier를 의미한다. EUI-64 Format은 MAC 주소의 Upper와 Lower 사이에 모두 1로 채워진 16 비트를 삽입하여 64 비트를 형성한다.

EUI-48 → EUI-64 → Modified EUI-64 를 만드는 과정을 그림으로 살펴보자.

이 때, IPv6 주소는 EUI-64 Format을 사용하긴 하나, Modfied EUI-64 Format을 이용함을 유의하자!

MAC 주소의 형태는 아래 그림과 같다.

이 때 16진수로 표현된 각 값들이 실제로 통신에서 전송될 때는 뒤집혀서 전달된다.

이런 과정이 일어나는 것은 아래 그림과 같이 각 Octet별 표현이 있을 때, 각 Octet의 LSB부터 (끝에서부터) 전송이 되기 때문이다.

IPv6 주소의 Speical Address는 IPv4 주소와 크게 다를 것은 없다.

0:0:0:0:0:0:0:0 혹은 :: 주소는 IPv6 주소의 부재를 의미한다. IPv4 주소의 0.0.0.0과 동일한 표현이다. Unique한 주소를 받기 위해 전달하는 Packet의 Source의 임시 주소로 이용된다.

IPv4 주소의 127.0.0.1과 동일한 표현이다. IPv6 주소에서는 0:0:0:0:0:0:0:1 혹은 :: 1로 표현한다. Loopback 주소를 향한 Packet은 절대로 IPv6 Router로 Forward 되지 않는다. (다음 Link로도 나가지 않는 것도 당연하다.)

IPv6 주소를 이용하는 컴퓨터인데 IPv4 주소에 연결된 경우에 사용한다.

IPv4 주소를 이용하는 컴퓨터인데 IPv6 주소를 할당하는 경우에 사용한다.

아래 그림과 같은 상황일 때, 주소를 다음과 같이 Mapping 한다. 80 비트는 0으로 채우고, 16 비트는 1로 채운 뒤 (만일 이 부분의 16 비트가 0으로 채워져 있다면 이는 IPv4-Mapped IPv6 Address가 아닌 IPv4-Compatiable IPv6 Address이다.), 32 비트 길이의 IPv4를 씌운다.

IPv6 Unicast 주소의 범위는 크게 3가지로 나뉜다.

Link-Local Addresses라고 부른다. 하나의 Link 범위 내에 속한 모든 Host들에 대한 Identifier를 의미한다.(Link-Local Scope에 해당하는 주소는 Link-Local Addresses와 Site-Local Addresses가 있는데 후자는 Deprecated 되었다.)

Unique-Lcoal Addresses라고 부른다. 특별히 관리되는 범위 혹은 별도의 Link 내에 속한 모든 Host들에 대한 Identifier를 의미한다.

Global Unicast Addresses라고 부른다. 모든 인터넷 상에서 기기가 도달할 수 있는 Identifier를 의미한다.

해당 Unicast 주소는 IPv4의 주소와 일맥상통하다. Globally Routable하고, Reachable하다. 다만 수평적이면서도 계층적인 IPv4 주소 환경의 인터넷과 조금은 다른 점이 있다면, IPv6 주소 환경의 인터넷은 설계부터 효율적이고 계층적인 주소와 Routing을 목적으로 되어 있다는 것이다.

Global한 Scope를 두어 통신하려는 Unicast 주소는 최상위 3개의 비트가 001로 되어 있다.

그림에서 알 수 있듯이 Global Unicast Address는 3가지 영역으로 나뉘어져있다. 첫 3개의 비트는 001로 고정되어 있고, 그 외에 Global Routing Prefix (Site Prefix), Subnet ID, Interface ID로 나뉘어져 있다.

여기서 Global Routing Prefix는 Leaf Site로 기관에 등록된다. 이는 Provider Prefix로써 등록된다. 이렇게 등록된 Prefix는 추가 16 비트를 Subnet ID로 이용이 가능하다. 따라서 기관은 최대 $65535$개의 Subnet을 생성할 수 있다. Host 부분은 Node의 Interface Identifier로써 기록된다. 이에 대한 예는 아래 그림과 같다.

주로 Link 상의 이웃 사이에 사용되거나, NDP (Neighbor Discovery Processes)에서 사용된다.

이 주소는 다른 Unicast 주소가 존재하지 않아도 Default Gateway로부터 컴퓨터 부팅 시 자동으로 설정된다. 이 때 Link-Local Address의 Prefix는 FE80::/10이다. (이어지는 나머지 54 비트는 0으로 채워지기 때문에 FE80::/64로 보기도 한다.)

Site-Local Address는 IPv4 주소에서의 Private 주소와 동일하다.

(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 내의 주소들과 동일하다.)

Site-Local Address의 범위는 해당 Site에만 해당한다. Site-Local Address는 다른 Site에서는 접근이 불가능하다. 따라서 반대로도 Router는 Site-Local Traffic을 Site 밖으로 Forward 해서도 안 된다.

Site-Local Address의 Prefix는 FEC0::/10이다. (Link-Local Address와 달리 자동으로 설정되지는 않지만, Link-Local Address와 마찬가지로 나머지 54 비트는 0으로 채워지므로 FEC0::/64로 보기도 한다.)

Anycast는 서로 다른 Node의 Interface에 동일한 Anycast 주소가 할당되어 있는 경우에 이용할 수 있다.

Anycast로 전달된 Packet들은 서로 다른 Node에서 Anycast 주소가 접근 가능한 Interface에 전달된다. 이 때, Packet은 Routing Protocol에 따라 가장 가까운 것으로 결정된 Node의 Interface로 가게 된다. (동일한 Anycast 주소를 Node들이 갖고 있다고 해도 아무데로나 가는 것이 아니다.)

위처럼 Routing Protocol이 어디로 향해가는지 본 것처럼, Anycast를 사용하는 주된 목적은 Traffic에 대한 Load Balancing이다. (Packet을 처리할 수 있는 Node가 여럿인 경우, 가장 가까운 Node로 감으로써 Traffic이 몰리는 것을 어느 정도 방지할 수 있다.) 실제 구글의 Cloud Service로 이용하는 Load Balancer도 Anycast 방식으로 처리한다.

이외에도 위 그림처럼 DNS Server 역시 Anycast를 통해 득을 볼 수 있다. DNS Server가 Anycast를 이용하게 된 배경을 조금 살펴보면 DNS Server에 대한 공격과 많은 연관이 있다. 2002년 10월 Root DNS DDoS Attack이 있었고 이로 인해 전 세계에 있는 13개의 Root DNS 중 8개가 죽어버리는 사건이 있었고, 2003년 1월에는 Worm DDos Attack으로 5개의 Root DNS가 죽었었다. 이 때문에 많은 사용자들이 DNS Server를 이용하지 못하는 일이 있었다. 따라서 DNS Server를 이용할 때, Anycast 방식을 이용하게 하여 만일 한 쪽 지역에 있는 DNS Server가 죽더라도 다른 지역의 DNS Server를 이용할 수 있도록 만들어서 이런 현상에 대처할 수 있게끔 만들었다. 이에 대한 유명한 예로는 구글의 Public DNS 8.8.8.8에 있다. 구글의 DNS는 전 세계에 굉장히 광범위하게 흩어져 있다. 만일 내가 구글의 Public DNS를 이용하면, 내 지역에서 가장 최적의 Routing Path에 있는 지역의 DNS 서비스를 이용하게 된다. (보통 이런 서비스가 제공되는 곳의 지역은 구글 서비스를 위한 최적인 지역에 둔다. 아시아의 경우 대만과 홍콩에 위치해있다.)

또한 IPv6 주소의 Anycast는 Network Redundancy의 목적을 갖고 있기도 하다. (설계는 했지만 쓰는 사람은 잘 없다.)

만일 A Server와 B Server의 Anycast 주소가 동일하고 A Server와 통신이 없었고 B Server와 통신을 하고 있었다고 한다면, Client Anycast를 시도할 때 별도의 설정 없이 자동으로 B Server로 통신을 보내게 된다.

마지막으로 Subnet-Router Anycast Address를 알아보자. Subnet-Router Anycast Address는 사전에 정의된 주소이다. (Anycast에서의 Subnet Prefix는 특정 Link에 대해서 작용하는 Identifier이다.) 이 때, Subnet-Router Anycast Address는 어떤 Node가 여러 Router들 중 하나와 통신을 해야하는 경우 이용된다. (즉, Anycast인데 특정 Subnet에 대한 Anycast라고 보면 된다.) Subnet-Router Anycast Address가 생성되면, 아래 그림과 같이 Subnet Prefix의 비트가 적절한 값으로 정해지며 나머지 비트는 0으로 할당된 상태로 이용된다.

이런 Subnet-Router Anycast Address에 대해서 정리해보면 다음과 같다.

이상 Anycast에 대한 설명들이고, 마지막으로 주의할 점은 Anycast 주소는 IPv6 Packet의 Source 주소로 사용되어서는 안 된다!

IPv6 주소에서는 더 이상의 Broadcast는 존재하지 않는다. 오로지 Multicast로만 불특정 다수에게 Packet을 보낼 수 있다. (IPv6 주소에서는 Unicast, Anycast, Multicast만이 존재한다.) IPv6 주소를 사용하는 모든 Node에서는 Multicast를 지원해야 한다. Multicast가 존재하지 않으면 IPv6에서는 사용하고자 하는 대부분의 서비스가 작동하지 않는다. (IPv4 주소가 공표되었을 때는 Multicast에 대한 표준이 존재하지 않았었기 때문에, ARP 혹은 DHCP와 같은 Protocol은 Broadcast에 의존했었다.) 단순히 생각해서 Broadcast보다 Multicast가 더 좋기 때문에 Broadcast는 사용하지 않게 되었다. LAN의 크기가 커지고 Switch가 존재하기 때문에 현대의 Broadcast는 문제거리이다.

그렇다면 Mutlicast 주소 형태는 어떤 식일까? Multicast를 이용할 때 IPv6 주소의 첫 Octet의 모든 비트들은 1로 채워진다. 이는 곧 첫 Octet이 FF로 시작함을 의미한다. (비트 Masking에서도 쉽게 Mutlicast임을 확인할 수 있다.)

위 그림에서 알 수 있듯, flgs와 scop에 대한 항목이 있는데 이를 통해서 특정 범위와 주소에 대한 타입을 구분지을 수 있다. 나머지 112 비트들은 Multicast에 대한 그룹 ID를 표현하는데 사용된다.

IPv6 주소에서 Flag는 다음과 같다.

T는 Transient Flag, P는 Prefix Flag, R은 Rendezvous Point Address Flag를 의미한다.

T 값이 0이면 IANA (Internet Assigned Numbers Authority의 약어로 IPv4, IPv6 등의 할당에 관여하는 기관이다.) 에 의해 할당된 Permanent Assigned Multicast Address이고, T 값이 1이면 Non-Permanent Assigned Multicast Address이다.

Prefix Flag는 RFC3306에 의해 제시된 Flag으로써, Unicast 주소의 Prefix에 기반한 Multicast 주소인지에 대한 Flag이다.

R Flag는 Rendezvous Point Address를 내장하고 있는 여부에 따라 설정되는 Flag이다.

IPv6 주소에서 Scope는 다음과 같다.

Solicited-Node Multicast Address는 IPv4 주소에서는 필요하지 않았지만, IPv6 주소에서는 필요한 주소이다. 이 주소는 DAD (Duplicate Address Detection)을 확인한 후에 할당을 받을 수 있다. DAD는 NDP (Neighbor Discovery Protocol)의 일부로써, DAD를 사용하면 현재 Node에서 Stateless Auto Configuration을 통해 사용하려고 하는 IPv6 주소에 대해서 Local-Link에서 이미 IPv6 주소가 사용 중인지 확인을 할 수 있다. Solicited-Node Multicast Address는 다른 Node에서 이미 구성된 Unicast 주소 혹은 Anycast 주소를 검색하여 Local-Link에서 사용 중인 주소를 확인하는데 사용된다.

Solicited-Node Multicast Address의 Prefix는 FF02::1:FF00:0000/104로써 Link-Local의 Multicast 주소의 Prefix를 사용하는 것을 볼 수 있다. 주어진 104 비트를 Prefix로 사용하기 때문에 남은 24 비트 값은 Unicast 주소 혹은 Anycast 주소의 끝 24 비트를 복사해와서 Solicited-Node Multicast Address로 이용한다. 변환 과정은 아래 그림과 같다.

예를 들어서 Unicast 주소가 FE80::2AA:FF:FE28:9C5A라고 한다면, Solicited-Node Multicast Address는 FF02::1:FF28:9C5A가 된다.

그렇다면 이런 Solicited-Node Multicast Address는 왜 필요한 것일까? 현재 내 IPv6 주소를 다른 곳에서 이용하고 있는지 DAD를 통한 확인을 위해 Destination 주소로 이용하는 것을 예측할 수 있는데, 예상한대로 Solicited-Node Mutlicast Address는 IPv4 주소에서 ARP의 대체로 이용하기 위해 존재한다. IPv6 주소에서는 ARP가 존재하지 않기 때문에 사용되며, 이는 현재의 Node 혹은 Router에게 인접한 Node 혹은 Router의 Data Link Layer 주소를 확인하기 위해 사용된다. IPv4 주소에서의 ARP와 마찬가지로, IPv6 Packet을 Data Link Layer의 Frame으로 전달을 하기 위해선 인접한 Node의 Data Link Layer의 주소가 필요하다.

IPv4 주소의 경우 네트워크 어댑터에 붙은 하나의 Host는 하나의 IPv4 주소를 가졌었지만, IPv6 주소의 경우 하나의 Interface에만 여러 IPv6 주소를 가질 수 있다.

즉, IPv6 주소를 이용하는 Host들 및 Router들은 IPv4 주소와 달리 Packet을 받을 수 있는 주소가 적어도 2개 이상이 존재한다. 이를 Logically Multihomed라고 한다. (Local-Link Traffic을 받을 수 있는 Link-Local Address, Site-Local Address 혹은 Global Address와 같이 Routable한 주소) 또한 각 Host들 및 Router들은 이렇게 2개의 주소로 Packet을 받을 수 있을 뿐 아니라 Multicast Address에 대해서도 Traffic을 받을 수 있도록 Listen 하고 있다.

IPv4 주소 체계는 크게 2가지, Public IP 주소와 Private IP 주소로 나누어져있다.

그렇다면 IP 주소를 Public과 Private로 나눈 이유는 무엇일까?

가장 큰 이유는 바로 할당 가능한 IPv4주소의 고갈이다. IPv4 주소 체계에서 이론상으로 약 43억 개의 단말을 식별할 수 있다. 하지만 점점 인터넷 사용자도 늘어나고 통신이 가능한 기계들이 점점 생겨나면서 43억 개의 주소가 부족한 시대가 왔다. 그래서 Public IP 주소와 Private IP 주소로 나누어 IP 주소를 절약하는 시스템을 만들었다.

인터넷 사용자의 Local 네트워크를 식별하기 위해 ISP(인터넷 서비스 공급자)가 제공하는 IP 주소이다. Public IP 주소는 외부에 공개되어 있는 IP 주소이다.

일반 가정이나 회사 내 등에 할당된 네트워크의 IP 주소이며, Local IP, 가상 IP라고도 한다. IPv4 주소 부족으로 인해 Subnetting되었기 때문에 Router에 의해 Local 네트워크상의 PC 나 장치에 할당된다.

Private IP 주소 대역은 아래와 같다.

간단한 예제로 알아보자.

이렇게 Private, Public IP 주소를 활용해서 네트워크를 구성하였을 경우, Public IP 주소를 가지고 있으면 어디서든 나의 주소로 찾아올 수 있지만 Private IP 주소는 해당 IP 주소가 포함된 사설망 내에서만 찾을 수 있다.(외부 네트워크에서는 찾을 수 없다.)

여기서 중요한 것이 사설망 역시 Public IP 주소를 가진 Host와 통신할 수 있어야 한다. 사설망의 IP 주소를 가진 Host도 외부 네트워크에 접근할 수 있어야 인터넷의 의미가 있다. 따라서 Public IP 주소와 Private IP 주소 간 Host와 통신할 수 있도록 만든게 바로 NAT이다.

NAT는 주로 Private IP 주소를 사용하는 네트워크 망에서 Public IP 주소를 사용하는 네트워크 망으로의 통신을 위해 네트워크 주소를 변환하는 것이다. 즉, 사설망에서는 Private IP 주소를 이용해서 통신을 하고, 외부 네트워크와 통신할 때에는 NAT를 거쳐서 Public IP 주소로 자동 변환된다.

Public IP 주소와 Private IP 주소를 1 : 1 로 Mapping하여 변환한다.

가장 쉬운 변환 방식이지만 이렇게 구성할 경우 Public IP 주소와 Private IP 주소의 개수가 같아야 하기 때문에 Public IP 주소를 효율적으로 쓰고자 하는 목적에 맞지 않는다.

일반적으로 사설망의 역할이 많아서 Port Forwarding 작업이 많이 필요한 경우, 아예 해당 사설망의 IP 주소를 Public IP 주소로 Mapping하는 방식으로 사용한다.

Public IP 주소와 Private IP 주소를 N : N 으로 Mapping하여 변환한다.

현재 사용중이지 않은 Public IP 주소에 Private IP 주소를 동적으로 Mapping한다.

보통 Public IP 주소가 Private IP 주소보다 적을 경우에 사용된다.

Public IP 주소와 Private IP 주소를 1 : N 으로 맵핑하여 변환한다. 사설망 내 각 Host마다 Port를 지정해주어, Private IP + Port를 하나의 Public IP + Port로 Mapping한다.

사설망 (개인 PC)에서 외부 네트워크로 통신을 시도하면 해당 Packet은 항상 공유기(Gateway 등)을 거치게 되어있다.

이러한 통신 과정은 아래와 같이 크게 4가지 단계로 진행된다.

아래는 이 과정을 그림으로 그려본 것이다. 여기서 Source IP 주소는 Packet을 보내는 주소, Destination IP 주소는 Packet이 도착하는 주소이다.

위 그림의 1번 과정에서 Packet을 발송하면 보내는 사람의 IP 주소는 PC의 사설망 주소인 192.168.0.2로 채워져 있고 받는 사람의 IP 주소는 Destination IP 주소인 2.2.2.2로 채워져 있다. Packet이 2번 과정을 거쳐 Server로 전달 될 때 아무 변환없이 그대로 넘어간다면, Server가 받은 수신자의 주소는 192.168.0.2로 채워져있다. 하지만 이 주소는 Private IP 주소이기 때문에 Server 입장에서는 전 세계의 수 많은 사설망 중에 어디로 보내야 할지 알수가 없다. 이렇게 외부에서 Private IP 주소만으로 사설망에 접근할 수 없다는 것이 NAT의 장점이다.

그래서 Gateway는 Packet을 받으면 보내는 IP 주소를 자신의 Public IP 주소로 임의 수정을 거친 뒤 Destination로 발송한다. 2번 과정을 보면 Source IP 주소가 Private IP 주소에서 Gateway의 Public IP 주소로 변경된 후 전송되는 것을 알 수 있다. 이제 Server는 통신을 완료하기 위해 Packet을 Gateway로 보내게 된다. 이때 Destination의 Server가 Packet을 받을 때의 Source IP 주소가 된다.

그런데 Server가 받은 주소는 Gateway의 Public IP 주소인 1.1.1.1 밖에 없어서 Gateway에 도착한 Packet이 이후 어디로 가야하는지 Destination를 잃어버리게 된다. 그렇다면 4번 과정은 어떻게 진행이 되는 것일까?

그래서 Gateway는 발신자의 IP 주소를 수정할 때, 내부에 있는 NAT Table에 이 정보들을 기록해 둔다. 발신자의 Private IP 주소, Destination IP 주소 등을 기록해둔 후 응답 Packet이 돌아오면 그 값에 맞는 사설망으로 Packet을 전송한다.

하지만 NAT 통신방식은 큰 단점이 있다. 한 사설망 내의 여러 기기가 동시에 같은 외부 네트워크로 연결 요청을 한다면 응답 Packet을 받았을 때 중복되는 값들이 많아서 Packet이 길을 잃어버리게 된다. 따라서 이 문제를 해결하기위해 NAPT를 만들었다.

위에서의 경우처럼 같은 사설망 내의 여러 기기가 하나의 Server에 연결 요청을 한다면 Server에서 다시 보내온 응답 Packet이 Destination를 잃을 수 있다. 왜냐하면 NAT Table내에 있는 Source IP 주소, Destination IP 주소의 정보가 같기 때문에 응답 받은 Packet이 어떤 Private IP 주소로 돌아가야 하는지 판단하지 못한다.

그래서 NAT의 방식에 Port까지 변해서 Packet을 전송한다. 이렇게 하면 Gateway는 발신자의 Port만 보고 구별할 수 있게 된다. NAPT를 사용하면 하나의 외부 주소당 65535개의 동시 Session을 유지할 수 있다.

현재 우리가 사용하는 네트워크처럼 Packet Switch가 가능한 컴퓨터 간의 네트워크 통신이 가능하도록 Internet Protocol이 설계되었다. Internet Protocol은 Source로부터 Destination까지 Datagram이라고 하는 데이터 블록들을 전송할 수 있게 해주게 해준다. (여기서 말하는 Source와 Destination은 특정 길이의 IP 주소로 명시된 Host를 의미한다.) 이 때 IP는 Network Layer에서 최소한의 기능만 수행하며, Small Packet만 지원하는 네트워크에서도 통신이 가능하도록 긴 Datagram에 대해서 Fragment 및 Reassemble를 지원한다.

IP는 기본적으로 2가지 Function을 실행한다. 하나는 Addressing이고, 나머지 하나는 Fragmentation이다.

Internet Module들은 IP Header에 명시되어 있는 주소를 이용하여 Destination으로 Datagram을 전송하는데, 이 때 Destination으로 데이터를 보내기 위해 경로를 찾는 것을 Routing이라고 한다.

또한 Internet Module들은 IP Header에 있는 몇 필드들을 이용하여 Datagram에 대한 Fragment와 Reassemble을 수행하게 된다.

이 때 중요한 것이 IP는 서로 다른 Datagram에 대해서 관련성이 없는 각각 독립적인 개체로 인식한다는 것이다. 이 말은 전송하는 Datagram을 메모리에 쓰지 않겠다라는 말로 State를 두지 않은 채로 기억하지 않겠다와 동일한 의미이며, Network Layer에서 최소한의 기능만을 수행하겠다는 의미이다. 이런 State에 대한 정보는 End-to-End 및 Fate Sharing에 따라 End 단말에만 두고, 외의 단말에서는 Datagram에 대해서 별도의 저장을 하지 않고 빠르게만 처리한다는 것으로 보면 된다. (실제로 End외의 단말에서는 통계에 대한 정보 정도는 저장을 한다.)

위와 같은 2개의 Function을 수행하는데 있어서 IP는 아래의 4가지의 핵심 메커니즘을 사용한다.

(위의 4가지보다는 IP는 Addressing과 Fragmentation이라는 Function을 수행한다는 것을 명심하자.)

IPv4 주소 체계에서 Datagram은 다음과 같은 구조이다.

Datagram 내의 Header의 구조가 가장 중요한데 그 구조는 아래와 같다.

Node에 대한 구별의 3요소는 Names, Addresss, Routes이다.

Name은 우리가 찾고자 하는 식별 대상이고, Address는 식별 대상의 위치를 말하며, Route는 어떻게 그 위치까지 도달할 수 있는지 이다.

IP는 3가지를 다 만족할 수 있도록 Addressing을 수행해준다.

Fragmentation은 Datagram에 대해서 Datagram이 생성된 곳에서 허용한 Packet 크기보다 Datagram이 향해 가는 Destination에서 허용한 Packet의 크기가 더 작은 경우 수행하게 된다. Fragmentation은 필수 사항은 아닐 수 있기 때문에, Fragmentation을 수행하지 말라고 Packet에 명시할 수 있다.

Fragmentation의 단위는 MTU라고 볼 수 있다. MTU란 Maximum Transmit Unit의 약어로, 네트워크 Interface에서 분할을 하지 않아도 되는 Datagram의 최대 크기를 의미한다. (아래 그림을 참고)

만일 Datagram을 Data Link Layer로 넘기는 과정에서 Frame화를 해야할 때, MTU 단위로 끊어서 Frame화를 진행한다. (아래 그림 참고)

IPv4 Header Format에서 밝힌 것처럼 Header에는 Fragmentation에 대한 정보가 담겨있다. Identification, Flag, Fragmentation Offset 필드들이 이에 해당한다.

Identification은 서로 다른 Datagram이 섞이지 않도록 송신 측에서 작성하여 정체성을 보장해준다. 이를 통해 수신 측에서는 Datagram이 섞이지 않도록 편하게 Assembling이 가능하다.

Flag의 경우 3 비트를 이용하는데, 첫 번째 비트는 활용하지 않으며, 두 번째 비트는 Do Not Fragment로 Fragmentation을 수행하지 않을 때 1로 표기한다. 마지막 비트는 More 비트로 후에 추가적으로 받아야하는 Fragment가 있다면 1로 표기 되고, 자신을 마지막으로 더 받을 Fragment가 없다면 0으로 표기한다.

Fragmentation Offset은 현재 Fragment가 Datagram의 어느 부분에 속하는지를 의미한다. Fragmentation Offset과 Total Length를 통해서 원래의 Datagram에서 어느 부분에 속하는지 확인할 수 있게 된다. 이 때 Datagram의 크기는 Header를 포함하여 $2^{16}$ 바이트로 $65535$ 바이트만큼 가질 수 있다고 했었는데 이는 곧 $2^{16} * 2^3$ 비트를 표현할 수 있어야 한다는 것이다. Fragmentation Offset은 13 비트만 주어져 있기 때문에 $2^{13}$ 비트만큼을 표현할 수 있기 때문에 저 많은 크기를 표현할 수 없는 상태인 것을 알 수 있다. 기본적으로 Fragmentation Offset은 바이트 단위의 표현을 하기 때문에 $2^{16} * 2^3$에서의 $2^3$ 부분은 해결할 수 있다. 이제 남은 것은 13 비트를 통해서 $2^{16}$을 어떻게 표현할 것이냐인데, Fragmentation Offset은 기본적으로 8개의 Octet을 하나의 단위로 본다. 따라서 $2^{16}$을 $2^{13}$까지 줄일 수 있고, 이는 13 비트로 표현이 가능하게 된다. 이해하면 간단하지만, 조금은 받아들이기 어려울 수 있기 때문에 아래 예시를 살펴보자.

좌측과 같이 총 4000 바이트 길이의 Datagram이 있다고 해보자. 이 때 Total Length는 Datagram 크기 4000에 Header 크기 20을 더해 4020으로 기록된다. 현재는 Fragmentation이 되지 않았기 때문에 Flag 필드의 More 비트는 0이고, Fragmentation Offset 도 000인것을 확인할 수 있다. 여기서 MTU가 1400 바이트라고 하여 원본 Datagram 4000 바이트가 각각 1400, 1400, 1200으로 쪼개졌다고 가정해보자.

첫 번째 Fragment의 Total Length는 1400 바이트 + Header 크기 20 바이트로 1420이되고, 뒤에 아직 2개의 Fragment가 남았기 때문에 Flag 필드의 More 비트가 1이 된다. 또한 첫 Fragment이므로 Fragmentation Offset도 0인 것을 확인할 수 있다.

두 번째 Fragment의 경우 첫 번째 Fragment처럼 Flag의 More 비트가 1, Total Length가 1420인 것을 알 수 있다. 이 때 Fragmentation Offset은 크기 바이트에 대해서 8개의 Octet으로 표현한다고 했기 때문에 첫 번째 Fragment의 크기 1400 바이트에 8 바이트 단위로 표현한다고 했으므로 8로 나누어 175로 표기하게 된다.

세 번째 Fragment의 경우 크기가 1200 바이트므로 Header 크기를 더하여 Total Length는 1220이 되고, 마지막 Fragment이므로 Flag의 More 비트가 0인 것을 확인할 수 있다. Fragmentation Offset에 대해서는 두 번째 Fragment의 크기가 1400 바이트였으므로 8로 나누어 (8 바이트 단위로 표현하므로) 나온 175를 두 번째 Fragmentation Offset인 175에 더하여 350이 된다는 것을 알 수 있다.

추가적으로 만일 두 번째 Fragment에 대해서 MTU 800으로 쪼갠다고 가정하여 더 쪼개보자. 2.1 Fragment의 Total Length는 Header 크기를 더하여 820, Flag의 More 비트는 (아직 끝 Fragment가 아니므로) 1이 된다. Fragmentation Offset은 첫 번째 Fragment의 크기가 1400이었으므로 8로 나누어 175인 상태인 것을 볼 수 있다. 2.2 Fragment의 경우 두 번째 Fragment의 크기 1400에서 2.1 Fragment의 크기 800을 뺀 600 바이트이고, Header 크기를 더하여 Total Length는 620이 되는 것을 확인할 수 있다. 세 번째 Fragment가 있기 때문에 Flag의 More 비트도 1인 것을 볼 수 있다. Offset의 경우 2.1 Fragment의 Fragmentation Offsest 175에 2.1 Fragment의 크기 800 바이트를 8로 나눈 100을 더하여 275가 되는 것을 볼 수 있다.

Checksum이라는 것은 TCP/IP 모델에서 사용하는 Error Detection 방법 중에 하나이다. Error에 대해서 찾을 수 있기 때문에 Packet 전송 중에 망가진 데이터에 대해서 Protection이 가능하다.

Checksum은 송신 측에서 계산하여 Packet에 넣게되고, 수신 측에서는 송신 측으로부터 받은 모든 Packet에 대해 Packet에 기입된 Checksum을 이용하여 동일한 계산을 반복한다. 만일 Checksum 확인에서 문제가 없이 다 통과가 된다면 수신 측에서 Packet을 받게된다. 그렇지 않다면 Packet을 받지 않는다.

Header Checksum은 오로지 Header에 대해서만 검증한다. 만일 Header의 특정 필드의 값이 변했을 경우 (대표적으로 TTL과 같은...), Header가 처리되는 각 지점에서 다시 계산되어 검증된다.

각 Header에서 16 비트씩 끊어서 나온 값들을 모두 더하여 (덧셈 시 1의 보수로 더함) 나온 값을 Negate (비트들을 모두 Flip)한 값이 Checksum 필드에 기재된다. 이 때 16 비트씩 끊어서 사용할 때 Checksum의 값도 계산에 기여하게 되는데 초기 Checksum의 값은 0으로 계산된다. 여기서 덧셈 시 1의 보수로 더한다고 한 것은 Carry 발생 시 Carry를 더하는 것을 의미한다. (2의 보수 덧셈 시에는 Carry 발생 시 Carry를 버린다.) 아래 예시를 살펴보자.

위와 같이 계산된 Checksum이 Packet에 담기게 되면 수신 측에서는 모든 Header의 내용들을 송신 측에서 Checksum을 계산했을 때 처럼 16 비트씩 끊어서 모두 더해보게 된다. 이 때 만일 Header에 문제가 없다면, 결과는 FFFF가 나오게 되고 Negate 시에 0000이 결과로 나오게 되어 수신 측에서는 송신으로부터 받은 Packet의 Header에 문제가 없다는 것을 확인할 수 있다. (아래 그림을 참고)

Network Layer에서 통신을 하기 위해선 Host의 소프트웨어에는 IP와 ICMP (RFC792)가 구현되어 있어야 한다.

Host에서 동작하는 IP는 위에서 언급했던 것처럼 2가지 기능을 수행하는데, 첫 째로는 Datagram이 보내질 수 있도록 Next Hop할 Gateway 혹은 Host를 찾을 수 있는 Addressing, 둘 째로는 Datagram에 대한 Fragmentation 및 Reassembling이다.

ICMP는 Network Layer가 정상 동작이 가능한지 진단하는 기능에 대해서 수행하게 된다. 위의 카테고리들에서 언급했던 내용들이지만 요약하여 정리해보자.

RFC1122에는 위 내용 외에도 IP 통신을 위해 Routing Outbound Datagrams (Route Cache 필요성, Default Gateway들이 명시된 리스트 필요성), Forwarding Outbound Datagrams (Local / Remote Decision에 대한 Rule의 필요성, Gateway Selection에 대한 Rule의 필요성), Dead Gateway Detection, New Gateway Selection, Host Initialization, ARP Cache Validation, ARP Packet Queue 등이 만족되어야 한다.