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

IPv6 Multicast Wireshark Capture

Expand Messages
  • Coleman Brumley
    IP-WG, Attached is a Wireshark capture of various BACnet broadcasts transmitted via IPv4 broadcast as well as IPv6 link-local multicast (ff02::bac0). This was
    Message 1 of 5 , Feb 27, 2012
    • 1 Attachment
    • 982 Bytes

    IP-WG,

     

    Attached is a Wireshark capture of various BACnet broadcasts transmitted via IPv4 broadcast as well as IPv6 link-local multicast (ff02::bac0). 

     

    This was done from a Windows machine, and one of the lessons learned from this exercise is that the interface index portion of the IPv6 address is important for building the outgoing packet.  So, this information must be contained in the network port object in addition to the VMAC address and the IPv6 address. It's possible to include the interface index in the IPv6 address itself, but in my opinion, it's cleaner to include it as a separate character property.

     

    Regards,

    Coleman

     

     

  • Hartman, John
    Suppose that I have BBMD A and Device B on a different subnet. B registers as a foreign device with A. If B sends a PDU with distribute-broadcast-to-network
    Message 2 of 5 , Mar 21, 2012
    • 0 Attachment

      Suppose that I have BBMD A and Device B on a different subnet.  B registers as a foreign device with A.  If B sends a PDU with distribute-broadcast-to-network to BBMD A, A will do its thing and forward the PDU according to its BDT and FDT.

       

      If B does not register (or if it allows the registration to time out), and then sends a PDU with distribute-broadcast-to-network to BBMD A, at least some current BBMDs (such as ours) will refuse to forward the PDU, and will return a BVLC-result with an error.  (Clause J.4.5 doesn’t explicitly talk about this sort of refusal, but it explicitly does allow a BBMD to return a BVLC-result “if the BBMD is unable to perform the forwarding function”.)

       

      Now suppose that device B is also a BBMD.  It wants to register foreign with A, so that it can use a DNS name to find A, and so that their BDTs don’t have to be kept in sync.

       

      When BBMD B needs to forward a local broadcast, it can’t use a distribute-broadcast-to-network message, since that doesn’t contain the source address of the originator of the broadcast.

       

      If BBMD B forwards to BBMD A using forwarded-NPDU, is the PDU likely to be rejected by BBMD A, since B is not a peer BBMD in A’s BDT?  Annex J doesn’t say anything explicit, but it does describe A doing a search for B’s address in A’s BDT to see whether or not A needs to do a local broadcast.  It is easy to imagine an implementation that A would say “B isn’t in my BDT, therefore it isn’t a BBMD and I will ignore its forwarded-NPDU”.

       

      Am I likely to have this sort of problem?  If so, what are people doing to avoid it?  I would hate to have to reconfigure all the non-BBMD devices on B’s subnet to register foreign.  In addition to configuration hassles, BBMD A would then need to cope with a large number of foreign registrations.

       

       

       

       

       




      The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.
    • Joel Bender
      John, ... All is happy and bright. ... Ours drops it rather than sending back a reject. ... The fact that it s a BBMD is blind to A. ... Device B needs to be
      Message 3 of 5 , Mar 21, 2012
      • 0 Attachment
        John,


        > Suppose that I have BBMD A and Device B on a different subnet. B registers as a foreign device with A. If B sends a PDU with distribute-broadcast-to-network to BBMD A, A will do its thing and forward the PDU according to its BDT and FDT.

        All is happy and bright.

        > If B does not register (or if it allows the registration to time out), and then sends a PDU with distribute-broadcast-to-network to BBMD A, at least some current BBMDs (such as ours) will refuse to forward the PDU, and will return a BVLC-result with an error. (Clause J.4.5 doesn’t explicitly talk about this sort of refusal, but it explicitly does allow a BBMD to return a BVLC-result “if the BBMD is unable to perform the forwarding function”.)

        Ours drops it rather than sending back a reject.

        > Now suppose that device B is also a BBMD. It wants to register foreign with A, so that it can use a DNS name to find A, and so that their BDTs don’t have to be kept in sync.

        The fact that it's a BBMD is blind to A.

        > When BBMD B needs to forward a local broadcast, it can’t use a distribute-broadcast-to-network message, since that doesn’t contain the source address of the originator of the broadcast.

        Device B needs to be an IP-to-IP router. It will use distribute broadcast to network messages, but they will contain the SNET/SLEN/SADR of the original source address.

        > If BBMD B forwards to BBMD A using forwarded-NPDU, is the PDU likely to be rejected by BBMD A, since B is not a peer BBMD in A’s BDT?

        Correct.

        > Annex J doesn’t say anything explicit, but it does describe A doing a search for B’s address in A’s BDT to see whether or not A needs to do a local broadcast. It is easy to imagine an implementation that A would say “B isn’t in my BDT, therefore it isn’t a BBMD and I will ignore its forwarded-NPDU”.

        Yes, that's what my implementation does. It seems to be a fairly common practice to simply drop requests a server doesn't like rather than reject them.

        > Am I likely to have this sort of problem? If so, what are people doing to avoid it? I would hate to have to reconfigure all the non-BBMD devices on B’s subnet to register foreign. In addition to configuration hassles, BBMD A would then need to cope with a large number of foreign registrations.

        It's not really a problem, but it can make the code for B slightly more complicated it has to check incoming forwarded-npdu messages to see if they are from peers or from A. And of course it adds B as an extra hop for devices on device A's networks to those on B's.

        We set up an Annex-H tunnel between A and B so the code can decide very early in the processing of incoming packets what path to take up the stack, the absence of the BVLL header points to the BTR side. We are also very aggressively filtering broadcasts and network visibility (network X is visible from Y but not Z) because the connection between A (on campus) and B (off campus) is over a cellular data network and the constant stream of broadcasts would crush the link and we would get an outrageous bill from Verizon!


        Joel
      • Matsen, Dean C
        John, Last time I investigated this, I came to the conclusion that the behavioral requirements of a BBMD and a registered device are mutually exclusive. As
        Message 4 of 5 , Mar 21, 2012
        • 0 Attachment

          John,

           

          Last time I investigated this, I came to the conclusion that the behavioral requirements of a BBMD and a registered device are mutually exclusive.  As far as I can see, a BBMD can't register as a foreign device with the current specification, for the reasons you stated, and maybe more.

           

           

          Regards,

          Dean Matsen

          Engineer Software Pr

          Alerton Dealer Business

          Honeywell Automation & Control Solutions

          6670 185th Ave NE

          Redmond WA 98052

          Phone – 425.897.3980

          Fax – 425.869.8445

          dean.matsen@...

           

           

           

          From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Hartman, John
          Sent: Wednesday, March 21, 2012 8:28 AM
          To: bacnet-ip-wg@yahoogroups.com
          Subject: [bacnet-ip-wg] Using foreign registration between BBMDs

           

           

          Suppose that I have BBMD A and Device B on a different subnet.  B registers as a foreign device with A.  If B sends a PDU with distribute-broadcast-to-network to BBMD A, A will do its thing and forward the PDU according to its BDT and FDT.

           

          If B does not register (or if it allows the registration to time out), and then sends a PDU with distribute-broadcast-to-network to BBMD A, at least some current BBMDs (such as ours) will refuse to forward the PDU, and will return a BVLC-result with an error.  (Clause J.4.5 doesn’t explicitly talk about this sort of refusal, but it explicitly does allow a BBMD to return a BVLC-result “if the BBMD is unable to perform the forwarding function”.)

           

          Now suppose that device B is also a BBMD.  It wants to register foreign with A, so that it can use a DNS name to find A, and so that their BDTs don’t have to be kept in sync.

           

          When BBMD B needs to forward a local broadcast, it can’t use a distribute-broadcast-to-network message, since that doesn’t contain the source address of the originator of the broadcast.

           

          If BBMD B forwards to BBMD A using forwarded-NPDU, is the PDU likely to be rejected by BBMD A, since B is not a peer BBMD in A’s BDT?  Annex J doesn’t say anything explicit, but it does describe A doing a search for B’s address in A’s BDT to see whether or not A needs to do a local broadcast.  It is easy to imagine an implementation that A would say “B isn’t in my BDT, therefore it isn’t a BBMD and I will ignore its forwarded-NPDU”.

           

          Am I likely to have this sort of problem?  If so, what are people doing to avoid it?  I would hate to have to reconfigure all the non-BBMD devices on B’s subnet to register foreign.  In addition to configuration hassles, BBMD A would then need to cope with a large number of foreign registrations.

           

           

           

           

           

           



          The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.

        • Buddy Lott
          John, Combining a BBMD, FD, and router can achieve the goal you after. It just takes some planning and a little more configuration.
          Message 5 of 5 , Mar 22, 2012
          • 0 Attachment

            John,

             

            Combining a BBMD, FD, and router can achieve the goal you after. It just takes some planning and a little more configuration.

             


            From: Matsen, Dean C [mailto:dean.matsen@...]
            Sent: Wednesday, March 21, 2012 2:32 PM
            To: bacnet-ip-wg@yahoogroups.com
            Subject: [bacnet-ip-wg] RE: Using foreign registration between BBMDs

             

             

            John,

             

            Last time I investigated this, I came to the conclusion that the behavioral requirements of a BBMD and a registered device are mutually exclusive.  As far as I can see, a BBMD can't register as a foreign device with the current specification, for the reasons you stated, and maybe more.

             

             

            Regards,

            Dean Matsen

            Engineer Software Pr

            Alerton Dealer Business

            Honeywell Automation & Control Solutions

            6670 185th Ave NE

            Redmond WA 98052

            Phone – 425.897.3980

            Fax – 425.869.8445

            dean.matsen@...

             

             

             

            From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Hartman, John
            Sent: Wednesday, March 21, 2012 8:28 AM
            To: bacnet-ip-wg@yahoogroups.com
            Subject: [bacnet-ip-wg] Using foreign registration between BBMDs

             

             

            Suppose that I have BBMD A and Device B on a different subnet.  B registers as a foreign device with A.  If B sends a PDU with distribute-broadcast-to-network to BBMD A, A will do its thing and forward the PDU according to its BDT and FDT.

             

            If B does not register (or if it allows the registration to time out), and then sends a PDU with distribute-broadcast-to-network to BBMD A, at least some current BBMDs (such as ours) will refuse to forward the PDU, and will return a BVLC-result with an error.  (Clause J.4.5 doesn’t explicitly talk about this sort of refusal, but it explicitly does allow a BBMD to return a BVLC-result “if the BBMD is unable to perform the forwarding function”.)

             

            Now suppose that device B is also a BBMD.  It wants to register foreign with A, so that it can use a DNS name to find A, and so that their BDTs don’t have to be kept in sync.

             

            When BBMD B needs to forward a local broadcast, it can’t use a distribute-broadcast-to-network message, since that doesn’t contain the source address of the originator of the broadcast.

             

            If BBMD B forwards to BBMD A using forwarded-NPDU, is the PDU likely to be rejected by BBMD A, since B is not a peer BBMD in A’s BDT?  Annex J doesn’t say anything explicit, but it does describe A doing a search for B’s address in A’s BDT to see whether or not A needs to do a local broadcast.  It is easy to imagine an implementation that A would say “B isn’t in my BDT, therefore it isn’t a BBMD and I will ignore its forwarded-NPDU”.

             

            Am I likely to have this sort of problem?  If so, what are people doing to avoid it?  I would hate to have to reconfigure all the non-BBMD devices on B’s subnet to register foreign.  In addition to configuration hassles, BBMD A would then need to cope with a large number of foreign registrations.

             

             

             

             

             

             



            The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.

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