'IPV4'에 해당되는 글 3건

  1. 2014.04.07 Assigned Internet Protocol Numbers (1)
  2. 2011.01.26 「차세대인터넷주소(IPv6) 실전적용서」발간
  3. 2009.03.09 [IPv6 강좌] IPv6 프로토콜 구조와 IPv4와의 비교
2014.04.07 18:20

Assigned Internet Protocol Numbers

Assigned Internet Protocol Numbers

DecimalKeyword Protocol IPv6 Extension Header Reference 
0HOPOPTIPv6 Hop-by-Hop OptionY[RFC2460]
1ICMPInternet Control Message[RFC792]
2IGMPInternet Group Management[RFC1112]
3GGPGateway-to-Gateway[RFC823]
4IPv4IPv4 encapsulation[RFC2003]
5STStream[RFC1190][RFC1819]
6TCPTransmission Control[RFC793]
7CBTCBT[Tony_Ballardie]
8EGPExterior Gateway Protocol[RFC888][David_Mills]
9IGPany private interior gateway (used by Cisco for their IGRP)[Internet_Assigned_Numbers_Authority]
10BBN-RCC-MONBBN RCC Monitoring[Steve_Chipman]
11NVP-IINetwork Voice Protocol[RFC741][Steve_Casner]
12PUPPUP[Boggs, D., J. Shoch, E. Taft, and R. Metcalfe, "PUP: An Internetwork Architecture", XEROX Palo Alto Research Center, CSL-79-10, July 1979; also in IEEE Transactions on Communication, Volume COM-28, Number 4, April 1980.][[XEROX]]
13ARGUSARGUS[Robert_W_Scheifler]
14EMCONEMCON[<mystery contact>]
15XNETCross Net Debugger[Haverty, J., "XNET Formats for Internet Protocol Version 4", IEN 158, October 1980.][Jack_Haverty]
16CHAOSChaos[J_Noel_Chiappa]
17UDPUser Datagram[RFC768][Jon_Postel]
18MUXMultiplexing[Cohen, D. and J. Postel, "Multiplexing Protocol", IEN 90, USC/Information Sciences Institute, May 1979.][Jon_Postel]
19DCN-MEASDCN Measurement Subsystems[David_Mills]
20HMPHost Monitoring[RFC869][Bob_Hinden]
21PRMPacket Radio Measurement[Zaw_Sing_Su]
22XNS-IDPXEROX NS IDP["The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specification", AA-K759B-TK, Digital Equipment Corporation, Maynard, MA. Also as: "The Ethernet - A Local Area Network", Version 1.0, Digital Equipment Corporation, Intel Corporation, Xerox Corporation, September 1980. And: "The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications", Digital, Intel and Xerox, November 1982. And: XEROX, "The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specification", X3T51/80-50, Xerox Corporation, Stamford, CT., October 1980.][[XEROX]]
23TRUNK-1Trunk-1[Barry_Boehm]
24TRUNK-2Trunk-2[Barry_Boehm]
25LEAF-1Leaf-1[Barry_Boehm]
26LEAF-2Leaf-2[Barry_Boehm]
27RDPReliable Data Protocol[RFC908][Bob_Hinden]
28IRTPInternet Reliable Transaction[RFC938][Trudy_Miller]
29ISO-TP4ISO Transport Protocol Class 4[RFC905][<mystery contact>]
30NETBLTBulk Data Transfer Protocol[RFC969][David_Clark]
31MFE-NSPMFE Network Services Protocol[Shuttleworth, B., "A Documentary of MFENet, a National Computer Network", UCRL-52317, Lawrence Livermore Labs, Livermore, California, June 1977.][Barry_Howard]
32MERIT-INPMERIT Internodal Protocol[Hans_Werner_Braun]
33DCCPDatagram Congestion Control Protocol[RFC4340]
343PCThird Party Connect Protocol[Stuart_A_Friedberg]
35IDPRInter-Domain Policy Routing Protocol[Martha_Steenstrup]
36XTPXTP[Greg_Chesson]
37DDPDatagram Delivery Protocol[Wesley_Craig]
38IDPR-CMTPIDPR Control Message Transport Proto[Martha_Steenstrup]
39TP++TP++ Transport Protocol[Dirk_Fromhein]
40ILIL Transport Protocol[Dave_Presotto]
41IPv6IPv6 encapsulation[RFC2473]
42SDRPSource Demand Routing Protocol[Deborah_Estrin]
43IPv6-RouteRouting Header for IPv6Y[Steve_Deering]
44IPv6-FragFragment Header for IPv6Y[Steve_Deering]
45IDRPInter-Domain Routing Protocol[Sue_Hares]
46RSVPReservation Protocol[RFC2205][RFC3209][Bob_Braden]
47GREGeneric Routing Encapsulation[RFC1701][Tony_Li]
48DSRDynamic Source Routing Protocol[RFC4728]
49BNABNA[Gary Salamon]
50ESPEncap Security PayloadY[RFC4303]
51AHAuthentication HeaderY[RFC4302]
52I-NLSPIntegrated Net Layer Security TUBA[K_Robert_Glenn]
53SWIPEIP with Encryption[John_Ioannidis]
54NARPNBMA Address Resolution Protocol[RFC1735]
55MOBILEIP Mobility[Charlie_Perkins]
56TLSPTransport Layer Security Protocol using Kryptonet key management[Christer_Oberg]
57SKIPSKIP[Tom_Markson]
58IPv6-ICMPICMP for IPv6[RFC2460]
59IPv6-NoNxtNo Next Header for IPv6[RFC2460]
60IPv6-OptsDestination Options for IPv6Y[RFC2460]
61any host internal protocol[Internet_Assigned_Numbers_Authority]
62CFTPCFTP[Forsdick, H., "CFTP", Network Message, Bolt Beranek and Newman, January 1982.][Harry_Forsdick]
63any local network[Internet_Assigned_Numbers_Authority]
64SAT-EXPAKSATNET and Backroom EXPAK[Steven_Blumenthal]
65KRYPTOLANKryptolan[Paul Liu]
66RVDMIT Remote Virtual Disk Protocol[Michael_Greenwald]
67IPPCInternet Pluribus Packet Core[Steven_Blumenthal]
68any distributed file system[Internet_Assigned_Numbers_Authority]
69SAT-MONSATNET Monitoring[Steven_Blumenthal]
70VISAVISA Protocol[Gene_Tsudik]
71IPCVInternet Packet Core Utility[Steven_Blumenthal]
72CPNXComputer Protocol Network Executive[David Mittnacht]
73CPHBComputer Protocol Heart Beat[David Mittnacht]
74WSNWang Span Network[Victor Dafoulas]
75PVPPacket Video Protocol[Steve_Casner]
76BR-SAT-MONBackroom SATNET Monitoring[Steven_Blumenthal]
77SUN-NDSUN ND PROTOCOL-Temporary[William_Melohn]
78WB-MONWIDEBAND Monitoring[Steven_Blumenthal]
79WB-EXPAKWIDEBAND EXPAK[Steven_Blumenthal]
80ISO-IPISO Internet Protocol[Marshall_T_Rose]
81VMTPVMTP[Dave_Cheriton]
82SECURE-VMTPSECURE-VMTP[Dave_Cheriton]
83VINESVINES[Brian Horn]
84TTPTransaction Transport Protocol[Jim_Stevens]
84IPTMInternet Protocol Traffic Manager[Jim_Stevens]
85NSFNET-IGPNSFNET-IGP[Hans_Werner_Braun]
86DGPDissimilar Gateway Protocol[M/A-COM Government Systems, "Dissimilar Gateway Protocol Specification, Draft Version", Contract no. CS901145, November 16, 1987.][Mike_Little]
87TCFTCF[Guillermo_A_Loyola]
88EIGRPEIGRP[Cisco Systems, "Gateway Server Reference Manual", Manual Revision B, January 10, 1988.][Guenther_Schreiner]
89OSPFIGPOSPFIGP[RFC1583][RFC2328][RFC5340][John_Moy]
90Sprite-RPCSprite RPC Protocol[Welch, B., "The Sprite Remote Procedure Call System", Technical Report, UCB/Computer Science Dept., 86/302, University of California at Berkeley, June 1986.][Bruce Willins]
91LARPLocus Address Resolution Protocol[Brian Horn]
92MTPMulticast Transport Protocol[Susie_Armstrong]
93AX.25AX.25 Frames[Brian_Kantor]
94IPIPIP-within-IP Encapsulation Protocol[John_Ioannidis]
95MICPMobile Internetworking Control Pro.[John_Ioannidis]
96SCC-SPSemaphore Communications Sec. Pro.[Howard_Hart]
97ETHERIPEthernet-within-IP Encapsulation[RFC3378]
98ENCAPEncapsulation Header[RFC1241][Robert_Woodburn]
99any private encryption scheme[Internet_Assigned_Numbers_Authority]
100GMTPGMTP[[RXB5]]
101IFMPIpsilon Flow Management Protocol[Bob_Hinden][November 1995, 1997.]
102PNNIPNNI over IP[Ross_Callon]
103PIMProtocol Independent Multicast[RFC4601][Dino_Farinacci]
104ARISARIS[Nancy_Feldman]
105SCPSSCPS[Robert_Durst]
106QNXQNX[Michael_Hunter]
107A/NActive Networks[Bob_Braden]
108IPCompIP Payload Compression Protocol[RFC2393]
109SNPSitara Networks Protocol[Manickam_R_Sridhar]
110Compaq-PeerCompaq Peer Protocol[Victor_Volpe]
111IPX-in-IPIPX in IP[CJ_Lee]
112VRRPVirtual Router Redundancy Protocol[RFC5798]
113PGMPGM Reliable Transport Protocol[Tony_Speakman]
114any 0-hop protocol[Internet_Assigned_Numbers_Authority]
115L2TPLayer Two Tunneling Protocol[RFC3931][Bernard_Aboba]
116DDXD-II Data Exchange (DDX)[John_Worley]
117IATPInteractive Agent Transfer Protocol[John_Murphy]
118STPSchedule Transfer Protocol[Jean_Michel_Pittet]
119SRPSpectraLink Radio Protocol[Mark_Hamilton]
120UTIUTI[Peter_Lothberg]
121SMPSimple Message Protocol[Leif_Ekblad]
122SMSimple Multicast Protocol[Jon_Crowcroft][draft-perlman-simple-multicast]
123PTPPerformance Transparency Protocol[Michael_Welzl]
124ISIS over IPv4[Tony_Przygienda]
125FIRE[Criag_Partridge]
126CRTPCombat Radio Transport Protocol[Robert_Sautter]
127CRUDPCombat Radio User Datagram[Robert_Sautter]
128SSCOPMCE[Kurt_Waber]
129IPLT[[Hollbach]]
130SPSSecure Packet Shield[Bill_McIntosh]
131PIPEPrivate IP Encapsulation within IP[Bernhard_Petri]
132SCTPStream Control Transmission Protocol[Randall_R_Stewart]
133FCFibre Channel[Murali_Rajagopal][RFC6172]
134RSVP-E2E-IGNORE[RFC3175]
135Mobility HeaderY[RFC6275]
136UDPLite[RFC3828]
137MPLS-in-IP[RFC4023]
138manetMANET Protocols[RFC5498]
139HIPHost Identity ProtocolY[RFC5201]
140Shim6Shim6 ProtocolY[RFC5533]
141WESPWrapped Encapsulating Security Payload[RFC5840]
142ROHCRobust Header Compression[RFC5858]
143-252Unassigned[Internet_Assigned_Numbers_Authority]
253Use for experimentation and testingY[RFC3692]
254Use for experimentation and testingY[RFC3692]
255Reserved[Internet_Assigned_Numbers_Authority]



출처 : iana.org


Trackback 1 Comment 1
  1. 2014.04.07 18:22 address edit & del reply

    비밀댓글입니다

2011.01.26 18:36

「차세대인터넷주소(IPv6) 실전적용서」발간

IPv6 적용 시나리오별 테스트베드 구성도


방송통신위원회(위원장 최시중)는 지난해 마련한「IPv6 전환 추진계획(’10. 9.15)」에 따라 현 IPv4 인터넷주소체계에서 차세대 체계인 IPv6로 전환시 현장에서 바로 활용할 수 있는「차세대인터넷주소(IPv6) 실전적용서」를 발간했다.

방통위는 IPv4의 할당 *종료시점이 금명간 도래하기 때문에 금년부터 본격적인 “IPv6 전환 실행단계”로 돌입한다고 밝히고, 이 실전적용서는 정부가 2001년부터 민·학·연과 추진해왔던 기술개발, 시범사업 등을 모두 종합한 것으로써 실제 전환 작업현장에서 시행착오를 최소화해주는 가이드 역할을 하게 될 것이라고 밝혔다. 

※ IP 할당절차는 국제인터넷주소기구(IANA)→대륙별주소기구(아태지역 주소기구 APNIC)→국별 주소기관(KISA), 우리나라의 경우 APNIC의 할당 종료가 실질적 종료임. 
IANA(Internet Assigned Numbers Authority), APNIC(Asia Pacific Network Information Center) 

※ IANA의 IPv4 할당 종료 시점은 1월말 또는 2월초, APNIC의 할당 종료 시점은 4∼5월로 추정 

동 실전적용서는 IPv6 전환 관련 주체를 ▲망사업자(ISP) ▲서비스제공자(포털,CP) ▲비즈니스이용자(일반기업) ▲제품제조사(H/W, S/W)로 분류하고, 전환 주체별 행동지침을 테스트베드 실험결과와 함께 제시하고 있다. 

각 분야별로 IPv6 전환 적용시 특별히 고려되어야할 주요사항은

▲(ISP, 이통사 등 망사업자)의 경우 그간 백본망 위주로 IPv6 전환 작업이 진행되어 왔으나 가입자 설비(집선장치, 모뎀, 셋톱박스 등) 및 단말의 IPv6 지원이 필요하다. 특히 *무선 단말기의 경우 베이스밴드칩에서 IPv6 지원이 필수적이다.

※ ’10년말 현재, IPv6 지원 3G 무선단말은 전 세계적으로 Nokia N900 제품 1종임

▲(포털, 콘텐츠 제공자 등 서비스제공자)는 웹서버, *DNS서버, DB서버 등에 IPv6를 적용해야 하며 웹을 통해 설치되는 응용프로그램의 수정도 반드시 필요하다. 
※ DNS서버 : 도메인을 숫자로 된 인터넷주소(IP)로 변환시켜주는 장치

▲(일반기업 등 비즈니스이용자)는 기업 내부 PC와 보안 시스템에 IPv6를 적용해야 하며, 기업업무에 특화되어 개발한 응용프로그램은 *소스코드 수준에서 IPv6를 지원해야 한다.
※ 소스코드(source code) : 컴퓨터 프로그램을 사람이 읽을 수 있는 프로그래밍 언어로 기술한 글, 주로 실행 프로그램을 만드는 과정을 입력하는데 이용 

▲(장비 제조사, 소프트웨어 개발사 등 제품제조사)는 IPv6 기술들이 공개돼 있어 신규제품에는 IPv6기능 탑재를, 출시된 제품은 업그레이드를 통해 IPv6 지원이 가능토록 해야 한다. 

방통위는 이번 실전적용서 발간을 시작으로 본격적인 IPv6 전환 가속화를 위해 ▲인터넷주소의 우선할당 순위 수립 시행 ▲IPv6 상용화 본격 추진 ▲IPv6 취약계층 지원 ▲분야별 점검 강화 등 추진과제를 차질없이 실행할 계획이다. 

우선, IPv4 신규할당 종료에 따른 IP 주소 할당 우선순위 계획을 수립·시행한다. 서비스의 중요도, 네트워크 용도, 운영환경 등을 고려하여 IPv6 전환을 단계적으로 추진할 계획이며, 시행은 APNIC의 최종 IPv4 신규 할당이 종료되는 *시점부터다. 
※ APNIC은 비공식적으로 4∼5월로 추정, 국가별 IP 신청 수요에 따라 변동 가능

△ 가입자 증가가 감소하는 전화선기반 데이터통신망, 전력제어통신 등 안전성이 요구되는 국가 주요 통신망 등은 당분간 IPv4 유지
△ 스마트모바일 등 신규 인터넷주소 수요가 많은 서비스는 IPv4/IPv6 혼용
△ 새로 구축되는 LTE 등 차세대 이동 통신망 등은 초기부터 IPv6 체계로 구축 

둘째, IPv6 기반 웹 서비스(DNS, 메일) 등 상용화를 본격 추진한다. 방통위는 지난 해에 IPv6 기반의 △모바일 서비스 △인터넷 웹 서비스 △IPTV 서비스 등 상용 유·무선망에 IPv6 적용 시범사업을 성공적으로 완료하였으며, 그 결과를 토대로 금년부터는 상용화가 되도록 추진할 계획이다. 

셋째, IPv6 취약계층 지원을 강화한다. IPv6 전환 취약계층(중소 ISP, 콘텐츠사업자 등)에는 이번에 발간한 실전적용서 배포는 물론 ‘IPv6 전환 종합지원센터’를 통한 직접적인 기술컨설팅, 테스트 지원 등을 연중 실시한다. 

넷째, ISP, 서비스제공자, 비즈니스 이용자, 제조사 등 분야별로 IPv6 목표치를 구체적으로 설정하고 주기적으로 점검한다. ’13년까지 백본망 100%, 가입자망 45%까지 전환을 추진하고, 파급효과 극대화를 위해 포털과 온라인쇼핑몰 등 주요 100대 웹사이트에 IPv6 우선 적용을 유도할 계획이다. 

방통위는 효율적인 IPv6 전환 추진을 통하여 ▲인터넷주소 부족문제의 근본적 해결 등 미래인터넷서비스 기반 구축 ▲서비스 및 장비에 대한 글로벌 인터넷시장 선점 ▲보다 편리한 인터넷서비스 이용환경 구축을 통한 사회·문화적 욕구 충족 확대 등의 효과를 기대한다고 밝혔다.

한편 방통위는 오는 1월 28일 제4차 ‘IPv6 전환추진협의회’를 개최하고, 국제인터넷할당기구(IANA)의 IPv4 조기 할당 종료에 따른 IPv6 전환 대책 등을 논의할 예정이다.

출처 : 방송통신위원회

Trackback 0 Comment 0
2009.03.09 17:48

[IPv6 강좌] IPv6 프로토콜 구조와 IPv4와의 비교

출처 : 온더넷, 2005년 4월호

IPv6로 망을 구축하거나 기존의 망을 전환하기 위해서는 IPv6 주소체계와 구조를 알아야 한다. 예를 들면 기존에 202.15.6.1 형태로 표현된 32비트 IPv4 주소 프로토콜을 대체해 128비트의 새로운 주소 프로토콜이 사용되는 것이다. IPv6의 탄생 배경과 필요성에 대해서는 지난호에서 이미 상세히 설명했으므로 이번호에는 IPv6 프로토콜의 구조와 IPv4와의 차이점에 대해서 알아보자.

염창열 | 한국전산원 차세대인터넷팀 선임연구원

인터넷 데이터는 일정한 형태를 이뤄 전달된다. 이를 패킷이라고 부르는데 패킷의 구조는 (그림 1)과 같이 IP 헤더, TCP/UDP 헤더, 애플리케이션 헤더 그리고 이용자 데이터 영역으로 분류된다.

IPv6 헤더는 (그림 2)와 같이 버전, 트래픽으로 이뤄진다. 각 필드에 대해 간단히 설명하면, 버전(version, 4비트)은 패킷이 IPv4인지 IPv6인지 IP 프로토콜의 버전을 알려주는 필드다. 트래픽 클래스(Traffic Class, 8비트)는 QoS에서 사용되는 필드로 패킷의 우선 순위 등을 나타낸다. IPv4의 CoS 필드와 동일하다. 플로우 레이블(Flow Label, 20비트)은 IPv6에 신설된 필드로 플로우를 구분해 플로우별 패킷 처리를 가능하게 해주는 QoS 관련 필드다. 이에 대한 세부적인 활용 방안은 IETF에서 아직도 협의중이다. 페이로드 길이(Payload Length, 16비트)는 IPv6 헤더의 길이를 알려주고 넥스트 헤더(Next Header, 8비트)는 IP 헤더 다음에 어떤 확장 헤더가 올지 혹은 확장 헤더없이 UDP/TCP가 올지를 알려준다. 홉 리미트(Hop Limit, 8비트)는 IPv4의 TTL 값으로 루프(Loop) 방지를 위해 사용되며, 소스 어드레스(128비트)/도착지 어드레스(128비트)는 출발지/목적지 주소다.

(그림 3)과 같이 IPv6 헤더는 IPv4와 비교해 그 길이는 길어졌지만, 헤더 규격이 단순화 돼 처리 효율은 높아졌다. 왼쪽의 IPv4 헤더에서 현재 많이 사용하지 않는 'Flags' 'Fragment offset' 'Options and padding' 'checksum' 등의 필드는 붉은색 동그라미와 같이 삭제되거나 뒤에 설명할 확장 헤더로 넘겼고, 나머지 필드는 그 규격을 개선했다. 뿐만 아니라 플로우 레이블과 같이 추가 필드를 정의해 플로우별 데이터 처리를 가능케했다.

IPv6 헤더에서 정의하지 못했으나 인터넷 데이터 전송을 위해 필요하다고 생각되는 부가 기능에 대해서는 확장헤더를 통해 구현했다. 확장헤더는 IPv6 헤더와 TCP/UDP 헤더 사이에 (그림 4)처럼 위치한다.

(그림 5)는 확장 헤더의 종류와 그 기능을 설명하고 있으며, 이를 통해 IPv4보다 보안(IPsec), 이동성(Mobile IPv6) 등을 강화할 수 있었다.

 

IPv6 주소 형식
IPv4 주소는 10진수 형태로 A.B.C.D와 같이 4개의 점으로 구분돼 표현되지만, IPv6 주소표현 형태는 16진수 형태로 X:X:X:X:X:X:X:X와 같으며, 여기서 X는 16비트 크기로 네 개의 16진수로 표현된다.

예) 2002:2ABC:DEF0:1234:5678:90AB:CDEF:1234

IPv6 주소는 128비트로, IPv4의 32비트와 비교해서 4배가 길기 때문에 IPv4처럼 10진수로 표현하면 길이가 너무 길어질 수 있다. 그러나 IPv6 현재 주소표시 형태로도 길이가 길기 때문에 다음과 같이 주소 축약 형식을 채택하고 있다. '0'의 숫자 열을 압축하는 형식으로써 '::'은 '0'의 16비트 그룹이 이어진 것을 의미한다.

예) 2002 : 0 : 0 : 0 : 0 : 0 : 0 : 99 은 다음과 같이 표현됨
→ 2002 :: 99

다음과 같이 IPv4와 IPv6 노드의 혼합 환경을 취급하는 형식도 정의했다.

예) X: X: X: X: X: X: d. d. d. d

여기서 'X'는 16비트, 4개의 16진수 값이고, 'd'는 8비트 10진수 값이다. d.d.d.d는 표준 IPv4 주소 표현이다.

예 1) 2002 : 0 : 0 : 0 : 0 : 0 : 202.1.2.3 → 2002::202.1.2.3
예 2) 0 : 0 : 0 : 0 : 0 : 1234 : 10.1.2.3 → :: 1234:10.1.2.3

IP 주소는 네트워크 영역과 호스트 영역으로 나뉜다. IPv4에서는 주로 마스크(mask)를 사용하거나 '/(프리픽스 길이)'로 네트워크 영역과 호스트 영역을 구분했다. IPv6에서는 주소 길이가 길어 마스크 방식을 사용하기는 어려워 '/(프리픽스 길이)' 방식을 사용한다. 즉 주소 중 왼쪽부터 (프리픽스 길이)라고 표시된 길이의 비트만큼이 네트워크 영역이고 나머지 부분이 호스트 영역이 된다.
예를 들어, 2002:123::5/16에서 네트워크 영역은 2002이고, 호스트 영역은 123::5이다. 또한 이 주소를 통해 2002 프리픽스를 같은 네트워크의 규모는 2112이다.
IPv4 에서는 네트워크 영역과 호스트 영역의 규모를 A, B, C 클래스로 구분한다. (그림 6)과 같이 상위 4비트에 따라 크게 A, B, C 클래스로 구분되며, 각각의 클래스에 따라 호스트를 수용할 수 있는 네트워크 규모가 결정된다. A클래스는 1개의 네트워크당 224개의 호스트 주소를 할당할 수 있으며, B클래스는 1개의 네트워크당 216개의 호스트 주소, C클래스는 1개의 네트워크당 28개의 호스트 주소를 할당할 수 있다.

그러나 IPv6 주소는 이런 클래스 구분이 없다. 다만, 국가 주소 관리 기구가 통신업체에게 /32 크기의 주소를 할당해 주고 통신업체는 이를 자사 고객에게 /41 혹은 /48 크기로 할당해준다.

 

IPv6 주소의 종류
IPv6 의 주소 종류로는 (그림 7)과 같이 유니캐스트(unicast), 애니캐스트(anycast), 멀티캐스트(multicast)가 있다. IPv4와 비교해 브로드캐스트 주소가 없어졌으며(브로드캐스트 주소의 기능을 멀티캐스트에서 포함하고 있음), 애니캐스트 주소가 새로 생성됐다. 기존 IPv4가 유니캐스트, 멀티캐스트, 브로드캐스트로 구분되는 것과 마찬가지지만, 길어진 주소의 구조화된 사용을 위해서 이와 같이 바뀌게 됐다. 이들 3종의 주소에 대한 설명은 다음과 같다.

·유니캐스트 주소
단일 인터페이스를 지정하며 유니캐스트 주소로 보내진 패킷은 그 어드레스에 해당하는 인터페이스에 전달된다.

·애니캐스트 주소
여러 노드에 속한 인터페이스의 집합을 지정하며, 애니캐스트 주소로 보내진 패킷은 그 어드레스에 해당하는 인터페이스 중 하나의 인터페이스에 전달된다. 현재는 멀티캐스트 주소에 그 기능이 포함돼 있어서 거의 사용하지 않는다.

·멀티캐스트 주소
여러 노드에 속한 인터페이스의 집합을 지정하며, 멀티캐스트 주소로 보내진 패킷은 그 어드레스에 해당하는 모든 인터페이스에 전달된다. IPv6에는 브로드캐스트 주소는 없고, 그 기능은 멀티캐스트 주소로 대체됐다. 현재 어드레스 공간의 15%는 초기 할당됐고, 나머지 85%는 미래를 위해 예약돼 있다.

 

유니캐스트 주소
단일 인터페이스를 지정하며, 유니캐스트 주소로 보내진 패킷은 그 어드레스에 해당하는 인터페이스에 전달된다. IPv6에서 유니캐스트 주소를 할당하는 여러 가지 형태가 있다. (그림 8)은 유니캐스트 주소 구조의 예를 나타낸다.

예를 들어 2001:2b81:33bb::1234/32의 경우 상위 32비트 2001:2b81은 서브넷 프리픽스(subnet prefix)가 되며, 하위 96비트인 33bb::1234는 인터페이스 ID가 된다. 유니캐스트 주소의 예는 다음과 같다.
LAN이나 IEEE 802 MAC 주소를 갖는 환경에서의 일반적인 유니캐스트 주소의 구조는 (그림 9)와 같다. (그림 9)에서 48비트 인터페이스 ID는 IEEE 802 MAC 주소로, IPv6 주소가 설정된다.

유니캐스트 주소에는 'Global' 'Linklocal' 'Loopback' 'unspecified' 'IPv4 mapped' 'IPv6 compatible' 등으로 구분된다. Global IPv6 주소는 글로벌하게 라우팅되는 일반적인 주소다. 글로벌 주소는 왼쪽 3개의 비트가 모두 0으로 시작된다. Linklocal 주소는 같은 링크 상에서만 사용되는 주소로 (그림 10)처럼 왼쪽이 FE80으로 시작된다.

Loopback 주소는 (그림 11)과 같이 ::1, unspecified 주소는 (그림 12)와 같이 ::0으로 표기되며, 네트워크 상에서 자기 자신의 주소, 정해지지 않는 모든 주소 등으로 사용된다. IPv4 mapped 및 IPv4 compatible 주소는 모두 IPv4 주소를 IPv6 주소로 표현하는 방법으로 전자는 애플리케이션에서, 후자는 네트워크상 터널 주소로 활용된다.

 

애니캐스트 주소
여 러 노드들에 속한 인터페이스의 집합을 지정하며 애니캐스트(Anycast) 주소로 보내진 패킷은 그 어드레스에 해당하는 인터페이스 중 하나의 인터페이스에 전달된다. 전달되는 인터페이스는 라우팅 프로토콜의 거리 측정에 의해 같은 애니캐스트 주소를 갖는 인터페이스 중에서 가장 거리가 짧은 인터페이스에 전달된다. 애니캐스트 주소는 유니캐스트 주소 공간으로부터 할당됐고, 유니캐스트 주소 구조를 갖는다. 따라서 애니캐스트 주소는 그 형태만으로는 유니캐스트 주소와 구별할 수 없다. IPv6 애니캐스트 주소는 IPv6 패킷의 소스 주소로 사용될 수 없다. 애니캐스트 주소 구조는 (그림 13)과 같다.

사실 애니캐스트 주소 개념은 IPv4에도 존재한다. IPv4 상에서도 루트 DNS의 미러(Mirror) 서버에는 애니캐스트 주소가 할당돼 로드밸런싱 등의 용도로 사용됐다. 하지만 IPv4의 애니캐스트 주소는 IPv6와 달리 특정 영역 192.88.99.0/24이 사용된다.

 

멀티캐스트 주소
여 러 노드에 속한 인터페이스의 집합을 지정하며 멀티캐스트 주소로 보내진 패킷은 그 주소에 해당하는 모든 인터페이스에 전달된다. 멀티캐스트 주소는 주소의 상위 8비트가 FF(11111111) 값을 가짐으로써 유니캐스트 주소와 구별된다. 멀티캐스트 주소 구조는 (그림 14)와 같다.

멀티캐스트 주소는 여러 종류가 있는데, (표 1)에 자주 사용되는 주소를 나열하면 다음과 같다.

 

ICMPv6
IPv6 로 전환하기 위해 ICMP의 기능 또한 변화가 필요하다. ICMPv6는 패킷을 처리하면서 발생하는 오류(Error)나 현상에 대한 정보 전달 등을 수행한다. IP 헤더 다음에 ICMPv6가 오는지는 넥스트 헤더(Next header) 필드값(58)을 통해 확인할 수 있다. (그림 15)는 ICMPv6의 구조를 보여주고 있다.

IPv6에서는 주소 자동설정, MTU 발견(discovery) 기능, 주소중복확인(DAD) 등이 필수로 정의돼 있기 때문에 ICMPv6에서도 이를 지원할 수 있도록 변화가 필요했다. 이런 요구로 변화된 ICMPv6와 기존의 ICMPv4간의 차이는 (표 2)에서 비교하고 있다.


Trackback 2 Comment 0