0

Is it possible to NAT PIM Join packet?

Assume the receiver and the source are in two different networks (address regimes). 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.

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, 2021 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, 2021 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, 2021 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, 2021 at 21:57
  • 1
    NAT translates network addresses in the header, not in the data.
    – Ron Maupin
    Mar 5, 2021 at 22:18

3 Answers 3

2

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

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

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, 2021 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, 2021 at 22:25
  • I agree they would probably use unicast. Your last sentence is a wise solution.
    – huseyin39
    Mar 5, 2021 at 22:52
0

After a long research, there isn't manufacturers which propose a solution to translate PIM packets for 2 address plans/regimes.

enter image description here

In the packet above, one can see that the PIM packet contains upstream-neighbor, group and source adresses: 10.4.1.2, 239.1.1.9 and 104.255.224.1.

Traditional 'Network Address Translator' translates only the Src and Dst fields of IP packets. If those three adresses are in another address plan/regime, then there isn't any solution/device that handles 'PIM translation'.

Hence, constructing a multicast tree between 2 IP adressing plans (e.g two public networks) is not possible with COTS solutions.

2
  • "A traditional firewall translates only the Src and Dst fields of IP packets." Firewalls really do not NAT. A firewall is often a convenient place to run a NAT process, but NAT really has nothing to do with the firewall process. You can run a firewall without running a NAT process on it, and that is the default for enterprise-grade firewall (what is on-topic here).
    – Ron Maupin
    Feb 8 at 15:27
  • I totally agree with you, it's not its main purpose, tough NATing is often included as a feature in firewalls. I will edit the answer accordingly, it concerns any tool processing address translation (could be a firewall or a router or anything else).
    – huseyin39
    Feb 9 at 16:06

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.