유니버설 플러그 앤 플레이

UPnP 포럼(2001–2016) 및 오픈 커넥티비티 파운데이션(2016–현재)이 추진한 UPnP 로고

UPnP(원래 명칭: 유니버설 플러그 앤 플레이, Universal Plug and Play)는 개인용 컴퓨터, 프린터, 게이트웨이, 와이파이 액세스 포인트 및 모바일 장치와 같은 네트워크 장치들이 네트워크상에서 서로의 존재를 원활하게 검색하고 기능적인 네트워크 서비스를 구축할 수 있도록 허용하는 인터넷 프로토콜 기반 네트워킹 프로토콜 세트이다. UPnP는 주로 기업용 장비가 없는 가정용 네트워크를 대상으로 한다. 공식적으로는 약어인 UPnP와 UPnP+만이 상표로 등록되어 있다.

UPnP는 네트워크가 IP를 실행한다고 가정하며, IP 상단에서 HTTP를 사용하여 장치/서비스 설명, 동작, 데이터 전송 및 이벤트 알림을 제공한다. 장치 검색 요청 및 광고는 멀티캐스트(HTTPMU로 알려짐)를 사용하는 UDP(포트 1900) 상단의 HTTP를 통해 지원된다. 검색 요청에 대한 응답 또한 UDP를 통해 전송되지만, 대신 유니캐스트(HTTPU로 알려짐)를 사용하여 전송된다.

개념적으로 UPnP는 장치를 컴퓨터에 직접 동적으로 연결하는 기술인 플러그 앤 플레이를 가정용 및 소호 무선 네트워크를 위한 Zeroconf로 확장한다. UPnP 장치는 네트워크에 연결될 때 다른 장치와 자동으로 작동 구성을 설정하므로, 사용자가 IP 주소를 통해 수동으로 장치를 구성하고 추가할 필요가 없다는 점에서 플러그 앤 플레이 방식이다.

UPnP는 일반적으로 경제성, 복잡성 및 일관성 문제로 인해 비즈니스 환경에서의 배포에는 부적합한 것으로 간주된다. 멀티캐스트 기반 방식은 통신량이 많아 장치 수가 많은 네트워크에서 너무 많은 네트워크 리소스를 소비하며, 단순화된 액세스 제어는 복잡한 환경에 잘 맞지 않기 때문이다.

개요

UPnP 아키텍처는 컨슈머 일렉트로닉스, 모바일 장치, 개인용 컴퓨터 및 네트워크에 연결된 가전제품 간의 장치 대 장치 네트워킹을 허용한다. 이는 인터넷 프로토콜 스위트(TCP/IP), HTTP, XML 및 SOAP와 같이 확립된 표준을 기반으로 하는 분산형 오픈 아키텍처 프로토콜이다. UPnP 제어 지점(CP)은 UPnP 프로토콜을 사용하여 UPnP 제어 대상 장치(CD)를 제어하는 장치이다.

UPnP 아키텍처는 Zeroconf 네트워킹을 지원한다. 어떤 제조사의 UPnP 호환 장치라도 동적으로 네트워크에 참여하고, IP 주소를 할당받으며, 자신의 이름을 알리고, 요청 시 자신의 기능을 광고하거나 전달하며, 다른 장치의 존재와 기능을 파악할 수 있다. 동적 호스트 구성 프로토콜(DHCP) 및 도메인 네임 시스템(DNS) 서버는 선택 사항이며 네트워크에서 사용 가능한 경우에만 사용된다. 장치는 상태 정보를 남기지 않고 네트워크에서 자동으로 연결을 해제할 수 있다.

UPnP는 2008년 12월에 73부로 구성된 국제 표준 ISO/IEC 29341로 발표되었다.

기타 UPnP 기능은 다음과 같다:

매체 및 장치 독립성
UPnP 기술은 이더넷, 파이어와이어, 적외선(IrDA), 홈 배선(G.hn) 및 무선 주파수(블루투스, 와이파이)를 포함하여 IP를 지원하는 많은 매체에서 실행될 수 있다. 특별한 장치 드라이버 지원은 필요하지 않으며, 대신 일반적인 네트워크 프로토콜이 사용된다.
사용자 인터페이스(UI) 제어
선택적으로 UPnP 아키텍처를 통해 장치는 웹 브라우저를 통해 사용자 인터페이스를 제공할 수 있다(아래의 프레젠테이션 참조).
운영체제 및 프로그래밍 언어 독립성
UPnP 제품을 빌드하는 데 모든 운영체제와 프로그래밍 언어를 사용할 수 있다. UPnP 스택은 대부분의 플랫폼과 운영체제에서 폐쇄형 및 오픈 소스 형태로 모두 제공된다.
프로그램 제어
UPnP 아키텍처는 또한 기존의 애플리케이션 프로그램 제어를 가능하게 한다.
확장성
각 UPnP 제품은 기본 아키텍처 위에 장치별 서비스를 계층화할 수 있다. UPnP 포럼에서 정의한 서비스를 다양한 방식으로 결합하는 것 외에도, 벤더는 자신만의 장치 및 서비스 유형을 정의할 수 있다. 표준 장치 및 서비스를 벤더 정의 동작, 상태 변수, 자료 구조 요소 및 변수 값으로 확장할 수 있다.

프로토콜

UPnP는 일반적인 인터넷 기술을 사용한다. 네트워크가 반드시 인터넷 프로토콜(IP)을 실행해야 한다고 가정하며, IP 상단에서 HTTP, SOAP 및 XML을 사용하여 장치/서비스 설명, 동작, 데이터 전송 및 이벤팅을 제공한다. 장치 검색 요청 및 광고는 멀티캐스트(HTTPMU로 알려짐)를 사용하는 UDP 상단의 HTTP를 통해 지원된다. 검색 요청에 대한 응답 또한 UDP를 통해 전송되지만, 대신 유니캐스트(HTTPU로 알려짐)를 사용하여 전송된다. UPnP는 수신 데이터 확인이나 손상된 패킷의 재전송이 필요하지 않아 오버헤드가 적은 UDP를 사용한다. HTTPU 및 HTTPMU 사양은 처음에 인터넷 드래프트로 제출되었으나 2001년에 만료되었으며, 이후 이 사양들은 실제 UPnP 사양에 통합되었다.

UPnP는 UDP 포트 1900을 사용하며, 사용되는 모든 TCP 포트는 SSDP 생존(alive) 및 응답 메시지에서 파생된다.

주소 지정

UPnP 네트워킹의 기초는 IP 주소 지정이다. 각 장치는 DHCP 클라이언트를 구현해야 하며 장치가 네트워크에 처음 연결될 때 DHCP 서버를 검색해야 한다. 사용할 수 있는 DHCP 서버가 없으면 장치는 스스로 주소를 할당해야 한다. UPnP 장치가 스스로 주소를 할당하는 프로세스는 UPnP 장치 아키텍처 내에서 AutoIP로 알려져 있다. UPnP 장치 아키텍처 버전 1.0에서 AutoIP는 사양 자체에 정의되어 있으며, UPnP 장치 아키텍처 버전 1.1에서는 AutoIP가 IETF RFC 3927을 참조한다. DHCP 트랜잭션 중에 장치가 DNS 서버 또는 DNS 포워딩 등을 통해 도메인 이름을 획득하면 이후의 네트워크 작업에서 해당 이름을 사용해야 하며, 그렇지 않으면 IP 주소를 사용해야 한다.

검색

장치가 IP 주소를 설정하면 UPnP 네트워킹의 다음 단계는 검색이다. UPnP 검색 프로토콜은 Simple Service Discovery Protocol(SSDP)로 알려져 있다. 장치가 네트워크에 추가되면 SSDP를 통해 해당 장치가 네트워크상의 제어 지점에 자신의 서비스를 광고할 수 있다. 이는 SSDP 생존 메시지를 전송함으로써 이루어진다. 제어 지점이 네트워크에 추가되면 SSDP를 통해 해당 제어 지점이 네트워크에서 관심 있는 장치를 능동적으로 검색하거나 장치로부터의 SSDP 생존 메시지를 수동적으로 청취할 수 있다. 기본적인 교환은 장치 또는 그 서비스 중 하나에 대한 몇 가지 필수 세부 정보(유형, 식별자 및 더 상세한 정보에 대한 포인터(네트워크 위치) 등)가 포함된 검색 메시지이다.

설명

제어 지점이 장치를 발견한 후에도 장치에 대해 아는 바는 거의 없다. 제어 지점이 장치 및 그 기능에 대해 더 많이 알거나 장치와 상호 작용하려면 검색 메시지에서 장치가 제공한 위치(URL)에서 장치 설명을 검색해야 한다. UPnP 장치 설명은 XML로 표현된다. 여기에는 모델 이름 및 번호, 일련번호, 제조사 이름, 제조사별 웹사이트의 (프레젠테이션) URL 등과 같은 제조사별 정보가 포함된다. 설명에는 임베디드 서비스 목록도 포함된다. 각 서비스에 대해 장치 설명 문서에는 제어, 이벤팅 및 서비스 설명에 대한 URL이 나열된다. 각 서비스 설명에는 서비스가 응답하는 명령어 또는 동작 목록과 각 동작에 대한 매개변수 또는 인수가 포함된다. 서비스 설명에는 변수 목록도 포함되며, 이러한 변수들은 런타임 시 서비스의 상태를 모델링하며 데이터 유형, 범위 및 이벤트 특성 측면에서 설명된다.

제어

장치의 설명을 검색한 제어 지점은 장치의 서비스에 동작을 보낼 수 있다. 이를 위해 제어 지점은 (장치 설명에 제공된) 서비스의 제어 URL로 적절한 제어 메시지를 보낸다. 제어 메시지는 단순 객체 액세스 프로토콜(SOAP)을 사용하여 XML로 표현된다. 함수 호출과 마찬가지로 서비스는 제어 메시지에 대한 응답으로 동작별 값을 반환한다. 동작의 효과는 서비스의 런타임 상태를 설명하는 변수의 변화로 모델링된다.

이벤트 알림

UPnP 네트워킹의 또 다른 기능은 이벤트 알림 또는 이벤팅이다. UPnP 장치 아키텍처에 정의된 이벤트 알림 프로토콜은 일반 이벤트 알림 아키텍처(GENA)로 알려져 있다. 서비스에 대한 UPnP 설명에는 서비스가 응답하는 동작 목록과 런타임 시 서비스의 상태를 모델링하는 변수 목록이 포함된다. 이러한 변수가 변경되면 서비스는 업데이트를 게시하고 제어 지점은 이 정보를 받기 위해 구독할 수 있다. 서비스는 이벤트 메시지를 전송하여 업데이트를 게시한다. 이벤트 메시지에는 하나 이상의 상태 변수 이름과 현재 값이 포함된다. 이러한 메시지도 XML로 표현된다. 제어 지점이 처음 구독할 때 특별한 초기 이벤트 메시지가 전송된다. 이 이벤트 메시지에는 모든 이벤트 변수의 이름과 값이 포함되어 구독자가 서비스 상태 모델을 초기화할 수 있게 한다. 여러 제어 지점이 있는 시나리오를 지원하기 위해 이벤팅은 모든 제어 지점에 동작의 효과에 대해 동일하게 정보를 제공하도록 설계되었다. 따라서 모든 구독자에게 모든 이벤트 메시지가 전송되며, 구독자는 변경된 모든 "이벤트" 변수에 대한 이벤트 메시지를 받게 되며, 상태 변수가 변경된 이유(요청된 동작에 대한 응답이든 서비스가 모델링하는 상태의 변화이든)에 관계없이 이벤트 메시지가 전송된다.

프레젠테이션

UPnP 네트워킹의 마지막 단계는 프레젠테이션이다. 장치에 프레젠테이션용 URL이 있는 경우 제어 지점은 이 URL에서 페이지를 가져와 웹 브라우저에 로드할 수 있으며, 페이지의 기능에 따라 사용자가 장치를 제어하거나 장치 상태를 볼 수 있도록 허용할 수 있다. 이러한 기능이 수행될 수 있는 정도는 프레젠테이션 페이지와 장치의 구체적인 능력에 따라 달라진다.

AV 표준

UPnP AV 아키텍처는 TV, VCR, CD/DVD 플레이어/쥬크박스, 셋톱박스, 스테레오 시스템, MP3 플레이어, 정지 영상 카메라, 캠코더, 전자 액자(EPF) 및 개인용 컴퓨터와 같은 다양한 장치를 지원하는 UPnP의 오디오 및 비디오 확장이다. UPnP AV 아키텍처를 통해 장치는 MPEG2, MPEG4, JPEG, MP3, 윈도우 미디어 오디오(WMA), 비트맵(BMP) 및 NTSC, PAL 또는 ATSC 형식을 포함한 엔터테인먼트 콘텐츠를 위한 다양한 형식을 지원할 수 있다. IEEE 1394, HTTP, RTP 및 TCP/IP를 포함한 여러 유형의 전송 프로토콜이 지원된다.

2006년 7월 12일, UPnP 포럼은 미디어 서버(MS) 버전 2.0 및 미디어 렌더러(MR) 버전 2.0 클래스와 함께 UPnP 오디오 및 비디오 사양 버전 2의 출시를 발표했다. 이러한 향상된 기능은 미디어 서버 및 미디어 렌더러 장치 클래스에 기능을 추가하여 서로 다른 제조사 제품 간의 더 높은 수준의 상호 운용성을 가능하게 한다. 이 표준을 준수하는 초기 장치 중 일부는 필립스가 Streamium 브랜드로 마케팅했다.

2006년 이후 UPnP 오디오 및 비디오 장치 제어 프로토콜의 버전 3과 4가 발표되었다. 2013년 3월에는 업데이트된 장치 제어 프로토콜을 통합한 업데이트된 UPnP AV 아키텍처 사양이 발표되었다. UPnP 장치 아키텍처 2.0은 2020년 4월에 출시되었다.

UPnP AV 표준은 Digital Living Network Alliance(DLNA) 네트워크 장치 상호 운용성 지침, 국제전기기술위원회 IEC 62481-1, 및 Cable Television Laboratories OpenCable 홈 네트워킹 프로토콜을 포함하여 다른 기관에서 발행한 사양에서 참조되었다.

AV 구성 요소

일반적으로 UPnP 오디오/비디오(AV) 아키텍처는 다음으로 구성된다.

미디어 서버

UPnP AV 미디어 서버는 미디어 라이브러리 정보를 제공하고 오디오/비디오/사진/파일과 같은 미디어 데이터를 네트워크의 UPnP 클라이언트에 스트리밍하는 UPnP 서버("마스터" 장치)이다. 이는 사진, 영화 또는 음악과 같은 디지털 미디어를 저장하고 이를 다른 장치와 공유하는 컴퓨터 시스템 또는 유사한 디지털 가전이다.

UPnP AV 미디어 서버는 서버의 미디어 콘텐츠를 브라우징하고 미디어 서버에 재생을 위한 파일 전달을 요청하는 제어 지점이라고 불리는 UPnP AV 클라이언트 장치에 서비스를 제공한다.

UPnP 미디어 서버는 대부분의 운영체제와 많은 하드웨어 플랫폼에서 사용할 수 있다. UPnP AV 미디어 서버는 소프트웨어 기반 또는 하드웨어 기반으로 분류될 수 있다. 소프트웨어 기반 UPnP AV 미디어 서버는 PC에서 실행될 수 있다. 하드웨어 기반 UPnP AV 미디어 서버는 모든 NAS 장치 또는 DVR과 같은 미디어 전달을 위한 특정 하드웨어에서 실행될 수 있다. 2008년 5월 현재 하드웨어 기반 서버보다 소프트웨어 기반 UPnP AV 미디어 서버가 더 많았다.

기타 구성 요소

NAT 트래벌설

NAT 트래벌설을 위한 한 가지 해결책으로 인터넷 게이트웨이 장치 제어 프로토콜(UPnP IGD)이 UPnP를 통해 구현된다. 많은 라우터와 방화벽은 스스로를 인터넷 게이트웨이 장치로 노출하여, 로컬 UPnP 제어 지점이 장치의 외부 IPv4 주소 검색, 기존 포트 매핑 열거, 포트 매핑 추가 또는 제거를 포함한 다양한 동작을 수행할 수 있도록 허용한다. 포트 매핑을 추가함으로써 IGD 뒤에 있는 UPnP 컨트롤러는 외부 주소에서 내부 클라이언트로의 IGD 트래벌설을 활성화할 수 있다.

실제로 하위 호환되는 방대한 IGDv1 및 IGDv2 사양에 대한 서로 다른 해석으로 인해 수많은 호환성 문제가 존재한다. 그중 하나는 현재 마이크로소프트 윈도우 및 Xbox 시스템에 통합된 UPnP IGD 클라이언트와 인증된 IGDv2 라우터 간의 문제이다. 이 호환성 문제는 2001년 윈도우 XP에 IGDv1 클라이언트가 도입된 이후 계속되었으며, 해결 방법이 없는 IGDv2 라우터는 라우터 포트 매핑을 불가능하게 만든다.

UPnP가 라우터 포트 매핑 및 핀홀 제어에만 사용되는 경우, PCP 및 NAT-PMP와 같이 IETF에서 RFC로 표준화한 더 새롭고 훨씬 간단하며 가벼운 대안 프로토콜이 있다. 이러한 대안들은 아직 서로 다른 클라이언트와 서버 간의 호환성 문제가 알려져 있지 않지만 채택률은 여전히 낮다. 소비자용 라우터의 경우 현재 AVM과 오픈 소스 라우터 소프트웨어 프로젝트인 OpenWrt, OPNsense 및 pfSense만이 UPnP의 대안으로 PCP를 지원하는 것으로 알려져 있다. AVM의 Fritz!Box UPnP IGDv2 및 PCP 구현은 도입 이후 버그가 매우 많았으며, 많은 경우 제대로 작동하지 않는다.

문제점

인증

UPnP 프로토콜은 기본적으로 어떠한 인증도 구현하지 않으므로, UPnP 장치 구현은 추가적인 장치 보호(Device Protection) 서비스를 구현하거나 장치 보안 서비스(Device Security Service)를 구현해야 한다. 또한 UPnP 장치 및 애플리케이션을 위한 사용자 인증 및 권한 부여 메커니즘을 허용하는 확장을 제안하는 UPnP-UP(Universal Plug and Play - User Profile)이라는 비표준 솔루션도 존재한다. 많은 UPnP 장치 구현에는 인증 메커니즘이 부족하며 기본적으로 로컬 시스템과 그 사용자를 완전히 신뢰할 수 있다고 가정한다.

인증 메커니즘이 구현되지 않은 경우 UPnP IGD 프로토콜을 실행하는 라우터 및 방화벽은 공격에 취약하다. 예를 들어, 브라우저의 샌드박스 외부에서 실행되는 어도비 플래시 프로그램(예: 보안 문제가 확인된 특정 버전의 어도비 플래시가 필요함)은 특정 유형의 HTTP 요청을 생성할 수 있으며, 이는 UPnP 가능 라우터를 사용하는 사람이 악성 웹 사이트를 방문할 때 해당 웹 사이트가 UPnP IGD 프로토콜을 구현한 라우터를 제어할 수 있게 한다. 이는 UPnP의 "방화벽 홀 펀칭" 기능에만 해당되며, 라우터/방화벽이 UPnP IGD를 지원하지 않거나 라우터에서 비활성화된 경우에는 해당되지 않는다. 또한 사양의 상당 부분(LAN 호스트 구성을 포함하여)이 UPnP 가능 라우터에 대해 선택 사항이기 때문에 모든 라우터가 UPnP에 의해 DNS 서버 설정과 같은 것을 변경할 수 있는 것은 아니다. 그 결과, 일부 UPnP 장치는 보안 조치로서 UPnP를 기본적으로 끈 상태로 출고된다.

인터넷으로부터의 액세스

2011년 연구원 다니엘 가르시아는 인터넷으로부터의 UPnP 요청을 허용하는 일부 UPnP IGD 장치 스택의 결함을 악용하도록 설계된 도구를 개발했다. 이 도구는 DEFCON 19에서 공개되었으며 장치에서 외부 IP 주소로, 그리고 NAT 뒤의 내부 IP 주소로 포트 매핑 요청을 보낼 수 있게 한다. 이 문제는 전 세계적으로 널리 퍼져 있으며 스캔 결과 한 번에 수백만 개의 취약한 장치가 발견되기도 했다.

2013년 1월 보스턴의 보안 회사 Rapid7은 6개월간의 연구 프로그램에 대해 보고했다. 팀은 인터넷 연결 가용성을 알리는 UPnP 가능 장치의 신호를 스캔했다. 8,100만 개의 IP 주소에서 1,500개 회사의 약 6,900개 네트워크 지원 제품이 요청에 응답했다. 장치의 80%는 가정용 라우터였으며 나머지는 프린터, 웹캠 및 감시 카메라를 포함했다. UPnP 프로토콜을 사용하면 이러한 장치 중 상당수에 액세스하거나 조작할 수 있다.

2013년 2월 UPnP 포럼은 보도 자료를 통해 사용된 UPnP 스택의 최신 버전을 권장하고 이러한 문제를 방지하기 위한 체크 항목을 포함하도록 인증 프로그램을 개선함으로써 대응했다.

IGMP 스누핑 및 안정성

UPnP는 종종 디지털 홈 네트워크에서 사용되는 유일한 주요 멀티캐스트 애플리케이션이다. 따라서 멀티캐스트 네트워크 구성 오류나 기타 결함이 기저의 네트워크 문제보다는 UPnP 문제로 나타날 수 있다.

스위치나 더 일반적으로 무선 라우터/스위치에서 IGMP 스누핑이 활성화된 경우, 잘못 구성되거나 불완전하게 구성되면(예: 활성 쿼리어 또는 IGMP 프록시가 없는 경우) UPnP/DLNA 장치 검색(SSDP)을 방해하여 UPnP가 불안정하게 보일 수 있다.

관찰된 전형적인 시나리오로는 서버나 클라이언트(예: 스마트 TV)가 전원을 켠 후 나타났다가 IGMP 그룹 멤버십 만료로 인해 몇 분 후(보통 기본값 30분) 사라지는 경우가 있다.

콜백 취약점

2020년 6월 8일, 또 다른 프로토콜 설계 결함이 발표되었다. 발견자에 의해 "CallStranger"라고 명명된 이 취약점은 공격자가 이벤트 구독 메커니즘을 전복하여 DDoS 공격을 위한 요청 증폭, 열거 및 데이터 유출과 같은 다양한 공격을 실행할 수 있게 한다.

OCF는 2020년 4월에 프로토콜 사양에 대한 수정 사항을 발표했다. 하지만 UPnP를 실행하는 많은 장치는 업그레이드가 쉽지 않기 때문에 CallStranger는 앞으로도 오랫동안 위협으로 남을 가능성이 높다. CallStranger는 설계 및 구현상의 반복적인 보안 실패로 인해 최종 사용자가 UPnP를 포기해야 한다는 목소리에 힘을 실어주었다.

역사

UPnP 포럼 로고
UPnP 포럼 로고

UPnP 프로토콜은 다양한 벤더의 독립형 장치 및 개인용 컴퓨터에 간단하고 견고한 연결을 가능하게 하기 위한 컴퓨터 산업 이니셔티브인 UPnP 포럼(1999년 10월 결성)에 의해 추진되었다. 이 포럼은 가전 제품에서 네트워크 컴퓨팅에 이르는 모든 분야에 종사하는 800개 이상의 벤더로 구성되었다. 2016년부터 모든 UPnP 관련 노력은 오픈 커넥티비티 파운데이션(OCF)에 의해 관리되고 있다.

2008년 가을, UPnP 포럼은 UPnP 1.0 장치 아키텍처의 후속작인 UPnP 1.1을 승인했다. 웹 서비스용 장치 프로필(DPWS) 표준이 UPnP의 후속 후보였으나 UPnP 포럼은 UPnP 1.1을 선택했다. IGD 버전 2도 표준화되었다.

UPnP 인터넷 게이트웨이 장치(IGD) 표준에는 IETF 표준인 포트 컨트롤 프로토콜과 유사한 기능을 제공하는 WANIPConnection 서비스가 있다. NAT-PMP 사양에는 NAT-PMP 및 그 후속인 PCP의 생성을 촉발한 IGDP 관련 문제 목록이 포함되어 있다.: 26–32 

UPnP 장치 아키텍처에 대해 다음과 같은 몇 가지 추가 표준이 정의되었다:

같이 보기

각주

  1. 1 2 “Universal Plug and Play Device Architecture”. 《upnp.org》. 2025년 5월 22일에 확인함.
  2. 1 2 3 4 5 6 “OCF – UPnP Standards & Architecture” (미국 영어). 《Open Connectivity Foundation (OCF)》. 2017년 8월 30일에 원본 문서에서 보존된 문서. 2025년 5월 22일에 확인함.
  3. ↑ OCF – UPnP Logo Usage Guidelines
  4. ↑ Velimirovic, Andreja (2022년 1월 13일). “What is UPnP (Universal Plug and Play)?” (미국 영어). 《phoenixNAP Blog》. 2023년 9월 27일에 확인함.
  5. ↑ “Using the UPnP Control Point API”. 마이크로소프트 개발자 네트워크. 2012년 9월 14일. 2014년 9월 11일에 확인함.
  6. 1 2 “UPnP Device Architecture v1.0” (PDF). 《upnp.org》. UPnP Forum. 2008년 10월 15일.
  7. 1 2 “UPnP Device Architecture v1.1” (PDF). 《openconnectivity.org》. UPnP Forum. 2008년 10월 15일.
  8. ↑ “UPnP Device Architecture v2.0” (PDF). 《openconnectivity.org》. OCF. 2020년 4월 17일.
  9. 1 2 3 “UPnP InternetGatewayDevice v1.0/v2.0”. 《openconnectivity.org》. UPnP Forum. 2010년 12월 10일.
  10. ↑ “ISO/IEC standard on UPnP device architecture makes networking simple and easy”. 국제 표준화 기구. 2008년 12월 10일. 2014년 9월 11일에 확인함.
  11. ↑ “UPnP Specifications Named International Standard for Device Interoperability for IP-based Network Devices” (PDF). UPnP Forum. 2009년 2월 5일. 2014년 4월 1일에 원본 문서 (PDF)에서 보존된 문서. 2014년 9월 11일에 확인함.
  12. ↑ Goland, 야론 Y.; Schlimmer, 제프리 C. (2000년 10월 2일). “Multicast and Unicast UDP HTTP Messages”. UPnP Forum Technical Committee. 2006년 12월 30일에 원본 문서에서 보존된 문서. 2014년 9월 11일에 확인함.
  13. ↑ “How Windows Firewall affects the UPnP framework in Windows XP Service Pack 2”. 마이크로소프트. 2014년 5월 23일. 2014년 9월 11일에 확인함.
  14. 1 2 “UPnP AV Architecture” (PDF). UPnP Forum. 2013년 3월 31일. 2014년 9월 11일에 확인함.
  15. ↑ “UPnP Forum Releases Enhanced AV Specifications Taking Home Network to the Next Level” (PDF). UPnP Forum. 2006년 7월 12일. 2014년 9월 11일에 확인함.
  16. ↑ “Device Control Protocols”. UPnP Forum. 2014년 9월 11일에 확인함.
  17. ↑ “DLNA Networked Device Interoperability Guidelines”. Digital Living Network Alliance. March 2014. 2014년 9월 11일에 확인함.
  18. ↑ “Digital living network alliance (DLNA) home networked device interoperability guidelines - Part 1: Architecture and protocols”. 국제전기기술위원회. 2013년 10월 23일. 2014년 9월 11일에 확인함.
  19. ↑ “OpenCable Specifications Home Networking 2.0 - Home Networking Protocol 2.0 Revision 10” (PDF). Cable Television Laboratories. 2013년 5월 30일. 2014년 9월 11일에 원본 문서 (PDF)에서 보존된 문서. 2014년 9월 11일에 확인함.
  20. ↑ EDN (2005년 9월 9일). “How DLNA and UPnP will enable easy home video networks” (미국 영어). 《EDN》. 2023년 9월 27일에 확인함.
  21. ↑ “ANSI/CTA-2014-B - Web-based Protocol and Framework for Remote User Interface on UPnP Networks and the Internet (Web4CE)”. CEA R7 Home Home Network Committee. 2011년 1월 1일. 2013년 4월 29일에 원본 문서에서 보존된 문서. 2014년 9월 11일에 확인함.
  22. ↑ “Detect FDSSDP as a microsoft client · miniupnp/miniupnp@8381867” (영어). 《GitHub》. 2023년 9월 18일에 확인함.
  23. ↑ 12 Fehler in der AVM UPnP IGD- und PCP-Implementation (aller FritzBoxen).
  24. ↑ “UPnP not working with my FRITX!Box” (영어). 《Syncthing Community Forum》. 2022년 4월 12일. 2023년 9월 18일에 확인함.
  25. ↑ “UPNP_GetValidIGD returns Temporary IPv6 Address, causing UPNP_AddPinHole to fail with 606 · Issue #600 · miniupnp/miniupnp” (영어). 《GitHub》. 2023년 9월 18일에 확인함.
  26. ↑ “upnpc shows wrong duration for port forward longer than 120 seconds · Issue #222 · miniupnp/miniupnp” (영어). 《GitHub》. 2023년 9월 18일에 확인함.
  27. ↑ “miniupnp.tuxfamily.org :: View topic - Setting up portforward doesn't work”. 《miniupnp.tuxfamily.org》. 2023년 9월 18일에 확인함.
  28. ↑ “Device Protection V 1.0”. UPnP Forum. 2014년 10월 17일에 원본 문서에서 보존된 문서. 2014년 9월 11일에 확인함.
  29. ↑ “Device Security and Security Console V 1.0”. UPnP Forum. 2014년 8월 31일에 원본 문서에서 보존된 문서. 2014년 9월 11일에 확인함.
  30. ↑ “UPnP-UP - Universal Plug and Play - User Profile”. 2013년 12월 10일에 원본 문서에서 보존된 문서. 2012년 1월 1일에 확인함.
  31. ↑ Sales, Thiago; Sales, Leandro; Almeida, Hyggo; Perkusich, Angelo (November 2010). 《A UPnP extension for enabling user authentication and authorization in pervasive systems》. 《Journal of the Brazilian Computer Society》 16. 261–277쪽. doi:10.1007/s13173-010-0022-2.
  32. ↑ Eastep, 토마스 M. (2014년 6월 4일). “Shorewall and UPnP”. 2013년 12월 14일에 원본 문서에서 보존된 문서. 2014년 9월 11일에 확인함.
  33. ↑ “Linux UPnP Internet Gateway Device - Documentation - Security”. 2014년 9월 11일에 확인함.
  34. ↑ “Hacking The Interwebs”. 2008년 1월 12일. 2014년 9월 11일에 확인함.
  35. ↑ 가르시아, 다니엘. “UPnP Mapping” (PDF). 2014년 9월 11일에 확인함.
  36. ↑ “US-CERT Vulnerability Note VU#357851”. CERT/CC. 2012년 11월 30일. 2014년 9월 11일에 확인함.
  37. ↑ “Millions of devices vulnerable via UPnP - Update”. The H. 2013년 1월 30일. 2014년 9월 11일에 확인함.
  38. ↑ Moore, H. D. (2013년 1월 29일). “Whitepaper: Security Flaws in Universal Plug and Play: Unplug, Don't Play.”. 2013년 1월 30일에 원본 문서에서 보존된 문서. 2014년 9월 11일에 확인함.
  39. ↑ “UPnP Forum Responds to Recently Identified LibUPnP/MiniUPnP Security Flaw.” (PDF). UPnP Forum. 2013년 2월 8일. 2013년 12월 7일에 원본 문서 (PDF)에서 보존된 문서. 2014년 9월 11일에 확인함.
  40. ↑ “CERT/CC Vulnerability Note VU#339275”.
  41. ↑ “CallStranger CVE-2020-12695”. 2020년 6월 16일에 원본 문서에서 보존된 문서. 2020년 6월 14일에 확인함.
  42. ↑ “OCF – UPnP Standards & Architecture”. 2017년 8월 30일에 원본 문서에서 보존된 문서. 2026년 3월 16일에 확인함.
  43. ↑ “CVE-2020-12695: CallStranger Vulnerability in Universal Plug and Play (UPnP) Puts Billions of Devices at Risk”. 2020년 6월 8일.
  44. ↑ “Disable UPnP on Your Wireless Router Already” (미국 영어). 《Lifehacker》. 2020년 6월 12일. 2020년 6월 14일에 확인함.
  45. ↑ “OCF – UPnP Standards & Architecture” (미국 영어). 《Open Connectivity Foundation (OCF)》. 2017년 8월 30일에 원본 문서에서 보존된 문서. 2023년 9월 27일에 확인함.
  46. ↑ Bodlaender, M.P. (February 2005). 《UPnP 1.1 - designing for performance & compatibility》. 《IEEE Transactions on Consumer Electronics》 51. 69–75쪽. doi:10.1109/TCE.2005.1405701. S2CID 11792030.
  47. ↑ “UPnP Forum Gateway Working Committee: IGD:2 Improvements over IGD:1” (PDF). UPnP Forum. 2009년 3월 10일. 2014년 9월 11일에 확인함.
  48. ↑ S. Cheshire; M. Krochmal (April 2013). “RFC 6886: NAT Port Mapping Protocol (NAT-PMP)”. 국제 인터넷 표준화 기구 (IETF). doi:10.17487/RFC6886. 2014년 8월 8일에 확인함.
  49. ↑ “WFA WLANConfig Service 1.0 Service Template Version 1.01” (PDF). January 2006. 2022년 12월 8일에 원본 문서 (PDF)에서 보존된 문서.
  50. ↑ “Wi-Fi Protected Setup Specification Version 2.0.8” (PDF). 2021년 3월 22일에 원본 문서 (PDF)에서 보존된 문서.

외부 링크