%% You should probably cite draft-stenn-ntp-mac-last-ef-04 instead of this revision.
@techreport{stenn-ntp-mac-last-ef-00,
    number =    {draft-stenn-ntp-mac-last-ef-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-stenn-ntp-mac-last-ef/00/},
    author =    {Harlan Stenn and Danny Mayer},
    title =     {{Network Time Protocol MAC/Last Extension Fields}},
    pagetotal = 7,
    year =      2016,
    month =     oct,
    day =       30,
    abstract =  {NTPv4 is defined by RFC 5905 {[}RFC5905{]}, and it and earlier versions of the NTP Protocol have supported symmetric private key Message Authentication Code (MAC) authentication. MACs were first described in Appendix C of RFC 1305 {[}RFC1305{]} and are further described in RFC 5905 {[}RFC5905{]}. As the number of Extension Fields grows there is an increasing chance of a parsing ambiguity when deciding if the "next" set of data is an Extension Field or a legacy MAC. This proposal defines two new Extension Fields to avoid this ambiguity. One is used to signifiy that it is the last Extension Field in the packet. If present, any subsequent data MUST be considered to be a legacy MAC. The other allows one or more MACs to be encapsulated in an Extension Field. If all parties in an association support MAC-EF, the use of a legacy MAC may be avoided.},
}