제 90 차 IETF 정례회의 IPv6 표준화동향 2014. 9
제 90 차 IETF 정례회의 IPv6 표준화동향 인터넷주소산업팀 유지영연구원 IPv6는 IETF의 IPng(The IP Next Generation) 워킹그룹에서개발된차세대인터넷프로토콜이다. 1988년 RFC 발간을시작으로기본기술개발이완료되고주요구간준비기간을거쳐, 현시점에서는 IPv6 전환을위한준비가마무리되어 IPv6 상용서비스가전세계적으로빠르게확산되고있다. 본원고에서는 90차 IETF 회의에서의 IPv6 관련표준화동향을중점적으로살펴보고자한다. I. 개요 IETF는인터넷의운영, 관리, 개발에대해협의하고인터넷프로토콜과구조적사안을논의하는인터넷표준화기구로, 1986년설립되어 8개분야 (area) 의 100여개워킹그룹 (working group) 에서자발적인참여와논의를통하여인터넷전분야에대한기술표준을제정하고있다. IPv6는 1988년 IETF의 IPng(The IP Next Generation) 워킹그룹에서개발한인터넷프로토콜로, IPv6 워킹그룹, BEHAVE 워킹그룹등에서현재까지관련기술명세및이슈를다루어왔다. 캐나다토론토에서개최된이번 90차 IETF 정례회의에는총 53개국에서 1,435여명이참석하여인터넷각분야의사안을논의하였으며, 영국런던에서개최된 89차회의의 1,364명에비교하면약간증가한수치이다. 참석자중약 50% 가미국인이며, 캐나다, 중국, 일본등의국가에서주로참석하였다. 우리나라에서는연구기관, 표준화기관, 기업및대학을중심으로 20여명정도참석하였다. 현재 IETF의 IPv6 관련워킹그룹은 SOFTWIRE(Softwires), V6OPS(IPv6 Operations), SUNSET4(Sunsetting IPv4), 6MAN(IPv6 Maintenance), HOMENET(Home Networking), 6lo (IPv6 over Networks of Resource-constrained Nodes), 6tisch (IPv6 over the TSCH mode of IEEE 802.15.4e) 등으로, SOFTWIRE 워킹그룹에서는터널기술을중심으로한 IPv6 전환기술을, V6OPS 워킹그룹에서는 IPv6 운영전반의이슈를, SUNSET4 워킹그룹에서는 IPv4 종료이슈를논의하고있다. 6MAN 워킹그룹에서는 IPv6 프로토콜의유지보수를논의하며 HOMENET에서는홈네트워킹관련 IPv6 이슈를, 6LO와 - 2 -
6TISCH 워킹그룹에서는저전력등다양한제한적네트워크에서 IPv6를이용하기위한프로토콜스택경량화등의이슈를다루고있다. 본고에서는 SOFTWIRE와 V6OPS, SUNSET4 워킹그룹을중심으로 IPv6 관련논의를살펴보도록한다. II. SOFTWIRE 워킹그룹표준화동향 IETF의 SOFTWIRE 워킹그룹은 6RD와 DS-Lite 등터널을이용한 IPv6 전환기술전반의표준화를추진하고있다. 최근 SOFTWIRE 워킹그룹은 LW4o6, 4RD, MAP 등 IPv6 전환기술에대한기본문서표준화를마무리하고있으며관련한후속문서를논의하고있다. DS-Lite를확장한 Lightweight 4over6 터널기술문서의경우표준화작업이거의완료되어 IESG의승인을기다리고있다. DS-Lite는 CGN과터널링기술 (IPv4 in IPv6) 을활용하여 IPv4 연결성을제공하고점진적인 IPv6 전환또한가능케하는전환기술로, ISP 네트워크에는 CGN(NAT44) 이구현되고 ISP장비부터 CPE까지는 IPv4 in IPv6 터널링을이용한다. SOFTWIRE 워킹그룹에서논의되고있는 LW4o6 전환기술은 DS-Lite 모델에서 ISP의터널링장비가수행하던대량의 NAT를 CPE단의터널링장비가수행하도록기능을위임하여, ISP단에대규모 NAT(CGN, NAT44) 를구현하지않아도기술적용이가능하도록개선하고중앙에걸리는부하를분산하는기술이다. LW4o6 기술은기술의기본구조의표준화가마무리되는단계로적용고려사항등관련후속문서의표준화추이를지켜볼필요가있다. 또한 SOFTWIRE 워킹그룹에서는 4RD(IPv4 Residual Deployment) 전환기술에대한 WG Last Call을마치고표준화절차를진행하는중인데, 4RD 기술은 stateless 주소매핑을이용하여 IPv6 네트워크를통해잔여 IPv4 주소의통신이가능하도록하는자동터널링기술로, IPv4 네트워크에 IPv6을빠르게적용하는터널링기술인 6RD(IPv6 Rapid Depolyment) 의반대급부가되는기술이다. 6RD는 SOFTWIRE 워킹그룹에서 2010년표준화된전환기술이다. Cisco 에서주도하여표준화를추진하고있는 MAP 기술은 A+P 포트주소변 환과 ISP 내부 IPv6 네트워크단의 IPv4 패킷터널링을결합한 IPv6 전환기술인 - 3 -
로역시 WG Last Call을마치고 IESG에제출되어승인을기다리고있다. MAP 프레임워크는 2가지운영모드를제공하는데, 변환 (Translation) 기술을이용하는 MAP-T와, 인캡슐레이션 (Encapsulation) 을활용하는 MAP-E이다. MAP-T는 CPE와 ISP 라우터에서상태비보존형 NAT64 기능을활용하며, MAP-E는 CPE와 ISP 라우터에서 IPv6 over IPv4 상태비보존형캡슐화 / 디캡슐화기능을활용하여 IPv4-IPv6간통신을제공하도록설계되었다. III. V6OPS 워킹그룹표준화동향 V6OPS 워킹그룹은 IPv4/IPv6 공존네트워크운영시문제점을식별하고해결책을제시하며, 기존네트워크에 IPv6을적용하는방법론을연구하는워킹그룹이다. V6OPS 워킹그룹은 IPv6 본격적용이후생기는네트워크전반의다양한운영이슈를논의하였는데, 이중특기할만한몇가지주제는아래와같다. 90차회의에서 V6OPS는 ULA(Unique Local Addresses, RFC4193) 사용시고려사항에대한드래프트를논의하였다. ULA는인터넷에라우팅하지않고로컬통신을위해사용되는내부주소이며, 예약프리픽스인 fc00::/7를사용한다. IPv4 사설주소 (RFC1918) 에대응한다고볼수있으나인터넷에접속하지않는로컬노드에도 Globally Unique Address를부여하므로 IPv4 환경에서처럼사설주소충돌에따른 IP주소재할당이나다중 NAT 설정을피할수있다. ULA 주소포맷 7 bits 1 40 bits 16 bits 64 bits Prefix L Global ID Subnet ID Interface ID - Prefix : fc00::/7 로고정 - Global ID : 다른사이트의 ULA 와충돌하지않는 40bit 의 ID 를부여하여타사이트와의사설주소충돌예방 (NTP 를이용하여 EUI-64 를생성, 해쉬알고리즘을통해 160 비트길이의값을생성하고그값으로부터 40 비트를추출 ) ULA 사용고려사항문서는워킹그룹드래프트로채용되어있으며 3 번째수 정버전이발표되었으며, ULA 의여러가지사용시나리오를분석하고참고할 만한유즈케이스를기술하고있다. 유즈케이스는아래와같다. - 4 -
1) 분리된망에서 ULA만을적용 2) 인터넷에연결된망에서 ULA만가지고내부네트워크주소를적용 3) 인터넷에연결된망에서 ULA와 ISP에할당받은주소를혼재하여적용 4) IPv4와 IPv6 ULA를동시에적용 NTT는해당드래프트관련하여 JANOG(JApan Network Operator s Group) 의 34번째컨퍼런스에서위드래프트에따라 ULA 적용테스트를수행한결과를발표하였는데, 테스트결과컨퍼런스네트워크에 ULA와 GUA, IPv4 사설주소를함께적용하였을때문제없이통신됨을확인하였다. 그러나 JANOG34 테스트베드에서 Android 운영체제에서는 IPv6 사용이불가능했으며, Skype와 Dropbox 어플리케이션은 IPv4 없이 IPv6 ULA만을할당했을때통신이어려웠음을발표하고개선이필요함을지적하였다. 한편 2013년도에 V6OPS 워킹그룹에서표준화된 464XLAT 전환기술은 CLAT(Client Side Translator) 과 PLAT(Provider Side Translator) 이라는양방향변환기를이용하여 IPv6 네트워크에서 IPv4 패킷을처리하는전환기술로, 현재미국의 T-mobile이 464XLAT을이용해상용 IPv6 서비스를개시한바있다. 90차 IETF에서는로드밸런싱을위하여여러개의 PLAT을운영하는방법론이제안되었다. PLAT은 Client에서 IPv4 패킷을받았을때 ISP망에서처리가능한 IPv6 주소로변환해주고 IPv6 패킷을받았을때에는그냥통과시켜주는변환기이며, 464XLAT 아키텍처는 Single PLAT 시나리오를기반으로하고있어 NAT장비의특성상 PLAT장비에부하가클수있으므로 PLAT을여러개운영하여부하를분산하는방법을제안한것이다. 또한 Cisco에서무선 (Wi-Fi) 장비에서 IPv6 멀티캐스트시전력소비량에대한실험결과를공유하였다. IPv6은 ND(Neighbor Discovery) 나 DHCPv6, mdns (Multicast DNS) 등의프로토콜에서멀티캐스트메시지를이용하는데, 89차 IETF 회의에서 IPv6 only 환경의 Wi-fi를무선장비에서이용할시배터리가빠르게소모된다는제보이후실제전력소비량을측정한것이다. 실험결과, Idle mode 에있는스마트폰등의무선장비는평균적으로 10mA 의 매우낮은전력을소모하지만, 멀티캐스트프레임을받았을시메인 CPU 의구동 - 5 -
이시작되며순간적으로 100~150mA 정도의높은전력소모량을보였으며, 메인 CPU 구동없이 L2단에서멀티캐스트프레임을받는동안에는 40mA정도의전력소모량을보였다. Cisco는사물인터넷을위한다양한환경에서전력소모량을최소화하기위한솔루션을아래와같이제안하였다. 1) RA(Router Advertisement) 메시지간의인터벌을확대 2) NUD(Neighbor Unreachability Detection) 메시지의인터벌을확대 3) RA를 Unicast로송신 4) 인프라레벨에서멀티캐스트를필터링 III. SUNSET4 워킹그룹표준화동향 SUNSET4 워킹그룹은 IPv6로의안정적인전환을위하여 IPv4/IPv6 갭분석등을수행하고 IPv6 전환이거의완료되는시점에 IPv4를어떻게종료할 (Turning off) 할것인지방법론을논의하는워킹그룹이다. SUNSET4 워킹그룹은 90차회의에서 4개의인터넷드래프트를논의하였고아직워킹그룹문서로채택된문서는없다. 90 차워킹그룹회의에서 Viagenie 는 DHCPv6 나 ICMP 의 RA 메세지를활용 하여하부에 IPv4 가존재하지않음을상위네트워크에알리는방법론을제안하 였다. DHCPv4와 DHCPv6을모두이용할수있는듀얼스택홈게이트웨이가부팅될때그 CPE는 DHCPv4 서버로서동작하며 LAN 인터페이스를통해 IPv4 주소를분배하고, 동시에 DHCPv6 서버로서 IPv6 주소를분배하는데, 이때 WAN쪽인터페이스는 IPv4와 IPv6을위한병렬적인프로비저닝프로시저를시작하고, 이시점에서 ISP는 CPE가 IPv6 only로동작하는지여부를알수없으므로 DHCPv4 요청에도응답하게된다. 또한네트워크내부에 IPv4 클라이언트가없을시 CPE는 ISP의 BR(Border Router) 에 OPTION_NO_IPv4 옵션을포함한 DHCPv6 리퀘스트를보내게되며, ISP는이옵션이포함된요청에응답하게된다. 이프로시저가끝나면 ISP는이고객이네트워크를 IPv6-only 모드로운영할것이고 IPv4 패킷을첫번째홉에서드랍할것이라는것을알게되고, ISP의응답을받은 CPE는 IPv4 프로비저닝프로시저를중단하고 DHCPv4를포함한모든 IPv4 기능을비활성화하는방식이다. - 6 -
회의에서는이방법론이 (CPE에서) DHCPv4를꼭운영해야하고, 더아래쪽레이어에서 IPv4를차단하는등의대안을고려하지않아명확한요구나갭분석이필요함을지적하였으며특히 ISP가 no IPv4 시그널을보내더라도 CPE 내부의홈네트워크에서는 IPv4를계속운영할수있는점이주요개선점으로지적되었다. V. 맺음말 IPv6의기본기술개발이완료되고주요장비교체및네트워크준비도를높이는기간에는 6RD와같이 IPv4 네트워크에 IPv6 단말을연결하기위한전환기술이주로논의되었으나, 각구간의 IPv6 지원준비가대부분마무리되고 IPv6 상용서비스가전세계적으로빠르게확산되는추세에맞춰, 최근의 IETF 회의에서논의되고있는 IPv6 전환기술은주로 IPv6 네트워크를전제하고있다. 2013년에표준화된 464XLAT을필두로 SOFTWIRE 워킹그룹에서논의되고있는전환기술또한백본 IPv6 시나리오를전제하고있다. 국내환경또한마찬가지로백본네트워크의 IPv6 지원준비는완료된상황이며실제사용자환경을 IPv4-IPv6이공존할수있도록구성하는데에있어서상기한전환기술에대한고려가필요할것이며, 운영개시후발생하는이슈에대한대응을위하여지속적으로 IETF의해당워킹그룹을주목할필요가있을것이다. - 7 -
< 참고문헌 > 1. IETF Internet-Draft, Lightweight 4over6: An Extension to the DS-Lite Architecture, http://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ 2014.09.26. 2. IETF Internet-Draft, Deployment Considerations for Lightweight 4over6, http://www.ietf.org/archive/id/draft-sun-softwire-lightweigh-4over6-de ployment-04.txt 2014.07.14. 3. IETF Internet-Draft, IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd), https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/, 2014.09.26. 4. IETF Internet-Draft, IPv6 Multicast in a 6rd Deployment, https://datatracker.ietf.org/doc/draft-zhou-softwire-6rdmulticast/, 2014.06.26. 5. IETF Internet-Draft, Mapping of Address and Port with Encapsulation (MAP), https://datatracker.ietf.org/doc/draft-ietf-softwire-map/, 2014.09.26 6. IETF Internet-Draft, Mapping of Address and Port using Translation (MAP-T), https://datatracker.ietf.org/doc/draft-ietf-softwire-map-t/, 2014.09.26. 7. IETF RFC4193, Unique Local IPv6 Unicast Addresses, http://www.rfc-editor.org/rfc/rfc4193.txt, 2005.10. 8. IETF Internet-Draft, Considerations of Using Unique Local Addresses, http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendat ions/, 2014.07.04. 9. IETF Internet-Draft, Running Multiple PLATs in 464XLAT, draft-sun-v6ops-xlat-multi-00, http://datatracker.ietf.org/doc/draft-sun-v6ops-xlat-multi/, 2014.07.04. 10. IETF Internet-Draft, Turning off IPv4 Using DHCPv6 or Router Advertisements, http://www.ietf.org/archive/id/draft-ietf-sunset4-noipv4-00.txt, 2013.9.24. - 8 -