4.3 인터넷 프로토콜(IP) : IPv4, 주소체계, IPv6 등
IPv4 fragmentation, reassembly
- 네트워크 링크에는 링크 수준 프레임이 전송할 수 있는 최대 데이터 양인 MTU(최대 전송단위) 가 있다.
- 경로에 따라 다른 링크유형 , 다른 MTU
- 라우터에서 대용량 IP 데이터그램 분할('fragment')
- 하나의 데이터그램 -> 여러 개의 데이터그램(조각)
- 'IP header'을 사용하여 전송 계층에 도달하기 전에 router가 아닌 최종 목적지 "host"에서만 재조립됨.
- IP헤더비트는 관련 조각 식별, 순서 지정에 사용
IP4 fragmentation at router
- Q. MTU가 700바이트인 링크로 2400바이트의 데이터그램을 전송한다고 가정해보자. 원본 데이터그램에 식별번호 422가 찍혀 있다고 가정한다 .몇 개의 조각 영역이 생성될까? 조각화와 관련하여 생성된 IP datagram의 다양한 필드 값은 무엇인가?
- IP 주소지정 : introduction
- IP adress : 각 호스트 또는 라우터 인터페이스와 연결된 32-bit 식별자
- interface : host/router과 물리적 링크 간의 연결
- 라우터에는 일반적으로 여러개의 인터페이스가 있다.
- 호스트에는 일반적으로 하나 또는 두개의 인터페이스(ex. 유선 이더넷, 무선 802.11) 가 있다.
- IP adresses는 각각 인터페이스와 연관돼있다.
- host의 network inteface가 router에 직접 몰려있는 경우 거의 x. 대부분 ethernet switch나 wifi access point에 몰려있다.
- subnets
- subnet이란? : IP주소의 동일한 서브넷 부분을 가진 장치 인터페이스는 라우터의 개입 없이 물리적으로 서로 연결할 수 있다.
- IP주소에는 구조가 있음:
- 서브넷 부분: 동일한 서브넷에 있는 장치는 공통 high order bits를 가진다.
- 호스트 부분: low order bits 유지
Q. 서브넷은 몇개일까?
- subnet을 정의하는 방법
- 서브넷을 결정하려면 라우터에서 각 인터페이스를 분리하여 격리된 네트워크의 섬을 만든다.
- 분리된 각 네트워크를 서브넷이라 한다. (subnet portion adress가 일치하는 집합)
IPv4 adressing : classful v.s. classless adressing
- classful adressing : 유용- packet 들어왔을 때 first few bit만 보면 forwarding table에서 look up 할 때 몇 bit까지 look up할지가 확실-> look up process가 확실
- forward table의 individual interface별로 forwarding table entry를 만들지 않는다.
- subnet별로 entry 만듦 -> network core에서의 forwarding table의 size가 subnet 개수정도 있으면 됨 -> 훨씬 scale 줄어듦.
- incoming IP datagram의 destination IP adress를 forwarding table에서 찾을 때는 subnet portion만 보면 됨 -> 1st octet의 1st few bit만 보면 금방 subnet portion의 몇 bit까지인지가 결정
- IP주소 : 223.7.112.9/24
- subnet mask를 써준다? -> subnet portion의 bit 수가 가변적일 수 O
- 현재 사용하고 있는 IP adress mechanism : class less adressing
- 처음에는 classful adressing 사용: 1st Octct의 high order bit를 가지고 어느 class에 속하는 IP 주소인지 쉽게 판단 가능
IPv4 classless addressing : CIDR
- classful adressing의 단점 : class C는 너무 작은 호스트제공(최대 254호스트)
class B는 너무 많은 호스트를 제공(최대 65534개 호스트)- --> 클래스 B 주소 공간의 빠른 고갈 및 할당된 주소 공간의 활용도 저하, IP주소 space를 많이 낭비 --> CIDR(classless interdomain routing)
- CIDR
- 임의 길이(가변적)의 주소의 서브넷부분 -아무 길이라도 될 수 O.
- /24 : subnet mask 명시하는 가변적 길이의 subnet portion 가지는 classless Interdomain Routing하게 됨.
- -> classful : B=16, A=8, C=24
- 형식: a.b.c.d/x, 여기서 x는 주소 x의 서브넷 부분에서 가장 왼쪽 비트 #
- x는 called 'subnet mask', 'network prefix', 'prefix'
- 임의 길이(가변적)의 주소의 서브넷부분 -아무 길이라도 될 수 O.
- ----> IPv6
- move on하게 된 계기 : IP주소 space의 고갈. 여기서는 주소 bit가 32bit -> 128bit => 식별할 수 있는 interface의 개수 많음 (2^32 -> 2^128)
- IP는 네트워크 코어의 라우터에도 올라가는 프로토콜 계층 -> IP에 변화가 오면 painful
- 하루만에 변화 불가. 점진적으로 , interoperable하게, 공존하게 하며 change(이 과정에서 나온 게 CIDR)
- 하루만에 변화 불가. 점진적으로 , interoperable하게, 공존하게 하며 change(이 과정에서 나온 게 CIDR)
- IP는 네트워크 코어의 라우터에도 올라가는 프로토콜 계층 -> IP에 변화가 오면 painful
- move on하게 된 계기 : IP주소 space의 고갈. 여기서는 주소 bit가 32bit -> 128bit => 식별할 수 있는 interface의 개수 많음 (2^32 -> 2^128)
Q1) 서브넷 마스크가 /24일 때, IP 주소들이 동일한 네트워크에 속하는지 확인하려면, 첫 번째 세 개의 옥텟(128.119.40)은 동일하게 유지되어야 합니다.
- 128.119.40.64, 128.119.40.80, 128.119.40.96, 128.119.40.112는 모두 128.119.40.0/24 네트워크에 속합니다.
따라서, 답변은 "예" 입니다.
Q2) 서브넷 마스크가 /26일 때, /26 서브넷 마스크는 각 서브넷을 64개 주소 범위로 나눕니다.
- 128.119.40.64, 128.119.40.80, 128.119.40.96, 128.119.40.112는 각각 다른 /26 서브넷에 속합니다.
따라서, 답변은 "아니오" 입니다.
Q3) 서브넷 마스크가 /28일 때, /28 서브넷 마스크는 각 서브넷을 16개 주소 범위로 나눕니다.
- 128.119.40.64, 128.119.40.80, 128.119.40.96, 128.119.40.112는 서로 다른 /28 서브넷에 속합니다.
따라서, 답변은 "아니오" 입니다.
-
- 네트워크 주소: 호스트 비트가 모두 0인 IP 주소. 네트워크 자체를 나타냅니다.
예: 192.168.1.0 (네트워크의 시작점) - 브로드캐스트 주소: 호스트 비트가 모두 1인 IP 주소. 네트워크의 모든 장치로 데이터를 보내는 데 사용됩니다.
예: (네트워크의 끝점)
- 네트워크 주소: 호스트 비트가 모두 0인 IP 주소. 네트워크 자체를 나타냅니다.
- 2가지 질문
- Q1. host는 네트워크 내에서 어떻게 IP주소를 얻을까요(주소의 호스트 부분)?)
- 구성에서 sysadmin(server와 관리자)(얘가 computer configuration file에 직접 hard coding)에 의해 하드코딩됨
- DHCP : 동적 호스트 구성 프로토콜 : 서버에서 동적으로 주소 가져오기 - 내가 IP주소가 필요하면 동적으로 server(관리자)에서 받아옴 -> 하드코딩하는 것이 아닌 DHCP program 구동돼서 DHCP server로부터 dynamic하게 내가 쓸 IP주소 받아와서 설정.
- Q2. 네트워크는 자체적으로 IP주소를 어떻게 얻나요(주소의 서브넷 부분)?
- ex. 우리학교로 치면 정보통신처라는 중앙부처에 data 신청, IP주소 하나 주세요 ! 하면 줌.
- Q1. host는 네트워크 내에서 어떻게 IP주소를 얻을까요(주소의 호스트 부분)?)
- 프록시 서버는 클라이언트와 실제 서버 사이에서 중계 역할을 하는 서버입니다. 클라이언트의 요청을 받아 이를 실제 서버로 전달하고, 응답을 받아 클라이언트에 전달합니다.
- DNS 서버는 도메인 이름을 IP 주소로 변환하는 역할을 하는 서버입니다. 사람이 기억하기 쉬운 도메인 이름(예: www.google.com)을 컴퓨터가 이해할 수 있는 숫자 IP 주소(예: 142.250.64.78)로 바꿔줍니다.
- 하드 코딩이란 프로그램의 코드에 변경 가능한 데이터(값이나 설정)를 고정된 형태로 직접 삽입하는 것을 의미합니다. 즉, 외부 파일, 데이터베이스, 사용자 입력 등에서 값을 가져오지 않고, 코드에 직접 값(상수나 문자열 등)을 삽입하는 방식입니다.
- DHCP(hard coded 와 대비)
- 동적 호스트 구성 프로토콜 : 서버에서(not 사람관리자) 임시주소(일시적으로 할당)를 동적으로 가져온다.
- popular -> well-known port번호(67) 갖고 있음. client도 well-known port번호 사용
- Client-Server protocal
- Plug-and-play(바로)
- Service/deamon[사용자가 직접적으로 제어하지 않고 백그라운드에서 돌면서 여러 작업 하는 프로그램(저절로 실행)]은 UDP(서버포트: 67)을 통해 실행된다.
- 클라이언트는 잘 알려진 포트(68)도 사용한다. 왜? -> "클라이언트 IP 주소 및 브로드캐스트 없음"으로 인해. - IP주소 없는 상황 -> 무조건 DHCP msg broadcasting
- IP 주소 없는 상태: 클라이언트는 DHCP Discover 메시지를 브로드캐스트(255.255.255.255)로 전송.
- 클라이언트 포트 68 사용 이유: DHCP 응답을 받을 준비를 하기 위함. 포트 68은 클라이언트 측에서 예약된 포트.
- "IP 주소 및 브로드캐스트 없음"의 의미: 초기 IP 주소가 없으므로 클라이언트는 반드시 브로드캐스트를 통해 네트워크와 통신해야 함.
DHCP: 동적 호스트 구성 프로토콜
- 목표: 호스트가 네트워크에 '가입'할 때 네트워크 서버로부터 동적으로 IP주소 획득
- 사용중인 주소의 임대 갱신 가능
- 주소 재사용 허용(연결/켜져 있는 동안에만 주소 유지)
- 네트워크에 가입/탈퇴하는 모바일 사용자 지원 - 특히 모바일 유저에게 더 유용 :
- 자꾸 장소 옮김 -> 학교에서 나를 연결시켰던 access point와 집에서 나를 연결해주는 wifi access point가 다름, or ethernet switch 달라짐.
- hard coding 방식은 사용자가 힘들어짐 <-> DHCP는 새로운 네트워크가 참여할때마다 새로운 ip주소 뽑아서 자동으로 background에서 할당. 이전에 사용되던 adress는 다시 collect돼서 reuse됨.
- IP주소 받아오면 일정 시간만큼만 사용할 수 O. 후에 다른 애한테 할당. 사용하고 나면 집 감 -> 집에서 또 새로운 IP주소 받음 -> 주소 reuse 가능(훨씬 많은 사용자 support <-> hard coding(그 주소는 이 인터페이스에 붙어있음)
- IP주소 부족 문제에 기여. 주소 사용하다가 이 사람이 network 안 떠나고 계속 사용 -> 주소 사용기간 renew -> 다시 사용할 수 O.
- 어느 장소에 가서 컴퓨터 켜면 거기에 network available하면 자동으로 plug-and-play 상태.
- 개요;
- 호스트가 DHCP 검색메시지를 broadcast한다.(선택사항) -client
- DHCP서버가 DHCP offer msg로 응답(선택사항) - server
- 호스트가 IP주소 요청 : DHCP요청 msg - client
- DHCP가 주소 보냄 : DHCP ack msg - server
- server와 client가 주고받는 msg : request와 ack. obtional하게 discover과 offer
DHCP client-server 시나리오
- 전형적으로 DHCP서버는 라우터에 함께 위치하여 라우터가 연결된 모든 서브넷에 서비스 제공
모든 DHCP msg는 목적지주소가 다 broadcast - 모든 DHCP client-server interactional 완성될때까지(완성돼야 host가 그제서야 IP주소 할당받음)
DHCP: more than IP adress
- DHCP는 서브넷에서 할당된 IP주소 이상을 반환할 수 있음-IP의 subnet mask도 같이 알려줌
- network mask(주소의 네트워크 vs 호스트 부분 표시)
- 클라이언트의 first-hop 라우터(기본 게이트웨이) -ip주소 알려주며 더불어 알려줌 + 나는 내 주소 알고 보내고 싶으면 기본게이트웨이에 보내면 됨. 내 목적지의 host name을 알고 있으면 그 host name을 번역할 수 있어야 함
- DNS 서버의 이름 및 IP주소(DNS 서버 자체의 IP주소를 알아야 클라이언트가 DNS서버와 통신 가능)
- 통신하기 위해 first hope router 정보, DNS 서버의 IP주소 필요 --> 다 DHCP서버로부터 받아옴
- client는 IP주소 외에 네트워크 계층의 routing protocal 안 갖고있음. 무조건 first hope router로 토스(패킷 보낼 때 라우팅 신경쓰지 않고 기본 게이트웨이에게 모든 것을 맡김)
예시
- 연결 노트북에 IP주소, first-hop 라우터 주소, DNS서버 주소가 필요 : DHCP사용(얘네 알아오기 위해 msg만듦)
- UDP로 캡슐화되고, IP로 캡슐화되고, 802.1 이더넷으로 캡슐화된 DHCP 요청
- LAN에서 이더넷 프레임 broadcast(목적지: FFFFFFFFFFFF), DHCP 서버를 실행하는 라우터에서 수신됨
- 이더넷이 IP demuxed로 demux되고 UDP가 DHCP로 demux됨
- DHCP서버는 클라이언트의 IP주소, 클라이언트의 첫번째 홉 라우터의 IP주소, DNS서버의 이름 및 IP주소가 포함된 DHCP ACK을 공식화한다.
- DHCP서버의 캡슐화, 클라이언트로 프레임 전달, 클라이언트에서 DHCP까지 demuxing
- client는 이제 자신의 IP주소, DNS서버의 이름 및 IP주소, 첫번째 홉 라우터의 IP주소를 알 수 있음. - client가 자신이 network에 connect돼서 다른 사람들과 통신하기 위해 필요
IP adresses : 서브넷 부분은 어떻게 얻나요?
Q. 네트워크는 IP주소의 서브넷 부분을 어떻게 얻나요?
A. 제공자 ISP의 주소 공간 일부를 할당받습니다.
- 계층적 주소 지정 : 경로 집계(route aggregation)
- 계층적 주소 지정을 통해 라우팅 정보를 효율적으로 advertise(알리다) 할 수 있음
- 조직 1이 Fly-By-Night-ISP에서 ISP-R-Us로 이동
- ISP-R-Us는 조직1에 대한 보다 구체적인 경로 알림(advertise)
- subnet prefix와 host ID, network 주소가 계층적으로 이루어져 있음. IP주소의 allocation 자체도 ISP가 기관에게, 기관이 각 host에게 allocate -> 계층적 adressing이 root정보 advertise를 굉장히 efficient 하게 만듦.
- 가장 긴 prefix 매칭
- 지정된 대상 주소에 대한 forwarding table 항목을 찾을 때 대상 주소와 일치하는 가장 긴 주소 prefix를 사용한다.
- Q9. ISP가 128.119.40.64/26형식의 주소블록을 소유하고 있다고 가정하자. 이 블록에서 4개의 subnet을 생성하려고 하며 각 서브넷에는 동일한 수의 IP주소가 있다고 가정하자. 네개의 서브넷의 접두사(a.b.c.d/x)는 무엇인가?
IP adressing : last words...
Q. ISP는 어떻게 주소 블록을 얻나?
A. ICANN: internet corporation for assigned names and numbers - root server 관리하는 역할 담당, ISP들에게 주소 block 나눠주는 역할도 함.
- 5개의 지역 registries(RR)을 통해 IP주소[RFC 2050]를 할당(이후 지역 레지스트리에 할당할 수 있음)
- 레지스트리(Registry)**는 네트워크나 인터넷 자원(예: IP 주소, 도메인 이름 등)을 등록하고 관리하는 기관이나 데이터베이스를 의미합니다.
- 개별 TLD(.com, .edu, ...)관리 위임, 도메인 이름 할당, 도메인 이름 분쟁 해결을 포함한 DNS루트서버 관리
- 중재 : 자신이 원하는 domain name가진 소유자에게 돈 내고 삼, 분쟁 생기면 중재 (누가 이미 점유하면 점유한 소비자에게 돈 내고 사는데, ICANN에서 중재역할을 함.)
- 한국인터넷정보센터(KRNIC)
Q. 32비트 IP주소가 충분한가? (2^32)
A.
- ICANN은 2011년에 마지막 IPv4 주소를 RR에 할당했다.
- NAT(다음)은 IPv4 주소 공간 고갈을 돕는다.
- IPv6은 128비트 주소공간을 가진다.
- classless interdomain routing 사용 -> 굉장히 tight하게 IP주소 활용가능
-첨에는 이렇게 많은 주소공간이 필요한지 몰랐음
NAT : network adress translation or NAPT : network address port translation
- NAT : 로컬 네트워크의 모든 기기는 외부 인터넷에 대해 하나의 IPv4 주소만 공유한다. - local site 전체가 하나의 ip주소로 살아가게 해줌
로컬 네트워크를 떠나는 모든 데이터그램들은 동일한 단일소스 NAT IP주소(138.76.29.7)와 다른 소스 포트 번호를 갖는다.
로컬 네트워크의 모든 장치는 로컬네트워크에서만 사용할 수 있는 "개인"IP주소공간에 32비트 주소(10.0.0/24)를 가진다.
- 16비트 포트번호필드: 단일 LAN측 주소로 60,000개의 동시연결 가능!
NAT의 동기부여 및 장점
- home network 연결하는 router통해 작은 기관처럼 자기 뒤에 딸려있는 host들을 위해 block of ip주소 요구 -> 그런데 ip주소는 없음 -> isp가 ip주소 하나만 둬서 얘네 다 연결
- 동기부여
- 모든 IP지원 디바이스에는 IP주소가 필요
-
- 모든 ip 디바이스가 unique한 ip주소 필요 -> ip주소는 running out
-
- 소규모 사무실, 홈 오피스(SOHO) 서브넷의 확산
- 모든 IP지원 디바이스에는 IP주소가 필요
- 장점
- ISP에서 필요하지 않은 주소범위 : 모든 장치에 대해 공급자 ISP로부터 하나의 IP주소만 필요.
- ip주소를 아낄 수 있는 좋은 방법
- 로컬 네트워크에서 외부에 알리지 않고 호스트의 주소 변경 가능
- 내가 service받는 isp 바꿈 -> subnet prefix 달라짐 -> router뒤에 있는 애들이 다 isp 주소 바꿀필요 x. -> security 측면에서 + 외부에서 온 패킷 거를 수 있는 장치 추가. ip주소하나만 줘서 다 연결시킴
- 로컬 네트워크 안에서만 valid, 이 안에서 ip주소 바꿔도 밖에서 알 수 x.
- 로컬 네트워크에서 디바이스의 주소를 변경하지 않고도 ISP변경가능
-
- ISP의 subnet prefix 달라짐 -> router 뒤에 있는 모든 호스트들이 ip주소 바꿔야 함 -> NAT 뒤에 있는 host들은 어차피 private주소 사용 -> 어차피 안엔서만 통용 -> 변경할필요 x.
- 내 상황이 외부에 알려질 필요 x. 연결된 isp에 따라서 내 ip주소 바꿀 필요 x - 이런 점이 security면에서 +
- local host가 outside world에서는 not visible. NAT- enabled router만 볼 수 있고 얘를 반드시 통과해야 함.
- 내 상황이 외부에 알려질 필요 x. 연결된 isp에 따라서 내 ip주소 바꿀 필요 x - 이런 점이 security면에서 +
- ISP의 subnet prefix 달라짐 -> router 뒤에 있는 모든 호스트들이 ip주소 바꿔야 함 -> NAT 뒤에 있는 host들은 어차피 private주소 사용 -> 어차피 안엔서만 통용 -> 변경할필요 x.
- 보안 : 로컬 네트워크 내부의 디바이스는 직접 주소 지정이 불가능하며 외부에서 볼 수 있음
- ISP에서 필요하지 않은 주소범위 : 모든 장치에 대해 공급자 ISP로부터 하나의 IP주소만 필요.
NAT 구현
- 구현 : NAT enabled 라우터는 반드시(투명하게) - host들은 모름:
- 모든 outgoing datagrams : 모든 발신 데이터그램의 (소스 ip주소, 포트#)-(private)를 (NAT IP주소, 새 포트#)로 바꾼다.-NAT가 intercept 해서 NAT-enabled router의 외부와 통용되는 ip주소로 바꿈, 이 source로부터 request packet이 왔다고 생각하여 대입할때도 목적지주소를 이렇게 적음
- 현재 진행중인 conversation과 overlap되지 않는 unique한 새로운 port#로 붙여버림
- NAT translation 테이블의 모든 변환 쌍을 기억한다(바꿨다는 사실 기록) : (소스 ip주소, 포트#)를 (NAT IP주소, 새 포트#)로
- 원격호스트(client)는 (NAT IP주소, 새 포트 #)를 대상주소로 사용하여 응답한다.
- remote host로부터 오는 답도 반드시 NAT enabled router 통과, 외부에서 들어오는 packet에 대해 NAT translation lookup(조회)함.
- incoming datagram : 모든 수신 데이터그램의 대상 필드에 있는 (NAT IP주소, 새 포트 #)를 NAT 테이블에 저장된 해당 (소스 ip주소, 포트#)로 바꾼다.
- local site내에서의 원래 source IP주소, 원래 port#로 바꿔치기. local network에서 목적지로 datagram을 보내주게 된다. - NAT뒤에 있는 호스트 입장에서
- 모든 outgoing datagrams : 모든 발신 데이터그램의 (소스 ip주소, 포트#)-(private)를 (NAT IP주소, 새 포트#)로 바꾼다.-NAT가 intercept 해서 NAT-enabled router의 외부와 통용되는 ip주소로 바꿈, 이 source로부터 request packet이 왔다고 생각하여 대입할때도 목적지주소를 이렇게 적음
NAT는 어떻게 일하는가
논란의 여지가 있는 NAT-궁극적으로 NAT가 아닌 IPv6 이용하여 문제 해결해야 함
- 주소부족은 IPv6로 해결해야 한다. - IP번호 밑에 있는 port번호로 들어가서 header 바꿔줘야 함
- 라우터는 layer3 이상에서만 처리해야 한다.
- port번호는 segment에 있으므로 IP header 밑에 있는 header에 들어가서 port번호 바꿔줘야 함
- NAT는 원래 인터넷 설계에서 구상된 종단간 연결 원칙(네트워크 계층 장치에 의한 포트번호 조작)을 위반
- port번호는 end-to-end로 사용하는 번호인데 segment는 end-to-end로 얘가 보낸 segment를 그대로 상대방 transport process에서 받아와야함 -> 그런데 그러지 못함
- 홈 네트워크에서 실행되는 서버에 문제 일으킴
- 클라이언트가 NAT 뒤에 있는 서버에 연결하려는 경우 어떻게 해야 하나?(ex. p2p애플리케이션에서는 NAT뒤에 있는 peer가 서버역할을 할 수 없음) but 많은 application이 client-server형태, NAT뒤에 있는 host는 서버가 될 수 x.
- client process라면 먼저 server에게 packet 내보내기 때문에 상관x -> NAT table에 entry가 생기게 됨.
- server쪽으로부터 답이 왔을 때 client에게 잘 deliever될 수 있음
- NAT뒤에 있는 host가 server라면 server의 존재에 대해 외부에서 알 수 x -> 외부의 client들이 server의 존재에 대해 알 수 x.
- --> NAT traversal techniques(NAT 통과기술): 앱 설계자는 NAT 가능성을 고려해야 한다. - NAT뒤에 server둘 수 없음 해결
- 하지만 가정 및 기관 네트워크, 4G/5G 셀룰러 네트워크에서 광범위하게 사용되는 NAT.
UPnP IGD
universal plug and play(어디서나 plug and play) Internet gateway device protocal
호스트가 IGD(인터넷 게이트웨이 장치)프로토콜을 기반으로 근처의 NAT를 자동으로 검색하고 구성할 수 있는 프로토콜
- NAT traversal technique의 제일 근본적인 문제 : client-server architecture에서 NAT 뒤에 있는 host가 server가 될 때.
- private한 ip와 server end point의 IP 포트 번호를 외부에서 통용되는 IP포트번호로 translate해주는 NAT translation table이 없어서.
NAT(Network Address Translation)은 LAN(Local Area Network)에서 사용되는 사설 IP 주소와 WAN(Wide Area Network)에서 사용되는 공인 IP 주소 간의 주소 변환을 처리하는 데 사용된다. NAT 테이블은 이러한 변환 정보를 추적하는 데 사용되며, IGD(Internet Gateway Device) 프로토콜을 통해 이를 확인할 수 있다.
- classful adress에서 classless interdomain routing으로 넘어가고 더 잘 사용하기 위해 DHCP이용 -> 재사용 가능(줬다뺐다) 궁극적으로 site 전체가 주소 하나 갖고 살아가게하는 NAT ->한계점 해결 : IPv6
- Classful Addressing에서 Classless Inter-Domain Routing(CIDR)로의 발전, 그리고 DHCP 및 NAT의 활용은 네트워크 주소 공간의 효율적 이용과 인터넷 확장성을 높이기 위해 도입된 중요한 개념들입니다.
- Classful Addressing(클래스 기반 주소 체계)은 IP 주소를 A, B, C, D, E 클래스로 나누어 정해진 크기의 네트워크와 호스트 주소를 제공했습니다. 문제점: IP 주소가 고정된 크기로 분배되다 보니 비효율적이었습니다.
- Classless Inter-Domain Routing (CIDR)의 등장 : CIDR는 고정 클래스 경계를 없애고 유연한 네트워크 분할을 가능하게 했습니다. 네트워크 크기를 서브넷 마스크를 사용해 표현 (예: /24는 256개의 주소 제공).
- DHCP는 네트워크에서 IP 주소를 동적으로 할당하고 관리하는 프로토콜입니다.
- NAT(Network Address Translation)의 역할 : NAT는 네트워크 내부의 사설 IP 주소를 공인 IP 주소로 변환하여 인터넷에 연결합니다.
- 궁극적 효과: IP 주소 절약, 보안 강화, 네트워크 확장성 제공
IPv6 : 동기부여
- 초기동기부여 : 32bit IPv4 주소공간이 완전히 할당될 것이다.(주소부족문제 해결)
- 추가동기부여:
- 헤더형식은 처리/전달속도 높이는 데 도움됨 ; 40-byte 고정길이헤더
- 굉장히 빨라진 transmission medium(전송매체)을 keep up하기위해 router의 processing speed를 boost-up하기 위한 방법도 고려
- 헤더를 변경하여 QoS(flow에 대한 QoS지원, 네트워크 리소스를 효율적으로 관리하여 특정 애플리케이션이나 서비스가 필요로 하는 대역폭, 지연, 패킷 손실률 등을 보장 ) 용이하게 함; 'flows'를 다른 네트워크 계층에서 처리 가능
- IPv6가 연구되면서부터는 향후 killer application은 streaming이 될 것이다(real time app)
- 헤더형식은 처리/전달속도 높이는 데 도움됨 ; 40-byte 고정길이헤더
- IPv5는?
- target이 streaming 잘 하게 하기 위한 것, 달라진 거 별로x -> 그냥 사라짐.
IPv6 adressing
IPv6 datagram format
- 라우터 버전에서는 조각화가 허용되지 않음
- flow label : 동일한 flow의 데이터그램 식별("흐름"의 개념이 잘 정의되지 않음)
- next header : 이 데이터그램의 데이터 필드가 전달될 프로토콜을 식별
IPv6 패킷의 확장 헤더 체인 연결(IP datagram payload에 upper layer data unit 실린경우)
페이로드 : **헤더(header)**와 **페이로드(payload)**로 구성된 데이터 패킷에서, 헤더는 데이터를 전달하는 데 필요한 제어 정보(예: 출발지, 목적지, 패킷 길이 등)를 포함하고, 페이로드는 실제 전달하려는 사용자 데이터를 포함합니다. 실제 콘텐츠가 바로 페이로드입니다.
Changes from IPv4
- 고정길이 40byte header(src/dst 주소의 경우 32bytes)
- 다음 hope으로 보내는 link로 전송할 수 x -> packet drop -> source쪽으로 packet too big msg 보냄.
- 라우터에서 조각화가 허용되지 않음 -for speed up- "packet이 너무 큼" ICMPv6 msg(얘를 이 패킷의 source로 보내줌), 다음 홉의 MTU(source가 retransmit할 때 자체에서 fragmentation해서 넘김) size 제공, router끼리 오류사항 활용
- **MTU (Maximum Transmission Unit)**는 네트워크에서 한 번에 전송할 수 있는 최대 데이터 패킷 크기를 의미합니다. MTU는 바이트 단위로 측정되며, 각 네트워크 인터페이스 및 링크에서 설정된 최대 크기를 초과하는 데이터를 전송하려면 **패킷 단편화(fragmentation)**가 필요합니다.
- 헤더 checksum X. 각 router에서 처리시간 줄이기 위해 완전히 제거
- 현재상황 network에서는 적절, transmission bit error로 인해 IP datagram 받았는데 오류가 있는 datagram 받을 chance 너무 낮음 -> 오류가 있다면 end point에서 check되도록
- options : 확장헤더로 허용되며 "다음헤더"필드에 표시.
- 가변길이 header가 hardware 적힌 IPv6 datagram처리 어렵게 함 -> 없애버리고 확장헤더 만듦
- 먼저 고정헤더 처리 -> extention header 있으면 그 때 처리.
Transition from IPv4 to IPv6(얘네가 섞여있으면 tunneling 기법 사용)
- 모든 router을 동시에 업그레이드할 수 없음
- 'flag days' 없음
- IPv4 및 IPv6 혼합 라우터로 네트워크가 어떻게 작동하는가?
1. Dual Stack : 라우터는 하나의 인터페이스에 두 개의 IPv4/IPv6 주소를 모두 갖고 있음
2. NAT-PT (NAT-Protocol Translation) : 주소뿐만 아니라 IPv4와 IPv6간의 프로토콜 변환 지원
3. Tunneling
1. dual stack
- dual stack router : 관련 ip체계의 네트워크를 가리키는 인터페이스에 ipv4, ipv6 주소가 모두 구성된 상태로 설치.
- 라우터, PC 등의 네트워크 장치가 동일한 인터페이스에서 IPv4와 IPv6를 동시에 지원하는 방식입니다.
두 프로토콜이 독립적으로 작동하며, 장비는 요청에 따라 적절한 프로토콜을 선택하여 통신합니다. - 얘가 연결돼있으면 ipv4일때는 얘에 맞춰서, ipv6일 때는 얘에 맞춰서 동작가능
- ipv4, ipv6 주소가 구성된 서버는 ipv4, ipv6 네트워크 모두의 모든 호스트와 통신가능
- 호스트가 각각의 ip버전 변경하지 않고도 서버에 접속할 수 있는 매체 제공
- 대부분 코어가 아닌 인터넷의 edge에 위치
- 라우터, PC 등의 네트워크 장치가 동일한 인터페이스에서 IPv4와 IPv6를 동시에 지원하는 방식입니다.
2. NAT-PT (NAT-Protocol Translation)
- ipv4주소를 가진 호스트는 NAT-PT장치/라우터 도움으로 IPV4주소를 이해하지 못하는 인터넷의 IPv6 지원서버에게 요청을 보낼 수 있다.
- IPv4와 IPv6 간의 통신을 가능하게 하기 위해 주소 변환뿐만 아니라 프로토콜 자체를 변환하는 방식입니다.
예를 들어, IPv4 클라이언트가 IPv6 서버와 통신하려면 NAT-PT 장치가 IPv4 패킷을 IPv6 패킷으로 변환합니다.- ipv4호스트가 ipv6 서버에 요청패킷을 보내면 NAT-PT장치/라우터는 IPv4 패킷을 제거하고 IPv4헤더를 제거한 후 IPv6헤더를 추가하여 인터넷 통해 전달
- IPv6 서버에서 IPv4 호스트에 대한 응답이 오면 라우터는 그 반대의 경우도 마찬가지로 행동.
3. Tunneling
- 터널링: 사용자의 데이터가 지원되지 않는 IP버전을 통과할 수 있는 더 나은 솔루션. 중간경로 혹 전송네트워크가 서로 다른 IP버전일 때 유용
- IPv6 패킷을 IPv4 패킷에 캡슐화하거나 반대로 처리하여, 서로 다른 네트워크 간 통신이 가능하게 하는 기술입니다. 캡슐화된 패킷은 기존 네트워크를 통해 전송되고, 종단에서 캡슐이 해제되어 원래의 프로토콜 데이터가 복구됩니다.
- 두 개의 원격 IPv4 네트워크가 터널을 통해 통신할 수 있으며 transit network는 IPv6에 있다.
- 전송네트워크가 IPv4에 있고 통신하려는 원격 사이트가 IPv6에 있는 경우의 반대의 경우도 가능
- IPv4 라우터간에 IPv6 데이터그램을 payload로 전달하는 IPv4 데이터그램("패킷 내의 패킷")
- 다른 context에서 광범위하게 사용되는 터널링(4G/5G)
- **Payload(페이로드)**는 네트워크 통신이나 데이터 전송에서 실제 전달되는 데이터 또는 유용한 정보를 의미합니다. 페이로드는 데이터 패킷의 헤더(Header)나 메타데이터를 제외한 순수한 내용물입니다.
IPv6: adoption
- 구글: ~45%의 고객이 IPv6를 통해 서비스에 액세스
- NIST: 전체 미국 정부 도메인의 1/3이 IPv6 지원
- 긴 시간동안 배포, 사용(20년이상)
- 다양한 새로운 application이 등장한 것에 비해 IPv6가 adapt되는데는 시간 많이 걸림 -> 네트워크 core에 변화를 가져와야 하는 상황이기 때문 + IPv4위해 만들어진 app이 많기 때문
4.4 일반화된 포워딩 및 소프트웨어 기반 네트워크(SDN)
- generalized forward, SDN(software-defined networking) - data 전달이 어떻게 이루어지나, data plane에서 어떤 일들이 일어나는가
- OpenFlow(이 네트워크에서 가장 초창기부터 사용되기 시작한 네트워크) : match-plus-action
- router의 forwarding table에 longest prefix matching -> forwardign table lookup&forward
- traditional table에서는 router가 forwarding table maintain, incoming packet에 대해 forwarding table lookup&forward
Generalized forwarding : match plus action
- review: 각 라우터에는 포워딩 테이블(일명 flow table)이 포함돼 있음
- traditioal하게는 internet에서 forwarding table을 router에서 maintain
- traditional 하게는( destination based forwarding ) lookup and forward. generalized forwarding에서는 match+action
- match plus action 추상화: 도착하는 패킷의 비트를 match시키고 action을 취한다.
- destination-based forwarding: 목적지를 기반으로 forwarding
- IP header에 목적지 주소 prefix를 갖고 이거에 기반해서 forwarding
- generalized forwarding:
- 받은 IP datagram의 header의 몇 가지 field를 갖고 어떤 treat 해줄건지 결정
- 많은 헤더필드는 action결정 가능
- 많은 action 가능: drop/copy/modify/log packet/ forwarding
- router(목적지 ip주소 기준으로 경로 선택하여 전달), forwarding table(전통적인 라우터는 forwarding table을 사용하여 목적지 ip주소와 네트워크 인터페이스를 매핑한다.)
- 특징 :
- 정적 또는 동적 경로: 경로는 관리자가 설정하거나 동적 라우팅 프로토콜(OSPF, BGP 등)을 통해 학습됩니다.
- 빠른 조회: 목적지 IP를 기준으로 가장 적합한 경로를 선택합니다.
- 단순한 동작: 목적지 기반의 일대일 매핑이 주된 기능입니다.
- 특징 :
- -> packet switch(데이터 링크 계층에서 패킷의 흐름을 기반으로 전달 수행, SDN과 결합되어 세부적인 흐름제어 가능하게 함, flow table(패킷의 다양한 필드를 match하여 특정 동작(action)수행하는 규칙 집합
- 특징:
- 다양한 매칭 필드: IP 주소뿐만 아니라, 포트 번호, 프로토콜, VLAN ID 등도 포함합니다.
- 액션(Action): 전달(Forward), 삭제(Drop), 복제(Clone), 수정(Modify) 등 다양한 작업이 가능.
- 중앙 관리: SDN 컨트롤러가 Flow Table을 실시간으로 업데이트.
- 유연성: 복잡한 네트워크 흐름을 제어 가능.
- 특징:
- destination-based forwarding: 목적지를 기반으로 forwarding
flow table abstraction
- flow : 추상화 전송을 위해 특정 속성을 공유하는 패킷 그룹('match')
- header field 값으로 정의됨(링크, 네트워크, 전송계층 필드)
- flow table의 항목
- 헤더필드 값의 집합 : 들어오는 패킷 헤더 필드의 패턴 값 match; 일치하는 항목이 없는 패킷은 삭제되거나 추가 처리를 위해 원격 컨트롤러로 전송
- actions: matched 패킷에 대해: block/drop, forward, modify(header의 certain field modify), send to a controller(flow table 생성해서 packet switch들에게 내려보냄, in SDN)/special server(packet을 받아서 certain objective를 가지고 bit packet 점검)
- counters : #bytes and #packets(match된 packet의 얘네 얼마나 되는지 통계 keep up-> flow table의 counter 부분에 기록; 패킷이 플로우 테이블 항목과 일치하면 업데이트됨.
OpenFlow: Flow Table Entries
OpenFlow abstraction
- match+action(generalized forwarding): 추상화를 통해 다양한 종류의 디바이스를 통합-동일한 paradigm을 갖고 여러 device의 역할. packet switch 이용해서 하나의 장비 갖고 programmable하게 만듦 -> 굉장히 빠른 속도로 packet switch evolve
- router
- match: 가장 긴 대상 IP접두사
- action: 링크 전달
- switch
- match: 목적지 MAC 주소 -MAC계층 특성: broadcasting하는 medium -> flood(목적지에 보내는 게 아님)
- action: forward or flood
- packet switch라는 장비로 match +action하는 장비 제조하면 얘를 경우에 따라 router, switch, load balancing에 쓸 수 O.
- firewall
- match: IP주소 및 TCP/UDP port번호
- action: 허용 또는 거부
- NAT
- match: IP주소 및 port
- action: 주소 및 port 다시 쓰기
- port : 운영 체제와 네트워크 프로토콜에서 데이터를 특정 애플리케이션이나 서비스에 전달하기 위해 사용하는 식별 번호
- load balancing
- match: 목적지 주소 - 목적지가 어떤 server, 여러 server들이 있음 -> load balancing해주면 좋음. 서로 협력해서 service제공? - match된 pocket을 copy를 여러 개 만들어서 여러 output port로 내보냄.
- action: 서비스로 이어지는 둘 이상의 출력 port 전달
- DPI
- 네트워크 상에서 전송되는 데이터를 패킷 수준에서 상세히 분석하는 기술입니다. 단순히 패킷의 헤더 정보(출발지/목적지 주소, 포트 등)만 확인하는 전통적인 방식과 달리, **패킷의 페이로드(payload)**를 포함한 전체 데이터를 검사할 수 있습니다.
- match: IP주소 및 port
- action: 일치하는 패킷을 추가 처리 및 조치를 위한 특수 서버로 전송
- router
OpenFlow 예시
- orchestrated(조직)된 테이블은 network-wide 동작 생성가능.
- 호스트 h5 와 h6의 데이터그램은 s1, 그리고 거기에서 s2를 통해 h3이나 h4로 전송돼야 한다.
- traditional한 network 사용하는 router에서도 source로부터 목적지까지 가려면 router들이 일관된 행동을 해야 한다.(목적지로 가는데 새로 coordinate) 안그러면 A->B에서 다시 B->A로 올 수 도 있음.
- controller도 flowtable 잘 조직해서 특정 root 따라 목적지까지 갈 수 있도록 한다.(forwarding시 특정 root로 (S1, S2)전달되도록 함 -> traditional distributed routing이 하는 것보다 좀 더 할 수 o, (route inforce)
- SDN network의 centralized controll도 할 수 o. (네트워크 상황 전부 파악한 후 특정한 요구조건에 맞춰 forwarding table 작성), router들이 목적지까지 가는데 균일한 network 필요
- flowtable을 다 작성해야 하는 건 x.
- match class action으로 다양한 기능을 할 수 o
- individual packet switch들에 대해 flow table을 orchestrate할 수 있음.
- like traditional routing(inforce x)에서 전체 router들이 cordinate 서로서로 잘 해서 자신의 own forward table을 각자 distributed way로 establish. 각 individual router들의 forwarding table이 잘 coordinate돼서 목적지까지 가게 하는 것처럼
- network manager가 test목적으로 source로부터 특정 destination으로 data내보낼 때 IP datagram option field이용해서 이 데이터가 지나야 할 길(거칠 router) 명시할수도 있긴 함
4.5 미들박스
Middleboxes
- source호스트와 목적지 호스트 사이의 데이터 경로에서 IP router의 일반적인 표준 기능 이외의 기능을 수행하는 모든 중개 박스.
- source로부터 destination 상으로 가는 길에 있는 box. 기본적인 IP 라우터의 기능을 제공해줌
Middleboxes everywhere!
Middle boxes
- 초기 : 독점(폐쇄형)하드웨어 솔루션
- hardware인 middlebox있어서 하는 기능이 일체형으로 나와있음(새로운 기능 넣으려면 새 미들박스 달아야 함)
- 오픈 API를 구현하는 'whitebix'하드웨어로 전환- 하드웨어 자체는 아주 basic한 기능
- 독점 하드웨어 솔루션에서 벗어나기
- match+action을 통한 프로그래밍 가능한 local actions-program으로 software 제공이 가능해짐
- 소프트웨어 혁신, 차별화를 위한 움직임 : 새로운 기능 필요: software적으로 upgrade가능, whitebox 기능 하는 하드웨어는 하드웨어 업자가 단순화한 whitebox기능 업그레이드 할 수 있음.
- SDN(위의 일환): private/public cloud에 주로 있는 (논리적으로) 중앙 집중된 제어 및 구성관리 - cloud에서 flow table 계산-> 각 packet switch에서 필요로 하는 기능 다운로드 할 수 있게 해줌.
- 사업 분리: 기능들을 software적으로 개발해나가는 사업자 vs whitebox hardware을 판매하는 사업자 -> 발전이 빨라지고 가격 저렴해짐.
- 네트워크 기능 가상화(NFV)-SDN 등장하기 전 좀 더 general한 개념: over white box 네트워킹, 컴퓨팅, storage를 통한 프로그래밍 가능한 서비스 - whitebox에 서비스를 programmable하게 해 줌
The end-end argument(종단인수)
- 일부 네트워크 기능(ex. 안정적인 데이터전송, 혼잡)은 네트워크 또는 네트워크 edge에서 구현 가능-미들박스도 실제로 네트워크 edge에 달리는 경우 많음), 원한다면 네트워크 내, 네트워크 edge에서 구현될 수 있음, 대부분의 것은 end-to-end에서 구현(많은 복잡한 기능 해결)
- 인터넷 접근방식: end-to-end
- 라우터처리를 최소화하기 위한 edge에 대한 복잡성
- 컴퓨터 네트워크의 smart host
- 필요한 기능은 통신 시스템의 end points에 있는 애플리케이션의 지식과 도움만으로 구현할 수 있음.
- router processing minimize + edge(end-to-end)가 smart하기 때문에
- 인터넷 접근방식: end-to-end
- Q. forwarding table(desitnation-based forwarding)이나 flow table(generalized forwarding)은 어떻게 계산되나요?
- A. control plane에 의해!
Virtual Circuits(VC): signaling protocals(가상회로: 신호 프로토콜)
- 설정, 해체 유지에 사용되는 신호 프로토콜
- ATM, frame-relay(FR), X.25에서 사용
- 오늘날의 인터넷에서는 사용되지 않음
Layer-3 Router | Layer-2 Switch |
Network-layer 장치 -계층 3,2,1 구현 |
link-layer 장치 -서로 다른 네트워크 간 네트워크 레이어 헤더 필드 값을 기반으로 데이터그램 전달 |
주요목표: 서로 다른 네트워크간에 network-layer 헤더필드 값을 기반으로 데이터그램 전달 | 주요목표: 동일한 네트워크에서 link-layer 헤더필드값을 기반으로 frame forwarding |
라우팅 알고리즘 실행중 | 라우팅 알고리즘 실행X |
layer-3 FIB와 RIB 다 있음 -라우팅 알고리즘에 의해 |
layer-2 FIB만 있고 RIB는 없음 -layer-2 FIB는 layer 2 프로토콜에 의해서만 구성 |
소위 'layer3 switch' |
네트워크 계층에서...
routing information base(RIB) | Forward Information base(FIB) | |
포함 | -모든 목적지 목록 -목적지에 도착하기 위한 다양한 next hope들 -기타 많은 정보 |
목적지 및 목적지에 도달하기 위한 최적의 next hope |
하나의 목적지는 가능한 많은 next-hopes를 가질 수 있음 | 패킷 전송에 사용 | |
매우 클 수 있음 | 작고 빠름(회선 속도) | |
가장 좋은 next-hop만 FIB로 들어감 | 어떤 사람들은 이를 여전히 route라 부름 |
NAT 통과기술
1. 범용 plug and play
2. Relaying (Skype에서 사용)
3. connection reversal
(1) 접두사가 128.119.40.128/26인 서브넷을 생각해보자. 이 네트워크에 할당할 수 있는 IP주소의 범위는?
(2) ISP가 128.119.40.64/26 형식의 주소 블록을 소유하고 있다고 가정하자. 이 블록에서 4개의 서브넷을 생성하려고 하며 각 서브넷에는 동일한 수의 IP주소가 있다고 가정해보자. 네 개의 서브넷의 접두사 (a,b,c,d/x)는 무엇인가?
'Computer Networking' 카테고리의 다른 글
Computer Networking[컴퓨터 네트워크] chap 5. Network layer (5.5 | 5.6 | 5.7) (0) | 2024.12.09 |
---|---|
[컴퓨터 네트워크] ch5. Network layer (5.1 | 5.2 | 5.3 | 5.4) (2) | 2024.12.07 |
[컴퓨터 네트워크] chap4. Network Layer : The Data Plane ( 4.1 | 4.2 ) (1) | 2024.11.22 |
[컴퓨터 네트워크] chap3. Transport Layer (0) | 2024.10.22 |
[컴퓨터 네트워크] chap2. 애플리케이션 계층 (4) | 2024.10.21 |