Subject: [ntpwg] Idea about modifying existing NTP extension header to remove size restriction due to MAC.

From: Vikram Choudhary <[email-masked]>
Date: Wed, 15 Apr 2015 05:26:59 +0000

Hi All,

I was thinking of redefining the legacy NTP extension header for reducing unwanted padding introduced due to MAC.

How this helps:

è Removes size restriction for the NTP extension field imposed due to MAC. (RFC 5905)

è Reduces packet size avoiding unwanted padding.

è Saves bandwidth.

Idea:

Reserve MSB of field type to indicate whether the following TLV is an extension or not.

       0                   1                   2                   3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |M|        Field Type         |            Length             |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      .                                                             .

      .                            Value                            .

      .                                                             .

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                       Padding (as needed)                   |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure: New extension Field Format

        Bit-M : 1 - More extensions to be followed, 0 - No more extensions.

Ensuring backward compatibility:

   Following points/rules will take care of backward compatibility.

a.  NTP packet with no extension/s and MAC.

      This is simple as the packet size will be just equal to NTP header size. No special processing required.

b.  NTP packet with MAC.

      NTP packet size as defined in RFC 5905 will be considered for MAC processing.

   c.  NTP packet with autokey extension/s and with/without MAC.

       Autokey extension's are the only defined NTP extension's so current size limitation and processing will remain as defined in RFC 5905 and 5906.

       Note: Autokey extension will be identified as per the defined IANA values.

   d.  NTP packet with new extension/s with/without autokey extension/s and with/without MAC.

Ø   Autokey extension/s MUST be continuous and SHOULD start after NTP header (existing implementation, no change).

Ø   First extension following NTP header MUST be at least 7 words.

Ø   First extension following autokey extension MUST be at least 7 words.

   e.  IANA values for the newer extensions should not collide with Autokey IANA values after considering the MSB bit value.

Request you to kindly let me know about your views.

Thanks

Vikram

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg