쥬벤 라이브러리
프로그래밍언어, 각종코드, 관련동향, 논문 등의 저장소
IPv6 (2)
IPv6
IPv6의 개요

 
1969년 미국 국방부의 ARPAnet(Advanced Research Projects Network)이라 불리는 학술 연구망을 모체로 한 인터넷은 1994년 WWW(World Wide Web)의 대중화의 힘으로 급속도로 발전해왔다. 이러한 정보통신의 발전과 함께 국내의 인터넷은 1982년 서울대와 KIET간의 SDN (System Development Network) 이라는 통신망을 시점으로 현재는 교육전산망 (KREN: Korea Education Network), 연구전산망 (KREONet: Korea Research Environment Open Network), 초고속국가망 (PUBNet)과 같은 비영리 인터넷망을 비롯하여, BORANet, NEXTEL, KOLnet, NOWNet, KTNet, Inet, 등과 같은 많은 상업적 목적의 인터넷 망이 존재하고 있다.
이러한 국내외 통신망의 발전에 따라 인터넷 통신의 수요자는 전 세계적으로 99년 말에는 약 2억 5천만명에 이르렀으며, 2000년도에는 3억 8천명을 넘을것으로 예상된다. 또한 전 세계적으로 호스트의 수는 99년 말에는 7천만개를 넘어섰다.

위와 같이 전 세계적인 통신망을 구성하는 인터넷의 발전과 함께 그 수요의 폭발적인 증가에 따른 가까운 미래에 예측되는 인터넷의 확장은 ASIA 25억명, EASTEN EUROPE 2억 5천명, AFRICA 8억명, SOUTH AND CENTURAL AMERICA 5억명의 사용자와 그외에 이동전화사용, 홈네트워킹 기술에 기반을 둔 각종 가정기기등은 50억 이상으로 예측된다. 이러한 급속적인 수요의 증가에 따라 인터넷상의 주소(IPv4)는 고갈이 예상되었으며, IPv6에 대한 연구가 시작되었다.
   
IPv6의 특징
  가. IPv4(RFC791)의 문제점
    현재 인터넷 주소로써 사용되고 있는 IPv4는 다음과 같은 문제점을 가지고 있다 현재 32비트 주소에서의 할당용량 부족 사이트규모에 따른 class별 할당방식의 문제점IPv4헤더영역의 비효율적 사용 특히 기하급수적으로 늘어가는 사용자에 대하여 할당용량의 부족은 가장 커다란 문제점을 가지고 있으며, 이러한 문제를 해결하기 위하여 Dynamic IP allocation with PPP 와 Private IP addresses with NAT의 기술로써 임시방편적인 대책을 마련하고 있지만, 이러한 대책들은 통신, 보안, 게임 같은 대부분의 인터넷응용들은 양방향 통신이 이루어져야 하므로 NAT와 같은 단방향성인 해결책은 인터넷 확산에 대하여 장애가 될 수 있다. 따라서 근본적인 IP에 대한 해결책은 될 수 없는 것이다.
     
  나. IPv6의 특징
    IPv4에 대한 문제점과 할당공간부족에 대한 문제점을 해결책으로 개발된 IPv6의 특징으로써는 다음과 같다.
     
    - 거의 무한대 주소공간 (128bit)
- Aggregation-based address hierarchy
- 효과적인 백본 라우팅
- Efficient and Extensible IP datagram
- Fragmentation NOT by Routers, but only by a Source Host
- 보다 단순한 IPv6 기본 헤더, 40 bytes ·More efficient forwarding
- Source Routing & Hop-by-Hop Options Header
- Autoconfiguration & IP Renumbering ·Built-in Security AH & ESP
- QoS Flow Labeling
     
  다. IPv6 의 규격
    현재 RFC 규약에 의해 프로토콜규격 주소규격 라우팅 및 기타 규격에 의해 정의된 IPv6의 규격은 다음과 같다.
    - 프로토콜 규격
    RFC 2460: IPv6 Specification
RFC 1886: DNS Extensions to support IPv6
RFC 1981: Path MTU Discovery
RFC 2461: Neighbor Discovery for IPv6
RFC 2462: IPv6 Stateless Address Autoconfiguration
    - 주소 규격
    RFC 2373: IPv6 Addressing Architecture
RFC 2375: IPv6 Multicast Address Assignments
RFC 1887: An Architecture for IPv6 Unicast Address Allocation
RFC 2374: An IPv6 Aggregatable Global Unicast Address Format
RFC 2470: Proposed TLA and NLA Assignment Rules
    - Routing
    RFC 2080: RIPng for IPv6
RFC 2283: Multiprotocol Extensions for BGP-4
RFC 2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain
    - 기타
    RFC 2292: Advanced Sockets API for IPv6
RFC 2553: Basic Socket Interface Extensions for IPv6
RFC 2473: Generic Packet Tunneling in IPv6 Specification
RFC 2507: IP Header Compression
RFC 2675: IPv6 Jumbograms
RFC 2711: IPv6 Router Alert Option
     
IPv6의 구조 (RFC2460)
  가. IPv6의 기본 헤더구조
   
Ver Traffic Class Flow Label
Payload length Next Header Hop limit
128bit
Source Address
128bit
Destination Address
     
  나. Version (4bits) : 0110
     
  다. Traffic Class (8bits): 클래스 또는 우선권 식별
    RFC1881에 따르면
0~7: Congestion-controlled traffic 8~15: Non-congestion-controlled traffic

0 No spechfic priorty  
1 Background traffic News
2 Unattended data transfer email
3 Reserved for fufure definition  
4 Attended bulk transfer File transfer
5 Reserved for future definition  
6 Interactive traffic Remote login & windowing systems
7 Control traffic Routing protocols & NMS
8   High-fidelity video traffic
   
15   Low-fidelity audio traffic
     
  라. Flow Level : 송신자 노드에서 할당
    - Flow : 송신자 IP 주소와 Non-zero flow label의 조합으로 유일하게 식별.
- 같은 flow에 속하는 모든 패킷들은 the same source address, destination address,and flow label.
- 아직 실험적 대상, 변경 가능성 있음
     
  마.Payload Length (16bits)
    - Basic header (40bytes)를 제외한 나머지 모든 영역

BasicHeade
BasicHeader
~ 210(65,535 bytes)
ExtensionHeaders
TCP/UDPHeaders ApplicationHeader User Data
     
  바. Next Header (8bit)
   
IP v6header Next = TCP TCP Header + DATA

IP v6 header
Next = Routing
Routing header
Next = TCP
TCP Header
+data

IP v6 header
Next = Routing
Routing header
Next = fragment
Fragment Header
Next = TCP
Fragment TCP Header + data

0 Hop-by-Hop Options Header
4 Internet Protocol
6 Transmission Control Protocol
17 User Datagram Protocol
41 IPv6
43 Routing Header
44 Fragment Header
45 Interdomain Routing Protocol
46 Resource Reservation Protocol
50 Encapsulating Security Payload
51 Authentication Header
58 Internet Control Message Protocol
59 No Next Header
60 Destination Options Header
     
  사. Hop limits (8bits)
    - 패킷 포워딩을 하는 노드에서 1씩 감소시킴
  아. Source Address (128bits)
  자. Destination Address (128bits)
   
IPv6확장헤더
  IPv6의 기본 헤더 바로 다음에 위치하여 헤더의 종류는 바로 전 NEXT 헤더부분으로 판별된다. 확장헤더는 필요할 때만 사용하여 공간을 절약하는 장점을 가지고 있으며, 확장헤더의 종류와 나열순서는 다음과 같다.
   
  가. 확장헤더의 종류
    - Hop-by-Hop Options Header
- Options: Router Alert & Jumbogram
- TLV format
- 옵션별 위치 정렬 가능 처리 효율이 증가됨
   
    Routing Header (Type 0)
    패킷 전달경로를 Routingheader 내의 주소들을 따라서 결정 (현재Type = 0만 선언)

Next header Hdr leagth Type = 0 Seg left
Reserved
Address (0)
 
Address (n)
     
    Fragment Header
   
Next header Reserved Fragment Offset Res M
Identification
    Destination Options Header ·Authentication Header ·Encapsulating Security Payload
     
  나. 헤더 나열순서
    - IPv6 header Hop-by-Hop Options header Destination Options header ·Routing header
- Fragment header
   
  다. IPv6 Addressing Architecture (RFC 2373)
    주소표현 방식(128비트형식)
      - 주소표현 형태
     
Prefix Interface -ID
ㆍInterface ?ID : 128 ?prefix(n)
   fedc::ba00::/64등으로 <prefix>/<prefix length>로 prefix표기

ㆍx:x:x:x:x:x:x:x ·x는 16비트 크기로서 네 개의 16진수로 나타냄

  예) FEDC:0098:7654:3210:FEDC:BA98:7654:3210
· 각 필드에서 앞에 나오는 0은 선택적
     
  예) FEDC:0098:… = FEDC:98:
· 주소에서 유효한 비트의 수를 /를 이용하여 나타냄
     
  예) FE80::/10
     
  각기 16비트로 구성된 여러 개의 필드가 0이면 FF01:0:0:0:0:0:0:101 = FF01::101 0:0:0:0:0:0:0:1
= ::1 0:0:0:0:0:0:0:0 = :: FF01:0:0:8A01:0:0:0:1 = FF01:0:0:8A01::1
       
    prefix
      ISP (Internet Service Provider)나 네트워크관리 담당자로부터 할당 받음 ·주소의 사용목적에 따라 다양한 할당방식이 가능하다.
     
      다음은 사용목적에 따른 할당방식의 예이다

Allocation 항목 Prefix(2진수)
reserved 0000 0000
NSAP Allocation 0000 001
IPX Allocation 0000 010
Aggregatable Unicast Address 001
Link-local Unicast Address 1111 1110 10
Site-local Unicast Address 1111 1110 11
Muticast Address 1111 1111
     
    Unicast
      어떤 인터페이스 (interface) 하나에 대한 식별자 따라서 unicast 주소로 보내진 패킷은 이 주소가 할당된 인터페이스로 전달됨
   
  - 기본형식
 
n-bits 128-nbits
Subnet prefix Interface ID
  - Interface identifiers
    ㆍLinks or Nodes with EUI-64 Identifiers (64 bits)
ㆍLinks or Nodes with MAC address (48bits)Unspecified AddressLoopback Address
  - IPv6 aggregatable global unicast address
   
3 13 8 24 16 64
FP TLA ID RES NLA ID SLA ID Interface ID
    001 Format Prefix (3 bit) for Aggregatable Global Unicast Addresses

TLA ID Top-Level Aggregation Identifier
ex.)0x1ffe, 6Bone / 0x0001, official use 0x0002, 6to4
RES Reserved for future use
NLA ID Next-Level Aggregation Identifier
SLA ID Site-Level Aggregation Identifier
INTERFACE ID Interface Identifier
   
현재 할당값
  - 6bone 테스트값
  - NIC에서의 Sub ? TLA 할당값 : 2001:/16
  - NIC에서의 6to4 transition용 TLA : 2002:/16
주소 예 : 2002:230::/35 001 0000000000010 ,
ETRI TLA 3ffe:2e00::/24 001 1111111111110 , 6Bone-KR
  - Local-use IPv6 Unicast 주소
    Link-Local addresses FE80::/10
  - Site-Local Address (fe80 ::/10)
   
10bits 38bits 16bits 64bits
1111111011 0 Subnet Interface ID
     
    Anycast
   
  - 여러 개의 인터페이스를 묶어서 하나로 나타내는 식별자
(이들 인터페이스는 통상 다른 노드에 있음)
  - Anycast 주소로 보내진 패킷은 이 주소를 사용하는 그룹 멤버들 가운데
가장 가까운 하나에게만 전달됨
     
    Multicast
      Anycast의 경우처럼 여러 개의 인터페이스를 묶어서 하나로 나타내는 식별자
그러나 이 주소로 보내진 패킷은 이 주소를 사용하는 그룹 멤버들 전체에게 전달됨
   
  - 멀티캐스트주소형식
   
8 4 4 112
8bits 4bits 4bits 112bits
11111111 flags scop Group ID
  - Flags is a set of 4flags
   
0 0 0 T

8 4 4 112
11111111 flag scop Group ID
11111111 flag scop Group ID
  - flags is a set of 4flags
   
0 0 0 T

ㆍT = 0, 영구 할당 주소용
ㆍT = 1, 임시 할당 주소용
ㆍscope (scope)은 멀티캐스트의 범위를 제한

  0 reserved 8 organization-local scope
1 node-local scope 9 A,B,C,D (unassigned)
2 link-local scope E global scope
3,4 (unassigned) F reserved
5 site-local scope
6,7 (unassigned)· 예약되어 있어 일반 사용 불가 멀티캐스트 주소

FF0[0~F]::
  - All-nodes Multicast 주소
Node-local(scope 1) FF01::1
Link-local (scope 2) FF02::1
  - All-routers Multicast 주소
Node-local (scope 1) FF01::2
Link-local (scope 2) FF02::2
Site-local (scope 5) FF05::2
  - Solicited-Node Multicast 주소
FF02::1:FFxx:xxxx, 즉, FF02:0:0:0:0:1:FF00::/104
Unicast와 Anycast 주소의 하위 24bit를 가지고 만듬
     
    URL에서의 IPv6 주소 표현 방식
      http:// [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html
( [ ]를 사용하여 포트와 주소를 구분한다 . )

http://[1080:0:0:0:8:800:200C:417A]/index.html


http://[3ffe:2a00:100:7031::1]

( 여러 개의 0이 반복되는 경우 ::로 축약가능하다 .)

http://[1080::8:800:200C:417A]/foo

(한서버에서 여러 개의 홈페이지를 서비스하는 방법은 기존과 동일하다.)

http://[::192.9.5.5]/ipng


http://[::FFFF:129.144.52.38]:80/index.html
     
    IPv4의 사용 (prefix) IPv4-compatatible IPv6 address
   
  - IP v4주소를 그대로 IPv6에서 사용한다.
    예 ) :: <IPv4에서 사용하던 주소)
  - IPv4-mapped IPv6 address
    이 주소를 사용하는 호스트는 IPv6가 지원되지 않는 호스트임을 나타낸다.
    예 ) ::ffff:<IP v4 dotted-decimal address>
  - IPv6의 기능
  - IPv6 Stateless Address Autoconfiguration (RFC 2462)
    자동 주소 설정
Plug-and-Play 기능
자동 주소 재지정 (Renumbering) 기능 수행
Autoconfiguration 종류
      - Stateful Mechanism
  ㆍDHCP 서버로부터 주소를 비롯한 모든 네트워크 정보를 받음
- Stateless Mechanism
  ㆍRouter로부터 주소를 비롯한 모든 네트워크 정보를 받을 수도 있고, 또는
  ㆍRouter로부터 주소 정보만 받고 나머지 네트워크 정보들을 DHCP 서버로부터 받을 수도 있음
  ㆍNDP 메시지를 사용하여 자동설정
  ㆍLink - Local 주소를 NDP 메시지의 IP v6헤더에 사용
     
    NDP (Neighbor Discovery Protocol)
   
  - IPv4 에서의 Address Resolution 기능에 ICMP 에서의 router discovery.rediraction 기능이 포함되었다
  - NDP message
    Router solictation/ advertisement message
      자신과 동일한 링크에 연결되어 있는 router를 파악할 때 사용되며, 호스트는 router solicitation 으로 질의를 보내고 router는 router advertisement로 자신의 정보를 전달한다.
    Neighbor solicitation / advertisement message
  - IP v4에서의 ARP기능
  - 호스트는 neighbor solicitation으로 질의를 보낸다
  - 목적호스트는 neighbor adverisement로써 응답을 보낸다.
    Redirect message
  - 라우터가 더 나은 경로를 알고 있을 때 redirect message를 패킷전송자에게 전달
     
    Site Renumbering
      Site 주소변경 시 Network의 재설정을 용이하게 해준다.
(각 호스트에 대한 주소변경이 불필요하다.) 1. 관리자에 의해 prefix1 에서 prefix2로 변경
2. 변경된 prefix2로 Router advertisment
3. prefix / default router 변경( prefix1:host 를 prefix2:host로 변경완료)
     
    IPv4에서 IPv6로의 변환
     
      현재 전세계적으로 사용되고 있는 IPv4를 IPv6로 전환시에는 많은 시간과 비용이 필요하게 된다. 이러한 문제점은 IPv6로의 전환을 어렵게 만들고 있다. 커다란 인터넷망에서 한순간에 IPv6로의 전환은 힘들다는 것을 인지하고 IPv4와 IPv6와의 공존의 기간과 IPv6로의 전환기간역시 고려되어야 한다. 다음은 IPv4와 IPv6의 두가지 형식을 통신에 함께 사용할 수 있는 기술들이다.

- Tunneling방식 : 네트워크에서 터널을 제공해주는 서비스를 하거나 동적으로 터널을 생성해주는 방식
     
   
  AIIH( Assignment of IPv4 global Address)
    IPv4 및 IPv6 이중호스트가 원할 때에만 IPv4주소를 얻는 형식이다.
단점 : DNS/DHCPv6와의 통신방법이 불분명하다.
  2 DTI(DynamixTunnelInterface)
    IPv6 도메인내에서 IPv4호스트와의 통신을 위해서 사용되는 방식이다.
  3 6 to 4
    IPv4 도메인을 사이에 둔 IPv6도메인간의 통신을 위해 사용된다. 이 방식은 주소에 6to4 TLA 및 IPv4를 위한 NLA가 사용되며 IPv4호스트와의 통신기법은 아니므로 별도의 변환작업이 필요하다.
  Header Translation 방식
    Header Translation 방식은 네트워크에서의 호스트등에서 IPv6 의 패킷과 IPv4 의 패킷을 서로간에 변환하여 통신하는 방식이다 .
  NAT-PT
    IPv4도메인 및 IPv6도메인의 경계지점에서 각 패킷의 프로토콜 헤더부분을 변환하는 역할을 담당한다. 가) SIIT : 헤더별 변환 메커니즘을 가지고 변환하는 방식이다 나) SOCKS64 : Firewall용 프로토콜인 SOCKS64를 수정하여 IPv4와 IPv6간의 Traslator로 사용하는 형식이다. SOCKS서버는 통신을 원하는 IPv4호스트 및 IPv6호스트를 각각의 TCP로 접속하여 변환작업을 수행한다. 다) IPv6할당과 진행사항
  6bone 테스트주소를 위한 prefix(pTLA)
    3ffe:0000::/24 - 3ffe:3900::/24
3ffe:0000::/24 - 3ffe:8050::/28
  NIC에서의 공식주소 할당
    sub-TLA 할당주소 : 2002:: /16
6to4 transition용 주소 : 2002/16
  6bone-KR주소할당
    3ffe:2e01:
NLA1:3ffe:2e01::/32 3ffe:2e03::/32
(6bone-KR. APAN-KR)
NLA2 : 3ffe:2e01:1::/48 ? 3ffe2e01:9:: /48
  6bone이란?
    IPv6의 표준 구현테스트와 Transition 전략테스트 그리고 이러한 IPv6의 네트워크운영경험을 축척하기 위해서 테스트용으로 인터넷 IPv6 백본망이 필요하게 되며, 현재 북아메리카, 유럽, 일본, 한국을 포함하는 비공식적인 합작 프로젝트로써 6Bone이라는 백본망을구성하고 있다.
이러한 6Bone은 IPv6 패킷 라우팅을 지원하기 위한 물리적인 IPv4 기반의 인터넷 상속물들의 제일 높은 계층의 가상 네트워크이다. 이를 통하여 현재 IPv6와 관련된 많은 테스트들이 행하여지고 있으며, IPv4에서 IPv6로의 이행은 IPv4와 IPv6가 동시에 병행되어 쓰이면서 점차적으로 완전한 IPv6로 이행되는 형태가 될 것으로 예상된다.
     
   
- 6bone 테스트 주소를 위한 prefix (pTLA)
  3ffe:0000::/28 ? 3ffe:8050::/28
3ffe:0000::/24 ? 3ffe:3900::/24
- NIC 에서의 공식주소할당
  sub-TLA 할당 주소 : 2002::/16
6to4 transition 용 주소 : 2002::/16
- 6bone-KR 주소할당 -3ffe:2e01:
  NLA1 (3ffe:2e01::/32 ? 3ffe:2e03:2::/32 6bone-KR, APAN-KR )
NLA2 (3ffe:2e01:1::/48 ? 3ffe2e01:9::/48)

신고
0  Comments,   0  Trackbacks
댓글 쓰기
IPv6 Tutorial
제목 : IPv6 Tutorial

작성자 : 유리바다(seaofglass@korea.com)

작성일 : 2004.5.14




- 필요성

이 글을 작성하는 현재 우리는 Internet Protocol의 버전은 4.0을 사용하고 있습니다.

하지만 폭발적인 인터넷의 보급으로 인하여 할당할 수 있는 IP는 거의 고갈되었고

이에 대한 해결책으로 Inetnet Protocol version 6.0이 나오게 된 것입니다.

이것을 IPng(Next Generation - 차세대 IP)라고도 합니다.

128bit를 사용하기 때문에(IPv4는 32bit) 앞으로는 통신기능을 가지고 있는 기기들이 있다면

IPv6를 사용하여서 각각에 대한 ip 주소를 할당하게 될 것입니다.

Mobile IP에 대한 내용은 이 문서에서 다루지 않으며 정보가 필요하신 분들은 RFC 2002를 참조해 주시기 바랍니다.



- 표준화 중점

확장 주소 기능(Expanded Addressing Capabilities)

헤더 포맷 간소화(Header Format Simplification)

확장/선택사항 추가 기능(Improved Support for Extensions and Options)

Flow Labeling 기능

인증/사생활 보호 기능(Authentication and Privacy Capabilities)



- 새로운 기능

QoS(Quality Of Service)

	IPv6 header의 Priority와 Flow Label 필드를 통해 구현됩니다.

NDP(Neighbor Discovery)
	
	네트워크 환경 검색(ND)은 인접한 노드들 사이의 관계를 결정하는 메시지 및 프로세스 세트입니다.
	
	ARP, ICMPv4와 같은 IPv4 프로토콜을 대체하며 추가의 기능을 제공합니다.
	
	ND는 ICMPv6를 메세지를 사용합니다.

Auto Configuration

	이것은 사용자의 수동설정 없이 라우터나 호스트 자체에서 주소를 설정하는 기능입니다.
	

- IPv6 Header


기본헤더

	Version(4bit) : 각 IP 데이터그램의 첫 번째 네 비트는 IP의 버전을 포함합니다.
	
	
	Priority(4bit) : 데이터그램의 우선순위를 정하여 0에서 15 사이의 값으로 발신측에서 전송하는
	패킷에 대한 요구되는 우선순위 값을 지정한다. 예를들어 "실시간" 패킷이 일정한 속도로 전송되는데
	사용됩니다. 실시간 응용프로그램과 같은 비집중 제어식 통신의 경우 가장 낮은 우선순위값 8은 송신자가 혼잡상황에서
	가장 쉽게 폐기할 수 있는 패킷에 대해 사용됩니다. 그리고 가장 높은 우선순위값 15는 송신자가 폐기할 수 없는
	패킷에 대해 사용됩니다. 집중 제어식 통신의 IPv6의 우선 순위 필드 값은 다음과 같습니다.
	
	0		특별한 특징이 없는 통신
	1		'filter' 통신 (ex : netnews)
	2		무인 데이터 전송(ex : e-mail)
	3		(예약됨)
	4		유인 대량 전송(ex : FTP, NFS)
	5		(예약됨)
	6		대화형 통신(ex : Telnet, X)
	7		인터넷 제어 통신(ex: 경로 설정 프로토콜, SNMP)
	
	
	Flow label(24bit) : 이 패킷이 원본과 대상 사이의 특정 패킷 시퀀스에 속하므로 중간 IPv6 라우터에 의한 특수처리가
	필요하다는 것을 나타냅니다. flow label은 실시간 데이터처럼 서비스 연결에 대한 기본 이상의 품질을 제공하기 위해
	사용됩니다. 기본 라우터를 처리할 때 흐름 레이블은 0으로 설정되고, 원본과 대상 사이에는 0이 아닌 별도의 
	flow label로 구별되는 여러 흐름이 있을 수 있습니다. 예를들어 서버에서 멀티미디어 스테이션으로 비디오나 오디오를
	운반하는 데이터그램은 서로 다른 flow label을 가질 수 있는데 이것은 동일한 flow label 값을 네트워크 전체에 걸쳐서
	똑같은 방법으로 처리할 수 있게 해 줍니다.
	
	
	Payload Length(16bit) : payload 길이는 IP 기본 헤더 그 자체보다는 적은 IP 데이터그램의 전체 길이를 바이트 단위로
	나타냅니다. 이 필드는 16비트 크기이므로, 보통 IP 데이터그램을 65535바이트나 더 적은 크기로 제한합니다.
	hop-by-hop옵션 확장 헤더의 점보그램(jumbo payload) 옵션을 사용하여 더 큰 데이터그램을 보낼 수 있습니다.
	이 옵션이 사용되면 payload 길이는 0 으로 설정됩니다.
	
	
	Next Header(8bit) : next header 필드는 어떤 헤더가 데이터그램에서 기본 IP 헤더 다음에 오는지를 나타낸다.
	그것은 옵션적 IP 헤더나 상위 계층 프로토콜을 나타낼 수 있습니다. IP Next Header 값은 다음과 같습니다.
	
	0			Hop-by-hop Options Header
	1	ICMP		Internet Control Message Protocol	(IPv4)
	2	IGMP		Internet Group Management Protocol	(IPv4)
	3	GGP		Gateway Protocol
	4	IP		Ineternet Protocol			(IPv4 캡슐화)
	5	ST		Stream
	6	TCP		Transmission Control Protocol
	17	UDP		User Datagaram Protocol
	43	RH		Routing Header			(IPv6)
	44	FH		Fragment Header			(IPv6)
	45	IDRP		Interdomain Routing Protocol
	46			Resource Reservation Protocol
	50			Encapsulating Security Payload
	51	AH		Authentication Header		(IPv6)
	52	ESP		Encryption Security Payload		(IPv6)
	58	ICMP		Internet Control Message Protocol
	59	NULL		No Next Header			(IPv6)
	60			Destination Options Header
	80	ISO-IP		CLNP
	
	
	Hop Limit(8bit) : 이 필드는 얼마나 멀리 데이터그램이 여행할 것인지 결정합니다. 호스트가 데이터그램을 생성할 때
	
	호스트는 hop limit를 어떤 초기치로 설정합니다. 홉 한계의 초기값은 송신자가 설정합니다. 데이터그램이 네트워크상의 
	
	라우터를 통해 여행할 때, 각각의 라우터는 이 필드를 1씩 감소시킵니다. 만약 데이터그램의 hop limit가 그것의 
	
	목적지에 도착하기 전에 0이 되면 데이터그램은 폐기됩니다. 홉 한계는 IPv4의 TTL 필드와 비슷하지만 TTL 필드는
	
	초 단위로 재는 데 비하여 IPv6의 홉 한계는 홉 단위로 잰다는 차이가 있습니다.
	
	
	Source Address(128bit) 
	
	
	Destination Address(128bit)


확장헤더

	추가적인 정보를 경로를 따라 목적지나 중간 시스템으로 전송하기 위해 사용됩니다.
	기본 헤더 다음에 확장헤더가 위치하게 됩니다.
	
	
	
	경로 설정 헤더 : IPv6 경로 설정 확장 헤더는 IPv6 데이터그램이 목적지로 가는 도중에 거쳐가야 하는 하나 이상의
	중간 라우터를 지정하기 위해 사용됩니다. 이 헤더는 IPv4에도 사용되는 출발지 경로 설정 옵션의 개념을 구현하기
	위해서 사용됩니다. IPv6 경로 설정 확장 헤더는 IPv6 기본 헤더으 Next Header 값 43으로 식별합니다.
	각 필드는 다음과 같은 의미를 지닙니다.
		
		* Next Header : 이것은 경로 설정 헤더의 바로 다음에 오는 헤더의 유형을 식별하는 8비트 선택자입니다.
		그것은 IPv6 확장 헤더 체인의 일부인 또 다른 IPv6 확장 헤더 또는 상위 계층 운반 프로토콜일 수 있다.
		
		* Hdr Ext Len : 이것은 첫 번째 8옥텟을 제외하고 8옥텟 단위의 경로 설정 헤더 길이를 나타내는 8비트
		부호없는 정수 값입니다.
		
		* 경로 설정 유형 : 이 필드는 특정 경로 설정 헤더 변형의 8비트 식별자이며 현재 IPv6 사양(RFC 1833)에는
		경로 설정 유형 0이 정의되어 있습니다. 다른 값을 사용하면 경로설정헤더 형식의 대안을 식별할 수 있습니다.
		
		* 남은 세그먼트 : 이 필드는 8비트 부호 없는 정수값이며 나머지 경로 세그먼트 수를 지정합니다.
		나머지 경로 설정 세그먼트 수는 최종 목적지에 도달하기 전까지 아직 거쳐가야 하는 것으로 명시적으로
		열거된 중간 노드의 수 입니다.
		
		* 유형별 데이터 : 이것은 경로 설정 유형 필드에서 그 형식이 결정되는 가변 길이 필드입니다. 필드의 길이는
		전체 경로 설정 헤더 길이가 8옥텟의 정수 배수입니다.
		
		| Next Header (8bit)  | Hdr Ext Len (8bit)  | 경로 설정 유형 (8bit)  | 남은 세그먼트 (8bit) |
		|		유 	형	별	데	이 	터 (32bit)		|
		
					< IPv6 경로 설정 확장 헤더 >
		
		
		어떤 노드가 익식할 수 없는 경로 설정 유형 값을 가진 경로 설정 헤더를 발견하면 나은 세그먼트 필드의 값에
		따라 패킷을 처리합니다. 남은 세그먼트가 0이면 노드는 경로 설정 헤더를 무시하고 패킷의 다음 헤더를 계속
		처리합니다. 다음 헤더는 경로 설정 헤더의 Next Header 필드로 식별됩니다.
		
		남은 세그먼트가 0이 아니면 노드는 패킷을 삭제하고 ICMP 매개변수 문제 코드 0 메세지를 출발지 주소 필드에
		나타나고 인식할 수 없는 경로 설정 유형 값을 가르키는 패킷의 목적지에 보내야 합니다.
		
		IPv6 유형 0 경로 설정 확장 헤더의 필드는 다음과 같은 의미를 가지고 있습니다.
		
		* Next Header : 경로 설정 헤더 바로 다음에 오는 헤더의 유형을 식별하는 8비트 선택자
		
		* Hdr Ext Len : 8bit 부호 없는 정수. 이 필드는 처음 8옥텟을 제외하고 8 옥텟 단위의 경로 설정 헤더 길이며
		유형 0 경로 설정 헤더의 Hdr Ext Len은 헤더의 주소 수의 2배와 같으며 46보다 작거나 같은 짝수입니다.
		
		* 남은 세그먼트 : 8bit 부호 없는 정수이며 이 필드는 남은 경로 세그먼트 수이며 그 최대값은 경로 유형 0을
		나타내는 23입니다.
		
		* 예약 : 송신할 때 0으로 초기화되고 수신할 때 무시되는 8비트 에약 필드입니다.
		
		* 정밀/일반 비트 맵 : 0부터 23까지 왼쪽에서 오른쪽으로 나열되는 24비트 비트맵이며 각 비트는 경로의
		세그먼트에 해당하고 다음 목적지 주소가 앞 주소의 인접장치인지 여부를 나타낸다. 비트값 1은 정밀 출발지
		경로 설정을 의미합니다. 다시말해서 다음 목적지 주소는 인접 장치이어야 합니다. 비트값 0은 일반 출발지
		경로 설정을 나타냅니다. 즉 다음 목적지 주소가 인접 장치일 필요가 없습니다.
		
		* 주소[1..n] :  1부터 n 까지 128비트 주소의 벡터
		
		| Next Header (8bit) | Hdr Ext Len (8bit)  | 경로 설정 유형=0 (8bit) | 남은 세그먼트(8bit) |
		|	예약 (8bit) |	정밀 / 일반 비트 맵 ( 32 bit)				|
		|				주소[1]					|
		|				주소[2]					|
		|				주소[n]					|
		
				<경로 설정 유형 0, IPv6 경로 설정 헤더 >

	
	
	
	단편 헤더 : IPv4와 달리 IPv6의 단편화는 출발지 노드에서만 수행되며 패킷의 전달 경로에 있는 라우터에서는 수행되지
	않습니다. IPv6 출발지 노드는 목적지에 대한 MTU 크기를 알고 있습니다. IPv6 노드는 'RFC 1191 Path MTU Discovery'에
	정의된 대로 경로 MTU 발견을 구현하여 목적지에 대한 MTU를 발견합니다.
	
	IPv6 출발지는 단편 헤더를 삽입하여 그 목적지에 대한 경로 MTU에 들어가는 것보다 더 큰 패킷을 보낸다. 단편 헤더는
	바로 앞 헤더의 Next Header 값 44로 식별됩니다.
	
	| Next Header(8bit)	 | 예약 (8bit) | 단편 오프셋 (13bit) |  Res (2bit) |  M (1bit) |
	|			식	별	(32bit)			|
	
			<IPv6 단편 확장 헤더>
			
	단편헤더의 필드는 다음과 같은 의미를 가집니다.
		
		* Next Header : 경로 설정 헤더 바로 다음에 오는 헤더의 유형을 식별하는 8bit 선택자입니다.
		이 헤더는 IPv6 확장 헤더 체인의 일부인 또 다른 IPv6확장 헤더 또는 상위 계층 운반 프로토콜일 수 있습니다.
		
		* 예약 : 송신할 때 0으로 초기화되고 수신할 때는 무시되는 8bit 예약 필드입니다.
		
		* 단편오프셋 : 이 헤더 다음에 오는 데이터의 8 옥텟단위 오프셋을 나타내는 13비트 부호없는 정수입니다.
		오프셋은 원본 패킷의 단편 부분의 시작 위치를 기준으로 따지게 됩니다.
		
		* Res : 송신할 때 0으로 초기화되고 수신할 때 무시되는 2비트 예약 필드입니다.
		
		* M 플래그 : 이 필드는 단편이 더 있으면 1, 마지막 단편이면 0으로 설정됩니다.
		
		* 식별 : 32비트 필드이며 단편화 될 모든 패킷에 대하여 출발지 모드는 식별 값을 생성하게 됩니다.
		식별값은 같은 출발지 주소와 목적지 필드를 가지고 최근에 보낸 다른 단편화 패킷의 것과 달라야 합니다.
		
	
	

	목적지 옵션 헤더 : 목적지 옵션 헤더는 패킷의 목적지 노드에서만 심사해야 하는 선택적 정보를 운반하기 위해 사용됩니다.
	목적지 옵션 헤더는 바로 앞 헤더의 Next Header 값 60으로 식별됩니다.
	
	| Next Header(8bit) | Hdr Ext Len(8bit) | Option |
	
	목적지 옵션 헤더의 필드는 다음과 같은 의미를 가집니다.
	
		* Next Header : 경로 설정 헤더 바로 다음에 오는 헤더의 유형을 식별하는 8비트 선택자 입니다.
		
		* Hdr Ext Len : 8비트 부호 없는 정수. 이 필드느 처음 8옥텟을 제외하고 경로 설정 헤더의 8옥텟 단위 길이입니다.
		
		* 옵션 : 가변 길이 필드이며 전체 목적지 옵션 헤더 길이는 8옥텟의 정수 배수입니다.
		
		옵션값은 Hop-by-Hop 과 목적지 옵션 헤더에 사용됩니다. 옵션 값은 Type-Length-Value(TLV)형식을 사용하는
		기호입니다. 옵션 유형은 1옥텟이고 옵션 길이는 1옥텟이며 바로 다음에 오는 옵션 데이터의 크기를 가지고 있습니다.
		옵션 유형 식별자는 최대 유의 2비트가 IPv6노드의 처리에서 옵션 유형을 인식하지 못한 경우 취해야 하는 조치를 
		지정합니다. 
		
		00		이 옵션을 무시하고 헤더의 처리를 게속함
		
		01		패킷을 삭제
		
		10		패킷 삭제. 패킷의 목적지 주소가 다른 다중 전송 주소였는지 여부와 관계없이, 인식할 수 없는
				옵션 유형을 가리키는 패킷의 목적지 주소에 ICMP 매개변수 문제 코드 2 메세지를 보냅니다.
		
		11		패킷 삭제. 패킷의 목적지 주소가 다중 전송 주소가 아니었으면, 패킷의 목적지 주소에 ICMP
				매개변수 문제 코드 2 메세지를 보내고 인식할 수 없는 옵션 유형을 가르킵니다.
				
		옵션 유형의 세 번째 최대 유의 비트는 그 옵션의 데이터가 패킷의 최종 목적지에 대한 en 경로를 바꿀 수 있는지
		여부를 지정합니다. 세 번째 최대 유의 비트는 의미는 다음과 같습니다.
		
		0 옵션 데이터는 en 경로를 바꾸지 못한다.
		1 옵션 데이터는 en 경로를 바꿀 수 있다.
		
		Pad1과 PadN 등 2개의 채워넣기 옵션은 차후의 옵션을 정렬해야 할 때 헤더를 채워넣어서 8옥텟을 배수의
		길이로 만들어야 할 때 사용됩니다. Pad1 옵션은 헤더의 옵션 영역에 1옥텟을 채워넣기 위해서 사용합니다.
		채워넣을 것이 1옥텟보다 많으면 PadN 옵션을 사용해야 합니다.
		
		Pad1 옵션(정렬 요구 사항 : 없음)
		
		| 0 (8bit) |
		
		/* Pad1 옵션의 형식은 특별한 경우로서 길이와 값 필드가 없다. */
		
		PadN 옵션 (정렬 요구 사항 : 없음)
		
		| 1 (8bit) | 옵션 데이터 길이(8bit) | 옵션 데이터 |
	
	
	

	No Next Header : IPv6 헤더나 확장 헤더의 Next Header 필드에 값 59가 사용되면 그것은 그 헤더 다음에 아무것도 
	없다는 뜻입니다. IPv6의 Payload Length 필드가 그 Next Header 필드에 59를 간직한 헤더의 끝을 넘어선 옥텟을 나타내면
	그 옥텟은 무시되고 패킷이 발송되어도 변경되지 않고 전달됩니다.
	


	Hop-by-Hop Option Header : 패킷의 전달 경로를 따라 모든 중간 노드에 필요한 선택적 정보를 운반하기 위해 쓰입니다.
	이 헤더는 Next Header의 값이 0인 것을 보고 식별하며 다음과 같은 형식을 가지고 있습니다.
	
	| Next Header (8bit) | Hdr Ext Len (8bit) | Option |
	
	< IPv6 Hop-by-Hop Options 헤더 >
	
		각 필드가 지니는 의미는 다음과 같습니다.
		
		* Next Header : Routing 헤더 바로 다음에 오는 헤더의 유형을 식별하는 8비트 선택자
		
		* Hdr Ext Len : 8bit unsigned int. 이것은 처음 8 옥텟을 제외하고 Routing 헤더의 8옥텟 단위 길이를 가집니다.
		
		* Option : 전체 Destination Options 헤더 길이가 8옥텟의 정수 배수인 가변 길이의 필드입니다.
		옵션 값은 Type-Length-Value(TLV)형식을 사용하는 부호입니다.
		
		
	Pad1과 PadN 옵션 외에 Hop-by-Hop 옵션과 함께 Jumbo Payload 옵션이 정의 되어 있습니다.
	
	
	
	Jumbo Payload 옵션에 대한 정렬 요구사항은 4n+2입니다. 이 정렬은 옵션의 시작이 헤더의 시작으로부터 4옥텟의 배수에
	2를 더한 것이어야 한다는 뜻입니다. Jumbo Payload 옵션은 65,535 옥텟보다 긴 페이로드로 IPv6 패킷을 보내기 위해
	사용됩니다. Jumbo Payload Length 필드는 32비트 폭으로 되어 있으며 IPv6 헤더는 제외하고 Hop-by-Hop Options 헤더는
	포함한 옥텟 단위의 패킷 길이를 나타냅니다. Jumbo Payload 길이는 65,535보다 길어야 하며 작거나 같을 경우 ICMP
	Parameter Problem 메세지 Code 0이 패킷의 출발지에 보내집니다. 이 메세지는 유효하지 않은 Jumbo Payload Length 필드의
	상위 옥텟을 가르킵니다. 또한 IPv6 헤더의 Payload Length 필드는 Jumbo Payload 옵션을 운반하는 모든 패킷에서 0으로
	설정해야 합니다. 유효한 Jumbo Payload 옵션이 있고 IPv6 Payload Length 필드가 0이 아닌 상태에서 패킷을 받으면
	ICMP Parameter Problem 메세지 Code 0이 패킷의 출발지에 보내집니다. 이 메세지는 Jumbo Payload 옵션의 Option
	Type 필드르 가르킵니다.
	
	

	인증헤더 : 이 헤더는 IP 데이터그램의 강력한 무결성과 인증을 제공하기 위해서 사용됩니다.
	IPv6인증 헤더는 IP 데이터그램에 인증정보를 추가하여 보안을 제공합니다. 이 인증정보는 IPv6 데이터그램에 인증정보를
	추가하여 제공합니다. 이 인증정보는 IPv6 데이터그램이 통과하는 동안에 변하지 않는 모든 필드를 사용하여 계산됩니다.
	홉 개수, 활동 시간 동안에 변해야 할 필드나 옵션은 인증 데이터의 계산에서 0으로 간주합니다. 인증헤더 바로 앞에 있는
	IPv6 헤더는 그 Next Header 필드에 값 51을 간직하고 있습니다. 인증 헤더는 패킷의 변경 여부를 탐지하기 위해 사용됩니다.
	하지만 그것은 패킷을 암호화하기 위한 기능을 가지고 있지는 않습니다. 패킷 암호화는 IPv6 Encrypted Security Payload
	헤더에서 처리됩니다.
	
	|  Next Header(8bit)  | 길이 (8bit)  | 예약 (16bit) |
	| 	보안 매개변수 색인 (32 bit)		|
	|	인증 데이터 (임의의 32비트 워드 수)	|
	
		< IPv6 인증 헤더 >

	인증 헤더 필드는 다음과 같은 의미를 가지고 있습니다.
		
		* Next Header : 이 필드는 Routing 헤더 바로 다음의 헤더 유형을 식별하는 8bit 선택자입니다.
		
		* 길이 : 이 필드는 8bit 폭을 가지고 있으며 인증 데이터 필드의 길이를 지정합니다. 그 최소값은 0워드이며
		인증 알고리즘이 사용되지 않는 특별한 경우에만 사용합니다.
		
		* 예약 : 이 필드는 16비트 폭을 가지고 있으며 미래에 사용하기 위해서 예약되어있습니다. 그것은 송신자가
		모두 0으로 설정해야 합니다. 이 값은 인증 데이터 계산에 포함되지만 수신자 쪽에서는 그것을 무시합니다.
		
		* 보안 매개변수 색인 : 이것은 데이터그램의 보안 연관성을 식별하는 32비트 임의 값입니다. 보안 매개변수
		색인 값 0은 보안 연관성이 없는 것을 나타내기 위해 예약되어 있습니다. 범위 1부터 255까지의 보안 매개변수
		색인 값들은 Internet Assigned Numbers Authority (IANA)에서 미래에 사용되도록 예약되어 있습니다.
		예약된 SPI 값은 특별히 할당된 SPI 값의 사용을 RFC에 공개적으로 지정한 경우를 제외하고는 IANA에서
		할당해 주지 않습니다.
		
		* 인증 데이터 : 이것은 가변 길이 필드이지만 언제나 32비트 워드의 자연수이며 이 패킷에 대해 계산된 인증 데이터를
		간직하고 있습니다.


	암호화 보안 페이로드 헤더 : IPv6 암호화 보안 페이로드(ESP)는 IP 데이터그램의 무결성과 비밀성을 제공하기 위해 사용됩니다.
	거절금지(nonrepudiation)와 통신량 분석으로 부터의 보호는 ESP에서 제공되지 않습니다. IPv6 인증 헤더는 특정 인증
	알고리즘에 사용할 경우에만 거절 금지를 제공할 수 있습니다. IP 인증 헤더는 인증을 제공하기 위해 ESP와 함께 사용할 수 있습니다.
	IP 인증 헤더는 인증을 위해 설계되었고 ESP 헤더는 비밀성을 위해 설계되었으므로 비밀성 없이 무결성과 인증이 필요한
	응용프로그램은 ESP 대신 인증 헤더를 사용해야 합니다. ESP는 보호할 데이터를 암호화하고 암호화한 데이터를 캡슐화
	보안 페이로드의 데이터 부분에 넣습니다. 이 메커니즘을 사용하면 운반 계층 세그먼트 또는 전체 IP 데이터그램을 암호화
	할 수 있습니다. ESP는 다음 두 가지 작동 모드를 가지고 있습니다.
	
	터널 모드 ESP
	운반 모드 ESP

	터널 모드 ESP에서, 원본 IP 데이터그램은 캡슐화 보안 페이로드의 암호화된 부분에 놓이고 전체 ESP 프레임은 암호화되지
	않은 IP헤더를 가진 데이터그램에 놓입니다. 암호화되지 않은 IP헤더의 정보는 원본의 안전한 데이터그램을 목적지에 경로
	설정하기 위해 사용됩니다. 암호화되지 않은 IP 경로 설정 헤더는 IP헤더와 캡슐화 보안 페이로드 사이에 포함될 수 있습니다.
	
	운반모드 ESP에서, ESP헤더 IP 데이터그램의 운반 계층 프로토콜 바로 앞에 삽입됩니다. 이 모드에서는 암호화된 IP헤더나
	IP옵션이 없으므로 대역폭이 절약됩니다.
	
	| IP 헤더 | 다른 IP 헤더들 | ESP 헤더 | 암호화된 데이터 |
	|------암호화 않됨------|---------암호화됨---------|
	
	< ESP 헤더의 레이아웃 >
	
	
	
	| 보안 페이로드 식별자(SPI) 32 bit	|
	| 불투명 전송 데이터, 가변길이	|
	
	< ESP 헤더의 형식 >


	ESP는 IP헤더 뒤와 마지막 운반 계층 프로토콜 헤더 앞의 어디에나 나타날 수 있습니다. ESP 헤더 바로 앞에 오는 헤더는
	그 Next Header 필드에 값 50가지고 있어야 합니다. ESP는 암호화 되지 않은 헤더와 그 뒤에 오는 암호화된 데이터로 구성될 수
	있습니다. 암호화된 데이터는 보호된 ESP헤더 필드와 보호된 사용자 데이터 둘을 다 포함하고 있으며 후자는 전체 IP 데이터그램
	또는 운반계층 프로토콜입니다.
	
	암호화와 인증 알고리즘 및 그것들과 관련된 불투명 전송 데이터의 정밀한 형식을 변형(transform)이라 합니다. ESP형식은
	새로운 또는 추가되는 암호법 알고리즘을 미래에 새 변형을 지원하도록 설계되었습니다.
	
	SPI 필드는 이 데이터그램의 보안 연관성을 식별하는 32bit 임의의 값입니다. 보안 연관성이 설정되어 있지 않으면 SPI 필드의
	값은 0으로 설정됩니다. SPI는 다른 보안 프로토콜에 사용되는 보안 연관성 식별자(SAID)와 비슷합니다. 0부터 255까지의
	SPI값은 IANA에서 미래에 사용하기 위해 예약해 놓았습니다. SPI는 유일하게 전송과 무관한 필수 필드입니다.


- 주소 표기법

이진수로 표시한 아래의 IPv6를 보고 생각해 봅시다.

01011000 00000000 00000000 11000101

11100011 11000011 11110001 10101010

01001000 11100011 11011001 00100111

11010100 10010101 10101010 11111110

위의 IPv6 주소는 다음과 같습니다.

88.0.0.192.227.195.241.170.72.227.217.39.212.149.170.254

점 십진 표기법을 사용하였을 경우 간결하지 않음을 알 수 있습니다.

그래서 설계자들은 콜론 16진 표기법을 사용하기로 결정하였습니다.

16진 값은 콜론(:) 문자로 분리된 16bit로 표기합니다.

위의 IPv6 주소를 16진 표기법으로 다시 나타내어 보겠습니다.

5800:00C3:E3C3:F1AA:48E3:D923:D495:AAFE

훨씬 더 효율적으로 표기할 수 있음을 알 수 있습니다.

이것을 더욱 효율적으로 표기하기 위해서 세 가지 약식 표기 기법을 사용할 수 있습니다.

첫 째는 앞부분의 0을 생략할 수 있도록 한 것입니다.

다음과 같은 IPv6 주소가 있다고 합시다.

48A6:0000:0000:0000:0000:0DA3:003F:0001

0을 제거하여 표현하면 다음과 같이 됩니다.

48A6:0:0:0:0:DA3:3F:1

두 번째는 0 압축을 사용하는 방법입니다.

반복되는 0의 문자열을 겹콜론(::)으로 처리하는 방법입니다.

48A6:0:0:0:0:DA3:3F:1

0을 제거한 위 주소를 겹콜론(::)을 사용하여 표현하면 다음과 같이 됩니다.

48A6::DA3:3F:1

하지만 겹콜론을 한 번 이상 사용하면 해석이 모호해지므로 잘못된 것입니다.

마지막으로  겹콜론을 접두어나 접미어로 사용하는 방법입니다.

170.1.1.1의 IPv6 표시는 다음과 같습니다.

0:0:0:0:0:0:AA01:101

이것은 다음과 같이 표현이 가능합니다.

::AA01:101


IPv4와 IPv6 노드의 혼합환경을 취급하는 형식은 다음과 같습니다.

X:X:X:X:X:X:d.d.d.d

X -> hex(16진), d -> decimal(10진)


0:0:0:0:0:0:210.12.34.28

위 주소는 ::210.12.34.28로 표현이 가능하며 IPv4 네트워크 인프라 구조를 경유해서 다른 IPv6 호스트와 통신하는 경우에

표현되는 방식입니다.


0:0:0:0:0:FFFF:141.83.25.192

위 주소는 ::FFFF:141.83.25.192로 표현 가능하며 IPv4만을 지원하는 호스트와 통신하는 IPv6 호스트의 표현방식입니다.
	
	
	
- 주소 종류

IPv6는 3가지 Address 유형에 관한 규칙을 가지고 있습니다.



 유니캐스트(Unicast)
 
 단일 인터페이스를 지정하며 Unicast 주소로 보내진 패킷은 그 어드레스에 해당하는 인터페이스로 전달됩니다.
 
 IPv6에서 Unicast 주소를 할당하는 형태는 여러가지가 있습니다. 그 종류로는 global provider based Unicast 주소,
 
 geographic based Unicast 주소, NSAP 주소, IPX hierarchical 주소, site-local-use 주소, link-local-use 주소,
 
 IPv4-capable host 주소 등이 있으며 앞으로 여러 형태가 추가 될 것 입니다. Unicast 주소는 내부 구조를 갖는 주소와
 
 내부 구조를 갖지 않는 주소로 나눠집니다. 단순한 IPv6노드는 주소의 내부 구조를 인식하지 못하므로 내부 구조가 없는
 
 주소가 사용되고 IPv6 노드의 성능이 좋아질수록 보다 복잡한 내부 구조를 인식하게 됩니다.
 
| node address(128bit) |

 <내부 구조가 없는 Unicast 주소>

| subnet prefix(n bits) | interface ID(128-n bits) |

<단순한 내부 구조를 갖는 Unicat 주소>
 
 Unicast의 예를 들면 다음과 같은 것들이 있습니다.
 
LAN이나 IEEE 802 MAC 주소를 갖는 환경에서의 일반적인 unicast 주소의 구조는 다음과 같습니다.

여기서 48비트 인터페이스 ID는 IEEE 802 MAC 주소를 지시합니다.

| Subscriber prefix(n bits) | Subnet ID (80 - n bits) | Interface ID (48bits) |

<MAC 주소를 갖는 Unicast 구조>

또 하나의 Unicast주소 구조의 예로 subnet ID가 area ID와 subnet ID 로 분리된 경우입니다.

이러한 구조는 내부 계층 구조에 부가적인 계층이 요구되는 곳에서 유용합니다.

| Subscriber prefix(s Bits) | area ID (n bits) | subnet ID (m bits) | Interface ID (128 - n - m bits) |

 <area ID와 subnet ID로 분리된 Unicast 주소 구조의 예>
 
 
 
 
 애니캐스트(Anycast)
 
 여러 노드들에 속한 인터페이스의 집합을 지정하며 Anycast 주소로 보내진 패킷은 그 어드레스에 해당하는
 
 인터페이스들 중 하나의 인터페이스에 전달됩니다. 전달되는 인터페이스는 라우팅 프로토콜의 거리 측정에
 
 의해 같은 Anycast 주소를 갖는 인터페이스 중에서 가장 거리가 짧은 인터페이스에 전달됩니다.
 
 Anycast 주소는 Unicast 주소공간으로 부터 할당되어졌고 Unicast 주소구조를 갖습니다. 따라서 Anycast주소는
 
 구문적으로 Unicast주소와 구별할 수 없습니다. IPv6 anycast주소는 다음의 제한이 있습니다. Anycast주소는
 
 IPv6 패킷의 소스 주소로 사용될 수 없으며 IPv6 호스트에 할당 될 수 없고 단지 IPv6 라우터에만 할당될 수 있습니다.
 
 | 0 subnet prefix (n bits) | 000000000000000000 (128 - n bits) |
 
 <Subnet-Router anycast 주소 구조>
 
 subnet prefix는 특정 링크를 명시합니다. 이러한 anycast 주소는 interface 인식자가 0으로 설정된 unicast 주소와 
 
 구문적으로 동일한 것입니다. Subnet-Router anycast주소로 전송되는 패킷은 subnet상의 하나의 라우터에 전달될
 
 것이며, 모든 라우터는 Subnet-Router anycast 주소 전송을 제공해야 합니다.
 
 
 


 멀티캐스트(Multicast)
 
 여러 노드들에 속한 인터페이스의 집합을 지정하며 Multicast 주소로 보내진 패킷은 그 어드레스에 해당하는
 
 모든 인터페이스에 전달된다. IPv6에는 broadcast 주소는 없고, 그 기능은 Multicast 주소로 대체됩니다.
 
 Muticast주소는 주소의 상위 Octet이 FF(11111111)값을 가짐으로써 unicast주소와 구별됩니다.
 
 | 11111111 (8bits) | flag (4bits) | scop (4bits) | group ID (112bits) |
 <Multicast 주소 구조>
 
 Flag의 상위 3개의 bit는 예약되었으며 0으로 초기화되어 있고 하위 1bit(T)는 다음의 위미를 가집니다.
 
 T = 0 : 영구히 할당받은 Multicast 주소임을 지시합니다. ("well-known")
 T = 1 : 일시적으로 할당받은 Multicast 주소임을 지시합니다. ("transient")
 
 scope는 4bit multicast scope 값이며 multicast 그룹의 범위를 제한하는데 사용며 다음과 같은 값을 갖습니다.
 
 0	예약됨
 1	node-local scope
 2	link-local scope
 3	(할당되어 있지 않음)
 4	(할당되어 있지 않음)
 5	site-local scope
 6	(할당되어 있지 않음)
 7	(할당되어 있지 않음)
 8	organization-local scope
 9	(할당되어 있지 않음)
 A	(할당되어 있지 않음)
 B	community-local scope
 C	(할당되어 있지 않음)
 D	(할당되어 있지 않음)
 E	global scope
 F	예약됨
 
 group ID는 주어진 범위(scope) 내에서 영구적이거나 일시적인 Multicast 그룹을 지정하게 됩니다.
 "영구적"이란 것은 할당받은 multicast의 주소가 범위와 무관하다는 뜻이며 "일시적"이란 것은 할당받은 Multicast의 주소가
 단지 주어진 범위 내에서만 의미가 있다는 것을 말합니다. Multicast 주소는 IPv6 데이터그램의 소스 주소로 사용될 수 없습니다.
 



- 이 Tutorial을 만드는데 사용된 문서

TCP/IP 완전정복		KARANJIT S. SIYAN     	성안당

Network Programming 	신동규, 신동일		ITC
신고
0  Comments,   0  Trackbacks
댓글 쓰기

티스토리 툴바