[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MMUSIC] Question on Forming Candidate Pairs in ICE-17



inline.

Zingerle, Meinrad wrote:
Hi Jonathan,
probably I'm annoying you - but I need to address the topic of pairing a addresses of local scope with addresses global scope once again, this time with the focus on IPv4 addresses.
Given the following candidates
local remote
10.0.0.8 host 192.168.34.33 host
210.221.23.4 srflx 210.123.44.14 srflx
210.221.25.1 relayed
As I've understood ICE-17, we would get the following candidate pairs:
10.0.0.8-192.168.34.33
10.0.0.8-210.123.44.14
210.221.23.4-210.123.44.14
210.221.25.1-192.168.34.33 (**)
210.221.25.1-210.123.44.14
My question now is, in what case it makes sense to piar a candidate of a private IP address (192.168.34.33 in this example) with one of a public IP address (210.221.25.1)? In my understanding, the connectivity checks for such pairs will always fail ...

Ahh. Were it so easy as that ;)

Never make assumptions. That is the cardinal rule of ICE. And you've made an assumption - that a private IP and public IP are never directly reachable from each other.

Turns out this isn't always true. I am aware of real, large scale enterprise IP network deployments that use private and public IP addresses internal to the enterprise, WITHOUT nat between them, and then NAT the entire internal enterprise into a small number of external public IP. In this case, calls between two hosts within the enterprise, would end up working when a check is sent from a private IP to a 'seemingly' public IP from the peer. Its not hard to imagine how something like an acquisition or network expansion could produce a deployment like this over time.


Note that RFC3330 states: "192.168.0.0/16 - This block is set aside for use in private networks. Its intended use is documented in [RFC1918]. Addresses within this block should not appear on the public Internet." The same is stated for the block 10.0.0.0/8

Right. But public addresses can be used within private networks, and that is what is happening in this case.


-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic