CHAPTER 09 인터넷 프로토콜(IP)과 주소체계

IP 패킷 구성과 기능 도메인명 시스템(DNS) IP(IPv4) 주소체계 서브넷 기법 9.1 9.4 9.2 9.3 TCP/IP 네트워크 모델과 IP IP 데이터그램의 형식과 기능 IP 패킷 구성과 기능 DNS의 개념 DNS 서버 IP(IPv4) 주소체계 9.2 IP 주소의 표현 IP 주소의 클래스 서브넷 기법 9.3 서브넷이란 무엇인가 서브넷을 사용하는 이유 서브넷 마스크

TCP/IP 네트워크 모델과 IP TCP/IP란? IP(Internet Protocol)란? 개방형 프로토콜로 누구나 표준화를 통해 제품을 개발 할 수 있음 물리적인 네트워크와 컴퓨터 하드웨어 또는 소프트웨어로부터 독립적이므로 이더넷, 토큰링, X.25, UNIX PC, IBM PC 등 어느 환경에서도 사용 가능 범용성으로 인해 새로운 네트워크 기술을 쉽게 수용할 수 있음 IP(Internet Protocol)란? IP 주소체계를 이용하여 인터넷에 연결된 모든 호스트들과 데이터통신이 가능해짐 IP 계층은 네트워크 계층에 해당하는 프로토콜. TCP/IP 프로토콜에서 전송 메커니즘을 제공  [그림 9-1] IP는 비신뢰성 비연결형 데이터그램 프로토콜. 오류제어 기능 수행 없이 best effort delivery service를 제공함

IP 데이터그램의 형식과 기능 IP에서 사용하는 패킷을 ‘데이터그램 (datagram)’이라 함 최대 60바이트까지 확장가능

IP 패킷 구성과 기능(1) 버전 영역(VER) 헤더 길이 영역(HLEN) 4바이트를 기본 단위로 하여 헤더 부분의 길이를 규정 차별화된 서비스(Differentiated Services) 또는 서비스 유형 데이터의 전송 목적에 따라 서로 다른 우선권을 설정하기 위한 영역 네트워크를 통한 데이터 전송 시 사용자의 데이터마다 우선권을 부여함 우선권이 높은 데이터가 먼저 서비스를 받도록 허용하며 차별화된 서비스를 위한 영역으로 사용할 수 있도록 규정 차별화된 서비스 또는 서비스 유형  [그림 9-3]

9. 1 IP 패킷 구성과 기능 서비스 유형별(TOS) 코드

IP 패킷 구성과 기능(2) 전체길이(total length) 데이터그램 식별자(identification) 플래그(flag) 패킷 분할(fragmentation)시 이 영역 값을 참조하면, 어느 원본 데이터 그램으로부터 분할되었는지를 구분 가능 플래그(flag) 전송되는 패킷이 분할된 패킷인지 아닌지 여부에 대한 정보를 나타냄 패킷분할 옵셋(fragmentation offset) 8바이트 단위로, 분할된 패킷의 일부분을 나타냄 존재시간 영역(Time To Live) 라우터를 지날 때마다 TTL 값을 하나씩 감소시킴 만일 TTL의 값이 ‘0’으로 설정된 패킷을 라우터가 받게 된다면 그 패킷을 폐기함  이렇게 폐기된 패킷을 수신하게 되면 전송 측에 패킷이 폐기되었다는 오류 메시지 전송

IP 패킷 구성과 기능(3) 프로토콜(protocol) 헤더 체크섬(header checksum) 프로토콜 영역의 값에 따라 해당하는 상위계층 프로토콜의 예  [표 9-2] 만일 이 영역의 값이 6이라면, 서비스를 사용하는 상위계층 프로토콜이 TCP라는 의미 헤더 체크섬(header checksum) 네트워크를 통해 패킷이 전송될 때 발생한 오류를 검출하기 위해 사용 1에 대한 보수(complement) 연산을 수행함 전송 측(source)과 목적지(destination) 주소 영역 패킷을 전송하는 호스트의 주소와 패킷을 수신하는 호스트의 주소를 나타내는 영역 32비트로 구성

9. 1 IP 패킷 구성과 기능 IP 패킷 구성 예제(1)

9. 1 IP 패킷 구성과 기능 IP 패킷 구성 예제(2)

9. 2 IP(IPv4) 주소체계 IP 주소의 표현 IP(IPv4) 데이터그램은 전송 측과 목적지 주소 영역이 각각 32비트로 구성되고, IPv6인 경우 128비트 영역으로 확장됨 IPv4는 기본적으로 클래스(class)로 구분되는 주소체계를 취함 심볼화된 이름, 즉 ‘도메인 이름’을 사용함 응용 프로그램에서 사용자가 심볼화된 주소를 입력하면, 이 주소는 이진수 형태의 주소로 변환되고 이 변환된 결과가 메모리에 저장됨 이진 형태의 주소 표현을 사용하면, 심볼화된 이름을 사용하는 것보다 시스템의 메모리 사용이 줄어들어 네트워크를 통한 데이터 전송시간을 줄일 수 있음 호스트 컴퓨터 A는 IP 주소체계를 이용해서 호스트 컴퓨터 B로 데이터 패킷을 전송  [그림 9-5] 호스트 A는 호스트 B가 지리적으로 어느 곳에 위치하는지 알 필요가 없으며, 다만 인터넷 프로토콜 주소체계에 따라 패킷의 경로를 결정하면 됨 IP 주소가 네트워크 내에서 유일한 식별자의 역할

IP 주소의 표현 – ‘dotted-decimal notation’ 9. 2 IP(IPv4) 주소체계 IP 주소의 표현 – ‘dotted-decimal notation’ 네트워크상에서 데이터통신을 위해서는 반드시 고유한 IP 주소가 필요함 IP 주소는 32비트체계(XXX.XXX.XXX.XXX)로 이루어져 있으며, 이는 네트워크의 규모에 따라 주소체계를 선택할 수 있도록 클래스로 구분되어 있음 이진수 32비트로 이루어진 IP주소는 8비트 4개의 영역으로 구분하여 10진수로 표현함  ‘점으로 구분된 십진표기법(dotted-decimal notation)’ ([그림 9-6])

IP 주소 표현 예제

IP 주소의 클래스 클래스의 종류 : A 클래스, B 클래스, C 클래스, D 클래스, E 클래스가 있음  [그림 9-7] 9. 2 IP(IPv4) 주소체계 IP 주소의 클래스 클래스의 종류 : A 클래스, B 클래스, C 클래스, D 클래스, E 클래스가 있음  [그림 9-7] 앞의 4비트로 식별  0이면 A 클래스가 되고, 10이면 B 클래스, 110이면 C 클래스, 1110이면 D 클래스, 1111이면 E 클래스가 됨 총 가능한 IP 주소 중 50%가 A 클래스에, 25%는 B 클래스에, 12.5%는 C 클래스에 할당되고, D 클래스와 E 클래스에는 각각 6.25%씩 할당

9. 2 IP(IPv4) 주소체계 클래스별 구성 각 클래스는 ‘ IP 네트워크 주소(또는 네트워크 IDNetid)’와 ‘ IP 호스트 주소(호스트 ID Hostid)’의 조합으로 구성 IP 네트워크 ID : 네트워크의 식별을 위한 것 IP 호스트 ID : 네트워크의 호스트 컴퓨터를 식별하기 위한 것  ([그림 9-8])

9. 2 IP(IPv4) 주소체계 IP 주소의 클래스 A 클래스의 주소체계 B 클래스의 주소체계 C 클래스의 주소체계

서브넷이란 무엇인가 서브넷(subnet) 서브넷팅(subnetting) 9. 3 서브넷 기법 서브넷이란 무엇인가 서브넷(subnet) 하나의 IP 네트워크 주소를 네트워크 내부에서 적절히 분할하여, 실제로는 다수의 상호 연결된 하부 네트워크로 나누어 사용하는 방법  [그림 9-12] 서브넷팅(subnetting) 자신의 회사나 조직에 할당된 네트워크 ID의 IP 주소를 사용하여 내부적으로 여러 개의 서브넷을 구성하는 과정

서브넷을 사용하는 이유 네트워크 크기(domain size)를 감소시키기 위해 네트워크의 관리와 유지보수를 용이하게 하기 위해 9. 3 서브넷 기법 서브넷을 사용하는 이유 네트워크 크기(domain size)를 감소시키기 위해  네트워크 관리자는 적절한 크기로 네트워크를 분할함으로써 효율을 극대화 할 수 있음 네트워크의 관리와 유지보수를 용이하게 하기 위해 트래픽의 혼잡(congestion)을 줄이고, 자신이 속한 네트워크를 구조와 상황에 맞도록 분할함으로써 어떤 회사나 기관에서 서로 다른 LAN 기술을 수용할 수 있도록 구성하기 위해 전기적 신호 혹은 광신호의 특성에 따라 연결할 수 있는 호스트 수와 케이블의 길이에도 제한과 함께, 연결해야 하는 호스트 수가 많아지면 네트워크를 여러 그룹으로 분리할 필요성 때문 관리의 유용성을 증대  트래픽에 따른 영역의 분리가 가능하도록 하여 점대점(point to point) 링크를 사용할 수 있도록 구성하기 위해

서브넷의 크기 먼저 필요한 서브넷의 크기가 결정되면, 이에 따라 필요한 비트수를 계산해야 함 사용 예  [그림 9-13] 9. 3 서브넷 기법 서브넷의 크기 먼저 필요한 서브넷의 크기가 결정되면, 이에 따라 필요한 비트수를 계산해야 함 사용 예  [그림 9-13] 우측의 8비트 중에서 좌측의 3비트를 서브넷 영역으로 전환하여 사용하고 있음을 나타냄 3개의 비트를 서브넷 영역으로 사용하면 6개의 서브넷 구성이 가능해짐

서브넷 마스크(1) 서브넷 마스크(subnet mask)는 하나의 IP 네트워크 주소를 다시 여러 IP 서브 네트워크로 9. 3 서브넷 기법 서브넷 마스크(1) 서브넷 마스크(subnet mask)는 하나의 IP 네트워크 주소를 다시 여러 IP 서브 네트워크로 분할하는 기능을 수행 IP 네트워크 ID 주소부를 나타내는 영역을 IP호스트 주소 영역까지 확장하여, 하나의 IP 네트워크 주소를 또 다른 여러 개의 IP 네트워크 주소 생성 서브넷으로 구분하지 않는 IP 네트워크 주소에 대한 네트워크 마스크는 모든 네트워크를 나타내는 영역의 비트(네트워크 비트)를 1로 설정하고, 모든 호스트를 나타내는 영역의 비트(호스트 비트)를 0으로 설정 IP 주소의 3가지 클래스에 대한 네트워크 마스크

서브넷 마스크(2) 서브넷에서는 하나 혹은 그 이상의 사용 가능한 호스트 비트를 차용하여 네트워크 ID에 9. 3 서브넷 기법 서브넷 마스크(2) 서브넷에서는 하나 혹은 그 이상의 사용 가능한 호스트 비트를 차용하여 네트워크 ID에 포함시키고, 차용된 비트를 네트워크의 일부로 해석하도록 함 네트위크 주소를 두 개의 서브넷으로 구분하기 위해서는 첫 번째 호스트의 네트워크 마스크 비트에서 적절한 비트를 1로 지정하여 한 개의 호스트 비트를 차용함 C 클래스 네트워크 주소인 ‘192.168.1.0’에 대해 몇 개의 서브넷 옵션을 지정  표[9-3]

IP 주소 경제성 비교표 서브넷 마스크 사용 시 주의사항 9. 3 서브넷 기법 IP 주소 경제성 비교표 IP 주소의 경제성 비교표 : 클래스 C에서 몇 개의 서브넷 영역을 차용했을 경우에 사용되거나 낭비되는 주소를 정리한 도표  [표 9-4] 네트워크를 효율적으로 나누기 위해 서브넷을 이용하는 것은 유용하지만, 반면에 다수의 IP 주소(네트워크 ID, 브로드캐스트 주소 등)가 낭비됨 [표 9-4]의 첫째 줄은 2개의 서브넷 영역을 추가 지정한 경우를 나타낸 것 서브넷 마스크 사용 시 주의사항 서브넷 마스크는 전체가 1 또는 0인 경우가 아니라면, 서브넷 마스크의 결정 방법에 관한 특별한 규칙은 없음 사용할 서브넷과 그 체계의 결정은 지역(local) 사이트에 일임 32비트 모두를 서브넷 정의에 사용할 수는 있지만, 4비트나 8비트를 단위로 하여 서브넷 마스크를 할당하도록 권고

9. 3 서브넷 기법 서브넷 기법의 예제(1)

9. 3 서브넷 기법 서브넷 기법의 예제(2)

9. 3 서브넷 기법 서브넷 기법의 예제(3)

9. 3 서브넷 기법 서브넷 기법의 예제(4)

DNS: services, structure hostname to IP address translation host aliasing canonical, alias names mail server aliasing load distribution replicated Web servers: many IP addresses correspond to one name why not centralize DNS? single point of failure traffic volume distant centralized database maintenance A: doesn’t scale! Application Layer

DNS: a distributed, hierarchical database Root DNS Servers com DNS servers org DNS servers edu DNS servers poly.edu DNS servers umass.edu yahoo.com amazon.com pbs.org … … client wants IP for www.amazon.com; 1st approx: client queries root server to find com DNS server client queries .com DNS server to get amazon.com DNS server client queries amazon.com DNS server to get IP address for www.amazon.com Application Layer

DNS: root name servers contacted by local name server that can not resolve name root name server: contacts authoritative name server if name mapping not known gets mapping returns mapping to local name server c. Cogent, Herndon, VA (5 other sites) d. U Maryland College Park, MD h. ARL Aberdeen, MD j. Verisign, Dulles VA (69 other sites ) k. RIPE London (17 other sites) i. Netnod, Stockholm (37 other sites) e. NASA Mt View, CA f. Internet Software C. Palo Alto, CA (and 48 other sites) m. WIDE Tokyo (5 other sites) 13 root name “servers” worldwide a. Verisign, Los Angeles CA (5 other sites) b. USC-ISI Marina del Rey, CA l. ICANN Los Angeles, CA (41 other sites) g. US DoD Columbus, OH (5 other sites) Application Layer

TLD, authoritative servers top-level domain (TLD) servers: responsible for com, org, net, edu, aero, jobs, museums, and all top-level country domains, e.g.: uk, fr, ca, jp Network Solutions maintains servers for .com TLD Educause for .edu TLD authoritative DNS servers: organization’s own DNS server(s), providing authoritative hostname to IP mappings for organization’s named hosts can be maintained by organization or service provider Application Layer

Local DNS name server does not strictly belong to hierarchy each ISP (residential ISP, company, university) has one also called “default name server” when host makes DNS query, query is sent to its local DNS server has local cache of recent name-to-address translation pairs (but may be out of date!) acts as proxy, forwards query into hierarchy Application Layer

DNS name resolution example root DNS server 2 host at cis.poly.edu wants IP address for gaia.cs.umass.edu 3 TLD DNS server 4 5 iterated query: contacted server replies with name of server to contact “I don’t know this name, but ask this server” local DNS server dns.poly.edu 7 6 1 8 authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu Application Layer

authoritative DNS server DNS name resolution example root DNS server 2 3 recursive query: puts burden of name resolution on contacted name server heavy load at upper levels of hierarchy? 7 6 TLD DNS server local DNS server dns.poly.edu 4 5 1 8 authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu Application Layer

DNS: caching, updating records once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time (TTL) TLD servers typically cached in local name servers thus root name servers not often visited cached entries may be out-of-date (best effort name-to-address translation!) if name host changes IP address, may not be known Internet-wide until all TTLs expire update/notify mechanisms proposed IETF standard RFC 2136 Application Layer

RR format: (name, value, type, ttl) DNS records DNS: distributed db storing resource records (RR) RR format: (name, value, type, ttl) type=A name is hostname value is IP address type=CNAME name is alias name for some “canonical” (the real) name www.ibm.com is really servereast.backup2.ibm.com value is canonical name type=NS name is domain (e.g., foo.com) value is hostname of authoritative name server for this domain type=MX value is name of mailserver associated with name Application Layer

DNS protocol, messages query and reply messages, both with same message format 2 bytes 2 bytes identification flags # questions questions (variable # of questions) # additional RRs # authority RRs # answer RRs answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs) msg header identification: 16 bit # for query, reply to query uses same # flags: query or reply recursion desired recursion available reply is authoritative Application Layer

DNS protocol, messages name, type fields for a query RRs in response 2 bytes 2 bytes identification flags # questions questions (variable # of questions) # additional RRs # authority RRs # answer RRs answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs) name, type fields for a query RRs in response to query records for authoritative servers additional “helpful” info that may be used Application Layer

Q & A