RE: [bacnet-ip-wg] NAT after Germantown
NAT after Germantown
" Register-Foreign-Device-NAT BVLLl. This not only provides a guaranteed B/IP that the FD can be accessed with, it also provides a mechanism whereby the BBMD knows whether or not the FD supports NAT-Unicast."
I tried this when I was experimenting with work-arounds to the various NAT problems, and I found out the hard way that other devices besides the BBMD wind up talking to FDs (ie: other BBMDs that are peers of the BBMD with which the device is registered). Those BBMDs do not "know" how the FD registered, so the other BBMDs wind up sending the NAT-Unicast message.
This is the main reason for suggesting the TCP/IP solution – it would get around that problem by mandating that all traffic go through the correct BBMD. It may be possible to avoid this issue by limiting the routing scenarios.
Also, according to Stuart, the concept was not specifically a "NAT-Unicast BVLL" per se, but rather to have a BVLL wrapper with a source B/IP address in it, and which contains another BVLL inside it. It was my understanding that there was some agreement on this, because all BVLLs are subject to the same set of problems, including "Read BDT", "Read FDT", etc... Having a general wrapper message would allow a requestor to embed the return information in any existing message.
From: email@example.com [mailto: firstname.lastname@example.org ] On Behalf Of Roland Laird
Sent: Friday, May 26, 2006 8:01 AM
Subject: [bacnet-ip-wg] NAT after Germantown
Stuart and B/IPers,
These are hard questions. I don't like the situation of having multiple methods to configure the BDT. My current bias is to take the easy way out and leave it as a "local matter".
In adding the NAT-Unicast to BBMD Devices, FDs will have to support it as well. It also makes sense to provide a new Register-Foreign-Device-NAT BVLLl. This not only provides a guaranteed B/IP that the FD can be accessed with, it also provides a mechanism whereby the BBMD knows whether or not the FD supports NAT-Unicast.
I don't support the idea of making a Register-Foreign-Device over TCP (though it would keep the session open) because B/IP is totally based on UDP, and making this exception would involve a whole new set of compilcations.
In order to add in the concept of a NAT-Unicast BVLL I think the following needs to be done to RL-002:
1. Define Original-NAT-Unicast-NPDU BVLL in J.2
2. Define Register-NAT-Foreign-Device BVLL in J.2
3. Add to J.3 "BACnet/IP Directed Messages", an explanation of of when to use the NAT-Unicast.
a) When Nat enabled
- on unicast messages from a BBMD Device/Router to B/IP addresses that are flagged in the BDT as supporting Unicast-NAT
- on unicast messages to FD's registered with Register-NAT
b) By FDs when they have been able to successfully register with Register-NAT…
4. Add to J.5.2 "Foreign Device Table" the explanation of the new Register-NAT-FD BVLL
- specify that FD's fall back to the regular Register-FD if a success Result is not returned.
5. Annex A Conformance option added.
Have I got something wrong or am I missing something?
I don't think the group reach a consensus that these changes are nessesary, but I will add them so we can see what it looks like.
So in going through my notes from Germantown , the direction on the NAT was to incorporate a BVLL into the RL-002 proposal because there were situations from a standards compatibility basis with NAT that would not work. However the group wanted to do this without breaking existing solutions.
Would this look like a per-entry flag to indicate whether messages to that BBMD should use the new BVLL with routing info?
i) If so, should we worry about not being able to set this with the existing messages to write a BDT?
ii) Should we leave it up to a future Network Port object to handle configuration?
iii) Should it be done through a global configuration that says the devices listed in the public BDT optionally use the new BVLL?
Also, this still leaves the issue of foreign device registration, and how it should work through NAT. I recall some support for a new register foreign device command that would cause the routing to be handled correctly through the router as well.
Another idea came up here, would it make sense to try and handle NAT foreign device registration through a new Register Foreign Device service over a TCP connection rather than UDP?
Software Engineering Lead
Honeywell / Alerton
6670 185th Ave NE
Redmond, WA 98052
Office: +1 425 869 8400