You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactoring the base support for IPv4 into also supporting IPv6 is a bit of work. Fortunately there is experience to be gained from other code bases such as the SMCRoute, mcjoin, and mping projects.
IPv6 has been supported since UPnP v1.1, and as of v2.0 is accepted as a primary address family (not just secondary to IPv4 as in v1.1).
The wording in v2.0 around IPv6 is a lot better and is worth citing here:
2012 IPv6 Support Update: This revision to the UPnP Device Architecture Annex A is motivated by operational experience gained since the previous update. There are four high level goals addressed with these latest changes:
IPv6 support needs to be required in order for new and existing devices to interoperate with each other
GUA and ULA should be treated with equal weight, with address selection performed according to IETF guidance
IPv6 needs to be preferred over IPv4 whenever it is available, per IETF guidance
The IPv6 updates need to be applicable to UDA 1.0, UDA 1.1 and UDA 2.0 implementations
UPnP devices and control points need to be encouraged to support IPv6. The IPv4 public address space is effectively exhausted, and the move towards IPv6 is considered inevitable. Service providers and on-line content providers are all adding support of IPv6. Consumer electronics devices that are capable of accessing on-line services and content will also need to move to IPv6. In fact, the IETF has signaled its opinion on the deployment of IPv6 in RFC 6540, titled “IPv6 Support Required for all IP-capable Nodes.” Also, as IPv6 standards and support progress, there may be additional benefit to having UPnP supported over IPv6. There are potential advantages to the Remote Access architecture, as well as possible future benefits for traversal of multiple routers inside a home network. IPv6 support is being encouraged by CEA through the efforts of a new CEA Working Group focused on IPv6 and the transition from IPv4. UPnP needs to stay relevant in the evolving IP world, which demands that IPv6 interoperability be enabled. Legacy UDA 1.0 certified devices are allowed to remain non-IPv6 compliant, however it is highly recommended that all UPnP devices and control points support IPv6 and dual-stack operation.
The text was updated successfully, but these errors were encountered:
Refactoring the base support for IPv4 into also supporting IPv6 is a bit of work. Fortunately there is experience to be gained from other code bases such as the SMCRoute, mcjoin, and mping projects.
IPv6 has been supported since UPnP v1.1, and as of v2.0 is accepted as a primary address family (not just secondary to IPv4 as in v1.1).
The wording in v2.0 around IPv6 is a lot better and is worth citing here:
The text was updated successfully, but these errors were encountered: