IP 주소
IP 주소는 32비트로 구성되는 주소이다. IP 주소를 통해 호스트나 라우터 인터페이스를 구분할 수 있다.
그럼 인터페이스란 뭘까...
인터페이스는 호스트와 라우터 사이의 연결이나 physical link를 말한다.
라우터는 보통 여러 개의 인터페이스를 가지고 있는 반면, 호스트는 보통 1개 또는 2개의 인터페이스만 가지고 있다.
즉, IP 주소는 인터페이스와 연관되어 있다.
예를 들어 233.1.1.1이라는 IP 주소가 있다면 32비트 형식으로는
11011111 00000001 00000001 00000001 라고 표현될 것이다.
여러 개의 호스트들의 인터페이스들과 하나의 라우터 인터페이스로 연결된 네트워크를 subnet을 구성한다고 한다.
IP 주소는 high order bits 부분과 low order bits 부분으로 나눌 수 있다.
여기서 high order bits 부분은 subnet part가 되고, low order bits는 host part가 된다.
그래서 장치들의 인터페이스 IP 주소의 subnet 부분이 같다면 그 장치들은 같은 subnet에 있는 것이다.
같은 subnet 안에 있는 장치들은 라우터 연결없이 네트워크에 서로 연결될 수 있다.
이 네트워크는 Ethernet LAN으로 상호 연결되고, 인터페이스는 Ethernet switch 또는 wifi 등으로 상호연결된다.
IP 주소 체계는 233.1.1.1/24라는 주소를 할당하는데 여기서 /24는 subnet mask이다. 이것의 의미는 상위 24비트가 subnet part라는 것이다. 상위 24비트이니까 [233.1.1]까지가 subnet part, [.1]는 host part가 되시겠다.
여기 그림에서 보면 하늘색 부분이 subnet이고, 같은 서브넷끼리는 subnet part(상위 24비트) 부분이 모두 같은 것을 확인할 수 있다.
이 원칙대로라면 다른 subnet은 서로다른 subnet 주소를 가져야 한다. 하지만 현실에서는 서로 같은 주소를 가지는 subnet이 존재한다. 왜 그럴까?
그 이유를 알기 위해서는 CIDR에 대해 알아야 한다.
CIDR(Classless Interdomain Routing)
subnet 주소체계 방식이다.
IP 주소는 2부분으로 나누고, 다시 십진수 형태의 a.b.c.d/x를 가진다.
x는 주소의 subnet part의 비트 수를 의미한다. 이것을 prefix 또는 네트워크 프리픽스라고 한다.
예를 들어 200.22.13.0/21이라는 IP 주소가 있을 때 이것의 subnet part는 21비트 이니까 나머지 11비트가 host part인 것이다. 그러면 2^11개의 호스트들을 식별할 수 있다.
아니면 11비트들 중 일부를 다시 기관 내부의 subnet을 위해 사용할 수 있다.
a.b.c.d/24는 기관 내부의 subnet을 나타낼 수 있는 것이다.
기관은 subnet에서 사용할 IP 주소 블록을 얻기 위해, 네트워크 관리자는 할당받은 주소의 큰 블록에서 주소를 제공하는 ISP와 접촉해야 한다.
만약 ISP가 200.23.16.0/20 주소 블록을 할당받았다면 ISP는 이 주소 블록을 8개의 블록으로 나눈다.
ISP 블록: 11001000 00010111 00010000 00000000
0: 11001000 00010111 00010010 00000000
1: 11001000 00010111 00010100 00000000
...
7: 11001000 00010111 00011110 00000000
이렇게 8개의 subnet을 지원할 수 있을 것이다.
ISP와 다른 조직에 주소 블록을 할당하는 최상위 국제기관인 비영리단체인 ICANN은 IP 주소 할당과 DNS 루트 서버를 관리한다. 도메인 이름을 할당하고, 도메인 이름 분쟁을 해결한다.
이렇게 기관이 ISP로 부터 주소를 받아온 뒤, 개별 IP 주소를 기관 내부의 호스트와 라우터들에게 할당한다.
호스트에 IP 주소를 할당할 때 DHCP(Dynamic Host Configuration Protocol)을 사용한다.
DHCP(Dynamic Host Configuration Protocol)
이것은 호스트가 네트워크에 접속할 때 마다 네트워크 서버로 부터 IP 주소를 호스트에게 동적으로 할당하기 위해 사용한다.
IP 주소의 사용시간을 재설정 할 수 있고, 주소를 재사용 할 수 있다.
연결 되었을 때만 특정 주소를 hold하고 있는 것이기 때문에, a라는 호스트가 쓰다가 더이상 쓰지 않게 된다면 그 주소를 다시 b라는 호스트에게 할당할 수 있는 것이다.
DHCP는 일종의 클라이언트-서버 프로토콜이라고 볼 수 있다.
특정 subnet에 DHCP 서버가 구현되어 있어서, 그 서브넷에 새로운 클라이언트(호스트)가 들어오면 다음과 같은 과정을 거친다. 이 프로토콜은 빠른 속도로 이루어지기 위해 UDP를 사용한다.
1. DHCP discover:
클라이언트는 패킷(데이터그램)을 어디로 보낼지, 자신의 IP 주소는 무엇인지 알지 못한다. 그렇기 때문에 source를 0.0.0.0으로 설정하고, destination을 255.255.255.255로 설정하여 서브넷에 연결된 모든 노드에게 브로드캐스팅 된다.
2. DHCP officer:
메세지를 받은 DHCP 서버는 임대 IP 주소(yiaddr), 임대 IP 주소 사용기간(lifetime)을 넣어서 255.255.255.255로 패킷을 보낸다. 이 패킷은 다시 서브넷에 연결된 모든 노드에게 브로드캐스팅 된다.
3. DHCP request:
메세지를 받은 클라이언트는 서버에 request 메세지를 보낸다.
4. DHCP ACK:
메세지를 받은 서버는 클라이언트에 ACK 메세지를 보낸다.
NAT(Network address translation)
NAT가 가능한 라우터는 외부세계로 부터 한개의 IP 주소만 가지는 것처럼 보인다.
하지만 실제로 내부에 많은 IP 주소들을 관리하고 있다.
이 그림을 보면 192.168.1/24의 subnet을 가지고 있고, 그 안에 여러개의 호스트들이 존재한다. 하지만 NAT를 통해 라우터 밖의 외부세계에서는 202.45.1.1 이라는 하나의 IP 주소로 인식되는 것이다.
이것이 왜 편리하냐?
먼저 내부적으로 장치들(호스트들)의 IP 주소를 바꾸더라도 외부세계에 이 사실을 알릴 필요가 없다.
그리고 ISP 주소를 바꾸더라도 내부 장치들의 IP 주소에는 영향을 미치지 않는다!
그렇다면 어떻게 NAT가 동작하게 되는 것일까.
NAT 라우터는 NAT 변환 테이블을 사용한다.
NAT 변환 테이블에는 [source IP 주소, port num] 과 [NAT IP 주소, 새로운 port num] 이 쌍을 이루고 있다.
이 그림을 보면 NAT이 어떻게 동작하는지 이해하기 쉬울 것이다.
- subnet의 IP addr이 10.0.0.1인 host가 3345번 포트를 통해 128.119.40.186의 80번 포트로 데이터를 보내려고 한다.
- NAT 라우터는 NAT 변환 테이블을 통해 10.0.0.1이라는 source IP addr을 138.76.29.7이라는 NAT addr로 바꾸고, 5001번 포트를 부여한다. 그리고 목적지로 데이터를 보낸다.
- 목적지에서 데이터를 수신한 뒤 138.76.29.7 이라는 NAT IP addr의 5001번 포트로 답장을 보낸다.
- 138.76.29.7 이라는 NAT IP addr를 가지는 NAT 라우터는 다시 NAT 변환 테이블을 통해 원래 subnet 속 host의 IP addr과 포트 넘버를 찾은 뒤, 해당 호스트에 답장을 전달한다.
NAT가 많이 쓰이고 있음에도, 이것을 반대하는 사람들이 있다.
왜냐하면 포트 넘버가 호스트 주소 지정이 아닌 프로세스 주소 지정에 사용되기 때문이다.
application layer에서 배웠듯이, 서버 프로세스는 잘 알려진 포트번호(ex: 80...)에서 요청이 올 때까지 기다린다.
P2P protocol의 peer가 서버로서의 역할을 하는 경우 클라이언트로 부터 들어오는 연결을 수락해야 한다.
그런데 이 peer가 홈 네트워크에서 실행되는 서버인 경우, 클라이언트는 NAT 뒤에서 보이지 않는 서버(=subnet안에 존재하는 호스트)와 직접 연결해야 하는 상황이 발생하는 것이다.
이러한 문제를 해결하기 위해 NAT traversal이 존재한다.
하지만, 이러한 방법은 NAT 라우터가 network layer 뿐만 아니라 그 위의 layer의 부분(포트 넘버)까지 관여하게 되기에, end to end 규칙에 어긋난다.
IPv4, IPv6
인터넷에 접속하는 subnet과 노드들로 인해 기존에 사용하던 IPv4의 32bit 주소공간이 부족해졌고, 이를 해결하기 위해 개발된 것이 IPv6이다.
IPv6이 IPv4와 다른점은, 헤더 포멧을 간단하게 만들어서, 이것을 읽어들이고, 프로세싱/포워딩 하는 시간을 줄이도록 하였다.
헤더 길이가 전체 40byte로 고정되어 있고, fragmentation이 허용되지 않아서 length에 대한 부분이 존재하지 않는다.
그렇다면 보내려는 datagram의 크기가 link layer로 내보내기에 너무 클 때는 어떻게 할까?
이때는 송신자에게 "Packet Too Big"이라는 ICMP 오류 메시지를 전송한다.
IPv4에서 IPv6를 사용하게 되면, IPv4를 사용하던 기존의 라우터들은 어떻게 되는 것일까.
IPv6의 경우 IPv4를 변환할 수 있지만, IPv4의 경우 IPv6를 변환하는 기능이 없다.
그렇다면, 기존의 라우터들을 모두 교체해야 하는 것일까? 하지만 이렇게 하기에는 시간과 비용이 너무 많이 소요된다.
그래서 tunneling이라는 것을 통해 이러한 문제를 해결한다.
IPv6 라우터 B, E 사이에 IPv4 라우터 C, D 가 존재한다.
그러면 B에서 C로 전달할 때 IPv4 형식 안에 IPv6형식의 데이터그램을 담아서 C에 전달한다.
이를 통해 C에서 D로 데이터그램을 전송할 수 있다.
D에서 E로 데이터그램이 전달된 후에는 IPv4를 IPv6로 변환하고, 그것을 F로 전달한다.
SDN
우리는 앞부분에서 generalized forwarding에 대해 배웠다.
generalized forwarding이란 어떤 input port, output port로 들어왔는지, 데이터그램의 우선순위가 뭔지를 고려하여 forwarding을 하는 것이었다.
SDN이란 소프트웨어 기반 네트워킹으로, 이것을 가능하게 해준다.
'전공 관련 > 컴퓨터 네트워크' 카테고리의 다른 글
| HTTP 그리고 HTTPS (0) | 2023.04.16 |
|---|---|
| Routing Algorithm(라우팅 알고리즘) (0) | 2020.12.08 |
| Network layer(네트워크 계층)과 router(라우터) (0) | 2020.11.30 |
댓글