How you address nodes in WebRTC is totally up to you, the implementor, because signalling is - deliberately - left out of the specification. So if you'd like to address the nodes in your overlay by their IP addresses, go ahead. But I think you slightly misunderstood how connection establishment in WebRTC works, so let me dive a bit deeper:

WebRTC connection establishment is accomplished by exchanging SDP messages (http://en.wikipedia.org/wiki/Session_Description_Protocol). If you want one browser to establish a PeerConnection to another browser, you'll have to find a way to send the SDP message (generated via RTCPeerConnection#createOffer) to the other browser. There's no way to just open a UDP connection to that browser (or ICE wouldn't work).

So for a node to join the overlay network you'll have to have a central point (let's call it server) or another channel (have a look at https://github.com/cjb/serverless-webrtc/ for "server-less" WebRTC) for connection establishment. As soon as all your nodes are connected to each other via RTCPeerConnections (e.g. as a chain) you can use those connections for further connection establishment (i.e. transfer SDP offers/answers through these connections).

Back to addressing nodes via IP address: This is not a good idea because sometimes you don't even know the address (e.g. when STUN and esp. TURN come into play).

Edit to answer question in comment:

Instead of the IP address you could use sth. like a UUID (http://en.wikipedia.org/wiki/UUID). Also, you could as well use sth. like the user's e-mail address if all your users are authenticated in some way. But keep in mind that the matter of authenticating peers is still not fully specified by IETF/W3C and implementations don't exist, yet.