Loading ...
Sorry, an error occurred while loading the content.

NAT/PAT

Expand Messages
  • rolandlus
    Dear IP-WG: I spent a couple of hours on this sunny Saturday looking into the complications caused to B/IP by dynamic NAT and PAT. Here are the conclusions I
    Message 1 of 13 , Mar 11, 2006
    • 0 Attachment
      Dear IP-WG:

      I spent a couple of hours on this sunny Saturday looking into the
      complications caused to B/IP by dynamic NAT and PAT. Here are the
      conclusions I came to:

      1. To prevent erroneous router-to-network address bindings caused
      by randomly assigned source IP or port numbers, do not update
      routing tables on any directed communication from a network. Use
      exclusively the Who-Is-Router-To-Network and the I-Am-Router-To-
      Network network layer services or the I-Am service. These are always
      broadcast so will be sent with F-NPDU's.

      2. There will have to be one fixed global B/IP address for each
      subnet that is port-forwarded to the BBMD/Router on each subnet.
      This fixed B/IP address is entered in the BDT and conveyed in F-
      NPDUs.

      3. It does not matter that directed communications may have
      differently assigned IP's and Ports as long as the NAT Router keeps
      the temporary reply forwarding open long enough for the reply to
      come through (which I believe it does).

      On Foreign Devices behind a NAT Router:
      Either:
      1. Resister often to keep temporary path open.
      or
      2. Need new Register-Foreign-Device-NAT that specifies Global-IP
      like in F-NPDU. This would also require each FD behind the NAT to
      have a separtate port-forwarding.


      Roland Laird
    • Christopher.J.McCann@jci.com
      Roland, We had advised this solution as a way to fix the problem with NATs; however, many IT departments are having a problem with assigning one global address
      Message 2 of 13 , Mar 13, 2006
      • 0 Attachment

        Roland,

        We had advised this solution as a way to fix the problem with NATs; however, many IT departments are having a problem with assigning
        one global address for BACNet communications.  I am also concerned that you are relying on WHO-IS-ROUTER-TO-NETWORK and
        I-AM-ROUTER-TO-NETWORK as the solution to the problem. This would only cover the case of the static IP router.  It would not cover
        other routers that may have different MSTP networks.  These would get through the BBMD, but the IP address would be wrong when you
        update your routing table  for that particular network anyway.  I'm not sure, but I think we are going to have to think of another solution where
        we try not to use BACNet/IP functionality, but instead use SSL or HTTP as the way to get through the NAT.  The other solution is start
        pushing hard to change over to IPV6.

        Chris McCann
        Johnson Controls, Inc.



        rlaird@...
        Sent by: bacnet-ip-wg@yahoogroups.com

        03/11/2006 04:55 PM

        Please respond to
        bacnet-ip-wg@yahoogroups.com

        To
        bacnet-ip-wg@yahoogroups.com
        cc
        Subject
        [bacnet-ip-wg] NAT/PAT





        Dear IP-WG:

        I spent a couple of hours on this sunny Saturday looking into the
        complications caused to B/IP by dynamic NAT and PAT. Here are the
        conclusions I came to:

        1.  To prevent erroneous router-to-network address bindings caused
        by randomly assigned source IP or port numbers, do not update
        routing tables on any directed communication from a network. Use
        exclusively the Who-Is-Router-To-Network and the I-Am-Router-To-
        Network network layer services or the I-Am service. These are always
        broadcast so will be sent with F-NPDU's.

        2. There will have to be one fixed global B/IP address for each
        subnet that is port-forwarded to the BBMD/Router on each subnet.
        This fixed B/IP address is entered in the BDT and conveyed in F-
        NPDUs.

        3. It does not matter that directed communications may have
        differently assigned IP's and Ports as long as the NAT Router keeps
        the temporary reply forwarding open long enough for the reply to
        come through (which I believe it does).

        On Foreign Devices behind a NAT Router:
        Either:
        1. Resister often to keep temporary path open.
        or
        2. Need new Register-Foreign-Device-NAT that specifies Global-IP
        like in F-NPDU. This would also require each FD behind the NAT to
        have a separtate port-forwarding.


        Roland Laird







        YAHOO! GROUPS LINKS




      • Buddy Lott
        All, I am still have trouble seeing how this proposed changes are going to solve the problems with BBMDs, FDs, IP Fowarding, NAT, PAT, and DHCP. In order to
        Message 3 of 13 , Mar 13, 2006
        • 0 Attachment

          All,

           

          I am still have trouble seeing how this proposed changes are going to “solve” the problems with BBMDs, FDs, IP Fowarding, NAT, PAT, and DHCP.

           

          In order to propose a solution, we have to understand:

          1)      NAT, PAT, and DHCP are designed for a dynamic environment where IP address are largely irrelevant to the users.

          2)       IP forwarding is design for one rather specific case where an IP address is relevant.

          3)      BBMDs & FDs are designed for an environment where  IP Addresses are very relevant.

           

          The number of scenarios where NAT & PAT get involved in BOTH ends of the communications is large and VERY common. Almost ALL access to the internet these days, is via a NAT & PAT. ISPs & Campuses buy a small set of  “public” IP address (usually one or two) for use by a lot of PCs.

           

           On this very list, we have seen reports of 1 IP router performing NAT/PAT that operations WITHOUT human intervention. If BACnet is becoming as prolific as we hope, then other routers will not be far behind. I have even heard of some current routers with the capability of being “extended” to support BACnet. Do we really need to spend the time & energy changing the standard when the problematic IT equipment is already changing to support our current standard?

           

          If so,  for BACnet IP to be successful in today’s Internet we have to come up with changes that:

          1)      support DHCP (the preferred mechanism for assign IP addresses)

          2)      minimizes manual configuration allowing IT departments to do their job without affecting the HVAC equipment (at least for most changes) and vice versa.

          3)      minimizes the scope of a manual change when we can’t avoid it.

          4)      supports NAT,PAT, & IP Forwarding.

          5)      supports VPN (for secure communications over a public network).

          6)      flexible enough to handle new technology such as IPv6.

          7)      maintain enough backwards compatibility to allow access while minimizing addition cost.

           

          In previous emails I have mention some ideas that would support many of these goals.

           

           

           

          *******************************************************************

           

          Buddy Lott
          Firmware Design Engineer
          19476 Industrial Dr .
          New Paris , IN 46553
          574.831.5250 x 197
          blott@...

           

          *******************************************************************


          From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of rolandlus
          Sent: Saturday, March 11, 2006 5:56 PM
          To: bacnet-ip-wg@yahoogroups.com
          Subject: [bacnet-ip-wg] NAT/PAT

           

          Dear IP-WG:

          I spent a couple of hours on this sunny Saturday looking into the
          complications caused to B/IP by dynamic NAT and PAT. Here are the
          conclusions I came to:

          1.  To prevent erroneous router-to-network address bindings caused
          by randomly assigned source IP or port numbers, do not update
          routing tables on any directed communication from a network. Use
          exclusively the Who-Is-Router-To-Network and the I-Am-Router-To-
          Network network layer services or the I-Am service. These are always
          broadcast so will be sent with F-NPDU's.

          2. There will have to be one fixed global B/IP address for each
          subnet that is port-forwarded to the BBMD/Router on each subnet.
          This fixed B/IP address is entered in the BDT and conveyed in F-
          NPDUs.

          3. It does not matter that directed communications may have
          differently assigned IP's and Ports as long as the NAT Router keeps
          the temporary reply forwarding open long enough for the reply to
          come through (which I believe it does).

          On Foreign Devices behind a NAT Router:
          Either:
          1. Resister often to keep temporary path open.
          or
          2. Need new Register-Foreign-Device-NAT that specifies Global-IP
          like in F-NPDU. This would also require each FD behind the NAT to
          have a separtate port-forwarding.


          Roland Laird






        • Donaldson, Stuart (WA26)
          The proposal that has been discussed in the working group meetings, and which Roland is coordinating and authoring is really aimed at a minimal set of changes
          Message 4 of 13 , Mar 13, 2006
          • 0 Attachment

            The proposal that has been discussed in the working group meetings, and which Roland is coordinating and authoring is really aimed at a minimal set of changes that can support accessing a BACnet/IP network behind a NAT enabled router/firewall.

             

            It still requires an address/port on the public side of the NAT router be configured to forward to the BBMD/Router on the internal network.  This may be a small hurdle to overcome with some IT groups, I see most would prefer this because the security conscious IT groups really want to know exactly what traffic is going across the nework.

             

            This approach, once the details are worked out, will be a great step forward.  However, the working group in the face to face meetings acknowledged that more work will need to be done to address DHCP.  The approach in RL-002 is really aimed at fixing the immediate problem to my recollection.

             

            -Stuart-

             


            From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Buddy Lott
            Sent: Monday, March 13, 2006 6:14 AM
            To: bacnet-ip-wg@yahoogroups.com
            Subject: RE: [bacnet-ip-wg] NAT/PAT

             

            All,

             

            I am still have trouble seeing how this proposed changes are going to “solve” the problems with BBMDs, FDs, IP Fowarding, NAT, PAT, and DHCP.

             

            In order to propose a solution, we have to understand:

            1)  NAT, PAT, and DHCP are designed for a dynamic environment where IP address are largely irrelevant to the users.

            2)   IP forwarding is design for one rather specific case where an IP address is relevant.

            3)  BBMDs & FDs are designed for an environment where  IP Addresses are very relevant.

             

            The number of scenarios where NAT & PAT get involved in BOTH ends of the communications is large and VERY common. Almost ALL access to the internet these days, is via a NAT & PAT. ISPs & Campuses buy a small set of  “public” IP address (usually one or two) for use by a lot of PCs.

             

             On this very list, we have seen reports of 1 IP router performing NAT/PAT that operations WITHOUT human intervention. If BACnet is becoming as prolific as we hope, then other routers will not be far behind. I have even heard of some current routers with the capability of being “extended” to support BACnet. Do we really need to spend the time & energy changing the standard when the problematic IT equipment is already changing to support our current standard?

             

            If so,  for BACnet IP to be successful in today’s Internet we have to come up with changes that:

            1)  support DHCP (the preferred mechanism for assign IP addresses)

            2)  minimizes manual configuration allowing IT departments to do their job without affecting the HVAC equipment (at least for most changes) and vice versa.

            3)  minimizes the scope of a manual change when we can’t avoid it.

            4)  supports NAT,PAT, & IP Forwarding.

            5)  supports VPN (for secure communications over a public network).

            6)  flexible enough to handle new technology such as IPv6.

            7)  maintain enough backwards compatibility to allow access while minimizing addition cost.

             

            In previous emails I have mention some ideas that would support many of these goals.

             

             

             

            *******************************************************************

             

            Buddy Lott
            Firmware Design Engineer
            19476 Industrial Dr .
            New Paris , IN 46553
            574.831.5250 x 197
            blott@...

             

            *******************************************************************


            From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of rolandlus
            Sent: Saturday, March 11, 2006 5:56 PM
            To: bacnet-ip-wg@yahoogroups.com
            Subject: [bacnet-ip-wg] NAT/PAT

             

            Dear IP-WG:

            I spent a couple of hours on this sunny Saturday looking into the
            complications caused to B/IP by dynamic NAT and PAT. Here are the
            conclusions I came to:

            1.  To prevent erroneous router-to-network address bindings caused
            by randomly assigned source IP or port numbers, do not update
            routing tables on any directed communication from a network. Use
            exclusively the Who-Is-Router-To-Network and the I-Am-Router-To-
            Network network layer services or the I-Am service. These are always
            broadcast so will be sent with F-NPDU's.

            2. There will have to be one fixed global B/IP address for each
            subnet that is port-forwarded to the BBMD/Router on each subnet.
            This fixed B/IP address is entered in the BDT and conveyed in F-
            NPDUs.

            3. It does not matter that directed communications may have
            differently assigned IP's and Ports as long as the NAT Router keeps
            the temporary reply forwarding open long enough for the reply to
            come through (which I believe it does).

            On Foreign Devices behind a NAT Router:
            Either:
            1. Resister often to keep temporary path open.
            or
            2. Need new Register-Foreign-Device-NAT that specifies Global-IP
            like in F-NPDU. This would also require each FD behind the NAT to
            have a separtate port-forwarding.


            Roland Laird





             

          • Buddy Lott
            I think the immediate problem is easily fixed when the BBMD is embedded in a BACNet router capable of handling multiple BACnet IP networks. This requires no
            Message 5 of 13 , Mar 13, 2006
            • 0 Attachment

               

              I think the immediate problem is easily fixed when the BBMD is embedded in a BACNet router capable of handling multiple BACnet IP networks. This requires no changes to the standard, just some well written documentation. This solution will not fix all problems, but I think it would fix most.

               

              It also has the advantage of not invalidating those IP routers that already “fix” the problem.

               

              IMHO: The solutions I have seen so far, seem to create a fragile network that requires too much manual configuration.

               

               

               

              *******************************************************************

               

              Buddy Lott
              Firmware Design Engineer
              19476 Industrial Dr .
              New Paris , IN 46553
              574.831.5250 x 197
              blott@...

               

              *******************************************************************


              From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Donaldson, Stuart (WA26)
              Sent: Monday, March 13, 2006 12:26 PM
              To: bacnet-ip-wg@yahoogroups.com
              Subject: RE: [bacnet-ip-wg] NAT/PAT

               

              The proposal that has been discussed in the working group meetings, and which Roland is coordinating and authoring is really aimed at a minimal set of changes that can support accessing a BACnet/IP network behind a NAT enabled router/firewall.

               

              It still requires an address/port on the public side of the NAT router be configured to forward to the BBMD/Router on the internal network.  This may be a small hurdle to overcome with some IT groups, I see most would prefer this because the security conscious IT groups really want to know exactly what traffic is going across the nework.

               

              This approach, once the details are worked out, will be a great step forward.  However, the working group in the face to face meetings acknowledged that more work will need to be done to address DHCP.  The approach in RL-002 is really aimed at fixing the immediate problem to my recollection.

               

              -Stuart-

               


              From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott
              Sent: Monday, March 13, 2006 6:14 AM
              To: bacnet-ip-wg@yahoogroups.com
              Subject: RE: [bacnet-ip-wg] NAT/PAT

               

              All,

               

              I am still have trouble seeing how this proposed changes are going to “solve” the problems with BBMDs, FDs, IP Fowarding, NAT, PAT, and DHCP.

               

              In order to propose a solution, we have to understand:

              1)  NAT, PAT, and DHCP are designed for a dynamic environment where IP address are largely irrelevant to the users.

              2)   IP forwarding is design for one rather specific case where an IP address is relevant.

              3)  BBMDs & FDs are designed for an environment where  IP Addresses are very relevant.

               

              The number of scenarios where NAT & PAT get involved in BOTH ends of the communications is large and VERY common. Almost ALL access to the internet these days, is via a NAT & PAT. ISPs & Campuses buy a small set of  “public” IP address (usually one or two) for use by a lot of PCs.

               

               On this very list, we have seen reports of 1 IP router performing NAT/PAT that operations WITHOUT human intervention. If BACnet is becoming as prolific as we hope, then other routers will not be far behind. I have even heard of some current routers with the capability of being “extended” to support BACnet. Do we really need to spend the time & energy changing the standard when the problematic IT equipment is already changing to support our current standard?

               

              If so,  for BACnet IP to be successful in today’s Internet we have to come up with changes that:

              1)  support DHCP (the preferred mechanism for assign IP addresses)

              2)  minimizes manual configuration allowing IT departments to do their job without affecting the HVAC equipment (at least for most changes) and vice versa.

              3)  minimizes the scope of a manual change when we can’t avoid it.

              4)  supports NAT,PAT, & IP Forwarding.

              5)  supports VPN (for secure communications over a public network).

              6)  flexible enough to handle new technology such as IPv6.

              7)  maintain enough backwards compatibility to allow access while minimizing addition cost.

               

              In previous emails I have mention some ideas that would support many of these goals.

               

               

               

              *******************************************************************

               

              Buddy Lott
              Firmware Design Engineer
              19476 Industrial Dr .
              New Paris , IN 46553
              574.831.5250 x 197
              blott@...

               

              *******************************************************************


              From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of rolandlus
              Sent: Saturday, March 11, 2006 5:56 PM
              To: bacnet-ip-wg@yahoogroups.com
              Subject: [bacnet-ip-wg] NAT/PAT

               

              Dear IP-WG:

              I spent a couple of hours on this sunny Saturday looking into the
              complications caused to B/IP by dynamic NAT and PAT. Here are the
              conclusions I came to:

              1.  To prevent erroneous router-to-network address bindings caused
              by randomly assigned source IP or port numbers, do not update
              routing tables on any directed communication from a network. Use
              exclusively the Who-Is-Router-To-Network and the I-Am-Router-To-
              Network network layer services or the I-Am service. These are always
              broadcast so will be sent with F-NPDU's.

              2. There will have to be one fixed global B/IP address for each
              subnet that is port-forwarded to the BBMD/Router on each subnet.
              This fixed B/IP address is entered in the BDT and conveyed in F-
              NPDUs.

              3. It does not matter that directed communications may have
              differently assigned IP's and Ports as long as the NAT Router keeps
              the temporary reply forwarding open long enough for the reply to
              come through (which I believe it does).

              On Foreign Devices behind a NAT Router:
              Either:
              1. Resister often to keep temporary path open.
              or
              2. Need new Register-Foreign-Device-NAT that specifies Global-IP
              like in F-NPDU. This would also require each FD behind the NAT to
              have a separtate port-forwarding.


              Roland Laird




               

            • Roland Laird
              The embedded BACnet Router in the BBMD is required in RL-002 for NAT with more than one device. I will try to take some time this week to add diagrams and
              Message 6 of 13 , Mar 13, 2006
              • 0 Attachment

                 

                The embedded BACnet Router in the BBMD is required in RL-002 for NAT with more than one device. I will try to take some time this week to add diagrams and improve the text in RL-002.

                Roland

                 


                From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Buddy Lott
                Sent: Monday, March 13, 2006 9:59 AM
                To: bacnet-ip-wg@yahoogroups.com
                Subject: RE: [bacnet-ip-wg] NAT/PAT

                 

                 

                I think the immediate problem is easily fixed when the BBMD is embedded in a BACNet router capable of handling multiple BACnet IP networks. This requires no changes to the standard, just some well written documentation. This solution will not fix all problems, but I think it would fix most.

                 

                It also has the advantage of not invalidating those IP routers that already “fix” the problem.

                 

                IMHO: The solutions I have seen so far, seem to create a fragile network that requires too much manual configuration.

                 

                 

                 

                *******************************************************************

                 

                Buddy Lott
                Firmware Design Engineer
                19476 Industrial Dr .
                New Paris , IN 46553
                574.831.5250 x 197
                blott@...

                 

                *******************************************************************


                From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Donaldson, Stuart (WA26)
                Sent: Monday, March 13, 2006 12:26 PM
                To: bacnet-ip-wg@yahoogroups.com
                Subject: RE: [bacnet-ip-wg] NAT/PAT

                 

                The proposal that has been discussed in the working group meetings, and which Roland is coordinating and authoring is really aimed at a minimal set of changes that can support accessing a BACnet/IP network behind a NAT enabled router/firewall.

                 

                It still requires an address/port on the public side of the NAT router be configured to forward to the BBMD/Router on the internal network.  This may be a small hurdle to overcome with some IT groups, I see most would prefer this because the security conscious IT groups really want to know exactly what traffic is going across the nework.

                 

                This approach, once the details are worked out, will be a great step forward.  However, the working group in the face to face meetings acknowledged that more work will need to be done to address DHCP.  The approach in RL-002 is really aimed at fixing the immediate problem to my recollection.

                 

                -Stuart-

                 


                From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott
                Sent: Monday, March 13, 2006 6:14 AM
                To: bacnet-ip-wg@yahoogroups.com
                Subject: RE: [bacnet-ip-wg] NAT/PAT

                 

                All,

                 

                I am still have trouble seeing how this proposed changes are going to “solve” the problems with BBMDs, FDs, IP Fowarding, NAT, PAT, and DHCP.

                 

                In order to propose a solution, we have to understand:

                1)  NAT, PAT, and DHCP are designed for a dynamic environment where IP address are largely irrelevant to the users.

                2)   IP forwarding is design for one rather specific case where an IP address is relevant.

                3)  BBMDs & FDs are designed for an environment where  IP Addresses are very relevant.

                 

                The number of scenarios where NAT & PAT get involved in BOTH ends of the communications is large and VERY common. Almost ALL access to the internet these days, is via a NAT & PAT. ISPs & Campuses buy a small set of  “public” IP address (usually one or two) for use by a lot of PCs.

                 

                 On this very list, we have seen reports of 1 IP router performing NAT/PAT that operations WITHOUT human intervention. If BACnet is becoming as prolific as we hope, then other routers will not be far behind. I have even heard of some current routers with the capability of being “extended” to support BACnet. Do we really need to spend the time & energy changing the standard when the problematic IT equipment is already changing to support our current standard?

                 

                If so,  for BACnet IP to be successful in today’s Internet we have to come up with changes that:

                1)  support DHCP (the preferred mechanism for assign IP addresses)

                2)  minimizes manual configuration allowing IT departments to do their job without affecting the HVAC equipment (at least for most changes) and vice versa.

                3)  minimizes the scope of a manual change when we can’t avoid it.

                4)  supports NAT,PAT, & IP Forwarding.

                5)  supports VPN (for secure communications over a public network).

                6)  flexible enough to handle new technology such as IPv6.

                7)  maintain enough backwards compatibility to allow access while minimizing addition cost.

                 

                In previous emails I have mention some ideas that would support many of these goals.

                 

                 

                 

                *******************************************************************

                 

                Buddy Lott
                Firmware Design Engineer
                19476 Industrial Dr .
                New Paris , IN 46553
                574.831.5250 x 197
                blott@...

                 

                *******************************************************************


                From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of rolandlus
                Sent: Saturday, March 11, 2006 5:56 PM
                To: bacnet-ip-wg@yahoogroups.com
                Subject: [bacnet-ip-wg] NAT/PAT

                 

                Dear IP-WG:

                I spent a couple of hours on this sunny Saturday looking into the
                complications caused to B/IP by dynamic NAT and PAT. Here are the
                conclusions I came to:

                1.  To prevent erroneous router-to-network address bindings caused
                by randomly assigned source IP or port numbers, do not update
                routing tables on any directed communication from a network. Use
                exclusively the Who-Is-Router-To-Network and the I-Am-Router-To-
                Network network layer services or the I-Am service. These are always
                broadcast so will be sent with F-NPDU's.

                2. There will have to be one fixed global B/IP address for each
                subnet that is port-forwarded to the BBMD/Router on each subnet.
                This fixed B/IP address is entered in the BDT and conveyed in F-
                NPDUs.

                3. It does not matter that directed communications may have
                differently assigned IP's and Ports as long as the NAT Router keeps
                the temporary reply forwarding open long enough for the reply to
                come through (which I believe it does).

                On Foreign Devices behind a NAT Router:
                Either:
                1. Resister often to keep temporary path open.
                or
                2. Need new Register-Foreign-Device-NAT that specifies Global-IP
                like in F-NPDU. This would also require each FD behind the NAT to
                have a separtate port-forwarding.


                Roland Laird



                 

              • Roland Laird
                Hi Chris, I don t understand the concern with other routers that may have different MS/TP networks . The way I see it the NAT aware BBMD/Router will update
                Message 7 of 13 , Mar 13, 2006
                • 0 Attachment

                  Hi Chris,

                   

                  I don’t understand the concern with “other routers that may have different MS/TP networks”.  The way I see it the NAT aware BBMD/Router will update its routing tables with the addresses passed in the F-NPDU. All communications from other networks (MS/TP or otherwise) will use these addresses on their outgoing communications. Likewise the BBMD/Router will be the router to its ms/tp networks and will advertise it with a F-NPDU so all other remote networks will know how to communicate with the target ms/tp networks.

                   

                  Roland

                   


                  From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Christopher.J.McCann@...
                  Sent: Monday, March 13, 2006 5:47 AM
                  To: bacnet-ip-wg@yahoogroups.com
                  Subject: Re: [bacnet-ip-wg] NAT/PAT

                   


                  Roland,

                  We had advised this solution as a way to fix the problem with NATs; however, many IT departments are having a problem with assigning
                  one global address for BACNet communications.  I am also concerned that you are relying on WHO-IS-ROUTER-TO-NETWORK and
                  I-AM-ROUTER-TO-NETWORK as the solution to the problem. This would only cover the case of the static IP router.  It would not cover
                  other routers that may have different MSTP networks.  These would get through the BBMD, but the IP address would be wrong when you
                  update your routing table  for that particular network anyway.  I'm not sure, but I think we are going to have to think of another solution where
                  we try not to use BACNet/IP functionality, but instead use SSL or HTTP as the way to get through the NAT.  The other solution is start
                  pushing hard to change over to IPV6.

                  Chris McCann
                  Johnson Controls, Inc.


                  rlaird@...
                  Sent by: bacnet-ip-wg@yahoogroups.com

                  03/11/2006 04:55 PM

                  Please respond to
                  bacnet-ip-wg@yahoogroups.com

                  To

                  bacnet-ip-wg@yahoogroups.com

                  cc

                   

                  Subject

                  [bacnet-ip-wg] NAT/PAT

                   

                   

                   




                  Dear IP-WG:

                  I spent a couple of hours on this sunny Saturday looking into the
                  complications caused to B/IP by dynamic NAT and PAT. Here are the
                  conclusions I came to:

                  1.  To prevent erroneous router-to-network address bindings caused
                  by randomly assigned source IP or port numbers, do not update
                  routing tables on any directed communication from a network. Use
                  exclusively the Who-Is-Router-To-Network and the I-Am-Router-To-
                  Network network layer services or the I-Am service. These are always
                  broadcast so will be sent with F-NPDU's.

                  2. There will have to be one fixed global B/IP address for each
                  subnet that is port-forwarded to the BBMD/Router on each subnet.
                  This fixed B/IP address is entered in the BDT and conveyed in F-
                  NPDUs.

                  3. It does not matter that directed communications may have
                  differently assigned IP's and Ports as long as the NAT Router keeps
                  the temporary reply forwarding open long enough for the reply to
                  come through (which I believe it does).

                  On Foreign Devices behind a NAT Router:
                  Either:
                  1. Resister often to keep temporary path open.
                  or
                  2. Need new Register-Foreign-Device-NAT that specifies Global-IP
                  like in F-NPDU. This would also require each FD behind the NAT to
                  have a separtate port-forwarding.


                  Roland Laird




                   


                  YAHOO! GROUPS LINKS

                   

                   


                   

                   

                • Matsen, Dean (WA26)
                  As much as I hate to say it, perhaps a new technology is needed. It seems to me that if we started from scratch, we would wind up with something that was kind
                  Message 8 of 13 , Mar 14, 2006
                  • 0 Attachment

                     

                    As much as I hate to say it, perhaps a new technology is needed.

                     

                    It seems to me that if we started from scratch, we would wind up with something that was kind of like BACnet/IP + BBMD functionality, but customized for use with NAT/PAT.  This would even allow for future DHCP/DNS considerations.  It could be called "BNFD" for "BACnet NAT Forwarding Device" or something.  

                    It seems like this technology would not be THAT difficult to propose, especially if it were modeled after the desirable elements of Annex J.

                     

                    In the end, this might become a much more intelligent solution than trying to quick-fix the Annex J language to accommodate what we are trying to do.

                     

                    As it turns out, we at Alerton Honeywell already have a few variants of such proposals (which we have held back in hopes that Roland's proposal becomes an easier fix).  Dare I muddy the waters further by bringing forth one of these proposals?

                     

                     

                    Regards,

                    Dean

                     

                  • Jimmy Rimmer
                    Dean, are you proposing a new technology separate from B/IP, or a full revision of B/IP -- call it B/IP version 2? Either way, I know that I d be interested in
                    Message 9 of 13 , Mar 14, 2006
                    • 0 Attachment
                      Dean, are you proposing a new technology separate from B/IP, or a full revision of B/IP -- call it B/IP version 2?

                      Either way, I know that I'd be interested in the proposal.  I'd rather have too many proposals than not enough.


                      On Mar 14, 2006, at 8:34 AM, Matsen, Dean ((WA26)) wrote:

                       

                      As much as I hate to say it, perhaps a new technology is needed.

                       

                      It seems to me that if we started from scratch, we would wind up with something that was kind of like BACnet/IP + BBMD functionality, but customized for use with NAT/PAT.  This would even allow for future DHCP/DNS considerations.  It could be called "BNFD" for "BACnet NAT Forwarding Device" or something.  

                      It seems like this technology would not be THAT difficult to propose, especially if it were modeled after the desirable elements of Annex J.

                       

                      In the end, this might become a much more intelligent solution than trying to quick-fix the Annex J language to accommodate what we are trying to do.

                       

                      As it turns out, we at Alerton Honeywell already have a few variants of such proposals (which we have held back in hopes that Roland's proposal becomes an easier fix).  Dare I muddy the waters further by bringing forth one of these proposals?

                       

                       

                      Regards,

                      Dean

                       



                      SPONSORED LINKS
                      Communication and networkingProtocol


                      YAHOO! GROUPS LINKS





                      --
                      Jimmy Rimmer
                      Member of Technical Staff
                      Kiyon, Inc

                      Legal mumbo-jumbo:

                      The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you.

                    • Matsen, Dean (WA26)
                      The proposal I have still needs a little work (we didn t think of the implications of PAT vs. NAT either). It is a separate technology in addition to B/IP. We
                      Message 10 of 13 , Mar 14, 2006
                      • 0 Attachment

                        The proposal I have still needs a little work (we didn't think of the implications of PAT vs. NAT either).  It is a separate technology in addition to B/IP.

                        We thought this was a cleaner solution than fiddling with Annex J.

                         

                         

                        I will refine the proposal and publish it.

                         

                         

                        Regards,

                        Dean

                         

                         


                        From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Jimmy Rimmer
                        Sent: Tuesday, March 14, 2006 12:43 PM
                        To: bacnet-ip-wg@yahoogroups.com
                        Subject: Re: [bacnet-ip-wg] NAT/PAT

                         

                        Dean, are you proposing a new technology separate from B/IP, or a full revision of B/IP -- call it B/IP version 2?

                         

                        Either way, I know that I'd be interested in the proposal.  I'd rather have too many proposals than not enough.

                         

                         

                        On Mar 14, 2006, at 8:34 AM, Matsen, Dean ((WA26)) wrote:



                         

                        As much as I hate to say it, perhaps a new technology is needed.

                         

                        It seems to me that if we started from scratch, we would wind up with something that was kind of like BACnet/IP + BBMD functionality, but customized for use with NAT/PAT.  This would even allow for future DHCP/DNS considerations.  It could be called "BNFD" for "BACnet NAT Forwarding Device" or something.  

                        It seems like this technology would not be THAT difficult to propose, especially if it were modeled after the desirable elements of Annex J.

                         

                        In the end, this might become a much more intelligent solution than trying to quick-fix the Annex J language to accommodate what we are trying to do.

                         

                        As it turns out, we at Alerton Honeywell already have a few variants of such proposals (which we have held back in hopes that Roland's proposal becomes an easier fix).  Dare I muddy the waters further by bringing forth one of these proposals?

                         

                         

                        Regards,

                        Dean

                         

                         

                        SPONSORED LINKS

                        Communication and networking

                        Protocol

                         


                        YAHOO! GROUPS LINKS

                         

                         




                         

                        --

                        Jimmy Rimmer

                        Member of Technical Staff

                        Kiyon, Inc

                         

                        Legal mumbo-jumbo:


                        The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you.



                      • Carl Neilson
                        We implemented something close to what RL-002 describes many years ago and it has served us faithfully. The implementation works with other vendor s BBMD
                        Message 11 of 13 , Mar 16, 2006
                        • 0 Attachment
                           
                          We implemented something close to what RL-002 describes many years ago and it has served us faithfully. The implementation works with other vendor's BBMD implementations and so far we have not encountered an installation where this solution does not work when deployed with a single point of access behind a NAT/PAT. That single point of access is always a BBMD/Router in our installations and the setup works great.
                           
                          I have not had the opportunity to read through all of the emails that have transpired so maybe there is a problem that we have yet to encounter but if this simple modification to the existing standard works, why consider making more work for ourselves?
                           
                          Also, it might be worth noting that a BACnet/SSL proposal is in the works which will provide another Internet connectivity solution.
                           
                          Carl


                          From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Matsen, Dean (WA26)
                          Sent: Tuesday, March 14, 2006 1:00 PM
                          To: bacnet-ip-wg@yahoogroups.com
                          Subject: RE: [bacnet-ip-wg] NAT/PAT

                          The proposal I have still needs a little work (we didn't think of the implications of PAT vs. NAT either).  It is a separate technology in addition to B/IP.

                          We thought this was a cleaner solution than fiddling with Annex J.

                           

                           

                          I will refine the proposal and publish it.

                           

                           

                          Regards,

                          Dean

                           

                           


                          From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Jimmy Rimmer
                          Sent: Tuesday, March 14, 2006 12:43 PM
                          To: bacnet-ip-wg@yahoogroups.com
                          Subject: Re: [bacnet-ip-wg] NAT/PAT

                           

                          Dean, are you proposing a new technology separate from B/IP, or a full revision of B/IP -- call it B/IP version 2?

                           

                          Either way, I know that I'd be interested in the proposal.  I'd rather have too many proposals than not enough.

                           

                           

                          On Mar 14, 2006, at 8:34 AM, Matsen, Dean ((WA26)) wrote:



                           

                          As much as I hate to say it, perhaps a new technology is needed.

                           

                          It seems to me that if we started from scratch, we would wind up with something that was kind of like BACnet/IP + BBMD functionality, but customized for use with NAT/PAT.  This would even allow for future DHCP/DNS considerations.  It could be called "BNFD" for "BACnet NAT Forwarding Device" or something.  

                          It seems like this technology would not be THAT difficult to propose, especially if it were modeled after the desirable elements of Annex J.

                           

                          In the end, this might become a much more intelligent solution than trying to quick-fix the Annex J language to accommodate what we are trying to do.

                           

                          As it turns out, we at Alerton Honeywell already have a few variants of such proposals (which we have held back in hopes that Roland's proposal becomes an easier fix).  Dare I muddy the waters further by bringing forth one of these proposals?

                           

                           

                          Regards,

                          Dean

                           

                           

                          SPONSORED LINKS

                          Communication and networking

                          Protocol

                           


                          YAHOO! GROUPS LINKS

                           

                           




                           

                          --

                          Jimmy Rimmer

                          Member of Technical Staff

                          Kiyon, Inc

                           

                          Legal mumbo-jumbo:


                          The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you.



                        • Matsen, Dean (WA26)
                          Carl, If your solution is different from RL-002, why don t you publish it? Perhaps you have solved the problem in a way that avoids this problem. Our front end
                          Message 12 of 13 , Mar 16, 2006
                          • 0 Attachment

                            Carl,

                             

                            If your solution is different from RL-002, why don't you publish it?  Perhaps you have solved the problem in a way that avoids this problem.

                             

                            Our front end software detects the introduction of new devices (or the same device instance with a new MAC address).  Whenever the NAT router gets rebooted, it looks like a new device has been added to the BACnet network, which leads to a user warning.  This is a user-requested feature, not an idea that originated from Engineering.

                             

                            Regards,

                            Dean

                             

                             


                            From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Carl Neilson
                            Sent: Thursday, March 16, 2006 1:22 PM
                            To: bacnet-ip-wg@yahoogroups.com
                            Subject: RE: [bacnet-ip-wg] NAT/PAT

                             

                             

                            We implemented something close to what RL-002 describes many years ago and it has served us faithfully. The implementation works with other vendor's BBMD implementations and so far we have not encountered an installation where this solution does not work when deployed with a single point of access behind a NAT/PAT. That single point of access is always a BBMD/Router in our installations and the setup works great.

                             

                            I have not had the opportunity to read through all of the emails that have transpired so maybe there is a problem that we have yet to encounter but if this simple modification to the existing standard works, why consider making more work for ourselves?

                             

                            Also, it might be worth noting that a BACnet/SSL proposal is in the works which will provide another Internet connectivity solution.

                             

                            Carl

                             


                            From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Matsen, Dean (WA26)
                            Sent: Tuesday, March 14, 2006 1:00 PM
                            To: bacnet-ip-wg@yahoogroups.com
                            Subject: RE: [bacnet-ip-wg] NAT/PAT

                            The proposal I have still needs a little work (we didn't think of the implications of PAT vs. NAT either).  It is a separate technology in addition to B/IP.

                            We thought this was a cleaner solution than fiddling with Annex J.

                             

                             

                            I will refine the proposal and publish it.

                             

                             

                            Regards,

                            Dean

                             

                             


                            From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Jimmy Rimmer
                            Sent: Tuesday, March 14, 2006 12:43 PM
                            To: bacnet-ip-wg@yahoogroups.com
                            Subject: Re: [bacnet-ip-wg] NAT/PAT

                             

                            Dean, are you proposing a new technology separate from B/IP, or a full revision of B/IP -- call it B/IP version 2?

                             

                            Either way, I know that I'd be interested in the proposal.  I'd rather have too many proposals than not enough.

                             

                             

                            On Mar 14, 2006, at 8:34 AM, Matsen, Dean ((WA26)) wrote:

                             

                             

                            As much as I hate to say it, perhaps a new technology is needed.

                             

                            It seems to me that if we started from scratch, we would wind up with something that was kind of like BACnet/IP + BBMD functionality, but customized for use with NAT/PAT.  This would even allow for future DHCP/DNS considerations.  It could be called "BNFD" for "BACnet NAT Forwarding Device" or something.  

                            It seems like this technology would not be THAT difficult to propose, especially if it were modeled after the desirable elements of Annex J.

                             

                            In the end, this might become a much more intelligent solution than trying to quick-fix the Annex J language to accommodate what we are trying to do.

                             

                            As it turns out, we at Alerton Honeywell already have a few variants of such proposals (which we have held back in hopes that Roland's proposal becomes an easier fix).  Dare I muddy the waters further by bringing forth one of these proposals?

                             

                             

                            Regards,

                            Dean

                             

                             

                            SPONSORED LINKS

                            Communication and networking

                            Protocol

                             


                            YAHOO! GROUPS LINKS

                             

                             


                             

                             

                            --

                            Jimmy Rimmer

                            Member of Technical Staff

                            Kiyon, Inc

                             

                            Legal mumbo-jumbo:


                            The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you.

                             

                             

                          • Matsen, Dean (WA26)
                            Ok, here is a proposal that I hope is agreeable to all concerned. It requires some familiarity with RL-002 and the discussion between Roland and Myself
                            Message 13 of 13 , Mar 17, 2006
                            • 0 Attachment

                              Ok, here is a proposal that I hope is agreeable to all concerned.  

                               

                              It requires some familiarity with RL-002 and the discussion between Roland and Myself regarding the B/IP addresses being randomly assigned by the NAT/PAT routers.

                               

                              In the interest of quick turn-around, I worked on this quickly.  If this looks acceptable, I will revise it to stand on its own rather than to depend on other sources.

                               

                              Regards,

                              Dean

                               

                               


                              From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Jimmy Rimmer
                              Sent: Tuesday, March 14, 2006 12:43 PM
                              To: bacnet-ip-wg@yahoogroups.com
                              Subject: Re: [bacnet-ip-wg] NAT/PAT

                               

                              Dean, are you proposing a new technology separate from B/IP, or a full revision of B/IP -- call it B/IP version 2?

                               

                              Either way, I know that I'd be interested in the proposal.  I'd rather have too many proposals than not enough.

                               

                               

                              On Mar 14, 2006, at 8:34 AM, Matsen, Dean ((WA26)) wrote:



                               

                              As much as I hate to say it, perhaps a new technology is needed.

                               

                              It seems to me that if we started from scratch, we would wind up with something that was kind of like BACnet/IP + BBMD functionality, but customized for use with NAT/PAT.  This would even allow for future DHCP/DNS considerations.  It could be called "BNFD" for "BACnet NAT Forwarding Device" or something.  

                              It seems like this technology would not be THAT difficult to propose, especially if it were modeled after the desirable elements of Annex J.

                               

                              In the end, this might become a much more intelligent solution than trying to quick-fix the Annex J language to accommodate what we are trying to do.

                               

                              As it turns out, we at Alerton Honeywell already have a few variants of such proposals (which we have held back in hopes that Roland's proposal becomes an easier fix).  Dare I muddy the waters further by bringing forth one of these proposals?

                               

                               

                              Regards,

                              Dean

                               

                               

                              SPONSORED LINKS

                              Communication and networking

                              Protocol

                               


                              YAHOO! GROUPS LINKS

                               

                               




                               

                              --

                              Jimmy Rimmer

                              Member of Technical Staff

                              Kiyon, Inc

                               

                              Legal mumbo-jumbo:


                              The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you.



                            Your message has been successfully submitted and would be delivered to recipients shortly.