떠오르는 차세대 IP 기술: IPv6 (2회)
지난 호에서는 IPv6가 나오게 된 가장 직접적인 배경, IPv6가 IPv4에 비해 가지는 장점, 그 리고 IPv6의 주소 체계를 설명했습니다. 이번 호에서는 지난 호에 이어, IPv6의 실제 패킷 이 어떻게 구성되는지, 특히 어떻게 만들었길래 IP 패킷 처리가 고속화될 수 있는지 보겠습 니다. 그리고 이제 IP 프로토콜을 도와주는 여러 가지 프로토콜에 대해서 알아 보겠습니다.
ICMP는 계속 IP를 도와주고 있구요, 기존의 IGMP 기능 및 ARP 기능들까지 합쳐 놓은 강 력한 프로토콜이 된 것을 보시구요. 그 밖에 DNS, 라우팅 프로토콜 들을 알아 보겠습니다.
이어서, 실제 IPv6 라우터를 어떻게 설정할 수 있는지, 그리고 IPv6 프로그래밍이란 어떤 것이 IPv4 때와 틀리고, 어떤 API 들이 있는지 알아 보겠습니다. 그리고 마지막으로 IPv4 네트웍을 엮기 위한 방법과 어떻게 자연스럽게 IPv6로 진화하는지, 그리고 진화해서 결국 어떤 세상이 되는지 상상해보기로 하겠습니다.
IPv6 패킷의 기본 해더 들여다보기.
이제 IPv6 기본 헤더 (옵션들을 하나도 넣지 않은 경우로 40 바이트입니다) 는 어떻게 생 겼는지 살펴보겠습니다. 개념들을 먼저 보고, 그 개념들이 실제 어떤 헤더 내용으로 표현되 었는지 살피는 것이 대부분의 방법이지만, 여기서는 반대로 접근함으로써 빠르게 이해할 수 있도록 해보겠습니다. 우선 다음 그림은 IPv6 패킷의 해더 포맷입니다. 우선 쉽게 알 수 있 는 것이 Source Address, Destination Address 모두 128비트일 것입니다. 그럼 우선 각각 에 대한 간단한 설명을 해보죠.
(1) version (4비트): IPv6는 version 6이므로 6입니다.
(2) Traffic Class (8비트)와 flow label (20비트): 두 필드 모두 QOS를 제공하기 위한 필드 입니다. Traffic Class의 값은 upper layer에서 setting하거나 읽을 수 있다는 점에서, upper layer (TCP나 UDP)의 application QOS를 IP layer 이하단의 전송 계층에게 요구하는 경우를 위한 것입니다. Flow label은 Traffic Class를 받아서, 이를 source에서 destination 까지의 모든 라우터들에서 만족하기 위해 지정하는 것입니다. 물론 RSVP (reservation protocol) 등 이 미리 모든 라우터를 훑으면서 flow label을 setting 해야 하겠습니다. Flow label이 일단 setting된다는 것은 어떤 QOS를 만족하는 virtual path가 만들어졌다는 의미가 되는 것입 니다.
(3) payload length (16비트): 현재의 헤더 뒤에 따라오는 모든 payload의 바이트 수를 말합 니다. 주의할 사항은 Destination Address 뒤에 올지도 모르는 Option/Extension 필드 값도 역시 payload로 계산된다는 점입니다. 그렇게 한 이유는? 물론 간단하기 때문입니다. 아래의 그림을 보면, 기본 헤더가 40바이트이고, 뒤에 오는 헤더들의 크기를 모두 더한 값이 payload의 값이 됩니다. 그럼 65535 바이트가 넘는 payload는 어떻할까요? 65535 바이트 보다 큰 payload를 Jumbogram이라고 부르고, 처리하는 방법이 따로 있습니다. 뒤의 Jumbo payload Hop-By-Hop 옵션에서 설명하기로 하겠습니다.
(4) 다음 헤더 지정 (Next Header) (8비트): Destination Address 필드 뒤에 따라오는 옵션 헤더의 타입을 결정하게 됩니다. 예를 들어, 다음 헤더 (Next Header) 값이 60이면 Destination Field 뒤에 Destination Option 헤더가 온다는 의미입니다. 몇가지 더 예를 들어 보면 다음과 같습니다. 첫번째 경우는 IPv6 헤더 뒤에 TCP 헤더가 바로 오는 경우이고, 뒤 의 경우는 Routing 헤더, 조각 (Fragment) 헤더를 더 첨가해서 보내는 경우입니다.
위와 같이 보낼 경우에 실제로 다음 헤더 (Next Header) 값은 다음 그림과 같이 표현될 것 입니다. TCP 헤더는 6, Routing 헤더는 43 값을 쓰고 있습니다.
다음 헤더 (Next Header) 필드에서 표시하는 다음에 올 헤더들의 타입들은 다음과 같이 정 리할 수 있습니다.
- 0: Hop-by-Hop 옵션 헤더:
source에서 destination까지 가는 동안 모든 라우터에서 봐야 하는 옵션입니다.
- 4: IP (Internet Protocol):
뒤에 오는 헤더는 IPv4 헤더입니다. 이 값을 쓰면, IPv6 패킷으로 IPv4 패킷을 보내고 받을 수가 있을 것입니다.
- 6: TCP (Transmission Control Protocol) 헤더:
뒤에 오는 헤더는 TCP 헤더.
- 17: UDP (User Datagram Protocol) 헤더:
뒤에 오는 헤더는 UDP 헤더.
- 41: IPv6:
뒤에 오는 헤더는 IPv6 헤더입니다. IPv6로 IPv6를 보내는 경우에 사용합니다.
- 43: Routing 헤더:
IPv4에서 있던 Loose Source Routing (source에서 destination까지 path 중에서 어떤 라우터는 꼭 거쳐가라고 지정하는 것)을 구현하기 위한 필드입니다.
- 44: 조각 (Fragment) 헤더:
Path-MTU가 작아 잘라보내야 하는 경우에 씁니다. 될 수 있으면 응용 프로그램에서 미리 잘라주 는 것을 추천합니다.
- 45: Inter-Domain Routing 헤더:
라우팅 프로토콜 헤더가 옵니다.
- 46: RSVP (Reservation Protocol) 헤더:
RSVP를 사용하는 경우입니다.
- 50: ESP (Encapsulating Security Payload) 헤더:
보안 사항을 위함. IPSec에 정의됩니다.
- 51: AH (Authentication Header) 헤더:
보안 사항을 위함. IPSec에 정의됩니다.
- 58: ICMP (Internet Control Message Protocol) 헤더:
뒤에 오는 헤더는 ICMP 헤더.
- 59:
뒤에 헤더 없음.
- 60: Destination Option 헤더:
오로지 Destination에서만 봐야 하는 옵션입니다.
(5) Hop Limit (8비트): 라우터를 하나 거칠 때마다 1씩 줄어드는 값으로 IPv4의 TTL (time to live) 값과 유사합니다. 0이 되면 해당 라우터에서 ICMP Time Exceeded 가 발생되겠죠.
(6) Source Address (128비트), Destination Address (128비트): 명확합니다.
이제 기본 헤더값의 크기를 모두 더해보면, 처음 Version, Traffic Class, Flow Label, Payload Length, 다음 헤더 (Next Header), 그리고 Hop Limit를 더해서 64비트가 됩니다. 그리고 두 개의 주소가 각각 128비트입니다. 나중에 설명되지만, 대부분의 IPv6 주소는 아래 64비 트가 interface identifier입니다. 그리고 위의 64비트는 prefix로 router에서 받은 값이거 나, 고정된 값을 사용합니다. 한마디로 말해서, IPv6는 기본적으로 64비트 처리가 가능하도 록 만든 것입니다.
프로그래밍을 위한 IPv6 패킷의 기본 해더 들여다보기.
실제로 BSD 계열의 운영체제에서는 <netinet/ipv6.h>에 IPv6 헤더 포맷이 다음과 같이 정 의되어 있습니다. 살펴보면, union 형식이라 처음 8비트가 겹치게 됩니다. 처음 4비트는 버 전 번호이구요. 다음 28비트를 traffic class와 flow label로 쓸 수도 있고, 또는 priority로 쓸 수도 있습니다. 이유는 아직 traffic class와 flow label을 어떻게 설정할 지에 대한 기준 이 없기 때문입니다.
struct ip6_hdr { union {
struct ip6_hdrctl {
uint32_t ip6_un1_flow; /* 20 bits of flow-ID */
uint16_t ip6_un1_plen; /* payload length */
uint8_t ip6_un1_nxt; /* next header */
uint8_t ip6_un1_hlim; /* hop limit */
} ip6_un1;
uint8_t ip6_un2_vfc; /* 4 bits version, 4 bits priority */
} ip6_ctlun;
struct in6_addr ip6_src; /* source address */
struct in6_addr ip6_dst; /* destination address */
};
#define ip6_vfc ip6_ctlun.ip6_un2_vfc
#define ip6_flow ip6_ctlun.ip6_un1.ip6_un1_flow #define ip6_plen ip6_ctlun.ip6_un1.ip6_un1_plen #define ip6_nxt ip6_ctlun.ip6_un1.ip6_un1_nxt #define ip6_hlim ip6_ctlun.ip6_un1.ip6_un1_hlim
#define ip6_hops ip6_ctlun.ip6_un1.ip6_un1_hlim
위에서 ip6_unl_nxt에 올 수 있는 값은 다음과 같이 <netinet/in.h에 정의되어 있습니다.
#define IPPROTO_HOPOPTS 0 /* IPv6 Hop-by-Hop options */
#define IPPROTO_IPV6 41 /* IPv6 header */
#define IPPROTO_ROUTING 43 /* IPv6 Routing header */
#define IPPROTO_FRAGMENT 44 /* IPv6 fragmentation header */
#define IPPROTO_ESP 50 /* encapsulating security payload */
#define IPPROTO_AH 51 /* authentication header */
#define IPPROTO_ICMPV6 58 /* ICMPv6 */
#define IPPROTO_NONE 59 /* IPv6 no next header */
#define IPPROTO_DSTOPTS 60 /* IPv6 Destination options */
IPv6 패킷의 기본 해더가 IPv4 기본 헤더와 틀린 점은.
IPv4의 무엇이 없어졌는지? IPv4 패킷의 기본 포맷에서 보이던 헤더 길이 (Header Length) 라든지, 헤더 체크섬 (Header Checksum)은 없어진 것을 볼 수 있습니다. IPv4 패킷의 옵션 패킷에서는 Record Route Option (패킷이 전달되면서 어떤 라우터 경로를 따라가는지를 기 록하는 옵션), Time Stamp Option (패킷 송신 시간 등을 기록), 그리고 Strict Route Option (source에서 destination까지의 모든 라우터를 지정하고, 반드시 그 라우터들을 거쳐가도록 하는 옵션)이 없어졌습니다. Strict Source Route 옵션은 거의 쓰지 않고 실제로도 네트웍 에 너무 큰 제약을 가한다는 측면에서 뺀 것이죠. Time Stamp를 뺀 이유는, 실시간 통신을 위한 flow label 등이 이미 들어가 있고, 또한 실시간 패킷 전송을 위해서는 RTP (real time transfer protocol)이 있는데, RTP 내에 Time stamp 기능 등이 있기 때문입니다.
초점 (어떻게 IPv6는 고속 처리가 가능할 수 있는지?): IPv6는 64비트 단위로 프로토콜이 처리되도록 설계에서 고려하였습니다. 실제로 IPv6 패킷은 100 Gbps 이상의 속도로 진행되 어야 합니다. 이제 조만간 IP over WDM (wavelength division multiplexing)이 도입이 된다면, 간단하고 빠른 라우팅이 더욱 절실해질 것입니다.
IPv6 패킷의 확장 해더 들여다보기
앞에서 살펴본 바와 같이, 다음 헤더 (Next Header)로 지정되어 올 수 있는 옵션 헤더들은 (1) Hop-By-Hop Option 헤더, (2) Routing (Type 0) 헤더, (3) 조각 (Fragment) 헤더, (4)
Destination Option 헤더, (5) Authentication 헤더, (6) ESP (Encapsulating Security Payload) 헤더가 있습니다.
생각해보기: 각각의 Option 헤더들은 왜 만들어졌나?
우선 Hop-By-Hop 옵션이 다른 옵션과 틀린 점은 Hop-by-Hop 옵션만 source와 destination 사이 의 라우터에서 볼 수가 있고, 다른 옵션들은 모두 source에서 만들고, destination에서만 볼 수 있다는 점입니다.
IPv6 패킷의 확장 해더 들여다보기 (Hop-By-Hop 옵션 해더).
우선 Hop-by-Hop 옵션 헤더에는 상세 옵션으로 Jumbo Payload Length 옵션이라는 것이 있 어서, payload가 65535 바이트를 넘는 경우에도 처리할 수 있도록 합니다. 65535 바이트를 넘는 경우에도 length를 지정하게 되면, 빠른 네트웍에서는 거의 분할 (fragmentation)이 일어나지 않고 전송이 됨으로써, 밑의 전송 계층을 최대한 이용할 수가 있는 것이죠.
또한 Router Alert라는 상세 옵션이 있는데, 이 값이 1,2,0인지에 따라, RSVP, AN (Active Network), Multicast Listener Discovery (MLD) 기능을 수행하게 됩니다. Source 노드에서 destination 노드까지 QOS를 보장하기 위해서는, source에서 destination까지 가면서 거치 게 되면 라우터에 흔히 말하는 찜을 해둘 필요가 있습니다. 찜을 해주는 대표적인 프로토콜 이 RSVP라는 것이고, RSVP는 각 라우터에 QOS를 보장하기 위해서 flow label 등으로 예약 을 하게 되고, 한번 예약하면, 어느 시간동안은 라우터에 soft state (예약했다는 증거)가 남 아있게 됩니다.
IPv6 패킷의 확장 해더 들여다보기 (라우팅 해더).
Routing 헤더는 loose source 라우팅을 지원하게 됩니다. 즉 어떤 라우터를 지나갈지를 source에서 지정함으로써, 라우팅 최적화를 해줄 수 있는 것이죠. 비단 라우팅 최적화 뿐만 아니라, 어떤 노드를 반드시 지나가도록 만드는 경우에도 유용합니다. 라우팅 헤더는 IPv4 의 loose source routing (어떤 노드는 꼭 거쳐가도록 강제)과 record route (지난 라우터들 을 패킷에 기록해둠) 옵션을 합친 것과 비슷합니다.
참조: Loose source routing이란 무엇인가?
다음 그림에서 보는 바와 같이, S에서 D로 패킷을 전달하는 경우, A와 B를 거치도록 지정할 수 있습니다. S에서 D까지의 모든 라우터를 다 지정하는 경우를 strict source routing이라고 부르는 데 잘 사용하지 않습니다. 왜냐하면, 그림에서 보듯이 loose source routing을 사용하면, S에서 A 까지 가는 경우와 B에서 D로 가는 경우는 어떤 라우터를 거쳐가도 마음대로이니까요. 네트웍에 서 상태를 보아서 적절한 라우터를 거쳐서 갈 수가 있습니다. 또한 strict source routing은 중간 의 모든 라우터를 미리 안다고 가정하는 것인데, 만약 예전에 있던 라우터가 없어지면, 라우팅이 안 되는 불상사가 생길 수가 있습니다.
.
Mobile IP는 움직이는 이동체를 위한 IP입니다. 어떤 노드에서 움직이는 노드로 IP 패킷을 보내려면 반드시 HA (home agent)라는 곳에 물어봐야 현재 위치를 알 수 있습니다. 움직이 는 노드는 반드시 움직일 때 HA에 자신의 위치를 알려주니까요. 한번 HA에 물어본 다음에 는 바로 보낼 수가 있습니다. 그런데 이동체가 다른 곳으로 가버리는 경우에, 예전의 위치 로 계속 IP 패킷을 보낼 수가 있죠. 그런 경우에, 예전의 위치로 Binding Update 등을 보내 서 쓸데없이 패킷이 가지않도록 해줍니다. 그런 경우에, Routing 헤더가 유용하게 쓰일 수가 있습니다.
라우팅 헤더는 다음 그림과 같이 생겼습니다. 라우팅 헤더 중에서 Routing Type이 0인 것을 Type 0 라우팅 해더라고 부르고, Type 0 라우팅 헤더의 모양은 일반적인 라우팅 헤더 그림 밑에서 볼 수 있습니다. Type-Specific 부분이 Reserved 부분과 Address 벡터 부분으로 바 뀐 것 밖에는 없죠.
이제 라우팅 헤더가 어떻게 동작하는지를 보기 위해, RFC에서 설명하고 있는 바와 같이, S 라는 source에서 I1, I2, I3을 거쳐 D라는 destination까지 가능 경우를 보이겠습니다.
Loose source routing이니까 S와 D 사이의 모든 라우터를 지정한 것은 아니고, 지나다 보니 까 I1, I2, I3을 지나게 된다고 생각하시면 됩니다.
처음 S에서 I1으로 갈 때.
주의할 점은 Destination Address가 I1이라는 점입니다. 일단은 I1까지 가도록 해야 모든 Address 벡터에 들어있는 곳을 통과할 수 있겠죠. 또한 Hop-By-Hop 옵션을 제외하고서는 모두 Destination에서만 처리된다고 했던 것을 기억하면 반드시 Destination Address가 I1이 되어야 겠습니다.
처음 I1에서 I2으로 갈 때
이제 가야 할 곳은 I2이고, I1은 이미 지나왔다는 정보를 Address 벡터 Address[1]에 담아둡니 다. 당연히 한 군데 통과했기 때문에 Segment Left는 하나 줄입니다.
처음 I2에서 I3으로 갈 때.
이제 가야 할 곳은 I3이고, I2은 방금 지나왔다는 정보를 Address 벡터 Address[2]에 담아둡니 다. 당연히 한 군데 더 통과했기 때문에 Segment Left는 하나 더 줄입니다.
처음 I3에서 D로 갈 때.
이제 가야 할 곳은 D이고, I3은 이미 지나왔다는 정보를 Address 벡터 Address[3]에 담아둡니 다. 당연히 한 군데 더 통과했기 때문에 Segment Left는 하나 더 줄입니다. 이제 D에 도착하게 되면 지금까지 지나 온 곳들 Address[1], Address[2], Address[3]이 남게 됩니다. 참고로, D에 도 착하게 되면, Destination Option에 정의된 사항들이 실행될 것입니다.
IPv6 패킷의 확장 해더 들여다보기: 조각 (FRAGMENT) 해더.
Path MTU Discovery를 수행해서, Path MTU가 얼마인지 안 다음에, source에 있는 응용 계 층에서 Path MTU 사이즈에 맞추어서 패킷을 보내주는 것이 가장 좋은 방법이긴 하지만, 응 용 프로그램이 못한다고 하면, source에 있는 IP 계층에서 해야 할 것입니다. 그러한 기능을 제공해주는 것이 조각 (Fragment) 헤더입니다.
그럼 실제로 큰 패킷이 어떤 식으로 작은 패킷으로 조각 (FRAGMENT)이 되는지 다음 그림 에서 보겠습니다. 다음 그림과 같이, 패킷은 기본 헤더 등이 있는 더 이상 분할 (FRAGMENT) 안되는 부분과, 분할 가능한 부분으로 나눌 수 있습니다. 이제, 조각 (FRAGMENT) 헤더를 사용해서 나눈 것은 아래 그림에서 확인할 수 있습니다.
원래 패킷입니다.
나뉘어진 패킷입니다.
쉽게 생각할 수 있듯이, 조각 (FRAGMENT) 헤더에는 이번이 몇번째 조각인지, 혹은 이번이 마지막 조각인지 아닌지 등의 정보가 들어있을 것입니다. 또한 destination에서 조각들을 조 립하려면, 이 조각이 원래 어떤 패킷이었는지를 가르키는 번호도 있어야하겠죠. 다음 그림 은 조각 (FRAGMENT) 헤더의 포맷을 나타냅니다. NEXT 헤더는 이번 조각 (FRAGMENT) 헤더 뒤에 오는 헤더 타입을 나타내고 (8비트입니다), RESERVED (8비트), FRAGMENT OFFSET (13비트)는 이번 조각이 몇번째 조각인지, RES (2비트), M (1비트)는 이번 조각이 마지막 조각인지 아니면 뒤에 또 조각이 있는지를 나타내고, Identification (32비트)은 원래 이 조각이 어떤 패킷의 조각인지 원래 패킷 번호를 적어주는 것입니다.
주의할 점은 FRAGMENT OFFSET의 값이 3이라면, 이는 원래 패킷의 3*8 바이트번째를 의미합니다. FRAGMENT OFFSET의 단위는 바이트가 아니라, 8 바이트 단위입니다.
FRAGMENT OFFSET이 0이라면 패킷의 제일 처음 조각이겠죠. 반대로 M 비트가 1이면, 이 조각은 패킷의 맨 마지막 조각이겠죠.
어떤 패킷이 조각 조각 나뉘어서 가면, 아마도 한 패킷이 간 것과 달리, 각 조각들이 따로 따로 들어오기 때문에 destination에서 조립하다가 중간에 조각이 하나 안 들어온 것이 있 어서 멈추는 경우도 발생할 것입니다. 그런 경우엔, Destination에서는 ICMP FRAGMENT REASSEMBLY TIME EXCEEDED 메시지를 source에게 보내주게 됩니다.
실전 IPv6 라우터 설정.
실제 IPv6가 구현된 라우터에서 어떤 식으로 IPv6 설정을 잡아주는지에 대해, 가장 많이 쓰인다고 생각하는 CISCO 라우터에 대해서 살펴보기로 하겠습니다. 우선 설정할 라우터는 기본적으로 link-local 주소와, 부가적으로 global 주소를 가진다고 하겠습니다.
(1) 우선 라우터에서 IPv6 unicast 패킷을 forwarding 할 수 있도록 합니다.
ipv6 unicast-routing
(2) 이제, 라우터에 물린 Ethernet 인터페이스 카드 (여기에서는 첫번째 Ethernet 카드) 의 IPv6 설정을 잡아줍니다. 인터페이스의 global address를 구성하기 위한 prefix는 3ffe:c00:c18:1::/64로 잡아주고, 밑의 64비트는 Ethernet 카드의 MAC 주소에서 EUI64 포맷으로 만들어주라고 지정합니다.
interface ethernet 0
ipv6 address 3ffe:c00:c18:1::/64 eui-64
(2) 이제 라우터에서 설정된 값들을 표시해봅니다. 중간에 보면, 현재 이 라우터에 자동적으 로 link-local 주소가 붙었고, 주소는 FE80::260:3EFF:FE47:1530인 것을 볼 수 있습니다.
그리고 밑의 메시지들을 살펴보면, 아직까지 라우터에서 address configuration에 대한 지정 사항이 내려오지 않았기 때문에, 그대로 auto-configuration으로 잡고 있습니다.
Router# show ipv6 interface ethernet 0
Ethernet0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::260:3EFF:FE47:1530 Global unicast address(es):
3FFE:C00:C18:1:260:3EFF:FE47:1530, subnet is 3FFE:C00:C18:1::/64 Joined group address(es):
FF02::1 FF02::2
FF02::1:FF47:1530 FF02::9
MTU is 1500 bytes
ICMP error messages limited to one every 500 milliseconds ND reachable time is 30000 milliseconds
ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds Hosts use stateless autoconfig for addresses.
IPv6 네트웍을 조정하는 파수꾼: ICMPv6.
ICMP (Internet Control Message Protocol)은 IPv4에서도 IP를 감독하고, IP 네트웍이 잘 유지되도록 힘쓰는 강력한 수단이었습니다. IPv6에서는 아예 ICMP가 IGMP (Internet Group Management Protocol)이라는 Multicasting 그룹을 관리하는 부분과, ARP/RARP (Address Resolution Protocol, Reverse-ARP)이라는 IP 주소를 link-layer 주소 (또는 MAC 주소)로 상호 변환하는 기능들을 모두 모으게 되었습니다. 아래 그림은 전체적인 ICMPv6에 서 다루는 메시지들을 정리했습니다.
그럼 우선 전체적인 ICMPv6를 살펴보기 전에, 기본적인 기능들을 살펴보도록 하겠습니다.
ICMPv6의 기본적인 기능이라면, IP가 제대로 동작하는지 검사하는 기능일 것입니다. PING 명렁어로 어떤 컴퓨터가 살아 있는지를 검사하려면, 실제로는 ICMP ECHO REQUEST가 날 라가게 됩니다. 살아 있다면 ECHO REPLY를 보낼 것입니다. 하나하나 정리해보겠습니다.
INFORMATION 메시지의 ECHO REQUEST와 ECHO REPLY는 PING이라는 프로그램에서 널리 쓰이고 있듯이, 어떤 인터페이스가 현재 작동 중인지 알아 볼 때 유용합니다. TIME EXCEEDED 메시지는 TRACEROUTE 등의 응용프로그램에서 사용할 수 있습니다.
ERROR 메시지는 (1) DESTINATION UNREACHABLE, (2) PACKET TOO BIG, (3) TIME EXCEEDED, (4) PARAMETER PROBLEM이 있습니다. INFORMATIONAL 메시지는 ECHO REQUEST와 ECHO REPLY가 있습니다.
DESTINATION UNREACHABLE 메시지는, 보낸 패킷이 제대로 갈 수 없을 때, 라우터나 또는 source 노드에서 발생시킵니다. 어떤 경우에 갈 수 없는지 보면, (1) 패킷의 목적지에 맞는 다음 목적지가 라우터에 정의되어 있지 않는 경우입니다. (0: no route to destination) (2) 패킷이 보안 관리 등의 이유로 못 가는 경우입니다. (1: administratively prohibited) (3) link specific한 에러가 발생해서 못 가는 경우입니다. (address unreachable) (4) 상대편 컴 퓨터의 해당 port가 없는 경우입니다 (4: port unreachable).
PACKET TOO BIG 메시지는 중간의 라우터에서 패킷 사이즈가 라우터에 물려 있는 네트웍 의 MTU 보다 큰 경우에 발생시킵니다. TIME EXCEEDED 메시지는 중간의 라우터에서 패 킷을 받아서 HOP LIMIT를 하나 줄이고 보니, HOP LIMIT가 0으로 된 경우에 발생시킵니 다. PARAMETER PROBLEM 메시지는 패킷을 받아보니 헤더 등이 엉망일 때 발생합니다.
방금 전에 본 표에서는 INFORMATION과 ERROR 메시지 외에도 많은 메시지가 있습니다.
하지만 실제로 RFC2463 (ICMP)를 보게 되면 몇 개 정의된 것이 없습니다. 하지만 다른 RFC에서 정의되었을 뿐이지 ICMPv6는 방대한 양을 포함하고 있습니다. Group Membership (130, 131, 132) 부분은 RFC2710: MLD (Multicast Listener Discovery) 프로토콜에 정의되어 있습니다. Router Discovery 및 Neighbor Discovery 부분은 RFC 2461: NDP (Neighbor Discovery Protocol) 부분에 정의되어 있습니다. 아래에서 다시 알아보겠습니다.
ICMPv6 조금 더: IPv6 네트웍에서 인접 노드를 인식하기 위한 Neighbor Discovery Protocol.
ND는 다음 기능을 수행합니다. (1) router discovery 기능, (2) prefix discovery 기능, (3) parameter discovery 기능. Link MTU, hop limit 등을 받을 수 있습니다, (4) address auto- configuration 기능, (5) address resolution 기능, (6) next-hop determination 기능, (7) neighbor unreachability detection기능, (8) duplicate address detection 기능, (9) redirect 기능입니다.
ND의 기능을 위한 메시지는 다음 5가지입니다. (1) ROUTER SOLICITATION, (2) ROUTER ADVERTISEMENT (stateful address를 사용할 것인지, stateless auto-address configuration을 사용할 것인지를 알려주고, prefix도 알려줍니다), (3) NEIGHBOR
SOLICITATION, (4) NEIGHBOR ADVERTISEMENT, (5) REDIRECT 메시지입니다. 이제 위의 5가지 메시지를 가지고 기능을 어떻게 구현할 수 있는지 알아보겠습니다.
(1) router discovery 기능: 현재의 네트웍에 물린 호스트가 어떻게 라우터를 찾을 수 있나 요? 라우터는 주기적으로 ROUTER ADVERTISEMENT를 내려줍니다. 혹은 호스트가 급하 다면, ROUTER SOLICITATION 메시지를 all router multicast 주소로 보내면 됩니다.
(2) prefix discovery 기능과 (3) parameter discovery 기능: 라우터에서 내려 받는 ROUTER ADVERTISEMENT 메시지 안에는 prefix 정보도 들어 있고, 다른 파라미터 값, 예를 들어 Link MTU, hop limit 등이 들어 있어 받을 받을 수 있습니다, 또한 라우터가 관리하는 호스 트들이 stateful address configuration을 사용할 지 혹은 stateful로 DHCP를 사용할지도 알려주게 됩니다.
(3) address auto-configuration 기능: 각 호스트가 처음에 자기 스스로 link-local 주소를 하 나 만들고, 중복되는지 여부를 검사하려면 DAD 과정을 해야 합니다. DAD 과정은 NEIGHBOR SOLICITATION을 보내서, NEIGHBOR ADVERTISEMENT 메시지가 돌아오지 않기를 기대하는 것입니다. 이제 라우터에서 ROUTER ADVERTISEMENT 메시지를 받고, stateful로 할지, stateless로 할지를 지시 받으면, stateful이면 DHCPv6 서버와 연결하면 되고, stateless이면 prefix를 받아서 site-local 혹은 global 주소를 만들면 됩니다.
(4) address resolution 기능: 서브넷 안에서의 데이터 이동은 반드시 link-layer 주소를 알아 야 합니다. ARP 라는 프로토콜이 있는 이유죠. 어떤 호스트의 link-layer 주소를 알고 싶다 면, 그 호스트의 IP 주소로 NEIGHBOR SOLICITATION 메시지를 보내서 link-layer 주소 를 요청하면 됩니다. 해당 호스트는 NEIGHBOR ADVERTISEMENT 메시지로 응답합니다.
ICMPv6 조금 더: IPv6 네트웍에서 인접 노드를 인식하기 위한 Neighbor Discovery Protocol 메시지들은.
ND의 기능을 위한 메시지는 다음 5가지입니다. (1) ROUTER SOLICITATION, (2) ROUTER ADVERTISEMENT, (3) NEIGHBOR SOLICITATION, (4) NEIGHBOR ADVERTISEMENT, (5) REDIRECT 메시지입니다. 이제 위의 5가지 메시지 중에서 중요하다고 생각되는 ROUTER ADVERTISEMENT, NEIGHBOR ADVERTISEMENT을 살펴보겠습니다.
다음 그림은 ROUTER ADVERTISEMENT 메시지의 포맷입니다. TYPE은 134입니다. M 플레 그는 MANAGED를 의미하고, 호스트가 M=1로 설정된 이 메시지를 받으면, 호스트가 stateful address configuration을 하라는 의미입니다. O는 Other Stateful Configuration을 의미합니다. O=1이면 주소를 빼고는 Stateful로 주소를 설정하라는 의미입니다.
중요한 몇가지는 OPTIONS 필드에 오게 되는데, 한가지는 이 메시지를 보내는 source의 link-layer 주소입니다 (ARP가 자동으로 되는 셈이죠), 두번째는 link-MTU 값입니다. 세번째 는 prefix 관련 정보인데, 다음 그림과 같이 생겼습니다. (1) Prefix length는 prefix의 길이 를 말합니다. (2) A 비트는 AUTONOMOUS ADDRESS CONFIGURATION을 지정합니다. 1 로 설정되면, prefix가 address auto-configuration에 사용될 수 있다는 것이죠. VALID, PREFERRED LIFETIME은 prefix의 lifetime (유효기간)을 정의하고 있습니다.
다음 그림은 NEIGHBOR ADVERTISEMENT 메시지의 포맷입니다. R비트 (ROUTER)를 1로 하면, 이 메시지를 보내는 것은 라우터라고 말하는 것입니다. S 비트는 SOLICITED 플래그 로 이 메시지는 NEIGHBOR SOLICITATION 메시지를 받고 대응해서 보내는 메시지라고 알려주는 것입니다. 마지막으로 O 비트는 OVERRIDE 플래그로 이 메시지를 받으면, 기존 에 link-layer를 저장해둔 캐쉬의 내용은 오래 된 내용이니 이 내용으로 바꾸라는 지시입니
다.
ICMPv6의 응용: IPv6 네트웍에서 고속 데이터 전송을 위한 Path MTU Discovery Protocol.
무슨 일이든지, 한 큐에 가는 것이 좋다고 말합니다. 한 큐에 가려면 중간에 걸리지 않아야 합니다. 걸리는 이유는 통과할 통로보다 몸집이 크기 때문입니다. 어떤 곳에서 어떤 곳까지 한 큐에 가려면, 연결된 모든 통로 중에서 가장 작은 통로보다 작아야 하겠습니다. IPv4도 마찬가지이고, IPv6에서도 이를 Path MTU (maximum transfer unit)라고 부릅니다. 다음 그 림을 보세요. 중간의 라우터를 거쳐서 S에서 D까지 데이터 패킷이 전달됩니다. S에서 R까 지 아무리 고속의 네트웍으로 구성한다고 해도, R에서 D까지 저속이면 전체 스피드는 R에 서 D까지의 저속 스피드에 좌우되게 됩니다. IPv6에서는 Path MTU를 미리 알아내서, S에서 출발할 때부터 Path MTU보다 작게 만들어서 보내자는 생각입니다.
Path MTU를 결정하는 문제는 그리 단순하지는 않습니다. 한가지 문제는 네트웍 경로가 바 뀌고, 네트웍 시설 업그레이드 등으로 항상 Path MTU가 같을 수가 없습니다. Path MTU가 어느 순간 작아졌는데도 계속 큰 패킷으로 보낼 수는 없고, 반대로, Path MTU가 커졌는데 도, 계속 작은 패킷으로 보내는 것도 비효율적입니다. Path MTU가 전보다 작아지면, ICMP
PACKET TOO BIG 에러 메시지가 오게 됩니다. 알맞게 줄이면 됩니다. Path MTU가 전보다 커지는 경우에는 별다른 메시지가 없습니다. 방법은 S가 가끔 한번씩 Path MTU를 늘려서 시도해봐야 합니다.
여기서 한가지 생각해볼만한 것은 UDP의 경우에는 connection setup 과정도 없는데, 어떻 게 Path MTU를 알지 입니다. 생각해보시기 바랍니다. IETF에서도 계속 생각하고 있는 중입 니다.
프로그래밍을 위한 ICMPv6 패킷의 해더 들여다보기.
실제로 BSD 계열의 운영체제에서는 <netinet/icmp6.h>에 ICMPv6 헤더 포맷이 다음과 같이 정의되어 있습니다. 프로그래밍 관점에서 보게 되면, ICMPv6, OSPF 등은 모두 IP 계층 위 에서 바로 동작하는 것이라서 raw socket이라 불리는 socket API를 사용해야 합니다. 예를 들어 ICMPv6 패킷을 만들기 위해서는 socket API에 PF_INET6, SOCK_RAW, IPPROTO_ICMPV6를 넘겨 주어야 합니다.
struct icmp6_hdr {
uint8_t icmp6_type; /* type field */
uint8_t icmp6_code; /* code field */
uint16_t icmp6_cksum; /* checksum field */
union {
uint32_t icmp6_un_data32[1]; /* type-specific field */
uint16_t icmp6_un_data16[2]; /* type-specific field */
uint8_t icmp6_un_data8[4]; /* type-specific field */
} icmp6_dataun;
};
이미 살펴본 바와 같이, icmp6type에 올 수 있는 값은 다음과 같이 정의되어 있습니다.
#define ICMP6_DST_UNREACH 1
#define ICMP6_PACKET_TOO_BIG 2
#define ICMP6_TIME_EXCEEDED 3
#define ICMP6_PARAM_PROB 4
#define ICMP6_ECHO_REQUEST 128
#define ICMP6_ECHO_REPLY 129
#define ICMP6_MEMBERSHIP_QUERY 130
#define ICMP6_MEMBERSHIP_REPORT 131
#define ICMP6_MEMBERSHIP_REDUCTION 132
#define ND_ROUTER_SOLICIT 133
#define ND_ROUTER_ADVERT 134
#define ND_NEIGHBOR_SOLICIT 135
#define ND_NEIGHBOR_ADVERT 136
#define ND_REDIRECT 137
IPv6 네트웍에서의 새로운 DNS
IPv6 주소를 사람들이 외우고 다닌다는 것은 영화 “레인맨”에 나오는 사람들이 아니고서는 어려울 것입니다. DNS (domain name system) 서비스는 www.yahoo.com과 같은 domain name을 받아서, IP주소로 바꾸어주거나, 혹은 IP 주소를 받아서 domain name으로 바꾸어주 고, 혹은 domain name에 연결된 각종 정보를 알려주는 역할을 합니다. IPv4에서의 DNS 서 비스는 아래 그림과 같이, 노드와 연결된 local DNS 서버가 있어서, 노드에서 보내오는 DNS QUERY를 자신이 해결할 수 있으면 해결하고, 그렇지 못하면, 상위 DNS 서버에게 요 청하는 식으로 해결하는 방식입니다.
IPv4에서 그랬듯이 사람들이 기억하기 쉬운 www.yahoo.com과 실제 IPv6 주소를 연결해주 는 서비스인 DNS (Domain Name System) 서비스는 아주 유용한 서비스로 남아있습니다.
Domain name을 가지고 IPv6 주소로 변환하기 위해서는 DNS entry에 AAAA라는 resource record type으로 <domain name, IPv6 주소> 쌍이 있어야 합니다. AAAA 대신에 A6로 쓸 수 도 있다는 것을 기억해주세요.
www.abc.test AAAA 3FFE:B00:C18:1::2 www.abc.test A6 3FFE:B00:C18:1::2
IPv4의 DNS 서비스에서도 IPv4 주소를 domain name으로 다시 역변환하는 방법이 있었습 니다. IPv6에도 있습니다. 단지 domain 이름만 IP6.INT라는 이름으로 바뀌었습니다. 예를 들어, IPv6 주소가 “4321:0:1:2:3:4:567:89ab”라면 domain name을 찾기 위해 찾아야 할 domain은 숫자를 거꾸로 적고, 마지막에 IP6.INT를 붙이면 됩니다. 즉
“b.a.9.8.7.6.5.4.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT”입니다. 다음은 관련 RFC입니다. DNS에는 다음과 같이 entry를 넣어주면 될 것입니다.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.8.1.c.0.0.0.b.0.e.f.f.3.ip6.int PTR www.abc.test
RFC1886: DNS for IPv6
RFC1886에서는 domain name을 IPv6 주소로 변환하기 위한 새로운 AAAA라는 resource record type을 정의합니다. 또한 IPv6로 domain name을 알아내기 위한 IP6.INT라는 domain에 대해 설명합니다.
그럼 anycast 주소 설명에서 말씀 드렸듯이, 처음에 컴퓨터가 실제 DNS 서버의 IPv6 주소 를 가지고 있지 않고, 다만 DNS 서버 그룹의 anycast 주소만을 가지고 있다고 했습니다.
그리고 그 anycast 주소의 scope는 site-local로 하기로 최근 IETF 회의에서 결정되었구요.
Site-local anycast 주소로 해서 한 네트웍 관리자가 관리하는 것이 당연할 것입니다.
마지막으로 한 마디 더: IPv6 노드에서, IPv4 노드의 DNS QUERY를 하게 되는 경우는 어떻 게 처리할까요? 아래 그림과 같이, 노드에서 요청하는 www.ipv6forum.com은 local DNS 서 버를 거쳐서, IPv4의 DNS QUERY를 관장하는 FRIENDLY DNS 서버로 DNS RELAY를 거 쳐 요청하면 됩니다. IPv4 네트웍이 한꺼번에 사라지지는 않을 것이라는 점에서 이런 식으 로 IPv4와 IPv6의 DNS QUERY를 연결시켜줄 수 있는 것은 필수적인 기능입니다.
IPv6 네트웍에서의 라우팅 프로토콜들.
IPv4에서와 마찬가지로, IPv6에서도 라우팅은 대상 범위에 따라, interior gateway protocol (IGP)과 exterior gateway protocol (EGP)로 분류합니다. 전체 네트워크는 AS (autonomous system) 단위로 물려져 있습니다. AS란 single authority라는 말을 쓰는 것에서 느껴지는 것 처럼, 독립된 조직에서 관리하는 네트웍입니다. 그러면 AS와 AS간의 라우팅은 어떤 것이 최우선 고려사항이 되어야 할까요? Policy입니다. 난 저 AS로 패킷이 가지 않게 해야 겠다 고 생각하면 가지 못하게 해야 합니다. 반면에 AS 내에서의 서브 네트웍 간의 라우팅을 할 때 최우선 고려 대상은 무엇인가요? 효율성 또는 속도입니다. 라우팅 프로토콜마다 measure가 있고 그를 만족시키기 위해서 프로토콜이 실행됩니다. IGP 방식에는 OSPF, RIP 등이 해당됩니다. EGP에는 EGP, BGP 등이 해당되구요.
IGP 방식에는 크게 distance vector 방식과 link state 방식이 있습니다. Distance vector 방 식에서는 인접한 라우터 간에 distance vector를 서로 교환합니다. 인접 노드끼리만 정보를 교환하기 때문에 네트웍이 바뀌는 경우에, 전체 라우터가 그 사항을 학습하는데 시간이 걸 리는 단점이 있습니다. 또한 이곳 저곳 거쳐서 loop가 생기는 경우에 라우팅이 잘못 되어
계속 뺑뺑이만 돌 수도 있습니다. 반면에 link state에서는 LSP라 불리는 패킷을 모든 라우 터에 보냅니다. 따라서 네트웍이 변경되더라도 순식간에 모든 라우터가 상황 변화를 알 수 없습니다. Distance vector의 대표적인 것이 RIP (Routing Information Protocol)입니다. Link state의 대표적인 것이 OSPF입니다.
IPv6에서의 라우팅은 IPv4에서 CIDR (classless domain routing)에서 사용하던 longest prefix matching (앞의 비트수가 가장 같은 곳으로 라우팅하는 방법) 방법을 그대로 사용합 니다. 따라서 기존의 라우팅 프로토콜을 그대로 바꾸어주게 됩니다.
- 유니캐스트: OSPF, RIP-II, IS-IS, BGP4+
- 멀티캐스트: PIM, MOSPF
다음은 IPv6의 라우팅 프로토콜을 정리한 문서들입니다.
RFC2080: RIPng Routing Protocol
IPv4의 distance vector 라우팅 방법인 RIP를 IPv6에서 개선한 방법입니다.
RFC2283: OSPFv6
IPv4의 link state vector 라우팅 방법인 OSPF를 IPv6에서 개선한 방법입니다.
RFC2545: BGP4+ for Inter-Domain Routing
IPv4의 EGP 라우팅 방법인 BGP (Border Gateway Protocol)를 IPv6에서 개선한 방법입니다.
IPv6의 실제 Physical Network 구성은.
IPv6는 network layer protocol입니다. 즉 일단 IPv6로 라우팅되어서 현재의 physical network까지 오게 되면 다음 필요한 것은 physical network 상에서의 데이터 전달입니다.
이를 IPv6 over XXX라고 합니다. XXX는 PPP (Point to Point Protocol), Ethernet, ATM, NBMA (Non-Broadcast Multiple Access), Token-Ring이 될 수 있습니다. 다음은 관련 RFC 들입니다.
RFC2472: IPv6 over PPP
IPv6 over PPP는 전화선을 사용해서 ISP로 인터넷 서비스를 받을 때 흔히 사용하게 됩니다. PPP 는 상위 프로토콜 (IP이든, IPX이든) 이 무엇이든 상관 없이 동작합니다. 즉 PPP는 상위 프로토콜 에 의존적인 부분과 그렇지 않은 부분으로 구성되어 있다는 이야기도 되죠. 상관 업는 부분은 LCP (link control protocol)이라고 하고, 두 개의 노드 간에 link를 만들고, 설정하는 역할을 하게 됩니다. 이제 LCP가 교환되고 나면, 인증 절차를 거치게 됩니다. 인증 절차는 패스워드를 사용하 는 PAP와 서로 상대방을 암호화 방식으로 확인하는 CHAP 방식이 있습니다. 이제 인증 절차도 끝나고 나면, 상위 프로토콜과 밀접한 부분이 실행됩니다. 이를 NCP (network control protocol)이 라고 하고, 상위 프로토콜이 IPv4인 경우, IPCP, IPv6인 경우를 IPV6CP (IPv6 control protocol) 라고 부릅니다.
IPV6CP 부분에서는 IP 프로토콜을 지원하기 위한 설정 기능이 이루어집니다. 그 중 중요한 것은 IP 프로토콜이 되려면, PPP 인터페이스의 IPv6 주소가 있어야겠죠. IPV6CP 과정 중에 주소를 설 정하는 과정이 있습니다. 주소는 link-local address를 사용합니다. 따라서 앞의 64비트가 FE80::/10으로 시작하고, 뒤의 인터페이스 아이디는 IPV6CP에서 negotiation 됩니다.
RFC2464: IPv6 over Ethernet
RFC2464에서는 Ethernet 802 주소 (48비트)가 어떻게 64비트 interface ID를 구성하는지와, IPv6에서의 unicast 주소와 multicast 주소를 MAC 주소로 어떻게 대응되는지를 알려줍니다.
RFC2491: IPv6 over NBMA (Non-Broadcast Multiple Access)
NBMA 네트웍이란 ATM, FRAME-RELAY와 같이, virtual circuit (VC) 기반의 서비스를 제공하는 네트웍들입니다. 어떤 S와 D간에 패킷 전달은 VC가 할당되고 VC를 통해서 전달되기 때문에, S와 D간에 1:1 선이 있다고 생각해도 되는 네트웍들입니다. NBMA도 서브 네트웍이고 보면, IP 주소 를 알아도 반드시 서브 네트웍 내에서 움직이기 위해서는 link-layer 주소를 알아야 합니다. 지금 까지 IP 망들은 대부분 Ethernet 환경을 생각하고 있었습니다. Ethernet에서는 link-layer 주소를 모르면 그냥 방송하면 됩니다. 내가 IP주소는 아는데, link-layer 주소를 모르니까 자기가 이 IP 주소를 가진 호스트이면 내게 응답하기 바람이라는 ARP 메시지를 보냅니다. 하지만 NBMA에서 는 방송망이 아닌 관계로 어렵습니다. 어떻게 할지가 RFC2491에서 다루는 내용입니다.
ARP는 서브 네트웍 상에서 IP 주소를 알 때, link-layer 주소를 알아내는 프로토콜입니다. NBMA 에서는 이 기능을 제공하기 위해 NHRP (next hop resolution protocol)를 제공합니다. NHRP는 1개 hop 이내 (서브네트웍) 뿐이 아니라, 여러 개의 hop을 건너서 동작할 수 있는 ARP의 일반화라고 생각할 수 있습니다.
RFC2492: IPv6 over ATM
RFC2491을 ATM에 적용시켜서 정의한 문서입니다.
RFC2467: IPv6 over FDDI, RFC2470: IPv6 over Token Ring, RFC2497: IPv6 over ARCNET 다양한 네트웍에 대한 사항들을 정리한 RFC 문서들입니다.
IPv6 네트웍 프로그래밍은 어떻게.
IPv4 네트웍에서 응용 프로그래밍을 하는 일은 다양한 방법이 있습니다. 우선 socket이나 TLI라는 네트웍 API를 사용해서 프로그래밍하는 경우 (물론 윈도우의 경우의 winsock 이라 는 API가 있었습니다), 그리고 RPC (remote procedure call)이라는 것이 있고, CORBA (common object request broker architecture)를 활용한 프로그래밍도 있습니다. Socket을 사용하게 되면 상대편 address와 port 번호를 알아야 합니다. RPC를 사용하면, 상대편의 IP 주소만 알면 되고, port 번호 대신 실제 의미가 있는 서비스 이름만 알면 됩니다. RPC의 기 본 데몬인 portmapper (rpcbind) 등이 서비스 이름을 대면 자동으로 연결시켜 주기 때문입 니다. CORBA는 한술 더 뜹니다. 아예 서비스 이름만 알려주면, CORBA의 ORB (object request broker)가 적절한 서버를 찾아서 연결시켜 줍니다.
현재 IPv6의 기본 윤곽은 완성이 되었지만, IPv6를 실제로 어떻게 응용 프로그래밍을 구성 할지에 대한 API 부분은 아직도 많은 부분이 남아있습니다. 따라서 우선은 socket 인터페 이스가 IPv6 프로그래밍에서는 어떻게 적용이 되는지 알아 보겠습니다.
우선 IPv6를 위한 socket 네트웍 인터페이스를 만들기 전에 세워진 원칙을 몇 가지 들어보 면, (1) 기존의 IPv4 socket 인터페이스를 사용하는 네트웍 프로그램도 source 레벨은 물론 이고, binary 레벨에서 호환되도록 하자. 이렇게 하기 위해서는 IPv4 socket 인터페이스가 기본적으로 IPv6 socket 의 일부분이어야겠죠. (2) IPv6 socket과 IPv4 socket의 다른 점이 적어서 배우는 사람들이 머리가 안 아프게 해야 한다. (3) IPv6 socket API를 가지고 프로그 래밍을 하면 기존의 IPv4 컴퓨터들과 통신을 할 수 있어야 한다. (4) IPv6의 새로운 기능들, 예를 들어 traffic class나 flow label 등을 API에서 설정할 수 있어야 한다. 등입니다.
그럼 이제 IPv6 socket 인터페이스에 대해 하나하나 알아보겠습니다. 우선 순서는 (1) socket 인터페이스 본래의 기능 (TCP connection을 열고 닫고, 데이터를 보내고, UDP 패킷 을 보내고 받는 등의 작업), (2) IPv6 주소를 설정하는 방법, (3) DNS 이름과 IP 주소를 변 환하는 방법, (4) 128비트 IPv6 주소와 1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6과 같은 dot 표현을 서 로 바꾸는 방법으로 알아 보겠습니다.
IPv6 네트웍 프로그래밍 하나: IPv6 주소를 설정하는 방법.
IPv4에서는 sockaddr_in이라는 struct 타입이 있습니다. IPv4 주소를 저장하는 자료 구조입 니다. 그런데, Ipv6는 주소가 128비트라 우선 크기가 맞지 않습니다. 또한 IPv6에서는
scope라는 주소의 유효범위가 있어서 scope를 지정하기 위한 필드가 있어야 합니다. 또한 flow나 traffic class 등을 지정할 수 있는 필드도 있어야 합니다. 그래서 바뀐 sockaddr_in6의 포맷은 다음과 같습니다.
struct sockaddr_in6 {
sa_family_t sin6_family; /* AF_INET6 */
in_port_t sin6_port; /* transport layer port # */
uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */
struct in6_addr sin6_addr; /* IPv6 address */
uint32_t sin6_scope_id; /* set of interfaces for a scope */
};
struct in6_addr { uint8_t s6_addr[16]; /* IPv6 address */ };
sa_family_t는 IPv6의 경우에는 AF_INET6 (<sys/socket.h> 에 정의되어 있음) 로 맞추어 주면 됩니다. Sin6_flowinfo (32비트 길이입니다) 에는 flow label과 traffic class 값을 넣어 줍니다. 이 부분은 현재 INTSERV, DIFFSERV, 그리고 RSVP 이슈와 맞물려서 여러 의견이 진행되고 있는 상황입니다. 어떤 식으로 QOS signalling을 할지를 정해야 이 field를 어떻게 설정할지를 알게 될 것입니다. Sin6_addr는 IPv6 주소를 넣는 부분입니다. 16바이트로 구성 되어 있습니다. 다음 sin6_scope_id는 이 주소가 link-local이거나 site-local인 경우에 scope 를 적어주게 되는데, link-local인 경우엔 interface index가, site-local인 경우엔 site identifier가 들어가게 됩니다.
IPv6 네트웍 프로그래밍 하나: 기본적인 데이터 주고 받기.
TCP connection을 열고 닫고, 데이터를 보내고, UDP 패킷을 보내고 받는 등의 작업을 어떻 게 하는지 알아보겠습니다. 우선 아래 테이블에는 IPv4 socket, IPv6 socket 인터페이스 중 에서 기본적인 데이터 주고 받기에 관계된 내용만 첨가했습니다. 보시는 바와 같이, 약간의 차이만 있을 뿐 근본적으로 동일합니다.
IPv4 socket API IPv6 socket API IPv4 TCP connection 을 만들기 위해서는
s = socket(PF_INET, SOCK_STREAM, 0);
IPv4 UDP socket 을 만들기 위해서는 s = socket(PF_INET, SOCK_DGRAM, 0);
IPv4 TCP connection 을 만들기 위해서는
s = socket(PF_INET6, SOCK_STREAM, 0);
IPv4 UDP socket 을 만들기 위해서는
s = socket(PF_INET6, SOCK_DGRAM, 0);
데이터를 보내기 위해서는
bind(),connect(),sendmsg(),sendto() 데이터를 받기 위해서는
accept(),recvfrom(),recvmsg() getpeername(), getsockname()
IPv4 와 동일함.
부가적으로 언급하면, IPv6 컴퓨터에서 IPv4 컴퓨터로 데이터를 보내려고 합니다. Connect() 나 sendto()에서 목적지 주소를 어떻게 설정해야 하죠? 위에서 알려드린 바와 같이, IPv4 mapped address 포맷을 사용합니다. IPv4 mapped 주소는 ::FFFF:<IPv4 address>로 구성됩 니다. 즉 하위 32비트는 IPv4 주소이고, 바로 위에만 FFFF이고 나머지 위는 0으로 채우면 됩니다.
IPv6 네트웍 프로그래밍 셋: 주소 변환.
IPv4 socket 인터페이스에는 gethostbyname(), gethostbyaddr(), inet_ntoa(), inet)_addr() 등이 있습니다. IPv6에서 이들을 사용하기 위해서는 다음과 같이 바꾸어 주면 됩니다.
IPv4 socket API IPv6 socket API DNS 이름으로 IPv4 주소를 알기 위해서
gethostbyname(name)
IPv4 주소로 DNS 이름 알기 위해서 gethostbyaddr()
IPv4 x.x.x.x 주소와 비트 주소 사이의 변환 inet_ntoa()
inet_addr()
DNS 이름으로 IPv6 주소를 알기 위해서
getipnodebyname(name,AF_INET6,flag,,&error_
num)
IPv6 주소로 DNS 이름 알기 위해서 getipnodebyaddr(name, length,AF_INET6,
&error_num)
IPv6 x.x.x.x 주소와 비트 주소 사이의 변환 inet_ntop (AF_INET6, char_string, binary, len) inet_pton(AF_INET6, “::x.x.”, binary_string)
또한 IPv6에는 다양한 주소 체계가 있기 때문에 타입을 검사하는 함수들이 필요한데, 다음 은 매우 유용한 함수들입니다.
#include <netinet/in.h>
int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *);
int IN6_IS_ADDR_MULTICAST (const struct in6_addr *);
int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *);
int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *);
int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *);
int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);
int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);
IPv6 네트웍 프로그래밍 넷: 헤더 조작하는 방법.
IPv4 에는 없던 많은 기능들이, IPv6에는 extension 헤더에 들어가게 되었습니다. 또한 헤 더 중에는 응용 프로그래머가 직접 생각해주어야 하는 것들도 여럿 있습니다. 다음은 대표 적인 몇가지를 알아 보겠습니다.
우선 IPv4에서 어떤 패킷의 TTL (time to live)를 3으로 주게 되면, 첫번째, 두번째, 세번째 라우터를 거치면서 TTL 값이 하나씩 줄어들다가, 세번째 라우터에서 0이 되면, ICMP 에러 메시지를 내게 됩니다. 같은 기능이 Hop Limit라는 것으로 IPv6 기본 헤더에 들어가 있습니 다. Hop Limit를 조작하기 위한 방법은 다음과 같습니다. 어떤 Hop Limit 값은 특별한 의미 를 가집니다. –1보다 작은 음수인 경우에는 EINVAL이라는 에러를 내게 됩니다. –1이면 kernel이 가지고 있는 default 값으로 맞추어줍니다. 256보다 같거나 큰 값인 경우에는 역 시 EINVAL이라는 에러를 내게 됩니다.
int hoplimit = 10;
if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
(char *) &hoplimit, sizeof(hoplimit)) == -1) perror("setsockopt IPV6_UNICAST_HOPS");
반대로, 현재 설정되어 있는 Hop Limit 값을 알아보려면 다음과 같이 하면 됩니다.
int hoplimit;
size_t len = sizeof(hoplimit);
if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, (char *) &hoplimit, &len) == -1) perror("getsockopt IPV6_UNICAST_HOPS");
else
printf("Using %d for hop limit.\n", hoplimit);
간단하게 IPv6의 기본 헤더 중에서 Hop Limit를 설정하는 법을 배웠고, 이젠 extension 헤 더 중에서 routing 헤더를 설정하는 방법을 간단히 설명하겠습니다. 아래의 예에서 보는 바 와 같이, IPv4 socket API에서 raw socket을 사용하는 경우에는, 바로 read/write가 가능했 습니다. 하지만 IPv6에서는 아래의 예에서처럼 cmsgptr로 라우팅 헤더의 위치를 지정하고, add 함수를 이용해서 써주게 됩니다. 좀더 쉽다고도 볼 수 있지만, 이제는 네트웍에서 ICMP 패킷 등을 함부로 만들지 못하도록 한다는 의미도 있습니다.
void *ptr;
struct msghdr msg;
struct cmsghdr *cmsgptr;
struct sockaddr_in6 I1, I2, I3, D;
unsigned int f0, f1, f2, f3;
ptr = malloc(inet6_rthdr_space(IPV6_RTHDR_TYPE_0, 3));
cmsgptr = inet6_rthdr_init(ptr, IPV6_RTHDR_TYPE_0);
inet6_rthdr_add(cmsgptr, &I1.sin6_addr, f0);
inet6_rthdr_add(cmsgptr, &I2.sin6_addr, f1);
inet6_rthdr_add(cmsgptr, &I3.sin6_addr, f2);
inet6_rthdr_lasthop(cmsgptr, f3);
msg.msg_control = ptr;
msg.msg_controllen = cmsgptr->cmsg_len;
/* finish filling in msg{}, msg_name = D */
/* call sendmsg() */
IPv6 네트웍으로 가기 위한 진화 전략.
다음은 CISCO에서 IPv6 네트웍으로 진화하기 위한 방안을 정리한 것입니다. 첫번째 단계 는 당연히, 기존 IPv4 망에서 IPv6 트래픽을 tunneling해서 가상의 IPv6 망을 지원하는 것 입니다. 6BONE이라고 하는 것들이 그것입니다. 아래 그림과 같이, IPv6 패킷은 IPv4 네트 웍 위에서 tunneling되어 이동하게 됩니다.
두번째 단계에서는 IPv6 트래픽이 많이 발생하는 곳끼리는 아예 IPv6 라우터를 제공하는 것입니다. 세번째 단계에서는 MPLS가 앞으로 백본 L3 스위치를 대표한다고 가정하고, MPLS L3 스위치에서 IPv6 트래픽을 지원하는 것입니다. 네번째 단계는 DUAL STACK이라 고 되어 있는데, 대부분의 트래픽이 IPv6로 흘러가지만 IPv4도 지원해야 하는 경우에 쓰기 위함입니다. 하지만 기본적으로 IPv4가 살아 있는 한, 초창기부터 응용 프로그램들은 DUAL STACK을 가정한다고 생각하면 됩니다. 다섯번째 단계는 모든 것들이 IPv6로 되거나, 혹은 IPv4는 신경 쓰지 않아도 되는 환경에 사는 경우입니다.
IPv6와 IPv4 네트웍을 연결하기 위한 대책.
위의 IPv4 망에서 IPv6 트래픽을 지원하는 경우, 그리고 IPv6 망에서 IPv4 망을 지원하는 경우가 많이 쓰일 것입니다. 또한 터널링이 아닌, 아예 일정 라우터에서 IPv4와 IPv6를 상 호 변환하는 경우도 있을 것입니다. 아래 그림은 IPv6 트래픽이 기존의 IPv4 네트웍 위에 서 터널링 되어서 전달되는 경우입니다. 이렇게 IPv6 호스트들이 IPv4 네트웍을 이용하는 경우에, IPv6 호스트들은 IPv4 주소를 가져야 합니다. 그런 경우를 IPv4 compatible 주소라 고 합니다.
IPv4 compatible address와 IPv4 mapped address의 차이는? IPv4 compatible address는 IPv4 주소 (32비트) 96비트의 0을 채운 것입니다. 예를 들어, IPv4 주소가 143.248.2.5이면,
“::143.248.2.5”가 되는 것입니다. IPv4 mapped address는 IPv4 주소 (32비트) 앞에 80개의 0과 16개의 1을 채우는 것입니다. 예를 들면, “::ffff:143.248.2.5”가 됩니다.
IPv4 compatible 주소는 IPv6 컴퓨터인데, IPv4 네트웍에 연결된 경우에 사용합니다. 이런 경우에, IPv6 패킷은 IPv4 패킷 위에 tunneling 되어서 다른 IPv6 컴퓨터로 전송되어야 합 니다. IPv4 네트웍 속에 덮여있는 IPv6 컴퓨터인 셈이죠.
IPv6 mapped address는 IPv4 컴퓨터에 IPv6 주소를 할당하는 경우입니다. IPv6 compatible 이 IPv4 cloud 안에 갇힌 컴퓨터라면, 이 경우에는 그런 것은 없지만 IPv4 컴퓨터에 패킷을 전달하기 위해서는 IPv4 컴퓨터가 IPv6에서 알 수 있는 주소를 가져야 하겠죠.
IPv6에서 고려한 다른 기술적인 사항들.
IPv6 역시 기본적인 기능 외에 부가적으로 기억해두어야 할 기술들이 많이 있습니다. 다음 RFC들은 Jumbo-gram이라고 부르는 멀티미디어 정보들과 같이 큰 패킷을 어떻게 처리할지 와, 멀티캐스팅을 위한 주소 배정, 그리고 Tunneling 기법, 그리고 Anycast 주소에 대한 단 서를 제공하게 됩니다.
RFC2147: TCP/UDP over Jumbo Grams
Jumbo-gram이라고 부르는 payload가 65535 바이트 이상 되는 멀티미디어 정보들과 같이 큰 패 킷을 어떻게 처리할지를 다룹니다.
RFC2473: Generic Packet Tunneling
새로운 프로토콜을 가진 네트웍이 생기고, 예전의 프로토콜을 사용하는 응용 프로그램을 지원하 기 위해서는, 예전의 프로토콜을 현재의 프로토콜 위에서 simulate해주어야 합니다. 새로운 프로 토콜이 예전의 프로토콜을 tunneling해서 지원하는 것이 일반적입니다. IPv4를 계속 지원하려면, IPv4 트래픽을 IPv6 트래픽에 실어서 보내고 받으면 됩니다. 부가적으로 예전에 IPv4 네트웍일 때 했던 것과 모든 것이 동일하게 만들어주는 것이죠 (인접 노드는 그대로 인접 노드이고, ICMPv4도 그대로 돌아가고). IPv4 뿐만 아니라, IPv6, APPLETALK, IPX, CLNP 등이 모두 tunneling의 대상입니다.
IPv6의 앞으로의 방향과 현재 논쟁거리들
IPv6는 큰 그림은 나왔지만, 여러 가지 세부 사항들은 아직도 논의 중입니다. 더욱이 IPv6 가 최초로 적용할 대상이 IMT-2000 (특히 4세대 IMT-2000망. 현재는 2.5 세대 IMT- 2000이라고 불림) 이라고 불리는 무선망인지라, 많은 회사들의 이해 관계가 얽혀있어서 쉽 게 해결할 사항들도 계속 논쟁거리가 되는 경우가 많습니다. 예전 UCLA나 몇몇 대학을 중 심으로 IPv4가 시작할 때와는 다른 양상을 보이는 셈이죠. 실제로 많은 IPv6 엔지니어들이 시스코, 노텔 네트웍스, 루슨트, 노키아, 에릭슨 등 미국 주요 제조업자들에 소속되어 있습 니다. 다음은 몇몇 이슈들을 정리해보았습니다.
(1) Anycast 주소를 어떻게 사용할 것인가? 이미 anycast 설명 부분에서 언급한 것처럼 anycast 주소가 매력적이긴 하지만, TCP에는 사용이 어렵고, UDP에도 몇몇이 조정이 되어야 합니다. 그리고 anycast를 가지고 어떤 응용 프로그램을 만들 수 있는지도 주요 관심 사항 이 되고 있습니다.
(2) QOS를 어떻게 지원할지는 말들이 많습니다. DIFFSERV로 할지 INTSERV로 할지도 안 정해져 있고, DIFFSERV로 한다고 해도 어떤 필드를 어떻게 사용할지는 아직도 해결해야 할일들입니다. IPv6의 헤더에는 traffic class, flow label이라는 것이 있습니다. 어떻게 사용 할지 의미는 무엇으로 정할지 관심이 모여 있습니다. 실제 이 필드들은 QOS를 어떤 방식 으로 지원하는지와 연관이 되어 있습니다. QOS 지원 방식에는 application entity 개별로 QOS를 맞추어주려는 IntServ 방식과 패킷 별로 맞추어 주려는 DiffServ라는 방식이 있습 니다. 또한 프로토콜로는 Microsoft 등이 주장해오고 있는 RSVP를 사용할지 또는 다른 방 식을 사용할지도 관심 사항입니다. 실제 본격적인 논의는 백본 망의 경우에는 MPLS backbone 들이 실제 설치되는 때에 시작될 것으로 생각하고 있습니다. 또한 액세스 측면의
QOS는 IMT-2000의 구조와 밀접하게 생각해야 하기 때문에 실제 대부분의 논의가 3GPP 와 3GPP2의 해당 그룹에서 논의되고 있습니다.
(3) 현재 ROHC라는 헤더 압축 (Header Compression) 방식이 표준화 되고 있습니다. IPv6 는 헤더도 그렇고, 대부분이 간단하게 설계되었습니다. 이유는 하드웨어로 고속화 시키고자 합니다.
(4) 논쟁은 되고 있지 않지만, IPv6의 완성도가 높아지면서 항상 생각하게 되는 것이 운용 보전 (Operation and maintenance. OAM) 측면입니다. 이런 사항들은 실제 네트웍의 performance를 측정하는 것과 긴밀하기 때문에 대부분의 논의는 ATT Lab 등의 사업자 들 을 중심으로 이루어지고 있습니다. OAM은 크게 TMN (CMIP 기반)과 SNMP 기반이 있긴 하지만, IP 세상은 SNMP 사용을 전통으로 생각하고 있습니다.
(5) IPv6의 대부분의 사항들은 정리가 되었습니다만, 아직도 MIPv6 등은 표준화가 끝나지 않은 상태입니다. MIPv6는 IPv6와는 다른 프로토콜이긴 하지만, IPv4에서 MIPv4의 관계와 는 달리, IPv6에서는 MIPv6가 바로 IPv6 패킷으로 날라가는 경우가 태반이기 때문에 MIPv6가 끝나기 전까지는 IPv6의 큰 작업이 끝났다고 볼 수 없습니다. 아래 그림을 보시면 다양한 분야가 있습니다.
(6) Mobile IP (MIP) v6 아직 끝나지 않았습니다. Smooth Handoff 이슈라고, MIP 주소를 가 진 사용자가 이동할 때, 끊어지지 않고 이동할 수 있으려면, COA (collocated address)를 자 연스럽게 바꾸어주어야 할 것입니다. MIPv6는 BINDING UPDATE라는 특성 상, 보안에 취 약할 수 밖에 없습니다. IPSEC을 도입하지만 여러 가지 해결해야 할 문제가 있습니다. IPv6 를 핸드폰에 적용 시키려면, 무선 자원이 귀중한 관계로, 압축이 필수적입니다.
(7) IPv6로 사업을 하려면, 과금 (Accounting)이 필수적입니다. 정당한 사용자가 들어왔는지 (Authentication) 체크하는 것도 중요합니다. 정당한 사용자가 들어와도 어떤 서비스를 사용 할 수 있는 사람인지 (Authorization) 체크해야 합니다. AAAv6의 할 일입니다.
IPv6 구현을 위한 모임과 KAME.
현재 많은 라우터와 호스트에 IPv6가 구현되고 있습니다. 우선 라우터에 대해서 보면, 시스 코, 에릭슨 등 여러 업자들에서 제공이 되고 있습니다. 다음은 에릭슨에서 출시된 IPv6 라 우터입니다. 에릭슨 산하의 TELEBIT는 IPv6를 처음 구현한 것으로 알려져 있습니다.
KAME는 KarigoME (KAME는 일본어로 거북이라는 뜻입니다) 의 약자입니다. KAME는 이름 이 의미하듯이 일본 WIDE 프로젝트에서 진행하는 것이며, IPv6의 핵심적인 프로토콜인 Neighbor Discovery Protocol을 거의 완벽하게 구현하고 있다는 것이 장점이고, 또하나 장 점은 IPSec 구현을 별다른 제한 없이 가져올 수 있다는 점입니다. 보안 관련 기술들은 미 국과 같은 경우에는 철저하게 export control에 의해 수출이 제한되고 있는 점을 고려하면 매력적인 장접입니다.
KAME는 현재 FreeBSD 운영체제에서 실행이 가능하고 자세한 사항은 www.kame.net에서 구할 수 있습니다.
IPv6가 만들 세상은.
IPv6가 대상으로 하는 영역은 무선기기들과 가정에서의 네트워킹 분야라고 말씀드렸습니다.
그리고 이제 실제의 가정 환경을 보게 되면, 다양한 가전기기들이 물려있고, IEEE 802.11을 주축으로 하는 데이터 네트웍이 구성되게 됩니다. 물론 전력선을 사용하는 네트웍도 backup 용으로 사용될 것입니다. 이런 다양한 기기들을 연결할 수 있는 기술은 주소 체계가 충분해 야 하고, 당연히 플러그인 플레이 기능이 되어야 할 것입니다. 또한 다양한 가전기기에서 요구하는 QOS 기능을 적절하게 제공해야 할 것입니다.
맺으며
이번 호에서는 지난 호에 이어, IPv6의 실제 패킷 포맷, IP 프로토콜을 도와주는 여러 가지 프로토콜 (ICMP, DNS, 라우팅 프로토콜 등) 등에 대해 알아 보고, 실전을 위해, 실제 IPv6 라우터를 어떻게 설정할 수 있는지, 그리고 IPv6 프로그래밍이란 어떤 것인지 알아보았습니 다. 그리고 마지막으로 IPv4 네트웍과의 연동 방법, IPv6로 진화하는 방법, 그리고 IPv6가
그리는 세상을 생각해 보았습니다. 아무쪼록 이 두 번의 연재가 여러 분들이 쉽게 IPv6 기 술을 이해하시고, 조만간에 들이닥칠 무선망 및 핸드폰 프로그래밍 영역에서 진가를 발휘하 시기를 바라겠습니다.
