[펌] 개발자를 힘들게 하는 애플의 IPv6 검수 통과하기

---

 출처: http://meetup.toast.com/posts/91

---

개발자를 힘들게 하는 애플의 IPv6 검수 통과하기

목차

IPv6에 대해서 최소한도로 알아보기
Apple에서 공지한 iOS 앱에 대한 검수 내용 살펴보기
개발자들이 주의해야 할 사항
IPv6 로 인한 App Reject 사례와 참고 자료

지난 WWDC15 이후에 Apple 개발자 페이지에 올라온 News인 Supporting IPv6 in iOS 9에서는 IPv6-only network service가 지원돼야 한다는 정책을 발표하고, 2016년도 초부터 해당 사항을 앱 리뷰 시에 적용한다고 했습니다. 뉴스를 보자마자 머리가 띵해져 왔지만, 사실 이때까지만 해도 잘 와 닿지 않았던 이유는 IPv6 only Network를 일반인들에게 제공하는 국내 ISP는 존재하지 않았기 때문에 Apple이 무엇을 원하는지, 그리고 도대체 어느 수준까지 앱 리뷰할 때 Reject 기준이 될지 머릿속에서 혼란이 왔습니다.

물론 Apple답게 테스트 방법에 대한 가이드라인이 있었기 때문에 해당 문서를 보고 제가 담당하고 있는 SDK에 대한 테스트를 진행해봤지만, 역시나 IPv6 only network에서는 통신이 이루어지지 않았습니다.

처음에는 사내 네트워크 환경부터 SDK의 소스 코드 등을 살펴 보았지만, 크게 문제가 있어 보이지는 않았습니다. 하지만 컴퓨터는 거짓말을 하지 않는지라 SDK 내에서 사용하고 있는 Open Source 라이브러리를 살펴보니, IPv6를 지원할 수 없는 상태였습니다. 따라서 해당 문제를 해결하고 나니 정상적으로 IPv6 환경에서의 테스트가 성공하게 되었습니다.

이제부터의 글은 제가 IPv6에 대한 이슈를 처리하기 위하여 알아본 기본적인 내용에 대해서 적어보도록 하겠습니다.

IPv6에 대해서 최소한도로 알아보기

주소의 길이가 128bit로써 급격하게 늘어나는 인터넷 연결 기기와 이에 따른 IPv4 주소의 고갈에 대응하여 제안되었습니다.
IPv6는 기존 Ipv4와의 호환성을 최대한 유지할 수 있는 방향으로 설계되어, 대부분의 기존 프로토콜의 수정 없이 IPv6 상에서
동작할 수 있습니다.

주소 표현 방법

주소의 표현은 128bit의 주소공간으로써 16bit(2octet)를 16진수로 표현하여 8자리로 구성합니다.

2001:0db8:85a3:0000:0000:8a2e:0370:7334

위의 Address Literal은 아래와 같이 표현할 수 있습니다.
0000 은 0으로 축약할 수 있으며, 아래와 같이 생략할 수도 있습니다.

2001:0db8:85a3:8a2e:0370:7334

IPv6의 특성

IPv6의 특성에 대해서 간략하게 알아보겠습니다.

• IP 주소의 확장: IPv4의 기존 32 비트 주소공간에서 벗어나, IPv6는 128 비트 주소공간을 제공합니다.
• 호스트 주소 자동 설정: IPv6 호스트는 IPv6 네트워크에 접속하는 순간 자동적으로 네트워크 주소를 부여 받습니다.
  이는 네트워크 관리자로부터 IP 주소를 부여 받아 수동으로 설정해야 했던 IPv4에 비해 중요한 사항입니다.
• 패킷 크기 확장: IPv4에서 패킷 크기는 64킬로바이트로 제한되어 있었습니다. IPv6의 점보그램 옵션을 사용하면 특정 호스트 사이에는 임의로 큰 크기의 패킷을 주고받을 수 있도록 제한이 없어지게 됩니다. 따라서 대역폭이 넓은 네트워크를 더 효율적으로 사용할 수 있습니다.
• 효율적인 라우팅: IP 패킷의 처리를 신속하게 할 수 있도록 고정크기의 단순한 헤더를 사용하는 동시에, 확장헤더를 통해 네트워크 기능에 대한 확장 및 옵션기능의 확장이 용이한 구조로 정의 했습니다.
• 플로 레이블링(Flow Labeling): 플로 레이블(flow label) 개념을 도입, 특정 트래픽은 별도의 특별한 처리(실시간 통신 등)를 통해 높은 품질의 서비스를 제공할 수 있도록 합니다.
• 인증 및 보안 기능: 패킷 출처 인증과 데이터 무결성 및 비밀 보장 기능을 IP 프로토콜 체계에 반영 하였습니다.
  IPv6 확장헤더를 통해 적용할 수 있습니다.
• 이동성: IPv6 호스트는 네트워크의 물리적 위치에 제한 받지 않고 같은 주소를 유지하면서도 자유롭게 이동할 수 있습니다.
  이와 같은 모바일 IPv6는 RFC 3775와 RFC 3776에 기술되어 있습니다.
  (IPv4에도 모바일 IP가 정의되어 있지만 아직 많이 사용되지 않습는다.)

참조 : https://ko.wikipedia.org/wiki/IPv6

Apple에서 공지한 iOS 앱에 대한 검수 내용 살펴보기

iPhone 앱에 대한 검수

많은 개발자들이 야근을 하게한 원흉인 Apple의 공지: https://developer.apple.com/news/?id=05042016a

내용은 아주 간단하게도 IPv6 only 네트워크에서도 App이 정상적으로 동작을 해야 한다는 것입니다.
이는 IPv4에 기반한 API의 작동은 되지 않는다는 것을 의미합니다. 일반적으로 네트워크 통신 시, NSURLSession과 CFNetwork 같은
High Level API의 경우는 이미 IPv6에 대한 지원에 문제가 없으나, Low-Level socket APIs를 직접 사용할 경우에는 구조체와 함수 등
IPv4 전용 함수를 사용하고 있는지에 대해서 확인이 필요합니다.

또한 앱에서 네트워크 통신 시, 하드 코딩 된 IPv4 주소를 사용하거나, 또는 서버에서 전달해주는 주소가 IPv4 주소를 사용하여
서버에 접근할 때도 앱에 대한 수정이 필요합니다.

따라서 아래에 기술한 방법과 같이 테스트 환경을 구축하여, 정상적으로 네트워크 통신이 가능해야 합니다.

IPv6 테스트 방법

일반적으로는 IPv6 only 네트워크 환경을 갖추고 테스트를 할 수가 없을 것이기 때문에 Apple에서는 IPv6 테스트를 위하여
NAT64/DNS64 환경을 구성할 수 있도록 가이드를 마련해주었습니다.

테스트 환경

[https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW16] 에서 발췌

테스트 환경을 구축하기 위해서는 아래와 같은 장비가 필요합니다.

1. 유, 무선 지원하는 MacOS가 설치된 장비
2. iPhone, MacOS 장비

MacOS장비의 경우 DNS64, NAT64 역할을 하여 연결된 iOS Device에 IPv6주소를 할당하고, 외부 네트워크(IPv4)와의 통신을 할 수 있도록 해줍니다. (NAT64는 IPv6와 IPv4 호스트들 간에 통신을 할 수 있도록 하는 기술이며, DNS64는 DNS 서버에 AAAA 레코드를 요청했을 때, A 레코드만 존재한다면 A 레코드로부터 AAAA 레코드로 합성(변환)을 해주어서 요청한 서버의 IP주소를 획득할 수 있도록 합니다.)

iPhone은 인터넷 공유(NAT64)를 활성화 시킨 iMac(위의 1항목을 충족한다면 다른 장비도 가능)의 장비에 접속하며, iMac은 유선랜으로 기존 인터넷 환경에 접속하면 됩니다.

따라서 iPhone은 NAT64 환경에서 제공하는 IPv6 주소를 할당 받게 됩니다. 자세한 사항은 아래의 링크를 참고하시면 됩니다.

[https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW16]

만일 위와 같은 방법으로 테스트 시에 네트워크 통신이 제대로 되지 않는다거나, 오동작하는 경우가 발생한다면, 아래의 케이스에 대한 확인이 필요합니다.

1. IP literal을 직접 hard-coding하여 프로그램에서 사용하고 있는지? 또는 IP Address를 설정파일이나 서버로부터 획득하여 socket연결을 시도하는지?
2. Network Preflight(통신 전, Wi-Fi, Cellular 등의 연결 테스트)를 ZeroAddress (0.0.0.0)으로 Reachability Test를 하는지?
3. Low-Level Networking API들을 사용하는지 (소스코드 및 외부 라이브러리)
4. IP Address를 저장하기 위하여 uint32_t, in_addr, sockaddr_in과 같은 변수 타입(32bit 이하의 크기)을 사용하는지?

다음 항목에서는 위의 내용에 대해서 좀더 자세히 살펴보도록 하겠습니다.

개발자들이 주의해야 할 사항

IP literal을 프로그램 상에 Hard-Coding한 경우

일반적으로는 IP literal을 직접 사용하는 경우는 없겠지만, 일부 시스템의 경우, 최초 서버에 접근한 후, 해당 서버에서 IP를 할당 받아 다시 할당 받은 IP로 접속하게 하는 시스템들이 있을 수 있습니다. 또는 설정파일에서 IP를 가져와서 사용하는 경우도 있을 수 있습니다. 이럴 경우에는 IPv6 only 네트워크 상에서는 통신이 정상적으로 이루어지지 않으며, Apple 검수 시 Reject 사유가 됩니다. 따라서 반드시 DNS를 이용하여 IP를 획득할 수 있도록 해야 합니다.

Network Preflight를 할 경우

iPhone이나 iPad등 Mobile Device에서는 네트워크 통신이 항상 연결되어 있다고 보장을 할 수 없기 때문에, 통신 전에 Wi-Fi나 Cellular 연결 상태를 확인한 뒤, 통신을 하도록 구현을 많이 하는데요. 이 때, 기존에는 Zero-Address (0.0.0.0)로 Reachability Test를 많이 사용했습니다.

하지만 IPv6 only 네트워크의 경우에도 Zero-Address로 Reachability Test를 할 경우 정상적으로 연결 상태를 확인할 수 없습니다.
따라서 아래와 같이 변경이 필요합니다.

일반적으로 IPv4 네트워크 환경에는 아래의 API에 Zero-Address를 할당하여 연결테스트를 했습니다.

SCNetworkReachabilityCreateWithAddress()

IPv4및 IPv6 네트워크 환경을 동시에 지원하기 위해서는 아래의 API를 통하여 실제 DNS에 존재하는 Host명을 기입하여 연결테스트를 하도록
해야 합니다.

reachability = SCNetworkReachabilityCreateWithName(kCFAllocatorDefault, @"www.google.com" UTF8String]);

SCNetworkReachabilityCreateWithName() 함수를 통하여 연결테스트를 할 때 실제 해당 Domain을 가지고 있는 서버로의 연결상의 부하는 발생하지 않으며, 네트워크 연결 상태만 확인합니다.

Low-Level Networking API들을 사용하는 경우

iOS Foundation Framework에서 지원하는 High-Level API들만을 사용하여 통신을 한다면 별도의 처리는 필요가 없지만, 일반적으로는 Websocket등의 통신을 위하여 외부 라이브러리를 사용하거나, 통신성능을 높이기 위하여 Open Source 네트워크 라이브러리를 사용하는 경우가 있습니다. 이럴 때는 Open Source 상에서 아래와 같은 함수들 만을 사용하고 있는지 확인해야 합니다.

아래와 같은 IPv4 전용 API들이 있다면 확인하여 제거(또는 변경)이 필요합니다.

• inet_addr()
• inet_aton()
• inet_lnaof()
• inet_makeaddr()
• inet_netof()
• inet_network()
• inet_ntoa()
• inet_ntoa_r()
• bindresvport()
• getipv4sourcefilter()
• setipv4sourcefilter()

IPv4 타입을 사용하는 부분이 있다면 IPv6 타입도 똑같이 지원을 해야 합니다.

IPv4	IPv6
AF_INET	AF_INET6
PF_INET	PF_INET6
struct in_addr	struct in_addr6
struct sockaddr_in	struct sockaddr_in6
kDNSServiceProtocol_IPv4	kDNSServiceProtocol_IPv6

IPv6 로 인한 App Reject 사례와 참고 자료

App Reject 사례

일부 앱에서 6월 1일 이후에 검수를 올린 App에서 별다른 변경사항 없이 Reject를 당하는 경우가 발생하였으며, Review Reject 사유에서는 IPv6 only network에서 정상적으로 게임이 실행되지 않는다는 이유를 듣게 되었습니다.

게임과 게임 서버의 통신상에서는 이미 IPv6를 지원하는 API를 사용하도록 조치하고 앱에서 사용하는 모든 서버의 주소를 Domain을 등록하도록 변경하여 문제 없이 검수를 통과할 수 있을 것으로 생각했지만, 위에 말씀 드린 것과 같이 정상적으로 검수를 통과하지 못했습니다. 확인 결과로는 서버로부터 IPv4 주소를 받아서 클라이언트가 그 주소 기반으로 접속을 시도하는 중에 이슈가 문제가 발생하였으며, 해당 주소가 IPv4 literal로 구성되어 있어서, IPv6 only network 환경에서는 정상적으로 Connection을 맺을 수 없는 상황이었던 것입니다.

최근에는 앱을 개발할 때 Open Source나 외부솔루션을 많이 사용하고 있는 추세이기 때문에, 앱에서 사용하고 있는 외부 솔루션에 대해서 IPv6에 대해서 지원이 되는지 명확히 확인해야 할 필요성이 있습니다.

참고 자료

• IPv6 only network 테스트 가이드: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW16
• Application Aspects of IPv6 Transition: https://tools.ietf.org/html/rfc4038
• Unity iOS and IPv6 support: http://forum.unity3d.com/threads/unity-ios-and-ipv6-support.404938/
• NAT64 Technology: Connecting IPv6 and IPv4 Networks: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html