Draft: draft-ietf-rtcweb-ip-handling

Commentary: S 3 . That said , I could get behind switching ' will ' to ' can ' , as is used in S3 , category . S 6.2 . This seems like a good addition .
If the client is multihomed, additional public IP addresses for
the client can be learned.  In particular, if the client tries to
hide its physical location through a Virtual Private Network
(VPN), and the VPN and local OS support routing over multiple
interfaces (a "split-tunnel" VPN), WebRTC will discover not only
the public address for the VPN, but also the ISP public address
over which the VPN is running.
If the client is multihomed, additional public IP addresses for
the client can be learned.  In particular, if the client tries to
hide its physical location through a Virtual Private Network
(VPN), and the VPN and local OS support routing over multiple
interfaces (a "split-tunnel" VPN), WebRTC can discover not only
the public address for the VPN, but also the ISP public address
over which the VPN is running.
Default route + associated local addresses: WebRTC MUST follow the
kernel routing table rules, which will typically cause media
packets to take the same route as the application's HTTP traffic.
If an enterprise TURN server is present, the preferred route MUST
be through this TURN server.  Once an interface has been chosen,
the private IPv4 and IPv6 addresses associated with this interface
MUST be discovered and provided to the application.  This ensures
that direct connections can still be established in this mode.
Default route + associated local addresses: WebRTC MUST follow the
kernel routing table rules, which will typically cause media
packets to take the same route as the application's HTTP traffic.
If an enterprise TURN server is present, the preferred route MUST
be through this TURN server.  Once an interface has been chosen,
the private IPv4 and IPv6 addresses associated with this interface
MUST be discovered and provided to the application as host
candidates.  This ensures that direct connections can still be
established in this mode.
When trying to follow typical IP routing, the simplest approach is to
bind() the sockets used for peer-to-peer connections to the wildcard
addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to
route WebRTC traffic the same way as it would HTTP traffic.  STUN and
TURN will work as usual, and host candidates can still be determined
as mentioned below.
When binding to a wildcard address, some extra work is needed to
determine a suitable host candidate, which we define as the source
address that would be used for any packets sent to the web
application host (assuming that UDP and TCP get the same routing).
Use of the web application host as a destination ensures the right
source address is selected, regardless of where the application
resides (e.g., on an intranet).
When trying to follow typical IP routing, as required by Modes 2 and
3, the simplest approach is to bind() the sockets used for peer-to-
peer connections to the wildcard addresses (0.0.0.0 for IPv4, :: for
IPv6), which allows the OS to route WebRTC traffic the same way as it
would HTTP traffic.  STUN and TURN will work as usual, and host
candidates can still be determined as mentioned below.
When binding to a wildcard address, some extra work is needed to
determine the associated local address required by Mode 2, which we
define as the source address that would be used for any packets sent
to the web application host (assuming that UDP and TCP get the same
routing).  Use of the web application host as a destination ensures
the right source address is selected, regardless of where the
application resides (e.g., on an intranet).
Finally, the socket can be queried using getsockname() or the
equivalent to determine the appropriate host candidate.
Finally, the socket can be queried using getsockname() or the
equivalent to determine the appropriate local address.