multicast - wrong interface - NTP

This is a discussion on multicast - wrong interface - NTP ; David L. Mills wrote: > Martin, > > The descrete values used for the TTL is consistent with the > administrative scoping rules spelled out in the RFC cited in the > documentation. > > Dave Dave, this is a ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 25 of 25

Thread: multicast - wrong interface

  1. Re: multicast - TTL

    David L. Mills wrote:
    > Martin,
    >
    > The descrete values used for the TTL is consistent with the
    > administrative scoping rules spelled out in the RFC cited in the
    > documentation.
    >
    > Dave


    Dave, this is a case where the rules are totally wrong. TTL here is a
    HOP count and not a time-to-live, in spite of the label. In IPv6 it's
    really called a hop count rather than ttl but we should not propogate
    this error. I can't find anything either in the NTPv4 Draft RFC or RFC
    1305 so I don't know what RFC you mean. Can you clarify? Multicast
    doesn't work the way that it was originally designed. It also make no
    sense to specify a value other than what you want the ttl be set to.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: multicast - wrong interface

    > > And because it is already known, I will not report it as a bug.
    > Well you should since I don't think we have a bug report on this.
    > Furthermore, I don't know yet whether or not we should try and figure
    > out which interface should be used or just add a option to the broadcast
    > line to tell it what to use.

    Bug 785 submitted.

    Martin

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  3. Re: multicast - TTL

    Danny,

    The TTL mechanism in NTP manycast expanding-ring search was designed for
    RFC 2365. Routers of the day applied administrative scoping fences
    specific to multicast packets. I don't know if routers can do that
    today. It actually was quite useful in the MBONE.

    Note that the ttl option in the server configuration is the index of an
    entry in the ttl table. The ttl command sets the contents of that table.
    The manycast expanding-rung search uses the entries in the table in
    ascending order.

    Dave

    Danny Mayer wrote:
    > Martin wrote:
    >
    >>wa6zvp wrote:
    >>
    >>>The quick answer is to put this in your config file:
    >>>
    >>>ttl 0 1 2 3 4 5 6 7
    >>>
    >>>This creates a one-to-one mapping for ttl.

    >>
    >>Roger, thank you for solving the issue.
    >>
    >>I've read the discussion you mentioned. It looks to me that unless overridden
    >>with the ttl command like the one above, the whole TTL range 0-255 is reduced
    >>to just 8 values: 0,32,64, ... 224. The ttl option to the broadcast command is
    >>then not the real TTL value, but an index selecting one from those 8 values.
    >>
    >>It probably causes no harm to use incorrect (larger) TTL, but this feature
    >>could be better documented, IMHO.

    >
    >
    > No, the code should be corrected. In spite of its name, the value is
    > actually a hop count when you are doing multicasting. Originally when
    > the IPv4 multicast protocol was being developed it was thought that this
    > should really be a time-to-live. In practice this didn't happen. The
    > routers actually take the value and subtract one and send it on if the
    > new value is greater than 0. With IPv6 multicasting it's actually called
    > a hop count. Multicasting is not really well developed beyond site-local
    > and I doubt that any of the Internet backbone routers will pass on
    > multicast packets outside of their own though I haven't checked that
    > myself. In fact your border routers should stop them.
    >
    > In summary, the ttl on the broadcast line should be what you want to set
    > the outgoing ttl to and not something else. It should always been that
    > way. I don't understand why you want an extra line to specify what the
    > value means.
    >
    > Danny
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


  4. Re: multicast - TTL

    Danny,

    The TTL support in ntpd was specifically designed for an expanding-ring
    search. It has nothing to do with the specifications NTPv3 or NTPv4.
    With current Unix semantics, it is operative only in multicast/manycast
    modes. I haven't verified recently, but for a long time it didn't work
    in IPv4 broadcast.

    There is no intent to bring into discussion the time-to-live/hop-count
    issue, but if you read RFC 760 carefully:

    "Time to Live: 8 bits

    This field indicates the maximum time the datagram is allowed to
    remain the internet system. If this field contains the value zero,
    then the datagram should be destroyed. This field is modified in
    internet header processing. The time is measured in units of
    seconds. The intention is to cause undeliverable datagrams to be
    discarded.

    It was the habit at that time, including the gateway code I wrote, to
    decrement the ttl for each 30-second interval the packet was held on a
    queue. Once upon a time the Internet was like that.

    As I said, it is a simple matter to seed the ttl table with whatever
    values seem useful. It does not seem like a good idea to change the
    rules between unicast, multicast and manycast.

    Dave

    Danny Mayer wrote:

    > David L. Mills wrote:
    >
    >>Martin,
    >>
    >>The descrete values used for the TTL is consistent with the
    >>administrative scoping rules spelled out in the RFC cited in the
    >>documentation.
    >>
    >>Dave

    >
    >
    > Dave, this is a case where the rules are totally wrong. TTL here is a
    > HOP count and not a time-to-live, in spite of the label. In IPv6 it's
    > really called a hop count rather than ttl but we should not propogate
    > this error. I can't find anything either in the NTPv4 Draft RFC or RFC
    > 1305 so I don't know what RFC you mean. Can you clarify? Multicast
    > doesn't work the way that it was originally designed. It also make no
    > sense to specify a value other than what you want the ttl be set to.
    >
    > Danny
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


  5. Re: multicast - wrong interface

    Martin,

    The original intent for network interface selection with DVMRP and IGMP
    was to broadcast on the local net(s) and encapsulate the packet to the
    next gateway on the reverse-path-forward spanning tree. Thus, the
    selection of exit interface was determined by the protocol. Only in the
    cast where the spanning tre was rooted at the sender could more than one
    interface be used. I suspect that paradigm perished with the demise of
    the MBONE.

    Dave

    Martin wrote:
    >>>And because it is already known, I will not report it as a bug.

    >>
    >>Well you should since I don't think we have a bug report on this.
    >>Furthermore, I don't know yet whether or not we should try and figure
    >>out which interface should be used or just add a option to the broadcast
    >>line to tell it what to use.

    >
    > Bug 785 submitted.
    >
    > Martin
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2