Comment 1 for bug 1740739

I think the best plan of attack would be to test against source port IDs (reg6) rather than IP addresses. This raises the problem that reg6 must always be set to the correct value. This is mostly correct, except for a few apps:

* Tunneling

* dNAT

* Provider network

* SFC

For dNAT and provider network, we can infer reg6 from the incoming packet by source IP and network or source IP and MAC.

For SFC, we should have all the information available, we just need to re-set reg6 once the packet finished the SFC flow.

For tunneling, there are two options:

1. Infer all routable addresses to the network, and then infer from source IP and network. (preferred)

2. Do the routing both on the source and destination node. The packet sent through the tunnel will be the original tunnel (before routing), and routing will be done again on the destination node (routing will be done twice!)

3. Encode the reg6 value somewhere on the packet, e.g. source MAC address, and then (optionally) re-encode the correct MAC on the destination node.

Option 1 is preferred, because it is the only option allowing full interoperability (option 3 won't work if the tunnel source is an e.g. DVR compute node).

Action Items:

1-4. Update dNAT app
1-4. Update provider network app
1-4. Update SFC app
1-4. Update tunnelling app
5. Update SecGroup

This solution only works for 'ingress' rules. For 'egress' rules, we may want to move them to a point where we know the destination port (reg7) and then match by port and not by IP as well.