0

Is it possible to NAT PIM Join packet?

Assume the receiver and the source are in two different private network. Thus NAT is required. The upstream source and the groupe are included in the PIM Join packet while building the multicast tree. Is it possible to translate the network addresses included in PIM Join packet ?

I have searched and haven't found anything so far.

Thanks in advance.

Improve this question
6
  • NAT is bad for routing protocols. You should use a tunnel for multicast because you cannot multicast over the public Internet. – Ron Maupin♦ Mar 5 at 21:41
  • In general, NAT isn't applied to multicast traffic. (while theoretically possible, it defeats the purpose.) When 192.168.1.1 sends a join for 239.0.0.1, the only thing that sees that is the router. That message isn't forwarded anywhere else, nor is the sender of the mcast stream aware of the receiver(s). [which is the whole point] – Ricky Mar 5 at 21:46
  • I gather your question is about rewriting the source address of the multicast stream. (i.e. 192.168.1.1 sending out whatever to 239.0.0.1) In that case, there is no join. – Ricky Mar 5 at 21:51
  • It's not about translating multicast traffic. It's about translating the PIM Join/Prune messages while building the tree (shared or source). It won't be over IPST but rather 2 private network. – huseyin39 Mar 5 at 21:57
  • 1
    NAT translates network addresses in the header, not in the data. – Ron Maupin♦ Mar 5 at 22:18
1

You appear to have the wrong idea of how multicast works. Join/Leave are client (receiver) functions. The sender of a stream doesn't join the group.

If you have two isolated 192.168.1.0/24 private LANs, then NAT would have to be applied to the multicast traffic leaving/entering each LAN, just like any other layer-3 traffic... a src of 1.1 doesn't mean anything to the rest of the internet, and will only be confusing to the other network. A multicast packet is fundamentally the same as a unicast packet: it has a source address and destination address. If you transport a multicast stream from 192.168.1.1 to 239.0.0.1 into the other network, the source is now nonsense; the 1.1 in the local network is not the sender. Any client attempting to send a message to the apparent sender will be talking to the wrong node:

(A) (server) 192.168.1.1>239.0.0.1 <-> intermediate net(s) <-> (B) (client) 192.168.1.1>239.0.0.1 [assuming the private addresses can even cross the intermediate network(s)]

NAT MUST be applied at the boundaries of the private networks. Lets say each side sees the other as 192.168.2.0/24... ("I'm one, you're two" is true in both networks.)

(A) (server) 192.168.1.1>239.0.0.1 <-> intermediate net(s) <-> (B) (client) 192.168.2.1>239.0.0.1

The "B" side router will see a join for 239.0.0.1 from the local 1.x host(s); it doesn't necessarily care who is joining the group, just that there's a group it needs to request from upstream. If SSM is being used, then the stream source address matters, again, meaning NAT must happen.

[Note: interconnecting overlapping networks is a pain that everyone tries to avoid. Attempting to mix multicast into that mess is suicide.]

Improve this answer
4
  • I agree that multicast data can be translated as it consists in transleting IP address: 239.0.0.1 <--> 239.0.0.6 let's say. However first, you need to build the multicast tree first. My question lies in build the tree among 2 (or more) private network. The client (located in network A) sends a PIM Join message to the source or the RP (located in the network B). Inside the PIM Join message payload (not at layer 3), there's the address of the source/rp and the group address. Those 2 addresses must be translated too as they are private. But it's not only layer 3 NAT, it's kinda "PIM-NAT". – huseyin39 Mar 5 at 23:06
  • You really need to learn a lot more about multicast. JOINs are not sent to the source or RP; they're sent to the router for that network segment. (interface specific, in fact.) Only SSM will have a src in the membership data, and that source must be correct from the perspective of that network segment. (real src 1.1, seen as 2.1 at the client. PIM would associate (S,G) for whatever "S" the traffic is at that point -- 1.1 on e0, 2.1 on e1) The router (DR) sends MBR reports toward the RP, not directly to it, because everything along the path needs to know what to pass through. – Ricky Mar 6 at 7:28
  • See Also: RFC5135, juniper.net/documentation/en_US/junos/topics/topic-map/… , cisco.com/c/en/us/support/docs/ip/… , (any number of wiki pages) – Ricky Mar 6 at 7:41
  • Sorry, I meant toward the RP/source, all along the path until it reaches a router belonging to the tree or the source/RP. In this context the downstrem router is in one private network and the upstream router is in another network. How would the two PIM routers communicate since they are in two different networks hence addresses require to be translated? When a DR receives an IGMP/PIM packet then it sends a PIM Join toward the source not an "MBR reports: tools.ietf.org/html/rfc7761#page-8 – huseyin39 Mar 6 at 15:15
0

Assume the receiver and the source are in two different private network. Thus NAT is required.

No, it's not. NAT is only required between two address regimes, usually between private and public addressing.

There's no public multicast routing, so there's little sense in trying to use NAT with PIM.

NAT is an ugly hack and you only use it if you must.

Improve this answer
3
  • Assume YouTube and Facebook are the 2 stakeholders which have their own private network. NAT is required in this case. If for some reason YouTube broadcasts multicast traffic to several receivers (including its own servers) and Facebook would like to receive it as well. I agree it's a very rare and weird situation. Technically it would be possible, yet I haven't found any constructor/proxy proposing it. – huseyin39 Mar 5 at 22:19
  • 3
    In that unlikely scenario (you know YouTube belongs to Google, don't you?), those parties wouldn't use multicast to stream data between them. They'd use unicast and then perhaps redistribute within their network using multicast. Alternatively, they could agree to run multicast addresses across their peering links, so they wouldn't have any need for NAT there either. – Zac67 Mar 5 at 22:25
  • I agree they would probably use unicast. Your last sentence is a wise solution. – huseyin39 Mar 5 at 22:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.