참조모델·캡슐화·Ethernet·IPv6 전달 경계

신호·매체·패킷·프레임과 프로토콜·계층·주소·이름·경로에서 링크와 여러 네트워크의 차이를 확인한다. 이 절에서는 계층별 포장과 라우터 전달 네 단계를 실제 길이·주소 값에 연결한다.

0. 한 번의 웹 요청 안에는 여러 배송이 겹쳐 있다

브라우저에서 주소를 입력하고 응답을 받는 일은 겉으로는 한 번의 통신이다. 그러나 실제로는 응용 메시지를 프로그램 사이에 전달하는 대화, 여러 네트워크를 건너 목적지를 찾는 전달, 현재 링크를 통과하는 전달이 포개져 있다. 각 층은 자기 책임에 필요한 제어정보를 붙이고, 받은 쪽은 그 정보를 해석해 다음 층으로 넘긴다.

이 경계를 모르면 패킷 캡처에 보이는 주소와 숫자를 외워도 원인을 찾기 어렵다. 링크 주소가 바뀌는 정상 동작을 네트워크 주소 변조로 오해하거나, 응용 오류를 케이블 문제처럼 다룰 수 있기 때문이다. 이 절에서는 제품 명령보다 누가 어떤 범위까지 전달하며, 어느 제어정보가 어디에서 바뀌는가를 배운다.

여기서 만드는 참조모델·캡슐화·전달경계는 프로토콜 분석과 패킷·로그·지표 분석을 가능하게 하는 공통이론이다.

뒤의 두 분석으로 건너가는 공통 관점

앞 절에서 배운 프로토콜은 통신 참여자가 지킬 메시지 형식·의미·순서·시간·오류 처리 규칙의 합의이고, 네트워크 계층화는 그 많은 통신 책임을 층별 계약으로 나누는 구조다. 앞의 프로토콜·계층·주소·이름·경로에서 두 개념을 배웠으며, 이 절에서는 전달경계를 읽는 데 필요한 만큼 되짚는다.

프로토콜 분석에서는 계층별 메시지 필드, 대화 상태와 시간관계를 읽어 규칙대로 동작했는지 판단한다. 네트워크 진단에서는 패킷·로그·지표를 구간과 시간축에 맞춰 지연·손실·혼잡과 전달 실패의 위치·원인을 좁힌다. 앞쪽은 규칙과 대화, 뒤쪽은 서비스 경로와 원인범위에 무게를 두지만 실제 장애에서는 서로의 증거를 함께 쓴다. 각 분석의 정식 정의는 해당 절에서 처음 제시한다.

분석은 패킷 한 줄의 해석으로 끝나지 않는다. 같은 숫자도 어느 계층의 어느 방향인지, 앞뒤 메시지와 어떤 상태를 이루는지, 어느 지점에서 몇 시에 수집했는지를 알아야 의미가 생긴다.

전체에서 어디인가: 종단 대화와 구간 배송을 분리한다

응용 메시지는 송신 프로그램과 수신 프로그램의 대화를 이룬다. 전송 PDU는 프로그램 사이의 논리 대화를, IPv6 패킷은 라우터들이 여러 링크를 이어 주는 전달을 표현한다. 실제 전송은 Ethernet 링크와 라우터의 경계를 거치며 각 링크의 프레임과 신호·매체를 사용한다. 종단 사이의 논리 관계가 중간 장치를 물리적으로 건너뛴다는 뜻은 아니다. 상위 PDU가 하위 데이터 안에 들어가는 포함관계를 함께 읽는다.

논리 대화라는 말은 전송 PDU가 중간장치를 물리적으로 건너뛴다는 뜻이 아니다. 실제 바이트는 아래 계층과 장치를 모두 지난다. 다만 같은 계층의 양 끝이 그 계층의 규칙과 제어정보를 상대와의 대화로 해석한다는 뜻이다. 라우터 경계에서는 들어온 Ethernet 프레임을 처리한 뒤 IPv6 패킷을 다음 링크의 새 프레임에 넣는다.

그림의 PDU는 프로토콜 데이터 단위(Protocol Data Unit)의 약자이며, 같은 계층끼리 해석하는 제어정보와 데이터 묶음이라는 뜻이다. 정식 정의와 포함관계는 2절에서 설명한다.

먼저 알아둘 것

인터페이스는 인접 요소가 주고받을 입력·출력·오류의 약속이고, 네트워크 계층화는 책임과 인터페이스를 따라 복잡성을 여러 계층으로 나눈다. 이름은 사람이 의미 있게 부르는 식별자, 주소는 전달체계가 접점을 구별하는 값, 경로는 목적지까지 거칠 링크와 장치의 연속이며, 패킷은 여러 링크를 잇는 네트워크 계층 단위이고 프레임은 현재 링크를 건너는 링크 계층 단위다. 낯선 선수개념은 앞의 신호·매체·패킷·프레임과 프로토콜·계층·주소·이름·경로에서 다시 읽는다.

1. 참조모델: 통신 책임을 놓을 공통 좌표

네트워크 참조모델은 통신 기능을 책임별 계층과 계층 사이 서비스로 나누어 설명하는 개념 지도다. 실제 패킷에 제4계층이라는 꼬리표가 붙어 이동하는 것이 아니라, 설계자와 분석자가 같은 책임 경계를 가리키게 하는 모델이다.

국제전기통신연합 전기통신표준화부문(ITU-T)의 X.200이 정의하는 개방형 시스템 상호연결(Open Systems Interconnection, OSI) 기본 참조모델은 응용·표현·세션·전송·네트워크·데이터링크·물리의 일곱 계층을 둔다. 인터넷 호스트 요구사항인 RFC 1122는 인터넷 프로토콜 집합을 응용·전송·인터넷·링크의 네 계층으로 설명한다. 이 책에서는 이를 OSI 참조모델과 TCP/IP 계층모형이라고 부른다.

참조모델은 세 가지 질문에 답한다. 이 기능의 책임은 어디인가, 인접 계층에 무엇을 제공하는가, 같은 계층의 상대와 어떤 프로토콜을 사용하는가다. 제품 기능을 억지로 한 칸에 넣기보다 이 질문으로 경계를 설명해야 한다.

계층·서비스·프로토콜은 서로 다른 방향의 관계다

계층은 비슷한 통신 책임을 묶은 논리적 범위이고, 서비스는 한 계층이 바로 위 계층에 제공하는 기능이며, 프로토콜은 서로 다른 시스템의 같은 계층 주체가 그 책임을 수행하기 위해 따르는 규칙이다. 서비스는 위아래의 사용관계이고 프로토콜은 양 끝의 논리적 대화관계다. 인터페이스는 한 시스템 안에서 인접 계층이 서비스를 요청하고 결과를 받는 경계다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

가로 점선은 같은 계층의 peer가 따르는 프로토콜 관계이며 물리적 직통 전송선이 아니다. 세로 화살표는 n−1 계층이 인접 인터페이스를 통해 n 계층에 제공하는 서비스다. 두 방향은 책임의 관계이지 동일한 패킷의 이동 경로가 아니다.

같은 계층끼리 논리적으로 대화하더라도 실제 데이터는 아래 계층 서비스를 거쳐 이동한다. 답안에서 서비스=프로토콜이라고 합치면 상하 책임과 대등한 통신 규칙이 뒤섞인다.

OSI와 TCP/IP: 층 수를 외우기보다 책임을 대응한다

이 표는 개념 대응이지 계층의 완전한 일대일 변환표가 아니다. OSI의 표현·세션 책임이 사라진 것이 아니라 인터넷 구현에서는 응용 프로토콜이나 라이브러리로 배치될 수 있다. TCP/IP라는 이름도 TCP와 IP 두 개만 있다는 뜻이 아니라 인터넷에서 함께 쓰는 프로토콜 집합을 가리킨다.

시험에서는 7 대 4만 쓰지 않는다. OSI는 통신 책임과 서비스·프로토콜 관계를 설명하는 일반 참조모델이고, TCP/IP 모형은 인터넷 프로토콜 집합의 실제 배치에 가까운 묶음이라는 차이, 그리고 각 층의 PDU와 분석 증거를 연결한다.

2. 네트워크 캡슐화와 PDU: 위층 데이터를 아래층 단위에 넣는다

네트워크 캡슐화(network encapsulation)는 상위 계층의 데이터 단위를 하위 계층의 사용자 데이터로 넣고, 하위 계층이 자기 책임에 필요한 제어정보를 더하는 과정이다. 객체지향의 정보은닉을 뜻하는 캡슐화와 동음이의어이므로 답안에는 반드시 네트워크 계층별 포장이라는 뜻을 밝힌다.

프로토콜 데이터 단위(Protocol Data Unit, PDU)는 같은 계층의 프로토콜 주체가 규칙에 따라 주고받는 제어정보와 사용자 데이터의 단위다. PDU의 이름은 문헌과 계층에 따라 메시지·세그먼트·데이터그램·패킷·프레임 등으로 달라진다. 중요한 것은 이름 암기가 아니라 어느 계층의 어떤 제어정보를 가진 단위인가다.

수신 측에서는 프레임의 제어정보를 검사·제거하고 그 안의 네트워크 PDU를 위로 넘기는 역캡슐화가 일어난다. 제거한다는 말은 무조건 버린다는 뜻이 아니다. 오류검사·주소·프로토콜 종류를 해석하고 그 결과에 따라 전달·폐기한 뒤 위층 PDU를 넘긴다.

송신→라우터→수신: 바깥 포장은 구간마다 바뀐다

넓은 화면과 모바일에서 같은 관계를 각각의 배치로 읽을 수 있습니다.

네 수준의 포함관계다. 송신자는 전송·IPv6·현재 링크의 제어정보를 더하고 수신자는 링크→IPv6→전송→응용으로 해석한다. 라우터는 입력 Ethernet 프레임을 처리·제거하고 IPv6 Hop Limit과 다음 전달을 결정한 뒤 다음 링크의 새 머리와 FCS를 붙인다. 링의 면적은 바이트 길이에 비례하지 않는다.

라우터는 들어온 링크 프레임 전체를 그대로 다음 링크로 복사하지 않는다. 현재 링크의 수신자로서 프레임을 처리하고, IPv6 패킷의 전달정보를 확인해 다음 링크에 맞게 다시 캡슐화한다. 이때 IPv6의 Hop Limit처럼 라우터가 처리하는 필드는 변한다. 반면 응용 메시지의 의미는 종단의 해당 응용 프로토콜이 해석한다.

암호화가 적용되면 포착 지점과 키 보유 여부에 따라 상위 내용이 보이지 않을 수 있다. 보이지 않는다고 상위 PDU가 없는 것은 아니며, 아래층의 주소·길이·방향·시간만으로 확인할 수 있는 사실과 해독이 필요한 사실을 나눠야 한다.

기본 머리 바로 뒤가 항상 TCP·UDP인 것은 아니다. 위 포함관계 그림은 IPv6 확장 머리가 없는 경우를 단순화한 것이다. 확장 머리가 있다면 IPv6 기본 머리의 Next Header는 먼저 그 확장 머리를 가리키고, 그 머리의 Next Header가 다음 머리를 잇는다. 전송 PDU를 온전히 담은 이 절의 분할되지 않은 패킷에서는 IPv6 Payload Length = 확장 머리들의 길이 합 + 전송 PDU 길이로 계산한다. 따라서 아래의 TCP 머리 + 데이터 계산은 명시된 ‘확장 머리 없음’ 조건에서 사용한다. IPv6 기본 머리 40옥텟은 Payload Length에 포함하지 않는다. 확장 머리별 처리 절차를 새로 외우기보다, 먼저 선언된 순서와 각각의 길이를 확인한다.

PDU를 보면 네 질문부터 적는다

무엇이 보이는가와 무엇을 단정할 수 있는가를 분리하면 과잉추론을 줄일 수 있다. 한 지점의 프레임만 보고 반대편 호스트가 받았다고 단정할 수 없고, HTTP 성공 응답 하나만 보고 모든 네트워크 구간이 여유롭다고 단정할 수도 없다.

3. Ethernet 전달: 현재 링크의 프레임을 책임진다

Ethernet은 IEEE 802.3 계열이 규정하는 링크·물리 계층 기술이며, 여기서 Ethernet 전달은 현재 Ethernet 링크에서 MAC 프레임을 송수신하는 책임을 뜻한다. MAC 주소(Media Access Control address)는 이 링크 전달에서 송신자와 수신 접점을 식별하는 값이다. 보안 분야의 강제적 접근통제(Mandatory Access Control, MAC)와 약어가 같으므로 답안에서는 MAC 주소라고 쓴다.

이 교재가 분석에 사용하는 MAC 프레임의 핵심은 목적지 주소, 출발지 주소, 길이/유형, 상위 데이터와 필요한 채움, 프레임 검사 순서(Frame Check Sequence, FCS)다. 실제 포착에서는 네트워크 인터페이스와 드라이버가 일부 정보를 처리한 뒤 분석기에 넘길 수 있어 프리앰블이나 FCS가 보이지 않을 수 있다. 안 보임을 곧 전송되지 않음으로 판단하지 않는다.

반송파 감지 다중접속/충돌검출(Carrier Sense Multiple Access with Collision Detection, CSMA/CD)은 여러 장치가 공유하는 반이중 Ethernet에서 매체 사용을 감지하고 충돌을 검출해 재시도하는 접근제어다. 송수신 경로가 분리된 교환기 기반 전이중 Ethernet에서는 이를 평상시 충돌제어로 설명하지 않는다. Wi-Fi의 CSMA/CA와 같은 기술로 쓰지도 않는다.

Ethernet 프레임은 누구에게·누가·무엇을·온전하게로 읽는다

필드의 순서·역할을 비교하는 표이며, 열 너비로 필드 길이를 표현하지 않는다.

목적 MAC은 현재 링크에서 받아야 할 접점을, 출발 MAC은 이 프레임을 보낸 접점을 나타낸다. 길이/유형 필드는 해석 방식에 따라 데이터 길이나 상위 프로토콜 종류를 구별하는 데 쓰인다. FCS는 수신 프레임의 비트 오류를 검출하는 데 도움을 주지만 잃어버린 프레임을 복원하거나 종단 응용 성공을 보장하지 않는다.

분석기는 필드를 사람이 읽기 좋은 이름으로 해석하지만 원래 바이트와 해석값을 구분해야 한다. 잘못된 캡처 오프로딩 표시, 잘린 캡처 길이, 분석기 버전의 디코딩 차이가 있을 수 있으므로 이상한 값은 다른 지점·원시 바이트·인터페이스 통계와 대조한다.

같은 링크와 다른 네트워크: 목적 MAC의 상대가 달라진다

송신 호스트가 목적지를 현재 링크에서 직접 전달할 대상으로 판단하면 그 대상의 링크 주소를 사용한다. 다른 네트워크로 보내야 한다면 IPv6의 최종 목적지 주소는 원격 호스트를 가리키되, 현재 Ethernet 프레임의 목적 MAC은 다음 전달을 맡을 라우터 접점을 가리킨다. 여기서는 필요한 링크 주소가 이미 안전하게 해석되었다고 가정하며, 구체적인 이웃 탐색 절차는 별도 네트워크 프로토콜 절에서 다룬다.

링크 주소는 바뀌고 종단 대화는 이어진다 · 상태 따라가기

라우터가 현재 링크 프레임 안의 IPv6 패킷을 받는다. 모든 단계에서 IP 패킷·링크 프레임의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

아래 실제 두 지점 예의 NAT·터널·분할·오프로딩 없음 조건을 따른다. 첫 목적 MAC은 R의 입력 접점이고 출력 링크의 MAC은 새로 구성한다. IPv6 목적지는 B로 유지하고 Hop Limit은 64→63이다. 라우터는 Next Header·선언 길이·목적지와 다음 전달을 검사한다. Hop Limit이 이미 1 이하이면 정상 출력 대신 폐기하며, 단독 MAC·HL 값으로 원인을 확정하지 않는다.

이 예의 조건

• 아래 실제 두 지점 예의 NAT·터널·분할·오프로딩 없음 조건을 따른다. 첫 목적 MAC은 R의 입력 접점이고 출력 링크의 MAC은 새로 구성한다. IPv6 목적지는 B로 유지하고 Hop Limit은 64→63이다. 라우터는 Next Header·선언 길이·목적지와 다음 전달을 검사한다. Hop Limit이 이미 1 이하이면 정상 출력 대신 폐기하며, 단독 MAC·HL 값으로 원인을 확정하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상Host A	원 설명MAC A→R 입력 IPv6 A→B Hop Limit 64
대상라우터 R	원 설명입력 프레임 처리·제거 IPv6 머리·경로 검사 Hop Limit 감소
대상Host B 쪽	원 설명MAC R 출력→B IPv6 A→B Hop Limit 63

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결Host A → 라우터 R	원 라벨·방향첫 링크 / 정방향 / 실선
연결라우터 R → Host B 쪽	원 라벨·방향다음 링크 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
수신 링크 라우터가 현재 링크 프레임 안의 IPv6 패킷을 받는다.	값·보충 정보 IP 패킷: 목적지 B·HL 64 링크 프레임: 수신 프레임	변화·이유 목적지 IP와 링크 MAC의 역할은 다르다.
프레임 제거·검사 현재 프레임을 제거하고 전달 조건을 확인한다.	값·보충 정보 IP 패킷: 동일 IP 패킷 링크 프레임: 옛 프레임 제거	변화·이유 라우터가 종단 목적지를 자기 주소로 바꾸지 않는다.
Hop Limit 감소 전달할 패킷의 Hop Limit을 64에서 63으로 바꾼다.	값·보충 정보 IP 패킷: 목적지 B·HL 63 링크 프레임: 다음 링크 준비	변화·이유 같은 패킷의 루프 제한 상태가 바뀐다.
새 프레임 전달 다음 링크의 MAC을 사용해 새 프레임을 만든다.	값·보충 정보 IP 패킷: 목적지 B 유지 링크 프레임: 새 링크 MAC	변화·이유 링크가 바뀌어도 종단 목적지 B를 유지한다.

링크 주소는 바뀌고 종단 대화는 이어진다 · 상태 따라가기

라우터가 현재 링크 프레임 안의 IPv6 패킷을 받는다. 모든 단계에서 IP 패킷·링크 프레임의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

아래 실제 두 지점 예의 NAT·터널·분할·오프로딩 없음 조건을 따른다. 첫 목적 MAC은 R의 입력 접점이고 출력 링크의 MAC은 새로 구성한다. IPv6 목적지는 B로 유지하고 Hop Limit은 64→63이다. 라우터는 Next Header·선언 길이·목적지와 다음 전달을 검사한다. Hop Limit이 이미 1 이하이면 정상 출력 대신 폐기하며, 단독 MAC·HL 값으로 원인을 확정하지 않는다.

이 예의 조건

• 아래 실제 두 지점 예의 NAT·터널·분할·오프로딩 없음 조건을 따른다. 첫 목적 MAC은 R의 입력 접점이고 출력 링크의 MAC은 새로 구성한다. IPv6 목적지는 B로 유지하고 Hop Limit은 64→63이다. 라우터는 Next Header·선언 길이·목적지와 다음 전달을 검사한다. Hop Limit이 이미 1 이하이면 정상 출력 대신 폐기하며, 단독 MAC·HL 값으로 원인을 확정하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상Host A	원 설명MAC A→R 입력 IPv6 A→B Hop Limit 64
대상라우터 R	원 설명입력 프레임 처리·제거 IPv6 머리·경로 검사 Hop Limit 감소
대상Host B 쪽	원 설명MAC R 출력→B IPv6 A→B Hop Limit 63

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결Host A → 라우터 R	원 라벨·방향첫 링크 / 정방향 / 실선
연결라우터 R → Host B 쪽	원 라벨·방향다음 링크 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
수신 링크 라우터가 현재 링크 프레임 안의 IPv6 패킷을 받는다.	값·보충 정보 IP 패킷: 목적지 B·HL 64 링크 프레임: 수신 프레임	변화·이유 목적지 IP와 링크 MAC의 역할은 다르다.
프레임 제거·검사 현재 프레임을 제거하고 전달 조건을 확인한다.	값·보충 정보 IP 패킷: 동일 IP 패킷 링크 프레임: 옛 프레임 제거	변화·이유 라우터가 종단 목적지를 자기 주소로 바꾸지 않는다.
Hop Limit 감소 전달할 패킷의 Hop Limit을 64에서 63으로 바꾼다.	값·보충 정보 IP 패킷: 목적지 B·HL 63 링크 프레임: 다음 링크 준비	변화·이유 같은 패킷의 루프 제한 상태가 바뀐다.
새 프레임 전달 다음 링크의 MAC을 사용해 새 프레임을 만든다.	값·보충 정보 IP 패킷: 목적지 B 유지 링크 프레임: 새 링크 MAC	변화·이유 링크가 바뀌어도 종단 목적지 B를 유지한다.

따라서 MAC 주소가 경로 중 바뀐다와 IPv6 목적지가 바뀐다는 같은 말이 아니다. 링크의 포장은 구간마다 새로 만들어지고, 네트워크 계층은 여러 링크를 이어 최종 목적지 쪽으로 전달한다.

4. IPv6 전달: 여러 링크를 잇는 패킷의 경계

인터넷 프로토콜 버전 6(Internet Protocol version 6, IPv6) 전달은 IPv6 패킷의 목적지 주소와 전달 상태를 바탕으로 호스트 또는 라우터가 다음 처리·전달을 결정하는 네트워크 계층 기능이다. IPv6의 기본 머리는 40옥텟이며 Version, Traffic Class, Flow Label, Payload Length, Next Header, Hop Limit, Source Address, Destination Address 필드를 가진다. 옥텟은 8비트 단위이며 바로 다음 표에서 각 필드의 의미를 풀어 쓴다.

Next Header는 다음 확장 머리 또는 TCP·UDP 같은 상위 프로토콜로 연결되는 사슬을 만든다. IANA 프로토콜 번호에서 TCP는 6, UDP는 17이며 이 값은 호스트 안의 프로그램 접점을 구별하는 TCP·UDP 포트 번호와 다른 식별축이다. IPv6 라우터는 경로 중 패킷을 분할하지 않고 필요한 분할은 송신 노드가 Fragment header를 사용해 수행한다.

Hop Limit은 패킷이 라우터를 지날 때마다 감소하는 전달 횟수 경계다. 라우터가 전달하면서 값을 1 줄이고, 전달 전 값이 1 이하라면 패킷을 폐기하므로 잘못된 경로 순환이 영원히 계속되는 것을 막는다. DNS 기록의 생존시간과 같은 TTL이라는 넓은 표현을 이 필드 이름으로 쓰지 않는다.

이 절은 IPv6 기본 머리, Next Header 연결과 송신자 분할 경계만 가르친다. IPv4 머리의 상세 비교, 확장 머리별 처리, 주소 자동설정과 이웃 탐색의 절차는 확보한 근거와 이 절의 설명 범위를 넘으므로 답안에 갑자기 추가하지 않는다. Hop-by-Hop 상세 처리는 RFC 9673 재검증 없이는 확대하지 않는다.

IPv6 기본 머리는 분류·길이·다음·수명·양 끝으로 읽는다

필드 하나만으로 결론 내리지 않는다. 같은 출발·목적지라도 시간과 Next Header가 다르면 다른 대화일 수 있고, Hop Limit 차이는 중간 라우터 수에 대한 단서이지 단독으로 정확한 물리 경로를 증명하는 값은 아니다.

라우터의 전달을 네 단계로 읽는다

1. 수신 링크 처리: 들어온 프레임의 수신 조건과 오류를 확인하고 IPv6 패킷을 꺼낸다.
2. 네트워크 머리 검사: 버전·길이·목적지·Hop Limit과 다음 머리 연결을 확인한다.
3. 다음 전달 결정: 목적지와 경로정보·정책을 바탕으로 출력 접점과 다음 전달 대상을 고른다.
4. 새 링크 캡슐화: Hop Limit을 처리한 IPv6 패킷을 출력 링크의 프레임에 넣어 보낸다.

경로 선택 규칙 자체는 네트워크 설계 절에서 배운다. 여기서는 캡처를 읽을 때 들어온 링크 프레임과 나가는 링크 프레임이 다르고, 그 사이에서 IPv6 전달 판단이 일어난다는 경계만 확정한다.

주소처럼 보이는 값의 책임범위를 구분한다

물리 주소라는 전통적 표현을 MAC 주소의 영구적·물리적 신원으로 과장하지 않는다. 시험에서는 이름→네트워크 주소→현재 링크 주소→포트의 역할과 변환·사용 시점을 그리되, 각 값의 범위가 다르다는 결론을 붙인다.

두 지점의 패킷을 비교해 정상 변화와 이상을 나눈다

예시

호스트 쪽 포착에서 IPv6 출발·목적지 A→B, Hop Limit 64인 패킷을 보았고, 한 라우터 뒤 포착에서 같은 대화의 A→B, Hop Limit 63인 패킷을 보았다고 하자. 두 지점의 Ethernet 출발·목적 MAC은 서로 다르다.

이는 곧바로 변조가 아니다. Hop Limit 1 감소와 링크 프레임 교체는 라우터 전달경계와 맞는다. 반대로 두 번째 지점에 대응 패킷이 전혀 없고 라우터 수신 통계에는 입력만 있다면, 수신 링크 처리·IPv6 머리 검사·경로 결정·출력 링크 중 어디에서 멈췄는지 추가 증거를 모은다. 같은 대화인지는 주소만이 아니라 Next Header, 길이, 전송 식별정보와 시간을 함께 맞춘다.

이 예시의 핵심은 값을 외우는 것이 아니라 변해야 하는 필드, 유지되어야 하는 대화, 관측만으로 아직 모르는 것을 세 칸으로 나누는 습관이다.

주소·포트가 같으면 같은 대화의 후보일 뿐 같은 패킷이라고 확정할 수는 없다. 다음은 NAT·터널·분할·오프로딩 없이 한 라우터를 통과한 TCP/IPv6 교육 예이며, 시간은 같은 기준으로 맞춘 값이다. TCP 머리 20바이트·데이터 100바이트, IPv6 확장 머리는 없다고 가정한다.

표의 seq는 이 예의 TCP 데이터 첫 바이트 순서번호다. [1001,1101)은 1001을 포함하고 1101은 포함하지 않는 범위여서 마지막 데이터 바이트는 1100, 개수는 1101−1001=100이다. 순서번호·확인번호의 정식 작동규칙은 프로토콜 분석에서 이어 배우고, 여기서는 데이터 범위와 계층별 길이를 읽는 데 사용한다.

첫 두 행은 방향·바이트 범위·길이·시간과 보이는 payload/옵션까지 대조할 대응 후보이며, 셋째 행은 같은 대화의 다음 데이터다. 길이 120에는 TCP 머리 20이 포함되고 IPv6 전체 길이는 40+120=160이다. VLAN 없는 Ethernet에서 FCS를 제외한 포착 길이는 14+160=174가 될 수 있다. 같은 seq·길이의 재전송이나 복제도 가능하므로 이 값들만으로 유일한 패킷 실체를 보장하지 않고 포착 누락·시간 오차·전송 순서를 함께 확인한다.

직접 풀어 보기 — 자체 조건 변경

독립적으로 확인해 보자. 셋째 행의 데이터만 60바이트로 줄이고 다른 가정을 유지할 때 데이터 범위, IPv6 Payload Length, IPv6 전체 길이, FCS 제외 Ethernet 포착 길이를 적어 보자.

길이 계산·오답 교정과 전달 경계

범위는 [1101,1161), Payload Length는 20+60=80, IPv6 전체는 40+80=120, 같은 14바이트 Ethernet 머리를 쓰는 포착은 14+120=134바이트다. Payload Length를 60으로 쓰는 오답은 TCP 머리를 빠뜨린 것이고, 120으로 쓰는 오답은 IPv6 기본 머리까지 넣은 것이다. 캡슐화 그림에서 각 머리가 어느 데이터 바깥에 붙는지 다시 확인한다. 별도로 입력 Hop Limit이 1이면 라우터가 전달 전에 폐기하므로 다음 링크에 HL 0인 정상 전달 프레임이 나올 것이라고 예상해서는 안 된다.

5. 실패조건과 분석 절차

계층표를 외워도 분석에 실패하는 경우

모델은 진단을 시작할 좌표이지 결론을 대신하는 규칙이 아니다. 각 관찰에는 포착지점·방향·시간·계층·필드를 붙이고, 단독 증거의 한계를 함께 적는다.

여덟 단계로 전달경계를 읽는다

1. 질문을 고정한다: 도달 실패, 지연, 내용 오류 중 무엇을 판단할지 쓴다.
2. 관찰점을 표시한다: 송신 전·후, 라우터 전·후, 수신 전·후와 방향을 그린다.
3. PDU 경계를 연다: Ethernet→IPv6→전송→응용 순으로 포함관계를 확인한다.
4. 길이와 종류를 검증한다: 선언 길이, 포착 길이, 다음 머리·상위 종류가 이어지는지 본다.
5. 식별범위를 맞춘다: MAC은 링크, IPv6는 네트워크, 포트는 프로그램 접점으로 구분한다.
6. 상태변화를 분류한다: 재캡슐화와 Hop Limit 감소처럼 정상 변화를 먼저 제외한다.
7. 앞뒤 증거를 연결한다: 먼저 대화 후보를 식별한 뒤, 시간·방향·주소·길이·TCP 바이트 범위와 관찰 가능한 내용으로 개별 전송의 대응을 좁힌다. 재전송·복제 때문에 같은 대화와 같은 순서범위도 유일한 패킷 식별자는 아니다.
8. 확인한 범위까지만 결론 내린다: 확인한 마지막 정상 지점, 최초 이상 지점, 아직 모르는 사실을 분리한다.

이 절차는 프로토콜 분석에서 메시지·상태 분석으로, 네트워크 진단에서 패킷·로그·지표 상관분석으로 확장된다.

배운 경계를 다음 분석에 연결한다

이 절의 참조모델·캡슐화·PDU·Ethernet·IPv6 전달경계는 다음의 프로토콜 분석과 네트워크 원인 진단을 읽는 기초다. 필드·상태의 기대 규칙과 관찰점의 정상 변화를 구별해 적용한다.

주소계획·라우팅 정책·이중화·서비스 품질 설계는 네트워크 설계와 통신시스템, 물리 신호와 프레임의 기초는 신호·매체·패킷·프레임, 프로토콜·계층·이름·주소·경로의 기초는 프로토콜·계층·주소·이름·경로에서 다시 읽는다. 이 장에서는 분석에 필요한 경계만 확장하고 같은 정의를 반복하지 않는다.

6. 기출 후보와 답안 전환

참조모델 기출은 계층 암기에서 전달경계로 확장한다

모든 연결은 AI 검토 후보이며 사람의 원문·배점·대표성 승인 수는 0이다. 실제 기출 문구를 모범답안으로 복제하지 않고 요구축만 재사용한다.

TOP-01090은 문항의 하위 요구까지 나누어 센다

자동 군집 TOP-01090은 OSI/TCP-IP 참조모델 군집으로 유지할 수 있지만 IM-0098-P04-Q06 전체를 넣어 반복성을 계산하면 안 된다. 이 문항의 요구 1 OSI 계층과 요구 2 OSI와 TCP/IP 비교만 전달경계의 직접 요구이고, 요구 3 subnetting·supernetting은 주소·라우팅 설계 담당인 네트워크 설계로 분리한다.

또한 IM-0098-P04-Q06은 이 절의 참조모델에는 direct지만 다음 절의 구체 프로토콜 분석에는 partial이다. 문항 전체나 군집 빈도로 장의 출제 반복성을 부풀리지 않고 requirement 단위로 센다.

시험에서는 어떻게 묻는가: 10점

다음은 본문을 답안으로 전환하기 위한 자체 제작 문제다.

OSI 참조모델과 TCP/IP 계층모형을 비교하고, PDU와 캡슐화가 분석에 주는 의미를 설명하시오.

층 수만 나열하지 말고 모델 목적→책임 대응→PDU 포함관계→분석 활용→한계로 압축한다. OSI와 TCP/IP를 완전히 일대일 대응시키지 않는 것이 핵심이다.

답안 목차·풀이·교정 근거 보기

10점 답안 목차

1. 정의·목적: 통신 책임과 계층 서비스를 설명하는 공통 좌표
2. 계층 대응: OSI 7계층과 TCP/IP 4계층의 책임 묶음
3. PDU·캡슐화: 상위 PDU를 하위 데이터로 넣고 제어정보 추가
4. 분석 활용: 링크 프레임→IPv6 패킷→전송→응용 상태 추적
5. 주의점: 완전 일대일 대응과 계층 이름 암기를 피함

10점 답안 도식

책임	OSI	TCP/IP	관찰 PDU
응용 의미	응용·표현·세션	응용	DNS/HTTP/TLS 메시지
종단 전달	전송	전송	TCP/UDP PDU
다중망 전달	네트워크	인터넷	IPv6 패킷
구간·신호	데이터링크·물리	링크	Ethernet 프레임

책임 묶음의 비교이며 완전한 일대일 변환은 아니다. 송신의 제어정보 추가와 수신의 역캡슐화는 PDU 포함관계 도식에서 설명한다.

10점 모범답안

네트워크 참조모델은 통신 기능을 책임별 계층과 인접 계층 서비스로 나누어 설계·분석의 공통 좌표를 제공한다. OSI는 응용·표현·세션·전송·네트워크·데이터링크·물리의 7계층이고, RFC 1122의 TCP/IP 모형은 응용·전송·인터넷·링크의 4계층이다. TCP/IP에서는 OSI 상위 세 계층의 책임이 주로 응용에, 하위 두 계층의 책임이 링크에 묶이지만 완전한 일대일 변환은 아니다.

PDU는 같은 계층 프로토콜이 해석하는 제어정보와 사용자 데이터의 단위다. 송신 측은 상위 PDU를 하위 계층 데이터로 넣고 하위 제어정보를 붙이며, 수신 측은 이를 검사해 역순으로 넘긴다. 따라서 분석은 Ethernet 프레임의 링크 주소, IPv6의 목적지·Hop Limit, TCP·UDP의 포트와 상태, 응용 메시지의 의미를 층별로 읽는다. 계층표만 외우지 말고 마지막 정상 계층과 최초 이상 계층을 증거로 경계 지어야 한다.

시험에서는 어떻게 묻는가: 25점

다음도 자체 제작 문제다.

IPv6 패킷이 서로 다른 Ethernet 링크를 거쳐 목적지에 도달하는 과정을 계층·PDU·주소 변화로 설명하고, 두 지점 패킷 캡처로 전달 실패 경계를 분석하는 절차를 제시하시오.

답안은 정상 재캡슐화와 장애를 먼저 구분한다. 링크마다 MAC 프레임이 달라지는 것, Hop Limit이 감소하는 것, 종단 대화와 구간 전달의 범위 차이를 하나의 그림으로 연결한다.

답안 목차·풀이·교정 근거 보기

25점 답안 목차

1. 모델·범위: 종단 대화, 다중망 패킷, 현재 링크 프레임 구분
2. 송신 캡슐화: 응용→전송→IPv6→Ethernet PDU와 제어정보
3. Ethernet 전달: 목적·출발 MAC, 길이/유형, 데이터, FCS
4. IPv6 전달: 40옥텟 기본 머리, 목적지·Next Header·Hop Limit
5. 라우터 경계: 수신 프레임 제거→머리 검사→다음 전달→새 프레임
6. 두 지점 비교: 정상 변화, 같은 대화 식별, 최초 이상 지점
7. 실패·한계: 캡처 누락·오프로딩·비대칭·단독 필드 과잉추론
8. 결론: 마지막 정상/최초 이상/미확인 사실과 추가 증거

25점 답안 도식

두 링크와 라우터 도식을 같은 캡처 조건으로 다시 읽는다. 입력 프레임 검사·제거, IPv6 길이·목적지·Hop Limit 검사, 다음 전달 결정, 출력 재캡슐화를 차례로 확인한다.

대조 축	남길 내용
비교키	관찰점·방향·시간, IPv6 양 끝·Next Header·길이·전송 식별정보
정상 변화	링크 MAC 교체와 Hop Limit 감소
종단 대화	유지할 주소·전송 대화와 개별 바이트 범위
실패 경계	누락·오류의 마지막 정상과 최초 이상
한계	아직 모르는 사실과 추가 포착·로그·통계

25점 모범답안

계층화된 전달은 응용 대화, 종단 전송, 여러 네트워크를 잇는 IPv6 전달, 현재 Ethernet 링크의 전달로 나뉜다. 송신 호스트는 응용 데이터에 전송 제어정보를 붙이고, 이를 IPv6 패킷에 넣은 뒤 현재 링크의 Ethernet 프레임으로 캡슐화한다. PDU는 각 계층의 상대가 해석하는 제어정보와 데이터 단위이며 아래 계층은 위 PDU 전체를 자기 데이터로 운반한다.

Ethernet 프레임에서는 목적·출발 MAC, 길이/유형, 상위 데이터와 FCS를 읽는다. MAC 주소의 효력은 현재 링크이므로 다른 네트워크의 호스트 B로 갈 때 첫 프레임의 목적 MAC은 다음 전달을 맡은 라우터 R의 접점이다. IPv6 기본 머리는 Version, Traffic Class, Flow Label, Payload Length, Next Header, Hop Limit, 출발·목적지 주소로 구성된다. 라우터는 들어온 프레임을 처리하고 IPv6 목적지와 경로정보를 확인하며 Hop Limit을 감소시킨 뒤 다음 링크의 새 프레임으로 캡슐화한다.

Next Header는 바로 뒤 확장 머리 또는 TCP·UDP 같은 상위 프로토콜 종류를 이어 주므로, 분석자는 선언된 순서를 따라 실제 데이터 경계를 연다. IPv6 중간 라우터는 패킷을 분할하지 않고, 분할이 필요하면 출발지가 Fragment 확장 머리를 만든다는 경계도 적는다. Ethernet FCS는 프레임 오류검출 값이지만 포착 장비·드라이버가 처리한 뒤 캡처에는 보이지 않을 수 있다. 따라서 FCS 미표시 하나를 링크 오류로 단정하지 않고 인터페이스 오류 통계와 다른 관찰점을 대조한다.

두 지점 분석은 먼저 질문과 관찰점·방향·시계를 고정한다. Ethernet→IPv6→전송 순으로 길이와 종류를 열고, IPv6 양 끝·Next Header·포트로 대화 후보를 찾고, seq와 실제 데이터 길이·관찰 가능한 내용·근접 시간으로 개별 전송의 대응을 좁힌다. 본문의 [1001,1101)과 [1101,1201)처럼 같은 대화의 서로 다른 바이트 범위를 구분하고, 같은 범위의 재전송·복제 가능성도 남긴다. 링크 MAC 교체와 Hop Limit 감소는 정상 변화로 분리한다. 송신 포착에는 있고 라우터 출력에는 없다면 수신 링크 검사, IPv6 머리 검사, 다음 전달 결정, 출력 링크 중 어디까지 정상인지 장치 로그·통계와 대조한다. 분석 결과는 마지막 정상 지점, 최초 이상 지점, 원인 후보, 추가로 필요한 증거로 끝낸다. 한 지점의 FCS 미표시나 Hop Limit 하나만으로 원인을 확정하지 않는다.

근거와 현행성

OSI의 참조모델 경계·계층/서비스/프로토콜·peer 관계·PDU는 ITU-T X.200 (07/1994) §§1.1–1.4, 1.16–1.18, 5.1, 5.2.1, 5.2.2.1–5.2.2.7, 5.3, 5.6, 6.1–6.3과 7.1–7.7을 확인했다. 인터넷 계층모형은 RFC 1122 §1.1.3과 링크/인터넷 경계인 §§2.4·3.1만 사용했으며 TCP 현행 규칙의 근거로 사용하지 않았다. 대응표와 도식은 원문 표·그림을 복제하지 않고 교재를 위해 다시 구성했다.

Ethernet의 MAC 프레임 필드와 FCS는 정확한 현행 공식 레코드인 IEEE Std 802.3-2022 Clause 3, 특히 3.1.1, 3.2와 3.2.9를, 반이중 공유매체의 CSMA/CD 경계는 Clause 4를 확인했다. 폐기된 802.3-2002 레코드를 인용하지 않는다. IPv6 기본 머리·Next Header 연결·송신자 분할은 RFC 8200 §3, §§4–4.1과 §4.5를 기준으로 했다. TCP=6, UDP=17과 포트의 구별은 IANA Assigned Internet Protocol Numbers의 해당 행을 2026-03-09 갱신 상태에서 확인했으며 registry 변경 또는 2026-12-01에 재검토한다. IEEE·ITU 원문의 표·그림·문장을 전재하지 않았고 분석 목적의 자체 도식만 사용했다. IPv4 상세, 이웃 탐색 절차, VLAN, 제품별 스위칭 구현은 이 근거 묶음으로 승인하지 않아 본문에서 제외했다.

기준 확인일은 2026-09-01이다. 기술 정확성·출제 적합성·기출 연결·권리에 대한 사람 승인 수는 0이며 상태는 candidate / human-validation-pending이다.

30초 정리

1. OSI와 TCP/IP는 실제 패킷의 꼬리표가 아니라 통신 책임을 놓는 참조모델이며 완전한 일대일 대응표가 아니다.
2. PDU는 같은 계층 프로토콜이 해석하는 단위이고, 네트워크 캡슐화는 상위 PDU에 하위 제어정보를 붙이는 과정이다.
3. Ethernet 프레임은 현재 링크, IPv6 패킷은 여러 링크의 전달을 책임한다.
4. 라우터는 들어온 링크 프레임을 처리하고 IPv6 Hop Limit을 감소시킨 뒤 다음 링크의 새 프레임을 만든다.
5. 분석은 관찰점·방향·시간을 고정하고 정상 변화, 마지막 정상, 최초 이상, 미확인 사실을 분리한다.

다시 읽을 때는 [Ethernet 프레임 [IPv6 패킷 [TCP/UDP PDU [응용 데이터]]]]라는 명확한 포함관계를 떠올리고, 각 경계에서 무엇이 바뀌어야 정상인가를 말해 본다.

적용 연습: 다음 머리의 종류와 페이로드 길이

앞의 길이 연습에 이어 TCP 머리 20바이트·TCP 데이터 60바이트, IPv6 기본 머리 40바이트인 패킷을 생각하자. 이번에는 기본 머리와 TCP 사이에 길이 8바이트인 Destination Options 확장 머리 하나가 있다. 기본 머리의 Next Header는 60(Destination Options), 확장 머리의 Next Header는 6(TCP)으로 올바르게 연결되어 있다. NAT·터널·분할·오프로딩·VLAN은 없고 Ethernet 머리 14바이트와 FCS를 제외한 포착 조건은 앞 연습과 같다. ① IPv6 Payload Length와 IPv6 전체 길이, ② FCS 제외 Ethernet 포착 길이, ③ ‘기본 머리의 Next Header가 6이 아니므로 TCP가 없다’는 판단의 옳고 그름을 설명하라.

확장 머리의 포함 범위와 사슬 읽기 풀이 보기

TCP PDU 길이는 20+60=80바이트다. IPv6 Payload Length는 기본 머리 뒤의 확장 머리도 포함하므로 8+80=88바이트, IPv6 전체 길이는 40+88=128바이트다. Ethernet 포착 길이는 14+128=142바이트다. 확장 머리 8바이트를 빠뜨린 134바이트는 앞의 ‘확장 머리 없음’ 연습 답이며 이번 조건의 답이 아니다.

Next Header는 바로 다음 머리의 종류를 알려준다. 따라서 IPv6 기본 머리(60) → Destination Options(6) → TCP로 따라가면 TCP가 있음을 확인할 수 있다. IPv6 패킷 시작에서 40바이트 뒤를 곧바로 TCP로 읽으면 확장 머리를 TCP 필드로 오해하게 된다. 이번 조건에서는 TCP가 패킷 시작에서 40+8=48바이트 뒤에 있다. 숫자 60과 6은 머리 종류 식별자이지 송수신 포트가 아니며, 이 예는 확장 머리 옵션의 상세 처리규칙을 추가하는 문제가 아니다. IPv6 기본 머리의 종류·길이와 상위 PDU의 포함관계를 함께 확인한다.