네트워크 계층의 프로토콜은 IP.
라우터에는 네트워크까지의 계층이 있음.
라우터에서 하는 일 두 가지
1. Forwarding
2. Routing
패킷의 목적지(header에 있음)를 확인 + 목적지로 가기 위해 어떤 경로로 보내야할지를 forwarding table을 보고 전달해줌 => Forwarding
그냥 1:1로 매칭하면 크기가 너무 커지니까, 우체국처럼 주소 범위로 관리(몇 번부터 몇 번까지는 어디로 가라)
가장 길게 매칭되는 쪽으로 보냄 = Longest Prefix Matching
IP의 헤더
Source IP Address: 데이터 출처의 IP Address
Time To Live: 라우터를 거칠 때마다 1씩 감소. 0이 되면 버려짐. -> 존재 이유? 혹시 테이블이 잘못돼서 계속 돌고 있는 패킷을 버리기 위해.
Transport(Upper Layer): TCP로 올릴지 UDP로 올릴지가 적혀있음
MTU(Max Transfer Unit)는 모든 종류의 링크마다 다름. -> MTU를 넘어서서 처리가 안될 경우, 버리기엔 너무 아까우니까 그 자리에서 바로 분리(IP fragmentation)함. 서로 다른 패킷이 되어서 독립적으로 진행되고 마지막에 원래 패킷으로 합쳐짐(IP reassembly).
Identification: 패킷별로 유일한 값(분리된 애들이면 다 같은 id)
flag: fragment됐는지 아닌지(안됐다면 0)
offset 분리됐다면, 원래 패킷에서 어느 위치의 패킷인지.
분리된 패킷을 잃어버린 경우?
reassemble이 안되면 위로 못올리니까 버려지고, 나중에 TCP가 timeout되든지 함
IP
32bit 2진수. 일반적으로 사람이 읽기 편하도록 8자리씩 끊어서 10진수로 표현
라우터
Network Interface 여러 개 두면서 각각 다른 네트워크에 연결되어 있고 각각 다른 IP 주소를 가지는 컴퓨터의 예시
Forwarding Table
destination IP와 nexthop을 맵핑해주는 테이블. 이 테이블의 엔트리들은 라우팅을 하는 과정에서 자연스럽게 채워지게됨.
계층화를 시켜둠. 예를 들어 32bit 중 앞의 24bit는 네트워크 아이디(=prefix, subnet id), 뒤의 8bit는 네트워크 내의 호스트 아이디를 지칭.
-> 같은 네트워크에 속하면 같은 prefix를 가진 IP 주소를 가짐
-> Forwarding Table이 단순해짐. IP 추가할 때도 테이블을 수정할 필요가 없음.
-> 네트워크 별로 가지는 prefix가 달라짐.
서브넷 마스크
ip가 있으면 어디까지가 네트워크 아이디이고 어디까지가 호스트 아이디인지 알기 쉽도록 하기 위해서 비트맵으로 해둔 것
Classless Inter-Domain Routing(CIDR)
이전에 클래스 기반으로 했을 때에는 소수의 집단이 다 사용할 수도 없는 호스트 갯수를 독점하고 클래스 C에 속한 IP는 가질 수 있는 호스트 갯수가 매우 적은 등 문제가 많았음.
그래서 이제는 이런 클래스를 없애고, 유연하게 필요한 길이의 prefix를 사용하는 방식으로 바뀜
Longest Prefix Match Forward
라우터에서 forwarding 테이블과 패킷의 목적지 주소를 매칭하며 가장 길게 매칭되는 쪽으로 보내주는 과정
Subnet
같은 prefix를 가진 디바이스의 집합. 즉 라우터들을 거치지 않고 접근 가능한 host들의 집합.
Network Address Translation
IP 주소 공간 부족 문제를 해결하기 위한 방법. (IPv6로 바꾸는 건 여러 문제점이 있어서 임시로 사용하는 방법)
네트워크 내부에서는 유일한 IP 주소를 사용하되, 이런 패킷이 외부로 나갈 때에는 NAT를 통해 Source IP 주소를 게이트웨이의 IP 주소로 바꿔주고 포트 번호를 바꿔줌.
받을 때에는 이 네트워크로 들어오는 Destination IP는 모두 같으니까 포트번호를 보고 호스트를 찾아감.
=> 문제점
1. Network Layer의 디바이스인 라우터가 header뿐 아니라 data도 알고 있음(포트 번호를 바꿔줘야해서)
2. 원래 포트 번호는 같은 호스트 내부에서 프로세스를 찾을 때 쓰는건데 이미 호스트 찾을 때 써버림. -> NAT 내부의 네트워크에서는 서버 호스팅을 할 수 없음.
=> IPv6(address space가 128bit)로 바꾸든 다른 방법을 찾든해야함
=> 근데 IPv6도 디자인된지 20년이 훨씬 넘었고, 미래에는 어떤 요구사항이 생길지 알 수 없음. 근데 한 번 표준을 만들면 바꾸기가 힘들어서 정하기 어려움.
=> 새로운 버전의 패킷이 생기면, 이를 이해하는 라우터들이 필요함 + 섞여서 산재할 가능성이 높음 (터널링과 같은 작업들이 필요)
IPv4의 문제
1) 주소 공간 부족
2) 초반에 Security를 고려하지 않고 디자인함
Dynamic Host Configuration Protocol(DHCP)
어떤 네트워크로 이동하든 해당 네트워크의 Router, DNS를 동적으로 지정해줌.
장점: address pool을 가지고 그때그때 active한 사용자 수만큼만 rental해줄 수 있으므로 고정 IP에 비해서 비용이 적게 듦.
cf.
고정 IP, 라우터를 쓰는 경우도 있긴 함. 
소스가 0.0.0.0 : 아무것도 모르니까 좀 도와달라. 포트는 68번.
목적지 주소가 255.255.255.255(32bit가 1)면 브로드 캐스트(서브넷에 있는 모든 멤버는 이 메세지를 받으라는 뜻)
DHCP 서버는 67번 포트를 돌리고 있음.
DHCP discover 메세지를 서브넷의 모든 호스트들이 받고, DHCP 서버 외에는 다 버려버림.
모든 애들이 받긴 하는데 67번 포트로 가는데, DHCP 서버 컴퓨터에서만 67번 포트를 열고 있어서 다른 애들은 버리게 됨.
offer message에 source ip는 자기 자신.
destination ip도 보면 브로드캐스트. 그 이유는 아직 클라이언트가 이름을 가지고 있지 않기 때문. 68번이 열려 있고, 클라이언트에서 선택한 transaction ID를 가진 것을 보고 클라이언트가 이 오퍼를 받아들임. lifetime은 1시간으로 되어있음. 오퍼를 받아서 수락한다는 의미로 다시 request를 보내는데 아직 이름은 없으니까 src 주소는 0.
아까 transaction id에 1를 더해서 보내줌.
ACK에 Router IP, DNS IP, IP가 담겨있어서 이 과정이 끝나면 모두 지정되게 됨.
DHCP 서버가 여러 개여서 offer가 여러 개 오는 상황이 있을 수도 있기 때문에, offer 후에 선택해서 request를 보내는 과정이 다시 필요함.
예시
IP: 192.168.1.47
Mask: 255.255.255.0 (3번째까지가 네트워크 ID라는 뜻)
Router: 192.168.1.1 (내 컴퓨터가 요청을 보냈을 때 이 요청을 전달해줄 가장 첫 라우터)
DNS: 192.168.1.1 (도메인을 IP로 변환해줄 로컬 네임 서버의 IP)
보통 게이트웨이 라우터에서 로컬 DNS 프로세스, DHCP 서버, NAT 프로세스, Firewall가 다 돌아가고 있음.
예시)
실제 집을 예로 들어보면, 인터넷 회사에 달마다 돈을 내고 받는 것은 IP 주소. 여기에서 무선 공유기가 게이트웨이의 기능을 해서 하나의 서브넷을 이루고 있음. 같은 공유기를 사용하면 prefix가 같음. prefix.1은 무선 공유기.
이 공유기를 사용하는 각각의 사용자는 IP 주소가 다르지만, 나갈 때는 같음(인터넷 회사에서 준 IP)
나가는 주소는 유일한 주소일까? 그것도 알 수 없음. 그 앞에 또 NAT가 있을 수도 있음.
ICMP(Internet Control Message Protocol)
네트워크 상에서 일어나는 event에 대한 정보를 source IP에 전달하기 위한 프로토콜. 네트워크 진단을 위해 사용됨.
ex) TTL이 0이 되어서 드랍될 때
