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

From: "Zingerle, Meinrad" <[email-masked]>
Date: Mon, 13 Aug 2007 09:57:37 +0200

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 ... 

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
 
Regards,
   Meinrad
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2007 17:55:24 -0400

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 

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.

> 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
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com