From 6336ef1ef3b557dc2b35ab32e980a288feef83cc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20Sur=C3=BD?= Date: Fri, 16 Feb 2018 15:55:58 +0100 Subject: [PATCH] Remove hard copies of RFCs and I-D from BIND repository, the authoritative source is IETF, and our copies doesn't reflect any errata, expired-by, etc. --- doc/draft/draft-faltstrom-uri-08.txt | 646 -- ...t-ietf-dnsext-dnssec-registry-fixes-08.txt | 448 -- doc/draft/draft-ietf-dnsext-ecc-key-10.txt | 928 --- .../draft-ietf-dnsext-interop3597-02.txt | 334 - .../draft-ietf-dnsext-rfc3597-bis-02.txt | 451 -- ...aft-ietf-dnsext-tsig-md5-deprecated-03.txt | 336 - .../draft-ietf-dnsop-dnssec-key-timing-03.txt | 1848 ----- ...aft-ietf-dnsop-dnssec-trust-history-02.txt | 616 -- .../draft-ietf-dnsop-inaddr-required-07.txt | 396 - doc/draft/draft-ietf-dnsop-respsize-14.txt | 784 -- doc/draft/draft-kato-dnsop-local-zones-00.txt | 295 - doc/draft/draft-kerr-ixfr-only-01.txt | 336 - .../draft-mekking-dnsop-auto-cpsync-01.txt | 392 - doc/draft/draft-pechanec-pkcs11uri-13.txt | 728 -- doc/draft/draft-yao-dnsext-bname-05.txt | 841 -- doc/draft/update | 68 - doc/expired/draft-duerst-dns-i18n-02.txt | 905 --- doc/expired/draft-dunlap-dns-duxfr-00.txt | 336 - doc/expired/draft-ietf-dnsext-iana-dns-00.txt | 696 -- .../draft-ietf-dnsind-binary-labels-05.txt | 337 - doc/expired/draft-ietf-dnsind-dddd-01.txt | 334 - doc/expired/draft-ietf-dnsind-dhcp-rr-00.txt | 167 - doc/expired/draft-ietf-dnsind-dname-03.txt | 502 -- doc/expired/draft-ietf-dnsind-edns0-01.txt | 319 - doc/expired/draft-ietf-dnsind-edns1-03.txt | 249 - .../draft-ietf-dnsind-indirect-key-00.txt | 470 -- .../draft-ietf-dnsind-keyreferral-00.txt | 440 -- .../draft-ietf-dnsind-kitchen-sink-02.txt | 697 -- ...draft-ietf-dnsind-local-compression-05.txt | 420 - .../draft-ietf-dnsind-local-names-07.txt | 662 -- .../draft-ietf-dnsind-rfc2052bis-02.txt | 560 -- doc/expired/draft-ietf-dnsind-rollover-00.txt | 648 -- doc/expired/draft-ietf-dnsind-sec-rr-00.txt | 663 -- .../draft-ietf-dnsind-sigalgopt-00.txt | 164 - .../draft-ietf-dnsind-test-tlds-13.txt | 290 - doc/expired/draft-ietf-dnsind-verify-00.txt | 158 - doc/expired/draft-ietf-dnssec-ar-00.txt | 618 -- doc/expired/draft-ietf-dnssec-as-map-05.txt | 522 -- .../draft-ietf-dnssec-indirect-key-01.txt | 464 -- .../draft-ietf-dnssec-key-handling-00.txt | 473 -- doc/expired/draft-ietf-dnssec-rollover-00.txt | 521 -- doc/expired/draft-ietf-dnssec-secfail-00.txt | 291 - .../draft-ietf-dnssec-simple-update-01.txt | 278 - doc/expired/draft-ietf-dnssec-tkey-01.txt | 1045 --- doc/expired/draft-ietf-dnssec-update2-00.txt | 871 --- doc/expired/draft-ietf-ipngwg-2292bis-00.txt | 3531 --------- .../draft-ietf-ipngwg-bsd-api-new-06.txt | 2176 ------ .../draft-ietf-ipngwg-rfc2292bis-01.txt | 4044 ---------- .../draft-schroeppel-dnsind-ecc-00.txt | 869 --- doc/rfc/fetch | 6 - doc/rfc/index | 170 - doc/rfc/rfc1032.txt | 781 -- doc/rfc/rfc1033.txt | 1229 --- doc/rfc/rfc1034.txt | 3077 -------- doc/rfc/rfc1035.txt | 3077 -------- doc/rfc/rfc1101.txt | 787 -- doc/rfc/rfc1122.txt | 6844 ----------------- doc/rfc/rfc1123.txt | 5782 -------------- doc/rfc/rfc1183.txt | 619 -- doc/rfc/rfc1348.txt | 227 - doc/rfc/rfc1535.txt | 283 - doc/rfc/rfc1536.txt | 675 -- doc/rfc/rfc1537.txt | 507 -- doc/rfc/rfc1591.txt | 395 - doc/rfc/rfc1611.txt | 1683 ---- doc/rfc/rfc1612.txt | 1795 ----- doc/rfc/rfc1706.txt | 563 -- doc/rfc/rfc1712.txt | 395 - doc/rfc/rfc1750.txt | 1683 ---- doc/rfc/rfc1876.txt | 1011 --- doc/rfc/rfc1886.txt | 268 - doc/rfc/rfc1912.txt | 899 --- doc/rfc/rfc1982.txt | 394 - doc/rfc/rfc1995.txt | 451 -- doc/rfc/rfc1996.txt | 395 - doc/rfc/rfc2052.txt | 563 -- doc/rfc/rfc2104.txt | 620 -- doc/rfc/rfc2119.txt | 171 - doc/rfc/rfc2133.txt | 1795 ----- doc/rfc/rfc2136.txt | 1460 ---- doc/rfc/rfc2137.txt | 619 -- doc/rfc/rfc2163.txt | 1459 ---- doc/rfc/rfc2168.txt | 1123 --- doc/rfc/rfc2181.txt | 842 -- doc/rfc/rfc2230.txt | 619 -- doc/rfc/rfc2308.txt | 1067 --- doc/rfc/rfc2317.txt | 563 -- doc/rfc/rfc2373.txt | 1459 ---- doc/rfc/rfc2374.txt | 675 -- doc/rfc/rfc2375.txt | 451 -- doc/rfc/rfc2418.txt | 1459 ---- doc/rfc/rfc2535.txt | 2635 ------- doc/rfc/rfc2536.txt | 339 - doc/rfc/rfc2537.txt | 339 - doc/rfc/rfc2538.txt | 563 -- doc/rfc/rfc2539.txt | 395 - doc/rfc/rfc2540.txt | 339 - doc/rfc/rfc2541.txt | 395 - doc/rfc/rfc2553.txt | 2299 ------ doc/rfc/rfc2671.txt | 395 - doc/rfc/rfc2672.txt | 507 -- doc/rfc/rfc2673.txt | 395 - doc/rfc/rfc2782.txt | 675 -- doc/rfc/rfc2825.txt | 395 - doc/rfc/rfc2826.txt | 339 - doc/rfc/rfc2845.txt | 843 -- doc/rfc/rfc2874.txt | 1123 --- doc/rfc/rfc2915.txt | 1011 --- doc/rfc/rfc2929.txt | 675 -- doc/rfc/rfc2930.txt | 899 --- doc/rfc/rfc2931.txt | 563 -- doc/rfc/rfc3007.txt | 507 -- doc/rfc/rfc3008.txt | 395 - doc/rfc/rfc3071.txt | 563 -- doc/rfc/rfc3090.txt | 619 -- doc/rfc/rfc3110.txt | 395 - doc/rfc/rfc3123.txt | 451 -- doc/rfc/rfc3152.txt | 227 - doc/rfc/rfc3197.txt | 283 - doc/rfc/rfc3225.txt | 339 - doc/rfc/rfc3226.txt | 339 - doc/rfc/rfc3258.txt | 619 -- doc/rfc/rfc3363.txt | 339 - doc/rfc/rfc3364.txt | 619 -- doc/rfc/rfc3425.txt | 283 - doc/rfc/rfc3445.txt | 563 -- doc/rfc/rfc3467.txt | 1739 ----- doc/rfc/rfc3490.txt | 1235 --- doc/rfc/rfc3491.txt | 395 - doc/rfc/rfc3492.txt | 1963 ----- doc/rfc/rfc3493.txt | 2187 ------ doc/rfc/rfc3513.txt | 1459 ---- doc/rfc/rfc3596.txt | 451 -- doc/rfc/rfc3597.txt | 451 -- doc/rfc/rfc3645.txt | 1459 ---- doc/rfc/rfc3655.txt | 451 -- doc/rfc/rfc3658.txt | 1067 --- doc/rfc/rfc3755.txt | 507 -- doc/rfc/rfc3757.txt | 451 -- doc/rfc/rfc3833.txt | 899 --- doc/rfc/rfc3845.txt | 395 - doc/rfc/rfc3901.txt | 283 - doc/rfc/rfc4025.txt | 675 -- doc/rfc/rfc4033.txt | 1179 --- doc/rfc/rfc4034.txt | 1627 ---- doc/rfc/rfc4035.txt | 2971 ------- doc/rfc/rfc4074.txt | 339 - doc/rfc/rfc4159.txt | 171 - doc/rfc/rfc4193.txt | 899 --- doc/rfc/rfc4255.txt | 507 -- doc/rfc/rfc4294.txt | 1123 --- doc/rfc/rfc4339.txt | 1459 ---- doc/rfc/rfc4343.txt | 563 -- doc/rfc/rfc4367.txt | 955 --- doc/rfc/rfc4398.txt | 955 --- doc/rfc/rfc4408.txt | 2691 ------- doc/rfc/rfc4431.txt | 227 - doc/rfc/rfc4470.txt | 451 -- doc/rfc/rfc4471.txt | 1291 ---- doc/rfc/rfc4472.txt | 1627 ---- doc/rfc/rfc4509.txt | 395 - doc/rfc/rfc4634.txt | 6051 --------------- doc/rfc/rfc4635.txt | 451 -- doc/rfc/rfc4641.txt | 1963 ----- doc/rfc/rfc4648.txt | 1011 --- doc/rfc/rfc4697.txt | 1011 --- doc/rfc/rfc4701.txt | 675 -- doc/rfc/rfc4892.txt | 451 -- doc/rfc/rfc4955.txt | 395 - doc/rfc/rfc4956.txt | 955 --- doc/rfc/rfc5001.txt | 619 -- doc/rfc/rfc5011.txt | 787 -- doc/rfc/rfc5155.txt | 2915 ------- doc/rfc/rfc5205.txt | 955 --- doc/rfc/rfc5452.txt | 1011 --- doc/rfc/rfc5507.txt | 1011 --- doc/rfc/rfc5625.txt | 675 -- doc/rfc/rfc5702.txt | 563 -- doc/rfc/rfc5933.txt | 507 -- doc/rfc/rfc5936.txt | 1627 ---- doc/rfc/rfc5952.txt | 787 -- doc/rfc/rfc5966.txt | 395 - doc/rfc/rfc6052.txt | 1011 --- doc/rfc/rfc6147.txt | 1795 ----- doc/rfc/rfc6168.txt | 955 --- doc/rfc/rfc6303.txt | 563 -- doc/rfc/rfc6605.txt | 451 -- doc/rfc/rfc6672.txt | 1235 --- doc/rfc/rfc6698.txt | 2075 ----- doc/rfc/rfc6742.txt | 1123 --- doc/rfc/rfc6840.txt | 1179 --- doc/rfc/rfc6844.txt | 1011 --- doc/rfc/rfc6891.txt | 899 --- doc/rfc/rfc7043.txt | 451 -- doc/rfc/rfc7314.txt | 227 - doc/rfc/rfc7477.txt | 843 -- doc/rfc/rfc7534.txt | 1347 ---- doc/rfc/rfc7535.txt | 899 --- doc/rfc/rfc7766.txt | 1067 --- doc/rfc/rfc7793.txt | 339 - doc/rfc/rfc7828.txt | 619 -- doc/rfc/rfc7830.txt | 283 - doc/rfc/rfc7873.txt | 1403 ---- doc/rfc/rfc8020.txt | 563 -- doc/rfc/rfc8080.txt | 395 - doc/rfc/rfc952.txt | 340 - 206 files changed, 186158 deletions(-) delete mode 100644 doc/draft/draft-faltstrom-uri-08.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-08.txt delete mode 100644 doc/draft/draft-ietf-dnsext-ecc-key-10.txt delete mode 100644 doc/draft/draft-ietf-dnsext-interop3597-02.txt delete mode 100644 doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt delete mode 100644 doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt delete mode 100644 doc/draft/draft-ietf-dnsop-dnssec-key-timing-03.txt delete mode 100644 doc/draft/draft-ietf-dnsop-dnssec-trust-history-02.txt delete mode 100644 doc/draft/draft-ietf-dnsop-inaddr-required-07.txt delete mode 100644 doc/draft/draft-ietf-dnsop-respsize-14.txt delete mode 100644 doc/draft/draft-kato-dnsop-local-zones-00.txt delete mode 100644 doc/draft/draft-kerr-ixfr-only-01.txt delete mode 100644 doc/draft/draft-mekking-dnsop-auto-cpsync-01.txt delete mode 100644 doc/draft/draft-pechanec-pkcs11uri-13.txt delete mode 100644 doc/draft/draft-yao-dnsext-bname-05.txt delete mode 100644 doc/draft/update delete mode 100644 doc/expired/draft-duerst-dns-i18n-02.txt delete mode 100644 doc/expired/draft-dunlap-dns-duxfr-00.txt delete mode 100644 doc/expired/draft-ietf-dnsext-iana-dns-00.txt delete mode 100644 doc/expired/draft-ietf-dnsind-binary-labels-05.txt delete mode 100644 doc/expired/draft-ietf-dnsind-dddd-01.txt delete mode 100644 doc/expired/draft-ietf-dnsind-dhcp-rr-00.txt delete mode 100644 doc/expired/draft-ietf-dnsind-dname-03.txt delete mode 100644 doc/expired/draft-ietf-dnsind-edns0-01.txt delete mode 100644 doc/expired/draft-ietf-dnsind-edns1-03.txt delete mode 100644 doc/expired/draft-ietf-dnsind-indirect-key-00.txt delete mode 100644 doc/expired/draft-ietf-dnsind-keyreferral-00.txt delete mode 100644 doc/expired/draft-ietf-dnsind-kitchen-sink-02.txt delete mode 100644 doc/expired/draft-ietf-dnsind-local-compression-05.txt delete mode 100644 doc/expired/draft-ietf-dnsind-local-names-07.txt delete mode 100644 doc/expired/draft-ietf-dnsind-rfc2052bis-02.txt delete mode 100644 doc/expired/draft-ietf-dnsind-rollover-00.txt delete mode 100644 doc/expired/draft-ietf-dnsind-sec-rr-00.txt delete mode 100644 doc/expired/draft-ietf-dnsind-sigalgopt-00.txt delete mode 100644 doc/expired/draft-ietf-dnsind-test-tlds-13.txt delete mode 100644 doc/expired/draft-ietf-dnsind-verify-00.txt delete mode 100644 doc/expired/draft-ietf-dnssec-ar-00.txt delete mode 100644 doc/expired/draft-ietf-dnssec-as-map-05.txt delete mode 100644 doc/expired/draft-ietf-dnssec-indirect-key-01.txt delete mode 100644 doc/expired/draft-ietf-dnssec-key-handling-00.txt delete mode 100644 doc/expired/draft-ietf-dnssec-rollover-00.txt delete mode 100644 doc/expired/draft-ietf-dnssec-secfail-00.txt delete mode 100644 doc/expired/draft-ietf-dnssec-simple-update-01.txt delete mode 100644 doc/expired/draft-ietf-dnssec-tkey-01.txt delete mode 100644 doc/expired/draft-ietf-dnssec-update2-00.txt delete mode 100644 doc/expired/draft-ietf-ipngwg-2292bis-00.txt delete mode 100644 doc/expired/draft-ietf-ipngwg-bsd-api-new-06.txt delete mode 100644 doc/expired/draft-ietf-ipngwg-rfc2292bis-01.txt delete mode 100644 doc/expired/draft-schroeppel-dnsind-ecc-00.txt delete mode 100755 doc/rfc/fetch delete mode 100644 doc/rfc/index delete mode 100644 doc/rfc/rfc1032.txt delete mode 100644 doc/rfc/rfc1033.txt delete mode 100644 doc/rfc/rfc1034.txt delete mode 100644 doc/rfc/rfc1035.txt delete mode 100644 doc/rfc/rfc1101.txt delete mode 100644 doc/rfc/rfc1122.txt delete mode 100644 doc/rfc/rfc1123.txt delete mode 100644 doc/rfc/rfc1183.txt delete mode 100644 doc/rfc/rfc1348.txt delete mode 100644 doc/rfc/rfc1535.txt delete mode 100644 doc/rfc/rfc1536.txt delete mode 100644 doc/rfc/rfc1537.txt delete mode 100644 doc/rfc/rfc1591.txt delete mode 100644 doc/rfc/rfc1611.txt delete mode 100644 doc/rfc/rfc1612.txt delete mode 100644 doc/rfc/rfc1706.txt delete mode 100644 doc/rfc/rfc1712.txt delete mode 100644 doc/rfc/rfc1750.txt delete mode 100644 doc/rfc/rfc1876.txt delete mode 100644 doc/rfc/rfc1886.txt delete mode 100644 doc/rfc/rfc1912.txt delete mode 100644 doc/rfc/rfc1982.txt delete mode 100644 doc/rfc/rfc1995.txt delete mode 100644 doc/rfc/rfc1996.txt delete mode 100644 doc/rfc/rfc2052.txt delete mode 100644 doc/rfc/rfc2104.txt delete mode 100644 doc/rfc/rfc2119.txt delete mode 100644 doc/rfc/rfc2133.txt delete mode 100644 doc/rfc/rfc2136.txt delete mode 100644 doc/rfc/rfc2137.txt delete mode 100644 doc/rfc/rfc2163.txt delete mode 100644 doc/rfc/rfc2168.txt delete mode 100644 doc/rfc/rfc2181.txt delete mode 100644 doc/rfc/rfc2230.txt delete mode 100644 doc/rfc/rfc2308.txt delete mode 100644 doc/rfc/rfc2317.txt delete mode 100644 doc/rfc/rfc2373.txt delete mode 100644 doc/rfc/rfc2374.txt delete mode 100644 doc/rfc/rfc2375.txt delete mode 100644 doc/rfc/rfc2418.txt delete mode 100644 doc/rfc/rfc2535.txt delete mode 100644 doc/rfc/rfc2536.txt delete mode 100644 doc/rfc/rfc2537.txt delete mode 100644 doc/rfc/rfc2538.txt delete mode 100644 doc/rfc/rfc2539.txt delete mode 100644 doc/rfc/rfc2540.txt delete mode 100644 doc/rfc/rfc2541.txt delete mode 100644 doc/rfc/rfc2553.txt delete mode 100644 doc/rfc/rfc2671.txt delete mode 100644 doc/rfc/rfc2672.txt delete mode 100644 doc/rfc/rfc2673.txt delete mode 100644 doc/rfc/rfc2782.txt delete mode 100644 doc/rfc/rfc2825.txt delete mode 100644 doc/rfc/rfc2826.txt delete mode 100644 doc/rfc/rfc2845.txt delete mode 100644 doc/rfc/rfc2874.txt delete mode 100644 doc/rfc/rfc2915.txt delete mode 100644 doc/rfc/rfc2929.txt delete mode 100644 doc/rfc/rfc2930.txt delete mode 100644 doc/rfc/rfc2931.txt delete mode 100644 doc/rfc/rfc3007.txt delete mode 100644 doc/rfc/rfc3008.txt delete mode 100644 doc/rfc/rfc3071.txt delete mode 100644 doc/rfc/rfc3090.txt delete mode 100644 doc/rfc/rfc3110.txt delete mode 100644 doc/rfc/rfc3123.txt delete mode 100644 doc/rfc/rfc3152.txt delete mode 100644 doc/rfc/rfc3197.txt delete mode 100644 doc/rfc/rfc3225.txt delete mode 100644 doc/rfc/rfc3226.txt delete mode 100644 doc/rfc/rfc3258.txt delete mode 100644 doc/rfc/rfc3363.txt delete mode 100644 doc/rfc/rfc3364.txt delete mode 100644 doc/rfc/rfc3425.txt delete mode 100644 doc/rfc/rfc3445.txt delete mode 100644 doc/rfc/rfc3467.txt delete mode 100644 doc/rfc/rfc3490.txt delete mode 100644 doc/rfc/rfc3491.txt delete mode 100644 doc/rfc/rfc3492.txt delete mode 100644 doc/rfc/rfc3493.txt delete mode 100644 doc/rfc/rfc3513.txt delete mode 100644 doc/rfc/rfc3596.txt delete mode 100644 doc/rfc/rfc3597.txt delete mode 100644 doc/rfc/rfc3645.txt delete mode 100644 doc/rfc/rfc3655.txt delete mode 100644 doc/rfc/rfc3658.txt delete mode 100644 doc/rfc/rfc3755.txt delete mode 100644 doc/rfc/rfc3757.txt delete mode 100644 doc/rfc/rfc3833.txt delete mode 100644 doc/rfc/rfc3845.txt delete mode 100644 doc/rfc/rfc3901.txt delete mode 100644 doc/rfc/rfc4025.txt delete mode 100644 doc/rfc/rfc4033.txt delete mode 100644 doc/rfc/rfc4034.txt delete mode 100644 doc/rfc/rfc4035.txt delete mode 100644 doc/rfc/rfc4074.txt delete mode 100644 doc/rfc/rfc4159.txt delete mode 100644 doc/rfc/rfc4193.txt delete mode 100644 doc/rfc/rfc4255.txt delete mode 100644 doc/rfc/rfc4294.txt delete mode 100644 doc/rfc/rfc4339.txt delete mode 100644 doc/rfc/rfc4343.txt delete mode 100644 doc/rfc/rfc4367.txt delete mode 100644 doc/rfc/rfc4398.txt delete mode 100644 doc/rfc/rfc4408.txt delete mode 100644 doc/rfc/rfc4431.txt delete mode 100644 doc/rfc/rfc4470.txt delete mode 100644 doc/rfc/rfc4471.txt delete mode 100644 doc/rfc/rfc4472.txt delete mode 100644 doc/rfc/rfc4509.txt delete mode 100644 doc/rfc/rfc4634.txt delete mode 100644 doc/rfc/rfc4635.txt delete mode 100644 doc/rfc/rfc4641.txt delete mode 100644 doc/rfc/rfc4648.txt delete mode 100644 doc/rfc/rfc4697.txt delete mode 100644 doc/rfc/rfc4701.txt delete mode 100644 doc/rfc/rfc4892.txt delete mode 100644 doc/rfc/rfc4955.txt delete mode 100644 doc/rfc/rfc4956.txt delete mode 100644 doc/rfc/rfc5001.txt delete mode 100644 doc/rfc/rfc5011.txt delete mode 100644 doc/rfc/rfc5155.txt delete mode 100644 doc/rfc/rfc5205.txt delete mode 100644 doc/rfc/rfc5452.txt delete mode 100644 doc/rfc/rfc5507.txt delete mode 100644 doc/rfc/rfc5625.txt delete mode 100644 doc/rfc/rfc5702.txt delete mode 100644 doc/rfc/rfc5933.txt delete mode 100644 doc/rfc/rfc5936.txt delete mode 100644 doc/rfc/rfc5952.txt delete mode 100644 doc/rfc/rfc5966.txt delete mode 100644 doc/rfc/rfc6052.txt delete mode 100644 doc/rfc/rfc6147.txt delete mode 100644 doc/rfc/rfc6168.txt delete mode 100644 doc/rfc/rfc6303.txt delete mode 100644 doc/rfc/rfc6605.txt delete mode 100644 doc/rfc/rfc6672.txt delete mode 100644 doc/rfc/rfc6698.txt delete mode 100644 doc/rfc/rfc6742.txt delete mode 100644 doc/rfc/rfc6840.txt delete mode 100644 doc/rfc/rfc6844.txt delete mode 100644 doc/rfc/rfc6891.txt delete mode 100644 doc/rfc/rfc7043.txt delete mode 100644 doc/rfc/rfc7314.txt delete mode 100644 doc/rfc/rfc7477.txt delete mode 100644 doc/rfc/rfc7534.txt delete mode 100644 doc/rfc/rfc7535.txt delete mode 100644 doc/rfc/rfc7766.txt delete mode 100644 doc/rfc/rfc7793.txt delete mode 100644 doc/rfc/rfc7828.txt delete mode 100644 doc/rfc/rfc7830.txt delete mode 100644 doc/rfc/rfc7873.txt delete mode 100644 doc/rfc/rfc8020.txt delete mode 100644 doc/rfc/rfc8080.txt delete mode 100644 doc/rfc/rfc952.txt diff --git a/doc/draft/draft-faltstrom-uri-08.txt b/doc/draft/draft-faltstrom-uri-08.txt deleted file mode 100644 index 388cce39fb..0000000000 --- a/doc/draft/draft-faltstrom-uri-08.txt +++ /dev/null @@ -1,646 +0,0 @@ - - - -Network Working Group P. Faltstrom -Internet-Draft Netnod -Updates: 3404, 3959 (if approved) O. Kolkman -Intended status: Standards Track NLnet Labs -Expires: January 04, 2014 July 5, 2013 - - The Uniform Resource Identifier (URI) DNS Resource Record - draft-faltstrom-uri-08 - -Abstract - - This document defines a new DNS resource record, called the Uniform - Resource Identifier (URI) RR, for publishing mappings from hostnames - to URIs. - - This document updates RFC 3958 and RFC 3404. - -Status of this Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on January 04, 2014. - -Copyright Notice - - Copyright (c) 2013 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents (http://trustee.ietf.org/ - license-info) in effect on the date of publication of this document. - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. Code Components - extracted from this document must include Simplified BSD License text - - - - - - - - -Faltstrom & Kolkman Expires January 04, 2014 [Page 1] - -Internet-Draft URI Resource Record July 2013 - - as described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Simplified BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 - 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 3 - 4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 3 - 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4 - 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 - 5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 5 - 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 6.1. Homepage at one domain, but two domains in use . . . . . . 6 - 7. Relation to S-NAPTR . . . . . . . . . . . . . . . . . . . . . 6 - 8. Relation to U-NAPTR . . . . . . . . . . . . . . . . . . . . . 6 - 9. Relation to SRV . . . . . . . . . . . . . . . . . . . . . . . 7 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 10.1. Registration of the URI Resource Record Type . . . . . . 7 - 10.2. Registration of services . . . . . . . . . . . . . . . . 7 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 8 - 13.2. Non-normative references . . . . . . . . . . . . . . . . 8 - Appendix A. The original RRTYPE Allocation Request . . . . . . . . 9 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 - -1. Introduction - - This document explains the use of the Domain Name System (DNS) for - the storage of URIs, and how to resolve hostnames to such URIs that - can be used by various applications. For resolution the application - need to know both the hostname and the protocol that the URI is to be - used for. The protocol is registered by IANA. - - Currently, looking up URIs given a hostname uses the DDDS [RFC3401] - application framework with the DNS as a database as specified in RFC - 3404 [RFC3404]. This has a number of implications such as the - inability to select what NAPTR records that match the query are - interesting. The RRSet returned will always consist of all URIs - "connected" with the domain in question. - - The URI resource record specified in this document enables the - querying party to select which ones of the NAPTR records one is - interested in. This because data in the service field of the NAPTR - record is included in the owner part of the URI resource record type. - - - - - -Faltstrom & Kolkman Expires January 04, 2014 [Page 2] - -Internet-Draft URI Resource Record July 2013 - - - Querying for URI resource records is not replacing querying for NAPTR - resource records (or use of S-NAPTR [RFC3958]). Instead, the URI - resource record type provides a complementary mechanism to use when - one already knows what service field is interesting. With it, one - can directly query for the specific subset of the otherwise possibly - large RRSet given back when querying for NAPTR resource records. - - This document updates RFC 3958 and RFC 3404 by adding the flag "D" to - the list of defined terminal flags in section 2.2.3 of RFC 3958 and - 4.3 of RFC 3404. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, RFC 2119 - [RFC2119]. - -2. Applicability Statement - - In general, it is expected that URI records will be used by clients - for applications where the relevant protocol to be used is known, - but, for example, an extra abstraction is needed in order to separate - a domain name from a point of service (as addressed by the URI). One - example of such a situation is when an organisation has many domain - names, but only one official web page. - - Applications MUST know the specific service fields to prepend the - hostname with. Using repetitive queries for URI records MUST NOT be - a replacement for querying for NAPTR records according to the NAPTR - (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to - discover the various services and URIs for looking up access points - for a given service. Those are two very different kinds of needs. - -3. DNS considerations - - Using prefix labels, such as underscored service tags, prevents the - use of wildcards, as constructs as _s2._s1.*.example.net. are not - possible in the DNS, see RFC 4592 [RFC4592]. Besides, underscored - service tags used for the URI RR (based on the NAPTR service - descriptions) may have slightly different semantics than service tags - used for underscored prefix labels that are used in combination with - other (yet unspecified) RR types. This may cause subtle management - problems when delegation structure that has developed within the - context of URI RRs is also to be used for other RR types. Since the - service labels might be overloaded, applications should carefully - check that the application level protocol is indeed the protocol they - expect. - - Subtle management issues may also arise when the delegations from - service to sub service label involves several parties and different - stake holders. - -4. The format of the URI RR - - -Faltstrom & Kolkman Expires January 04, 2014 [Page 3] - -Internet-Draft URI Resource Record July 2013 - - - This is the presentation format of the URI RR: - - - Ownername TTL Class URI Priority Weight Target - - - The URI RR does not cause any kind of Additional Section processing. - -4.1. Ownername, class and type - - The URI ownername is subject to special conventions. - - Just like the SRV RR [RFC2782] the URI RR has service information - encoded in its ownername. In order to encode the service for a - specific owner name one uses service parameters. Valid service - parameters used are those used for SRV resource records, or - registered by IANA for Enumservice Registrations. The Enumservice - Registration parameters are reversed (subtype(s) before type), - prepended with an underscore (_) and prepended to the owner name in - separate labels. The underscore is prepended to the service - parameters to avoid collisions with DNS labels that occur in nature, - and the order is reversed to make it possible to do delegations, if - needed, to different zones (and therefore providers of DNS). - - It should be noted that the usage of a prefix must be described in - detail in for example the Enumservice Registration documentation, or - in a specific document that clarifies potential overload of - parameters in the same URI. Specifically, registered URI schemes are - not automatically acceptable as a service. With the HTTP scheme, one - can for example have multiple methods (GET, PUT, etc), and this with - the same URI. - - For example, suppose we are looking for the URI for a service with - Service Parameter "A:B:C" for host example.com.. Then we would query - for (QNAME,QTYPE)=("_C._B._A.example.com","URI") - - The type number for the URI record is 256. - - The URI resource record is class independent. - - The URI RR has no special TTL requirements. - -4.2. Priority - - The priority of the target URI in this RR. Its range is 0-65535. A - client MUST attempt to contact the URI with the lowest-numbered - priority it can reach; URIs with the same priority SHOULD be tried in - - - - - - - -Faltstrom & Kolkman Expires January 04, 2014 [Page 4] - -Internet-Draft URI Resource Record July 2013 - - the order defined by the weight field. - -4.3. Weight - - A server selection mechanism. The weight field specifies a relative - weight for entries with the same priority. Larger weights SHOULD be - given a proportionately higher probability of being selected. The - range of this number is 0-65535. - -4.4. Target - - The URI of the target, enclosed in double-quote characters ('"'). - Resolution of the URI is according to the definitions for the Scheme - of the URI. - - Since the URI will not be encoded as a (see - RFC1035 section 3.3 [RFC1035]) there is no 255 character size - limitation. - -4.5. URI RDATA Wire Format - - The RDATA for a URI RR consists of a 2 octet Priority field, a two - octet Weight field, and a variable length target field. - - Priority and Weight are unsigned integers in network byte order. - - The remaining data in the RDATA contains the Target field. The - Target field contains the URI as a sequence of octets (without the - enclosing double- quote characters used in the presentation format). - - The Target field can also contain an IRI, but with the additional - requirements that it are in UTF-8 [RFC3629], and the requirement that - it be possible to convert to a URI according to section 3.1 of RFC - 3987 [RFC3987] and back again to an IRI according to section 3.2. - Other character sets than UTF-8 are not allowed. The domain name - part of the IRI can be either an U-LABEL or A-LABEL as defined in RFC - 5890 [RFC5890]. - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Priority | Weight | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Target / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -5. Definition of the flag 'D' for NAPTR records - - - - -Faltstrom & Kolkman Expires January 04, 2014 [Page 5] - -Internet-Draft URI Resource Record July 2013 - - - This document specifies the flag "D" for use as a flag in NAPTR - records. The flag indicate a terminal NAPTR record because it - denotes the end of the DDDS/NAPTR processing rules. In the case of a - "D" flag, the Replacement field in the NAPTR record, prepended with - the service flags, is used as the Owner of a DNS query for URI - records, and normal URI processing as defined in this document is - applied. - - The replacement field MUST NOT include any of the service parameters. - Those are to be prepended (together with underscore) as described in - other places in this document. - - The Regexp field in the NAPTR record MUST be empty when the 'D' flag - is in use. - -6. Examples - -6.1. Homepage at one domain, but two domains in use - - An organisation has the domain names example.com and example.net, but - the official URI http://www.example.com/. Given the service type - "web" and subtype "http" (from the IANA registry), the following URI - Resource Records could be made available in the respective zones - (example.com and example.net): - - - $ORIGIN example.com. - _http._web IN URI 10 1 "http://www.example.com/" - - $ORIGIN example.net. - _http._web IN URI 10 1 "http://www.example.com/" - - -7. Relation to S-NAPTR - - The URI resource record type is not a replacement for the S-NAPTR. - It is instead an extension and the seond step of the S-NAPTR - resolution can resolve a URI resource record instead of using SRV - records and yet another algorithm for how to use SRV records for the - specific protocol. - - - $ORIGIN example.com. - ;; order pref flags - IN NAPTR 100 10 "s" "EM:ProtA" ( ; service - "" ; regexp - _ProtA._tcp.example.com. ; replacement - _ProtA._tcp IN URI "schemeA:service.example.com/example" - - -8. Relation to U-NAPTR - - - -Faltstrom & Kolkman Expires January 04, 2014 [Page 6] - -Internet-Draft URI Resource Record July 2013 - - - The URI Resource Record Type, together with S-NAPTR, can be viewed as - a replacement for U-NAPTR [RFC4848]. The URI Resource Record Type is - though only interesting when one know a base domain name, a protocol - and service so that one can compose the record to look up. NAPTR - records of any kind are used to look up what services exists for a - certain domain, which is one step before the URI resource record is - used. - -9. Relation to SRV - - The URI Resource Record Type can be viewed as a replacement for the - SRV record. This because it like the SRV record can only be looked - up if one know the base domain, the protocol and the service. It has - a similar functionality, but instead of returning a hostname and port - number, the URI record return a full URI. As such, it can be viewed - as a more powerful resource record than SRV. - -10. IANA Considerations - -10.1. Registration of the URI Resource Record Type - - After an expert review in February 2011 (see Appendix Appendix A) - IANA has allocated RRTYPE 256 for the URI Resource Record Type in the - registry named Resource Record (RR) TYPEs and QTYPEs as defined in - BCP 42 (at the time RFC 6195 [RFC6195]), located at http:// - www.iana.org/assignments/dns-parameters. - - IANA is requested to update the reference with that registration to - this RFC. - -10.2. Registration of services - - No new registry is needed for the registration of services as the - Enumservice Registrations registry is used also for the URI resource - record type. - -11. Security Considerations - - The authors do not believe this resource record cause any new - security problems. Deployment must though be done in a proper way as - misconfiguration of this resource record might make it impossible to - reach the service that was originally intended to be accessed. - - Using the URI resource record together with security mechanisms that - relies on verification of authentication of hostnames, like TLS, - makes it important to choose the correct domain name when doing the - comparison. - - The basic mechanism works as follows: - - 1. Announce the fact example.com is hosted at example.org (with - some URL) in DNS - 2. Secure the URI resource record with DNSSEC. - -Faltstrom & Kolkman Expires January 04, 2014 [Page 7] - -Internet-Draft URI Resource Record July 2013 - - 3. Verify the TLS (for example) certificate for the connection to - example.org matches, i.e. use the hostname in the URI and not - the hostname used originally when looking up the URI resource - record. - 4. If needed, do application layer authentication etc over the then - encrypted connection. - - What also can happen is that the URI in the resource record type has - errors in it. Applications using the URI resource record type for - resolution should behave similarly as if the user typed (or copy and - pasted) the URI. At least it must be clear to the user that the error - is not due to any error from his side. - - One SHOULD NOT include userinfo (see User Information, Section 3.2.1, - in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record - as DNS data must be viewed as publicly available information. - -12. Acknowledgements - - Ideas on how to split the two different kind of queries "What - services exists for this domain name" and "What is the URI for this - service" came from Scott Bradner and Lawrence Conroy. Other people - that have contributed to this document include Richard Barnes, Leslie - Daigle, Olafur Gudmundsson, Ted Hardie, Peter Koch, Penn Pfautz, and - Willem Toorop. - -13. References - -13.1. Normative References - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application - Service Location Using SRV RRs and the Dynamic Delegation - Discovery Service (DDDS)", RFC 3958, January 2005. - - [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource - Identifiers (IRIs)", RFC 3987, January 2005. - - [RFC5890] Klensin, J., "Internationalized Domain Names for - Applications (IDNA): Definitions and Document Framework", - RFC 5890, August 2010. - - [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA - Considerations", BCP 42, RFC 6195, March 2011. - -13.2. Non-normative references - -Faltstrom & Kolkman Expires January 04, 2014 [Page 8] - -Internet-Draft URI Resource Record July 2013 - - - [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) - Part One: The Comprehensive DDDS", RFC 3401, October 2002. - - [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) - Part Three: The Domain Name System (DNS) Database", RFC - 3403, October 2002. - - [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) - Part Four: The Uniform Resource Identifiers (URI)", RFC - 3404, October 2002. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, RFC - 3986, January 2005. - - [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name - System", RFC 4592, July 2006. - - [RFC4848] Daigle, L., "Domain-Based Application Service Location - Using URIs and the Dynamic Delegation Discovery Service - (DDDS)", RFC 4848, April 2007. - - [RFC5507] IAB, Faltstrom, P., Austein, R. and P. Koch, "Design - Choices When Expanding the DNS", RFC 5507, April 2009. - -Appendix A. The original RRTYPE Allocation Request - - On February 22, 2011 IANA assigned RRTYPE 256 for the URI resource - record based on a request that followed the procedure documented in - RFC 6195 [RFC6195]. The DNS RRTYPE PARAMETER ALLOCATION form as - submitted to IANA at thet time is replicated below for reference. - - A. Submission Date: - - May 23, 2009 - - B. Submission Type: - - [X] New RRTYPE - [ ] Modification to existing RRTYPE - - C. Contact Information for submitter: - - Name: Patrik Faltstrom - Email Address: paf@cisco.com - International telephone number: +46-8-6859131 - -Faltstrom & Kolkman Expires January 04, 2014 [Page 9] - -Internet-Draft URI Resource Record July 2013 - - Other contact handles: - (Note: This information will be publicly posted.) - - D. Motivation for the new RRTYPE application? - - There is no easy way to get from a domain name to a URI (or - IRI). Some mechanisms exists via use of the NAPTR [RFC3403] - resource record. That implies quite complicated rules that are - simplified via the S-NAPTR [RFC3958] specification. But, the - ability to directly look up a URI still exists. This - specification uses a prefix based naming mechanism originated in - the definition of the SRV [RFC2782] resource record, and the - RDATA is a URI, encoded as one text field. - - See also above (Section 1). - - E. Description of the proposed RR type. - - The format of the URI resource record is as follows: - - - Ownername TTL Class URI Priority Weight Target - - - The URI RR has service information encoded in its ownername. In - order to encode the service for a specific owner name one uses - service parameters. Valid service parameters used are either - Enumservice Registrations registered by IANA, or prefixes used - for the SRV resource record. - - The wire format of the RDATA is as follows: - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Priority | Weight | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Target / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - F. What existing RRTYPE or RRTYPEs come closest to filling that - need and why are they unsatisfactory? - - - - - - - - - -Faltstrom & Kolkman Expires January 04, 2014 [Page 10] - -Internet-Draft URI Resource Record July 2013 - - The RRTYPE that come closest is the NAPTR resource record. It - is for example used in the DDDS and S-NAPTR algorithms. The - main problem with the NAPTR is that selection of what record (or - records) one is interested in is based on data stored in the - RDATA portion of the NAPTR resource record. This, as explained - in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, - most applications using NAPTR resource records uses regular - expression based rewrite rules for creation of the URI, and that - has shown be complicated to implement. - - The second closest RRTYPE is the SRV record that given a - prefixed based naming just like is suggested for the URI - resource record, one get back a port number and domain name. - This can also be used for creation of a URI, but, only URIs - without path components. - - G. What mnemonic is requested for the new RRTYPE (optional)? - - URI - - H. Does the requested RRTYPE make use of any existing IANA Registry - or require the creation of a new IANA sub-registry in DNS - Parameters? - - Yes, partially. - - One of the mechanisms to select a service is to use the - Enumservice Registry managed by IANA. Another is to use services - and protocols used for SRV records. - - I. Does the proposal require/expect any changes in DNS servers/ - resolvers that prevent the new type from being processed as an - unknown RRTYPE (see [RFC3597])? - - No - - J. Comments: - - None - - -Authors' Addresses - - Patrik Faltstrom - Netnod - - Email: paf@netnod.se - - - Olaf Kolkman - NLnet Labs - - Email: olaf@NLnetLabs.nl - -Faltstrom & Kolkman Expires January 04, 2014 [Page 11] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-08.txt b/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-08.txt deleted file mode 100644 index 15e51522fc..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-08.txt +++ /dev/null @@ -1,448 +0,0 @@ - - - -DNS Extensions Working Group S. Rose -Internet-Draft NIST -Updates: 2536, 2539, 3110, 4034, 4398, May 26, 2011 -5155, 5702, 5933 (if approved) -Intended status: Standards Track -Expires: November 27, 2011 - - - Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA - Registry - draft-ietf-dnsext-dnssec-registry-fixes-08 - -Abstract - - The DNS Security Extensions (DNSSEC) requires the use of - cryptographic algorithm suites for generating digital signatures over - DNS data. There is currently an IANA registry for these algorithms - that is incomplete in that it lacks the implementation status of each - algorithm. This document provides an applicability statement on - algorithm implementation compliance status for DNSSEC - implementations. This status is to measure compliance to this RFC - only. This document replaces that registry table with a new IANA - registry table for Domain Name System Security (DNSSEC) Algorithm - Numbers that lists (or assigns) each algorithm's status based on the - current reference. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on November 27, 2011. - -Copyright Notice - - Copyright (c) 2011 IETF Trust and the persons identified as the - document authors. All rights reserved. - - - - -Rose Expires November 27, 2011 [Page 1] - -Internet-Draft IANA Registry Fixes May 2011 - - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 - - 2. The DNS Security Algorithm Number Sub-registry . . . . . . . . 3 - 2.1. Updates and Additions . . . . . . . . . . . . . . . . . . . 4 - 2.2. Domain Name System (DNS) Security Algorithm Number - Registry Table . . . . . . . . . . . . . . . . . . . . . . 5 - 2.3. Specifying New Algorithms and Updating Status of - Existing Entries . . . . . . . . . . . . . . . . . . . . . 6 - - 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 - - 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - - 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 - - - - - - - - - - - - - - - - - - - - - - - - -Rose Expires November 27, 2011 [Page 2] - -Internet-Draft IANA Registry Fixes May 2011 - - -1. Introduction - - The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033], - [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702] uses - digital signatures over DNS data to provide source authentication and - integrity protection. DNSSEC uses an IANA registry to list codes for - digital signature algorithms (consisting of a cryptographic algorithm - and one-way hash function). - - The original list of algorithm status is found in [RFC4034]. Other - DNSSEC RFC's have added new algorithms or changed the status of - algorithms in the registry. However, implementers must read through - all the documents in order to discover which algorithms are - considered wise to implement, which are not, and which algorithms may - become widely used in the future. This document replaces the - original list with a new table that includes the current compliance - status for certain algorithms. - - This compliance status indication is only to be considered for - implementation, not deployment or operations. Operators are free to - deploy any digital signature algorithm available in implementations - or algorithms chosen by local security policies. This status is to - measure compliance to this RFC only. - - This document replaces the current IANA registry for Domain Name - System Security (DNSSEC) Algorithm Numbers with a newly defined - registry table. This new table (Section 2.2 below) contains a column - that will list the current compliance status of each digital - signature algorithm in the registry at the time of writing and - assigns status for some algorithms used with DNSSEC that did not have - an identified status in their specification. This document updates - the following: [RFC2536], [RFC2539], [RFC3110], [RFC4034], [RFC4398], - [RFC5155], [RFC5702], and [RFC5933]. - -1.1. Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -2. The DNS Security Algorithm Number Sub-registry - - The DNS Security Algorithm Number sub-registry (part of the Domain - Name System (DNS) Security Number registry) will be replaced with the - table below. This table is based on the existing DNS Security - Algorithm Number sub-registry and adds a column that contains the - current implementation status of the given algorithm. - - - - -Rose Expires November 27, 2011 [Page 3] - -Internet-Draft IANA Registry Fixes May 2011 - - - There are additional differences to entries that are described in - sub-section 2.1. The overall new registry table is in sub-section - 2.2. The values for the compliance status were obtained from - [RFC4034] with updates for algorithms specified after the original - DNSSEC specification. If no status was listed in the original - specification, this document assigns one. - -2.1. Updates and Additions - - This document updates three entries in the Domain Name System - Security (DNSSEC) Algorithm Registry. They are: - - The description for assignment number 4 is changed to "Reserved until - 2020". - - The description for assignment number 9 is changed to "Reserved until - 2020". - - The description for assignment number 11 is changed to "Reserved - until 2020". - - Registry entries 13-251 remains Unassigned. - - The status of RSASHA1-NSEC3-SHA1 is set to RECOMMENDED TO IMPLEMENT. - This is due to the fact that RSA/SHA-1 is a MUST IMPLEMENT. The - status of RSA/SHA-256 and RSA/SHA-512 are also set to RECOMMENDED TO - IMPLEMENT as it is believed that these algorithms will replace an - older algorithm (e.g. RSA/SHA-1) that have a perceived weakness in - its hash algorithm (SHA-1). - - - - - - - - - - - - - - - - - - - - - - -Rose Expires November 27, 2011 [Page 4] - -Internet-Draft IANA Registry Fixes May 2011 - - -2.2. Domain Name System (DNS) Security Algorithm Number Registry Table - - The Domain Name System (DNS) Security Algorithm Number registry is - hereby specified as follows below. The new column is titled - "Compliance to RFC TBD" (where TBD will change when published) as the - IANA Registry table is not normative. The IANA registry table is - only a reflection of the RFC, which is normative. - - Trans- - Zone action Compliance to - Number Description Mnemonic Sign Sign RFC TBD1 Reference - ------ ----------- ------ ---- ----- ------------ --------- - 0 Reserved [RFC4398] - 1 RSA/MD5 RSAMD5 N Y MUST NOT [RFC2537] - IMPLEMENT - 2 Diffie-Hellman DH N Y [RFC2539] - 3 DSA/SHA-1 DSASHA1 Y Y [RFC2536] - 4 Reserved until - 2020 - 5 RSA/SHA-1 RSASHA1 Y Y MUST [RFC3110] - IMPLEMENT - 6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y [RFC5155] - -SHA1 - 7 RSASHA1-NSEC3 RSASHA1- Y Y RECOMMENDED [RFC5155] - -SHA1 NSEC3- TO IMPLEMENT - SHA1 - 8 RSA/SHA-256 RSASHA256 Y * RECOMMENDED [RFC5702] - TO IMPLEMENT - 9 Reserved until - 2020 - 10 RSA/SHA-512 RSASHA512 Y * RECOMMENDED [RFC5702] - TO IMPLEMENT - 11 Reserved until - 2020 - 12 GOST R GOST-ECC Y * [RFC5933] - 34.10-2001 - 13-251 Unassigned - 252 Reserved for INDIRECT N N [RFC4034] - Indirect keys - 253 private PRIVATE Y Y [RFC4034] - algorithm - 254 private PRIVATEOID Y Y [RFC4034] - algorithm OID - 255 Reserved - - Table rows where the compliance column is not filled in are left to - the discretion of implementers. Their implementation (or lack - thereof) therefore cannot be included when judging compliance to this - - - -Rose Expires November 27, 2011 [Page 5] - -Internet-Draft IANA Registry Fixes May 2011 - - - document. - -2.3. Specifying New Algorithms and Updating Status of Existing Entries - - [RFC6014] establishes a parallel procedure for adding a registry - entry for a new algorithm other than a standards track document. - Algorithms entered into the registry using that procedure do not have - a listed compliance status. Specifications that follow this path do - not need to obsolete or update this document. - - Adding a newly specified algorithm to the registry with a compliance - status SHALL entail obsolescing this document and replacing the - registry table (with the new algorithm entry). Altering the status - column value of any existing algorithm in the registry SHALL entail - obsoleting this document and replacing the registry table. - - This document cannot be updated, only made obsolete and replaced by a - successor document. - -3. IANA Considerations - - This document replaces the Domain Name System (DNS) Security - Algorithm Numbers registry. The new registry table is in Section - 2.2. In the column "Compliance to RFC TBD", "RFC TBD" should be - changed to the official RFC when published. - - The original Domain Name System (DNS) Security Algorithm Number - registry is available at - http://www.iana.org/assignments/dns-sec-alg-numbers. - -4. Security Considerations - - This document replaces the Domain Name System (DNS) Security - Algorithm Numbers registry. It is not meant to be a discussion on - algorithm superiority. No new security considerations are raised in - this document. - -5. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. - - [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name - System (DNS)", RFC 2537, March 1999. - - - - -Rose Expires November 27, 2011 [Page 6] - -Internet-Draft IANA Registry Fixes May 2011 - - - [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the - Domain Name System (DNS)", RFC 2539, March 1999. - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name - System (DNS)", RFC 4398, March 2006. - - [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer - (DS) Resource Records (RRs)", RFC 4509, May 2006. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - - [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY - and RRSIG Resource Records for DNSSEC", RFC 5702, - October 2009. - - [RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST - Signature Algorithms in DNSKEY and RRSIG Resource Records - for DNSSEC", RFC 5933, July 2010. - - [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier - Allocation for DNSSEC", RFC 6014, November 2010. - - - - - - - - - - - - - -Rose Expires November 27, 2011 [Page 7] - -Internet-Draft IANA Registry Fixes May 2011 - - -Author's Address - - Scott Rose - NIST - 100 Bureau Dr. - Gaithersburg, MD 20899 - USA - - Phone: +1-301-975-8439 - EMail: scottr.nist@gmail.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rose Expires November 27, 2011 [Page 8] - diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-10.txt b/doc/draft/draft-ietf-dnsext-ecc-key-10.txt deleted file mode 100644 index db0aa3a989..0000000000 --- a/doc/draft/draft-ietf-dnsext-ecc-key-10.txt +++ /dev/null @@ -1,928 +0,0 @@ - -INTERNET-DRAFT Richard C. Schroeppel -Intended status: Proposed Standard Donald E. Eastlake 3rd -Expires: August 2007 March 2007 - - - - Elliptic Curve Keys and Signatures in the Domain Name System (DNS) - -------- ----- ---- --- ---------- -- --- ------ ---- ------ ----- - - - Richard C. Schroeppel - Donald Eastlake 3rd - - -Status of This Document - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Distribution of this document is unlimited. Comments should be sent - to the DNS mailing list . - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Abstract - - The standard format for storing elliptic curve cryptographic keys and - elliptic curve SHA-1 based signatures in the Domain Name System (DNS) - is specified. - - - - - - - - - -R. Schroeppel, et al [Page 1] - - -INTERNET-DRAFT ECC in the DNS - - -Acknowledgement - - The assistance of Hilarie K. Orman in the production of this document - is greatfully acknowledged. - - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Acknowledgement............................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. Elliptic Curve Keys in Resource Records.................3 - 3. The Elliptic Curve Equation.............................9 - 4. How do I Compute Q, G, and Y?..........................10 - 5. Elliptic Curve Signatures..............................11 - 6. Performance Considerations.............................13 - 7. Security Considerations................................13 - 8. IANA Considerations....................................13 - - Copyright and Additional IPR Provisions...................14 - - Informational References..................................15 - Normative Refrences.......................................15 - - Author's Addresses........................................16 - Expiration and File Name..................................16 - Disclaimer................................................16 - - - - - - - - - - - - - - - - - - - - -R. Schroeppel, et al [Page 2] - - -INTERNET-DRAFT ECC in the DNS - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information. [RFC1034] [RFC1035] The DNS stores data in - resource records and has been extended to include digital signatures - and cryptographic keys in some of these resource records. - - This document describes how to format elliptic curve cryptographic - (ECC) key and signature data in the DNS so they can be used for a - variety of purposes. The signatures use the SHA-1 eigest algorithm - [RFC3174]. Familiarity with ECC cryptography is assumed [Menezes]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - -2. Elliptic Curve Keys in Resource Records - - Elliptic curve public keys are stored, using the structure described - below, in the DNS within the RDATA portions of key RRs, such as RRKEY - [RFC4034] and IPSECKEY [RFC4025] RRs. - - The research world continues to work on the issue of which is the - best elliptic curve system, which finite field to use, and how to - best represent elements in the field. So, representations are - defined for every type of finite field, and every type of elliptic - curve. The reader should be aware that there is a unique finite - field with a particular number of elements, but many possible - representations of that field and its elements. If two different - representations of a field are given, they are interconvertible with - a tedious but practical precomputation, followed by a fast - computation for each field element to be converted. It is perfectly - reasonable for an algorithm to work internally with one field - representation, and convert to and from a different external - representation. - - - - - - - - - - - - - - -R. Schroeppel, et al [Page 3] - - -INTERNET-DRAFT ECC in the DNS - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |S M -FMT- A B Z| - +-+-+-+-+-+-+-+-+ - | LP | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | P (length determined from LP) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LF | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | F (length determined from LF) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEG | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEGH | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEGI | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEGJ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TRDV | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |S| LH | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | H (length determined from LH) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |S| LK | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | K (length determined from LK) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Q (length determined from LQ) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LA | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | A (length determined from LA) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ALTA | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LB | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | B (length determined from LB) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | C (length determined from LC) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LG | - - -R. Schroeppel, et al [Page 4] - - -INTERNET-DRAFT ECC in the DNS - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | G (length determined from LG) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LY | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Y (length determined from LY) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - SMFMTABZ is a flags octet as follows: - - S = 1 indicates that the remaining 7 bits of the octet selects - one of 128 predefined choices of finite field, element - representation, elliptic curve, and signature parameters. - MFMTABZ are omitted, as are all parameters from LP through G. - LY and Y are retained. - - If S = 0, the remaining parameters are as in the picture and - described below. - - M determines the type of field underlying the elliptic curve. - - M = 0 if the field is a GF[2^N] field; - - M = 1 if the field is a (mod P) or GF[P^D] field with P>2. - - FMT is a three bit field describing the format of the field - representation. - - FMT = 0 for a (mod P) field. - > 0 for an extension field, either GF[2^D] or GF[P^D]. - The degree D of the extension, and the field polynomial - must be specified. The field polynomial is always monic - (leading coefficient 1.) - - FMT = 1 The field polynomial is given explicitly; D is implied. - - If FMT >=2, the degree D is given explicitly. - - = 2 The field polynomial is implicit. - = 3 The field polynomial is a binomial. P>2. - = 4 The field polynomial is a trinomial. - = 5 The field polynomial is the quotient of a trinomial by a - short polynomial. P=2. - = 6 The field polynomial is a pentanomial. P=2. - - Flags A and B apply to the elliptic curve parameters. - - - - - - -R. Schroeppel, et al [Page 5] - - -INTERNET-DRAFT ECC in the DNS - - - A = 1 When P>=5, the curve parameter A is negated. If P=2, then - A=1 indicates that the A parameter is special. See the - ALTA parameter below, following A. The combination A=1, - P=3 is forbidden. - - B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, - then B=1 indicates an alternate elliptic curve equation is - used. When P=2 and B=1, an additional curve parameter C - is present. - - The Z bit SHOULD be set to zero on creation of an RR and MUST be - ignored when processing an RR (when S=0). - - Most of the remaining parameters are present in some formats and - absent in others. The presence or absence of a parameter is - determined entirely by the flags. When a parameter occurs, it is in - the order defined by the picture. - - Of the remaining parameters, PFHKQABCGY are variable length. When - present, each is preceded by a one-octet length field as shown in the - diagram above. The length field does not include itself. The length - field may have values from 0 through 110. The parameter length in - octets is determined by a conditional formula: If LL<=64, the - parameter length is LL. If LL>64, the parameter length is 16 times - (LL-60). In some cases, a parameter value of 0 is sensible, and MAY - be represented by an LL value of 0, with the data field omitted. A - length value of 0 represents a parameter value of 0, not an absent - parameter. (The data portion occupies 0 space.) There is no - requirement that a parameter be represented in the minimum number of - octets; high-order 0 octets are allowed at the front end. Parameters - are always right adjusted, in a field of length defined by LL. The - octet-order is always most-significant first, least-significant last. - The parameters H and K may have an optional sign bit stored in the - unused high-order bit of their length fields. - - LP defines the length of the prime P. P must be an odd prime. The - parameters LP,P are present if and only if the flag M=1. If M=0, the - prime is 2. - - LF,F define an explicit field polynomial. This parameter pair is - present only when FMT = 1. The length of a polynomial coefficient is - ceiling(log2 P) bits. Coefficients are in the numerical range - [0,P-1]. The coefficients are packed into fixed-width fields, from - higher order to lower order. All coefficients must be present, - including any 0s and also the leading coefficient (which is required - to be 1). The coefficients are right justified into the octet string - of length specified by LF, with the low-order "constant" coefficient - at the right end. As a concession to storage efficiency, the higher - order bits of the leading coefficient may be elided, discarding high- - order 0 octets and reducing LF. The degree is calculated by - - -R. Schroeppel, et al [Page 6] - - -INTERNET-DRAFT ECC in the DNS - - - determining the bit position of the left most 1-bit in the F data - (counting the right most bit as position 0), and dividing by - ceiling(log2 P). The division must be exact, with no remainder. In - this format, all of the other degree and field parameters are - omitted. The next parameters will be LQ,Q. - - If FMT>=2, the degree of the field extension is specified explicitly, - usually along with other parameters to define the field polynomial. - - DEG is a two octet field that defines the degree of the field - extension. The finite field will have P^DEG elements. DEG is - present when FMT>=2. - - When FMT=2, the field polynomial is specified implicitly. No other - parameters are required to define the field; the next parameters - present will be the LQ,Q pair. The implicit field poynomial is the - lexicographically smallest irreducible (mod P) polynomial of the - correct degree. The ordering of polynomials is by highest-degree - coefficients first -- the leading coefficient 1 is most important, - and the constant term is least important. Coefficients are ordered - by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of - degree D is X^D (which is not irreducible). The next is X^D+1, which - is sometimes irreducible, followed by X^D-1, which isn$t. Assuming - odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + - X, X^D + X + 1, X^D + X - 1, etc. - - When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be - odd. The polynomial is determined by the degree and the low order - term K. Of all the field parameters, only the LK,K parameters are - present. The high-order bit of the LK octet stores on optional sign - for K; if the sign bit is present, the field polynomial is X^DEG - K. - - When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + - K. When P=2, the H and K parameters are implicitly 1, and are - omitted from the representation. Only DEG and DEGH are present; the - next parameters are LQ,Q. When P>2, then LH,H and LK,K are - specified. Either or both of LH, LK may contain a sign bit for its - parameter. - - When FMT=5, then P=2 (only). The field polynomial is the exact - quotient of a trinomial divided by a small polynomial, the trinomial - divisor. The small polynomial is right-adjusted in the two octet - field TRDV. DEG specifies the degree of the field. The degree of - TRDV is calculated from the position of the high-order 1 bit. The - trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If - DEGH is 0, the middle term is omitted from the trinomial. The - quotient must be exact, with no remainder. - - When FMT=6, then P=2 (only). The field polynomial is a pentanomial, - with the degrees of the middle terms given by the three 2-octet - - -R. Schroeppel, et al [Page 7] - - -INTERNET-DRAFT ECC in the DNS - - - values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + - X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI - > DEGJ > 0. - - DEGH, DEGI, DEGJ are two-octet fields that define the degree of - a term in a field polynomial. DEGH is present when FMT = 4, - 5, or 6. DEGI and DEGJ are present only when FMT = 6. - - TRDV is a two-octet right-adjusted binary polynomial of degree < - 16. It is present only for FMT=5. - - LH and H define the H parameter, present only when FMT=4 and P - is odd. The high bit of LH is an optional sign bit for H. - - LK and K define the K parameter, present when FMT = 3 or 4, and - P is odd. The high bit of LK is an optional sign bit for K. - - The remaining parameters are concerned with the elliptic curve and - the signature algorithm. - - LQ defines the length of the prime Q. Q is a prime > 2^159. - - In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data - member of the pair is an element from the finite field defined - earlier. The length field defines a long octet string. Field - elements are represented as (mod P) polynomials of degree < DEG, with - DEG or fewer coefficients. The coefficients are stored from left to - right, higher degree to lower, with the constant term last. The - coefficients are represented as integers in the range [0,P-1]. Each - coefficient is allocated an area of ceiling(log2 P) bits. The field - representation is right-justified; the "constant term" of the field - element ends at the right most bit. The coefficients are fitted - adjacently without regard for octet boundaries. (Example: if P=5, - three bits are used for each coefficient. If the field is GF[5^75], - then 225 bits are required for the coefficients, and as many as 29 - octets may be needed in the data area. Fewer octets may be used if - some high-order coefficients are 0.) If a flag requires a field - element to be negated, each non-zero coefficient K is replaced with - P-K. To save space, 0 bits may be removed from the left end of the - element representation, and the length field reduced appropriately. - This would normally only happen with A,B,C, because the designer - chose curve parameters with some high-order 0 coefficients or bits. - - If the finite field is simply (mod P), then the field elements are - simply numbers (mod P), in the usual right-justified notation. If - the finite field is GF[2^D], the field elements are the usual right- - justified polynomial basis representation. - - - - - -R. Schroeppel, et al [Page 8] - - -INTERNET-DRAFT ECC in the DNS - - - LA,A is the first parameter of the elliptic curve equation. - When P>=5, the flag A = 1 indicates A should be negated (mod - P). When P=2 (indicated by the flag M=0), the flag A = 1 - indicates that the parameter pair LA,A is replaced by the two - octet parameter ALTA. In this case, the parameter A in the - curve equation is x^ALTA, where x is the field generator. - Parameter A often has the value 0, which may be indicated by - LA=0 (with no A data field), and sometimes A is 1, which may - be represented with LA=1 and a data field of 1, or by setting - the A flag and using an ALTA value of 0. - - LB,B is the second parameter of the elliptic curve equation. - When P>=5, the flag B = 1 indicates B should be negated (mod - P). When P=2 or 3, the flag B selects an alternate curve - equation. - - LC,C is the third parameter of the elliptic curve equation, - present only when P=2 (indicated by flag M=0) and flag B=1. - - LG,G defines a point on the curve, of order Q. The W-coordinate - of the curve point is given explicitly; the Z-coordinate is - implicit. - - LY,Y is the user$s public signing key, another curve point of - order Q. The W-coordinate is given explicitly; the Z- - coordinate is implicit. The LY,Y parameter pair is always - present. - - - -3. The Elliptic Curve Equation - - (The coordinates of an elliptic curve point are named W,Z instead of - the more usual X,Y to avoid confusion with the Y parameter of the - signing key.) - - The elliptic curve equation is determined by the flag octet, together - with information about the prime P. The primes 2 and 3 are special; - all other primes are treated identically. - - If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 - + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. - If A and/or B is negative (i.e., in the range from P/2 to P), and - P>=5, space may be saved by putting the sign bit(s) in the A and B - bits of the flags octet, and the magnitude(s) in the parameter - fields. - - If M=1 and P=3, the B flag has a different meaning: it specifies an - alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of - the right-hand-side is different. When P=3, this equation is more - - -R. Schroeppel, et al [Page 9] - - -INTERNET-DRAFT ECC in the DNS - - - commonly used. - - If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + - A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A - parameter can often be 0 or 1, or be chosen as a single-1-bit value. - The flag B is used to select an alternate curve equation, Z^2 + C*Z = - W^3 + A*W + B. This is the only time that the C parameter is used. - - - -4. How do I Compute Q, G, and Y? - - The number of points on the curve is the number of solutions to the - curve equation, + 1 (for the "point at infinity"). The prime Q must - divide the number of points. Usually the curve is chosen first, then - the number of points is determined with Schoof$s algorithm. This - number is factored, and if it has a large prime divisor, that number - is taken as Q. - - G must be a point of order Q on the curve, satisfying the equation - - Q * G = the point at infinity (on the elliptic curve) - - G may be chosen by selecting a random [RFC4086] curve point, and - multiplying it by (number-of-points-on-curve/Q). G must not itself - be the "point at infinity"; in this astronomically unlikely event, a - new random curve point is recalculated. - - G is specified by giving its W-coordinate. The Z-coordinate is - calculated from the curve equation. In general, there will be two - possible Z values. The rule is to choose the "positive" value. - - In the (mod P) case, the two possible Z values sum to P. The smaller - value is less than P/2; it is used in subsequent calculations. In - GF[P^D] fields, the highest-degree non-zero coefficient of the field - element Z is used; it is chosen to be less than P/2. - - In the GF[2^N] case, the two possible Z values xor to W (or to the - parameter C with the alternate curve equation). The numerically - smaller Z value (the one which does not contain the highest-order 1 - bit of W (or C)) is used in subsequent calculations. - - Y is specified by giving the W-coordinate of the user$s public - signature key. The Z-coordinate value is determined from the curve - equation. As with G, there are two possible Z values; the same rule - is followed for choosing which Z to use. - - - - - - -R. Schroeppel, et al [Page 10] - - -INTERNET-DRAFT ECC in the DNS - - - During the key generation process, a random [RFC4086] number X must - be generated such that 1 <= X <= Q-1. X is the private key and is - used in the final step of public key generation where Y is computed - as - - Y = X * G (as points on the elliptic curve) - - If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 - in the (mod P) case, or the high-order non-zero coefficient of Z > - P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the - GF[2^N] case), then X must be replaced with Q-X. This will - correspond to the correct Z-coordinate. - - - -5. Elliptic Curve Signatures - - The signature portion of an RR RDATA area when using the ECC - algorithm, for example in the SIG and RRSIG [RFC4034] RRs is shown - below. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | R, (length determined from LQ) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | S, (length determined from LQ) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - R and S are integers (mod Q). Their length is specified by the LQ - field of the corresponding KEY RR and can also be calculated from the - SIG RR$s RDLENGTH. They are right justified, high-order-octet first. - The same conditional formula for calculating the length from LQ is - used as for all the other length fields above. - - The data signed is determined as specified in [RFC4034]. Then the - following steps are taken where Q, P, G, and Y are as specified in - the public key [Schneier]. For further information on SHA-1, see - [RFC3174]. - - hash = SHA-1 ( data ) - - Generate random [RFC4086] K such that 0 < K < Q. (Never sign - two different messages with the same K. K should be chosen - from a very large space: If an opponent learns a K value - for a single signature, the user$s signing key is - compromised, and a forger can sign arbitrary messages. - There is no harm in signing the same message multiple times - with the same key or different keys.) - - - -R. Schroeppel, et al [Page 11] - - -INTERNET-DRAFT ECC in the DNS - - - R = (the W-coordinate of ( K*G on the elliptic curve )) - interpreted as an integer, and reduced (mod Q). (R must - not be 0. In this astronomically unlikely event, generate - a new random K and recalculate R.) - - S = ( K^(-1) * (hash + X*R) ) mod Q. - - S must not be 0. In this astronomically unlikely event, - generate a new random K and recalculate R and S. - - If S > Q/2, set S = Q - S. - - The pair (R,S) is the signature. - - Another party verifies the signature as follows. For further - information on SHA-1, see [RFC3174]. - - Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a - valid EC sigature. - - hash = SHA-1 ( data ) - - Sinv = S^(-1) mod Q. - - U1 = (hash * Sinv) mod Q. - - U2 = (R * Sinv) mod Q. - - (U1 * G + U2 * Y) is computed on the elliptic curve. - - V = (the W-coordinate of this point) interpreted as an integer - and reduced (mod Q). - - The signature is valid if V = R. - - The reason for requiring S < Q/2 is that, otherwise, both (R,S) and - (R,Q-S) would be valid signatures for the same data. Note that a - signature that is valid for hash(data) is also valid for hash(data)+Q - or hash(data)-Q, if these happen to fall in the range [0,2^160-1]. - It$s believed to be computationally infeasible to find data that - hashes to an assigned value, so this is only a cosmetic blemish. The - blemish can be eliminated by using Q > 2^160, at the cost of having - slightly longer signatures, 42 octets instead of 40. - - We must specify how a field-element E ("the W-coordinate") is to be - interpreted as an integer. The field-element E is regarded as a - radix-P integer, with the digits being the coefficients in the - polynomial basis representation of E. The digits are in the ragne - [0,P-1]. In the two most common cases, this reduces to "the obvious - thing". In the (mod P) case, E is simply a residue mod P, and is - - -R. Schroeppel, et al [Page 12] - - -INTERNET-DRAFT ECC in the DNS - - - taken as an integer in the range [0,P-1]. In the GF[2^D] case, E is - in the D-bit polynomial basis representation, and is simply taken as - an integer in the range [0,(2^D)-1]. For other fields GF[P^D], it$s - necessary to do some radix conversion arithmetic. - - - -6. Performance Considerations - - Elliptic curve signatures use smaller moduli or field sizes than RSA - and DSA. Creation of a curve is slow, but not done very often. Key - generation is faster than RSA or DSA. - - DNS implementations have been optimized for small transfers, - typically less than 512 octets including DNS overhead. Larger - transfers will perform correctly and and extensions have been - standardized to make larger transfers more efficient [RFC2671]. - However, it is still advisable at this time to make reasonable - efforts to minimize the size of RR sets stored within the DNS - consistent with adequate security. - - - -7. Security Considerations - - Keys retrieved from the DNS should not be trusted unless (1) they - have been securely obtained from a secure resolver or independently - verified by the user and (2) this secure resolver and secure - obtainment or independent verification conform to security policies - acceptable to the user. [RFC4033] [RFC4034] [RFC4035] As with all - cryptographic algorithms, evaluating the necessary strength of the - key is essential and dependent on local policy. - - Some specific key generation considerations are given in the body of - this document. - - - -8. IANA Considerations - - Assignment of meaning to the remaining ECC data flag bits or to - values of ECC fields outside the ranges for which meaning in defined - in this document requires an IETF consensus as defined in [RFC2434]. - - - - - - - - - -R. Schroeppel, et al [Page 13] - - -INTERNET-DRAFT ECC in the DNS - - -Copyright and Additional IPR Provisions - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - - Copyright (C) The IETF Trust (2007) - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - - - - - - - - - - - - - - - - - - - - - - -R. Schroeppel, et al [Page 14] - - -INTERNET-DRAFT ECC in the DNS - - -Informational References - - [RFC1034] - P. Mockapetris, "Domain names - concepts and facilities", - 11/01/1987. - - [RFC1035] - P. Mockapetris, "Domain names - implementation and - specification", 11/01/1987. - - [RFC2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August - 1999. - - [RFC4025] - M. Richardson, "A Method for Storing IPsec Keying - Material in DNS", February 2005. - - [RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC 4033, March - 2005. - - [RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security Extensions", RFC - 4035, March 2005. - - [RFC4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, - "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. - - [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C", 1996, John Wiley and Sons - - [Menezes] - Alfred Menezes, "Elliptic Curve Public Key - Cryptosystems", 1993 Kluwer. - - [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", - 1986, Springer Graduate Texts in mathematics #106. - - - -Normative Refrences - - [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", March 1997. - - [RFC2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", October 1998. - - [RFC3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm - 1 (SHA1)", RFC 3174, September 2001. - - [RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - -R. Schroeppel, et al [Page 15] - - -INTERNET-DRAFT ECC in the DNS - - -Author's Addresses - - Rich Schroeppel - 500 S. Maple Drive - Woodland Hills, UT 84653 USA - - Telephone: +1-505-844-9079(w) - Email: rschroe@sandia.gov - - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1 508-786-7554 (w) - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires in September 2007. - - Its file name is draft-ietf-dnsext-ecc-key-10.txt. - - - -Disclaimer - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - -R. Schroeppel, et al [Page 16] - diff --git a/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/doc/draft/draft-ietf-dnsext-interop3597-02.txt deleted file mode 100644 index 160afc356a..0000000000 --- a/doc/draft/draft-ietf-dnsext-interop3597-02.txt +++ /dev/null @@ -1,334 +0,0 @@ -DNS Extensions Working Group J. Schlyter -Internet-Draft May 19, 2005 -Expires: November 20, 2005 - - - RFC 3597 Interoperability Report - draft-ietf-dnsext-interop3597-02.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 20, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This memo documents the result from the RFC 3597 (Handling of Unknown - DNS Resource Record Types) interoperability testing. - - - - - - - - - - -Schlyter Expires November 20, 2005 [Page 1] - -Internet-Draft RFC 3597 Interoperability Report May 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.1 Authoritative Primary Name Server . . . . . . . . . . . . 3 - 3.2 Authoritative Secondary Name Server . . . . . . . . . . . 3 - 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . 4 - 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . 4 - 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4 - 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 - A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5 - Intellectual Property and Copyright Statements . . . . . . . . 6 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires November 20, 2005 [Page 2] - -Internet-Draft RFC 3597 Interoperability Report May 2005 - - -1. Introduction - - This memo documents the result from the RFC 3597 (Handling of Unknown - DNS Resource Record Types) interoperability testing. The test was - performed during June and July 2004 by request of the IETF DNS - Extensions Working Group. - -2. Implementations - - The following is a list, in alphabetic order, of implementations - tested for compliance with RFC 3597: - - DNSJava 1.6.4 - ISC BIND 8.4.5 - ISC BIND 9.3.0 - NSD 2.1.1 - Net::DNS 0.47 patchlevel 1 - Nominum ANS 2.2.1.0.d - - These implementations covers the following functions (number of - implementations tested for each function in paranthesis): - - Authoritative Name Servers (4) - Full Recursive Resolver (2) - Stub Resolver (4) - DNSSEC Zone Signers (2) - - All listed implementations are genetically different. - -3. Tests - - The following tests was been performed to validate compliance with - RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression") - and 5 ("Text Representation"). - -3.1 Authoritative Primary Name Server - - The test zone data (Appendix A) was loaded into the name server - implementation and the server was queried for the loaded information. - -3.2 Authoritative Secondary Name Server - - The test zone data (Appendix A) was transferred using AXFR from - another name server implementation and the server was queried for the - transferred information. - - - - - - -Schlyter Expires November 20, 2005 [Page 3] - -Internet-Draft RFC 3597 Interoperability Report May 2005 - - -3.3 Full Recursive Resolver - - A recursive resolver was queried for resource records from a domain - with the test zone data (Appendix A). - -3.4 Stub Resolver - - A stub resolver was used to query resource records from a domain with - the test zone data (Appendix A). - -3.5 DNSSEC Signer - - A DNSSEC signer was used to sign a zone with test zone data - (Appendix A). - -4. Problems found - - Two implementations had problems with text presentation of zero - length RDATA. - - One implementation had problems with text presentation of RR type - code and classes >= 4096. - - Bug reports were filed for problems found. - -5. Summary - - Unknown type codes works in the tested authoritative servers, - recursive resolvers and stub clients. - - No changes are needed to advance RFC 3597 to draft standard. - -6. Normative References - - [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) - Types", RFC 3597, September 2003. - - -Author's Address - - Jakob Schlyter - - Email: jakob@rfc.se - - - - - - - - -Schlyter Expires November 20, 2005 [Page 4] - -Internet-Draft RFC 3597 Interoperability Report May 2005 - - -Appendix A. Test zone data - - ; A-record encoded as TYPE1 - a TYPE1 \# 4 7f000001 - a TYPE1 192.0.2.1 - a A \# 4 7f000002 - - ; draft-ietf-secsh-dns-05.txt - sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e - - ; bogus test record (from RFC 3597) - type731 TYPE731 \# 6 abcd ( - ef 01 23 45 ) - - ; zero length RDATA (from RFC 3597) - type62347 TYPE62347 \# 0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires November 20, 2005 [Page 5] - -Internet-Draft RFC 3597 Interoperability Report May 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Schlyter Expires November 20, 2005 [Page 6] - - diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt deleted file mode 100644 index b5877705eb..0000000000 --- a/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -INTERNET-DRAFT A. Gustafsson - Araneus Information Systems Oy - February 24, 2010 - -Intended status: Draft Standard -Obsoletes: RFC3597 - - Handling of Unknown DNS Resource Record (RR) Types - draft-ietf-dnsext-rfc3597-bis-02.txt - -Abstract - - Extending the Domain Name System (DNS) with new Resource Record (RR) - types should not requires changes to name server software. This - document specifies how new RR types are transparently handled by DNS - software. - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - - - -Expires August 2010 Standards Track [Page 1] - -draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 - - - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -1. Introduction - - The DNS [RFC1034] is designed to be extensible to support new - services through the introduction of new resource record (RR) types. - Nevertheless, DNS implementations have historically required software - changes to support new RR types, not only at the authoritative DNS - server providing the new information and the client making use of it, - but also at all slave servers for the zone containing it, and in some - cases also at caching name servers and forwarders used by the client. - Because the deployment of new DNS software is slow and expensive, - this has been a significant impediment to supporting new services in - the DNS. - - [RFC3597] defined DNS implementation behavior and procedures for - defining new RR types aimed at simplifying the deployment of new RR - types by allowing them to be treated transparently by existing - implementations. Thanks to the widespread adoption of that - specification, much of the DNS is now capable of handling new record - types without software changes. Another development that has - simplified the introduction of new DNS RR types is the adoption of a - simpler IANA allocation procedure for RR types [RFC5395]. - - This document is a self-contained revised specification supplanting - and obsoleting RFC 3597, with the aim of allowing the specification - to advance on the Standards Track. - -2. Definitions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - An "RR of unknown type" is an RR whose RDATA format is not known to - the DNS implementation at hand, and whose type is not an assigned - QTYPE or Meta-TYPE as specified in [RFC5395] (section 3.1) nor within - the range reserved in that section for assignment only to QTYPEs and - Meta-TYPEs. Such an RR cannot be converted to a type-specific text - format, compressed, or otherwise handled in a type-specific way. - - In the case of a type whose RDATA format is known to be class - specific, an RR is considered to be of unknown type when the RDATA - format for that combination of type and class is not known. - -3. Transparency - - - -Expires August 2010 Standards Track [Page 2] - -draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 - - - To enable new RR types to be deployed without server changes, name - servers and resolvers MUST handle RRs of unknown type transparently. - The RDATA section of RRs of unknown type must be treated as - unstructured binary data, and must be stored and transmitted without - change ([RFC1123], section 6.1.3.5). - - To ensure the correct operation of equality comparison (section 6) - and of the DNSSEC canonical form (section 7) when an RR type is known - to some but not all of the servers involved, servers MUST also - exactly preserve the RDATA of RRs of known type, except for changes - due to compression or decompression where allowed by section 4 of - this document. In particular, the character case of domain names - that are not subject to compression MUST be preserved. - -4. Domain Name Compression - - RRs containing compression pointers in the RDATA part cannot be - treated transparently, as the compression pointers are only - meaningful within the context of a DNS message. Transparently - copying the RDATA into a new DNS message would cause the compression - pointers to point at the corresponding location in the new message, - which now contains unrelated data. This would cause the compressed - name to be corrupted. - - To avoid such corruption, servers MUST NOT compress domain names - embedded in the RDATA of types that are class-specific or not well- - known. This requirement was stated in [RFC1123] without defining the - term "well-known"; it is hereby specified that only the RR types - defined in [RFC1035] are to be considered "well-known". - - Receiving servers MUST decompress domain names in RRs of well-known - type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, - NXT, SRV, and NAPTR to ensure interoperability with implementations - predating [RFC3597]. - - Specifications for new RR types that contain domain names within - their RDATA MUST NOT allow the use of name compression for those - names, and SHOULD explicitly state that the embedded domain names - MUST NOT be compressed. - - As noted in [RFC1123], the owner name of an RR is always eligible for - compression. - -5. Text Representation - - In the "type" field of a master file line, an unknown RR type is - represented by the word "TYPE" immediately followed by the decimal RR - type number, with no intervening whitespace. In the "class" field, - - - -Expires August 2010 Standards Track [Page 3] - -draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 - - - an unknown class is similarly represented as the word "CLASS" - immediately followed by the decimal class number. - - This convention allows types and classes to be distinguished from - each other and from TTL values, allowing the "[] [] - " and "[] [] " forms of - [RFC1035] section 5.1 to both be unambiguously parsed. - - The RDATA section of an RR of unknown type is represented as a - sequence of items separated by any combination of tabs and spaces, as - follows: - - - The special token \# (a backslash immediately followed by a hash - sign), which identifies the RDATA as having the generic encoding - defined herein rather than a traditional type-specific encoding. - - - An unsigned decimal integer specifying the RDATA length in - octets. - - - Zero or more items of hexadecimal data encoding the actual RDATA - field, each item containing an even number of hexadecimal digits. - - If the RDATA is of zero length, the text representation contains only - the \# token and the single zero representing the length. - - An implementation MAY also choose to represent some RRs of known type - using the above generic representations for the type, class and/or - RDATA, which carries the benefit of making the resulting master file - portable to servers where these types are unknown. Using the generic - representation for the RDATA of an RR of known type can also be - useful in the case of an RR type where the text format varies - depending on a version, protocol, or similar field (or several) - embedded in the RDATA when such a field has a value for which no text - format is known, e.g., a LOC RR [RFC1876] with a VERSION other than - 0. - - Even though an RR of known type represented in the \# format is - effectively treated as an unknown type for the purpose of parsing the - RDATA text representation, all further processing by the server MUST - treat it as a known type and take into account any applicable type- - specific rules regarding compression, canonicalization, etc. - - The following are examples of RRs represented in this manner, - illustrating various combinations of generic and type-specific - encodings for the different fields of the master file format: - - a.example. CLASS32 TYPE731 \# 6 abcd ( - ef 01 23 45 ) - - - -Expires August 2010 Standards Track [Page 4] - -draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 - - - b.example. HS TYPE62347 \# 0 - e.example. IN A \# 4 C0000201 - e.example. CLASS1 TYPE1 192.0.2.1 - -6. Equality Comparison - - Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs - to be compared for equality. Two RRs of the same unknown type are - considered equal when their RDATA is bitwise equal. To ensure that - the outcome of the comparison is identical whether the RR is known to - the server or not, specifications for new RR types MUST NOT specify - type-specific comparison rules. - - This implies that embedded domain names, being included in the - overall bitwise comparison, are compared in a case-sensitive manner. - - As a result, when a new RR type contains one or more embedded domain - names, it is possible to have multiple RRs owned by the same name - that differ only in the character case of the embedded domain - name(s). This is similar to the existing possibility of multiple TXT - records differing only in character case, and not expected to cause - any problems in practice. - -7. DNSSEC Considerations - - The rules for the DNSSEC canonical form and ordering were updated to - support transparent treatment of unknown types in [RFC3597]. Those - updates have subsequently been integrated into the base DNSSEC - specification, such that the DNSSEC canonical form and ordering are - now specified in [RFC4034] or its successors rather than in this - document. - -8. Additional Section Processing - - Unknown RR types cause no additional section processing. Future RR - type specifications MAY specify type-specific additional section - processing rules, but any such processing MUST be optional as it can - only be performed by servers for which the RR type in case is known. - -9. IANA Considerations - - This document does not require any IANA actions. - -10. Security Considerations - - This specification is not believed to cause any new security - problems, nor to solve any existing ones. - - - - -Expires August 2010 Standards Track [Page 5] - -draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 - - -11. Normative References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -- - Application and Support", STD 3, RFC 1123, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA - Considerations", BCP 42, RFC 5395, November 2008. - -12. Informative References - - [RFC1876] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A - Means for Expressing Location Information in the Domain - Name System", RFC 1876, January 1996. - - [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - -14. Author's Address - - Andreas Gustafsson - Araneus Information Systems Oy - PL 110 - 02321 Espoo - Finland - - Phone: +358 40 547 2099 - EMail: gson@araneus.fi - -Appendix A. Summary of Changes Since RFC3597 - - This section summarizes the major changes between RFC3597 and this - - - -Expires August 2010 Standards Track [Page 6] - -draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 - - - document. In addition to the changes listed below, there has also - been a number of editorial changes, such as updates to the text in - the Abstract and Introduction to better reflect the current state of - implementation, updates to boilerplate text, and minor - clarifications. - - The reference to the DNS IANA Considerations BCP (BCP42) has been - changed from RFC2929 to the current version, RFC5395. - - Downward references have been eliminated; specifically, the document - no longer refers to RFC2163 or RFC2535. - - IP addresses in examples have been changed to use the 192.0.2.0/24 - range per RFC3330. - - The document no longer specifies changes to the DNSSEC canonical form - and ordering, as those changes have now been incorporated into the - base DNSSEC specification. - -Appendix B. Detailed Change Log - - [NOTE TO RFC EDITOR: PLEASE REMOVE THIS APPENDIX ON PUBLICATION.] - -B.1. Changes between RFC3597 and -00 - - The reference to the DNS IANA Considerations BCP (BCP42) has been - changed from RFC2929 to the current version, RFC5395. - - Downward references have been eliminated; specifically, the document - no longer refers to RFC2163 or RFC2535. - - IP addresses in examples have been changed to use the 192.0.2.0/24 - range per RFC3330. - - The document no longer specifies changes to the DNSSEC canonical form - and ordering, as those changes have now been incorporated into the - base DNSSEC specification. - - There has also been a number of editorial changes, such as updates to - the text in the Abstract and Introduction to better reflect the - current state of implementation. - -B.2. Changes between -00 and -01 - - Moved the Abstract to immediately following the document title. - - Updated boilerplate to the current version. - - - - -Expires August 2010 Standards Track [Page 7] - -draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 - - - In the Introduction, the text "Another development that has - simplified the introduction of new DNS RR types is the adoption of a - simpler IANA allocation procedure for RR types" and a reference to - [RFC5395] were added. - - In the Introduction, the text "with the aim of allowing the - specification to advance on the Standards Track" was added to explain - the motivation for the draft. - - In section 2, the text "is class specific" was replaced by "is known - to be class specific". - - In section 3, the words "That is" were removed so as not to imply - that the transparent treatment of RRs of unknown type is only a - matter of how the RDATA field is handled. The remainder of the - sentence was rephrased. - - In section 4, the entries for SRV and NAPTR in the list of RR types - to decompress were swapped to make the list consistently ordered by - ascending numerical RR type. - - References to RFC 1035 and RFC 1123 now include the specific section - numbers being referenced. - - A Change History was added as Appendix A. - -B.3. Changes between -01 and -02 - - In section 5, the term "white space" was replaced by "any combination - of tabs and spaces", and the term "word" was replaced by "item", for - consistency with RFC1035 terminology. - - In section 5, hyphens were added to mark the beginning of each item - in the the list of items comprising the RDATA text representation. - - The Change History was split into a Summary of Changes Since RFC3597 - (Appendix A) intended to remain in the document when published as an - RFC, and a Detailed Change Log (Appendix B) to be deleted on - publication. - - - - - - - - - - - - -Expires August 2010 Standards Track [Page 8] - diff --git a/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt b/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt deleted file mode 100644 index 72d38aa267..0000000000 --- a/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt +++ /dev/null @@ -1,336 +0,0 @@ - - - -DNSext Working Group F. Dupont -Internet-Draft ISC -Updates: 2845,2930,4635 May 8, 2009 -(if approved) -Intended status: Standards Track -Expires: November 9, 2009 - - - Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records - draft-ietf-dnsext-tsig-md5-deprecated-03.txt - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. This document may contain material - from IETF Documents or IETF Contributions published or made publicly - available before November 10, 2008. The person(s) controlling the - copyright in some of this material may not have granted the IETF - Trust the right to allow modifications of such material outside the - IETF Standards Process. Without obtaining an adequate license from - the person(s) controlling the copyright in such materials, this - document may not be modified outside the IETF Standards Process, and - derivative works of it may not be created outside the IETF Standards - Process, except to format it for publication as an RFC or to - translate it into languages other than English. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 9, 2009. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - - -Dupont Expires November 9, 2009 [Page 1] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - The main purpose of this document is to deprecate the use of HMAC-MD5 - as an algorithm for the TSIG (secret key transaction authentication) - resource record in the DNS (domain name system), and the use of MD5 - in TKEY (secret key establishment for DNS). - - -1. Introduction - - The secret key transaction authentication for DNS (TSIG, [RFC2845]) - was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm. - When the MD5 [RFC1321] security came to be considered lower than - expected, [RFC4635] standardized new TSIG algorithms based on SHA - [RFC3174][RFC3874][RFC4634] digests. - - But [RFC4635] did not deprecate the HMAC-MD5 algorithm. This - document is targeted to complete the process, in detail: - 1. Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm - name registry managed by the IANA under the IETF Review Policy - [RFC5226] - 2. Make HMAC-MD5.SIG-ALG.REG.INT support "not Mandatory" for - implementations - 3. Provide a keying material derivation for the secret key - establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman - exchange with SHA256 [RFC4634] in place of MD5 [RFC1321] - 4. Finally recommend the use of HMAC-SHA256. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - -2. Implementation Requirements - - The table of section 3 of [RFC4635] is replaced by: - - - - - - - - - -Dupont Expires November 9, 2009 [Page 2] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - +-------------------+--------------------------+ - | Requirement Level | Algorithm Name | - +-------------------+--------------------------+ - | Optional | HMAC-MD5.SIG-ALG.REG.INT | - | Optional | gss-tsig | - | Mandatory | hmac-sha1 | - | Optional | hmac-sha224 | - | Mandatory | hmac-sha256 | - | Optional | hmac-sha384 | - | Optional | hmac-sha512 | - +-------------------+--------------------------+ - - Implementations that support TSIG MUST also implement HMAC-SHA1 and - HMAC-SHA256 (i.e., algorithms at the "Mandatory" requirement level) - and MAY implement GSS-TSIG and the other algorithms listed above - (i.e., algorithms at a "not Mandatory" requirement level). - - -3. TKEY keying material derivation - - When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying - material is derived from the shared secret and TKEY resource record - data using MD5 [RFC1321] at the end of section 4.1 page 9. - - This is amended into: - - keying material = - XOR ( DH value, SHA256 ( query data | DH value ) | - SHA256 ( server data | DH value ) ) - - using the same conventions. - - -4. IANA Consideration - - This document extends the "TSIG Algorithm Names - per [] and - [RFC2845]" located at - http://www.iana.org/assignments/tsig-algorithm-names by adding a new - column to the registry "Compliance Requirement". - - The registry should contain the following: - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 3] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - +--------------------------+------------------------+-------------+ - | Algorithm Name | Compliance Requirement | Reference | - +--------------------------+------------------------+-------------+ - | gss-tsig | Optional | [RFC3645] | - | HMAC-MD5.SIG-ALG.REG.INT | Optional | [][RFC2845] | - | hmac-sha1 | Mandatory | [RFC4635] | - | hmac-sha224 | Optional | [RFC4635] | - | hmac-sha256 | Mandatory | [RFC4635] | - | hmac-sha384 | Optional | [RFC4635] | - | hmac-sha512 | Optional | [RFC4635] | - +--------------------------+------------------------+-------------+ - - where [] is this document. - - -5. Availability Considerations - - MD5 is no longer universally available and its use may lead to - increasing operation issues. SHA1 is likely to suffer from the same - kind of problem. In summary MD5 has reached end-of-life and SHA1 - will likely follow in the near term. - - According to [RFC4635], implementations which support TSIG are - REQUIRED to implement HMAC-SHA256. - - -6. Security Considerations - - This document does not assume anything about the cryptographic - security of different hash algorithms. Its purpose is a better - availability of some security mechanisms in a predictable time frame. - - Requirement levels are adjusted for TSIG and related specifications - (i.e., TKEY): - The support of HMAC-MD5 is changed from mandatory to optional. - The use of MD5 and HMAC-MD5 is NOT RECOMMENDED. - The use of HMAC-SHA256 is RECOMMENDED. - - -7. Acknowledgments - - Olafur Gudmundsson kindly helped in the procedure to deprecate the - MD5 use in TSIG, i.e., the procedure which led to this memo. Alfred - Hoenes, Peter Koch, Paul Hoffman and Edward Lewis proposed some - improvements. - - -8. References - - - -Dupont Expires November 9, 2009 [Page 4] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC4635] Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers", - RFC 4635, August 2006. - -8.2. Informative References - - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 - (SHA1)", RFC 3174, September 2001. - - [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., - and R. Hall, "Generic Security Service Algorithm for - Secret Key Transaction Authentication for DNS (GSS-TSIG)", - RFC 3645, October 2003. - - [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", - RFC 3874, September 2004. - - [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms - (SHA and HMAC-SHA)", RFC 4634, July 2006. - - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", RFC 5226, BCP 26, - May 2008. - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 5] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - -Author's Address - - Francis Dupont - ISC - - Email: Francis.Dupont@fdupont.fr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 6] - diff --git a/doc/draft/draft-ietf-dnsop-dnssec-key-timing-03.txt b/doc/draft/draft-ietf-dnsop-dnssec-key-timing-03.txt deleted file mode 100644 index eeba6d5ad9..0000000000 --- a/doc/draft/draft-ietf-dnsop-dnssec-key-timing-03.txt +++ /dev/null @@ -1,1848 +0,0 @@ - - - -Internet Engineering Task Force S. Morris -Internet-Draft ISC -Intended status: Informational J. Ihren -Expires: January 10, 2013 Netnod - J. Dickinson - Sinodun - July 9, 2012 - - - DNSSEC Key Timing Considerations - draft-ietf-dnsop-dnssec-key-timing-03.txt - -Abstract - - This document describes the issues surrounding the timing of events - in the rolling of a key in a DNSSEC-secured zone. It presents - timelines for the key rollover and explicitly identifies the - relationships between the various parameters affecting the process. - -Status of this Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on January 10, 2013. - -Copyright Notice - - Copyright (c) 2012 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - - - -Morris, et al. Expires January 10, 2013 [Page 1] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3 - 1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 - 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 - 2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 8 - 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9 - 3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9 - 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 12 - 3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 13 - 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 15 - 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 16 - 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 18 - 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 21 - 3.3.4. Interaction with Configured Trust Anchors . . . . . . 23 - 3.3.5. Introduction of First Keys . . . . . . . . . . . . . . 24 - 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 26 - 6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 26 - 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 - 11. Normative References . . . . . . . . . . . . . . . . . . . . . 27 - Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 28 - Appendix B. Change History (To be removed on publication) . . . . 31 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 - - - - - - - - - - - - - -Morris, et al. Expires January 10, 2013 [Page 2] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - -1. Introduction - -1.1. Key Rolling Considerations - - When a zone is secured with DNSSEC, the zone manager must be prepared - to replace ("roll") the keys used in the signing process. The - rolling of keys may be caused by compromise of one or more of the - existing keys, or it may be due to a management policy that demands - periodic key replacement for security or operational reasons. In - order to implement a key rollover, the keys need to be introduced - into and removed from the zone at the appropriate times. - Considerations that must be taken into account are: - - o DNSKEY records and associated information (such as the associated - DS records or RRSIG records created with the key) are not only - held at the authoritative nameserver, they are also cached by - resolvers. The data on these systems can be interlinked, e.g., a - validating resolver may try to validate a signature retrieved from - a cache with a key obtained separately. - - o Zone "boot-strapping" events, where a zone is signed for the first - time, can be common in configurations where a large number of - zones are being served. Procedures should be able to cope with - the introduction of keys into the zone for the first time as well - as "steady-state", where the records are being replaced as part of - normal zone maintenance. - - o To allow for an emergency re-signing of the zone as soon as - possible after a key compromise has been detected, standby keys - (additional keys over and above those used to sign the zone) need - to be present. - - o A query for the DNSKEY RRset returns all DNSKEY records in the - zone. As there is limited space in the UDP packet (even with - EDNS0 support), key records no longer needed must be periodically - removed. (For the same reason, the number of standby keys in the - zone should be restricted to the minimum required to support the - key management policy.) - - Management policy, e.g., how long a key is used for, also needs to be - considered. However, the point of key management logic is not to - ensure that a rollover is completed at a certain time but rather to - ensure that no changes are made to the state of keys published in the - zone until it is "safe" to do so ("safe" in this context meaning that - at no time during the rollover process does any part of the zone ever - go bogus). In other words, although key management logic enforces - policy, it may not enforce it strictly. - - - - -Morris, et al. Expires January 10, 2013 [Page 3] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - A high-level overview of key rollover can be found in - [I-D.ietf-dnsop-rfc4641bis]. In contrast, this document focuses on - the low-level timing detail of two classes of operations described - there, the rollover of key-signing keys, and the rollover of zone - signing keys. - -1.2. Types of Keys - - Although DNSSEC validation treats all keys equally, [RFC4033] - recognises the broad classification of zone-signing keys (ZSK) and - key-signing keys (KSK). A ZSK is used to authenticate information - within the zone; a KSK is used to authenticate the zone's DNSKEY - RRset. The main implication for this distinction concerns the - consistency of information during a rollover. - - During operation, a validating resolver must use separate pieces of - information to perform an authentication. At the time of - authentication, each piece of information may be in its cache or may - need to be retrieved from the authoritative server. The rollover - process needs to happen in such a way that at all times during the - rollover the information is consistent. With a ZSK, the information - is the RRSIG (plus associated RRset) and the DNSKEY. These are both - obtained from the same zone. In the case of the KSK, the information - is the DNSKEY and DS RRset with the latter being obtained from a - different zone. - - Although there are similarities in the algorithms to roll ZSKs and - KSKs, there are a number of differences. For this reason, the two - types of rollovers are described separately. It is also possible to - use a single key as both the ZSK and KSK. However, the rolling of - this type of key is not treated in this document. - -1.3. Terminology - - The terminology used in this document is as defined in [RFC4033] and - [RFC5011]. - - A number of symbols are used to identify times, intervals, etc. All - are listed in Appendix A. - -1.4. Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - - - -Morris, et al. Expires January 10, 2013 [Page 4] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - -2. Rollover Methods - -2.1. ZSK Rollovers - - A ZSK can be rolled in one of three ways: - - o Pre-Publication: described in [I-D.ietf-dnsop-rfc4641bis], the new - key is introduced into the DNSKEY RRset which is then re-signed. - This state of affairs remains in place for long enough to ensure - that any cached DNSKEY RRsets contain both keys. At that point - signatures created with the old key can be replaced by those - created with the new key, and the old signatures removed. During - the re-signing process (which may or may not be atomic depending - on how the zone is managed), it doesn't matter which key an RRSIG - record retrieved by a resolver was created with; cached copies of - the DNSKEY RRset will contain both the old and new keys. - - Once the zone contains only signatures created with the new key, - there is an interval during which RRSIG records created with the - old key expire from caches. After this, there will be no - signatures anywhere that were created using the old key, and it - can can be removed from the DNSKEY RRset. - - o Double-Signature: also mentioned in [I-D.ietf-dnsop-rfc4641bis], - this involves introducing the new key into the zone and using it - to create additional RRSIG records; the old key and existing RRSIG - records are retained. During the period in which the zone is - being signed (again, the signing process may not be atomic), - validating resolvers are always able to validate RRSIGs: any - combination of old and new DNSKEY RRset and RRSIG allows at least - one signature to be validated. - - Once the signing process is complete and enough time has elapsed - to allow all old information to expire from caches, the old key - and signatures can be removed from the zone. As before, during - this period any combination of DNSKEY RRset and RRSIG will allow - validation of at least one signature. - - o Double-RRSIG: strictly speaking, the use of the term "Double- - Signature" above is a misnomer as the method is not only double - signature, it is also double key as well. A true Double-Signature - method (here called the Double-RRSIG method) involves introducing - new signatures in the zone (while still retaining the old ones) - but not introducing the new key. - - Once the signing process is complete and enough time has elapsed - to ensure that all caches that may contain an RR and associated - RRSIG have a copy of both signatures, the key is changed. After a - - - -Morris, et al. Expires January 10, 2013 [Page 5] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - further interval during which the old DNSKEY RRset expires from - caches, the old signatures are removed from the zone. - - Of three methods, Double-Signature is conceptually the simplest - - introduce the new key and new signatures, then approximately one TTL - later remove the old key and old signatures. Pre-Publication is more - complex - introduce the new key, approximately one TTL later sign the - records, and approximately one TTL after that remove the old key. - Double-RRSIG is essentially the reverse of Pre-Publication - - introduce the new signatures, approximately one TTL later change the - key, and approximately one TTL after that remove the old signatures. - -2.2. KSK Rollovers - - For ZSKs, the issue for the validating resolver is to ensure that it - has access to the ZSK that corresponds to a particular signature. In - the KSK case, this can never be a problem as the KSK is only used for - one signature (that over the DNSKEY RRset) and both the key and the - signature travel together. Instead, the issue is to ensure that the - KSK is trusted. - - Trust in the KSK is either due to the existence of a signed and - validated DS record in the parent zone or an explicitly configured - trust anchor. If the former, the rollover algorithm will need to - involve the parent zone in the addition and removal of DS records, so - timings are not wholly under the control of the zone manager. If the - latter, [RFC5011] timings will be needed to roll the keys. (Even in - the case where authentication is via a DS record, the zone manager - may elect to include [RFC5011] timings in the key rolling process so - as to cope with the possibility that the key has also been explicitly - configured as a trust anchor.) - - It is important to note that this does not preclude the development - of key rollover logic; in accordance with the goal of the rollover - logic being able to determine when a state change is "safe", the only - effect of being dependent on the parent is that there may be a period - of waiting for the parent to respond in addition to any delay the key - rollover logic requires. Although this introduces additional delays, - even with a parent that is less than ideally responsive the only - effect will be a slowdown in the rollover state transitions. This - may cause a policy violation, but will not cause any operational - problems. - - Like the ZSK case, there are three methods for rolling a KSK: - - o Double-Signature: also known as Double-DNSKEY, the new KSK is - added to the DNSKEY RRset which is then signed with both the old - and new key. After waiting for the old RRset to expire from - - - -Morris, et al. Expires January 10, 2013 [Page 6] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - caches, the DS record in the parent zone is changed. After - waiting a further interval for this change to be reflected in - caches, the old key is removed from the RRset. (The name "Double- - Signature" is used because, like the ZSK method of the same name, - the new key is introduced and immediately used for signing.) - - o Double-DS: the new DS record is published. After waiting for this - change to propagate into caches, the KSK is changed. After a - further interval during which the old DNSKEY RRset expires from - caches, the old DS record is removed. - - o Double-RRset: the new KSK is added to the DNSKEY RRset which is - then signed with both the old and new key, and the new DS record - added to the parent zone. After waiting a suitable interval for - the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY - and DS record are removed. - - In essence, "Double-Signature" means that the new KSK is introduced - first and used to sign the DNSKEY RRset. The DS record is changed, - and finally the old KSK removed. With "Double-DS" it is the other - way around. Finally, Double-RRset does both updates more or less in - parallel. - -2.3. Summary - - The methods can be summarised as follows: - - +------------------+------------------+-----------------------------+ - | ZSK Method | KSK Method | Description | - +------------------+------------------+-----------------------------+ - | Pre-Publication | (not applicable) | Publish the DNSKEY before | - | | | the RRSIGs. | - | Double-Signature | Double-Signature | Publish the DNSKEY and | - | | | RRSIGs at same time. For a | - | | | KSK, this happens before | - | | | the DS is published. | - | Double-RRSIG | (not applicable) | Publish RRSIGs before the | - | | | DNSKEY. | - | (not applicable) | Double-DS | Publish DS before the | - | | | DNSKEY. | - | (not applicable) | Double-RRset | Publish DNSKEY and DS in | - | | | parallel. | - +------------------+------------------+-----------------------------+ - - Table 1 - - - - - - -Morris, et al. Expires January 10, 2013 [Page 7] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - -3. Key Rollover Timelines - -3.1. Key States - - During the rolling process, a key moves through different states. - The defined states are: - - Generated The key has been created, but has not yet been used for - anything. - - Published The DNSKEY record - or information associated with it - - is published in the zone, but predecessors of the key (or - associated information) may be held in caches. - - The idea of "associated information" is used in rollover - methods where RRSIG or DS records are published first and - the DNSKEY is changed in an atomic operation. It allows - the rollover still to be thought of as moving through a - set of states. In the rest of this section, the term - "key data" should be taken to mean "key or associated - information". - - Ready The new key data has been published for long enough to - guarantee that any previous versions of the DNSKEY RRset - have expired from caches. - - Active The key has started to be used to sign RRsets. Note that - when this state is entered, it may not be possible for - validating resolvers to use the key for validation in all - cases: the zone signing may not have finished, or the - data might not have reached the resolver because of - propagation delays and/or caching issues. If this is the - case, the resolver will have to rely on the key's - predecessor instead. - - Retired A successor key has become active and this key is no - longer being used to generate RRSIGs. However, as there - may still be RRSIGs in caches that were generated using - this key, it is being retained in the zone until they - have expired. - - Dead The key is published in the zone but there is no longer - information anywhere that requires its presence. Hence - the key can be removed from the zone at any time. - - - - - - - -Morris, et al. Expires January 10, 2013 [Page 8] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - Removed The key has been removed from the zone. - - There is one additional state, used where [RFC5011] considerations - are in effect (see Section 3.3.4): - - Revoked The key is published for a period with the "revoke" bit - set as a way of notifying validating resolvers that have - configured it as an [RFC5011] trust anchor that it is - about to be removed from the zone. - -3.2. Zone-Signing Key Timelines - - The following sections describe the rolling of a ZSK. They show the - events in the lifetime of a key (referred to as "key N") and cover - its replacement by its successor (key N+1). - -3.2.1. Pre-Publication Method - - The following diagram shows the timeline of a Pre-Publication - rollover. Time increases along the horizontal scale from left to - right and the vertical lines indicate events in the process. - Significant times and time intervals are marked. - - - - |1| |2| |3| |4| |5| |6| |7| |8| |9| - | | | | | | | | | - Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->| - | | | | | | | | | - Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - - - | | | | | | | | | - Tgen Tpub Trdy Tact TpubS Tret Tdea Trem - - ---- Time ----> - - Figure 1: Timeline for a Pre-Publication ZSK rollover. - - Event 1: Key N is generated at the generate time (Tgen). Although - there is no reason why the key cannot be generated immediately prior - to its publication in the zone (Event 2), some implementations may - find it convenient to create a pool of keys in one operation and draw - from that pool as required. For this reason, it is shown as a - separate event. Keys that are available for use but not published - are said to be generated. - - Event 2: Key N's DNSKEY record is put into the zone, i.e., it is - added to the DNSKEY RRset which is then re-signed with the current - key-signing key. The time at which this occurs is the key's - - - -Morris, et al. Expires January 10, 2013 [Page 9] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - publication time (Tpub), and the key is now said to be published. - Note that the key is not yet used to sign records. - - Event 3: Before it can be used, the key must be published for long - enough to guarantee that any cached version of the zone's DNSKEY - RRset includes this key. - - This interval is the publication interval (Ipub) and, for the second - or subsequent keys in the zone, is given by: - - Ipub = Dprp + TTLkey - - Here, Dprp is the propagation delay - the time taken in the worst- - case situation for a change introduced at the master to replicate to - all slave servers - which depends on the depth of the master-slave - hierarchy. TTLkey is the time-to-live (TTL) for the DNSKEY records - in the zone. The sum is therefore the maximum time taken for - existing DNSKEY records to expire from caches, regardless of the - nameserver from which they were retrieved. - - (The case of introducing the first ZSK into the zone is discussed in - Section 3.3.5.) - - After a delay of Ipub, the key is said to be ready and could be used - to sign records. The time at which this event occurs is the key's - ready time (Trdy), which is given by: - - Trdy = Tpub + Ipub - - Event 4: At some later time, the key starts being used to sign - RRsets. This point is the activation time (Tact) and after this, the - key is said to be active. - - Event 5: At some point thought must be given to its successor (key - N+1). As with the introduction of the currently active key into the - zone, the successor key will need to be published at least Ipub - before it is activated. Denoting the publication time of the - successor key by TpubS, then: - - TpubS <= Tact + Lzsk - Ipub - - Here, Lzsk is the length of time for which a ZSK will be used (the - ZSK lifetime). It should be noted that unlike the publication - interval, Lzsk is not determined by timing logic, but by key - management policy. Lzsk will be set by the operator according to - their assessment of the risks posed by continuing to use a key and - the risks associated with key rollover. However, operational - considerations may mean a key is active for slightly more or less - - - -Morris, et al. Expires January 10, 2013 [Page 10] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - than Lzsk. - - Event 6: While key N is still active, its successor becomes ready. - From this time onwards, key N+1 could be used to sign the zone. - - Event 7: When key N has been in use for an interval equal to the ZSK - lifetime, it is retired (i.e., it will never again be used to - generate new signatures) and key N+1 activated and used to sign the - zone. This is the retire time of key N (Tret) and is given by: - - Tret = Tact + Lzsk - - It is also the activation time of the successor key (TactS). Note - that operational considerations may cause key N to remain in use for - longer than Lzsk; if so, the retirement actually occurs when the - successor key is made active. - - Event 8: The retired key needs to be retained in the zone whilst any - RRSIG records created using this key are still published in the zone - or held in caches. (It is possible that a validating resolver could - have an unexpired RRSIG record and an expired DNSKEY RRset in the - cache when it is asked to provide both to a client. In this case the - DNSKEY RRset would need to be looked up again.) This means that once - the key is no longer used to sign records, it should be retained in - the zone for at least the retire interval (Iret) given by: - - Iret = Dsgn + Dprp + TTLsig - - Dsgn is the delay needed to ensure that all existing RRsets have been - re-signed with the new key. Dprp is (as described above) the - propagation delay, required to guarantee that the updated zone - information has reached all slave servers, and TTLsig is the maximum - TTL of all the RRSIG records in the zone created with the ZSK. - - The time at which all RRSIG records created with this key have - expired from resolver caches is the dead time (Tdea), given by: - - Tdea = Tret + Iret - - ... at which point the key is said to be dead. - - Event 9: At any time after the key becomes dead, it can be removed - from the zone's DNSKEY RRset, which must then be re-signed with the - current key-signing key. This time is the removal time (Trem), given - by: - - - - - - -Morris, et al. Expires January 10, 2013 [Page 11] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - Trem >= Tdea - - ... at which time the key is said to be removed. - -3.2.2. Double-Signature Method - - The timeline for a double-signature rollover is shown below. The - diagram follows the convention described in Section 3.2.1 - - - - |1| |2| |3| |4| |5| - | | | | | - Key N | |<----Lzsk--->|<---Iret--->| | - | | | | | - Key N+1 | | |<-----Lzsk------- - - - | | | | | - Tgen Tact Tret Tdea Trem - - ---- Time ----> - - Figure 2: Timeline for a Double-Signature ZSK rollover. - - Event 1: Key N is generated at the generate time (Tgen). Although - there is no reason why the key cannot be generated immediately prior - to its publication in the zone (Event 2), some implementations may - find it convenient to create a pool of keys in one operation and draw - from that pool as required. For this reason, it is shown as a - separate event. Keys that are available for use but not published - are said to be generated. - - Event 2: Key N is added to the DNSKEY RRset and is then used to sign - the zone; existing signatures in the zone are not removed. This is - the activation time (Tact), after which the key is said to be active. - - Event 3: After the current key (key N) has been in use for its - intended lifetime (Lzsk), the successor key (key N+1) is introduced - into the zone and starts being used to sign RRsets: neither the - current key nor the signatures created with it are removed. The - successor is key is now active and the current key is said to be - retired. This time is the retire time of the key (Tret); it is also - the activation time of the successor key (TactS). - - Tret = Tact + Lzsk - - Event 4: Before key N can be withdrawn from the zone, all RRsets that - need to be signed must have been signed by the successor key (key - N+1) and any old RRsets that do not include the new key or new RRSIGs - - - -Morris, et al. Expires January 10, 2013 [Page 12] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - must have expired from caches. Note that the signatures are not - replaced - each RRset is signed by both the old and new key. - - This takes Iret, the retire interval, given by the expression: - - Iret = Dsgn + Dprp + max(TTLkey, TTLsig) - - As before, Dsgn is the delay needed to ensure that all existing - RRsets have been signed with the new key and Dprp is the propagation - delay. The final term (the maximum of TTLkey and TTLsig) is the - period to wait for key and signature data associated with key N to - expire from caches. (TTLkey is the TTL of the DNSKEY RRset and - TTLsig is the maximum TTL of all the RRSIG records in the zone - created with the ZSK. The two may be different: although the TTL of - an RRSIG is equal to the TTL of the RRs in the associated RRset - [RFC4034], the DNSKEY RRset only needs to be signed with the KSK.) - - At the end of this interval, key N is said to be dead. This occurs - at the dead time (Tdea) so: - - Tdea = Tret + Iret - - Event 5: At some later time key N and the signatures generated with - it can be removed from the zone. This is the removal time Trem, - given by: - - Trem >= Tdea - -3.2.3. Double-RRSIG Method - - The timeline for a double-signature rollover is shown below. The - diagram follows the convention described in Section 3.2.1 - - - - |1||2| |3| |4||5| |6| |7||8| |9| |10| - | | | | | | | | | | - Key N | |<-Dsgn->| | |<--------Lzsk-------->|<-Iret->| | - | |<---IpubG-->| | | | | | | - | | | | | | | | | | - Key N+1 | | | | | |<-IpubG->| | | | - | | | | | | | | | | - Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem - - ---- Time ----> - - Figure 3: Timeline for a Double-Signature ZSK rollover. - - - - -Morris, et al. Expires January 10, 2013 [Page 13] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - Event 1: Key N is generated at the generate time (Tgen). Although - there is no reason why the key cannot be generated immediately prior - to its publication in the zone (Event 2), some implementations may - find it convenient to create a pool of keys in one operation and draw - from that pool as required. For this reason, it is shown as a - separate event. Keys that are available for use but not published - are said to be generated. - - Event 2: Key N is used to sign the zone but existing signatures are - retained. Although the new ZSK is not published in the zone at this - point, for analogy with the other ZSK rollover methods and because - this is the first time that key information is visible (albeit - indirectly through the created signatures) this time is called the - publication time (Tpub). - - Event 3: After the signing interval, Dsgn, all RRsets that need to be - signed have been signed by the new key. (As a result, all these - RRsets are now signed twice, once by the (still-absent) key N and - once by its predecessor. - - Event 4: There is now a delay while the old signature information - expires from caches. This interval is given by the expression: - - Dprp + TTLsig - - As before, Dprp is the propagation delay and TTLsig is the maximum - TTL of all the RRSIG records in the zone created with the ZSK. - - Again in analogy with other key rollover methods, this is defined as - key N's ready time (Trdy) and the key is said to be in the ready - state. (Although the key is not in the zone, it is ready to be - used.) The interval between the publication and ready times is the - publication interval of the signature, IpubG, i.e., - - Trdy = Tpub + IpubG - - where - - IpubG = Dsgn + Dprp + TTLsig - - Event 5: At some later time the predecessor key is removed and the - key N added to the DNSKEY RRset. As all the signed RRs have - signatures created by the old and new keys, the records can still be - authenticated. This time is the activation time (Tact) and the key - is now said to be active. - - Event 6: At some point thought must be given to rolling the key. The - first step is to publish signatures created by the successor key (key - - - -Morris, et al. Expires January 10, 2013 [Page 14] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - N+1) early enough for key N to be replaced after it has been active - for its scheduled lifetime. This occurs at TpubS (the publication - time of the successor), given by: - - TpubS <= Tact + Lzsk - IpubG - - Event 7: The signatures have propagated and the new key could be - added to the zone. This time is the ready time of the successor key - (TrdyS). - - TrdyS = TpubS + IpubG - - ... where IpubG is as defined above. - - Event 8: At some later time key N is removed from the zone's DNSKEY - RRset and the successor key (key N+1) is added to it. This is the - retire time of the key (Tret). - - Event 9: The signatures must remain in the zone for long enough that - the new DNSKEY RRset has had enough time to propagate to all caches. - Once caches contain the new DNSKEY, the old signatures are no longer - of use and can be considered to be dead as they cannot be validated - by any key. In analogy with other rollover methods, the time at - which this occurs is the dead time (Tdea), given by: - - Tdea = Tret + Iret - - ... where Iret is the retire interval, given by: - - Iret = Dprp + TTLkey - - Dprp is as defined earlier and TTLkey is the TTL of the DNSKEY RRset. - - Event 10: At some later time the signatures can be removed from the - zone. In analogy with other rollover methods, this time is called - the remove time (Trem) and is given by: - - Trem >= Tdea - -3.3. Key-Signing Key Rollover Timelines - - The following sections describe the rolling of a KSK. They show the - events in the lifetime of a key (referred to as "key N") and cover it - replacement by its successor (key N+1). - - - - - - - -Morris, et al. Expires January 10, 2013 [Page 15] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - -3.3.1. Double-Signature Method - - The timeline for a double-signature rollover is shown below. The - diagram follows the convention described in Section 3.2.1 - - - - |1| |2| |3| |4| |5| - | | | | | - Key N | |<-Ipub->|<--->|<-Dreg->|<-----Lksk--- - - - | | | | | - Key N+1 | | | | | - | | | | | - Tgen Tpub Trdy Tsub Tact - - ---- Time ----> - - (continued ...) - - |6| |7| |8| |9| |10| |11| - | | | | | | - Key N - - -------------Lksk------->|<-Iret->| | - | | | | | | - Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - - - | | | | | | - TpubS TrdyS TsubS Tret Tdea Trem - - ---- Time (cont) ----> - - Figure 4: Timeline for a Double-Signature KSK rollover. - - Event 1: Key N is generated at the generate time (Tgen). Although - there is no reason why the key cannot be generated immediately prior - to its publication in the zone (Event 2), some implementations may - find it convenient to create a pool of keys in one operation and draw - from that pool as required. For this reason, it is shown as a - separate event. Keys that are available for use but not published - are said to be generated. - - Event 2: Key N is introduced into the zone; it is added to the DNSKEY - RRset, which is then signed by key N and all currently active KSKs. - (So at this point, the DNSKEY RRset is signed by both key N and its - predecessor KSK. If other KSKs were active, it is signed by these as - well.) This is the publication time (Tpub); after this the key is - said to be published. - - Event 3: Before it can be used, the key must be published for long - enough to guarantee that any validating resolver that has a copy of - - - -Morris, et al. Expires January 10, 2013 [Page 16] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - the DNSKEY RRset in its cache will have a copy of the RRset that - includes this key: in other words, that any prior cached information - about the DNSKEY RRset has expired. - - The interval is the publication interval (Ipub) and, for the second - or subsequent KSKs in the zone, is given by: - - Ipub = DprpC + TTLkey - - ... where DprpC is the propagation delay for the child zone (the zone - containing the KSK being rolled) and TTLkey the TTL for the DNSKEY - RRset. The time at which this occurs is the key's ready time, Trdy, - given by: - - Trdy = Tpub + Ipub - - (The case of introducing the first KSK into the zone is discussed in - Section 3.3.5.) - - Event 4: At some later time, the DS record corresponding to the new - KSK is submitted to the parent zone for publication. This time is - the submission time, Tsub. - - Event 5: The DS record is published in the parent zone. As this is - the point at which all information for authentication - both DNSKEY - and DS record - is available in the two zones, in analogy with other - rollover methods, this is called the activation time of the key - (Tact): - - Tact = Tsub + Dreg - - ... where Dreg is the registration delay, the time taken after the DS - record has been received by the parent zone manager for it to be - placed in the zone. (Parent zones are often managed by different - entities, and this term accounts for the organisational overhead of - transferring a record.) - - Event 6: While key N is active, thought needs to be given to its - successor (key N+1). At some time before the scheduled end of the - KSK lifetime, the successor KSK is published in the zone. (As - before, this means that the DNSKEY RRset is signed by both the - current and successor KSK.) This time is the publication time of the - successor key, TpubS, given by: - - TpubS <= Tact + Lksk - Dreg - Ipub - - ... where Lksk is the scheduled lifetime of the KSK. - - - - -Morris, et al. Expires January 10, 2013 [Page 17] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - Event 7: After an interval Ipub, key N+1 becomes ready (in that all - caches that have a copy of the DNSKEY RRset have a copy of this key). - This time is the ready time of the successor (TrdyS). - - Event 8: At the submission time of the successor (TsubS), the DS - record corresponding to key N+1 is submitted to the parent zone. - - Event 9: The successor DS record is published in the parent zone and - the current DS record withdrawn. The current key is said to be - retired and the time at which this occurs is Tret, given by: - - Tret = Tact + Lksk - - Event 10: Key N must remain in the zone until any caches that contain - a copy of the DS RRset have a copy containing the new DS record. - This interval is the retire interval, given by: - - Iret = DprpP + TTLds - - ... where DprpP is the propagation delay in the parent zone and TTLds - the TTL of a DS record in the parent zone. - - As the key is no longer used for anything, is said to be dead. This - point is the dead time (Tdea), given by: - - Tdea = Tret + Iret - - Event 11: At some later time, key N is removed from the zone's DNSKEY - RRset (at the remove time Trem); the key is now said to be removed. - - Trem >= Tdea - -3.3.2. Double-DS Method - - The timeline for a double-DS rollover is shown below. The diagram - follows the convention described in Section 3.2.1 - - - - - - - - - - - - - - - -Morris, et al. Expires January 10, 2013 [Page 18] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - |1| |2| |3| |4| |5| |6| - | | | | | | - Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - - - | | | | | | - Key N+1 | | | | |<---->|<--Dreg+IpubP- - - - | | | | | | - Tgen Tsub Tpub Trdy Tact TsubS - - ---- Time ----> - - (continued ...) - - |7| |8| |9| |10| - | | | | - Key N - - -----Lksk---------->|<-Iret->| | - | | | | - Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - - - | | | | - TrdyS Tret Tdea Trem - - ---- Time ----> - - Figure 5: Timeline for a Double-DS KSK rollover. - - Event 1: Key N is generated at the generate time (Tgen). Although - there is no reason why the key cannot be generated immediately prior - to its publication in the zone (Event 2), some implementations may - find it convenient to create a pool of keys in one operation and draw - from that pool as required. For this reason, it is shown as a - separate event. Keys that are available for use but not published - are said to be generated. - - Event 2: The DS RR is submitted to the parent zone for publication. - This time is the submission time, Tsub. - - Event 3: After the registration delay, Dreg, the DS record is - published in the parent zone. This is the publication time Tpub, - given by: - - Tpub = Tsub + Dreg - - Event 4: At some later time, any cache that has a copy of the DS - RRset will have a copy of the DS record for key N. At this point, key - N, if introduced into the DNSKEY RRset, could be used to validate the - zone. For this reason, this time is known as the key's ready time, - Trdy, and is given by: - - - - - -Morris, et al. Expires January 10, 2013 [Page 19] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - Trdy = Tpub + IpubP - - IpubP is the parent publication interval and is given by the - expression: - - IpubP = DprpP + TTLds - - ... where DprpP is the propagation delay for the parent zone and - TTLds the TTL assigned to DS records in that zone. - - Event 5: At some later time, the key rollover takes place and the new - key (key N) is introduced into the DNSKEY RRset and used to sign - that. - - As both the old and new DS records have been in the parent zone long - enough to ensure that they are in caches that contain the DS RRset, - the zone can be authenticated throughout the rollover - the - validating resolver either has a copy of the DNSKEY RRset - authenticated by the predecessor key, or it has a copy of the updated - RRset authenticated with the new key. - - This time is key N's activation time (Tact) and at this point the key - is said to be active. - - Event 6: At some point thought must be given to key replacement. The - DS record for the successor key must be submitted to the parent zone - at a time such that when the current key is withdrawn, any cache that - contains the zone's DS records has data about the DS record of the - successor key. The time at which this occurs is the submission time - of the successor, given by: - - TsubS <= Tact + Lksk - IpubP - Dreg - - ... where Lksk is the lifetime of key N according to policy. - - Event 7: The successor key (key N+1) enters the ready state, i.e., - its DS record is now in caches that contain the parent DS RRset. - This is the ready time of the successor key, TrdyS. - - (The interval between events 6 and 7 for the key N+1 correspond to - the interval between events 2 and 4 for key N) - - Event 8: When key N has been active for its lifetime (Lksk), it is - replaced in the DNSKEY RRset by key N+1; the RRset is then signed - with the new key. This is the retire time (Tret) of key N, given by: - - - - - - -Morris, et al. Expires January 10, 2013 [Page 20] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - Tret = Tact + Lksk - - Event 9: At some later time, all copies of the old DNSKEY RRset have - expired from caches and the old DS record is no longer needed. In - analogy with other rollover methods, this is called the dead time, - Tdea, and is given by: - - Tdea = Tret + Iret - - ... where Iret is the retire interval, given by: - - Iret = DprpC + TTLkey - - As before, this term includes DprpC, the time taken to propagate the - RRset change through the master-slave hierarchy of the child zone and - TTLkey, the time taken for the DNSKEY RRset to expire from caches. - - Event 10: At some later time, the DS record is removed from the - parent zone. In analogy with other rollover methods, this is the - removal time (Trem), given by: - - Trem >= Tdea - -3.3.3. Double-RRset Method - - The timeline for a double-RRset rollover is shown below. The diagram - follows the convention described in Section 3.2.1 - - - - |1| |2| |3| |4| |5| |6| - | | | | | | - Key N | |<-Ipub->|<-----Lksk----->| | - | | | | | | - Key N+1 | | | |<-Ipub->| | - | | | | | | - Tgen Tpub Tact TpubS Tret Trem - - ---- Time ----> - - Figure 6: Timeline for a Double-RRset KSK rollover. - - Event 1: Key N is generated at the generate time (Tgen). Although - there is no reason why the key cannot be generated immediately prior - to its publication in the zone (Event 2), some implementations may - find it convenient to create a pool of keys in one operation and draw - from that pool as required. For this reason, it is shown as a - separate event. Keys that are available for use but not published - - - -Morris, et al. Expires January 10, 2013 [Page 21] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - are said to be generated. - - Event 2: The key is added to and used for signing the DNSKEY RRset - and is thereby published in the zone. At the same time the - corresponding DS record is submitted to the parent zone for - publication. This time is the publish time (Tpub) and the key is now - said to be published. - - Event 3: At some later time, the DS record is published in the parent - zone and at some time after that, the updated information has reached - all caches: any cache that holds a DNSKEY RRset from the child zone - will have a copy that includes the new KSK, and any cache that has a - copy of the parent DS RRset will have a copy that includes the new DS - record. - - The time at which this occurs is called the activation time of the - new KSK (Tact), given by: - - Tact = Tpub + Ipub - - ... where Ipub is the publication interval, given by: - - Ipub = max(IpubP, IpubC), - - IpubP being the publication interval in the parent zone and IpubC the - publication interval in the child zone. The parent zone's - publication interval is given by: - - IpubP = Dreg + DprpP + TTLds - - where Dreg is the registration delay, the time taken for the DS - record to be published in the parent zone. DprpP is the parent - zone's propagation delay and TTLds is the TTL of the DS record in - that zone. - - The child's publication interval is given by a similar equation: - - IpubC = DprpC + TTLkey - - ... where DprpC is the propagation delay in the child zone and TTLkey - the TTL of a DNSKEY record. - - Event 4: At some point we need to give thought to key replacement. - The successor key (key N+1) must be introduced into the zone (and its - DS record submitted to the parent) at a time such that it becomes - active when the current key has been active for its lifetime, Lksk. - This time is TpubS, the publication time of the successor key, and is - given by: - - - -Morris, et al. Expires January 10, 2013 [Page 22] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - TpubS <= Tact + Lksk - Ipub - - ... where Lksk is the lifetime of the KSK. - - Event 5: Key N+1's DNSKEY and DS records are in any caches that - contain the child zone DNSKEY and/or the parent zone DS RR, and so - the zone can be validated with the new key. This is the activation - time of the successor key (TactS) and by analogy with other rollover - methods, it is also the retire time of the current key. Since at - this time the zone can be validated by the successor key, there is no - reason to keep the current key in the zone and the time can also be - regarded as the current key's dead time. Thus: - - Tret = Tdea = TactS = Tact + Lksk - - Event 6: At some later time, the key N's DS and DNSKEY records are - removed from their respective zones. In analogy with other rollover - methods, this is the removal time (Trem), given by: - - Trem >= Tdea - -3.3.4. Interaction with Configured Trust Anchors - - Although the preceding sections have been concerned with rolling KSKs - where the trust anchor is a DS record in the parent zone, zone - managers may want to take account of the possibility that some - validating resolvers may have configured trust anchors directly. - - Rolling a configured trust anchor is dealt with in [RFC5011]. It - requires introducing the KSK to be used as the trust anchor into the - zone for a period of time before use, and retaining it (with the - "revoke" bit set) for some time after use. - -3.3.4.1. Addition of KSK - - When the new key is introduced, the publication interval (Ipub) in - the Double-Signature and Double-RRset methods should also be subject - to the condition: - - Ipub >= Dprp + max(Itrp, TTLkey) - - ... where the right hand side of the expression is the time taken for - the change to propagate to all nameservers for the zone plus the - "trust point" interval. This latter term is the interval required to - guarantee that a resolver configured for the automatic update of keys - from a particular trust point will see at least two validated DNSKEY - RRsets containing the new key (a requirement from [RFC5011], section - 2.4.1). It is defined by the expression: - - - -Morris, et al. Expires January 10, 2013 [Page 23] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - Itrp >= (2 * queryInterval) + (n * retryTime) - - ... where queryInterval and retryTime are as defined in section 2.3 - of [RFC5011]. "n" is the total number of retries needed by the - resolver during the two attempts to get the DNSKEY RRset. - - The first term of the expression (2 * queryInterval) represents the - time to obtain two validated DNSKEY RRsets. The second term (n * - retryTime) is a safety margin, with the value of "n" reflecting the - degree of confidence in the communication between a resolver and the - trust point. - - In the Double-DS method, instead of swapping the KSK RRs in a single - step, there must now be a period of overlap. In other words, the new - KSK must be introduced into the zone at least: - - DprpC + max(Itrp, TTLkey) - - ... before the switch is made. - -3.3.4.2. Removal of KSK - - The timeline for the removal of the key in all methods is modified by - introducing a new state, "revoked". When the key reaches its dead - time, instead of being declared "dead", it is revoked; the "revoke" - bit is set in the published DNSKEY RR, and the DNSKEY RRset re-signed - with the current and revoked keys. The key is maintained in this - state for the "revoke" interval, Irev, given by: - - Irev >= 30 days - - ... 30 days being the [RFC5011] remove hold-down time. After this - time, the key is dead and can be removed from the zone. - -3.3.5. Introduction of First Keys - - There are no timing considerations associated with the introduction - of the first keys into a zone other that they must be introduced and - the zone validly signed before a chain of trust to the zone is - created. - - This is important: in the case of a secure parent, it means ensuring - that the DS record is not published in the parent zone until there is - no possibility that a validating resolver can obtain the record yet - is not able to obtain the corresponding DNSKEY. In the case of an - insecure parent, i.e., the initial creation of a new security apex, - it is not possible to guarantee this. It is up to the operator of - the validating resolver to wait for the new KSK to appear at all - - - -Morris, et al. Expires January 10, 2013 [Page 24] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - servers for the zone before configuring the trust anchor. - - -4. Standby Keys - - Although keys will usually be rolled according to some regular - schedule, there may be occasions when an emergency rollover is - required, e.g., if the active key is suspected of being compromised. - The aim of the emergency rollover is to allow the zone to be re- - signed with a new key as soon as possible. As a key must be in the - ready state to sign the zone, having at least one additional key (a - standby key) in this state at all times will minimise delay. - - In the case of a ZSK, a standby key only really makes sense with the - Pre-Publication method. A permanent standby DNSKEY RR should be - included in the zone or successor keys could be introduced as soon as - possible after a key becomes active. Either way results in one or - more additional ZSKs in the DNSKEY RRset that can immediately be used - to sign the zone if the current key is compromised. - - (Although in theory the mechanism could be used with both the Double- - Signature and Double-RRSIG methods, it would require pre-publication - of the signatures. Essentially, the standby key would be permanently - active, as it would have to be periodically used to renew signatures. - Zones would also permanently require two sets of signatures.) - - It is also possible to have a standby KSK. The Double-Signature - method requires that the standby KSK be included in the DNSKEY RRset; - rolling the key then requires just the introduction of the DS record - in the parent. Note that the standby KSK should also be used to sign - the DNSKEY RRset. As the RRset and its signatures travel together, - merely adding the KSK without using it to sign the DNSKEY RRset does - not provide the desired time saving: for a KSK to be used in a - rollover the DNSKEY RRset must be signed with it, and this would - introduce a delay while the old RRset (not signed with the new key) - expires from caches. - - The idea of a standby KSK in the Double-RRset rollover method - effectively means having two active keys (as the standby KSK and - associated DS record would both be published at the same time in - their respective zones). - - Finally, in the Double-DS method of rolling a KSK, it is not a - standby key that is present, it is a standby DS record in the parent - zone. - - Whatever algorithm is used, the standby item of data can be included - in the zone on a permanent basis, or be a successor introduced as - - - -Morris, et al. Expires January 10, 2013 [Page 25] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - early as possible. - - -5. Algorithm Considerations - - The preceding sections have implicitly assumed that all keys and - signatures are created using a single algorithm. However, [RFC4035] - (section 2.4) states that "There MUST be an RRSIG for each RRset - using at least one DNSKEY of each algorithm in the zone apex DNSKEY - RRset". - - Except in the case of an algorithm rollover - where the algorithms - used to create the signatures are being changed - there is no - relationship between the keys of different algorithms. This means - that they can be rolled independently of one another. In other - words, the key rollover logic described above should be run - separately for each algorithm; the union of the results is included - in the zone, which is signed using the active key for each algorithm. - - -6. Limitation of Scope - - This document represents current thinking at the time of publication. - However, the subject matter is evolving and it is more than likely - that this document will need to be revised in the future. - - Some of the techniques and ideas that DNSSEC operators are - considering differ from this those described in this document. Of - particular interest are alternatives to the strict split into KSK and - ZSK key roles and the consequences for rollover logic from partial - signing (i.e., when the new key initially only signs a fraction of - the zone while leaving other signatures generated by the old key in - place). - - Furthermore, as noted in section 5, this document covers only rolling - keys of the same algorithm: it does not cover transitions between - algorithms. The timing issues associated with algorithm rollovers - will require a separate document. - - The reader is therefore reminded that DNSSEC is, as of date of - publication, in the early stages of deployment, and best practices - may further develop over time. - - -7. Summary - - For ZSKs, "Pre-Publication" is generally considered to be the - preferred way of rolling keys. As shown in this document, the time - - - -Morris, et al. Expires January 10, 2013 [Page 26] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - taken to roll is wholly dependent on parameters under the control of - the zone manager. - - In contrast, "Double-RRset" is the most efficient method for KSK - rollover due to the ability to have new DS records and DNSKEY RRsets - propagate in parallel. The time taken to roll KSKs may depend on - factors related to the parent zone if the parent is signed. For - zones that intend to comply with the recommendations of [RFC5011], in - virtually all cases the rollover time will be determined by the - RFC5011 "add hold-down" and "remove hold-down" times. It should be - emphasized that this delay is a policy choice and not a function of - timing values and that it also requires changes to the rollover - process due to the need to manage revocation of trust anchors. - - Finally, the treatment of emergency key rollover is significantly - simplified by the introduction of standby keys as standard practice - during all types of rollovers. - - -8. IANA Considerations - - This memo includes no request to IANA. - - -9. Security Considerations - - This document does not introduce any new security issues beyond those - already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. - - -10. Acknowledgements - - The authors gratefully acknowledge help and contributions from Roy - Arends, Matthijs Mekking and Wouter Wijngaards. - - -11. Normative References - - [I-D.ietf-dnsop-rfc4641bis] - Kolkman, O. and M. Mekking, "DNSSEC Operational Practices, - Version 2", draft-ietf-dnsop-rfc4641bis-11 (work in - progress), April 2012. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - - - -Morris, et al. Expires January 10, 2013 [Page 27] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) - Trust Anchors", RFC 5011, September 2007. - - -Appendix A. List of Symbols - - The document defines a number of symbols, all of which are listed - here. All are of the form: - - All symbols used in the text are of the form: - - - - where: - - is an upper-case character indicating what type the symbol is. - Defined types are: - - D delay: interval that is a feature of the process - - I interval between two events - - L lifetime: interval set by the zone manager - - T a point in time - - TTL TTL of a record - - I and T and TTL are self-explanatory. Like I, both D and L are time - periods, but whereas I values are intervals between two events (even - if the events are defined in terms of the interval, e.g., the dead - time occurs "retire interval" after the retire time), D and L are - fixed intervals: a "D" interval (delay) is a feature of the process, - probably outside control of the zone manager, whereas an "L" interval - (lifetime) is chosen by the zone manager and is a feature of policy. - - is lower-case and defines what object or event the variable is - related to, e.g., - - - -Morris, et al. Expires January 10, 2013 [Page 28] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - act activation - - pub publication - - ret retire - - Finally, is a capital letter that distinguishes between the - same variable applying to different instances of an object and is one - of: - - C child - - G signature - - P parent - - S successor - - The list of variables used in the text is: - - Dprp Propagation delay. The amount of time for a change made at - a master nameserver to propagate to all the slave - nameservers. - - DprpC Propagation delay in the child zone. - - DprpP Propagation delay in the parent zone. - - Dreg Registration delay: the time taken for a DS record - submitted to a parent zone to appear in it. As a parent - zone is often managed by a different organisation to that - managing the child zone, the delays associated with passing - data between zones is captured by this term. - - Dsgn Signing delay. After the introduction of a new ZSK, the - amount of time taken for all the RRs in the zone to be - signed with it. - - Ipub Publication interval. The amount of time that must elapse - after the publication of a key before it can be assumed - that any resolvers that have the DNSKEY RRset cached have a - copy of this key. - - IpubC Publication interval in the child zone. - - - - - - - -Morris, et al. Expires January 10, 2013 [Page 29] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - IpubG Publication interval for the signature created by a ZSK: - the amount of time that must elapse after the signature has - been created before it can be assumed that any resolves - that have the RRset and RRSIG cached have a copy of this - signature. - - IpubP Publication interval in the parent zone. - - Iret Retire interval. The amount of time that must elapse after - a key enters the retire state for any signatures created - with it to be purged from validating resolver caches. - - Irev Revoke interval. The amount of time that a KSK must remain - published with the revoke bit set to satisfy [RFC5011] - considerations. - - Itrp Trust-point interval. The amount of time that a trust - anchor must be published for to guarantee that a resolver - configured for an automatic update of keys will see the new - key at least twice. - - Lksk Lifetime of a key-signing key. This is the intended amount - of time for which this particular KSK is regarded as the - active KSK. Depending on when the key is rolled-over, the - actual lifetime may be longer or shorter than this. - - Lzsk Lifetime of a zone-signing key. This is the intended - amount of time for which the ZSK is used to sign the zone. - Depending on when the key is rolled-over, the actual - lifetime may be longer or shorter than this. - - Tact Activation time of the key; the time at which the key is - regarded as the principal key for the zone. - - TactS Activation time of the successor key. - - Tdea Dead time of a key. Applicable only to ZSKs, this is the - time at which any record signatures held in validating - resolver caches are guaranteed to be created with the - successor key. - - Tgen Generate time of a key. The time that a key is created. - - Tpub Publication time of a key. The time that a key appears in - a zone for the first time. - - - - - - -Morris, et al. Expires January 10, 2013 [Page 30] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - TpubS Publication time of the successor key. - - Trem Removal time of a key. The time at which a key is removed - from the zone. - - Tret Retire time of a key. The time at which a successor key - starts being used to sign the zone. - - Trdy Ready time of a key. The time at which it can be - guaranteed that validating resolvers that have key - information from this zone cached have a copy of this key - in their cache. (In the case of KSKs, should the - validating resolvers also have DS information from the - parent zone cached, the cache must include information - about the DS record corresponding to the key.) - - TrdyS Ready time of a successor key. - - Tsub Submission time - the time at which the DS record of a KSK - is submitted to the parent. - - TsubS Submission time of the successor key. - - TTLds Time to live of a DS record (in the parent zone). - - TTLkey Time to live of a DNSKEY record. (By implication, this is - also the time to live of the signatures on the DNSKEY - RRset.) - - TTLsig The maximum time to live of all the RRSIG records in the - zone that were created with the ZSK. - - -Appendix B. Change History (To be removed on publication) - - o draft-ietf-dnsop-dnssec-key-timing-03 - * Clarifications of and corrections to wording (Marc Lampo, Alfred - Hoenes). - * Updated timings related to trust anchor interaction (Matthijs - Mekking). - * Updated RFC 4641 reference to 4641bis (Alfred Hoenes). - * Moved change history to end of document (Alfred Hoenes). - - o draft-ietf-dnsop-dnssec-key-timing-02 - * Significant re-wording of some sections. - * Removal of events noting change of state of predecessor key from - ZSK Double-RRSIG and Double-Signature methods. - * Change order of bullet points (and some wording) in section 1.1. - - - -Morris, et al. Expires January 10, 2013 [Page 31] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - - * Remove discussion of advantages and disadvantages of key roll - methods from section 2: draft is informative and does not give - recommendations. - * Removal of discussion of upper limit to retire time relationship - to signature lifetime. - * Remove timing details of first key in the zone and move - discussion of first signing of a zone to later in the document). - (Matthijs Mekking) - * Removal of redundant symbols from Appendix A. - - o draft-ietf-dnsop-dnssec-key-timing-01 - * Added section on limitation of scope. - - o draft-ietf-dnsop-dnssec-key-timing-00 - * Change to author contact details. - - o draft-morris-dnsop-dnssec-key-timing-02 - * General restructuring. - * Added descriptions of more rollovers (IETF-76 meeting). - * Improved description of key states and removed diagram. - * Provided simpler description of standby keys. - * Added section concerning first key in a zone. - * Moved [RFC5011] to a separate section. - * Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott Rose, Sion - Lloyd, Tony Finch). - - o draft-morris-dnsop-dnssec-key-timing-01 - * Use latest boilerplate for IPR text. - * List different ways to roll a KSK (acknowledgements to Mark - Andrews). - * Restructure to concentrate on key timing, not management - procedures. - * Change symbol notation (Diane Davidowicz and others). - * Added key state transition diagram (Diane Davidowicz). - * Corrected spelling, formatting, grammatical and style errors - (Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya). - * Added note that in the case of multiple algorithms, the - signatures and rollovers for each algorithm can be considered as - more or less independent (Alfred Hoenes). - * Take account of the fact that signing a zone is not atomic - (Chris Thompson). - * Add section contrasting pre-publication rollover with double - signature rollover (Matthijs Mekking). - * Retained distinction between first and subsequent keys in - definition of initial publication interval (Matthijs Mekking). - - o draft-morris-dnsop-dnssec-key-timing-00 - Initial draft. - - - -Morris, et al. Expires January 10, 2013 [Page 32] - -Internet-Draft DNSSEC Key Timing Considerations July 2012 - - -Authors' Addresses - - Stephen Morris - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - Phone: +1 650 423 1300 - Email: stephen@isc.org - - - Johan Ihren - Netnod - Franzengatan 5 - Stockholm, SE-112 51 - Sweden - - Phone: +46 8615 8573 - Email: johani@autonomica.se - - - John Dickinson - Sinodun Internet Technologies Ltd - Stables 4 Suite 11, Howbery Park - Wallingford, Oxfordshire OX10 8BA - UK - - Phone: +44 1491 818120 - Email: jad@sinodun.com - - - - - - - - - - - - - - - - - - - - - -Morris, et al. Expires January 10, 2013 [Page 33] - diff --git a/doc/draft/draft-ietf-dnsop-dnssec-trust-history-02.txt b/doc/draft/draft-ietf-dnsop-dnssec-trust-history-02.txt deleted file mode 100644 index 1700fc3bf2..0000000000 --- a/doc/draft/draft-ietf-dnsop-dnssec-trust-history-02.txt +++ /dev/null @@ -1,616 +0,0 @@ - - - -Domain Name System Operations W. Wijngaards -Internet-Draft O. Kolkman -Intended status: Standards Track NLnet Labs -Expires: December 31, 2010 June 29, 2010 - - - DNSSEC Trust Anchor History Service - draft-ietf-dnsop-dnssec-trust-history-02 - -Abstract - - When DNS validators have trusted keys, but have been offline for a - longer period, key rollover will fail and they are stuck with stale - trust anchors. History service allows validators to query for older - DNSKEY RRsets and pick up the rollover trail where they left off. - -Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on December 31, 2010. - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - - - -Wijngaards & Kolkman Expires December 31, 2010 [Page 1] - -Internet-Draft Trust History Service June 2010 - - - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -1. Introduction - - This memo defines a trust history service for DNS validators -- the - component in a resolver that performs DNSSEC [RFC4034] validation, - validator for short. - - A validator that has been offline or missed an (emergency) rollover - can use this service to reconfigure themselves with the current - trust-anchor. Using a newly defined resource record (RR) that links - old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY - RRsets and checks they form a chain to the latest key (see - Section 3). The lists of old DNSKEYS, linked with the TALINK RRs, do - not necessarily need to be published in the zone for which the DNSKEY - history is being maintained but can be published in any DNS domain. - We will call the entity that offers the trust history the History - Provider. The choice of the History Provider is made by the - maintainer of the validator, possibly based on a hint provided, using - the TALINK, by the zone owner. - - Section 2 provides background on the mechanism and usage. It looks - at the viewpoints of publishers and consumers of trust anchors, the - use of keys with revocation flags, and SEP flags. - - The algorithm that the validator uses to construct a history and - reconfigure a new key is detailed in Section 4, it uses the TALINK RR - type defined in Section 3. The algorithms for how providers of trust - history can fetch the DNSKEY data as published by the zone they track - and publish that are explained in Section 5. - -2. Motivation and Description - - Validators provide a service in DNSSEC that can be seen from two - ways. Seen from the publisher's point of view, they provide - assurance that the data as received is as it was when it left the - publisher's hands. In this way of looking at things, validators - provide a publication integrity service. The publisher can be - confident that nobody can alter the published data (if it is - validated), because any alteration will be detected. So it protects - a publisher from being seen to send someone to the wrong place. - - From the consumer's point of view, validators provide a reason to - trust the data from the network. In this view, the validator is - - - -Wijngaards & Kolkman Expires December 31, 2010 [Page 2] - -Internet-Draft Trust History Service June 2010 - - - making a claim about whether the data ought to be accepted or not. - This is subtly different from the publisher's point of view, because - the question for the consumer is not whether the data is safe while - the consumer is not looking, but whether the data is safe for the - consumer at the moment of consumption. Validation protects a - consumer from going to the wrong place. - - These two slightly different ways of looking at the situation result - in slightly different operational goals. Whereas publishers want to - make assertions about their data, by controlling the roll over of - keys, consumers want to get the best assurance that they can get that - the data they are consuming is correct. - - If a validator has been offline during a key rollover event for one - of its trust anchors, then the validator will be unable to validate - answers that need that trust anchor. For the publisher, this state - of affairs is acceptable: the publisher is confident that no - validator ever consumes the wrong data. For the consumer, however, - this state of affairs represents an outage. - - Since publishers of trust anchors already use a chained series of - keys to perform rollovers under some circumstances (see [RFC5011]), - it is possible to use the history of that chain to allow a validator - to resume service for the consumer without needing to use an out-of- - band mechanism to obtain a new trust anchor. This improves the - experience for consumers of validated data, and increases the chances - that DNSSEC is useful for consumers of DNS data. - - The mechanism to do this is a double-linked list that recounts a - portion of the history of DNSKEY Resource Records. The list is used - by a validator to catch up with the changes that the validator - somehow missed. This approach may be thought of as replaying the - [RFC5011] rollover history, only at a later time. - -2.1. Considerations for Using a Revoked Key - - The keys that the publisher rolled are marked REVOKED by the RFC5011 - protocol. At this point the publisher considers the keys revoked, - but the validators have not yet seen this or marked the keys as - revoked. In the RFC5011 protocol, the validators probe regularly and - can then see if keys are revoked. If unable to probe, they will be - unable to see if keys are revoked. Hence when using a history to - recount rollovers, the consumer's validator has also missed a number - of revocations. The goal is to pick up the right keys and also the - new revocations along the way. - - Although the keys have been marked by the publisher as REVOKED a long - time ago, for the consumer these REVOKED keys are new information. - - - -Wijngaards & Kolkman Expires December 31, 2010 [Page 3] - -Internet-Draft Trust History Service June 2010 - - - Their storage in the history list makes it possible for consumers to - pick up key revocations if they missed the revocation announcement - because they could not probe. - - This is the allowed usage of REVOKED keys. The publisher is - announcing their presence. And the validators mark them as REVOKED - after verification. The initial part of this verification is the - reverse walk through the history list, which is to avoid exposing - which key is trusted. This means that older signatures with keys - that have in the meantime been revoked are used to construct and - verify the history list by the validator. - - A consequence is that once a publisher marks keys as REVOKED, there - will still be consumers who are using such keys, because they have - not seen the revocation. From the publishers point of view they are - revoked and the revocation is filed in the historical key list. From - the consumers point of view, it has not seen a revocation yet, and a - historical key list lookup algorithm is a state change where a new - trusted key is obtained while the old key is observed to be revoked. - -2.2. Motivation for Requiring the SEP Bit - - The SEP bit is used to differentiate Key Signing Keys from other - keys. It is defined in [RFC3757], it is used to designate trust - anchors in [RFC5011]. The protocol herein specified requires that - DNSKEYs that are subject to use for the trust history service have - the SEP bit set. The reason for this is to keep the set of keys that - need to be stored in history small. - -3. The TALINK Resource Record - - The DNS Resource Record type TALINK (decimal 58) ties the elements of - a linked list of DNSKEY RRs together. - - The rdata consists of two domain names. The first name is the start, - or previous name, and the other name the end or next name in the - list. The empty label '.' is used at the endpoints of the list. - - The presentation format is the two domain names. The wire encoding - is the two domain names, with no compression so the type can be - treated according to [RFC3597]. The list is a double linked list, - because this empowers low memory hosts to perform consistency checks. - - The TALINK used at the zone apex holds the endpoints of the list. - The TALINKs that form the lists hold previous and next entries. - These TALINKs are distinguished by their usage (entrypoint or list - connection). The double linked list is not circular, because lookups - must stop when they reach the oldest entry. - - - -Wijngaards & Kolkman Expires December 31, 2010 [Page 4] - -Internet-Draft Trust History Service June 2010 - - -4. Trust History Lookup - - This is the algorithm that a validator uses to detect and resolve the - situation in which a trust-anchor is out of sync with the DNSKEYs - published by a zone owner. The algorithm uses the TALINK RR type - which is used to link various old DNSKEYs as published by the History - Provider, to arrive from the outdated configured Trust Anchor to one - that matches the current DNSKEY. The TALINK RR type is defined in - Section 3. - - When the algorithm below results in failure the trust history cannot - be built and a new trust anchor will need to be re-configured using - another mechanism. - - Step 1: The validator performs a DNSKEY lookup to the target zone, - which looks like any other initial DNSKEY lookup that the - validator needs to match a trust anchor to the currently used - DNSKEY RR set. If the keyset verifies with the trust anchor - currently held, the trust-anchor is not out of sync. Otherwise, - store the DNSKEY RR set as result. The algorithm will - successfully build a linked list to this DNSKEY RR, or delete the - trust point, or fail. - - All nameservers (the ones authoritative for the zone or the - upstream resolver caches when the validator is not full resolver) - SHOULD be checked to make sure the DNSKEY RR sets are the same. - The results can differ if a key-rollover is in progress and not - all nameservers are in sync yet. This case can be detected by - checking that the older keyset signs the newer and take the newer - as result keyset. If both of the keysets sign each other, the - result keyset has the newest rrsig that validates it using the - other keyset. Use the the average over the middle of the - inception and expiration dates of the signatures that are - validated (and for serial arithmetic assume all dates on these - signatures lie within 2^(SERIAL_BITS-1) distance). If the keysets - do not sign each other then this is not a secure change in the - keyset and the history lookup fails. - - Step 2: Fetch the trust history list end points. Perform a query of - QTYPE TALINK and QNAME the domain name that is configured to be - the History Provider for the particular domain you are trying to - update the trust-anchor for. - - Step 3: Go backwards through the trust history list as provided by - the TALINK linked list. Verify that the keyset validly signs the - next keyset. This is [RFC4034] validation, but the RRSIG - expiration date is ignored. Replace the owner domain name with - the target zone name for verification. One of the keys that signs - - - -Wijngaards & Kolkman Expires December 31, 2010 [Page 5] - -Internet-Draft Trust History Service June 2010 - - - the next keyset MUST have the SEP bit set. The middle of - inception and expiration date from the valid signature MUST be - older than that of the signature that validates the next keys in - the list. Take the average if multiple signatures validate (and - for serial arithmetic assume all dates on these signatures lie - within 2^(SERIAL_BITS-1) distance). Query type TALINK to get - previous and next locations. - - If all SEP keys have the REVOKE flag set at this step, and the - keyset is signed by all SEP keys, then continue but store that the - end result is that the trust point is deleted, see Section 5 - [RFC5011]. - - If all SEP keys are of an unknown algorithm at this step, continue - and at the next step, when you verify if the keyset signs validly: - if false, continue with result a failure, if true, continue with - the end result that the trust point is deleted. Thus, the keysets - with unknown algorithms are stepped over with an end result of - failure because the validator cannot determine if unknown - algorithm signatures are valid, until the oldest keyset with - unknown algorithms is signed by a known algorithm and the result - is set to deletion and step 3 continues to a known key. - - Step 4: When the trust anchor currently held by the validator - verifies the keyset, the algorithm is done. The validator SHOULD - store the result on stable storage. Use the new trust anchor for - validation (if using [RFC5011], put it in state VALID). - -5. Trust History Tracker - - External trackers can poll the target zone DNSKEY RRset regularly. - Ignore date changes in the RRSIG. Ignore changes to keys with no SEP - flag. Copy the newly polled DNSKEY RRset and RRSIGs, change the - owner name to a new name at the history location. Publish the new - RRset and TALINK records to make it the last element in the list. - Update the TALINK that advertises the first and last name. - - Integrated into the rollover, the keys are stored in the history and - the TALINK is updated when a new key is used in the rollover process. - This gives the TALINK and new historical key time to propagate. - - The signer can support trust history. Trust history key sets need - only contain SEP keys. To use older signers, move historical RRSIGs - to another file. Sign the zone, including the TALINK and DNSKEY - records. Append the historical RRSIGs to the result. Signing the - zone like this obviates the need for changes to signer and server - software. - - - - -Wijngaards & Kolkman Expires December 31, 2010 [Page 6] - -Internet-Draft Trust History Service June 2010 - - -6. Example - - In this example the trust history for the 'example.net' zone is - published in the 'example.com' namespace. The DNSKEY rdata and RRSIG - rdata is omitted for brevity, it is a copy and paste of the data from - example.net. - - $ORIGIN example.com. - example.com. TALINK h0.example.com. h2.example.com. - - h0 TALINK . h1.example.com. - h0 DNSKEY ... - h0 RRSIG ... - - h1 TALINK h0.example.com. h2.example.com. - h1 DNSKEY ... - h1 RRSIG ... - - h2 TALINK h1.example.com. . - h2 DNSKEY ... - h2 RRSIG ... - - The example.net zone can advertise the example.com History Provider - by providing the TALINK shown here at example.com at the apex of the - example.net zone. The TALINK at example.com is then not needed. - -7. Deployment - - The trust history is advertised with TALINK RRs at the zone apex. - These represent alternative history sources, that can be searched in - turn. The TALINK at the zone apex contains the first and last name - of the list of historical keys. - - The historical list of keys grows perpetually. Since most validators - have recent keys, their processing time remains similar as the list - grows. If validators no longer have trust in the keys then they need - no longer be published. The oldest key entries can be omitted from - the list to shorten it. - - The validator decides how long it trusts a key. A recommendation - from the zone owner can be configured for keys of that zone, or - recommendations per algorithm and key size can be used (e.g. see - [NIST800-57]). If a key is older than that, trust history lookup - fails with it and the trust point can be considered deleted. This - assumes the validator has decided on a security policy and also can - take actions when the update of the trust anchor fails. Without such - policy, or if the alternative is no DNSSEC, the approach below can be - used. - - - -Wijngaards & Kolkman Expires December 31, 2010 [Page 7] - -Internet-Draft Trust History Service June 2010 - - - In general, the decision can be that any key - no matter how old or - how small - is better than no security. The validator then never - considers a key too old, and the lookup algorithm becomes an - unsecured update mechanism at the time where the key can be trivially - broken. The history provider SHOULD provide these broken keys to - facilitate clients performing the unsecured update. If a key can not - be trivially broken then it provides a non-trivial amount of security - that the history lookup algorithm uses to get the current keys. - Conceivably after the update the result is stored on stable storage - and the client is thereafter safe - it performs a leap of faith. The - validator operator can opt for this set up after considering the - trade-off between loss of DNSSEC, loss of connectivity, and the - argument that perceived security is worse than no security. - - The history lookup can be used on its own. Then, the trust history - is used whenever the key rolls over and no polling is performed. The - results of trust history lookup SHOULD be stored on stable storage, - so that the trust history lookup does not need to be performed if the - last results are okay and for use as trusted anchor in the next - history lookup. - - If a validator is also using [RFC5011] for the target zone, then the - trust history algorithm SHOULD only be invoked if the [RFC5011] - algorithm failed due to the inability to perform probes. This is the - case when the last [RFC5011] successful probe was more than 30 days - ago. If a new key has been announced, invoke the history if no 2 - probes succeeded during the add hold-down time and there was no - successful probe after the add hold-down time passed. Therefore the - time of the last successful probe MUST be stored on stable storage. - - For testing the potentially very infrequently used lookup, the - following SHOULD be implemented. For the test the lookup is - triggered manually by allowing the system to be given a particular - keyset with a last successful lookup date in the past and a test - History Provider. The test History Provider provides access to a - generated back-dated test history. - -8. Security Considerations - - The History Provider only provides copies of old data. If that - historic data is altered or withheld the lookup algorithm fails - because of validation errors in Step 3 of the algorithm. If the - History provider or a Man in the Middle Adversary (MIMA) has access - to the original private keys (through theft, cryptanalisis, or - otherwise), history can be altered without failure of the algorithm. - Below we only consider MIMAs and assume the History Provider is a - trusted party. - - - - -Wijngaards & Kolkman Expires December 31, 2010 [Page 8] - -Internet-Draft Trust History Service June 2010 - - - Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of - TALINK and DNSKEY data, can present some alternate history. However - the DNSKEY RR set trusted that the history should arrive at is - already fixed by step 1. If an attempt is made to subvert the - algorithm at step 2 or 3, then the result keyset can not be replaced - by another keyset unnoticed. - - To change the keyset trusted as the outcome, the step 1 data has to - be spoofed and the key held by the validator (or a newer historic - key) has to be compromised. Unless such spoof is targeted to a - specific victim, a spoof of the step 1 result has a high visibility. - Since most of the validators that receive the spoof have an up-to- - date trust anchor most validators that would receive this spoof - return validation failure for data from the zone that contains the - DNSKEYs. An adversary will therefore have to target the attack to - validators that are in the process of an update. Since validators do - not announce that they use trust history lookup until step 2 - adversaries will not be able to select the validators. - - A spoof of data in steps 2 and 3, together with a compromised (old) - key, can result in a downgrade. At steps 2 and 3 a faked trust point - deletion or algorithm rollover can be inserted in a fake history. - This avoids the high visibility of spoofing the current key (see - previous paragraph) and downgrades to insecure. - - Finally there is the case that one of the keys published by the - History Providers has been compromised. Since someone spoofing at - step 1 of the lookup algorithm and presenting some fake history to a - compromised key, of course does not include key revocations and does - extend the history to contain the compromised key, it therefore is - not really useful for a History Provider to remove the key from the - published history. That only makes lookups fail for those validators - who are not under attack. Useful action could be to update - validators using some other means. - - Rollover with [RFC5011] revokes keys after use. If a History - Provider is used, then such revoked keys SHOULD be used to perform - history tracking and history lookup. The trust anchor keys that the - validator has in its own storage and final current keys that it - stores MUST NOT be trusted if they are revoked. - - If the validator operator chooses to operate trust history without - also using [RFC5011] the trust anchor does not get hold-down timer - protection. This has associated risks, in that the immediate - rollover without timeout that it provides could be abused (if private - keys are compromised). Such abuse could result in the stored lookup - results to become compromised. The key changes can be logged, to - inform operators and keep an audit trail. - - - -Wijngaards & Kolkman Expires December 31, 2010 [Page 9] - -Internet-Draft Trust History Service June 2010 - - - The SEP bit is checked to make sure that control over the KSK is - necessary to change the keyset for the target zone. - - The algorithm can be used to get the inception and expiration times - of signatures on the current keyset, a clock. A MIMA can attempt to - shorten history and put back that clock, but the algorithm attempts - to make this difficult to target and highly visible to others. - - If the clock of the validator can be influenced, then setting it - forward is unlikely to give advantage, but setting it backward - enables a replay attack of old DNSSEC data and signatures. This - vulnerability exists also in plain DNSSEC. - -9. IANA Considerations - - Resource record type TALINK has been defined using RFC5395 expert - review, it has RR type number 58 (decimal). - -10. Acknowledgments - - Thanks to the people who provided review and suggestions, Peter Koch, - Andrew Sullivan, Joe Abley, George Barwood, Edward Lewis, Michael - StJohns, Bert Hubert, Mark Andrews, Ted Lemon, Steve Crocker, Bill - Manning, Eric Osterweil, Wolfgang Nagele, Alfred Hoenes, Olafur - Gudmundsson, Roy Arends and Matthijs Mekking. - -11. References - -11.1. Informative References - - [NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. - Smid, "Recommendations for Key Management", NIST - SP 800-57, March 2007. - - [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name - System KEY (DNSKEY) Resource Record (RR) Secure Entry - Point (SEP) Flag", RFC 3757, April 2004. - - [RFC5011] StJohns, M., "Automated Updates of DNS Security - (DNSSEC) Trust Anchors", RFC 5011, September 2007. - -11.2. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource - Record (RR) Types", RFC 3597, September 2003. - - - -Wijngaards & Kolkman Expires December 31, 2010 [Page 10] - -Internet-Draft Trust History Service June 2010 - - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security - Extensions", RFC 4034, March 2005. - -Authors' Addresses - - Wouter Wijngaards - NLnet Labs - Science Park 140 - Amsterdam 1098 XG - The Netherlands - - EMail: wouter@nlnetlabs.nl - - - Olaf Kolkman - NLnet Labs - Science Park 140 - Amsterdam 1098 XG - The Netherlands - - EMail: olaf@nlnetlabs.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wijngaards & Kolkman Expires December 31, 2010 [Page 11] - diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt deleted file mode 100644 index bcd0d14e4b..0000000000 --- a/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt +++ /dev/null @@ -1,396 +0,0 @@ - - - - - - -INTERNET-DRAFT D. Senie -Category: BCP Amaranth Networks Inc. -Expires in six months July 2005 - - Encouraging the use of DNS IN-ADDR Mapping - draft-ietf-dnsop-inaddr-required-07.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - -Abstract - - Mapping of addresses to names has been a feature of DNS. Many sites, - implement it, many others don't. Some applications attempt to use it - as a part of a security strategy. The goal of this document is to - encourage proper deployment of address to name mappings, and provide - guidance for their use. - -Copyright Notice - - Copyright (C) The Internet Society. (2005) - -1. Introduction - - The Domain Name Service has provision for providing mapping of IP - addresses to host names. It is common practice to ensure both name to - address, and address to name mappings are provided for networks. This - practice, while documented, has never been required, though it is - generally encouraged. This document both encourages the presence of - - - -Senie [Page 1] - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 - - - these mappings and discourages reliance on such mappings for security - checks. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -2. Discussion - - - From the early days of the Domain Name Service [RFC883] a special - domain has been set aside for resolving mappings of IP addresses to - domain names. This was refined in [RFC1035], describing the .IN- - ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA - was added [RFC3152]. This document uses IPv4 CIDR block sizes and - allocation strategy where there are differences and uses IPv4 - terminology. Aside from these differences, this document can and - should be applied to both address spaces. - - The assignment of blocks of IP address space was delegated to three - regional registries. Guidelines for the registries are specified in - [RFC2050], which requires regional registries to maintain IN-ADDR - records on the large blocks of space issued to ISPs and others. - - ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger - allocations. For smaller allocations, ARIN can provide IN-ADDR for - /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to - update IN-ADDR, however the present version of its policy document - for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft - copies of this document. As of this writing, it appears APNIC has no - actual policy on IN-ADDR. RIPE appears to have the strongest policy - in this area [RIPE302] indicating Local Internet Registries should - provide IN-ADDR services, and delegate those as appropriate when - address blocks are delegated. - - As we can see, the regional registries have their own policies for - recommendations and/or requirements for IN-ADDR maintenance. It - should be noted, however, that many address blocks were allocated - before the creation of the regional registries, and thus it is - unclear whether any of the policies of the registries are binding on - those who hold blocks from that era. - - Registries allocate address blocks on CIDR [RFC1519] boundaries. - Unfortunately the IN-ADDR zones are based on classful allocations. - Guidelines [RFC2317] for delegating on non-octet-aligned boundaries - exist, but are not always implemented. - -3. Examples of impact of missing IN-ADDR - - - -Senie [Page 2] - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 - - - These are some examples of problems that may be introduced by - reliance on IN-ADDR. - - Some applications use DNS lookups for security checks. To ensure - validity of claimed names, some applications will look up IN-ADDR - records to get names, and then look up the resultant name to see if - it maps back to the address originally known. Failure to resolve - matching names is seen as a potential security concern. - - Some FTP sites will flat-out reject users, even for anonymous FTP, if - the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when - itself resolved, does not match. Some Telnet servers also implement - this check. - - Web sites are in some cases using IN-ADDR checks to verify whether - the client is located within a certain geopolitical entity. This - approach has been employed for downloads of crypto software, for - example, where export of that software is prohibited to some locales. - Credit card anti-fraud systems also use these methods for geographic - placement purposes. - - The popular TCP Wrappers program found on most Unix and Linux systems - has options to enforce IN-ADDR checks and to reject any client that - does not resolve. This program also has a way to check to see that - the name given by a PTR record then resolves back to the same IP - address. This method provdes more comfort but no appreciable - additional security. - - Some anti-spam (anti junk email) systems use IN-ADDR to verify the - presence of a PTR record, or validate the PTR value points back to - the same address. - - Many web servers look up the IN-ADDR of visitors to be used in log - analysis. This adds to the server load, but in the case of IN-ADDR - unavailability, it can lead to delayed responses for users. - - Traceroutes with descriptive IN-ADDR naming proves useful when - debugging problems spanning large areas. When this information is - missing, the traceroutes take longer, and it takes additional steps - to determine that network is the cause of problems. - - Wider-scale implementation of IN-ADDR on dialup, wireless access and - other such client-oriented portions of the Internet would result in - lower latency for queries (due to lack of negative caching), and - lower name server load and DNS traffic. - -4. Recommendations - - - - -Senie [Page 3] - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 - - - 4.1 Delegation Recommendations - - - Regional Registries and any Local Registries to whom they delegate - should establish and convey a policy to those to whom they delegate - blocks that IN-ADDR mappings are recommended. Policies should - recommend those receiving delegations to provide IN-ADDR service - and/or delegate to downstream customers. - - Network operators should define and implement policies and procedures - which delegate IN-ADDR to their clients who wish to run their own IN- - ADDR DNS services, and provide IN-ADDR services for those who do not - have the resources to do it themselves. Delegation mechanisms should - permit the downstream customer to implement and comply with IETF - recommendations application of IN-ADDR to CIDR [RFC2317]. - - All IP address space assigned and in use should be resolved by IN- - ADDR records. All PTR records must use canonical names. - - All IP addresses in use within a block should have an IN-ADDR - mapping. Those addresses not in use, and those that are not valid for - use (zeros or ones broadcast addresses within a CIDR block) need not - have mappings. - - It should be noted that due to CIDR, many addresses that appear to be - otherwise valid host addresses may actually be zeroes or ones - broadcast addresses. As such, attempting to audit a site's degree of - compliance may only be done with knowledge of the internal subnet - architecture of the site. It can be assumed, however, any host that - originates an IP packet necessarily will have a valid host address, - and must therefore have an IN-ADDR mapping. - -4.2 Application Recommendations - - - Applications SHOULD NOT rely on IN-ADDR for proper operation. The use - of IN-ADDR, sometimes in conjunction with a lookup of the name - resulting from the PTR record provides no real security, can lead to - erroneous results and generally just increases load on DNS servers. - Further, in cases where address block holders fail to properly - configure IN-ADDR, users of those blocks are penalized. - -5. Security Considerations - - This document has no negative impact on security. While it could be - argued that lack of PTR record capabilities provides a degree of - anonymity, this is really not valid. Trace routes, whois lookups and - other sources will still provide methods for discovering identity. - - - -Senie [Page 4] - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 - - - By recommending applications avoid using IN-ADDR as a security - mechanism this document points out that this practice, despite its - use by many applications, is an ineffective form of security. - Applications should use better mechanisms of authentication. - -6. IANA Considerations - - There are no IANA considerations for this document. - -7. References - -7.1 Normative References - - [RFC883] P.V. Mockapetris, "Domain names: Implementation - specification," RFC883, November 1983. - - [RFC1035] P.V. Mockapetris, "Domain Names: Implementation - Specification," RFC 1035, November 1987. - - [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR): - an Address Assignment and Aggregation Strategy," RFC 1519, September - 1993. - - [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", - RFC 2026, BCP 9, October 1996. - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation - Guidelines", RFC2050, BCP 12, Novebmer 1996. - - [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," - RFC 2317, March 1998. - - [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August - 2001. - -7.2 Informative References - - [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date - unknown, http://www.arin.net/regserv/initial-isp.html - - [APNIC] "Policies For IPv4 Address Space Management in the Asia - Pacific Region," APNIC-086, 13 January 2003. - - [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6 - Address Space in the RIPE NCC Service Region", RIPE-302, April 26, - - - -Senie [Page 5] - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 - - - 2004. http://www.ripe.net//ripe/docs/rev-del.html - - - -8. Acknowledgements - - Thanks to Peter Koch and Gary Miller for their input, and to many - people who encouraged me to write this document. - -9. Author's Address - - Daniel Senie - Amaranth Networks Inc. - 324 Still River Road - Bolton, MA 01740 - - Phone: (978) 779-5100 - - EMail: dts@senie.com - -10. Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided - on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, - EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT - THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR - ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A - PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed - to pertain to the implementation or use of the technology - described in this document or the extent to which any license - under such rights might or might not be available; nor does it - represent that it has made any independent effort to identify any - such rights. Information on the procedures with respect to - rights in RFC documents can be found in BCP 78 and BCP 79. - - - - -Senie [Page 6] - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 - - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use - of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository - at http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention - any copyrights, patents or patent applications, or other - proprietary rights that may cover technology that may be required - to implement this standard. Please address the information to the - IETF at ietf-ipr@ietf.org. - - Internet-Drafts are working documents of the - Internet Engineering Task Force (IETF), its areas, and its - working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of - six months and may be updated, replaced, or obsoleted by - other documents at any time. It is inappropriate to use - Internet-Drafts as reference material or to cite them other - than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be - accessed at http://www.ietf.org/shadow.html - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - -Senie [Page 7] - diff --git a/doc/draft/draft-ietf-dnsop-respsize-14.txt b/doc/draft/draft-ietf-dnsop-respsize-14.txt deleted file mode 100644 index d95634eda3..0000000000 --- a/doc/draft/draft-ietf-dnsop-respsize-14.txt +++ /dev/null @@ -1,784 +0,0 @@ - - - -Internet Engineering Task Force P. Vixie -Internet-Draft Internet Systems Consortium -Intended status: Informational A. Kato -Expires: November 11, 2012 Keio University/WIDE Project - May 10, 2012 - - - DNS Referral Response Size Issues - draft-ietf-dnsop-respsize-14 - -Abstract - - With a mandated default minimum maximum UDP message size of 512 - octets, the DNS protocol presents some special problems for zones - wishing to expose a moderate or high number of authority servers (NS - RRs). This document explains the operational issues caused by, or - related to this response size limit, and suggests ways to optimize - the use of this limited space. Guidance is offered to DNS server - implementors and to DNS zone operators. - -Status of this Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on November 11, 2012. - -Copyright Notice - - Copyright (c) 2012 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - - - -Vixie & Kato Expires November 11, 2012 [Page 1] - -Internet-Draft DNS Referral Response Size May 2012 - - - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. - - -1. Introduction and Overview - - The original DNS standard limited the UDP message size to 512 octets - (see Section 4.2.1 of [RFC1035]). Even though this limitation was - due to the required minimum IP reassembly limit for IPv4, it became a - hard DNS protocol limit and is not implicitly relaxed by changes in a - network layer protocol, for example to IPv6. - - The EDNS (Extension Mechanisms for DNS) protocol extension starting - with version 0 permits larger responses by mutual agreement of the - requester and responder (see Section 4.3 and Section 6.2 of - [RFC2671bis]), and it is recommended to support EDNS. The 512 octets - UDP message size limit will remain in practical effect until - virtually all DNS servers and resolvers support EDNS. - - Since DNS responses include a copy of the request, the space - available for response data is somewhat less than the full 512 - octets. Negative responses are quite small, but for positive and - referral responses, every octet must be carefully and sparingly - allocated. While the response size of positive responses is also a - concern in [RFC3226], this document specifically addresses referral - response size. - - While more than twelve years passed since the publication of the - original EDNS0 document [RFC2671], approximately 65% of the clients - support it as observed at a root name server and this fraction has - not changed in recent few years. The long tail of EDNS deployment - may eventually be measured in decades. - - Even if EDNS deployment reached 100% of all DNS initiators and - responders there will still be cases when path MTU limitations or IP - - - -Vixie & Kato Expires November 11, 2012 [Page 2] - -Internet-Draft DNS Referral Response Size May 2012 - - - fragmentation/reassembly problems in firewalls and other middleboxes - will cause EDNS failures which leads to non-extended DNS retries. A - smaller referral response will always be better than a larger one if - the same end result can be achieved either way. See [RFC5625], - [SSAC035], and Section 6.2.6 of [RFC2671bis] for details. - - -2. Delegation Details - -2.1. Relevant Protocol Elements - - A positive delegation response will include the following elements: - - Header Section: fixed length (12 octets) - Question Section: original query (name, class, type) - Answer Section: empty, or a CNAME/DNAME chain - Authority Section: NS RRset (nameserver names) - Additional Section: A and AAAA RRsets (nameserver addresses) - Note: CNAME defines a canonical name ([RFC1034]) while DNAME maps an - entire subtree to another domain ([RFC2672]). - - If the total size of the UDP response exceeds 512 octets or the size - advertised in EDNS, and if the data that does not fit was "required", - then the TC bit will be set (indicating truncation). This will - usually cause the requester to retry using TCP, depending on what - information was desired and what information was omitted. For - example, truncation in the authority section is of no interest to a - stub resolver who only plans to consume the answer section. If a - retry using TCP is needed, the total cost of the transaction is much - higher. See Section 6.1.3.2 of [RFC1123] for details on the - requirement that UDP be attempted before falling back to TCP. - - RRsets (Resource Record Set, see [RFC2136]) are never sent partially - unless the TC bit is set to indicate truncation. When the TC bit is - set, the final apparent RRset in the final non-empty section must be - considered "possibly damaged" (see Section 6.2 of [RFC1035] and - Section 9 of [RFC2181]). - - With or without truncation, the glue present in the additional data - section should be considered "possibly incomplete", and requesters - should be prepared to re-query for any damaged or missing RRsets. - Note that truncation of the additional data section might not be - signaled via the TC bit since additional data is often optional (see - discussion in Appendix B of [RFC4472]). - - DNS label compression allows the component labels of a domain name to - be instantiated exactly once per DNS message, and then referenced - with a two-octet "pointer" from other locations in that same DNS - - - -Vixie & Kato Expires November 11, 2012 [Page 3] - -Internet-Draft DNS Referral Response Size May 2012 - - - message (see Section 4.1.4 of [RFC1035]). If all nameserver names in - a message share a common parent (for example, all of them are in - "ROOT-SERVERS.NET." zone), then more space will be available for - incompressible data (such as nameserver addresses). - - The query name can be as long as 255 octets of network data. In this - worst case scenario, the question section will be 259 octets in size, - which would leave only 240 octets for the authority and additional - sections (after deducting 12 octets for the fixed length header) in a - referral. - -2.2. Advice to Zone Owners - - Average and maximum question section sizes can be predicted by the - zone owner, since they will know what names actually exist and can - measure which ones are queried for most often. Note that if the zone - contains any wildcards, it is possible for maximum length queries to - require positive responses, but that it is reasonable to expect - truncation and TCP retry in that case. For cost and performance - reasons, the majority of requests should be satisfied without - truncation or TCP retry. - - Some queries to non-existing names can be large, but this is not a - problem because negative responses need not contain any answer, - authority or additional records. See Section 2.1 of [RFC2308] for - more information about the format of negative responses. - - The minimum useful number of name servers is two, for redundancy (see - Section 4.1 of [RFC1034]). A zone's name servers should be reachable - by all IP protocols versions (e.g., IPv4 and IPv6) in common use. As - long as the servers are well managed, the server serving IPv6 might - be different from the server serving IPv4 sharing the same server - name. - - The best case is no truncation at all. This is because many - requesters will retry using TCP immediately, or will automatically - requery for RRsets that are possibly truncated, without considering - whether the omitted data was actually necessary. - - Anycasting [RFC3258] is a useful tool for performance and reliability - without increasing the size of referral responses. - - While it is irrelevant to the response size issue, all zones have to - be served via IPv4 as well to avoid name space fragmentation - [RFC3901]. - - - - - - -Vixie & Kato Expires November 11, 2012 [Page 4] - -Internet-Draft DNS Referral Response Size May 2012 - - -2.3. Advice to Server Implementors - - Each NS RR for a zone will add 12 fixed octets (name, type, class, - ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME). - Each A RR will require 16 octets, and each AAAA RR will require 28 - octets. - - While DNS distinguishes between necessary and optional resource - records, this distinction is according to protocol elements necessary - to signify facts, and takes no official notice of protocol content - necessary to ensure correct operation. For example, a nameserver - name that is in or below the zone cut being described by a delegation - is "necessary content", since there is no way to reach that zone - unless the parent zone's delegation includes "glue records" - describing that name server's addresses. - - Recall that the TC bit is only set when a required RRset can not be - included in its entirety (see Section 9 of [RFC2181]). Even when - some of the RRsets to be included in the additional section don't fit - in the response size, the TC bit isn't set. These RRsets may be - important for a referral. Some DNS implementations try to resolve - these missing glue records separately which will introduce extra - queries and extra time to resolve a given name. - - A delegation response should prioritize glue records as follows. - - first: - All glue RRsets for one name server whose name is in or below the - zone being delegated, or which has multiple address RRsets - (currently A and AAAA), or preferably both; - second: - Alternate between adding all glue RRsets for any name servers - whose names are in or below the zone being delegated, and all - glue RRsets for any name servers who have multiple address RRsets - (currently A and AAAA); - thence: - All other glue RRsets, in any order. - - Whenever there are multiple candidates for a position in this - priority scheme, one should be chosen on a round-robin or fully - random basis. The goal of this priority scheme is to offer - "necessary" glue first to fill into the response if possible. - - If any "necessary" content cannot be fit in the response, then it is - advisable that the TC bit be set in order to force a TCP retry, - rather than have the zone be unreachable. Note that a parent - server's proper response to a query for in-child glue or below-child - glue is a referral rather than an answer, and that this referral must - - - -Vixie & Kato Expires November 11, 2012 [Page 5] - -Internet-Draft DNS Referral Response Size May 2012 - - - be able to contain the in-child or below-child glue, and that in - outlying cases, only EDNS or TCP will be large enough to contain that - data. - - The glue record order should be independent of the version of IP used - in the query because the DNS server might just see a query from an - intermediate server rather than the query from the original client. - - -3. Analysis - - An instrumented protocol trace of a best case delegation response is - shown in Figure 1. Note that 13 servers are named, and 13 addresses - are given. This query was artificially designed to exactly reach the - 512 octets limit. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Vixie & Kato Expires November 11, 2012 [Page 6] - -Internet-Draft DNS Referral Response Size May 2012 - - - ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 - ;; QUERY SECTION: - ;; [23456789.123456789.123456789.\ - 123456789.123456789.123456789.com A IN] ;; @80 - - ;; AUTHORITY SECTION: - com. 172800 NS E.GTLD-SERVERS.NET. ;; @112 - com. 172800 NS F.GTLD-SERVERS.NET. ;; @128 - com. 172800 NS G.GTLD-SERVERS.NET. ;; @144 - com. 172800 NS H.GTLD-SERVERS.NET. ;; @160 - com. 172800 NS I.GTLD-SERVERS.NET. ;; @176 - com. 172800 NS J.GTLD-SERVERS.NET. ;; @192 - com. 172800 NS K.GTLD-SERVERS.NET. ;; @208 - com. 172800 NS L.GTLD-SERVERS.NET. ;; @224 - com. 172800 NS M.GTLD-SERVERS.NET. ;; @240 - com. 172800 NS A.GTLD-SERVERS.NET. ;; @256 - com. 172800 NS B.GTLD-SERVERS.NET. ;; @272 - com. 172800 NS C.GTLD-SERVERS.NET. ;; @288 - com. 172800 NS D.GTLD-SERVERS.NET. ;; @304 - - - ;; ADDITIONAL SECTION: - A.GTLD-SERVERS.NET. 172800 A 192.5.6.30 ;; @320 - B.GTLD-SERVERS.NET. 172800 A 192.33.14.30 ;; @336 - C.GTLD-SERVERS.NET. 172800 A 192.26.92.30 ;; @352 - D.GTLD-SERVERS.NET. 172800 A 192.31.80.30 ;; @368 - E.GTLD-SERVERS.NET. 172800 A 192.12.94.30 ;; @384 - F.GTLD-SERVERS.NET. 172800 A 192.35.51.30 ;; @400 - G.GTLD-SERVERS.NET. 172800 A 192.42.93.30 ;; @416 - H.GTLD-SERVERS.NET. 172800 A 192.54.112.30 ;; @432 - I.GTLD-SERVERS.NET. 172800 A 192.43.172.30 ;; @448 - J.GTLD-SERVERS.NET. 172800 A 192.48.79.30 ;; @464 - K.GTLD-SERVERS.NET. 172800 A 192.52.178.30 ;; @480 - L.GTLD-SERVERS.NET. 172800 A 192.41.162.30 ;; @496 - M.GTLD-SERVERS.NET. 172800 A 192.55.83.30 ;; @512 - - ;; MSG SIZE sent: 80 rcvd: 512 - - - Figure 1 - - For longer query names, the number of address records supplied will - be lower. Furthermore, it is only by using a common parent name - (which is "GTLD-SERVERS.NET." in this example) that all 13 addresses - are able to fit, due to the use of DNS compression pointers in the - last 12 occurrences of the parent domain name. The outputs from the - response simulator in Appendix A (written in perl [PERL]) shown in - Figure 2 and Figure 3 demonstrate these properties. - - - -Vixie & Kato Expires November 11, 2012 [Page 7] - -Internet-Draft DNS Referral Response Size May 2012 - - - % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br - a.dns.br requires 10 bytes - b.dns.br requires 4 bytes - c.dns.br requires 4 bytes - d.dns.br requires 4 bytes - # of NS: 4 - For maximum size query (255 byte): - only A is considered: # of A is 4 (green) - A and AAAA are considered: # of A+AAAA is 3 (yellow) - preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow) - For average size query (64 byte): - only A is considered: # of A is 4 (green) - A and AAAA are considered: # of A+AAAA is 4 (green) - preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green) - - - Figure 2 - - - % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int - ns-ext.isc.org requires 16 bytes - ns.psg.com requires 12 bytes - ns.ripe.net requires 13 bytes - ns.eu.int requires 11 bytes - # of NS: 4 - For maximum size query (255 byte): - only A is considered: # of A is 4 (green) - A and AAAA are considered: # of A+AAAA is 3 (yellow) - preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow) - For average size query (64 byte): - only A is considered: # of A is 4 (green) - A and AAAA are considered: # of A+AAAA is 4 (green) - preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green) - - Figure 3 - - Here we use the term "green" if all address records could fit, or - "yellow" if two or more could fit, or "orange" if only one could fit, - or "red" if no address record could fit. It's clear that without a - common parent for nameserver names, much space would be lost. For - these examples we use an average/common name size of 15 octets, - befitting our assumption of "GTLD-SERVERS.NET." as our common parent - name. - - We're assuming a medium query name size of 64 since that is the - typical size seen in trace data at the time of this writing. If - Internationalized Domain Name (IDN) or any other technology that - results in larger query names be deployed significantly in advance of - - - -Vixie & Kato Expires November 11, 2012 [Page 8] - -Internet-Draft DNS Referral Response Size May 2012 - - - EDNS, then new measurements and new estimates will have to be made. - - -4. Conclusions - - The current practice of giving all nameserver names a common parent - (such as "GTLD-SERVERS.NET." or "ROOT-SERVERS.NET.") saves space in - DNS responses and allows for more nameservers to be enumerated than - would otherwise be possible, since the common parent domain name only - appears once in a DNS message and is referred to via "compression - pointers" thereafter. - - If all nameserver names for a zone share a common parent, then it is - operationally advisable to make all servers for the zone thus served - also be authoritative for the zone of that common parent. For - example, the root name servers (?.ROOT-SERVERS.NET.) can answer - authoritatively for the ROOT-SERVERS.NET. zone. This is to ensure - that the zone's servers always have the zone's nameservers' glue - available when delegating, and will be able to respond with answers - rather than referrals if a requester who wants that glue comes back - asking for it. In this case the name server will likely be a - "stealth server" -- authoritative but unadvertised in the glue zone's - NS RRset. See Section 2 of [RFC1996] for more information about - stealth servers. - - Thirteen (13) is the effective maximum number of nameserver names - usable with traditional (non-extended) DNS, assuming a common parent - domain name, and given that implicit referral response truncation is - undesirable in the average case. - - More than one address record in a protocol family per server is - inadvisable since the necessary glue RRsets (A or AAAA) are - atomically indivisible, and will be larger than a single resource - record. Larger RRsets are more likely to lead to or encounter - truncation. - - More than one address record across protocol families is less likely - to lead to or encounter truncation, partly because multiprotocol - clients, which are required to handle larger RRsets such as AAAA RRs, - are more likely to speak EDNS, which can use a larger UDP response - size limit, and partly because the resource records (A and AAAA) are - in different RRsets and are therefore divisible from each other. - - Name server names that are at or below the zone they serve are more - sensitive to referral response truncation, and glue records for them - should be considered "more important" than other glue records, in the - assembly of referral responses. - - - - -Vixie & Kato Expires November 11, 2012 [Page 9] - -Internet-Draft DNS Referral Response Size May 2012 - - -5. Security Considerations - - The recommendations contained in this document have no known security - implications. - - -6. IANA Considerations - - This document does not call for changes or additions to any IANA - registry. - - -7. Acknowledgement - - The authors thank Peter Koch, Rob Austein, Joe Abley, Mark Andrews, - Kenji Rikitake, Stephane Bortzmeyer, Olafur Gudmundsson, Alfred - Hoenes, Alexander Mayrhofer, and Ray Bellis for their valuable - comments and suggestions. - - This work was supported by the US National Science Foundation - (research grant SCI-0427144) and DNS-OARC. - - -8. References - -8.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - -8.2. Informative References - - [PERL] Wall, L., Christiansen, T., and J. Orwant, "Programming - Perl, 3rd ed.", ISBN 0-596-00027-8, July 2000. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, October 1989. - - [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", RFC 1996, August 1996. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - - - -Vixie & Kato Expires November 11, 2012 [Page 10] - -Internet-Draft DNS Referral Response Size May 2012 - - - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC2671bis] - Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms - for DNS (EDNS0)", draft-ietf-dnsext-rfc2671bis-edns0-08 , - February 2012. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", - RFC 2672, August 1999. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via - Shared Unicast Addresses", RFC 3258, April 2002. - - [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational - Guidelines", BCP 91, RFC 3901, September 2004. - - [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational - Considerations and Issues with IPv6 DNS", RFC 4472, - April 2006. - - [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", - BCP 152, RFC 5625, August 2009. - - [SSAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on - Broadband Routers and Firewalls", SSAC 035, - September 2008. - - -Appendix A. The response simulator program - - - #!/usr/bin/perl - # - # SYNOPSIS - # respsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ... - # if all queries are assumed to have a same zone suffix, - # such as "jp" in JP TLD servers, specify it in -z option - # - - - -Vixie & Kato Expires November 11, 2012 [Page 11] - -Internet-Draft DNS Referral Response Size May 2012 - - - use strict; - use Getopt::Std; - - my ($sz_msg) = (512); - my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28); - my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2); - my (%namedb, $name, $nssect, %opts, $optz); - my $n_ns = 0; - - getopt('z', %opts); - if (defined($opts{'z'})) { - server_name_len($opts{'z'}); # just register it - } - - foreach $name (@ARGV) { - my $len; - $n_ns++; - $len = server_name_len($name); - print "$name requires $len bytes\n"; - $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl - + $sz_rdlen + $len; - } - print "# of NS: $n_ns\n"; - arsect(255, $nssect, $n_ns, "maximum"); - arsect(64, $nssect, $n_ns, "average"); - - sub server_name_len { - my ($name) = @_; - my (@labels, $len, $n, $suffix); - - $name =~ tr/A-Z/a-z/; - @labels = split(/\./, $name); - $len = length(join('.', @labels)) + 2; - for ($n = 0; $#labels >= 0; $n++, shift @labels) { - $suffix = join('.', @labels); - return length($name) - length($suffix) + $sz_ptr - if (defined($namedb{$suffix})); - $namedb{$suffix} = 1; - } - return $len; - } - - sub arsect { - my ($sz_query, $nssect, $n_ns, $cond) = @_; - my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect); - $ansect = $sz_query + $sz_type + $sz_class; - $space = $sz_msg - $sz_header - $ansect - $nssect; - $n_a = atmost(int($space / $sz_rr_a), $n_ns); - - - -Vixie & Kato Expires November 11, 2012 [Page 12] - -Internet-Draft DNS Referral Response Size May 2012 - - - $n_a_aaaa = atmost(int($space - / ($sz_rr_a + $sz_rr_aaaa)), $n_ns); - $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) - / $sz_rr_aaaa), $n_ns); - printf "For %s size query (%d byte):\n", $cond, $sz_query; - printf " only A is considered: "; - printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns); - printf " A and AAAA are considered: "; - printf "# of A+AAAA is %d (%s)\n", - $n_a_aaaa, &judge($n_a_aaaa, $n_ns); - printf " preferred-glue A is assumed: "; - printf "# of A is %d, # of AAAA is %d (%s)\n", - $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns); - } - - sub judge { - my ($n, $n_ns) = @_; - return "green" if ($n >= $n_ns); - return "yellow" if ($n >= 2); - return "orange" if ($n == 1); - return "red"; - } - - sub atmost { - my ($a, $b) = @_; - return 0 if ($a < 0); - return $b if ($a > $b); - return $a; - } - - -Authors' Addresses - - Paul Vixie - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - US - - Phone: +1 650 423 1300 - Email: vixie@isc.org - - - - - - - - - - -Vixie & Kato Expires November 11, 2012 [Page 13] - -Internet-Draft DNS Referral Response Size May 2012 - - - Akira Kato - Keio University/WIDE Project - Graduate School of Media Design, 4-1-1 Hiyoshi - Kohoku, Yokohama 223-8526 - JP - - Phone: +81 45 564 2490 - Email: kato@wide.ad.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Vixie & Kato Expires November 11, 2012 [Page 14] - diff --git a/doc/draft/draft-kato-dnsop-local-zones-00.txt b/doc/draft/draft-kato-dnsop-local-zones-00.txt deleted file mode 100644 index d857cd9580..0000000000 --- a/doc/draft/draft-kato-dnsop-local-zones-00.txt +++ /dev/null @@ -1,295 +0,0 @@ - - - -Internet Engineering Task Force Akira Kato, WIDE -INTERNET-DRAFT Paul Vixie, ISC -Expires: August 24, 2003 February 24, 2003 - - - Operational Guidelines for "local" zones in the DNS - draft-kato-dnsop-local-zones-00.txt - -Status of this Memo - - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. - -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other groups -may also distribute working documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference material -or to cite them other than as ``work in progress.'' - -To view the list Internet-Draft Shadow Directories, see -http://www.ietf.org/shadow.html. - -Distribution of this memo is unlimited. - -The internet-draft will expire in 6 months. The date of expiration will -be August 24, 2003. - - -Abstract - -A large number of DNS queries regarding to the "local" zones are sent -over the Internet in every second. This memo describes operational -guidelines to reduce the unnecessary DNS traffic as well as the load of -the Root DNS Servers. - -1. Introduction - -While it has yet been described in a RFC, .local is used to provide a -local subspace of the DNS tree. Formal delegation process has not been -completed for this TLD. In spite of this informal status, .local has -been used in many installations regardless of the awareness of the -users. Usually, the local DNS servers are not authoritative to the -.local domain, they end up to send queries to the Root DNS Servers. - -There are several other DNS zones which describe the "local" -information. .localhost has been used to describe the localhost for -more than a couple of decades and virtually all of the DNS servers are -configured authoritative for .localhost and its reverse zone .127.in- - - -KATO Expires: August 24, 2003 [Page 1] - - -DRAFT DNS local zones February 2003 - -addr.arpa. However, there are other "local" zones currently used in the -Internet or Intranets connected to the Internet through NATs or similar -devices. - -At a DNS server of an university in Japan, half of the DNS queries sent -to one of the 13 Root DNS Servers were regarding to the .local. At -another DNS Server running in one of the Major ISPs in Japan, the 1/4 -were .local. If those "local" queries are able to direct other DNS -servers than Root, or they can be resolved locally, it contributes the -reduction of the Root DNS Servers. - -2. Rationale - -Any DNS queries regarding to "local" names should not be sent to the DNS -servers on the Internet. - -3. Operational Guidelines - -Those queries should be processed at the DNS servers internal to each -site so that the severs respond with NXDOMAIN rather than sending -queries to the DNS servers outside. - -The "local" names have common DNS suffixes which are listed below: - -3.1. Local host related zones: - -Following two zones are described in [Barr, 1996] and .localhost is also -defined in [Eastlake, 1999] . - - o .localhost - o .127.in-addr.arpa - - -Following two zones are for the loopback address in IPv6 [Hinden, 1998] -. While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush, -2001] , the old TLD .int has been used for this purpose for years -[Thomson, 1995] and many implementations still use .int. So it is -suggested that both zones should be provided for each IPv6 reverse -lookup zone for a while. - - o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int - o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa - - -3.2. Locally created name space - -While the use of .local has been proposed in several Internet-Drafts, it -has not been described in any Internet documents with formal status. -However, the amount of the queries for .local is much larger than -others, it is suggested to resolve the following zone locally: - - - - -KATO Expires: August 24, 2003 [Page 2] - - -DRAFT DNS local zones February 2003 - - o .local - - - -3.3. Private or site-local addresses - -The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site- -local addresses [Hinden, 1998] should be resolved locally: - - o 10.in-addr.arpa - o 16.172.in-addr.arpa - o 17.172.in-addr.arpa - o 18.172.in-addr.arpa - o 19.172.in-addr.arpa - o 20.172.in-addr.arpa - o 21.172.in-addr.arpa - o 22.172.in-addr.arpa - o 23.172.in-addr.arpa - o 24.172.in-addr.arpa - o 25.172.in-addr.arpa - o 26.172.in-addr.arpa - o 27.172.in-addr.arpa - o 28.172.in-addr.arpa - o 29.172.in-addr.arpa - o 30.172.in-addr.arpa - o 31.172.in-addr.arpa - o 168.192.in-addr.arpa - o c.e.f.ip6.int - o d.e.f.ip6.int - o e.e.f.ip6.int - o f.e.f.ip6.int - o c.e.f.ip6.arpa - o d.e.f.ip6.arpa - o e.e.f.ip6.arpa - o f.e.f.ip6.arpa - - -3.4. Link-local addresses - -The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden, -1998] should be resolved locally: - - o 254.169.in-addr.arpa - o 8.e.f.ip6.int - o 9.e.f.ip6.int - o a.e.f.ip6.int - o b.e.f.ip6.int - o 8.e.f.ip6.arpa - o 9.e.f.ip6.arpa - o a.e.f.ip6.arpa - o b.e.f.ip6.arpa - - - -KATO Expires: August 24, 2003 [Page 3] - - -DRAFT DNS local zones February 2003 - -4. Suggestions to developers - -4.1. Suggestions to DNS software implementors - -In order to avoid unnecessary traffic, it is suggested that DNS software -implementors provide configuration templates or default configurations -so that the names described in the previous section are resolved locally -rather than sent to other DNS servers in the Internet. - -4.2. Suggestions to developers of NATs or similar devices - -There are many NAT or similar devices available in the market. -Regardless of the availability of DNS Servers in those devices, it is -suggested that those devices are able to filter the DNS traffic or -respond to the DNS traffic related to "local" zones by configuration -regardless of its ability of DNS service. It is suggested that this -functionality is activated by default. - -5. IANA Consideration - -While .local TLD has yet defined officially, there are substantial -queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the -traffic sent to the Root DNS Servers are related to the .local zone. -Therefore, while it is not formally defined, it is suggested that IANA -delegates .local TLD to an organization. - -The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918 -address and the link-local address. It has several DNS server instances -around the world by using BGP Anycast [Hardie, 2002] . So the AS112 -Project is one of the candidates to host the .local TLD. - -Authors' addresses - - Akira Kato - The University of Tokyo, Information Technology Center - 2-11-16 Yayoi Bunkyo - Tokyo 113-8658, JAPAN - Tel: +81 3-5841-2750 - Email: kato@wide.ad.jp - - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063, USA - Tel: +1 650-779-7001 - Email: vixie@isc.org - - - - - - - -KATO Expires: August 24, 2003 [Page 4] - - -DRAFT DNS local zones February 2003 - -References - -To be filled - -References - -Barr, 1996. -D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912 -(February 1996). - -Eastlake, 1999. -D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999). - -Hinden, 1998. -R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in -RFC2373 (July 1998). - -Bush, 2001. -R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001). - -Thomson, 1995. -S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in -RFC1886 (December 1995). - -Rekhter, 1996. -Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, -"Address Allocation for Private Internets" in RFC1918 (February 1996). - -IANA, 2002. -IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002). - -Vixie, . -P. Vixie, "AS112 Project" in AS112. http://www.as112.net/. - -Hardie, 2002. -T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast -Addresses" in RFC3258 (April 2002). - - - - - - - - - - - - - - - - - -KATO Expires: August 24, 2003 [Page 5] - diff --git a/doc/draft/draft-kerr-ixfr-only-01.txt b/doc/draft/draft-kerr-ixfr-only-01.txt deleted file mode 100644 index 837b255f1f..0000000000 --- a/doc/draft/draft-kerr-ixfr-only-01.txt +++ /dev/null @@ -1,336 +0,0 @@ - - - -DNSext Working Group O. Sury -Internet-Draft CZ.NIC -Updates: 1995 (if approved) S. Kerr, Ed. -Intended status: Standards Track ISC -Expires: August 30, 2010 February 26, 2010 - - - IXFR-ONLY to Prevent IXFR Fallback to AXFR - draft-kerr-ixfr-only-01 - -Abstract - - This documents proposes a new QTYPE (Query pseudo RRtype) for the - Domain Name System (DNS). IXFR-ONLY is a variant of IXFR (RFC 1995) - that allows an authoritative server to incrementally update zone - content from another (primary) server without falling back from IXFR - to AXFR. This way, alternate peers can be contacted more quickly and - convergence of zone content may be achieved much faster in important, - resilient operational scenarios. - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 30, 2010. - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - - - -Sury & Kerr Expires August 30, 2010 [Page 1] - -Internet-Draft IXFR-ONLY February 2010 - - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the BSD License. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 - 2. IXFR Server Side . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. IXFR Client Side . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Applicability of IXFR-ONLY . . . . . . . . . . . . . . . . . . 5 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Sury & Kerr Expires August 30, 2010 [Page 2] - -Internet-Draft IXFR-ONLY February 2010 - - -1. Introduction - - For large DNS zones, RFC 1995 [RFC1995] defines Incremental Zone - Transfer (IXFR), which allows only to transfer the changed portion(s) - of a zone. - - In the document, an IXFR client and an IXFR server is defined as in - RFC 1995 [RFC1995], a secondary name server which requests IXFR is - called an IXFR client and a primary or secondary name server which - responds to the request is called an IXFR server. - - IXFR is an efficient way to transfer changes in zones from IXFR - servers to IXFR clients. However, when an IXFR client has multiple - IXFR servers for a single zone, it is possible that not all IXFR - servers have the zone with same serial number for that zone. In this - case, if an IXFR client attempts an IXFR from an IXFR server which - does not have zone with the serial number used by the IXFR client, - the IXFR server will fall back to a full zone transfer (AXFR) when it - has a version of the zone with serial number greater than the serial - requested by the IXFR client. - - For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for - a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the - same zone. An IXFR client that has the zone with serial number 2 - which sends an IXFR request to IXFR server NS2 will get a full zone - transfer (AXFR) of the zone at serial number 3. This is because NS2 - does not know the zone with serial number 2, and therefore does not - know what the differences are between zone with serial number 2 and - 3. - - If the IXFR client in this example had known to send the query to - IXFR server NS1, then it could have gotten an incremental transfer - (IXFR). But IXFR clients can only know what the latest version of - the zone is at a IXFR server (this information is available via an - SOA query). - - The IXFR-ONLY query type provides a way for the IXFR client to ask - each IXFR server to return an error instead of sending the current - version of the zone via full zone transfer (AXFR). By using this, a - IXFR client can check each IXFR server until it finds one able to - provide IXFR. - -1.1. Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - - - - -Sury & Kerr Expires August 30, 2010 [Page 3] - -Internet-Draft IXFR-ONLY February 2010 - - -2. IXFR Server Side - - A IXFR server receiving a DNS message requesting IXFR-ONLY will reply - as described in RFC 1995 [RFC1995] if it is able to produce an IXFR - for the serial number requested. - - If the IXFR server is is not able to reply with an IXFR it MUST NOT - reply with an AXFR unless AXFR result is smaller than IXFR result. - Instead, it MUST reply with RCODE CannotIXFR. (!FIXME) - - If the IXFR result is larger than an AXFR, then an IXFR server MAY - reply with an AXFR result instead. This is an optimization, and IXFR - servers MAY only reply with AXFR if they are certain that the reply - using AXFR is smaller than an equivalent IXFR reply. - - -3. IXFR Client Side - - An IXFR client who wishes to use IXFR-ONLY will send a message to one - of the IXFR servers. The format is exactly the same as for IXFR, - except the IXFR-ONLY QTYPE code is used instead of the IXFR QTYPE - code. - - If the IXFR server replies with IXFR, then the IXFR client is done. - - If the IXFR server replies with an RCODE of CannotIXFR, then the IXFR - client proceeds on to a different IXFR server. In this case the IXFR - server implements IXFR-ONLY, but does not have information about zone - with the serial number requested. - - If the IXFR server replies with any RCODE other than CannotIXFR or - NoError, then the IXFR client proceeds on to a different IXFR server. - In this case the IXFR server does not implement IXFR-ONLY. - - If the IXFR client attempts IXFR-ONLY to each IXFR server and none of - them reply with an incremental transfer (IXFR), then it should - attempt an IXFR as described in RFC 1995 [RFC1995] to each of the - IXFR servers which replied with an RCODE other than CannotIXFR or - NoError. - - The method described above allows IXFR clients to operate normally in - situatians where some of the IXFR servers do support IXFR-ONLY, and - some who do not. IXFR clients MAY remember which IXFR servers - support IXFR-ONLY and query those IXFR servers first. However since - IXFR servers may change software or even run a mix of software, IXFR - clients MUST attempt to query each IXFR server periodically when they - attempt to get new versions of a zone. - - - - -Sury & Kerr Expires August 30, 2010 [Page 4] - -Internet-Draft IXFR-ONLY February 2010 - - - Implementations MAY allow IXFR clients to disable IXFR-ONLY for a - given IXFR server, if this is known in advance. These IXFR servers - are treated as if they replied with an RCODE other than CannotIXFR or - NoError, although no query with IXFR-ONLY is actually sent. - - -4. Applicability of IXFR-ONLY - - Implementations SHOULD allow IXFR clients to disable IXFR-ONLY - completely. - - Implementations MAY allow IXFR clients to disable IXFR-ONLY for a - specific zone. This may be useful for small zones, where fallback to - AXFR is cheap, or in other cases where IXFR-ONLY is causing problems. - - Usage of IXFR-ONLY may cause IXFR clients to prefer particular IXFR - servers, by shifting load to ones that support IXFR-ONLY. If this a - problem, then administrators can disable IXFR-ONLY in implementations - that allow it. - - If a IXFR client has a single IXFR server for a zone, it SHOULD use - IXFR rather than IXFR-ONLY. - - -5. IANA Considerations - - IANA allocates the new IXFR-ONLY QTYPE, which means "incremental - transfer only". IANA allocates the CannotIXFR RCODE, which means - "Server cannot provide IXFR for zone". - - -6. Security Considerations - - IXFR-ONLY may be used by someone to get information about the state - of IXFR servers by providing a quick and efficient way to check which - versions of a zone each IXFR server supports. Zones should be - secured via TSIG [RFC2845] to prevent unauthorized information - exposure. However, even administrators of IXFR servers may not want - this information given to IXFR clients, in which case they will need - to disable IXFR-ONLY. - - -7. Normative References - - [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - - - -Sury & Kerr Expires August 30, 2010 [Page 5] - -Internet-Draft IXFR-ONLY February 2010 - - - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - -Authors' Addresses - - Ondrej Sury - CZ.NIC - Americka 23 - 120 00 Praha 2 - CZ - - Phone: +420 222 745 110 - Email: ondrej.sury@nic.cz - - - Shane Kerr (editor) - ISC - Bennebrokestraat 17-I - 1015 PE Amsterdam - NL - - Phone: +31 64 6336297 - Email: shane@isc.org - - - - - - - - - - - - - - - - - - - - - - - - -Sury & Kerr Expires August 30, 2010 [Page 6] - diff --git a/doc/draft/draft-mekking-dnsop-auto-cpsync-01.txt b/doc/draft/draft-mekking-dnsop-auto-cpsync-01.txt deleted file mode 100644 index d11e93329c..0000000000 --- a/doc/draft/draft-mekking-dnsop-auto-cpsync-01.txt +++ /dev/null @@ -1,392 +0,0 @@ - - - -Domain Name System Operations W. Mekking -Internet-Draft NLnet Labs -Intended status: Standards Track December 21, 2010 -Expires: June 24, 2011 - - - Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE - draft-mekking-dnsop-auto-cpsync-01 - -Abstract - - This document proposes a way to synchronise existing trust anchors - automatically between a child zone and its parent. The protocol can - be used for other Resource Records that are required to delegate from - a parent to a child such as NS and glue records. The synchronization - allows for a third party to be involved, thus the protocol is - suitable for both cases, whether you have to communicate to the - registry or to the registrar. - -Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on June 24, 2011. - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - - - -Mekking Expires June 24, 2011 [Page 1] - -Internet-Draft Child Parent Synchronization December 2010 - - - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -1. Introduction - - This memo defines a way to synchronise existing trust anchors - automatically between a child zone and its parent. The protocol can - be used for other Resource Records that are required to delegate from - a parent to a child such as NS and glue records. The synchronization - allows for a third party to be involved, thus the protocol is - suitable for both cases, whether you have to communicate to the - registry or to the registrar. - - To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones - must submit their DNSKEYs, or hashes of their DNSKEYs, to their - parent zone. The parent zone publishes the hashes of the DNSKEYs in - the form of a DS record. The DNSKEY RRset at the child may change - over time. In order to keep the chain of trust intact, the DS - records at the parent zone also needs to be updated. The rolling of - the keys with the SEP bit on is one of the few tasks in DNSSEC that - yet has to be fully automated. - - The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone - changes to the parent. - - To bootstrap the communication channel, information must be exchanged - in order to detect service location and granting update privileges. - A new or existing child zone is in need of a communication channel - with the parent. This can be a direct channel or a channel through a - third party: - - If the parent allows for direct communication channel with child - zones, the parent can share the required data to set up the - channel to the child zone. Once the child has the required - credentials, it can use the direct communication channel with the - parent to request zone changes related to its delegation. - - If a third party is involved, the third party acts on behalf of - the parent. In this case, the third party will give out the - required credentials to set up the communication channel. - - Allowing for a third party in the communication channel ensures - - - -Mekking Expires June 24, 2011 [Page 2] - -Internet-Draft Child Parent Synchronization December 2010 - - - flexibility of the service location. - - Please note that the document only describes the front end of the - synchronization service. The first reason for that is that it is not - necessary to write down how the DNS UPDATE is processed after it is - accepted. It is merely a goal to provide a way for the child zone to - automatically update the records at the zone cut. The second reason - is that flexibility is needed in order to fit the protocol into the - multifarious policies that exist among the great number of - registrars. - - Thus, it is not required that the DNS UPDATE immediately updates the - name server. Thus, it would still be possible to monitor the - incoming updates with the tools of your choice. It is not a - replacement of your RR provisioning system. The records in the DNS - UPDATE can be converted into any kind of format. - -2. Service Discovery - - The service location is handed out during bootstrap. If this - information is missing or incorrect, the normal guidelines for - sending DNS UPDATE messages SHOULD be followed. - -3. Access and Update Control - - The DNS UPDATE normally is used for granting update permissions to a - machine that is within the boundary of the same organization. This - document proposes to grant child zones the same permissions. - However, it MUST NOT be possible that a child zone updates - information in the parent zone that falls outside the administrative - domain of the corresponding delegation. For example, it MUST NOT be - possible for a child zone to update the data that the parent is - authoritative for, or update a delegation that is pointed to a - different child zone. It MUST only be able to update records that - match one of the following: - - Or: The owner name is equal the child zone name and RRtype is - delegation specific. Currently those are records with RRtype NS - or DS. - - Or: The owner name exists in the right side of the NS RRset - belonging to the child zone and RRtype is is glue specific. - Currently those are records with RRtype A or AAAA. - - We can make a distinction here between narrow and wide glue records. - Narrow glue records are said to be glue specific records with an - owner name that is a subdomain of the child zone. Wide glue records - are glue specific records with an owner name that is outside of the - - - -Mekking Expires June 24, 2011 [Page 3] - -Internet-Draft Child Parent Synchronization December 2010 - - - delegated child domain. - - These updates MAY be refused if it conflicts with the local policy. - This list may be expanded, if there is need for more delegation - related zone content. - - In case of adding or deleting delegation specific records, the DNSSEC - related RRs in the parent zone might need to be updated. - -4. Update Mechanism - -4.1. Update Request - - Updating the NS RRset or corresponding glue at the parent, an update - can be sent at any time. Updating the DS RRset is part of key - rollover, as described in RFC 4641 [RFC4641]. When performing a key - rollover that involves updating the RRset at the parent, the child - introduces a new DNSKEY in its zone that represents the security - entry point for determining the chain of trust. After a while, it - will revoke and/or remove the previous security entry point. The - timings when to update the DS RRset at the parent are described in - draft-dnsop-morris-dnssec-key-timing [keytiming]. When updating the - DS RRset at the parent automatically, these timing specifications - SHOULD be followed. To determine the propagation delays described in - this document, the child should poll the parent zone for a short - time, until the DS is visible at all parent name servers. - - [Author's note] To discuss: A child zone might be unable to reach all - parent name servers. - - The child notifies the parent of the requested changes by sending a - DNS UPDATE message. If it receives a NOERROR reply in return, the - update is acknowledged by the parent zone. Otherwise, the child MAY - retry transmitting the update. In order to prevent duplicate - updates, it SHOULD follow the guidelines described in RFC 2136 - [RFC2136]. - -4.2. Processing the Update - - An incoming DNS UPDATE message is processed as follows: - - Step 1: Check the TSIG/SIG0 credentials. In case of TSIG, the - parent should follow the TSIG processing described in section 3.2 - of RFC 2845. In case of SIG0, the parent should follow the SIG0 - processing described in section 3.2 of RFC 2931. - - - - - - -Mekking Expires June 24, 2011 [Page 4] - -Internet-Draft Child Parent Synchronization December 2010 - - - Step 2: Verify that the updates matches the update policy for child - zones. - - Step 3: If verified, send back DNS UPDATE OK. Otherwise, send back - DNS UPDATE REFUSED. - - Step 4: If verified, apply changes. How that is done is a matter of - policy. - -5. Examples - -5.1. Example BIND9 Configuration - - This is how a parent zone can configure a policy to enable a child - zone synchronize delegation specific records. The first rule of the - update policy grants children to update their DS and NS records in - the parent zone, in this case example.com. The second rule of the - update policy grants children to update the corresponding glue - records. - - key cs.example.com. { - algorithm HMAC-MD5; - secret "secretforcs"; - } - - key math.example.com. { - algorithm HMAC-MD5; - secret "secretformath"; - } - - ... - - zone "example.com" { - type master; - file "example.com"; - update-policy { grant *.example.com. self *.example.com. DS NS; }; - update-policy { grant *.example.com. selfsub *.example.com. A AAAA; - }; - }; - -6. Security Considerations - - Automating the synchronization of (DNSSEC) records between the parent - and child creates a new communication channel. It is up to the - policy of the parent, or the third party acting on behalf of the - parent, who is allowed such privileges. A policy would usually - include a form of access control. It is recommended that it involves - transaction authentication, for example TSIG [RFC2845] or SIG0 - - - -Mekking Expires June 24, 2011 [Page 5] - -Internet-Draft Child Parent Synchronization December 2010 - - - [RFC2931]. - - In the jungle of the DNS, many stakeholders exist. The registrant of - a zone might not be the one that maintains the zone. That can - possibly mean that many stakeholders need to possess the security - credentials in order to use this synchronization channel. However, - this problem exist with any kind of transaction authentication. - - The disadvantage of adding a new communication channel is that you - create a new attack window onto your DNS and DNSSEC records. When - using this synchronization method for your DNSSEC records, a - cryptographically equally strong, or stronger private key SHOULD be - used, compared to the strength of your DNSSEC keys. - - The advantage is that if somehow your DNSSEC keys are compromised, - you can still use this channel to perform an emergency key rollover. - -7. IANA Considerations - - None. - -8. Acknowledgments - - Mark Andrews, Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards. - -9. Changelog - - 01: - - - Make it clear that the solution is flexible and it can fit into - many and diverse environments of registrars. - - - Short section about service discovery. - - - Add text about narrow glue records. - - - Add text about transaction authentication concerns with respect - to many stakeholders involved. - - 00: - - - Initial document - -10. References - - - - - - - -Mekking Expires June 24, 2011 [Page 6] - -Internet-Draft Child Parent Synchronization December 2010 - - -10.1. Informative References - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS - UPDATE)", RFC 2136, April 1997. - - [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational - Practices", RFC 4641, September 2006. - - [keytiming] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key - Timing Considerations", March 2010. - -10.2. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - Wellington, "Secret Key Transaction Authentication for - DNS (TSIG)", RFC 2845, May 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -Author's Address - - Matthijs Mekking - NLnet Labs - Science Park 140 - Amsterdam 1098 XG - The Netherlands - - EMail: matthijs@nlnetlabs.nl - - - - - - - - - - - - - - -Mekking Expires June 24, 2011 [Page 7] - diff --git a/doc/draft/draft-pechanec-pkcs11uri-13.txt b/doc/draft/draft-pechanec-pkcs11uri-13.txt deleted file mode 100644 index 2e081bc32e..0000000000 --- a/doc/draft/draft-pechanec-pkcs11uri-13.txt +++ /dev/null @@ -1,728 +0,0 @@ - - - - -Network Working Group J. Pechanec -Internet-Draft D. Moffat -Intended status: Standards Track Oracle Corporation -Expires: April 03, 2014 September 30, 2013 - - - The PKCS#11 URI Scheme - draft-pechanec-pkcs11uri-13 - -Abstract - - This memo specifies a PKCS#11 Uniform Resource Identifier (URI) - Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, for - identifying PKCS#11 tokens themselves, or for identifying PKCS#11 - libraries. The URI is based on how PKCS#11 objects, tokens, and - libraries are identified in the PKCS#11 Cryptographic Token Interface - Standard. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on April 03, 2014. - -Copyright Notice - - Copyright (c) 2013 IETF Trust and the persons identified as the - document authors. All rights reserved. - - - - - - - - - - - - -Pechanec & Moffat Expires April 03, 2014 [Page 1] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. PKCS#11 URI Scheme Definition . . . . . . . . . . . . . . . . 3 - 3.1. PKCS#11 URI Scheme Name . . . . . . . . . . . . . . . . . 4 - 3.2. PKCS#11 URI Scheme Status . . . . . . . . . . . . . . . . 4 - 3.3. PKCS#11 URI Scheme Syntax . . . . . . . . . . . . . . . . 4 - 3.4. PKCS#11 URI Matching Guidelines . . . . . . . . . . . . . 7 - 3.5. PKCS#11 URI Comparison . . . . . . . . . . . . . . . . . 8 - 4. Examples of PKCS#11 URIs . . . . . . . . . . . . . . . . . . 9 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 7.2. Informative References . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 - -1. Introduction - - The PKCS #11: Cryptographic Token Interface Standard [pkcs11_spec] - specifies an API, called Cryptoki, for devices which hold - cryptographic information and perform cryptographic functions. - Cryptoki, pronounced crypto-key and short for cryptographic token - interface, follows a simple object-based approach, addressing the - goals of technology independence (any kind of device may be used) and - resource sharing (multiple applications may access multiple devices), - presenting applications with a common, logical view of the device - a - cryptographic token. - - It is desirable for applications or libraries that work with PKCS#11 - tokens to accept a common identifier that consumers could use to - identify an existing PKCS#11 storage object in a PKCS#11 token, an - existing token itself, or an existing Cryptoki library (also called a - producer, module, or provider). The set of storage object types that - can be stored in a PKCS#11 token includes a certificate, a public, - private or secret key, and a data object. These objects can be - uniquely identifiable via the PKCS#11 URI scheme defined in this - - - -Pechanec & Moffat Expires April 03, 2014 [Page 2] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - document. The set of attributes describing a storage object can - contain an object label, its type, and its ID. The set of attributes - that identifies a PKCS#11 token can contain a token label, a - manufacturer name, a serial number, and a token model. Attributes - that can identify a Cryptoki library are a library manufacturer, a - library description, and a library version. Library attributes may - be necessary to use if more than one Cryptoki library provides a - token and/or PKCS#11 objects of the same name(s). - - The PKCS#11 URI cannot identify other objects aside from storage - objects, for example a hardware feature or mechanism. Note that a - Cryptoki library does not have to provide for storage objects at all. - The URI can still be used to identify a specific PKCS#11 token or an - API producer in such a case. - - A subset of existing PKCS#11 structure members and object attributes - was chosen believed to be sufficient in uniquely identifying a - PKCS#11 token, storage object, or library in a configuration file, on - a command line, or in a configuration property of something else. - Should there be a need for a more complex information exchange on - PKCS#11 entities a different means of data marshalling should be - chosen accordingly. - - A PKCS#11 URI is not intended to be used to create new PKCS#11 - objects in tokens, or to create PKCS#11 tokens. It is solely to be - used to identify and work with existing storage objects and tokens - through the PKCS#11 API, or identify Cryptoki libraries themselves. - - The URI scheme defined in this document is designed specifically with - a mapping to the PKCS#11 API in mind. The URI uses the scheme, path - and query components defined in the Uniform Resource Identifier - (URI): Generic Syntax [RFC3986] document. The URI does not use the - hierarchical element for a naming authority in the path since the - authority part could not be mapped to PKCS#11 API elements. The URI - does not use the fragment component. - - If an application has no access to a producer or producers of the - PKCS#11 API it is left to its implementation to provide adequate user - interface to locate and load such producer(s). - -2. Contributors - - Stef Walter, Nikos Mavrogiannopoulos, Nico Williams, Dan Winship, and - Jaroslav Imrich contributed to the development of this document. - -3. PKCS#11 URI Scheme Definition - - - - - -Pechanec & Moffat Expires April 03, 2014 [Page 3] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - In accordance with [RFC4395], this section provides the information - required to register the PKCS#11 URI scheme. - -3.1. PKCS#11 URI Scheme Name - - pkcs11 - -3.2. PKCS#11 URI Scheme Status - - Permanent. - -3.3. PKCS#11 URI Scheme Syntax - - The PKCS#11 URI is a sequence of attribute value pairs separated by a - semicolon that form a one level path component, optionally followed - by a query. In accordance with Section 2.5 of [RFC3986], the data - should first be encoded as octets according to the UTF-8 character - encoding [RFC3629]; then only those octets that do not correspond to - characters in the unreserved set or to permitted characters from the - reserved set should be percent-encoded. This specification suggests - one allowable exception to that rule for the "id" attribute, as - stated later in this section. Grammar rules "unreserved" and "pct- - encoded" in the PKCS#11 URI specification below are imported from - [RFC3986]. As a special case, note that according to Appendix A of - [RFC3986], a space must be percent-encoded. - - PKCS#11 specification imposes various limitations on the value of - attributes, be it a more restrictive character set for the "serial" - attribute or fixed sized buffers for almost all the others, including - "token", "manufacturer", and "model" attributes. However, the - PKCS#11 URI notation does not impose such limitations aside from - removing generic and PKCS#11 URI delimiters from a permitted - character set. We believe that being too restrictive on the - attribute values could limit the PKCS#11 URI's usefulness. What is - more, possible future changes to the PKCS#11 specification should not - affect existing attributes. - - A PKCS#11 URI takes the form (for explanation of Augmented BNF, see - [RFC5234]): - - - - - - - - - - - - -Pechanec & Moffat Expires April 03, 2014 [Page 4] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - pk11-URI = "pkcs11" ":" pk11-path *1("?" pk11-query) - ; Path component and its attributes. Path may be empty. - pk11-path = *1(pk11-pattr *(";" pk11-pattr)) - pk11-pattr = pk11-token / pk11-manuf / pk11-serial / - pk11-model / pk11-lib-manuf / - pk11-lib-ver / pk11-lib-desc / - pk11-object / pk11-type / pk11-id / - pk11-x-pattr - ; Query component and its attributes. Query may be empty. - pk11-qattr = pk11-pin-source / pk11-x-qattr - pk11-query = *1(pk11-qattr *("&" pk11-qattr)) - ; RFC 3986 section 2.2 mandates all potentially reserved characters - ; that do not conflict with actual delimiters of the URI do not have - ; to be percent-encoded. - pk11-res-avail = ":" / "[" / "]" / "@" / "!" / "$" / - "'" / "(" / ")" / "*" / "+" / "," / "=" - pk11-path-res-avail = pk11-res-avail / "&" - ; We allow "/" and "?" in the query to be unencoded but "&" must - ; be encoded since it may be used as a delimiter in the component. - pk11-query-res-avail = pk11-res-avail / "/" / "?" - pk11-pchar = unreserved / pk11-path-res-avail / pct-encoded - pk11-qchar = unreserved / pk11-query-res-avail / pct-encoded - pk11-token = "token" "=" *pk11-pchar - pk11-manuf = "manufacturer" "=" *pk11-pchar - pk11-serial = "serial" "=" *pk11-pchar - pk11-model = "model" "=" *pk11-pchar - pk11-lib-manuf = "library-manufacturer" "=" *pk11-pchar - pk11-lib-desc = "library-description" "=" *pk11-pchar - pk11-lib-ver = "library-version" "=" 1*DIGIT *1("." 1*DIGIT) - pk11-object = "object" "=" *pk11-pchar - pk11-type = "type" "=" *1("public" / "private" / "cert" / - "secret-key" / "data") - pk11-id = "id" "=" *pk11-pchar - pk11-pin-source = "pin-source" "=" *pk11-qchar - pk11-x-attr-nm-char = ALPHA / DIGIT / "-" / "_" - ; Permitted value of a vendor specific attribute is based on - ; whether the attribute is used in the path or in the query. - pk11-x-pattr = "x-" 1*pk11-x-attr-nm-char "=" *pk11-pchar - pk11-x-qattr = "x-" 1*pk11-x-attr-nm-char "=" *pk11-qchar - - - - - - - - - - - - -Pechanec & Moffat Expires April 03, 2014 [Page 5] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - The URI path component contains attributes that identify a resource - in a one level hierarchy provided by Cryptoki producers. The query - component may contain a PIN source attribute that may be needed to - retrieve the resource identified by the URI path. Both path and - query components may contain vendor specific attributes. Such - attribute names must start with an "x-" prefix. Attributes in the - path component are delimited by ';' character, attributes in the - query component use '&' as a delimiter. - - The general '/' delimiter was removed from available characters that - do not have to be percent-encoded in the path component so that - generic URI parsers never split the path component into multiple - segments. The '/' delimiter can be used unencoded in the query - component. Delimiter '?' was removed since the PKCS#11 URI uses a - query component. Delimiter '#' was removed so that generic URI - parsers are not confused by unencoded hash characters. All other - generic delimiters are allowed to be used unencoded (':', '[', ']', - and '@') in the PKCS#11 URI. - - The attribute "token" represents a token label and corresponds to the - "label" member of the CK_TOKEN_INFO structure, the attribute - "manufacturer" corresponds to the "manufacturerID" member of - CK_TOKEN_INFO, the attribute "serial" corresponds to the - "serialNumber" member of CK_TOKEN_INFO, the attribute "model" - corresponds to the "model" member of CK_TOKEN_INFO, the attribute - "library-manufacturer" represents the Cryptoki library manufacturer - and corresponds to the "manufacturerID" member of the CK_INFO - structure, the attribute "library-description" corresponds to the - "libraryDescription" member of CK_INFO, the attribute "library- - version" corresponds to the "libraryVersion" member of CK_INFO, the - attribute "object" represents a PKCS#11 object label and corresponds - to the "CKA_LABEL" object attribute, the attribute "type" represents - the type of the object and corresponds to the "CKA_CLASS" object - attribute, the attribute "id" represents the object ID and - corresponds to the "CKA_ID" object attribute, and the attribute "pin- - source" specifies where the application or library should find the - token PIN, if needed. - - The PKCS#11 URI must not contain duplicate attributes of the same - name in the URI path component. It means that each attribute may be - present at most once in the PKCS#11 URI path. Aside from the "pin- - source" attribute, duplicate attributes may be present in the URI - query component and it is up to the URI consumer to decide on how to - deal with such duplicates. - - The "pin-source" attribute may represent a filename that contains a - token PIN but an application may overload this attribute. For - example, "pin-source=%7Cprog-name" could mean to read a PIN from an - - - -Pechanec & Moffat Expires April 03, 2014 [Page 6] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - external application (%7C denotes a pipe '|' character). Note that - an application may always ask for a PIN and/or interpret the "pin- - source" attribute by any means it decides to. However, as discussed - in Section 6, the attribute should never contain the PIN itself. - - It is recommended to percent-encode the whole value of the "id" - attribute which is supposed to be handled as arbitrary binary data. - Value "M" of the "library-version" attribute should be interpreted as - "M" for the major and "0" for the minor version of the library. Note - that if the "library-version" attribute is present, the major version - number is mandatory. - - An empty PKCS#11 URI path attribute that does allow for an empty - value matches a corresponding structure member or an object attribute - with an empty value. Note that according to the PKCS#11 - specification [pkcs11_spec], empty character values in a PKCS#11 API - producer must be padded with spaces and should not be NULL - terminated. - -3.4. PKCS#11 URI Matching Guidelines - - The PKCS#11 URI can identify PKCS#11 storage objects, tokens, or - Cryptoki libraries. The following guidelines should help a PKCS#11 - URI consumer (eg. an application accepting PKCS#11 URIs) to match the - URI with the desired resource. - - o the consumer must know whether the URI is to identify PKCS#11 - storage object(s), token(s), or Cryptoki producer(s). - - o an unrecognized attribute in the URI path component, including a - vendor specific attribute, should result in an empty set of - matched resources. The consumer should consider whether an error - message presented to the user is appropriate in such a case. - - o an unrecognized attribute in the URI query should be ignored. The - consumer should consider whether a warning message presented to - the user is appropriate in such a case. - - o an attribute not present in the URI path but known to a consumer - matches everything. Each additional attribute present in the URI - path further restricts the selection. - - o a logical extension of the above is that an empty URI path matches - everything. For example, if used to identify storage objects, it - matches all accessible objects in all tokens provided by all - PKCS#11 API producers found in the system. - - - - - -Pechanec & Moffat Expires April 03, 2014 [Page 7] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - o use of the PIN attribute may change the set of storage objects - visible to the consumer. - - o in addition to the PIN attribute, query string attributes may - contain further information about how to perform the selection or - other related information. - -3.5. PKCS#11 URI Comparison - - Comparison of two URIs is a way of determining whether the URIs are - equivalent without comparing the actual resource the URIs point to. - The comparison of URIs aims to minimize false negatives while - strictly avoiding false positives. - - Two PKCS#11 URIs are said to be equal if URIs as character strings - are identical as specified in Section 6.2.1 of [RFC3986], or if both - following rules are fulfilled: - - o set of attributes present in the URI is equal. Note that the - ordering of attributes in the URI string is not significant for - the mechanism of comparison. - - o values of respective attributes are equal based on rules specified - below - - The rules for comparing values of respective attributes are: - - o values of attributes "library-description", "library- - manufacturer", "manufacturer", "model", "object", "serial", - "token", and "type" must be compared using a simple string - comparison as specified in Section 6.2.1 of [RFC3986] after the - case and the percent-encoding normalization are both applied as - specified in Section 6.2.2 of [RFC3986] - - o value of attribute "id" must be compared using the simple string - comparison after all bytes are percent-encoded using uppercase - letters for digits A-F - - o value for attribute "pin-source", if deemed containing the - filename with the PIN value, must be compared using the simple - string comparison after the full syntax based normalization as - specified in Section 6.2.2 of [RFC3986] is applied. If value of - the "pin-source" attribute is believed to be overloaded it is - recommended to perform case and percent-encoding normalization - before the values are compared but the exact mechanism of - comparison is left to the application. - - - - - -Pechanec & Moffat Expires April 03, 2014 [Page 8] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - o value of attribute "library-version" must be processed as a - specific scheme-based normalization permitted by Section 6.2.3 of - [RFC3986]. The value must be split into a major and minor version - with character '.' (dot) serving as a delimiter. Library version - "M" must be treated as "M" for the major version and "0" for the - minor version. Resulting minor and major version numbers must be - then separately compared numerically. - - o when comparing vendor specific attributes it is recommended to - perform case and percent-encoding normalization before the values - are compared but the exact mechanism of comparison is left to the - application. - -4. Examples of PKCS#11 URIs - - This section contains some examples of how PKCS#11 token objects, - PKCS#11 tokens, and PKCS#11 libraries can be identified using the - PKCS#11 URI scheme. Note that in some of the following examples, - newlines and spaces were inserted for better readability. As - specified in Appendix C of [RFC3986], whitespace should be ignored - when extracting the URI. Also note that all spaces as part of the - URI are percent-encoded, as specified in Appendix A of [RFC3986]. - - An empty PKCS#11 URI might be useful to PKCS#11 consumers: - - pkcs11: - - - One of the simplest and most useful forms might be a PKCS#11 URI that - specifies only an object label and its type. The default token is - used so the URI does not specify it. Note that when specifying - public objects, a token PIN might not be required. - - pkcs11:object=my-pubkey;type=public - - - When a private key is specified either the "pin-source" attribute or - an application specific method would be usually used. Note that '/' - is not percent-encoded in the "pin-source" attribute value since this - attribute is part of the query component, not the path, and thus is - separated by '?' from the rest of the URI. - - pkcs11:object=my-key;type=private?pin-source=/etc/token - - - The following example identifies a certificate in the software token. - Note an empty value for the attribute "serial". Also note that the - "id" attribute value is entirely percent-encoded, as recommended. - - - -Pechanec & Moffat Expires April 03, 2014 [Page 9] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - While ',' is in the reserved set it does not have to be percent- - encoded since it does not conflict with any sub-delimiters used. The - '#' character as in "The Software PKCS#11 Softtoken" must be percent- - encoded. - - pkcs11:token=The%20Software%20PKCS%2311%20Softtoken; - manufacturer=Snake%20Oil,%20Inc.; - model=1.0; - object=my-certificate; - type=cert; - id=%69%95%3E%5C%F4%BD%EC%91; - serial= - ?pin-source=/etc/token_pin - - - The token alone can be identified without specifying any PKCS#11 - objects. A PIN may still be needed to list all objects, for example. - - pkcs11:token=Software%20PKCS%2311%20softtoken; - manufacturer=Snake%20Oil,%20Inc. - ?pin-source=/etc/token_pin - - - The Cryptoki library alone can be also identified without specifying - a PKCS#11 token or object. - - pkcs11:library-manufacturer=Snake%20Oil,%20Inc.; - library-description=Soft%20Token%20Library; - library-version=1.23 - - - The following example shows that the attribute value can contain a - semicolon. In such case, it is percent-encoded. The token attribute - value must be read as "My token; created by Joe". Lower case letters - can also be used in percent-encoding as shown below in the "id" - attribute value but note that Sections 2.1 and 6.2.2.1 of [RFC3986] - read that all percent-encoded characters should use the uppercase - hexadecimal digits. More specifically, if the URI string was to be - compared, the algorithm defined in Section 3.5 explicitly requires - percent-encoding to use the uppercase digits A-F in the "id" - attribute values. And as explained in Section 3.3, library version - "3" should be interpreted as "3" for the major and "0" for the minor - version of the library. - - pkcs11:token=My%20token%25%20created%20by%20Joe; - library-version=3; - id=%01%02%03%Ba%dd%Ca%fe%04%05%06 - - - - -Pechanec & Moffat Expires April 03, 2014 [Page 10] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - If there is any need to include literal "%;" substring, for example, - both characters must be escaped. The token value must be read as "A - name with a substring %;". - - pkcs11:token=A%20name%20with%20a%20substring%20%25%3B; - object=my-certificate; - type=cert - ?pin-source=/etc/token_pin - - - The next example includes a small A with acute in the token name. It - must be encoded in octets according to the UTF-8 character encoding - and then percent-encoded. Given that a small A with acute is U+225 - unicode code point, the UTF-8 encoding is 195 161 in decimal, and - that is "%C3%A1" in percent-encoding. - - pkcs11:token=Name%20with%20a%20small%20A%20with%20acute:%20%C3%A1; - object=my-certificate; - type=cert - - - Both the path and query components may contain vendor specific - attributes. Attributes in the query component may be delimited by - either ';' or '&'. We use '&' in the example that follows. - - pkcs11:token=my-token; - object=my-certificate; - type=cert; - x-vend-aaa=value-a - ?pin-source=/etc/token_pin& - x-vend-bbb=value-b - - -5. IANA Considerations - - This document moves the "pkcs11" URI scheme from the provisional to - the permanent URI scheme registry. The registration template for the - URI scheme is accessible on http://www.iana.org/assignments/uri- - schemes. - -6. Security Considerations - - There are general security considerations for URI schemes discussed - in Section 7 of [RFC3986]. - - From those security considerations, Section 7.1 of [RFC3986] applies - since there is no guarantee that the same PKCS#11 URI will always - identify the same object, token, or a library in the future. - - - -Pechanec & Moffat Expires April 03, 2014 [Page 11] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - Section 7.5 of [RFC3986] applies since the PKCS#11 URI may be used in - command line arguments to run applications, and those arguments can - be world readable on some systems. For that reasons, the URI - intentionally does not allow for specifying the PKCS#11 token PIN as - a URI attribute. - -7. References - -7.1. Normative References - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", RFC 3629, STD 63, November 2003. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", RFC 3986, STD - 66, January 2005. - - [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 5234, STD 68, January 2008. - -7.2. Informative References - - [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and - Registration Procedures for New URI Schemes", RFC 4395, - February 2006. - - [pkcs11_spec] - RSA Laboratories, "PKCS #11: Cryptographic Token Interface - Standard v2.20", June 2004. - -Authors' Addresses - - Jan Pechanec - Oracle Corporation - 4180 Network Circle - Santa Clara CA 95054 - USA - - Email: Jan.Pechanec@Oracle.COM - URI: http://www.oracle.com - - - - - - - - - - - -Pechanec & Moffat Expires April 03, 2014 [Page 12] - -Internet-Draft The PKCS#11 URI Scheme September 2013 - - - Darren J. Moffat - Oracle Corporation - Oracle Parkway - Thames Valley Park - Reading RG6 1RA - UK - - Email: Darren.Moffat@Oracle.COM - URI: http://www.oracle.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Pechanec & Moffat Expires April 03, 2014 [Page 13] diff --git a/doc/draft/draft-yao-dnsext-bname-05.txt b/doc/draft/draft-yao-dnsext-bname-05.txt deleted file mode 100644 index 2cf2111057..0000000000 --- a/doc/draft/draft-yao-dnsext-bname-05.txt +++ /dev/null @@ -1,841 +0,0 @@ - - -Network Working Group J. Yao -Internet-Draft X. Lee -Intended status: Standards Track CNNIC -Expires: February 20, 2011 P. Vixie - Internet Software Consortium - August 19, 2010 - - - Bundled DNS Name Redirection - draft-yao-dnsext-bname-05.txt - -Abstract - - This document defines a new DNS Resource Record called "BNAME", which - provides the capability to map itself and its subtree of the DNS name - space to another domain. It differs from the CNAME record which only - maps a single node of the DNS name space, from the DNAME which only - maps the subtree of the DNS name space to another domain. - -Status of this Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on February 20, 2011. - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - - - -Yao, et al. Expires February 20, 2011 [Page 1] - -Internet-Draft bname August 2010 - - - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. The BNAME Resource Record . . . . . . . . . . . . . . . . . . 4 - 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.2. The BNAME Substitution . . . . . . . . . . . . . . . . . . 4 - 3.3. The BNAME Rules . . . . . . . . . . . . . . . . . . . . . 4 - 3.4. BNAME Examples . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.1. Processing by Servers . . . . . . . . . . . . . . . . . . 5 - 4.2. Processing by Resolvers . . . . . . . . . . . . . . . . . 8 - 5. BNAME in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.1. BNAME validating . . . . . . . . . . . . . . . . . . . . . 9 - 5.2. BNAME alias algorithm identifiers . . . . . . . . . . . . 10 - 5.3. Signaling of BNAME . . . . . . . . . . . . . . . . . . . . 10 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 12 - 9.1. draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 12 - 9.2. draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 12 - 9.3. draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 12 - 9.4. draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 12 - 9.5. draft-yao-dnsext-bname: Version 04 . . . . . . . . . . . . 13 - 9.6. draft-yao-dnsext-bname: Version 05 . . . . . . . . . . . . 13 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 - - - - -Yao, et al. Expires February 20, 2011 [Page 2] - -Internet-Draft bname August 2010 - - -1. Introduction - - More and more internationalized domain name labels [RFC3490] appear - in the DNS trees. Some labels [RFC3743] are equivalent in some - languages. The internet users want them to be identical in the DNS - resolution. For example, color.exmaple.com==colour.example.com. The - BNAME represents for bundle names. This document defines a new DNS - Resource Record called "BNAME", which provides the capability to map - an entire tree of the DNS name space to another domain. It means - that the BNAME redirects both itself and its descendants to its - owner. The DNAME [RFC2672] and [RFC2672bis] do not redirect itself, - only the descendants. The domain name that owns a DNAME record is - allowed to have other resource record types at that domain name. The - domain name that owns a BNAME record is not allowed to have other - resource record types at that domain name unless they are the DNSSEC - related resource record types defined in [RFC4033], [RFC4034], - [RFC4035] and [RFC5155]. A server MAY refuse to load a zone that has - data at a sub-domain of a domain name owning a BNAME RR or that has - other data except the DNSSEC related resource record types and BNAME - at that name. BNAME is a singleton type, meaning only one BNAME is - allowed per name except the DNSSEC related resource record types. - Resolvers, servers and zone content administrators should be cautious - that usage of BNAME or its combination with CNAME or DNAME may lead - to form loops. The loops should be avoided. - -1.1. Terminology - - All the basic terms used in this specification are defined in the - documents [RFC1034], [RFC1035] and [RFC2672]. - - -2. Motivation - - In some languages, some characters have the variants, which look - differently or very similar but are identical in the meaning. For - example, Chinese character U+56FD and its variant U+570B look - differently, but are identical in the meaning. If Internationalized - Domain Label" or "IDL" [RFC3743] are composed of variant characters, - we regard this kind of IDL as the IDL variant. If these IDL variants - are put into the DNS for resolution, they are expected to be - identical in the DNS resolution. More comprehensible example is that - we expect color.exmaple.com to be equivalent with the - colour.exmaple.com in the DNS resolution. The BNAME Resource Record - and its processing rules are conceived as a solution to this - equivalence problem. Without the BNAME mechanism, current mechanisms - such as DNAME or CNAME are not enough capable to solve all the - problems with the emergence of internationalized domain names. The - internationalized domain names may have alias or equivalence of the - - - -Yao, et al. Expires February 20, 2011 [Page 3] - -Internet-Draft bname August 2010 - - - original one. The BNAME solution provides the solution to both ASCII - alias names and internationalized domain alias names. - - -3. The BNAME Resource Record - -3.1. Format - - The BNAME RR has mnemonic BNAME and type code xx (decimal). It is - not class-sensitive. Its RDATA is comprised of a single field, - , which contains a fully qualified domain name that must be - sent in uncompressed form [RFC1035], [RFC3597]. The field - MUST be present. The presentation format of is that of a - domain name [RFC1035]. The wildcards in the BNAME RR SHOULD NOT be - used. - - BNAME - - The effect of the BNAME RR is the substitution of the record's - for its owner name, as a suffix of a domain name. This - substitution has to be applied for every BNAME RR found in the - resolution process, which allows fairly lengthy valid chains of BNAME - RRs. - -3.2. The BNAME Substitution - - A BNAME substitution is performed by replacing the suffix labels of - the name being sought matching the owner name of the BNAME resource - record with the string of labels in the RDATA field. The matching - labels end with the root label in all cases. Only whole labels are - replaced. - -3.3. The BNAME Rules - - There are two rules which governs the use of BNAMEs in a zone file. - The first one is that there SHOULD be no descendants under the owner - of the BNAME. The second one is that no resource records can co- - exist with the BNAME for the same name except the DNSSEC related - resource record types. It means that if a BNAME RR is present at a - node N, there MUST be no other data except the DNSSEC related - resource record types at N and no data at any descendant of N. This - restriction applies only to records of the same class as the BNAME - record. - -3.4. BNAME Examples - - The table below shows some examples of the BNAME usage. - - - - -Yao, et al. Expires February 20, 2011 [Page 4] - -Internet-Draft bname August 2010 - - - QNAME owner BNAME target result - ---------------- -------------- -------------- ----------------- - com. example.com. example.net. - com. com. net. net. - example.com. example.com. example.net. example.net. - a.example.com. example.com. example.net. a.example.net. - a.b.example.com. example.com. example.net. a.b.example.net. - ab.example.com. b.example.com. example.net. - bar.example.com. example.com. example.net. bar.example.net. - a.b.example.com. b.example.com. example.net. a.example.net. - a.example.com. example.com. b.example.net. a.b.example.net. - - Table 1. BNAME Usage Examples. - - - If the owner name of the CNAME RR is regarded as the target of the MX - RR, it may cause some problems. Some mail servers may directly - connect the owner name of the CNAME instead of the name pointed by - CNAME for mail delivery and cause the undelivery of the mails. BNAME - has the similar problems with CNAME. This document specifies that - the owner name of the BNAME should not be the targets of some RRs - such as MX, SRV and PTR. In case that the owner name of the BNAME RR - is the target of some RRs, it should be cautious. - - -4. Query Processing - - To exploit the BNAME mechanism the name resolution algorithms - [RFC1034] must be modified slightly for both servers and resolvers. - Both modified algorithms incorporate the operation of making a - substitution on a name (either QNAME or SNAME) under control of a - BNAME record. This operation will be referred to as "the BNAME - substitution". - -4.1. Processing by Servers - - For a server performing non-recursive service steps 3.a, 3.c and 4 of - section 4.3.2 [RFC1034] are changed to check for a BNAME record, and - to return certain BNAME records from zone data and the cache. - - If the owner name of the bname is the suffix of the name queryed but - different, when preparing a response, a server performing a BNAME - substitution will in all cases include the relevant BNAME RR in the - answer section. A CNAME RR is synthesized and included in the answer - section. This will help the client to reach the correct DNS data. - - If the owner name of the bname is same with the name queryed, when - preparing a response, a server performing a BNAME substitution will - - - -Yao, et al. Expires February 20, 2011 [Page 5] - -Internet-Draft bname August 2010 - - - not include the relevant BNAME RR in the answer section unless the - type queryed is BNAME. A CNAME RR will be synthesized and included - in the answer section unless the type queryed is BNAME. - - The provided synthesized CNAME RR if there has one, MUST have - - - - The same CLASS as the QCLASS of the query, - - TTL equal to the corresponding BNAME RR, - - An equal to the QNAME in effect at the moment the BNAME RR - was encountered, and - - An RDATA field containing the new QNAME formed by the action of - the BNAME substitution. - - - The revised server algorithm is: - - - 1. Set or clear the value of recursion available in the response - depending on whether the name server is willing to provide - recursive service. If recursive service is available and - requested via the RD bit in the query, go to step 5, otherwise - step 2. - - 2. Search the available zones for the zone which is the nearest - ancestor to QNAME. If such a zone is found, go to step 3, - otherwise step 4. - - 3. Start matching down, label by label, in the zone. The matching - process can terminate several ways: - - - - - - - - - - - - - - - - - -Yao, et al. Expires February 20, 2011 [Page 6] - -Internet-Draft bname August 2010 - - - a. If the whole of QNAME is matched, we have found the node. - - If the data at the node is a CNAME, and QTYPE doesn't match - CNAME, copy the CNAME RR into the answer section of the - response, change QNAME to the canonical name in the CNAME RR, - and go back to step 1. - - If the data at the node is a BNAME, and QTYPE doesn't - match BNAME, copy the BNAME RR and also a corresponding, - synthesized CNAME RR into the answer section of the - response, change QNAME to the name carried as RDATA in - the BNAME RR, and go back to step 1. - - Otherwise, copy all RRs which match QTYPE into the answer - section and go to step 6. - - b. If a match would take us out of the authoritative data, we have - a referral. This happens when we encounter a node with NS RRs - marking cuts along the bottom of a zone. - - Copy the NS RRs for the subzone into the authority section of - the reply. Put whatever addresses are available into the - additional section, using glue RRs if the addresses are not - available from authoritative data or the cache. Go to step 4. - - c. If at some label, a match is impossible (i.e., the - corresponding label does not exist), look to see whether the - last label matched has a BNAME record. - - - If a BNAME record exists at that point, copy that record into - the answer section. If substitution of its for its - in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [RFC2136] and exit; otherwise - perform the substitution and continue. The server SHOULD - synthesize a corresponding CNAME record as described above and - include it in the answer section. Go back to step 1. - - If there was no BNAME record, look to see if the "*" label - exists. - - If the "*" label does not exist, check whether the name we are - looking for is the original QNAME in the query or a name we - have followed due to a CNAME. If the name is original, set an - authoritative name error in the response and exit. Otherwise - just exit. - - - - - -Yao, et al. Expires February 20, 2011 [Page 7] - -Internet-Draft bname August 2010 - - - - If the "*" label does exist, match RRs at that node against - QTYPE. If any match, copy them into the answer section, but - set the owner of the RR to be QNAME, and not the node with the - "*" label. Go to step 6. - - - 4. Start matching down in the cache. If QNAME is found in the cache, - copy all RRs attached to it that match QTYPE into the answer - section. If QNAME is not found in the cache but a BNAME record is - present at QNAME, copy that BNAME record into the - answer section. If there was no delegation from authoritative - data, look for the best one from the cache, and put it in the - authority section. Go to step 6. - - 5. Use the local resolver or a copy of its algorithm (see resolver - section of this memo) to answer the query. Store the results, - including any intermediate CNAMEs and BNAMEs, in the answer - section of the response. - - 6. Using local data only, attempt to add other RRs which may be - useful to the additional section of the query. Exit. - - - - Note that there will be at most one ancestor with a BNAME as - described in step 4 unless some zone's data is in violation of the - no-descendants limitation in section 3. An implementation might take - advantage of this limitation by stopping the search of step 3c or - step 4 when a BNAME record is encountered. - - -4.2. Processing by Resolvers - - A resolver or a server providing recursive service must be modified - to treat a BNAME as somewhat analogous to a CNAME. The resolver - algorithm of [RFC1034] section 5.3.3 is modified to renumber step 4.d - as 4.e and insert a new 4.d. The complete algorithm becomes: - - - - - - - - - - - - - -Yao, et al. Expires February 20, 2011 [Page 8] - -Internet-Draft bname August 2010 - - - 1. See if the answer is in local information, and if so return it to - the client. - - 2. Find the best servers to ask. - - 3. Send them queries until one returns a response. - - 4. Analyze the response, either: - - a. if the response answers the question or contains a name error, - cache the data as well as returning it back to the client. - - b. if the response contains a better delegation to other servers, - cache the delegation information, and go to step 2. - - c. if the response shows a CNAME and that is not the answer - itself, cache the CNAME, change the SNAME to the canonical name - in the CNAME RR and go to step 1. - - d. if the response shows a BNAME and that is not the answer - itself, cache the BNAME. If substitution of the BNAME's - for its in the SNAME would overflow the legal - size for a , return an implementation-dependent - error to the application; otherwise perform the substitution - and go to step 1. - - e. if the response shows a server failure or other bizarre - contents, delete the server from the SLIST and go back to step - 3. - - - A resolver or recursive server which understands BNAME records but - sends non-extended queries MUST augment step 4.c by deleting from the - reply any CNAME records which have an which is a subdomain of - the of any BNAME record in the response. - - -5. BNAME in DNSSEC - -5.1. BNAME validating - - With the deployment of DNSSEC, more and more servers and resolvers - will support DNSSEC. In order to make BNAME valid in DNSSEC - verification, the DNSSEC enabled resolvers and servers MUST support - BNAME. The synthesized CNAME in the answer section for the BNAME - will never be signed if there has one. - - If the owner name of the bname is the suffix of the name queryed but - - - -Yao, et al. Expires February 20, 2011 [Page 9] - -Internet-Draft bname August 2010 - - - different, DNSSEC validators MUST understand BNAME, verify the BNAME - and then checking that the CNAME was properly synthesized in order to - verify the synthesized CNAME. - - If the owner name of the bname is same with the name queryed, DNSSEC - validators MUST understand BNAME and verify the BNAME. The BNAME - enabled resolver (validator) should do somewhat analogous to a CNAME - for further query. - - In any negative response, the NSEC or NSEC3 [RFC5155] record type bit - map SHOULD be checked to see that there was no BNAME that could have - been applied. If the BNAME bit in the type bit map is set and the - query type is not BNAME, then BNAME substitution should have been - done. - -5.2. BNAME alias algorithm identifiers - - In order to prevent BNAME-unaware resolvers from attempting to - validate responses from BNAME-signed zones, this specification - allocates two new DNSKEY algorithm identifiers. Algorithm Y, DSA- - BNAME-SHA1 is an alias for algorithm 3, DSA. Algorithm Z, RSASHA1- - BNAME-SHA1 is an alias for algorithm 5, RSASHA1. These are not new - algorithms, they are additional identifiers for the existing - algorithms. Zones signed according to this specification MUST only - use these algorithm identifiers for their DNSKEY RRs. The BNAME- - unaware resolvers will not know these new identifiers and treat - responses from the BNAME signed zone as insecure, otherwise the bname - RR will be regarded as bogus if there is no such a mechanism. These - algorithm identifiers are used with the BNAME hash algorithm SHA1. - Using other BNAME hash algorithms requires allocation of a new alias. - Validating resolvers which follow the BNAME specification MUST - recognize the new alias algorithm identifier. The future new DNSSEC - algorithms are suggested to indicate the support of BNAME. - -5.3. Signaling of BNAME - - A new UB (Understand BNAME) bit in the EDNS flags field [RFC2671]can - be used to signal that the resolvers can understand BNAME in DNSSEC. - BNAME aware resolvers can set the Understand-BNAME (UB bit) to - receive a response without the synthesized CNAMEs. The UB bit is - part of the EDNS extended RCODE and Flags field[RFC2671]. Resolvers - should set this in a query to request omission of the synthesized - CNAMEs. - - If the query is a DNSSEC query, the BNAME enabled resolvers MUST set - the UB bit in the query. The server receiving the UB bit MUST not - issue synthesized CNAMEs. Servers copy the UB bit to the response, - and should delete the synthesized CNAMEs from the answer if there has - - - -Yao, et al. Expires February 20, 2011 [Page 10] - -Internet-Draft bname August 2010 - - - one. - - If the query is the DNSSEC query but the UB bit is not set, the - server should follow the rules below: - o If the owner name of the bname is the suffix of the name queryed - but different, when preparing a response, a server performing a - BNAME substitution will in all cases include the relevant BNAME RR - in the answer section. An unsigned CNAME RR is synthesized and - included in the answer section. This will help the client to - reach the correct DNS data. - o If the owner name of the bname is same with the name queryed, when - preparing a response, a DNSSEC enabled server performing a BNAME - substitution will not include the relevant BNAME RR and its RRSIG - RR in the answer section unless the type queryed is BNAME. An - unsigned CNAME RR will be synthesized and included in the answer - section unless the type queryed is BNAME. - o Since the BNAME-unaware DNSSEC resolvers do not know the alias - algorithm defined in secton 5.2 of this document, any response - from these zones signed with these alias algorithms unknown to - them will be regarded as the insecure one according to section 5.2 - of [RFC4035]. - - Below are Updated EDNS extended RCODE and Flags fields [RFC2671]: - - - +0 (MSB) +1 (LSB) - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 0: | EXTENDED-RCODE | VERSION | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 2: |DO|UB| Z | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - - - -6. IANA Considerations - - IANA is requested to assign the number to XX. This document updates - the IANA registry "DNS SECURITY ALGORITHM NUMBERS". IANA is - requested to assign the number to Y and Z. - - [[anchor15: Note in draft: before this document goes to WG Last call, - it is better that we list all DNSSEC algorithms that need to be - aliased to reflect compatibility with this extension.]] - - - - - - - -Yao, et al. Expires February 20, 2011 [Page 11] - -Internet-Draft bname August 2010 - - -7. Security Considerations - - Both ASCII domain name labels and non-ASCII ones have some aliases. - We can bundle the domain name labels and their aliases through BNAME - in the DNS resolutions. The name labels and their aliases in the - particular languages are only known by those who know these - languages. Those labels may be regarded as different ones by those - who don't know those languages. Those who do not know the aliases - should only use the familar ones. The applications will not know the - aliases unless they are properly configured. - - -8. Acknowledgements - - Because the BNAME is very similar to DNAME, the authors learn a lot - from [RFC2672]. Many ideas are from the discussion in the DNSOP and - DNSEXT mailling list. Thanks a lot to all in the list. Many - important comments and suggestions are contributed by many members of - the DNSEXT and DNSOP WGs. The authors especially thanks the - following ones:Niall O'Reilly, Glen Zorn, Mark Andrews, George - Barwood,Olafur Gudmundsson, Sun Guonian and Hanfeng for improving - this document. - - -9. Change History - - [[anchor18: RFC Editor: Please remove this section.]] - -9.1. draft-yao-dnsext-bname: Version 00 - - o Bundle DNS Name Redirection - -9.2. draft-yao-dnsext-bname: Version 01 - - o Improve the algorithm - o Improve the text - -9.3. draft-yao-dnsext-bname: Version 02 - - o Add the DNSSEC discussion - o Improve the text - -9.4. draft-yao-dnsext-bname: Version 03 - - o Update the DNSSEC discussion - o Update the IANA consideration - - - - - -Yao, et al. Expires February 20, 2011 [Page 12] - -Internet-Draft bname August 2010 - - -9.5. draft-yao-dnsext-bname: Version 04 - - o Improve the text - -9.6. draft-yao-dnsext-bname: Version 05 - - o add section: bname examples - o add section: Signaling of BNAME - - -10. References - -10.1. Normative References - - [ASCII] American National Standards Institute (formerly United - States of America Standards Institute), "USA Code for - Information Interchange", ANSI X3.4-1968, 1968. - - [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", - RFC 2672, August 1999. - - [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", - RFC 3490, March 2003. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - - - -Yao, et al. Expires February 20, 2011 [Page 13] - -Internet-Draft bname August 2010 - - - 10646", RFC 3629, November 2003. - - [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint - Engineering Team (JET) Guidelines for Internationalized - Domain Names (IDN) Registration and Administration for - Chinese, Japanese, and Korean", RFC 3743, April 2004. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - -10.2. Informative References - - [RFC2672bis] - Rose, S. and W. Wijngaards, "Update to DNAME Redirection - in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname- - 17.txt, 6 2009. - - -Authors' Addresses - - Jiankang YAO - CNNIC - No.4 South 4th Street, Zhongguancun - Beijing - - Phone: +86 10 58813007 - Email: yaojk@cnnic.cn - - - - - - - - - - - -Yao, et al. Expires February 20, 2011 [Page 14] - -Internet-Draft bname August 2010 - - - Xiaodong LEE - CNNIC - No.4 South 4th Street, Zhongguancun - Beijing - - Phone: +86 10 58813020 - Email: lee@cnnic.cn - - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA - - Phone: +1 650 779 7001 - Email: vixie@isc.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Yao, et al. Expires February 20, 2011 [Page 15] - - - diff --git a/doc/draft/update b/doc/draft/update deleted file mode 100644 index c5e3eecbef..0000000000 --- a/doc/draft/update +++ /dev/null @@ -1,68 +0,0 @@ -#!/bin/sh -commit= -if type fetch >/dev/null 2>&1 -then - fetch=fetch -elif type curl >/dev/null 2>&1 -then - fetch="curl -L -O" -else - exit 1 -fi - -for i -do - z= - case $i in - http://tools.ietf.org/html/*|http://www.ietf.org/internet-drafts/*|http://www.ietf.org/id/*) - z=`expr "$i" : 'http://.*/.*/\(.*\)'` - ;; - *://*/*) - echo -n "unknown uri $i" - continue; - esac - if test -n "$z" - then - case $z in - *-[0-9][0-9]) z="$z.txt"'' - esac - i="$z" - fi - if test -f "$i" - then - continue - fi - pat=`echo "$i" | sed 's/...txt/??.txt/'` - old=`echo $pat 2> /dev/null` - if test "X$old" != "X$pat" - then - newer=0 - for j in $old - do - if test $j ">" $i - then - newer=1 - fi - done - if test $newer = 1 - then - continue; - fi - fi - if $fetch "http://www.ietf.org/id/$i" - then - git add "$i" - if test "X$old" != "X$pat" - then - rm $old - git rm $old - commit="$commit $old" - fi - commit="$commit $i" - fi -done -if test -n "$commit" -then - git commit -m "new draft" - git push -fi diff --git a/doc/expired/draft-duerst-dns-i18n-02.txt b/doc/expired/draft-duerst-dns-i18n-02.txt deleted file mode 100644 index a42981634b..0000000000 --- a/doc/expired/draft-duerst-dns-i18n-02.txt +++ /dev/null @@ -1,905 +0,0 @@ - - - - - - -Internet Draft M. Duerst - Keio University -Expires in six months July 1998 - - - Internationalization of Domain Names - - -Status of this Memo - - This document is an Internet-Draft. Internet-Drafts are working doc- - uments of the Internet Engineering Task Force (IETF), its areas, and - its working groups. Note that other groups may also distribute work- - ing documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a "working - draft" or "work in progress". - - To learn the current status of any Internet-Draft, please check the - 1id-abstracts.txt listing contained in the Internet-Drafts Shadow - Directories on ftp.ietf.org (US East Coast), nic.nordu.net - (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific - Rim). - - Distribution of this document is unlimited. Please send comments to - the author at . - - -Abstract - - Internet domain names are currently limited to a very restricted - character set. This document proposes the introduction of a new - "zero-level" domain (ZLD) to allow the use of arbitrary characters - from the Universal Character Set (ISO 10646/Unicode) in domain names. - The proposal is fully backwards compatible and does not need any - changes to DNS. Version 02 is reissued without changes just to - keep this draft available. - -Table of contents - - 0. Change History ................................................. 2 - 0.8 Changes Made from Version 01 to Version 02 .................. 2 - 0.9 Changes Made from Version 00 to Version 01 .................. 2 - 1. Introduction ................................................... 3 - 1.1 Motivation .................................................. 3 - - - - Expires End of January 1998 [Page 1] - -Internet Draft Internationalization of Domain Names July 1997 - - - 1.2 Notational Conventions ...................................... 4 - 2. The Hidden Zero Level Domain ................................... 4 - 3. Encoding International Characters .............................. 5 - 3.1 Encoding Requirements ....................................... 5 - 3.2 Encoding Definition ......................................... 5 - 3.3 Encoding Example ............................................ 7 - 3.4 Length Considerations ....................................... 8 - 4. Usage Considerations ........................................... 8 - 4.1 General Usage ............................................... 8 - 4.2 Usage Restrictions .......................................... 9 - 4.3 Domain Name Creation ....................................... 10 - 4.4 Usage in URLs .............................................. 12 - 5. Alternate Proposals ........................................... 13 - 5.1 The Dillon Proposal ........................................ 13 - 5.2 Using a Separate Lookup Service ............................ 13 - 6. Generic Considerations ........................................ 14 - 5.1 Security Considerations .................................... 14 - 5.2 Internationalization Considerations ........................ 14 - Acknowledgements ................................................. 14 - Bibliography ..................................................... 15 - Author's Address .................................................= - 16 - - - - -0. Change History - - - -0.8 Changes Made from Version 01 to Version 02 - - No significant changes; reissued to make it available officially. - Changed author's address. - - Changes deferred to future versions (if ever): - - Decide on ZLD name (.i or .i18n.int or something else) - - Decide on casing solution - - Decide on exact syntax - - Proposals for experimental setup - - - - -0.9 Changes Made from Version 00 to Version 01 - - - - - - - - Expires End of January 1998 [Page 2] - -Internet Draft Internationalization of Domain Names July 1997 - - - - Minor rewrites and clarifications - - - Added the following references: [RFC1730], [Kle96], [ISO3166], - [iNORM] - - - Slightly expanded discussion about casing - - - Added some variant proposals for syntax - - - Added some explanations about different kinds of name parallelism - - - Added some explanation about independent addition of internation- - alized names in subdomains without bothering higher-level domains - - - Added some explanations about tools needed for support, and the - MX/CNAME problem - - - Change to RFC1123 (numbers allowed at beginning of labels) - - - - -1. Introduction - - -1.1 Motivation - - - The lower layers of the Internet do not discriminate any language or - script. On the application level, however, the historical dominance - of the US and the ASCII character set [ASCII] as a lowest common - denominator have led to limitations. The process of removing these - limitations is called internationalization (abbreviated i18n). One - example of the abovementioned limitations are domain names [RFC1034, - RFC1035], where only the letters of the basic Latin alphabet (case- - insensitive), the decimal digits, and the hyphen are allowed. - - While such restrictions are convenient if a domain name is intended - to be used by arbitrary people around the globe, there may be very - good reasons for using aliases that are more easy to remember or type - in a local context. This is similar to traditional mail addresses, - where both local scripts and conventions and the Latin script can be - used. - - There are many good reasons for domain name i18n, and some arguments - that are brought forward against such an extension. This document, - however, does not discuss the pros and cons of domain name i18n. It - proposes and discusses a solution and therefore eliminates one of the - - - - Expires End of January 1998 [Page 3] - -Internet Draft Internationalization of Domain Names July 1997 - - - most often heard arguments agains, namely "it cannot be done". - - The solution proposed in this document consists of the introduction - of a new "zero-level" domain building the root of a new domain - branch, and an encoding of the Universal Character Set (UCS) - [ISO10646] into the limited character set of domain names. - - - -1.2 Notational Conventions - - In the domain name examples in this document, characters of the basic - Latin alphabet (expressible in ASCII) are denoted with lower case - letters. Upper case letters are used to represent characters outside - ASCII, such as accented characters of the Latin alphabet, characters - of other alphabets and syllabaries, ideographic characters, and vari- - ous signs. - - -2. The Hidden Zero Level Domain - - The domain name system uses the domain "in-addr.arpa" to convert - internet addresses back to domain names. One way to view this is to - say that in-addr.arpa forms the root of a separate hierarchy. This - hierarchy has been made part of the main domain name hierarchy just - for implementation convenience. While syntactically, in-addr.arpa is - a second level domain (SLD), functionally it is a zero level domain - (ZLD) in the same way as "." is a ZLD. A similar example of a ZLD is - the domain tpc.int, which provides a hierarchy of the global phone - numbering system [RFC1530] for services such as paging and printing - to fax machines. - - For domain name i18n to work inside the tight restrictions of domain - name syntax, one has to define an encoding that maps strings of UCS - characters to strings of characters allowable in domain names, and a - means to distinguish domain names that are the result of such an - encoding from ordinary domain names. - - This document proposes to create a new ZLD to distinguish encoded - i18n domain names from traditional domain names. This domain would - be hidden from the user in the same way as a user does not see in- - addr.arpa. This domain could be called "i18n.arpa" (although the use - of arpa in this context is definitely not appropriate), simply - "i18n", or even just "i". Below, we are using "i" for shortness, - while we leave the decision on the actual name to further= - discussion. - - - - - - - Expires End of January 1998 [Page 4] - -Internet Draft Internationalization of Domain Names July= - 1997 - - -3. Encoding International Characters - - - - -3.1 Encoding Requirements - - - Until quite recently, the thought of going beyond ASCII for something - such as domain names failed because of the lack of a single encom- - passing character set for the scripts and languages of the world. - Tagging techniques such as those used in MIME headers [RFC1522] would - be much too clumsy for domain names. - - The definition of ISO 10646 [ISO10646], codepoint by codepoint iden- - tical with Unicode [Unicode], provides a single Universal Character - Set (UCS). A recent report [RFCIAB] clearly recommends to base the - i18n of the Internet on these standards. - - An encoding for i18n domain names therefore has to take the charac- - ters of ISO 10646/Unicode as a starting point. The full four-byte - (31 bit) form of UCS, called UCS4, should be used. A limitation to - the two-byte form (UCS2), which allows only for the encoding of the - Base Multilingual Plane, is too restricting. - - For the mapping between UCS4 and the strongly limited character set - of domain names, the following constraints have to be considered: - - - The structure of domain names, and therefore the "dot", have to be - conserved. Encoding is done for individual labels. - - - Individual labels in domain names allow the basic Latin alphabet - (monocase, 26 letters), decimal digits, and the "-" inside the - label. The capacity per octet is therefore limited to somewhat - above 5 bits. - - - There is no need nor possibility to preserve any characters. - - - Frequent characters (i.e. ASCII, alphabetic, UCS2, in that order) - should be encoded relatively compactly. A variable-length encoding - (similar to UTF-8) seems desirable. - - - -3.2 Encoding Definition - - - Several encodings for UCS, so called UCS Transform Formats, exist - - - - Expires End of January 1998 [Page 5] - -Internet Draft Internationalization of Domain Names July 1997 - - - already, namely UTF-8 [RFC2044], UTF-7 [RFC1642], and UTF-16 [Uni- - code]. Unfortunately, none of them is suitable for our purposes. We - therefore use the following encoding: - - - To accommodate the slanted probability distribution of characters - in UCS4, a variable-length encoding is used. - - - Each target letter encodes 5 bits of information. Four bits of - information encode character data, the fifth bit is used to indi- - cate continuation of the variable-length encoding. - - - Continuation is indicated by distinguishing the initial letter - from the subsequent letter. - - - Leading four-bit groups of binary value 0000 of UCS4 characters - are discarded, except for the last TWO groups (i.e. the last - octet). This means that ASCII and Latin-1 characters need two - target letters, the main alphabets up to and including Tibetan - need three target letters, the rest of the characters in the BMP - need four target letters, all except the last (private) plane in - the UTF-16/Surrogates area [Unicode] need five target letters, and - so on. - - - The letters representing the various bit groups in the various - positions are chosen according to the following table: - - - Nibble Value Initial Subsequent - Hex Binary - 0 0000 G 0 - 1 0001 H 1 - 2 0010 I 2 - 3 0011 J 3 - 4 0100 K 4 - 5 0101 L 5 - 6 0110 M 6 - 7 0111 N 7 - 8 1000 O 8 - 9 1001 P 9 - A 1010 Q A - B 1011 R B - C 1100 S C - D 1101 T D - E 1110 U E - F 1111 V F - - - [Should we try to eliminate "I" and "O" from initial? "I" might be - - - - Expires End of January 1998 [Page 6] - -Internet Draft Internationalization of Domain Names July 1997 - - - eliminated because then an algorithm can more easily detect ".i". "O" - could lead to some confusion with "0". What other protocols are - there that might be able to use a similar solution, but that might - have other restrictions for the initial letters? Proposal to run ini- - tial range from H to X. Extracting the initial bits then becomes ^ - 'H'. Proposal to have a special convention for all-ASCII labels - (start label with one of the letters not used above).] - - Please note that this solution has the following interesting proper- - ties: - - - For subsequent positions, there is an equivalence between the hex- - adecimal value of the character code and the target letter used. - This assures easy conversion and checking. - - - The absence of digits from the "initial" column, and the fact that - the hyphen is not used, assures that the resulting string conforms - to domain name syntax. - - - Raw sorting of encoded and unencoded domain names is equivalent. - - - The boundaries of characters can always be detected easily. - (While this is important for representations that are used inter- - nally for text editing, it is actually not very important here, - because tools for editing can be assumed to use a more straight- - forward representation internally.) - - - Unless control characters are allowed, the target string will - never actually contain a G. - - - -3.3 Encoding Example - - - As an example, the current domain - - is.s.u-tokyo.ac.jp - - with the components standing for information science, science, the - University of Tokyo, academic, and Japan, might in future be repre- - sented by - - JOUHOU.RI.TOUDAI.GAKU.NIHON - - (a transliteration of the kanji that might probably be chosen to rep- - resent the same domain). Writing each character in U+HHHH notation as - in [Unicode], this results in the following (given for reference - - - - Expires End of January 1998 [Page 7] - -Internet Draft Internationalization of Domain Names July 1997 - - - only, not the actual encoding or something being typed in by the - user): - - U+60c5U+5831.U+7406.U+6771U+5927.U+5b66.U+65e5U+672c - - The software handling internationalized domain names will translate - this, according to the above specifications, before submitting it to - the DNS resolver, to: - - M0C5L831.N406.M771L927.LB66.M5E5M72C.i - - - -3.4 Length Considerations - - - DNS allows for a maximum of 63 positions in each part, and for 255 - positions for the overall domain name including dots. This allows up - to 15 ideographs, or up to 21 letters e.g. from the Hebrew or Arabic - alphabet, in a label. While this does not allow for the same margin - as in the case of ASCII domain names, it should still be quite suffi- - cient. [Problems could only surface for languages that use very long - words or terms and don't know any kind of abbreviations or similar - shortening devices. Do these exist? Islandic expert asserted - Islandic is not a problem.] DNS contains a compression scheme that - avoids sending the same trailing portion of a domain name twice in - the same transmission. Long domain names are therefore not that much - of a concern. - - -4. Usage Considerations - - - -4.1 General Usage - - - To implement this proposal, neither DNS servers nor resolvers need - changes. These programs will only deal with the encoded form of the - domain name with the .i suffix. Software that wants to offer an - internationalized user interface (for example a web browser) is - responsible for the necessary conversions. It will analyze the domain - name, call the resolver directly if the domain name conforms to the - domain name syntax restrictions, and otherwise encode the name - according to the specifications of Section 3.2 and append the .i suf- - fix before calling the resolver. New implementations of resolvers - will of course offer a companion function to gethostbyname accepting - a ISO10646/Unicode string as input. - - - - Expires End of January 1998 [Page 8] - -Internet Draft Internationalization of Domain Names July 1997 - - - For domain name administrators, them main tool that will be needed is - a program to compile files configuring zones from an UTF-8 notation - (or any other suitable encoding) to the encoding described in Section - 3.3. Utility tools will include a corresponding decompiler, checkers - for various kinds of internationalization-related errors, and tools - for managing syntactic parallelism (see Section 4.3). - - -4.2 Usage Restrictions - - - While this proposal in theory allows to have control characters such - as BEL or NUL or symbols such as arrows and smilies in domain names, - such characters should clearly be excluded from domain names. Whether - this has to be explicitly specified or whether the difficulty to type - these characters on any keyboard of the world will limit their use - has to be discussed. One approach is to start with a very restricted - subset and gradually relax it; the other is to allow almost anything - and to rely on common sense. Anyway, such specifications should go - into a separate document to allow easy updates. - - A related point is the question of equivalence. For historical rea- - sons, ISO 10646/Unicode contain considerable number of compatibility - characters and allow more than one representation for characters with - diacritics. To guarantee smooth interoperability in these and related - cases, additional restrictions or the definition of some form of nor- - malization seem necessary. However, this is a general problem - affecting all areas where ISO 10646/Unicode is used in identifiers, - and should therefore be addressed in a generic way. See [iNORM] for - an initial proposal. - - Equally related is the problem of case equivalence. Users can very - well distinguish between upper case and lower case. Also, casing in - an i18n context is not as straightforward as for ASCII, so that case - equivalence is best avoided. Problems therefore result not from the - fact that case is distinguished for i18n domain names, but from the - fact that existing domain names do not distinguish case. Where it is - impossible to distinguish between next.com and NeXT.com, the same two - subdomains would easily be distinguishable if subordinate to a i18n - domain. There are several possible solutions. One is to try to grad- - ually migrate from a case-insensitive solution to a case-sensitive - solution even for ASCII. Another is to allow case-sensitivity only - beyond ASCII. Another is to restrict anything beyond ASCII to lower- - case only (lowercase distinguishes better than uppercase, and is also - generally used for ASCII domain names). - - A problem that also has to be discussed and solved is bidirectional- - ity. Arabic and Hebrew characters are written right-to-left, and the - - - - Expires End of January 1998 [Page 9] - -Internet Draft Internationalization of Domain Names July 1997 - - - mixture with other characters results in a divergence between logical - and graphical sequence. See [HTML-I18N] for more explanations. The - proposal of [Yer96] for dealing with bidirectionality in URLs could - probably be applied to domain names. Anyway, there should be a gen- - eral solution for identifiers, not a DNS-specific solution. - - -4.3 Domain Name Creation - - - The ".i" ZLD should be created as such to allow the internationaliza- - tion of domain names. Rules for creating subdomains inside ".i" - should follow the established rules for the creation of functionally - equivalent domains in the existing domain hierarchy, and should - evolve in parallel. - - For the actual domain hierarchy, the amount of parallelism between - the current ASCII-oriented hierarchy and some internationalized hier- - archy depends on various factors. In some cases, two fully parallel - hierarchies may emerge. In other cases, if more than one script or - language is used locally, more than two parallel hierarchies may - emerge. Some nodes, e.g. in intranets, may only appear in an i18n - hierarchy, whereas others may only appear in the current hierarchy. - In some cases, the pecularities of scripts, languages, cultures, and - the local marketplace may lead to completely different hierarchies. - - Also, one has to be aware that there may be several kinds of paral- - lelisms. The first one is called syntactic parallelism. If there is - a domain XXXX.yy.zz and a domain vvvv.yy.zz, then the domain yy.zz - will have to exist both in the traditional DNS hierarchy as well as - within the hierarchy starting at the .i ZLD, with appropriate encod- - ing. - - The second type of parallelism is called transcription parallelism. - It results by transcribing or transliterating relations between ASCII - domain names and domain names in other scripts. - - The third type of parallelism is called semantic parallelism. It - results from translating elements of a domain name from one language - to another, possibly also changing the script or set of used charac- - ters. - - On the host level, parallelism means that there are two names for the - same host. Conventions should exist to decide whether the parallel - names should have separate IP addresses or not (A record or CNAME - record). With separate IP addresses, address to name lookup is easy, - otherwise it needs special precautions to be able to find all names - corresponding to a given host address. Another detail entering this - - - - Expires End of January 1998 [Page 10] - -Internet Draft Internationalization of Domain Names July 1997 - - - consideration is that MX records only work for hostnames/domains, - not for CNAME aliases. This at least has the consequence that alias - resolution for internationalized mail addresses has to occur before - MX record lookup. - - When discussing and applying the rules for creating domain names, - some peculiarities of i18n domain names should be carefully consid- - ered: - - - Depending on the script, reasonable lengths for domain name parts - may differ greatly. For ideographic scripts, a part may often be - only a one-letter code. Established rules for lengths may need - adaptation. For example, a rule for country TLDs could read: one - ideographic character or two other characters. - - - If the number of generic TLDs (.com, .edu, .org, .net) is kept - low, then it may be feasible to restrict i18n TLDs to country - TLDs. - - - There are no ISO 3166 [ISO3166] two-letter codes in scripts other - than Latin. I18n domain names for countries will have to be - designed from scratch. - - - The names of some countries or regions may pose greater political - problems when expressed in the native script than when expressed - in 2-letter ISO 3166 codes. - - - I18n country domain names should in principle only be created in - those scripts that are used locally. There is probably little use - in creating an Arabic domain name for China, for example. - - - In those cases where domain names are open to a wide range of - applicants, a special procedure for accepting applications should - be used so that a reasonable-quality fit between ASCII domain - names and i18n domain names results where desired. This would - probably be done by establishing a period of about a month for - applications inside a i18n domain newly created as a parallel for - an existing domain, and resolving the detected conflicts. For - syntactically parallel domain names, the owners should always be - the same. Administration may be split in some cases to account for - the necessary linguistic knowledge. For domain names with tran- - scription parallelism and semantic parallelism, the question of - owner identity should depend on the real-life situation (trade- - marks,...). - - - It will be desirable to have internationalized subdomains in non- - internationalized TLDs. As an example, many companies in France - may want to register an accented version of their company name, - - - - Expires End of January 1998 [Page 11] - -Internet Draft Internationalization of Domain Names July 1997 - - - while remaining under the .fr TLD. For this, .fr would have to be - reregistered as .M6N2.i. Accented and other internationalized sub- - domains would go below .M6N2.i, whereas unaccented ones would go - below .fr in its plain form. - - - To generalize the above case, one may need to create a requirement - that any domain name registry would have to register and manage - syntactically parallel domain names below the .i ZLD upon request - to allow registration of i18n domain names in arbitrary subdo- - mains. An alternative to this is to organize domain name search - so that e.g. in a search for XXXXXX.fr, if M6N2.i is not found in - .i, the name server for .fr is queried for XXXXXX.M6N2.i (with - XXXXXX appropriately encoded). This convention would allow lower- - level domains to introduce internationalized subdomains without - depending on higher-level domains. - - - -4.4 Usage in URLs - - According to current definitions, URLs encode sequences of octets - into a sequence of characters from a character set that is almost as - limited as the character set of domain names [RFC1738]. This is - clearly not satisfying for i18n. - - Internationalizing URLs, i.e. assigning character semantics to the - encoded octets, can either be done separately for each part and/or - scheme, or in an uniform way. Doing it separately has the serious - disadvantage that software providing user interfaces for URLs in gen- - eral would have to know about all the different i18n solutions of the - different parts and schemes. Many of these solutions may not even be - known yet. - - It is therefore definitely more advantageous to decide on a single - and consistent solution for URL internationalization. The most valu- - able candidate [Yer96], for many reasons, is UTF-8 [RFC2044], an - ASCII-compatible encoding of UCS4. - - Therefore, an URL containing the domain name of the example of Sec- - tion 3.3 should not be written as: - - ftp://M0C5L831.N406.M771L927.LB66.M5E5M72C.i - - (although this will also work) but rather - - ftp://%e6%83%85%e5%a0%b1.%e7%90%86.%e6%9d%b1%e5%a4%a7. - %e5%ad%a6.%e6%97%a5%e6%9c%ac - - - - - Expires End of January 1998 [Page 12] - -Internet Draft Internationalization of Domain Names July 1997 - - - In this canonical form, the trailing .i is absent, and the octets can - be reconstructed from the %HH-encoding and interpreted as UTF-8 by - generic URL software. The software part dealing with domain names - will carry out the conversion to the .i form. - - -5. Alternate Proposals - - - -5.1 The Dillon Proposal - - The proposal of Michael Dillon [Dillon96] is also based on encoding - Unicode into the limited character set of domain names. Distinction - is done for each part, using the hyphen in initial position. Because - this does not fully conform to the syntax of existing domain names, - it is questionable whether it is backwards-compatible. On the other - hand, this has the advantage that local i18n domain names can be - installed easily without cooperation by the manager of the superdo- - main. - - A variable-length scheme with base 36 is used that can encode up to - 1610 characters, absolutely insufficient for Chinese or Japanese. - Characters assumed not to be used in i18n domain names are excluded, - i.e. only one case is allowed for basic Latin characters. This means - that large tables have to be worked out carefully to convert between - ISO 10646/Unicode and the actual number that is encoded with base= - 36. - - -5.2 Using a Separate Lookup Service - - Instead of using a special encoding and burdening DNS with i18n, one - could build and use a separate lookup service for i18n domain names. - Instead of converting to UCS4 and encoding according to Section 3.2, - and then calling the DNS resolver, a program would contact this new - service when seeing a domain name with characters outside the allowed - range. - - Such solutions have various problems. There are many directory ser- - vices and proposals for how to use them in a way similar to DNS. For - an overview and a specific proposal, see [Kle96]. However, while - there are many proposals, a real service containing the necessary - data and providing the wide installed base and distributed updating - is in DNS does not exist. - - Most directory service proposals also do not offer uniqueness. - Defining unique names again for a separate service will duplicate - much of the work done for DNS. If uniqueness is not guaranteed, the - - - - Expires End of January 1998 [Page 13] - -Internet Draft Internationalization of Domain Names July 1997 - - - user is bundened with additional selection steps. - - Using a separate lookup service for the internationalization of - domain names also results in more complex implementations than the - proposal made in this draft. Contrary to what some people might - expect, the use of a separate lookup service also does not solve a - capacity problem with DNS, because there is no such problem, nor will - one be created with the introduction of i18n domain names. - - -6. Generic Considerations - - - -6.1 Security Considerations - - This proposal is believed not to raise any other security considera- - tions than the current use of the domain name system. - - -6.2 Internationalization Considerations - - This proposal addresses internationalization as such. The main addi- - tional consideration with respect to internationalization may be the - indication of language. However, for concise identifiers such as - domain names, language tagging would be too much of a burden and - would create complex dependencies with semantics. - - - NOTE -- This section is introduced based on a recommenda- - tion in [RFCIAB]. A similar section addressing internation- - alization should be included in all application level - internet drafts and RFCs. - - - - - -Acknowledgements - - I am grateful in particular to the following persons for their advice - or criticism: Bert Bos, Lori Brownell, Michael Dillon, Donald E. - Eastlake 3rd, David Goldsmith, Larry Masinter, Ryan Moats, Keith - Moore, Thorvardur Kari Olafson, Erik van der Poel, Jurgen Schwertl, - Paul A. Vixie, Francois Yergeau, and others. - - - - - - - Expires End of January 1998 [Page 14] - -Internet Draft Internationalization of Domain Names July= - 1997 - - -Bibliography - - [ASCII] Coded Character Set -- 7-Bit American Standard Code - for Information Interchange, ANSI X3.4-1986. - - [Dillon96] M. Dillon, "Multilingual Domain Names", Memra Software - Inc., November 1996 (circulated Dec. 6, 1996 on iahc- - discuss@iahc.org). - - [HTML-I18N] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Inter- - nationalization of the Hypertext Markup Language", - Work in progress (draft-ietf-html-i18n-05.txt), August - 1996. - - [iNORM] M. Duerst, "Normalization of Internationalized Identi- - fiers", draft-duerst-i18n-norm-00.txt, July 1997. - - [ISO3166] ISO 3166, "Code for the representation of names of - countries", ISO 3166:1993. - - [ISO10646] ISO/IEC 10646-1:1993. International standard -- Infor- - mation technology -- Universal multiple-octet coded - character Set (UCS) -- Part 1: Architecture and basic - multilingual plane. - - [Kle96] J. Klensin and T. Wolf, Jr., "Domain Names and Company - Name Retrieval", Work in progress (draft-klensin-tld- - whois-01.txt), November 1996. - - [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facili- - ties", ISI, Nov. 1987. - - [RFC1035] P. Mockapetris, "Domain Names - Implementation and - Specification", ISI, Nov. 1987. - - [RFC1522] K. Moore, "MIME (Multipurpose Internet Mail Exten- - sions) Part Two: Message Header Extensions for Non- - ASCII Text", University of Tennessee, September 1993. - - [RFC1642] D. Goldsmith, M. Davis, "UTF-7: A Mail-safe Transfor- - mation Format of Unicode", Taligent Inc., July 1994. - - [RFC1730] C. Malamud and M. Rose, "Principles of Operation for - the TPC.INT Subdomain: General Principles and Policy", - Internet Multicasting Service, October 1993. - - [RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill, - "Uniform Resource Locators (URL)", CERN, Dec. 1994. - - - - Expires End of January 1998 [Page 15] - -Internet Draft Internationalization of Domain Names July 1997 - - - [RFC2044] F. Yergeau, "UTF-8, A Transformation Format of Unicode - and ISO 10646", Alis Technologies, October 1996. - - [RFCIAB] C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. - Atkinson, M. Crispin, P. Svanberg, "Report from the - IAB Character Set Workshop", October 1996 (currently - available as draft-weider-iab-char-wrkshop-00.txt). - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 2.0", Addison-Wesley, Reading, MA, 1996. - - [Yer96] F. Yergeau, "Internationalization of URLs", Alis Tech- - nologies, - = - . - - - -Author's Address - - Martin J. Duerst - World Wide Web Consortium - Keio Research Institute at SFC - Keio University - 5322 Endo - Fujisawa - 252-8520 Japan - - Tel: +81 466 49 11 70 - E-mail: mduerst@w3.org - - - NOTE -- Please write the author's name with u-Umlaut wherever - possible, e.g. in HTML as Dürst. - - - - - - - - - - - - - - - - - - - Expires End of January 1998 [Page 16] - diff --git a/doc/expired/draft-dunlap-dns-duxfr-00.txt b/doc/expired/draft-dunlap-dns-duxfr-00.txt deleted file mode 100644 index d299ac282b..0000000000 --- a/doc/expired/draft-dunlap-dns-duxfr-00.txt +++ /dev/null @@ -1,336 +0,0 @@ - DNSIND Working Group K. Dunlap - INTERNET-DRAFT Check Point Software - P. Vixie - ISC - September 1999 - - Dynamic Update Zone Transfer - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - Status of This Memo - - This draft, file name draft-dunlap-dns-duxfr-00.txt, is intended to - become a Proposed Standard RFC. Distribution of this document is unlim- - ited. Comments should be sent to or to the - authors. - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. Internet-Drafts are working docu- - ments of the Internet Engineering Task Force (IETF), its areas, and its - working groups. Note that other groups may also distribute working - documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is not appropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - To view the list Internet-Draft Shadow Directories, see - http://www.ietf.org/shadow.html. - - Abstract - - This document proposes an alternative extension to the DNS protocol for - Incremental zone transfer (IXFR) [RFC1995]. This extension uses the - mechanisms for adding and deleting Resource Records specified in - [RFC2136] to transmit the changes between authoritative servers of a - zone. - - Expires March 2000 [Page 1] - - INTERNET-DRAFT DNS DUXFR September 1999 - - 1 - Introduction - - For rapid propagation of changes to a DNS database [STD13], it is neces- - sary to reduce latency by actively notifying servers of the change. - This is accomplished by the DNS NOTIFY Mechanism [RFC1996]. - - The simple method described for Incremental transfer (IXFR), in - [RFC1995], does not adequately address the complexity of the problem. - - Dynamic Update Zone Transfer (DUXFR), as proposed, is a mechanism to - transmit the complexity of changes in the zone and still have the effi- - ciency of IXFR means to propagate changed portions of a zone. - - In this document, a slave name server which requests DUXFR is called a - DUXFR client and a master or slave name server which responds to the - request is called a DUXFR server. - - 2 - Brief Description of the Protocol - - If a DUXFR client, which likely has an older version of a zone, thinks - it needs a newer version of the zone (typically through SOA refresh - timeout or the NOTIFY mechanism), it sends a DUXFR message containing - the SOA serial number of its (presumably outdated) copy of the zone. - - A DUXFR server should keep record of the newest version of the zone and - the differences between that copy and several older versions. When a - DUXFR request with an older version number is received, the DUXFR server - needs to send only the differences required to make that version - current. These differences are sent using the DNS UPDATE format packets - for deletes and add specified in [RFC2136 2.5]. - - When a zone has been updated, it should be saved in stable storage - before the new version is used to respond to DUXFR (or AXFR) queries. - Otherwise, if the server crashes, data which is no longer available may - have been distributed to slave servers, which can cause persistent data- - base inconsistencies. - - If a DUXFR query with the same or newer version number than that of the - server is received, it is replied to with a single SOA record of the - server's current version, just as in IXFR. - - The Transport protocol for DUXFR queries is TCP/IP. - - Expires March 2000 [Page 2] - - INTERNET-DRAFT DNS DUXFR September 1999 - - 3 - Query Format - - The DUXFR Query format is based on the standard DNS UPDATE Message For- - mat. In the DNS Packet Header the Opcode is set to UPDATE and the Zone - Type (ZTYPE) being set to AXFR. The Additional section containing the - SOA record of the client's version of the zone. - - 4 - Response Format - - The response packets to the DUXFR query are in the standard DNS UPDATE - Message Format. The records in the Update Section are formatted using - the four sets of semantics for adding and deleting Resource Records - specified in the ``Update Section'' in [RFC2136 2.5]. The client will - process these changes using the prerequisite for the transaction as the - existence of the SOA serial number specified in the Additional section - of the DUXFR query. - - The response to a DUXFR query, when the server no longer has all the - previous history from the version the client requests, will be a - Response code (RCODE) of "Refused". It is recommended that the client - retry with an AXFR query described in [RFC1034 4.3.5]. - - It is recommended that the Prerequisite sections of the DNS message be - empty on transmission and ignored on reception. The Additional section - may contain necessary data such as signatures as specified by other - extensions to [RFC 2136]. - - 5 - Version Overhead - - A DUXFR server can not be required to hold all previous versions forever - and may delete them anytime. In general, there is a trade-off between - the size of storage space and the possibility of using DUXFR. - - Information about older versions should be purged if the total length of - a DUXFR response would be longer than that of an AXFR response. Given - that the purpose of DUXFR is to reduce AXFR overhead, this strategy is - quite reasonable. The strategy assures that the amount of storage - required is at most twice that of the current zone information. - - Information older than the SOA expire period may also be purged. - - 6 - IANA Considerations - - No IANA services are required by this document. - - Expires March 2000 [Page 3] - - INTERNET-DRAFT DNS DUXFR September 1999 - - 7 - Security Considerations - - DNS is related to several security problems, no attempt is made to fix - them in this document. - - The authors believe that this document does not introduce any additional - security problems to the current DNS protocol. - - 8 - Examples - - Given the following three generations of data with the current serial - number of 3. - - Example.Com. IN SOA NS.Example.Com. admin.Example.Com. -( - 1 600 600 3600000 604800 ) - IN NS NS.Example.Com. - NS.Example.Com. IN A 192.168.1.5 - Vangogh.Example.Com. IN A 192.168.1.21 - - Vangogh.Example.Com. is removed and Monet.Example.Com. is added. - - Example.Com. IN SOA NS.Example.Com. admin.Example.Com. ( - 2 600 600 3600000 604800 ) - IN NS NS.Example.Com. - NS.Example.Com. IN A 192.168.1.5 - Monet.Example.Com. IN A 192.168.6.27 - IN A 192.168.3.128 - - One of the IP address of Monet.Example.Com. is changed. - - Example.Com. IN SOA NS.Example.Com. admin.Example.Com. ( - 3 600 600 3600000 604800 ) - IN NS NS.Example.Com. - NS.Example.Com. IN A 192.168.1.5 - Monet.Example.Com. IN A 192.168.6.42 - IN A 192.168.3.128 - - Expires March 2000 [Page 4] - - INTERNET-DRAFT DNS DUXFR September 1999 - - The following DUXFR query: - - +--------------------------------------------------+ - Header | OPCODE=QUERY, QR=Request | - +--------------------------------------------------+ - Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR | - +--------------------------------------------------+ - Prerequisite | | - +--------------------------------------------------+ - Update | | - +--------------------------------------------------+ - Additional | Example.Com. IN SOA serial=1 | - +--------------------------------------------------+ - - The reply could be with the following DUXFR response with Update packets - in the Answer Section: - - +--------------------------------------------------+ - Header | OPCODE=QUERY, QR=Response | - +--------------------------------------------------+ - Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR | - +--------------------------------------------------+ - Prerequisite | Example.Com. IN SOA serial=1 | - +--------------------------------------------------+ - Update | Vangogh.Example.Com. 0 ANY A 192.168.1.21 | - | Monet.Example.Com. IN A 192.168.6.42 | - | Monet.Example.Com. IN A 192.168.3.128 | - | Example.Com. 0 IN SOA serial=1 | - | Example.Com. IN SOA serial=2 | - | Monet.Example.Com. 0 ANY A 192.168.6.42 | - | Example.Com. 0 ANY SOA serial=2 | - | Example.Com. IN SOA serial=3 | - +--------------------------------------------------+ - Additional | | - +--------------------------------------------------+ - - or with the following Compressed DUXFR response with Update packets in - the Answer Section: - - Expires March 2000 [Page 5] - - INTERNET-DRAFT DNS DUXFR September 1999 - - +--------------------------------------------------+ - Header | OPCODE=QUERY, QR=Response | - +--------------------------------------------------+ - Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR | - +--------------------------------------------------+ - Prerequisite | Example.Com. IN SOA serial=1 | - +--------------------------------------------------+ - Update | Vangogh.Example.Com. 0 ANY A 192.168.1.21 | - | Monet.Example.Com. IN A 192.168.6.42 | - | Monet.Example.Com. IN A 192.168.3.128 | - | Example.Com. 0 ANY SOA serial=1 | - | Example.Com. IN SOA serial=3 | - +--------------------------------------------------+ - Additional | | - +--------------------------------------------------+ - - References - - [RFC1034]] - P. Mockapetris, ``Domain Names - Concepts and Facilities'' STD - 13, RFC 1034, USC/Information Sciences Institute, November 1987. - - [RFC1035] - P. Mockapetris, ``Domain Names - Implementation and Specifica- - tion'' RFC 1035, USC/Information Sciences Institute, November - 1987. - - [RFC1996] - P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes - (DNS Notify)'' RFC 1996, August 1996 - - [RFC1995] - M. Ohta, ``Incremental Zone Transfer in DNS'' RFC 1995, August - 1996. - - [RFC2026] - S. Bradner, ``the Internet Standards Process -- Revision 3'' RFC - 2026, Harvard University, October 1996. - - [RFC2136] - P. Vixie, S. Thomson, Y. Rekhter and J. Bound, ``Dynamic - Updates in the Domain Name System (DNS UPDATE)'' RFC 2136, - April 1997 - - Expires March 2000 [Page 6] - - INTERNET-DRAFT DNS DUXFR September 1999 - - Author's Address - - Kevin J. Dunlap - Check Point Software Technologies, Inc. - The Meta IP Group - 119 South Main Street, Suite 200 - Seattle, WA 98033 - +1 206 674 3700 - - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - +1 650 779 7001 - - - Expires March 2000 [Page 7] - - INTERNET-DRAFT DNS DUXFR September 1999 - - Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished -to - others, and derivative works that comment on or otherwise explain -it - or assist in its implementation may be prepared, copied, -published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph -are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by -removing - the copyright notice or references to the Internet Society or -other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other -than - English. - - The limited permissions granted above are perpetual and will not -be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on -an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET -ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, -INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - Expires March 2000 [Page 8] diff --git a/doc/expired/draft-ietf-dnsext-iana-dns-00.txt b/doc/expired/draft-ietf-dnsext-iana-dns-00.txt deleted file mode 100644 index 84116106bc..0000000000 --- a/doc/expired/draft-ietf-dnsext-iana-dns-00.txt +++ /dev/null @@ -1,696 +0,0 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd - Eric Brunner - Bill Manning -Expires: June 2000 February 2000 - - - - Domain Name System (DNS) IANA Considerations - ------ ---- ------ ----- ---- -------------- - - - - -Status of This Document - - Distribution of this draft , which - is intended to become a Best Current Practice, is unlimited. Comments - should be sent to the DNS Working Group mailing list - or to the authors. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - -Abstract - - Internet Assigned Number Authority (IANA) parameter assignment - considerations are given for the allocation of Domain Name System - (DNS) classes, RR types, operation codes, error codes, etc. - - - - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 1] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. DNS Query/Response Headers..............................3 - 2.1 One Spare Bit?.........................................4 - 2.2 Opcode Assignment......................................4 - 2.3 RCODE Assignment.......................................5 - 3. DNS Resource Records....................................5 - 3.1 RR TYPE IANA Considerations............................7 - 3.1.1 Special Note on the OPT RR...........................8 - 3.2 RR CLASS IANA Considerations...........................8 - 3.3 RR NAME Considerations.................................9 - 4. Designated Expert......................................10 - 5. Security Considerations................................10 - References................................................10 - - Authors Addresses.........................................12 - Expiration and File Name..................................12 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 2] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -1. Introduction - - The Domain Name System (DNS) provides replicated distributed secure - hierarchical databases which hierarchically store "resource records" - (RRs) under domain names. - - This data is structured into CLASSes and zones which can be - independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535] - familiarity with which is assumed. - - This document covers, either directly or by reference, general IANA - parameter assignment considerations applying across DNS query and - response headers and all RRs. There may be additional IANA - considerations that apply to only a particular RR type or - query/response opcode. See the specific RFC defining that RR type or - query/response opcode for such considerations if they have been - defined. - - IANA currently maintains a web page of DNS parameters at - . - - "IETF Standards Action", "IETF Consensus", "Specification Required", - and "Private Use" are as defined in [RFC 2434]. - - - -2. DNS Query/Response Headers - - The header for DNS queries and responses contains field/bits in the - following diagram taken from [RFC 2136, 2535]: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ID | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT/ZOCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT/PRCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT/UPCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The ID field identifies the query and is echoed in the response so - they can be matched. - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 3] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - - The QR bit indicates whether the header is for a query or a response. - - The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful - only in queries or only in responses, depending on the bit. However, - many DNS implementations copy the query header as the initial value - of the response header without clearing bits. Thus any attempt to - use a "query" bit with a different meaning in a response or to define - a query meaning for a "response" bit is dangerous given existing - implementation. Such meanings may only be assigned by an IETF - Standards Action. - - The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), - authority count (NSCOUNT), and additional information count (ARCOUNT) - express the number of records in each section for all opcodes except - Update. These fields have the same structure and data type for - Update but are instead the counts for the zone (ZOCOUNT), - prerequisite (PRCOUNT), update (UPCOUNT), and additional information - (ARCOUNT) sections. - - - -2.1 One Spare Bit? - - There have been ancient DNS implementations for which the Z bit being - on in a query meant that only a response from the primary server for - a zone is acceptable. It is believed that current DNS - implementations ignore this bit. - - Assigning a meaning to the Z bit requires an IETF Standards Action. - - - -2.2 Opcode Assignment - - New OpCode assignments require an IETF Standards Action. - - Currently DNS OpCodes are assigned as follows: - - OpCode Name Reference - - 0 Query [RFC 1035] - 1 IQuery (Inverse Query) [RFC 1035] - 2 Status [RFC 1035] - 3 available for assignment - 4 Notify [RFC 1996] - 5 Update [RFC 2136] - 6-15 available for assignment - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 4] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -2.3 RCODE Assignment - - It would appear from the DNS header above that only four bits of - RCODE, or response/error code are available. However, RCODEs can - appear not only at the top level of a DNS response but also inside - TSIG RRs [RFC XXX3] and OPT RRs [RFC 2671]. The OPT RR provides an - eight bit extension resulting in a 12 bit RCODE field and the TSIG RR - has a 16 bit RCODE field. - - RCODE Name Description Reference - Decimal - Hexadecimal - 0 NoError No Error [RFC 1035] - 1 FormErr Format Error [RFC 1035] - 2 ServFail Server Failure [RFC 1035] - 3 NXDomain Non-Existent Domain [RFC 1035] - 4 NotImp Not Implemented [RFC 1035] - 5 Refused Query Refused [RFC 1035] - 6 YXDomain Name Exists when it should not [RFC 2136] - 7 YXRRSet RR Set Exists when it should not [RFC 2136] - 8 NXRRSet RR Set that should exist does not [RFC 2136] - 9 NotAuth Server Not Authoritative for zone [RFC 2136] - 10 NotZone Name not contained in zone [RFC 2136] - 11-15 available for assignment - 16 BADVERS Bad OPT Version [RFC 2671] - 16 BADSIG TSIG Signature Failure [RFC XXX3] - 17 BADKEY Key not recognized [RFC XXX3] - 18 BADTIME Signature out of time window [RFC XXX3] - 19-3840 available for assignment - 0x0013-0x0F00 - 3841-4095 Private Use - 0x0F01-0x0FFF - 4096-65535 available for assignment - 0x1000-0xFFFF - - Since it is important that RCODEs be understood for interoperability, - assignment of new RCODE listed above as "available for assignment" - requires an IETF Consensus. - - - -3. DNS Resource Records - - All RRs have the same top level format shown in the figure below - taken from [RFC 1035]: - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 5] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | | - / / - / NAME / - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TYPE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | CLASS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TTL | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | RDLENGTH | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| - / RDATA / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - NAME is an owner name, i.e., the name of the node to which this - resource record pertains. NAMEs are specific to a CLASS as described - in section 3.2. NAMEs consist of an ordered sequence of one or more - labels each of which has a label type [RFC 1035, 2671]. - - TYPE is a two octet unsigned integer containing one of the RR TYPE - codes. See section 3.1. - - CLASS is a two octet unsigned integer containing one of the RR CLASS - codes. See section 3.2. - - TTL is a four octet (32 bit) bit unsigned integer that specifies the - number of seconds that the resource record may be cached before the - source of the information should again be consulted. Zero is - interpreted to mean that the RR can only be used for the transaction - in progress. - - RDLENGTH is an unsigned 16 bit integer that specifies the length in - octets of the RDATA field. - - RDATA is a variable length string of octets that constitutes the - resource. The format of this information varies according to the - TYPE and in some cases the CLASS of the resource record. - - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 6] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -3.1 RR TYPE IANA Considerations - - There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, - and MetaTYPEs. - - Data TYPEs are the primary means of storing data. QTYPES can only be - used in queries. Meta-TYPEs designate transient data associated with - an particular DNS message and in some cases can also be used in - queries. Thus far, data TYPEs have been assigned from 1 upwards plus - the block from 100 through 103 while Q and Meta Types have been - assigned from 255 downwards (except for the OPT Meta-RR which is - assigned TYPE 41). There have been DNS implementations which made - caching decisions based on the top bit of the bottom byte of the RR - TYPE. - - There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG - [RFC XXX3], and TKEY [work in progress]. - - There are currently five QTYPEs assigned: * (all), MAILA, MAILB, - AXFR, and IXFR. - - Considerations for the allocation of new RR TYPEs are as follows: - - Decimal - Hexadecimal - - 0 - 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC - 2535] and in other circumstances and must never be allocated - for ordinary use. - - 1 - 127 - 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data - TYPEs by IETF Consensus. - - 128 - 255 - 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and - Meta TYPEs by IETF Consensus. - - 256 - 32767 - 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF - Consensus. - - 32768 - 65279 - 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. - - 65280 - 65535 - 0xFF00 - 0xFFFF - Private Use. - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 7] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -3.1.1 Special Note on the OPT RR - - The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its - primary purpose is to extend the effective field size of various DNS - fields including RCODE, label type, OpCode, flag bits, and RDATA - size. In particular, for resolvers and servers that recognize it, it - extends the RCODE field from 4 to 12 bits. - - - -3.2 RR CLASS IANA Considerations - - DNS CLASSes have been little used but constitute another dimension of - the DNS distributed database. In particular, there is no necessary - relationship between the name space or root servers for one CLASS and - those for another CLASS. The same name can have completely different - meanings in different CLASSes although the label types are the same - and the null label is usable only as root in every CLASS. However, - as global networking and DNS have evolved, the IN, or Internet, CLASS - has dominated DNS use. - - There are two subcategories of DNS CLASSes: normal data containing - classes and QCLASSes that are only meaningful in queries or updates. - - The current CLASS assignments and considerations for future - assignments are as follows: - - Decimal - Hexadecimal - - 0 - 0x0000 - assignment requires an IETF Standards Action. - - 1 - 0x0001 - Internet (IN). - - 2 - 0x0002 - available for assignment by IETF Consensus as a data CLASS. - - 3 - 0x0003 - Chaos (CH) [Moon 81]. - - 4 - 0x0004 - Hesiod (HS) [Dyer 87]. - - 5 - 127 - 0x0005 - 0x007F - available for assignment by IETF Consensus as data - CLASSes only. - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 8] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - - 128 - 253 - 0x0080 - 0x00FD - available for assignment by IETF Consensus as - QCLASSes only. - - 254 - 0x00FE - QCLASS None [RFC 2136]. - - 255 - 0x00FF - QCLASS Any [RFC 1035]. - - 256 - 32767 - 0x0100 - 0x7FFF - assigned by IETF Consensus. - - 32768 - 65280 - 0x8000 - 0xFEFF - assigned based on Specification Required as defined - in [RFC 2434]. - - 65280 - 65534 - 0xFF00 - 0xFFFE - Private Use. - - 65535 - 0xFFFF - can only be assigned by an IETF Standards Action. - - - -3.3 RR NAME Considerations - - DNS NAMEs are sequences of labels [RFC 1035]. The last label in each - NAME is "ROOT" which is the zero length label. By definition, the - null or ROOT label can not be used for any other NAME purpose. - - At the present time, there are two categories of label types, data - labels and compression labels. Compression labels are pointers to - data labels elsewhere within an RR or DNS message and are intended to - shorten the wire encoding of NAMEs. The two existing data label - types are frequently referred to as ASCII and Binary. ASCII labels - can, in fact, include any octet value including zero octets but most - current uses involve only [US-ASCII] For retrieval ASCII labels are - defined to treat upper and lower case letters the same. Binary - labels are bit sequences [RFC 2673]. - - IANA considerations for label types are given in [RFC 2671]. - - NAMEs are local to a CLASS. The Hesiod [Dyer 87] and Chaos [Moon 81] - CLASSes are essentially for local use. The IN or Internet CLASS is - thus the only DNS CLASS in global use on the Internet at this time. - - A somewhat dated description of name allocation in the IN Class is - given in [RFC 1591]. Some information on reserved top level domain - names is in Best Current Practice 32 [RFC 2606]. - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 9] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -4. Designated Expert - - To provide additional support to IANA in the DNS area, the IESG MAY - appoint a designed expert. - - - -5. Security Considerations - - This document addresses IANA considerations in the allocation of - general DNS parameters, not security. See [RFC 2535] for secure DNS - considerations. - - - -References - - [Dyer 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical - Plan - Name Service, April 1987, - - [Moon 81] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts - Institute of Technology Artificial Intelligence Laboratory, June - 1981. - - [RFC 1034] - P. Mockapetris, "Domain Names - Concepts and - Facilities", STD 13, November 1987. - - [RFC 1035] - P. Mockapetris, "Domain Names - Implementation and - Specifications", STD 13, November 1987. - - [RFC 1591] - J. Postel, "Domain Name System Structure and - Delegation", March 1994. - - [RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", August 1996. - - [RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. - - [RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS - Specification", July 1997. - - [RFC 2434] - "Guidelines for Writing an IANA Considerations Section - in RFCs", T. Narten, H. Alvestrand, October 1998. - - [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", - March 1999. - - [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", - June 1999. - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 10] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - - [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August - 1999. - - [RFC 2672] - M. Crawford, " Non-Terminal DNS Name Redirection", - August 1999. - - [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", - August 1999. - - [RFC XXX3] - P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, - "Secret Key Transaction Signatures for DNS (TSIG)", xxx 2000 (draft- - ietf-dnsind-tsig-*.txt). - - [US-ASCII] - ANSI, "USA Standard Code for Information - Interchange", X3.4, American National Standards Institute: New York, - 1968. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 11] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -Authors Addresses - - Donald E. Eastlake 3rd - Motorola - 65 Shindegan Hill Road - Carmel, NY 10512 USA - - Telephone: +1-914-276-2668 (h) - +1-508-261-5434 (w) - email: dee3@torque.pothole.com - - - Eric Brunner - 1415 Forest Avenue - Portland, ME 04103 USA - - Telephone: +1 207-797-0525 - email: brunner@world.std.com - - - Bill Manning - USC/ISI - 4676 Admiralty Way, #1001 - Marina del Rey, CA 90292 USA - - Telephone: +1 310 822 1511 - email: bmanning@isi.edu - - - -Expiration and File Name - - This draft expires August 2000. - - Its file name is draft-ietf-dnsext-iana-dns-00.txt. - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 12] - diff --git a/doc/expired/draft-ietf-dnsind-binary-labels-05.txt b/doc/expired/draft-ietf-dnsind-binary-labels-05.txt deleted file mode 100644 index 93a8de5b7f..0000000000 --- a/doc/expired/draft-ietf-dnsind-binary-labels-05.txt +++ /dev/null @@ -1,337 +0,0 @@ -DNSIND Working Group Matt Crawford -Internet Draft Fermilab - May 5, 1999 - - Binary Labels in the Domain Name System - - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet- Drafts as - reference material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - -1. Introduction and Terminology - - This document defines a ``Bit-String Label'' which may appear within - domain names. This new label type compactly represents a sequence - of ``One-Bit Labels'' and enables resource records to be stored at - any bit-boundary in a binary-named section of the domain name tree. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [KWORD]. - - -2. Motivation - - Binary labels are intended to efficiently solve the problem of - storing data and delegating authority on arbitrary boundaries when - the structure of underlying name space is most naturally represented - in binary. - - - - - - - -Expires November 10, 1999 Crawford [Page 1] - -Internet Draft Binary DNS Labels May 5, 1999 - - -3. Label Format - - Up to 256 One-Bit Labels can be grouped into a single Bit-String - Label. Within a Bit-String Label the most significant or "highest - level" bit appears first. This is unlike the ordering of DNS labels - themselves, which has the least significant or "lowest level" label - first. Nonetheless, this ordering seems to be the most natural and - efficient for representing binary labels. - - Among consecutive Bit-String Labels, the bits in the first-appearing - label are less significant or "at a lower level" than the bits in - subsequent Bit-String Labels, just as ASCII labels are ordered. - - -3.1. Encoding - - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . . - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+ - |0 1| ELT | Count | Label ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+ - - (Each tic mark represents one bit.) - - - ELT 000001 binary, the six-bit extended label type [EDNS0] - assigned to the Bit-String Label. - - Count The number of significant bits in the Label field. A - Count value of zero indicates that 256 bits are - significant. (Thus the null label representing the DNS - root cannot be represented as a Bit String Label.) - - Label The bit string representing a sequence of One-Bit Labels, - with the most significant bit first. That is, the One-Bit - Label in position 17 in the diagram above represents a - subdomain of the domain represented by the One-Bit Label - in position 16, and so on. - - The Label field is padded on the right with zero to seven - pad bits to make the entire field occupy an integral - number of octets. These pad bits MUST be zero on - transmission and ignored on reception. - - A sequence of bits may be split into two or more Bit-String Labels, - but the division points have no significance and need not be - preserved. An excessively clever server implementation might split - - - -Expires November 10, 1999 Crawford [Page 2] - -Internet Draft Binary DNS Labels May 5, 1999 - - - Bit-String Labels so as to maximize the effectiveness of message - compression [DNSIS]. A simpler server might divide Bit-String - Labels at zone boundaries, if any zone boundaries happen to fall - between One-Bit Labels. - - -3.2. Textual Representation - - A Bit-String Label is represented in text -- in a zone file, for - example -- as a surrounded by the delimiters "\[" and - "]". The is either a dotted quad or a base indicator and - a sequence of digits appropriate to that base, optionally followed - by a slash and a length. The base indicators are "b", "o" and "x", - denoting base 2, 8 and 16 respectively. The length counts the - significant bits and MUST be between 1 and 32, inclusive, after a - dotted quad, or between 1 and 256, inclusive, after one of the other - forms. If the length is omitted, the implicit length is 32 for a - dotted quad or 1, 3 or 4 times the number of binary, octal or - hexadecimal digits supplied, respectively, for the other forms. - - In augmented Backus-Naur form [ABNF], - - bit-string-label = "\[" bit-spec "]" - - bit-spec = bit-data [ "/" length ] - / dotted-quad [ "/" slength ] - - bit-data = "x" 1*64HEXDIG - / "o" 1*86OCTDIG - / "b" 1*256BIT - - dotted-quad = decbyte "." decbyte "." decbyte "." decbyte - - decbyte = 1*3DIGIT - - length = NZDIGIT *2DIGIT - - slength = NZDIGIT [ DIGIT ] - - OCTDIG = %x30-37 - - NZDIGIT = %x31-39 - - If a is present, the number of digits in the - MUST be just sufficient to contain the number of bits specified by - the . If there are insignificant bits in a final - hexadecimal or octal digit, they MUST be zero. A - always has all four parts even if the associated is less - - - -Expires November 10, 1999 Crawford [Page 3] - -Internet Draft Binary DNS Labels May 5, 1999 - - - than 24, but, like the other forms, insignificant bits MUST be zero. - - Each number represented by a must be between 0 and 255, - inclusive. - - The number represented by must be between 1 and 256 - inclusive. - - The number represented by must be between 1 and 32 - inclusive. - - When the textual form of a Bit-String Label is generated by machine, - the length SHOULD be explicit, not implicit. - - -3.2.1. Examples - - The following four textual forms represent the same Bit-String - Label. - - \[b11010000011101] - \[o64072/14] - \[xd074/14] - \[208.116.0.0/14] - - The following represents two consecutive Bit-String Labels which - denote the same relative point in the DNS tree as any of the above - single Bit-String Labels. - - \[b11101].\[o640] - - - -3.3. Canonical Representation and Sort Order - - Both the wire form and the text form of binary labels have a degree - of flexibility in their grouping into multiple consecutive Bit- - String Labels. For generating and checking DNS signature records - [DNSSEC] binary labels must be in a predictable form. This - canonical form is defined as the form which has the fewest possible - Bit-String Labels and in which all except possibly the first (least - significant) label in any sequence of consecutive Bit-String Labels - is of maximum length. - - For example, the canonical form of any sequence of up to 256 One-Bit - Labels has a single Bit-String Label, and the canonical form of a - sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of - which the second and third contain 256 label bits. - - - -Expires November 10, 1999 Crawford [Page 4] - -Internet Draft Binary DNS Labels May 5, 1999 - - - The canonical sort order of domain names [DNSSEC] is extended to - encompass binary labels as follows. Sorting is still label-by- - label, from most to least significant, where a label may now be a - One-Bit Label or a standard (code 00) label. Any One-Bit Label - sorts before any standard label, and a 0 bit sorts before a 1 bit. - The absence of a label sorts before any label, as specified in - [DNSSEC]. - - For example, the following domain names are correctly sorted. - - foo.example - \[b1].foo.example - \[b100].foo.example - \[b101].foo.example - bravo.\[b10].foo.example - alpha.foo.example - - -4. Processing Rules - - A One-Bit Label never matches any other kind of label. In - particular, the DNS labels represented by the single ASCII - characters "0" and "1" do not match One-Bit Labels represented by - the bit values 0 and 1. - - -5. Discussion - - A Count of zero in the wire-form represents a 256-bit sequence, not - to optimize that particular case, but to make it completely - impossible to have a zero-bit label. - - -6. IANA Considerations - - This document defines one Extended Label Type, termed the Bit-String - Label, and requests registration of the code point 000001 binary in - the space defined by [EDNS0]. - - -7. Security Considerations - - All security considerations which apply to traditional ASCII DNS - labels apply equally to binary labels. he canonicalization and - sorting rules of section 3.3 allow these to be addressed by DNS - Security [DNSSEC]. - - - - - -Expires November 10, 1999 Crawford [Page 5] - -Internet Draft Binary DNS Labels May 5, 1999 - - -8. References - - [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234. - - [DNSIS] P.V. Mockapetris, "Domain names - implementation and - specification", RFC 1035. - - [DNSSEC]D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security - Extensions", RFC 2065. - - [EDNS0] P. Vixie, "Extension mechanisms for DNS (EDNS0)", Currently - draft-dnsind-edns0-01.txt. - - [KWORD] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119. - - -9. Author's Address - - Matt Crawford - Fermilab MS 368 - PO Box 500 - Batavia, IL 60510 - USA - - Phone: +1 630 840-3461 - - EMail: crawdad@fnal.gov - - - - - - - - - - - - - - - - - - - - - - -Expires November 10, 1999 Crawford [Page 6] - diff --git a/doc/expired/draft-ietf-dnsind-dddd-01.txt b/doc/expired/draft-ietf-dnsind-dddd-01.txt deleted file mode 100644 index 0d3b429c54..0000000000 --- a/doc/expired/draft-ietf-dnsind-dddd-01.txt +++ /dev/null @@ -1,334 +0,0 @@ - -DNSIND Working Group Brian Wellington (TISLabs) -INTERNET-DRAFT Olafur Gudmundsson (TISLabs) - April 1999 - - - -Updates: RFC 2136 - - - - Deferred Dynamic Domain Name System (DNS) Delete Operations - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Abstract - - This document proposes a mechanism for notifying a dynamic DNS server - that a delete operation should be performed at a certain point in the - future. This works within the framework of the current DNS dynamic - update protocol, and provides needed functionality for clients with - leased dynamic addresses. - - - - - - - - - -Expires October 1999 [Page 1] - -INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 - - -1 - Introduction - -Dynamic update operations for the Domain Name System [RFC1034, RFC1035] -are defined in [RFC2136], but there is no automated method of specifying -that records should have a fixed lifetime, or lease. - -1.1 - Overview of DNS Dynamic Update - -DNS dynamic update defines a new DNS opcode and a new interpretation of -the DNS message if that opcode is used. An update can specify -insertions or deletions of data, along with prerequisites necessary for -the updates to occur. All tests and changes for a DNS update request -are restricted to a single zone, and are performed at the primary server -for the zone. The primary server for a dynamic zone must increment the -zone SOA serial number when an update occurs or before the next -retrieval of the SOA. - -1.2 - Overview of DHCP leases - -DHCP [RFC2131] provides a means for a host to obtain a network address -from a DHCP server. The server may ``lease'' this address to the host, -meaning that it is valid only for the period of time specified in the -lease. The host may may extend its lease with subsequent requests, or -may issue a message to release the address back to the server when it is -no longer needed. - -2 - Background - -When a host receives dynamic addresses with associated dynamic DNS -records, the records can be updated by either the host or the DHCP -server. In many cases, update by the server is recommended, since the -server maintains lease information for each address. In some cases, -though, the server cannot update some or all of the DNS records. This -happens when the DNS and DHCP server are under different administration, -for example. - -A host can easily update its own DNS records when receiving information -from the DHCP server. It can also delete its records when shutting -down. If the host unexpectedly goes down, though, it cannot delete the -records. When the DHCP lease on the address expires and is not renewed, -the DHCP server may reassign the address. The DNS records now point to -an assigned address, but not the correct address. Until the host -updates its records again, DNS will contain bad information. - -Since the DHCP and DNS servers are often not co-located with the -clients, the possibility of a host unexpectedly going down and not -communicating with the servers is non-trivial. - - - - -Expires October 1999 [Page 2] - -INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 - - -If the host could set a lease on the DNS records similar to that on its -address, the DNS records would lose validity at the same time as the -address. This would prevent bad information from remaining in DNS. DNS -has no such provision for leases, though, since this would require -storing a lease time along with each record (or each record in a dynamic -zone). - -An alternative method is suggested. A ``delete'' update is sent along -with the ``add'' update, but the delete is marked in such a way that it -will not be exectuted immediately. Instead, it will be stored for the -specified amount of time before being applied. If the host wishes to -extend or shorten the lifetime of the DNS record(s), it can replace the -``deferred delete'' record, which will reset the lease time of the -record(s). The ``deferred delete'' record would, of course, also be -removed if a normal delete update was received. - -3 - Protocol changes - -When doing a delete update operation as defined in [RFC2136] (deleting -an RR, an RRset, or all RRset from a name), the TTL field MUST be -specified as 0. An [RFC2136] compliant server will silently ignore (*) -an update record with a non-zero TTL. This document overloads the TTL -field. If TTL is non-zero, the value represents the number of seconds -(a 32 bit unsigned integer) before which the delete will be applied to -the zone. Thus, the delete operation will be deferred for that number -of seconds, where the number of seconds indicates the lease time. A 32 -bit integer provides for a lease time of over 136 years, which should be -long enough for most uses. - -3.1 - Storage and execution - -Deferred delete records are stored, persistently, by the name server. -The name server SHOULD attempt to evaluate the deletes in a timely -manner. If multiple deferred deletes are sent in the same DNS message -with the same TTL value, they MUST be processed atomically if processed -as planned (that is, none of the deferred deletes are updated or -cancelled). - -3.2 - Processing of deferred deletes - -When a deferred delete is received, the server must check to see if it -matches an existing deferred delete records, where matching indicates -the same name, type, class, and rdata. If a match is found, the new -deferred delete MUST replace the old one. If the deferred delete does -not refer to any record in the server, it should fail as a normal delete -would. - - - - - -Expires October 1999 [Page 3] - -INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 - - -3.3 - Processing of normal deletes - -When a normal delete is received and accepted, the server SHOULD purge -any matching deferred delete records. - -3.4 - Processing of cancellations - -The value 0xFFFFFFFF (the largest unsigned 32 bit integer) in the TTL -field has a special meaning. If a delete containing this lease time is -received, the server will unconditionally remove any matching deferred -deletes. If no deferred delete matches, this request will be silently -ignored. - -3.5 - Processing of adds - -When data is added through a dynamic update which matches a deferred -delete, there is no additional processing done. - -4 - TTL handling - -Any record that may be deleted SHOULD have a short TTL compared to its -lease time, to prevent deleted data from being cached past its -expiration. - -When the time until an RR is deleted becomes low enough, the server MAY -modify the TTL of the RRset. Whenever the TTL is automatically reduced -by this process, the zone will be considered ``changed'' for the purpose -of automatic SOA SERIAL increment (as in [RFC2136]) and real time zone -slave notification [RFC1996]. As these operations can potentially be -expensive (more so if DNSSEC [RFC2535] signatures must be regenerated), -the specific limits and effects are left to the implementation. - -If the TTL is modified by the server, it is not reset if the lease is -renewed. Therefore, the original RR SHOULD be sent with the lease -renewal if the client expects that the server has modified the TTL. - - - - - - - - - - - - - - - - -Expires October 1999 [Page 4] - -INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 - - -5 - Usage - -Normally, a deferred delete update will initially be sent along with an -add, although this is not required. Further updates to the deferred -delete may be sent independently, although the add should be sent again. -If the deferred delete is associated with a leased address, the lease -time of the update SHOULD be approximately equal to the lease time of -the address. - -6 - Protocol robustness - -This protocol has no inherent protection against replayed messages, -which can either originate from an attack or faulty hardware. To -prevent this problem, prerequisites should be used in the update -message, such as a test for the existence of a TXT record describing the -lease, which would be added along with the other records (see [RFC2136], -section 5). - -7 - Security considerations - -This addition to the dynamic DNS protocol does not affect the security -of the protocol. If security is desired, TSIG [TSIG] and/or DNSSEC -[RFC2535] authentication should be used, as specified in [simple-update] -or [RFC2137, update2]. The authors strongly recommend using security -along with this protocol. - -If a DNSSEC signed-zone is modified with deferred deletes, the server -must resign any affected records when the delete is executed. No -special processing is required when the delete is received. - -8 - IANA Considerations - -None. - -9 - References - -[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' - RFC 1034, ISI, November 1987. - -[RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification,'' RFC 1035, ISI, November 1987. - -[RFC1996] P. Vixie ``A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY),'' RFC 1996, ISC, August 1996. - -[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic - Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore - & Cisco & DEC, April 1997. - - - -Expires October 1999 [Page 5] - -INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 - - -[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC - 2137, CyberCash, April 1997. - -[RFC2535] D. Eastlake ``Domain Name System Security Extensions,'' RFC - 2535, IBM, March 1999. - -[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington - ``Secret Key Transaction Signatures for DNS (TSIG),'' draft- - ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs, - February 1999. - -[simple-update] - B. Wellington ``Simple Secure Domain Name System (DNS) - Dynamic Update,'' draft-ietf-dnssec-simple-update-00.txt, - TISLabs, November 1998. - -[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic - Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite - Systems Company, August 1998. - -8 - Author's Address - - - Brian Wellington Olafur Gudmundsson - TISLabs at Network Associates TISLabs at Network Associates - 3060 Washington Road, Route 97 3060 Washington Road, Route 97 - Glenwood, MD 21738 Glenwood, MD 21738 - +1 443 259 2369 +1 443 259 2389 - - - - - - - - - - - - - - - - - - - - - - - -Expires October 1999 [Page 6] - diff --git a/doc/expired/draft-ietf-dnsind-dhcp-rr-00.txt b/doc/expired/draft-ietf-dnsind-dhcp-rr-00.txt deleted file mode 100644 index 6d729e2938..0000000000 --- a/doc/expired/draft-ietf-dnsind-dhcp-rr-00.txt +++ /dev/null @@ -1,167 +0,0 @@ -INTERNET-DRAFT Andreas Gustafsson -draft-ietf-dnsind-dhcp-rr-00.txt Internet Engines, Inc. - October 1999 - - A DNS RR for encoding DHCP information - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet- Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Abstract - - This document describes a DNS RR for use by DHCP servers that need to - store state information in the DNS. - -Introduction - - A set of procedures to allow DHCP servers [RFC2131] to automatically - update the DNS [RFC1034, RFC1035] is proposed in [DHCPDNS]. - - A situation can arise where multiple DHCP clients request the same - DNS name from their (possibly distinct) DHCP servers. To resolve - such conflicts, [DHCPDNS] proposes storing client identifiers in the - DNS to unambiguously associate domain names with the DHCP clients - "owning" them. Early versions of [DHCPDNS] proposed using TXT - records for encoding this information; the current version specifies - the use of KEY records. - - In the interest of clarity, it would be preferable for this DHCP - -Expires April 2000 [Page 1] - -draft-ietf-dnsind-dhcp-rr-00.txt October 1999 - - information to use a distinct RR type rather than the existing KEY - type. A separate RR type can also improve efficiency by avoiding the - unnecessary transmission of unrelated KEY records. - - This memo defines a distinct RR type for use by DHCP servers, the - "DHCP" RR. - -The DHCP RR - - The DHCP RR is defined with mnemonic DHCP and type code . - -DHCP RDATA format - - The RDATA section of a DHCP RR in transmission contains RDLENGTH - bytes of binary data. The format of this data and its interpretation - by DHCP servers and clients, including the interpretation of multiple - DHCP RRs at the same domain name, are TBD. [This part of the - specification should be driven by the needs of, and written in - cooperation with, the DHCP Working Group and the authors of - [DHCPDNS]]. - - DNS software should consider the RDATA section to be opaque. In DNS - master files, the RDATA is represented as a hexadecimal string with - an optional "0x" or "0X" prefix. Periods (".") may be inserted - anywhere after the "0x" for readability. This format is identical to - that of the NSAP RR [RFC1706]. The number of hexadecimal digits MUST - be even. - -Example - - A DHCP server allocating the IPv4 address 10.0.0.1 to a client - "client.org.nil" might associate eight bytes of housekeeping - information with the client as follows: - - client.org.nil. A 10.0.0.1 - client.org.nil. DHCP 01.23.45.67.89.ab.cd.ef - -Security Considerations - - The DHCP record as such does not introduce any new security problems - into the DNS. However, care should be taken not to store sensitive - information in DHCP records, since they are published along with - other DNS data. Note that even the hardware addresses of DHCP - clients may be considered sensitive information. - -IANA Considerations - - The IANA is requested to allocate an RR type number for the DHCP - -Expires April 2000 [Page 2] - -draft-ietf-dnsind-dhcp-rr-00.txt October 1999 - - record type from the regular RR type number range. - -References - - [RFC1035] - Domain Names - Implementation and Specifications, P. - Mockapetris, November 1987. - - [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, - November 1987. - - [RFC1706] - DNS NSAP Resource Records, B. Manning, R. Colella, - October 1994. - - [RFC2131] - Dynamic Host Configuration Protocol, R. Droms, March - 1997. - - [DHCPDNS] - draft-ietf-dhc-dhcp-dns-*.txt - -Author's Address - - Andreas Gustafsson - Internet Engines, Inc. - 950 Charter Street - Redwood City, CA 94063 - USA - - Phone: +1 650 779 6004 - - Email: gson@iengines.net - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - -Expires April 2000 [Page 3] - -draft-ietf-dnsind-dhcp-rr-00.txt October 1999 - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." - -Expires April 2000 [Page 4] diff --git a/doc/expired/draft-ietf-dnsind-dname-03.txt b/doc/expired/draft-ietf-dnsind-dname-03.txt deleted file mode 100644 index f28cd1b3ea..0000000000 --- a/doc/expired/draft-ietf-dnsind-dname-03.txt +++ /dev/null @@ -1,502 +0,0 @@ - -DNSIND Working Group Matt Crawford -Internet Draft Fermilab - March 21, 1999 - - Non-Terminal DNS Name Redirection - - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet- Drafts as - reference material or to cite them other than as "work in progress." - - To view the list Internet-Draft Shadow Directories, see - http://www.ietf.org/shadow.html. - - -1. Introduction - - This document defines a new DNS Resource Record called ``DNAME'', - which provides the capability to map an entire subtree of the DNS - name space to another domain. It differs from the CNAME record - which maps a single node of the name space. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [KWORD]. - - -2. Motivation - - This Resource Record and its processing rules were conceived as a - solution to the problem of maintaining address-to-name mappings in a - context of network renumbering. Without the DNAME mechanism, an - authoritative DNS server for the address-to-name mappings of some - network must be reconfigured when that network is renumbered. With - DNAME, the zone can be constructed so that it needs no modification - when renumbered. DNAME can also be useful in other situations, such - as when an organizational unit is renamed. - - - -Expires September 26, 1999 Crawford [Page 1] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - -3. The DNAME Resource Record - - The DNAME RR has mnemonic DNAME and type code 39 (decimal). - - DNAME has the following format: - - DNAME - - The format is not class-sensitive. All fields are required. The - RDATA field is a [DNSIS]. - - The DNAME RR causes type NS additional section processing. - - The effect of the DNAME record is the substitution of the record's - for its as a suffix of a domain name. A "no- - descendants" limitation governs the use of DNAMEs in a zone file: - - If a DNAME RR is present at a node N, there may be other data at - N (except a CNAME or another DNAME), but there MUST be no data - at any descendant of N. This restriction applies only to - records of the same class as the DNAME record. - - This rule assures predictable results when a DNAME record is cached - by a server which is not authoritative for the record's zone. It - MUST be enforced when authoritative zone data is loaded. Together - with the rules for DNS zone authority [DNSCLR] it implies that DNAME - and NS records can only coexist at the top of a zone which has only - one node. - - The compression scheme of [DNSIS] MUST NOT be applied to the RDATA - portion of a DNAME record unless the sending server has some way of - knowing that the receiver understands the DNAME record format. - Signalling such understanding is expected to be the subject of - future DNS Extensions. - - Naming loops can be created with DNAME records or a combination of - DNAME and CNAME records, just as they can with CNAME records alone. - Resolvers, including resolvers embedded in DNS servers, MUST limit - the resources they devote to any query. Implementors should note, - however, that fairly lengthy chains of DNAME records may be valid. - - -4. Query Processing - - To exploit the DNAME mechanism the name resolution algorithms - [DNSCF] must be modified slightly for both servers and resolvers. - - Both modified algorithms incorporate the operation of making a - - - -Expires September 26, 1999 Crawford [Page 2] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - - substitution on a name (either QNAME or SNAME) under control of a - DNAME record. This operation will be referred to as "the DNAME - substitution". - - -4.1. Processing by Servers - - For a server performing non-recursive service steps 3.c and 4 of - section 4.3.2 [DNSCF] are changed to check for a DNAME record before - checking for a wildcard ("*") label, and to return certain DNAME - records from zone data and the cache. - - DNS clients sending Extended DNS [EDNS0] queries with Version 0 or - non-extended queries are presumed not to understand the semantics of - the DNAME record, so a server which implements this specification, - when answering a non-extended query, SHOULD synthesize a CNAME - record for each DNAME record encountered during query processing to - help the client reach the correct DNS data. The behavior of clients - and servers under Extended DNS versions greater than 0 will be - specified when those versions are defined. - - The synthesized CNAME RR, if provided, MUST have - - The same CLASS as the QCLASS of the query, - - TTL equal to zero, - - An equal to the QNAME in effect at the moment the DNAME - RR was encountered, and - - An RDATA field containing the new QNAME formed by the action of - the DNAME substitution. - - If the server has the appropriate key on-line [DNSSEC, SECDYN], it - MAY generate and return a SIG RR for the synthesized CNAME RR. - - The revised server algorithm is: - - 1. Set or clear the value of recursion available in the response - depending on whether the name server is willing to provide - recursive service. If recursive service is available and - requested via the RD bit in the query, go to step 5, otherwise - step 2. - - 2. Search the available zones for the zone which is the nearest - ancestor to QNAME. If such a zone is found, go to step 3, - otherwise step 4. - - - - -Expires September 26, 1999 Crawford [Page 3] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - - 3. Start matching down, label by label, in the zone. The matching - process can terminate several ways: - - a. If the whole of QNAME is matched, we have found the node. - - If the data at the node is a CNAME, and QTYPE doesn't match - CNAME, copy the CNAME RR into the answer section of the - response, change QNAME to the canonical name in the CNAME - RR, and go back to step 1. - - Otherwise, copy all RRs which match QTYPE into the answer - section and go to step 6. - - b. If a match would take us out of the authoritative data, we - have a referral. This happens when we encounter a node with - NS RRs marking cuts along the bottom of a zone. - - Copy the NS RRs for the subzone into the authority section - of the reply. Put whatever addresses are available into the - additional section, using glue RRs if the addresses are not - available from authoritative data or the cache. Go to step - 4. - - c. If at some label, a match is impossible (i.e., the - corresponding label does not exist), look to see whether the - last label matched has a DNAME record. - - If a DNAME record exists at that point, copy that record - into the answer section. If substitution of its - for its in QNAME would overflow the legal size for a - , set RCODE to YXDOMAIN [DNSUPD] and exit; - otherwise perform the substitution and continue. If the - query was not extended [EDNS0] with a Version indicating - understanding of the DNAME record, the server SHOULD - synthesize a CNAME record as described above and include it - in the answer section. Go back to step 1. - - If there was no DNAME record, look to see if the "*" label - exists. - - If the "*" label does not exist, check whether the name we - are looking for is the original QNAME in the query or a name - we have followed due to a CNAME. If the name is original, - set an authoritative name error in the response and exit. - Otherwise just exit. - - If the "*" label does exist, match RRs at that node against - QTYPE. If any match, copy them into the answer section, but - - - -Expires September 26, 1999 Crawford [Page 4] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - - set the owner of the RR to be QNAME, and not the node with - the "*" label. Go to step 6. - - 4. Start matching down in the cache. If QNAME is found in the - cache, copy all RRs attached to it that match QTYPE into the - answer section. If QNAME is not found in the cache but a DNAME - record is present at an ancestor of QNAME, copy that DNAME - record into the answer section. If there was no delegation from - authoritative data, look for the best one from the cache, and - put it in the authority section. Go to step 6. - - 5. Use the local resolver or a copy of its algorithm (see resolver - section of this memo) to answer the query. Store the results, - including any intermediate CNAMEs and DNAMEs, in the answer - section of the response. - - 6. Using local data only, attempt to add other RRs which may be - useful to the additional section of the query. Exit. - - Note that there will be at most one ancestor with a DNAME as - described in step 4 unless some zone's data is in violation of the - no-descendants limitation in section 3. An implementation might - take advantage of this limitation by stopping the search of step 3c - or step 4 when a DNAME record is encountered. - - -4.2. Processing by Resolvers - - A resolver or a server providing recursive service must be modified - to treat a DNAME as somewhat analogous to a CNAME. The resolver - algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d - as 4.e and insert a new 4.d. The complete algorithm becomes: - - 1. See if the answer is in local information, and if so return it - to the client. - - 2. Find the best servers to ask. - - 3. Send them queries until one returns a response. - - 4. Analyze the response, either: - - a. if the response answers the question or contains a name - error, cache the data as well as returning it back to the - client. - - b. if the response contains a better delegation to other - servers, cache the delegation information, and go to step 2. - - - -Expires September 26, 1999 Crawford [Page 5] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - - c. if the response shows a CNAME and that is not the answer - itself, cache the CNAME, change the SNAME to the canonical - name in the CNAME RR and go to step 1. - - d. if the response shows a DNAME and that is not the answer - itself, cache the DNAME. If substitution of the DNAME's - for its in the SNAME would overflow the - legal size for a , return an implementation- - dependent error to the application; otherwise perform the - substitution and go to step 1. - - e. if the response shows a server failure or other bizarre - contents, delete the server from the SLIST and go back to - step 3. - - A resolver or recursive server which understands DNAME records but - sends non-extended queries MUST augment step 4.c by deleting from - the reply any CNAME records which have an which is a - subdomain of the of any DNAME record in the response. - - -5. Examples of Use - -5.1. Organizational Renaming - - If an organization with domain name FROBOZZ.EXAMPLE became part of - an organization with domain name ACME.EXAMPLE, it might ease - transition by placing information such as this in its old zone. - - frobozz.example. DNAME frobozz-division.acme.example. - MX 10 mailhub.acme.example. - - The response to an extended recursive query for www.frobozz.example - would contain, in the answer section, the DNAME record shown above - and the relevant RRs for www.frobozz-division.acme.example. - - -5.2. Classless Delegation of Shorter Prefixes - - The classless scheme for in-addr.arpa delegation [INADDR] can be - extended to prefixes shorter than 24 bits by use of the DNAME - record. For example, the prefix 192.0.8.0/22 can be delegated by - the following records. - - - - - - - - -Expires September 26, 1999 Crawford [Page 6] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - - - $ORIGIN 0.192.in-addr.arpa. - 8/22 NS ns.slash-22-holder.example. - 8 DNAME 8.8/22 - 9 DNAME 9.8/22 - 10 DNAME 10.8/22 - 11 DNAME 11.8/22 - - A typical entry in the resulting reverse zone for some host with - address 192.0.9.33 might be - - $ORIGIN 8/22.0.192.in-addr.arpa. - 33.9 PTR somehost.slash-22-holder.example. - - - The same advisory remarks concerning the choice of the "/" character - apply here as in [INADDR]. - - -5.3. Network Renumbering Support - - If IPv4 network renumbering were common, maintenance of address - space delegation could be simplified by using DNAME records instead - of NS records to delegate. - - $ORIGIN new-style.in-addr.arpa. - 189.190 DNAME in-addr.example.net. - - $ORIGIN in-addr.example.net. - 188 DNAME in-addr.customer.example. - - $ORIGIN in-addr.customer.example. - 1 PTR www.customer.example. - 2 PTR mailhub.customer.example. - ; etc ... - - This would allow the address space 190.189.0.0/16 assigned to the - ISP "example.net" to be changed without the necessity of altering - the zone files describing the use of that space by the ISP and its - customers. - - Renumbering IPv4 networks is currently so arduous a task that - updating the DNS is only a small part of the labor, so this scheme - may have a low value. But it is hoped that in IPv6 the renumbering - task will be quite different and the DNAME mechanism may play a - useful part. - - - - - -Expires September 26, 1999 Crawford [Page 7] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - -6. IANA Considerations - - This document defines a new DNS Resource Record type with the - mnemonic DNAME and type code 39 (decimal). The naming/numbering - space is defined in [DNSIS]. This name and number have already been - registered with the IANA. - - -7. Security Considerations - - The DNAME record is similar to the CNAME record with regard to the - consequences of insertion of a spoofed record into a DNS server or - resolver, differing in that the DNAME's effect covers a whole - subtree of the name space. The facilities of [DNSSEC] are available - to authenticate this record type. - - -8. References - - [DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities", - RFC 1034. - - [DNSCLR] R. Elz, R. Bush, "Clarifications to the DNS Specification", - RFC 2181. - - [DNSIS] P.V. Mockapetris, "Domain names - implementation and - specification", RFC 1035. - - [DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security - Extensions", RFC 2065. - - [DNSUPD] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic - Updates in the Domain Name System", RFC 2136. - - [EDNS0] P. Vixie, "Extensions mechanisms for DNS (EDNS0)", Currently - draft-dnsind-edns0-01.txt. - - [INADDR] H. Eidnes, G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA - delegation", RFC 2317. - - [KWORD] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119. - - [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic - Update", RFC 2137. - - - - - - -Expires September 26, 1999 Crawford [Page 8] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - -9. Author's Address - - Matt Crawford - Fermilab MS 368 - PO Box 500 - Batavia, IL 60510 - USA - - Phone: +1 630 840-3461 - - EMail: crawdad@fnal.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires September 26, 1999 Crawford [Page 9] - diff --git a/doc/expired/draft-ietf-dnsind-edns0-01.txt b/doc/expired/draft-ietf-dnsind-edns0-01.txt deleted file mode 100644 index 8aefeaf902..0000000000 --- a/doc/expired/draft-ietf-dnsind-edns0-01.txt +++ /dev/null @@ -1,319 +0,0 @@ - - - - - DNSIND Working Group Paul Vixie - INTERNET-DRAFT ISC - January, 1999 - - - Extension mechanisms for DNS (EDNS0) - - - Status of this Memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - - - Abstract - - The Domain Name System's wire protocol includes a number of fixed - fields whose range has been or soon will be exhausted and does not - allow clients to advertise their capabilities to servers. This - document describes backward compatible mechanisms for allowing the - protocol to grow. - - 1 - Rationale and Scope - - 1.1. DNS (see [RFC1035]) specifies a Message Format and within such - messages there are standard formats for encoding options, errors, and - name compression. The maximum allowable size of a DNS Message is fixed. - Many of DNS's protocol limits are too small for uses which are or which - are desired to become common. There is no way for implementations to - advertise their capabilities. - - - - - - Expires July 1999 [Page 1] - - INTERNET-DRAFT EDNS0 January 1999 - - - 1.2. Existing clients will not know how to interpret the protocol - extensions detailed here. In practice, these clients will be upgraded - when they have need of a new feature, and only new features will make - use of the extensions. We must however take account of client behaviour - in the face of extra fields, and design a fallback scheme for - interoperability with these clients. - - 2 - Affected Protocol Elements - - 2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit - word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of - 1-bit flags. The original reserved Z bits have been allocated to - various purposes, and most of the RCODE values are now in use. More - flags and more possible RCODEs are needed. - - 2.2. The first two bits of a wire format domain label are used to denote - the type of the label. [RFC1035 4.1.4] allocates two of the four - possible types and reserves the other two. Proposals for use of the - remaining types far outnumber those available. More label types are - needed. - - 2.3. DNS Messages are limited to 512 octets in size when sent over UDP. - While the minimum maximum reassembly buffer size still allows a limit of - 512 octets of UDP payload, most of the hosts now connected to the - Internet are able to reassemble larger datagrams. Some mechanism must - be created to allow requestors to advertise larger buffer sizes to - responders. - - 3 - Extended Label Types - - 3.1. The ``0 1'' label type will now indicate an extended label type, - whose value is encoded in the lower six bits of the first octet of a - label. All subsequently developed label types should be encoded using - an extended label type. - - 3.2. The ``1 1 1 1 1 1'' extended label type will be reserved for future - expansion of the extended label type code space. - - 4 - OPT pseudo-RR - - 4.1. The OPT pseudo-RR can be added to the additional data section of - either a request or a response. An OPT is called a pseudo-RR because it - pertains to a particular transport level message and not to any actual - DNS data. OPT RRs shall never be cached, forwarded, or stored in or - loaded from master files. - - - - Expires July 1999 [Page 2] - - INTERNET-DRAFT EDNS0 January 1999 - - - 4.2. An OPT RR has a fixed part and a variable set of options expressed - as {attribute, value} pairs. The fixed part holds some DNS meta data - and also a small collection of new protocol elements which we expect to - be so popular that it would be a waste of wire space to encode them as - {attribute, value} pairs. - - 4.3. The fixed part of an OPT RR is structured as follows: - - Field Name Field Type Description - ------------------------------------------------------ - NAME domain name empty (root domain) - TYPE u_int16_t OPT - CLASS u_int16_t sender's UDP payload size - TTL u_int32_t extended RCODE and flags - RDLEN u_int16_t describes RDATA - RDATA octet stream {attribute,value} pairs - - - 4.4. The variable part of an OPT RR is encoded in its RDATA and is - structured as zero or more of the following: - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | OPTION-CODE | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | OPTION-LENGTH | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 4: | | - / OPTION-DATA / - / / - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - OPTION-CODE (Assigned by IANA.) - - OPTION-LENGTH Size (in octets) of OPTION-DATA. - - OPTION-DATA Varies per OPTION-CODE. - - 4.5. The sender's UDP buffer size (which OPT stores in the RR CLASS - field) is the number of octets of the largest UDP payload that can be - reassembled and delivered in the sender's network stack. Note that path - MTU, with or without fragmentation, may be smaller than this. - - - - - - Expires July 1999 [Page 3] - - INTERNET-DRAFT EDNS0 January 1999 - - - 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP - reassembly buffer. Choosing 1280 on an Ethernet connected requestor - would be reasonable. The consequence of choosing too large a value may - be an ICMP message from an intermediate gateway, or even a silent drop - of the response message. Requestors are advised to retry in such cases. - - 4.5.2. Both requestors and responders are advised to take account of the - path's already discovered MTU (if known) when considering message sizes. - - 4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) - are structured as follows: - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | EXTENDED-RCODE | VERSION | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | Z | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that - EXTENDED-RCODE value "0" indicates that an unextended - RCODE is in use (values "0" through "15"). - - VERSION Indicates the implementation level of whoever sets it. - Full conformance with this specification is indicated by - version ``0.'' Note that both requestors and responders - should set this to the highest level they implement, - that responders should send back RCODE=BADVERS and that - requestors should be prepared to probe using lower - version numbers if they receive an RCODE=BADVERS. - - Z Set to zero by senders and ignored by receivers, unless - modified in a subsequent specification. - - 5 - Transport Considerations - - 5.1. The presence of an OPT pseudo-RR in a request should be taken as an - indication that the requestor fully implements the given version of - EDNS, and can correctly understand any response that conforms to that - feature's specification. - - 5.2. Lack of use of these features in a request must be taken as an - indication that the requestor does not implement any part of this - specification and that the responder may make no use of any protocol - - - - Expires July 1999 [Page 4] - - INTERNET-DRAFT EDNS0 January 1999 - - - extension described here in its response. - - 5.3. Responders who do not understand these protocol extensions are - expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL. - Therefore use of extensions should be ``probed'' such that a responder - who isn't known to support them be allowed a retry with no extensions if - it responds with such an RCODE. If a responder's capability level is - cached by a requestor, a new probe should be sent periodically to test - for changes to responder capability. - - 6 - Security Considerations - - Requestor-side specification of the maximum buffer size may open a new - DNS denial of service attack if responders can be made to send messages - which are too large for intermediate gateways to forward, thus leading - to potential ICMP storms between gateways and responders. - - 7 - IANA Considerations - - IANA is hereby requested to assign an RR type code for OPT. - - It is the recommendation of this document and its working group that - IANA create a registry for EDNS Extended Label Types, for EDNS Option - Codes, and for EDNS Version Numbers. - - This document assigns label type 0b01xxxxxx as "EDNS Extended Label - Type." We request that IANA record this assignment. - - This document assigns extended label type 0bxx111111 as "Reserved for - future extended label types." We request that IANA record this - assignment. - - This document assigns option code 65535 to "Reserved for future - expansion." - - This document expands the RCODE space from 4 bits to 12 bits. This will - allow IANA to assign more than the 16 distinct RCODE values allowed in - [RFC1035]. - - This document assigns EDNS Extended RCODE "16" to "BADVERS". - - IESG approval should be required to create new entries in the EDNS - Extended Label Type or EDNS Version Number registries, while any - published RFC (including Informational, Experimental, or BCP) should be - grounds for allocation of an EDNS Option Code. - - - - Expires July 1999 [Page 5] - - INTERNET-DRAFT EDNS0 January 1999 - - - 8 - Acknowledgements - - Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, - Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas - Narten were each instrumental in creating and refining this - specification. - - 9 - References - - [RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification,'' RFC 1035, USC/Information Sciences - Institute, November 1987. - - 10 - Author's Address - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - +1 650 779 7001 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Expires July 1999 [Page 6] - diff --git a/doc/expired/draft-ietf-dnsind-edns1-03.txt b/doc/expired/draft-ietf-dnsind-edns1-03.txt deleted file mode 100644 index b300eed20c..0000000000 --- a/doc/expired/draft-ietf-dnsind-edns1-03.txt +++ /dev/null @@ -1,249 +0,0 @@ - DNSIND Working Group Paul Vixie - INTERNET-DRAFT ISC - June, 1999 - - Extensions to DNS (EDNS1) - - Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - Abstract - - This document specifies a number of extensions within the Extended - DNS framework defined by [EDNS0], including several new extended - label types and the ability to ask multiple questions in a single - request. - - 1 - Rationale and Scope - - 1.1. EDNS (see [EDNS0]) specifies an extension mechanism to DNS (see - [RFC1035]) which provides for larger message sizes, additional label - types, and new message flags. - - 1.2. This document makes use of the EDNS extension mechanisms to add - several new extended label types and message options, and the ability to - ask multiple questions in a single request. - - Expires December 1999 [Page 1] - - INTERNET-DRAFT EDNS1 June 1999 - - 2 - Affected Protocol Elements - - 2.1. Compression pointers are 14 bits in size and are relative to the - start of the DNS Message, which can be 64KB in length. 14 bits restrict - pointers to the first 16KB of the message, which makes labels introduced - in the last 48KB of the message unreachable by compression pointers. A - longer pointer format is needed. - - 2.2. DNS Messages are limited to 65535 octets in size when sent over - TCP. This acts as an effective maximum on RRset size, since multiple - TCP messages are only possible in the case of zone transfers. Some - mechanism must be created to allow normal DNS responses (other than zone - transfers) to span multiple DNS Messages when TCP is used. - - 2.3. Multiple queries in a question section have not been supported in - DNS due the applicability of some DNS Message Header flags (such as AA) - and of the RCODE field only to a single QNAME, QTYPE, and QCLASS. - Multiple questions per request are desirable, and some way of asking - them must be made available. - - 3 - Extended Label Types - - 3.1. In [EDNS0], the ``0 1'' label type was specified to denote an - extended label type, whose value is encoded in the lower six bits of the - first octet of a label, and an extended label type of ``1 1 1 1 1 1'' - was further reserved for use in future multibyte extended label types. - - 3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended - compression pointer, such that the following two octets comprise a - 16-bit compression pointer in network byte order. Like the normal - compression pointer, this pointer is relative to the start of the DNS - Message. - - 3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit - string label as described in [CRAW98]. - - 3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long - local compression pointer'' as described in [KOCH98]. - - Expires December 1999 [Page 2] - - INTERNET-DRAFT EDNS1 June 1999 - - 4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags - are structured as follows: - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | EXTENDED-RCODE | VERSION | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: |MD |FM |RRD|LM | Z | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As - defined by [EDNS0].) - - VERSION Indicates the implementation level of whoever sets it. - Full conformance with the draft standard version of this - specification is version ``1.'' Note that both - requestors and responders should set this to the highest - level they implement, that responders should send back - RCODE=BADVERS and that requestors should be prepared to - probe using lower version numbers if they receive an - RCODE=BADVERS. - - MD ``More data'' flag. Valid only in TCP streams where - message ordering and reliability are guaranteed. This - flag indicates that the current message is not the - complete request or response, and should be aggregated - with the following message(s) before being considered - complete. Such messages are called ``segmented.'' It - is an error for the RCODE (including the EXTENDED- - RCODE), AA flag, or DNS Message ID to differ among - segments of a segmented message. It is an error for TC - to be set on any message of a segmented message. Any - given RR must fit completely within a message, and all - messages will both begin and end on RR boundaries. Each - section in a multipart message must appear in normal - message order, and each section must be complete before - later sections are added. All segments of a message - must be transmitted contiguously, without interleaving - of other messages. - - FM ``First match'' flag. Notable only when multiple - questions are present. If set in a request, questions - will be processed in wire order and the first question - whose answer would have NOERROR AND ANCOUNT>0 is treated - - Expires December 1999 [Page 3] - - INTERNET-DRAFT EDNS1 June 1999 - - as if it were the only question in the query message. - Otherwise, questions can be processed in any order and - all possible answer records will be included in the - response. Response FM should be ignored by requestors. - - RRD ``Recursion really desired'' flag. Notable only when a - request is processed by an intermediate name server - (``forwarder'') who is not authoritative for the zone - containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If - set in a request, the intermediate name server can only - answer using unexpired cached answers (either positive - or negative) which were atomically acquired using (a) - the same QTYPE or set of QTYPEs present in the current - question and whose TTLs were each minimized to the - smallest among them when first cached, and (b) the same - FM and LM settings present in the current question. - - LM ``Longest match'' flag. If this flag is present in a - query message, then for any question whose QNAME is not - fully matched by zone or cache data, the longest - trailing label-bounded suffix of the QNAME for which - zone or cache data is present will be eligible for use - as an answer. Note that an intervening wildcard name - shall supercede this behaviour and the rules described - in [RFC1034 4.3.2, 4.3.3] shall apply, except that the - owner name of the answer will be the wildcard name - rather than the QNAME. Any of: QTYPE=ANY, or - QCLASS=ANY, or QCOUNT>1, shall be considered an error if - the LM flag is set. - - If LM is set in a request, then LM has meaning in the - response as follows: If the content of the response - would have been different without the LM flag being set - on the request, then the response LM will be set; If the - content of the response was not determined or affected - by the request LM, then the response LM will be cleared. - If the request LM was not set, then the response LM is - not meaningful and should be set to zero by responders - and ignored by requestors. - - Z Set to zero by senders and ignored by receivers, unless - modified in a subsequent specification. - - Expires December 1999 [Page 4] - - INTERNET-DRAFT EDNS1 June 1999 - - 5 - Multiple Questions for QUERY - - 5.1. If QDCOUNT>1, multiple questions are present. All questions must - be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It - is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY. - - 5.2. RCODE and AA apply to all RRs in the answer section having the - QNAME that is shared by all questions in the question section. AA - applies to all matching answers, and will not be set unless the exact - original request was processed by an authoritative server and the - response forwarded in its entirety. - - 5.3. If a multiple question request is processed by an intermediate - server and the authority server does not support multiple questions, the - intermediate server must generate an answer iteratively by making - multiple requests of the authority server. In this case, AA must never - be set in the final answer due to lack of atomicity of the contributing - authoritative responses. - - 5.4. If iteratively processing a multiple question request using an - authority server which can only process single question requests, if any - contributing request generates a SERVFAIL response, then the final - response's RCODE should be SERVFAIL. - - 6 - Acknowledgements - - Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, - Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Michael Patton, - and Michael Graff were each instrumental in creating this specification. - - 7 - References - - [RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification,'' RFC 1035, USC/Information Sciences - Institute, November 1987. - - [EDNS0] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' Draft - draft-ietf-dnsind-edns0-XX, IETF DNSIND, September 1998 - - [CRAW98] M. Crawford, ``Binary Labels in the Domain Name System,'' - Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March - 1998. - - [KOCH98] P. Koch, ``A New Scheme for the Compression of Domain - Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt. - - Expires December 1999 [Page 5] - - INTERNET-DRAFT EDNS1 June 1999 - - IETF DNSIND, March 1998. - - 8 - Author's Address - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - +1 650 779 7001 - - - Expires December 1999 [Page 6] diff --git a/doc/expired/draft-ietf-dnsind-indirect-key-00.txt b/doc/expired/draft-ietf-dnsind-indirect-key-00.txt deleted file mode 100644 index 7857081ee9..0000000000 --- a/doc/expired/draft-ietf-dnsind-indirect-key-00.txt +++ /dev/null @@ -1,470 +0,0 @@ -DNSIND Working Group D. Eastlake -INTERNET-DRAFT IBM -Expires October 1999 - April 1999 -draft-ietf-dnsind-indirect-key-00.txt - - - Indirect KEY RRs in the Domain Name System (DNS) - -------- --- --- -- --- ------ ---- ------ ----- - - Donald E. Eastlake 3rd - - - -Status of This Document - - This draft, file name draft-ietf-dnsind-indirect-key-00.txt, is - intended to be become a Proposed Standard RFC. Distribution of this - document is unlimited. Comments should be sent to the DNSSEC mailing - list or to the author. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - - - -Abstract - - [RFC 2535] defines a means for storing cryptographic public keys in - the Domain Name System. An additional code point is defined for the - algorithm field of the KEY resource record (RR) to indicate that the - key is not stored in the KEY RR but is pointed to by the KEY RR. - Encodings to indicate different types of key and pointer formats are - specified. - - [This draft is moved from the DNSSEC WG as part of that WG's merger - into me DNSIND WG. It would have been draft-ietf-dnssec-indirect- - key-02.txt in the DNSSEC WG.] - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT Indirect KEY RRs - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. The Indirect KEY RR Algorithm...........................3 - 2.1 The Target Type Field..................................4 - 2.2 The Target Algorithm Field.............................5 - 2.3 The Hash Fields........................................5 - 3. Performance Considerations..............................6 - 4. IANA Considerations.....................................6 - 5. Security Considerations.................................6 - References.................................................7 - Author's Address...........................................7 - Expiration and File Name...................................8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT Indirect KEY RRs - - -1. Introduction - - The Domain Name System (DNS) security extensions [RFC 2535] provide - for the general storage of public keys in the domain name system via - the KEY resource record (RR). These KEY RRs are used in support of - DNS security and may be used to support other security protocols. - KEY RRs can be associated with users, zones, and hosts or other end - entities named in the DNS. - - For reasons given below, it will sometimes be desireable to store a - key or keys elsewhere and merely point to it from the KEY RR. - Indirect key storage makes it possible to point to a key service via - a URL, to have a compact pointer to a larger key or set of keys, to - point to a certificate either inside DNS [RFC 2538] or outside the - DNS, and where appropriate, to store a key or key set applicable to - many DNS entries in some place and point to it from those entries. - - However, to simplify DNSSEC implementation, this technique MUST NOT - be used for KEY RRs used in for verification in DNSSEC, i.e., the - value of the "protocol" field of an indirect KEY RR MUST NOT be 3. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", - "RECOMMENDED", and "MAY" in this document are to be interpreted as - described in [RFC 2119]. - - - -2. The Indirect KEY RR Algorithm - - Domain Name System (DNS) KEY Resource Record (RR) [RFC 2535] - algorithm number 252 is defined as the indirect key algorithm. This - algorithm MAY NOT be used for zone keys in support of DNS security. - All KEYs used in DNSSEC validation MUST be stored directly in the - DNS. - - When the algorithm byte of a KEY RR has the value 252, the "public - key" portion of the RR is formated as follows: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | target type | target alg. | hash type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | hash size | hash (variable size) / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ - | / - / pointer (variable size) / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Indirect KEY RRs - - -2.1 The Target Type Field - - Target type specifies the type of the key containing data being - pointed at. - - Target type - ----------- - - 0 - reserved, see section 4 - - 1 - indicates that the pointer is a domain name from which KEY RRs - [RFC 2535] should be retrieved. Name compression in the pointer - field is prohibited. - - 2 - indicates that the pointer is a null terminated character string - which is a URL [RFC 1738]. For exisiting data transfer URL - schemes, such as ftp, http, shttp, etc., the data is the same as - the public key portion of a KEY RR. (New URL schemes may be - defined which return multiple keys.) - - 3 - indicates that the pointer is a domain name from which CERT RRs - [RFC 2538] should be retrieved. Name compression in the pointer - field is prohibited. - - 4 - indicates that the pointer is a null terminated character string - which is a URL [RFC 1738]. For exisiting data transfer URL - schemes, such as ftp, http, shttp, etc., the data is the same as - the entire RDATA portion of a CERT RR [RFC 2538]. (New URL - schemes may be defined which return multiple such data blocks.) - - 5 - indicates that the pointer is a null terminated character string - which is a URL [RFC 1738]. For exisiting data transfer URL - schemes, such as ftp, http, shttp, etc., the data is a PKCS#1 [RFC - 2437] format key. (New URL schemes may be defined which return - multiple keys.) - - 6 through 255 - available for assignment, see section 4. - - 256 through 511 (i.e., 256 + n) - indicate that the pointer is a null - terminated character string which is a URL [RFC 1738]. For - exisiting data transfer URL schemes, such as ftp, http, shttp, - etc., the data is a certificate of the type indicated by a CERT RR - [RFC 2538] certificate type of n. That is, target types 257, 258, - and 259 are PKIX, SPKI, and PGP certificates and target types 509 - and 510 are URL and OID private certificate types. (New URL - schemes may be defined which return multiple such certificates.) - - 512 through 65534 - available for assignment, see section 4. - - 65535 reserved, see section 4. - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Indirect KEY RRs - - -2.2 The Target Algorithm Field - - The algorithm field is as defined in [RFC 2535]. If non-zero, it - specifies the algorithm type of the target key or keys pointed. If - zero, it does not specify what algorithm the target key or keys apply - to. - - - -2.3 The Hash Fields - - If the indirecting KEY RRset [RFC 2181, 2535] is retrieved from an - appropriately secure DNS zone with a resolver implementing DNS - security, then there would be a high level of confidence in the - entire value of the KEY RRset including any direct keys. This may or - may not be true of any indirect key pointed to. If an indirect key - is embodied in a certificate or retrieved via a secure protocol such - as SHTTP, it may also be secure. But an indirecting KEY RR could, - for example, simply have an FTP URL pointing to a binary key stored - elsewhere, the retrieval of which would not be secure. - - The hash option in algorithm 252 KEY RRs provides a means of - extending the security of the indirecting KEY RR to the actual key - material pointed at. By including a hash in a secure indirecting RR, - this secure hash can be checked against the hash of the actual keying - material - - Type Hash Algorithm - ---- -------------- - 0 indicates no hash present - 1 MD5 [RFC 1321] - 2 SHA-1 - 3 RIPEMD - 4-252 available, see section 4 - 253 private, domain name (see below) - 254 private, OID (see below) - 255 reserved - - Codes 253 and 254 indicate that a private, proprietary, local, or - experimental hash algorithm is used. For code 253, the hash field - begins with a wire encoded domain name (with compression prohibited) - that indicates the algorithm to use. For code 254, the hash field - begins with a one byte unsigned OID length followed by a BER encoded - OID which indicates the algorithm to use. - - The hash size field is an unsigned octet count of the hash field size - less the length of any code 253 or 254 prefix. For some hash - algorithms it may be fixed by the algorithm choice but this will not - always be the case. For example, hash size is used to distinguish - between RIPEMD-128 (16 octets) and RIPEMD-160 (20 octets). If the - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Indirect KEY RRs - - - hash algorithm field is 0, the hash size MUST be zero and no hash - octets are present. - - The hash field itself is variable size with its length specified by - the hash size field and any code 253 or 254 prefix. - - - -3. Performance Considerations - - With current public key technology, an indirect key will sometimes be - shorter than the keying material it points at. In addition, there - can be cases where a single indirect KEY RR points to multiple keys - elsewhere. This may improve DNS performance in the retrieval of the - initial KEY RR. However, an additional retrieval step then needs to - be done to get the actually keying material which must be added to - the overall time to get the public key. - - - -4. IANA Considerations - - IETF consensus, standards action, and similar terms in this section - are as define in [RFC 2434]. - - KEY RR algorithm number 252 was already reserved for indirect keys in - RFC 2535. - - An IETF standards action is required to allocate target type codes - hex x0000, x0006 through x00FF, x0200 through x0FFF, and xFFFF. - Codes in the range x1000 through x7FFF can be allocated by an IETF - consensus. Codes x8000 through xFEFF are available on a first come - first serve basis. Codes xFF00 through xFFFE are available for - experimentation or private local use without allocation. Use of - codes in this block may result in conflicts outside such experiment - or locality. - - An IETF consensus is required to allocate an indirect KEY RR hash - algorithm code in the range 4-252 and a standards action is required - to allocate hash algorithm code 255. Codes 253 and 254 should cover - requirements for local, private, or proprietary algorithms. - - - -5. Security Considerations - - The indirecting step of using an indirect KEY RR adds complexity and - additional steps where security could go wrong. If the indirect key - RR was retrieved from a zone that was insecure for the resolver, you - have no security. If the indirect key RR, although secure itself, - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Indirect KEY RRs - - - point to a key which can not be securely retrieved and is not - validateted by a secure hash in the indirect key RR, you have no - security. - - - -References - - RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", - STD 13, November 1987. - - RFC 1035 - P. Mockapetris, "Domain Names - Implementation and - Specifications", STD 13, November 1987. - - RFC 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992. - - RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform - Resource Locators (URL)", December 1994. - - RFC 2119 - "Key words for use in RFCs to Indicate Requirement - Levels", S. Bradner. March 1997. - - RFC 2181 - R. Elz, R. Bush, "Clarifications to the DNS - Specification", July 1997. - - RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", October 1998. - - RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography - Specifications Version 2.0", October 1998. - - RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", - March 1999. - - RFC 2538 - D. Eastlake, O. Gudmundsson, "Storing Certificates in the - Domain Name System (DNS)", March 1999. - - - -Author's Address - - Donald E. Eastlake 3rd - IBM - 65 shindegan Hill Road, RR #1 - Carmel, NY 10512 USA - - Telephone: +1-914-784-7913 (w) - +1-914-276-2668 (h) - FAX: +1-914-784-3833 (w) - EMail: dee3@us.ibm.com - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT Indirect KEY RRs - - -Expiration and File Name - - This draft expires October 1999. - - Its file name is draft-ietf-dnsind-indirect-key-00.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - diff --git a/doc/expired/draft-ietf-dnsind-keyreferral-00.txt b/doc/expired/draft-ietf-dnsind-keyreferral-00.txt deleted file mode 100644 index 7670b4c66e..0000000000 --- a/doc/expired/draft-ietf-dnsind-keyreferral-00.txt +++ /dev/null @@ -1,440 +0,0 @@ - -DNSIND WG Edward Lewis -INTERNET DRAFT TIS Labs -May Update: RFC 2535 Jerry Scharf -Catagory: I-D ISC - April 1, 1999 - - The Zone Key Referral - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - Comments should be sent to the authors or the DNSIND WG mailing list - . - - This draft expires on October 1, 1999 - -Copyright Notice - - Copyright (C) The Internet Society (1999). All rights - reserved. - -Notes on this document - -This section will only appear in the -00.txt edition of this draft. - -This document originated in the DNSSEC working group in June 1998. The -discussion of the issues in this draft were tabled until the publication -of the then current DNSSEC drafts as RFCs. - -The first version of this document lists a third author, John Gilmore. -He is listed as an author because he was one of the initiators of what is -proposed. In this and following versions he is only listed in the -Acknowledgements (as opposed to being an author) as he has not been -involved in the writing/editing of the draft. This has been done to -avoid assigning his name to a document he may not have a chance to read, -this is not intended as a slight on his efforts. - -When commenting on this draft, please be aware that some terms used here -are up for negotiation before progressing - such as "thief" and "road -block" appearing later in the draft. Comments which are left justified -were added during the re-issuing of the draft, they add context that -may have been lost over time. - - Abstract - - A new type of key is defined to address the problems of - performance in large delegeted zones and issues of liability of - registrars with regards to the storing of public keys belonging - to zone cuts. This new key type also brings DNSSEC more in line - with the DNS treatment of zone cuts and speeds recovery in - handling privatekey exposure. - - The new type of key is a referral record that is stored, signed, - at the parent zone's place for the delegation point. A resolver - receiving this record is being informed that there are genuine - public keys at the child's authoritative name servers. The - parent no longer needs to store the child's public keys locally. - -1 Introduction - - There are a number of different reasons for the proposal of this - new key type. Reasons include: - o the performance impact that RFC 2535 has on name servers - o the problem of updating a widely delegated parent zone on demand - o statements in RFC 2181 on authoritative data at delegations - o perceived liability of the operator of a name server or registry - - To address these issues, which are expanded upon below, a new - key type is proposed - a "zone key referral" - to join the user - key, host key, and zone key types defined in RFC 2535. - -1.1 Performance Issues - - A sample zone will be used to illustrate the problem. The - example will part from reality mostly in the length of zone - names, which changes the size of the owner and resource record - data fields. - - # $ORIGIN test. - # @ IN SOA - # IN SIG SOA - # IN KEY <1024 bit zone key> - # IN SIG KEY - # IN SIG KEY - # IN NS ns.test. - # IN SIG NS - # IN NXT my-org.test. NS SOA SIG KEY NXT - # IN SIG NXT - # - # my-org IN KEY <1024 bit zone key> - # IN KEY <1024 bit zone key> - # IN SIG KEY - # IN NS ns1.my-org.test. - # IN NS ns2.my-org.test. - # IN NXT them.test. NS SIG KEY NXT - # IN SIG NXT - # - # them IN KEY 0xC100 3 1 - # IN SIG KEY - # IN NS ns1.them.test. - # IN NS ns2.them.test. - # IN NXT test. NS SIG KEY NXT - # IN SIG NXT - - In this zone file fragment, "my-org" is a delegation point of - interest with two registered public keys. Presumably, one key - is for signatures generated currently and the other is for still - living and valid but older signatures. "them" is another - delegation point, with a NULL key. This signifies that this zone - is unsecured. - - To analyze the performance impact of the storing of keys, the - number of bytes used to represent the RRs in the procotol format - is used. The actual number of bytes stored will likely be - higher, accounting for data structure overhead and alignment. - The actual number of bytes transferred will be lower due to DNS - name compression. - - The number of bytes for my-org's two 1024-bit keys, two NS - records, NXT and the associated signatures is 526. The bytes - needed for them (with the NULL key) is 346. Currently, there - are close to 2 million entries in com., so if we take my-org as - a typical domain, over 1GB on memory will be needed for com. - - The zone keys used in the example are set to 1024 bits. This - number may range from as low as 512 bits upwards to over 3000 - bits. To scale the above numbers to a different key size, - multiply the difference in key sizes by 4 for my-org and by 2 - for them, and adjust the numbers accordingly. - - The increased size of the data held for the zone cuts will have - two impacts at the transport and below layers. Bandwidth beyond - that currently needed will be used to carry the KEY records. - The inclusion of all of the child's keys will also push DNS over - the UDP size limit and start using TCP - which could cause - critical problems for current heavily used name servers, like - the roots. - - Another impact, not illustrated by the example, is the frequency - of updates. If each time a public key for my-org is added or - deleted, the SOA serial number will have to increase, and the - SOA signed again. If an average zone changes its keys(s) once - per month, there will be on average 45 updates per minute in a - zone of 2 million delegations. - -(The multiple algorithms issue is an extension of multiple keys. The -example should be updated to show at least a DSS key as well as an RSA -key.) - -1.2 Security Incident Recovery (w/ respect to keys only) - - Once a zone administrator is alerted that any key's private - counterpart has been discovered (exposed), the first action to - be taken is to stop advertising the public key in DNS. This - doesn't end the availability of the key - it will be residing in - caches - but is the closest action resembling revokation - available in DNS. - - Stopping the advertisement in the zone's name servers is as - quick as altering the master file and restarting the name - server. Having to do this in two places will will only delay - the time until the recovery is complete. - - For example, a registrar of a top level domain has decided to - update its zone only on Mondays and Fridays due to the size of - the zone. A customer/delegatee is the victim of a break in, in - which one of the items taken is the file of private keys used to - sign DNS data. If this occurs on a Tuesday, the thief has until - Friday to use the keys before they disappear from the DNS, even - if the child stops publishing them immediately. - - If the public key set is in the parent zone, and the parent zone - is not able to make the change quickly, the public key cannot be - revoked quickly. If the parent only refers to there being a key - at the child zone, then the child has the agility to change the - keys - even issue a NULL key, which will force all signatures in - the zone to become suspect. - -1.3 DNS Clarifications - - RFC 2181, section 6, clarifies the status of data appearing at a - zone cut. Data at a zone cut is served authoritatively from the - servers listed in the NS set present at the zone cut. The data - is not (necessarily) served authoritatively from the parent. - (The exception is in servers handling both the parent and child - zone.) - - Section 6 also mentions that there are two exceptions created by - DNSSEC, the NXT single record set and the KEY set. This - proposal addresses the exception relating to the KEY set, - limiting its severity (but falling short of removing it - altogether). By limiting the exception, we will be simplifying - DNS. - -1.4 Liability - - Liability is a legal concept, so it is not wise to attempt an - engineering solution to it. However, the perceived liability - incurred in using DNSSEC by registrars may prevent the adoption - of DNSSEC. Hence DNSSEC should be engineered in such a away to - address the concern. - - One source of liability is the notion that by advertising a - public key for a child zone, a parent zone is providing a - service of security. With that comes responsibility. By having - the parent merely indicate that a child has a key (or has no - key), the parent is providing less in the way of security. If - the parent is wrong, the potential loss is less. Instead of - falsely authenticated data, configuration errors will be - apparent to the resolving client. - -2 The Proposal - - The proposal is to introduce a new key type which indicates - whether the delegated zone is running secured or not. Running - secured is either a zone signed with at least one key, an - experimental zone, or a zone with only NULL keys published. - - The Zone Referral Key will resemble the NULL key in syntax. - There will be a flags field, an algorithm field, and a protocol - field, but no public key material. The Referral Key is signed - by the parent zone, as was the public key set in RFC 2065. - There is only one Referral Key RR present. - - The Referral Key flags field will have the following values: - Field Bit(s) Value Meaning - - A/C 0- 1 0b01 indicates a key will be found - 0b11 indicates a key will not be found - 0b?0 error (referral cannot encrypt) - XT 2 0 no extended flags are needed - Z 4- 5 0 must be zero for all keys - NAMTYP 6- 7 0b11 this is a referral to a zone key - Z 8-11 0 must be zero for all keys - SIG 12-15 0 must be zero for a referral key - - The legal values of the flags field are (in summary): - - Hex Value Indicates - 0x4300 The delegation has a key record set - 0xC300 The delegation has no key record - - Other values are not valid for Referral Keys (but may be valid - for other keys). - - The Protocol field must be set to 3, the DNSSEC protocol value. - - The Algorithm field must be 0. - -The algorithm is not important at this point. So long as the searcher -knows to expect a key set at the delegated zone's apex, a secure chain -is possible. One the key set is retrieved and verified, then the -algorithms used in the delegated zone are known. (The issue is that a -zone may be signed in algorithm 1 and not 3, 3 and not 1, both, etc., -and a secure resolver must know this in order to set signature arrival -expectations. - -2.1 Example - - The Referral key for my-org.test. and them.test. would appear as - the following in the zone master file: - - my-org.test. IN KEY 0x4300 3 0 - them.test. IN KEY 0xC300 3 0 - - In the example introduced earlier, the master file would change - to the following. - - # $ORIGIN test. - # @ IN SOA - # IN SIG SOA - # IN KEY <1024 bit zone key> - # IN SIG KEY - # IN SIG KEY - # IN NS ns.test. - # IN SIG NS - # IN NXT my-org.test. NS SOA SIG KEY NXT - # IN SIG NXT - # - # my-org IN KEY 0x4300 3 0 - # IN SIG KEY - # IN NS ns1.my-org.test. - # IN NS ns2.my-org.test. - # IN NXT them.test. NS SIG KEY NXT - # IN SIG NXT - # - # them IN KEY 0xC300 3 1 - # IN SIG KEY - # IN NS ns1.them.test. - # IN NS ns2.them.test. - # IN NXT test. NS SIG KEY NXT - # IN SIG NXT - -3 Analysis - - By removing the public keys from the parent's master file, the - parent is no longer a road block during an emergency removal of - keys. A parent zone is unchanged as a zone changes from NULL - keys to experimental keys to fully signed. The parent is also - not providing a security service, other than to authentically - claim the existence of a KEY record set - akin to the "hints" of - the name servers. - - The change also improves the prospect for performance. The need - for multiple KEY RR's, each one on the order of 100 bytes, is - removed and replaced by a single KEY RR of the order of 25 - bytes. Saving bytes reduces the need to use TCP to avoid - truncated responses. Also, the need for updating the zone drops - - no longer will there be updates for each key change. - - As far as the statements by RFC 2181 conerning authority levels, - the Referral Key is not authortative and would be superseeded by - a verified set of the real zone keys. The only caveat is that - once the verified set of keys expire (assuming the parent has to - learn the keys from another server), the Referal Key must - reappear. This is an example of what has been labelled "mount- - like semantics." - - [No reference for mount-like semantics has yet been found.] - - The last point is important. This requires the "mount-like - semantics" that have been discussed for the BIND name servers. - Once hints are overridden by learned, authorititative and - verified data, the hints are not discarded. Hints in this state - are stored and become visible when the learned data expires. - -4 IANA Considerations - - Other than using a new value in the flags field of the KEY RR, - no new number assignments are needed. The flags field is not - under the control of IANA as of yet. There are no requirements - placed on IANA by this draft. - -5 Security Considerations - - There has been some debate about whether the Referral key should - be treated as a hint - just like the NS records. If so, then - there is no need to sign the Referral Key, and an unsigned - (hence non-authenticated) security record is of little value. - So, is the Referral Key even needed? - - Authentication in DNSSEC is done from the data "back" towards a - trusted point - e.g., "up" to the root. Since the - authentication is done by going repeatedly from child to parent, - why bother having the parent indicate the status of the child? - - The answer is in the scenario in which a resolver somewhere has - obtained data which fails the verification process. Perhaps the - signature is wrong, a key in the chain of trust is unavailable, - the set should have had a signature, but none is found (or vice - versa), or the trail of signed-by names is not acceptable. In - this case, the resolver needs to find the authoritative zone, - its status and its name server set. - - If a zone is being attacked by a masquerader, and parents do not - make any statements about the security of child zones, then an - easy and successfull attack may occur. An attacker only needs - to supply either fake name server records or glue records to - redirect queries. - - While this attack will not be stopped as far as denial of - service, the masquerader can be stopped from being accepted as - an authoritative source if the parent of the zone claims the - child is secure and signs the public keys of the true child and - not the masquerader. - - The masquerader cannot successfully claim that the zone is - unsigned, because it must have a zone key signed by the parent. - NULL or not, the key would not be trusted by the resolver, - assuming the parent has not also been duped. The resolver, - sensing this, should report an error or security incident, and - not accept data. - -6 Acknowledgements - - John Gilmore originally raised the issues that have led to this - document. - -7 Author's addresses - -Edward Lewis Jerry Scharf - -3060 Washinton Rd (Rte 97) -Glenwood, MD 21738 -+1(443)259-2352 - -8 References - -RFC 2181 "Clarifications to the DNS Specification", Elz and Bush -RFC 2535 "Domain Name System Security Extensions", Eastlake - -9 Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." - -This draft expires on October 1, 1999 diff --git a/doc/expired/draft-ietf-dnsind-kitchen-sink-02.txt b/doc/expired/draft-ietf-dnsind-kitchen-sink-02.txt deleted file mode 100644 index 9a35062c52..0000000000 --- a/doc/expired/draft-ietf-dnsind-kitchen-sink-02.txt +++ /dev/null @@ -1,697 +0,0 @@ -INTERNET-DRAFT Donald E. Eastlake, 3rd - IBM -Expires March 2000 September 1999 -draft-ietf-dnsind-kitchen-sink-02.txt - - - - The Kitchen Sink DNS Resource Record - --- ------- ---- --- -------- ------ - - Donald E. Eastlake 3rd - - - -Status of This Document - - This draft, file name draft-ietf-dnsind-kitchen-sink-02.txt, is - intended to be become an Experimental RFC. Distribution of this - document is unlimited. Comments should be sent to - or to the author. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved - - - -Abstract - - Periodically people desire to put proprietary, complex, and/or - obscure data into the Domain Name System (DNS). This draft defines a - kitchen sink Resource Record that will satisfy this desire for the - storage of miscellaneous structured information. - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT The Kitchen Sink Resource Record - - -Acknowledgements - - The suggestions or information provided by the following persons have - improved this document and they are gratefully acknowledged: - - Rob Austein - Matt Crawford - Johnny Eriksson - Phillip H. Griffin - Michael A. Patton - David Singer - - - -Table of Contents - - Status of This Document....................................1 - Copyright Notice...........................................1 - Abstract...................................................1 - - Acknowledgements...........................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. Kitchen Sink Resource Record............................3 - 2.1 The Meaning Octet......................................4 - 2.2 The Coding and Subcoding Octets........................5 - 2.2.1 ASN.1 Subcodings.....................................7 - 2.2.2 MIME Subcodings......................................7 - 2.2.3 Text Subcodings......................................8 - 3. Master File Representation..............................8 - 4. Performance Considerations..............................9 - 5. Security Considerations.................................9 - 6. IANA Considerations.....................................9 - 7. Full Copyright Statement................................9 - - References................................................11 - Author's Address..........................................12 - Expiration and File Name..................................12 - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT The Kitchen Sink Resource Record - - -1. Introduction - - The Domain Name System (DNS) provides a replicated distributed secure - hierarchical database which stores "resource records" (RRs) under - hierarchical domain names. This data is structured into zones which - are independently maintained. [RFC 1034, 1035, 2535] - - Numerous types of RRs have been defined. These support such critical - functions as host name to address translation (A, AAAA, etc. RRs), - automatic mail routing (MX etc. RRs), and other functions. In - addition, there are RRs defined related to the zone structure and - administration of the DNS (SOA, NS, and RP RRs), security (SIG, KEY, - and NXT RRs), etc. There is a TXT RR for the inclusion of general - human readable text. - - New RRs that are reasonably simple and designed via the open IETF - standards process are periodically added as new needs become - apparent. But there are people who want to put some proprietary, - complex and/or non-standard structured data in the DNS. In the past - they have frequently come up with some way of reinterpreting the TXT - RR, since that is one of the least constrained RRs. This is likely a - bad idea since all previous ways to reinterpreting the TXT RR have - sunk without a trace. (Well, if they actually got an RFC out, it's - still there, but, practically speaking, almost nobody actually uses - it.) - - If a new type of data is needed for a global interoperable use in the - DNS, the best course is to design a new RR that meets the need - through the IETF standards process. This draft defines an extremely - general and flexible RR which can be used for other data, such as - proprietary data, where global interoperability is not a - consideration. It includes representations of OSI ASN.1, MIME, XML, - and, recursively, DNS RRs. - - - -2. Kitchen Sink Resource Record - - The symbol for the kitchen sink resource record is SINK. Its type - number is 40. This type is defined across all DNS classes. - - The RDATA portion of the SINK RR is structured as follows: - - - - - - - - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT The Kitchen Sink Resource Record - - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | meaning | coding | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | subcoding | / - +--+--+--+--+--+--+--+--+ / - / data / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The "meaning", "coding", and "subcoding" octets are always present. - The "data" portion is variable length and could be null in some - cases. The size of the "data" portion can always be determined by - subtracting 3 from the SINK resource record RDLENGTH. The coding - octet gives the general structure of the data. The subcoding octet - provides additional information depending on the value of the coding - nibble. - - All references to "domain name" in this document mean a domain name - in the DNS CLASS of the SINK RR. - - - -2.1 The Meaning Octet - - The meaning octet indicates whether any semantic tagging appears at - the beginning of the data field and the format of such semantic - tagging. This contrasts with the coding and subcoding octets which - merely indicate format. The inclusion of such semantic tagging is - encouraged and it is expected to be the primary means by which - applications determine if a SINK RR is of the variety in which they - have interest. - - It is noted that multiple popular uses of SINK could develop that are - not distinguished by using different parts of the DNS name space or - different DNS classes. If this occurs, retrievals may fetch large - sets of SINK RR to be sorted through at the application level. - Should this occur, such popular uses of SINK should obtain and - migrate to their own RR number using normal RR number allocation - procedures. In addition, it would be possible to define an extended - query operation that selects from among SINK RRs based on the - semantic tag. - - The types of tags available are chosen to be globally unique and - under the control of some "owner". The owner designates the meaning - associated with the tags they control. Where the tag is a URI, it is - recommended that a retrieval from the URI fetch material that would - be helpful in determining this meaning. No a priori method is - defined for determining the meaning of other tags beside an out of - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT The Kitchen Sink Resource Record - - - band question to the owner. - - INITIAL ASSIGNED MEANING VALUES - - 0 - reserved. - - 1 - none. - 2 - OID. - 3 - domain name. - 4 - URI. - - 5-254 - available for assignment, see section 6. - - 255 - reserved. - - A meaning octet value of 1 indicates that there is no semantic - tagging at the beginning of the data area. The information, whatever - it is, starts at the beginning of the data field and is coded - according to the coding and subcoding octets. - - Meaning octet values of 2, 3, or 4, indicate, on the other hand, that - a semantic tag is present. A value of two indicates that a BER - [X.690] encoded OID appears prefixed by a single unsigned octet of - OID length count. A value of three indicates that a DNS domain name - appears in wire format with name compression prohibited. And a value - of four indicates that a null (zero) octet terminated URI appears. - - - -2.2 The Coding and Subcoding Octets - - The coding octet gives the major method by which the data in the data - field is encoded. It should always have a meaningful value. The - subcoding octet is intended to give additional coding details. - Although the subcoding octet is always present, it must be - interpreted in the context of the coding octet. For any coding octet - value which does not specify subcoding octet value meanings, the - subcoding octet MUST be ignored and SHOULD be zero. - - While not explicitly mentioned below, the data field will actually - start with a semantic tag if indicated by the meaning octet. If such - a semantic tag is present, any data prefix required by the coding or - subcoding octet is placed after the semantic tag and before the data. - - CODING OCTET VALUES - - 0 - reserved. - - 1 - DNS RRs. The data portion consists of DNS resource records - as they would be transmitted in a DNS response section. The - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT The Kitchen Sink Resource Record - - - subcoding octet is the number of RRs in the data area as an - unsigned integer. Domain names may be compressed via pointers - as in DNS replies. The origin for the pointers is the beginning - of the RDATA section of the SINK RR. Thus the SINK RR is safe - to cache since only code that knows how to parse the data - portion of a SINK RR need know of and can expand these - compressions. - - 2 - MIME structured data [RFC 2045, 2046]. The data portion is - a MIME structured message. The "MIME-Version:" header line may - be omitted unless the version is other than "1.0". The top - level Content-Transfer-Encoding may be encoded into the - subcoding octet (see section 2.2.2). Note that, to some extent, - the size limitations of DNS RRs may be overcome in the MIME case - by using the "Content-Type: message/external-body" mechanism. - - 3 - Text tagged data. The data potion consists of text formated - as specified in the TXT RR except that the first and every - subsequent odd numbered text item is considered to be a tag - labeling the immediately following text item. If there are an - odd number of text items overall, then the last is considered to - label a null text item. Syntax of the tags is as specified in - RFC 2396 for the "Authority Component" without the two leading - slashes ("//") or trailing slash using the DNS for authority. - Thus any organization with a domain name can assign tags without - fear of conflict. The subcodings octet specifies the encoding - of the labeled text items as specified in section 2.2.3. - - 4 - HTML. The subcoding octet indicates the version of HTML - with the major version number in the upper nibble and the minor - version number in the lower nibble. Thus, for example, HTML 3.2 - would be indicated by a 0x32 octet. - - 5 - XML. The subcoding octet is the version of XML, currently - 1. - - 6 - ASN.1 [X.680, etc.]. See section 2.2.1. - - 7-251 - Available for assignment, see section 6. - - 252 - Private coding format indicated by an OID. The format of - the data portion is indicated by an initial BER encoded OID - which is prefixed by a one octet unsigned length count for the - OID. The subcoding octet is available for whatever use the - private formating wishes to make of it. - - 253 - Private coding format indicated by a domain name. The - format of the data portion is indicated by an initial wire - format domain name with compression prohibited. (Such names are - self delimiting.) The subcoding octet is available for whatever - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT The Kitchen Sink Resource Record - - - use the private formating wishes to make of it. - - 254 - Private coding format indicated by a URI. The format of - the data portion is indicated by an initial URI [RFC 2396] which - is terminated by a zero (null) valued octet followed by the data - with that format. The subcoding octet is available for whatever - use the private formating wishes to make of it. The manner in - which the URI specifies the format is not defined but presumably - the retriever will recognize the URI by some pattern match. - - 255 - reserved. - - NOTE: the existence of a DNS RR coding and the infinite possibilities - of ASN.1, XML, and MIME permit one to SINK to even greater depths by - nesting. - - - -2.2.1 ASN.1 Subcodings - - For ASN.1 [X.680, etc.] data, a specific concrete encoding must be - chosen as indicated by the subcoding octet. - - ASN.* SUBCODINGS - - 0 - reserved. - 1 - BER ( Basic Encoding Rules [X.690] ). - 2 - DER ( Distinguished Encoding Rules [X.690] ). - 3 - PER ( Packed Encoding Rules ) Aligned [X.691]. - 4 - PER Unaligned [X.691]. - 5 - CER ( Canonical Encoding Rules [X.690] ). - 6-253 - available for assignment, see section 6. - 254 - private. This subcoding will never be assigned to a standard - set of encoding rules. An OID preceded by a one octet unsigned - length of OID appears at the beginning of the data area after - the ASN coding OID. - 255 - reserved. - - - -2.2.2 MIME Subcodings - - If the coding octet indicates the data is MIME structured, the - precise encoding is given by the subcoding octets as listed below. - - MIME SUBCODINGS - - 0 - reserved, see section 6. - 1 - 7bit. - 2 - 8bit. - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT The Kitchen Sink Resource Record - - - 3 - binary. - 4 - quoted-printable. - 5 - base64. - 6 - 253 - available for assignment, see section 6. - 254 - private. The data portion must start with an "x-" or "X-" - token denoting the private content-transfer-encoding immediately - followed by one null (zero) octet followed by the remainder of - the MIME object. - 255 - reserved, see section 6. - - - -2.2.3 Text Subcodings - - If the coding octet indicates the data is text, the exact encoding of - the text items is indicated by the subcoding octet as follows: - - TEXT SUBCODINGS - - 0 - reserved, see section 6. - 1 - ASCII. - 2 - UTF-7 [RFC 1642]. - 3 - UTF-8 [RFC 2044]. - 4 - ASCII with MIME header escapes [RFC 2047]. - 5 - 253 - available for assignment, see section 6. - 254 - private. Each text item must start with a domain name [RFC - 1034] in wire format without compression denoting the private - text encoding immediately followed by the remainder of the text - item. - 255 - reserved, see section 6. - - - -3. Master File Representation - - SINK resource records may appear as lines in zone master files. The - meaning, coding, and subcoding appear as unsigned decimal integers. - The data portion can be quite long. It is represented in base 64 - [RFC 2045] and may be divided up into any number of white space - separated substrings, down to single base 64 digits, which are - concatenated to obtain the full data. These substrings can span - lines using the standard parenthesis notation. (This type of base64 - master file data is also required to support the DNS KEY and SIG - security RRs [RFC 2535].) - - - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT The Kitchen Sink Resource Record - - -4. Performance Considerations - - Currently DNS is optimized for small data transfers, generally not - exceeding 512 octets including overhead. Larger transfers are less - efficient but do work correctly and efforts are underway to make them - more efficient. - - It is easy to create very large RRs or RR sets using SINK. DNS - administrators should think about this and may wish to discourage - large RRs or RR sets. Consideration should also be given to putting - zones from which large RRs or RR sets will be commonly retrieved on - separate hosts which can be tuned for the load this will represent. - - - -5. Security Considerations - - Since the SINK resource record can be used to store arbitrary data in - the DNS, this data could have security consequences, particularly if - it is control, executable, macro, or interpretable information or - very large and might cause buffer overflow. Due care should be - taken. - - [RFC 2535] covers data original authentication of the data in the - domain name system including SINK RRs. - - - -6. IANA Considerations - - Assignment of specific meaning to the values listed herein as - "reserved" requires an IETF standards action. - - All other assignments of available meaning, coding, or subcoding - octet values are by IETF consensus. - - The many provisions for private indicita specified by separately - allocated OIDs, domain names, or URIs should cover most requirements - for private or proprietary values. - - - -7. Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT The Kitchen Sink Resource Record - - - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT The Kitchen Sink Resource Record - - -References - - [RFC 1034] - P. Mockapetris, "Domain names - concepts and - facilities", 11/01/1987. - - [RFC 1035] - P. Mockapetris, "Domain names - implementation and - specification", 11/01/1987. - - [RFC 1642] - D. Goldsmith, M. Davis, "UTF-7 - A Mail-Safe - Transformation Format of Unicode", 07/13/1994. - - [RFC 2044] - F. Yergeau, "UTF-8, a transformation format of Unicode - and ISO 10646", 10/30/1996. - - [RFC 2045] - N. Freed, N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message Bodies", - 12/02/1996. - - [RFC 2046] - N. Freed, N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part Two: Media Types", 12/02/1996. - - [RFC 2047] - K. Moore, "MIME (Multipurpose Internet Mail Extensions) - Part Three: Message Header Extensions for Non-ASCII Text", - 12/02/1996. - - [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", August 1998. - - [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", - March 1999. - - [X.680] - ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, - Information Technology - Abstract Syntax Notation One (ASN.1): - Specification of Basic Notation - - [X.681] - ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998, - Information Technology - Abstract Syntax Notation One (ASN.1): - Information Object Specification - - [X.682] - ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998, - Information Technology - Abstract Syntax Notation One (ASN.1): - Constraint Specification - - [X.683] - ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998, - Information Technology - Abstract Syntax Notation One (ASN.1): - Parameterization of ASN.1 Specifications - - [X.690] - ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, - Information Technology - ASN.1 Encoding Rules: Specification of Basic - Encoding Rules (BER), Canonical Encoding Rules (CER) and - - -D. Eastlake 3rd [Page 11] - - -INTERNET-DRAFT The Kitchen Sink Resource Record - - - Distinguished Encoding Rules (DER) - - [X.691] - ITU-T Recommendation X.691 (1997) | ISO/IEC 8825-2:1998, - Information Technology - ASN.1 Encoding Rules: Specification of - Packed Encoding Rules (PER) - - - -Author's Address - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road - Carmel, 10512 USA - - Telephone: +1 914-276-2668 (h) - +1 914-784-7913 (w) - FAX: +1 914-784-3833 (w) - EMail: dee3@us.ibm.com - - - -Expiration and File Name - - This draft expires March 2000. - - Its file name is draft-ietf-dnsind-kitchen-sink-02.txt. - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 12] - diff --git a/doc/expired/draft-ietf-dnsind-local-compression-05.txt b/doc/expired/draft-ietf-dnsind-local-compression-05.txt deleted file mode 100644 index ec27e3ac77..0000000000 --- a/doc/expired/draft-ietf-dnsind-local-compression-05.txt +++ /dev/null @@ -1,420 +0,0 @@ -INTERNET-DRAFT Peter Koch -Expires: December 1999 Universitaet Bielefeld -Updates: 1035, 1183, 2163, 2168, 2535 June 1999 - - A New Scheme for the Compression of Domain Names - draft-ietf-dnsind-local-compression-05.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - Comments should be sent to the author or the DNSIND WG mailing list - . - -Abstract - - The compression of domain names in DNS messages was introduced in - [RFC1035]. Although some remarks were made about applicability to - future defined resource record types, no method has been deployed yet - to support interoperable DNS compression for RR types specified since - then. - - This document summarizes current problems and proposes a new - compression scheme to be applied to future RR types which supports - interoperability. Also, suggestions are made how to deal with RR - types defined so far. - -1. Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - -Koch Expires December 1999 [Page 1] - -INTERNET-DRAFT DNS Compression June 1999 - - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - Domain names herein are for explanatory purposes only and should not - be expected to lead to useful information in real life [RFC2606]. - -2. Background - - Domain name compression was introduced in [RFC1035], section 4.1.4, - as an optional protocol feature and later mandated by [RFC1123], - section 6.1.2.4. The intent was to reduce the message length, - especially that of UDP datagrams, by avoiding repetition of domain - names or even parts thereof. - - A domain name is internally represented by the concatenation of label - strings, where the first octet denotes the string length, not - including itself. The null string, consisting of a single octet of - zeroes, is the representation of the root domain name and also - terminates every domain name. - - As labels may be at most 63 characters long, the two most significant - bits in the length octet will always be zero. Compression works by - overloading the length octet with a second meaning. If the two MSB - have the value '1', the remainder of the length octet and the next - octet form a compression pointer, which denotes the position of the - next label of the current domain name in the message: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 1 1| OFFSET | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - It is important that these pointers always point backwards. - - Compression may occur in several places. First, the owner name of an - RR may be compressed. The compression target may be another owner - name or a domain name in the RDATA section of a previous RR. Second, - any domain name within the RDATA section may be compressed and the - target may be part of the same RR, being the owner name or another - domain name in the RDATA section, or it may live in a previous RR, - either as its owner or as a domain name in its RDATA section. In - fact, due to the chaining feature, combinations of the above may - occur. - -3. Problems - - While implementations shall use and must understand compressed domain - names in the RDATA section of "well known" RR types (those initially - defined in [RFC1035]), there is no interoperable way of applying - -Koch Expires December 1999 [Page 2] - -INTERNET-DRAFT DNS Compression June 1999 - - compression to the RDATA section of newer RRs: - - Quote from [RFC1123], section 6.1.3.5: - Compression relies on knowledge of the format of data inside a - particular RR. Hence compression must only be used for the - contents of well-known, class-independent RRs, and must never be - used for class-specific RRs or RR types that are not well-known. - The owner name of an RR is always eligible for compression. - - DNS records in messages may travel through caching resolvers not - aware of the particular RR's type and format. These caches cannot - rearrange compression pointers in the RDATA section simply because - they do not recognize them. Handing out these RRs in a different - context later will lead to confusion if the target resolver tries to - uncompress the domain names using wrong information. This is not - restricted to intermediate caching but affects any modification to - the order of RRs in the DNS message. - -4. Local Compression - - We often observe a certain locality in the domain names used as owner - and occuring in the RDATA section, e.g. in MX or NS RRs but also in - newer RR types [RFC1183]: - - host.foo.bar.example RP adm.foo.bar.example adm.persons.bar.example - - So, to still profit from compression without putting interoperability - at risk, a new scheme is defined which limits the effect of - compression to a single RR. - - In contrast to the usual method of using offsets relative to the - start of a DNS packet we start counting at the RR owner or calculate - pointers relative to the start of the RDATA to avoid context - sensitivity. We use an additional compression indicator for a two - octet local pointer: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 1 0| OFFSET | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The "10" bits will indicate the use of local compression and - distinguish it from conventional compression, plain labels and EDNS - label codes [EDNS0]. Two types of pointers need to be specified: - those pointing into the owner name and those pointing into RDATA. - - A) Pointers into the owner name are interpreted as the ordinal label - number (starting at 0 for the topmost label, the TLD). This way we - avoid the need for extra decompression of the owner name during - -Koch Expires December 1999 [Page 3] - -INTERNET-DRAFT DNS Compression June 1999 - - message composition or decomposition. - - The highest possible value of a compression pointer pointing into - the owner name is 254. The value 255 is reserved for future use. - - B) Pointers into the RDATA section start at the fixed value 256 for - the first octet and have a maximum value of 16383 limiting - possible targets to the first 16128 octets. The actual offset - relative to the start of RDATA is determined by subtracting 256 - from the value of the pointer. - - Local pointers MUST point to a previous occurence of the same name in - the same RR. Even domain names in another RR of the same type cannot - serve as compression targets since the order of RRs in an RRSet is - not necessarily stable. The length of the compressed name(s) MUST be - used in the length calculation for the RDLENGTH field. - -Example - - Consider a DNS message containing two resource records, one CNAME RR - and one XMPL RR, undefined and meaningless so far, with an RDATA - section consisting of two domain names: - - ab.foo.example IN CNAME bar.example - bar.example IN XMPL a.foo.example foo.example - - In a message this appears as follows (randomly starting at octet 12): - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 12 | 2 | a | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 14 | b | 3 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 16 | f | o | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 18 | o | 7 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 20 | e | x | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 22 | a | m | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 24 | p | l | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 26 | e | 0 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - 10 octets skipped (TYPE, CLASS, TTL, RDLENGTH) - -Koch Expires December 1999 [Page 4] - -INTERNET-DRAFT DNS Compression June 1999 - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 38 | 3 | b | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 40 | a | r | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 42 | 1 1| 19 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The XMPL RR with local compression applied: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 44 | 1 1 | 38 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - 10 octets skipped (TYPE, CLASS, TTL, RDLENGTH) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 56 | 1 | a | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 58 | 3 | f | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 60 | o | o | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 62 | 1 0| 0 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 64 | 1 0| 258 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The first local pointer at position 62 points to the topmost label - "example" of the XMPL RR's owner. - - The second local pointer at position 64 represents the "foo.example" - and points backwards into the RDATA section, third octet, at absolute - position 58. Note that with conventional compression this example - message would have occupied less space. - -5. Interaction with DNSSEC - - The security extensions to DNS [RFC2535] mandate that domain names in - RDATA be signed only in expanded, lower case format. For RR types - using local compression the specification is changed as follows: - - Resource Records subject to local compression MUST be stored, - signed, transmitted and verified in locally compressed form. Name - expansion or canonicalization MUST NOT be performed on the RDATA - section for signing or verification. - - This way RR type transparency can be achieved, since domain names in - -Koch Expires December 1999 [Page 5] - -INTERNET-DRAFT DNS Compression June 1999 - - the RDATA section are treated as arbitrary data and can be cached and - verified by resolvers not aware of the particular RR type. Old RR - types subject to conventional or no compression are not affected by - this change. - - Wildcard owners may serve as compression targets only in their fixed - part. Even if a particular query asks for a domain name which could - be used to compress the RDATA part more efficiently, this MUST NOT be - done. Otherwise signatures would be invalidated. - - Currently slave servers store zones in text format and re-encode the - data into wire format, e.g. after a restart. This encoding must be - unique to ensure signature validity. To achieve this, local - compression MUST be applied optimally, i.e. every domain name must be - compressed as far as possible and each local compression pointer must - point to the earliest available target (including the owner). - -6. Interaction with Binary Labels - - When constructing local compression pointers into the owner name, - every one-bit label is counted as a label. This way the compression - and decompression is independent of the actual bit-string - representation. - - For local compression pointers into the RDATA section, only bit- - string labels may serve as targets, not single one-bit labels. Bit- - string labels may be adjusted to increase compression efficiency - [BINLABELS, section 3.1] - - The internal representation of a domain name has a maximum length of - 255 [RFC 1035]. Any label consists of at least two octets, leading - to at most 127 labels per domain name plus the terminating zero - octet, which does not qualify as a compression target. With the - introduction of binary labels a domain name can consist of up to 1904 - labels (all one-bit labels). This document restricts the possible - compression targets in an owner name to the topmost 255 labels. This - limit was chosen to be consistent with [RFC2535], section 4.1.3. - -7. Old RR types and deployment - - Although differences in RDATA sections by class have not yet been - reported and the concept of classes did not really spread, we are - just considering the IN class here. - - The following RR types with domain names in the RDATA section have - been defined since [RFC1035] (Standards Track, Experimental and - Informational RFCs, ignoring withdrawn types): RP [RFC1183], AFSDB - [RFC1183], RT [RFC1183], SIG [RFC2535], PX [RFC2163], NXT [RFC2535], - -Koch Expires December 1999 [Page 6] - -INTERNET-DRAFT DNS Compression June 1999 - - SRV [RFC2052], NAPTR [RFC2168], KX [RFC2230]. Some specifications do - not mention DNS compression at all, others explicitly suggest it and - only in part identify interoperability issues. Only the KX and SRV - RR types are safe as their specifications prohibit compression. - - The specification of RP, AFSDB, RT, PX, and NAPTR is hereby changed - in that domain names in the RDATA section MUST NOT be compressed and - MUST NOT be compression targets. - - Local compression MUST NOT be used for owner names and it MUST NOT be - applied to domain names in RDATA sections of any RR type defined so - far. - - The specification of future RR types should explicitly select the use - of local compression or forbid RDATA domain name compression at all. - -8. Security Considerations - - The usual caveats for using unauthenticated DNS apply. This scheme is - believed not to introduce any new security problems. However, - implementors should be aware of problems caused by blindly following - compression pointers of any kind. [RFC1035] and this document limit - compression targets to previous occurences and this MUST be followed - in constructing and decoding messages. Otherwise applications might - be vulnerable to denial of service attacks launched by sending DNS - messages with infinite compression pointer loops. In addition, - pointers should be verified to really point to the start of a label - (for conventional and local RDATA pointers) and not beyond the end of - the domain name (for local owner name pointers). - - The maximum length of 255 applies to domain names in uncompressed - wire format, so care must be taken during decompression not to exceed - this limit to avoid buffer overruns. - -9. Acknowledgements - - The author would like to thank Andreas Gustafsson, Paul Vixie, Bob - Halley, Mark Andrews and Thomas Narten for their review and - constructive comments. - -10. References - - [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", - RFC 1034, STD 13, November 1987 - -Koch Expires December 1999 [Page 7] - -INTERNET-DRAFT DNS Compression June 1999 - - [RFC1035] Mockapetris,P., "Domain Names - Implementation and - Specification", RFC 1035, STD 13, November 1987 - - [RFC1123] Braden,R., "Requirements for Internet Hosts -- Application - and Support", RFC 1123, STD 3, October 1989 - - [RFC1183] Everhart,C., Mamakos,L., Ullmann,R., Mockapetris,P., "New - DNS RR Definitions", RFC 1183, October 1990 - - [RFC2052] Gulbrandsen,A., Vixie,P. "A DNS RR for specifying the - location of services (DNS SRV)", RFC 2052, October 1996 - - [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997 - - [RFC2163] Allocchio,C., "Using the Internet DNS to Distribute MIXER - Conformant Global Address Mapping (MCGAM)", RFC 2163, - January 1998 - - [RFC2168] Daniel,R., Mealling,M., "Resolution of Uniform Resource - Identifiers using the Domain Name System", RFC 2168, June - 1997 - - [RFC2230] Atkinson,R., "Key Exchange Delegation Record for the DNS", - RFC 2230, November 1997 - - [RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC - 2535, March 1999 - - [RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", - RFC 2606, BCP 32, June 1999 - - [EDNS0] Vixie,P., "Extension mechanisms for DNS (EDNS0)", draft- - ietf-dnsind-edns0-XX.txt, work in progress - - [BINLABELS] Crawford,M., "Binary Labels in the Domain Name System", - draft-ietf-dnsind-binary-labels-XX.txt, work in progress - -11. Author's Address - - Peter Koch - Universitaet Bielefeld - Technische Fakultaet - Postfach 10 01 31 - D-33501 Bielefeld - Germany - -Koch Expires December 1999 [Page 8] - -INTERNET-DRAFT DNS Compression June 1999 - - +49 521 106 2902 - - -Koch Expires December 1999 [Page 9] diff --git a/doc/expired/draft-ietf-dnsind-local-names-07.txt b/doc/expired/draft-ietf-dnsind-local-names-07.txt deleted file mode 100644 index 63fcfcfb0e..0000000000 --- a/doc/expired/draft-ietf-dnsind-local-names-07.txt +++ /dev/null @@ -1,662 +0,0 @@ -DNS Working Group Donald E. Eastlake, 3rd -INTERNET-DRAFT IBM -Expires December 1999 June 1999 - -draft-ietf-dnsind-local-names-07.txt - - - Local Domain Name System (DNS) Names - ----- ------ ---- ------ ----- ----- - - Donald E. Eastlake 3rd - - - -Status of This Document - - This draft, file name draft-ietf-dnsind-local-names-07.txt. - Distribution of this document is unlimited. Comments should be sent - to the DNS mailing list or to the author. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - - - -Abstract - - It is increasingly common for their to be "local" domain names which - are not intended to be seen from the global Internet. In some cases - this if for policy reasons, in other cases because they map to IP - addresses or other data which is only locally meaningful [RFC 1918, - 2373]. - - A new top level domain (TLD) name (.local) is reserved and a name - structure suggested below this TLD such that local private DNS zones - can safely be created without fear of conflict if these names should - leak out of a private enclave. It addition, a method of providing - DNS service for these names is suggested such that they are - maintained privately, similar to the reserved private IP addresses, - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT Local DNS Names - - - yet locally appear to be part of the global DNS name tree and are - reachable by a local resolver with no special knowledge. Additional - second level domain names are assigned under this TLD for IPv6 link - and site local addresses and loopback functions. - - - -Acknowledgments - - The valuable contributions of the following persons are gratefully - acknowledged: - - Dan Harrington - - Michael A. Patton - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT Local DNS Names - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - Acknowledgments............................................2 - - Table of Contents..........................................3 - - 1. Introduction............................................4 - 2. Local Names Via The .local Top Level Domain.............5 - 2.1 Local DNS Server Specifics.............................7 - 2.2 Local in-addr.arpa Zones...............................8 - 2.3 Name Conflicts.........................................8 - 2.4 Nested Enclaves........................................9 - 3. Other Names in .local...................................9 - 4. Security Considerations.................................9 - 4.1 Strength of Privacy Offered............................9 - 4.2 Interaction with DNSSEC...............................10 - - References................................................11 - Author's Address..........................................11 - Expiration and File Name..................................11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Local DNS Names - - -1. Introduction - - The global Internet Domain Name System (DNS) is documented in [RFC - 1034, 1035, 1591, 2606] and numerous additional Requests for Comment. - It defines a tree of names starting with root, ".", immediately below - which are top level domain names such as .com and .us. Below top - level domain names there are normally additional levels of names. - - Generally the information in the DNS is public and intended to be - globally accessible. Certainly, in the past, the model of the - Internet was one of end-to-end openness [RFC 1958]. However, with - increasing security threats and concerns, firewalls and enclaves have - appeared. In many cases, organizations have hosts or resources that - they specifically want to reference with DNS names but which they - also want to be walled off from global access and even from global - knowledge of the DNS name for the resource. - - In the realm of IP addresses, this has been accomplished by reserving - three blocks of IPv4 addresses as documented in [RFC 1918] and by - allocating parts of the IPv6 address space for link and site local - addresses [RFC 2373]. Familiarity with the contents of these RFCs is - assumed. Addresses in these blocks are not to be globally routed. - - In the DNS area, local private names have generally been achieved in - the past by "splitting" DNS at the enclave boundary, giving different - answers to resolvers depending or whether they are inside or outside - of the enclave, using different servers for inside and outside, etc. - as mentioned in [RFC 1918]. Such relatively complex configuration - diddling is at variance with the simple global tree structure of the - initial DNS concept. - - This document specifies an alternative approach to achieving the - effect of local names that is more in tune with the concept of a - single global DNS tree or at least the appearance of a single tree. - Use of this approach is not required and older techniques will - continue to work. - - [RFC 1918] requires that private IP addresses not be indirectly - exposed to the general Internet via DNS records or otherwise. By - implication, the same would be true of IPv6 local addresses. This - RFC provides the recommended way to accomplish such private IP - address hiding and carves out a limited exception thereto for the - addresses of the servers for some zones which are children of the - .local top level domain name. - - - - - - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Local DNS Names - - -2. Local Names Via The .local Top Level Domain - - The fundamental idea, as described in more detail below, is to define - second level domains under .local which are served by DNS name - servers that have private IP addresses. These server's addresses - would only be routed within the domain to which the names are local. - Thus the servers, and the names and resource records inside them, - would not be directly accessible outside the enclave, if the - guidelines in this document are followed. - - The following figure shows a highly simplified overview of an example - configuration: - - +----------------------------+ - | domain/enclave A | - | | - | #====================# | - | H private IP addrs A H | - | H H | - +-----------------------O privhost1 H | - | | H H | - +-----+-----------------O privhost2 H | - | | | H H | - | | | #====================# | - | | a | | - | +--------------------O pubhost3 | - .local | | | | | - +----+ | | +----------------------------+ - | | | | - | | | | +----------------------------+ - | | | | | domain/enclave B | - (root) | | | | | | - . ----+ | | | | #====================# | - | | | | | H private IP addrs B H | - | | | | | H H | - | +--|--------------------O privhost2 H | - | | | | H H | - +-------+ +-----------------O privhost3 H | - .com | | H : H | - | | #====:===============# | - | | : | - | b +-------------O pubhost4 | - +------+ | | - | +-------------O pubhost5 | - | | | - | +----------------------------+ - | - | example - +---------------------O pubhost6 - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Local DNS Names - - - Starting at the bottom, pubhost6 is intended to illustrate an - ordinary host connected to the Internet with domain name - pubhost6.example.com. Though not indicated in the above diagram, - every DNS zone is in fact served by at least two hosts (and some but - substantially more). The addresses of the servers for the root (.), - .com, and example.com zones would all be in the public portion of the - IP address space, i.e., in the space of all unicast IP addresses not - reserved for private use. - - Moving to the top of the figure, enclave A represents some - organization that wishes to have some hosts with publicly visible - names and some with hidden names that are visible only locally. - pubhost3.a.com is an example of a publicly visible host which would - probably have a public IP address although access to pubhost3 from - outside the enclave might be filtered or even blocked by a firewall - or the like. privhost1 and privhost2 are examples of hidden names. - If a zone with privhost1 and privhost2 in it is served by DNS servers - with private IP addresses ("private IP addresses A") such that the - servers are accessible within enclave A but not from outside enclave - A, then the information is that zone will only be locally visible. - As show in the above figure, privhost1 and privhost2 have addresses - that are also private IP addresses, making those hosts inaccessible - outside enclave A, but it is the private addresses of the DNS - servers, not of the hosts pointed to from within the private DNS - zone, that provides the protection for the DNS names and other - private DNS information. (From the above simplified diagram, it - might appear that fully qualified domain names of these hosts would - be privhost1.local and privhost2.local but the names are actually - more complex as explained in Section 2.1.) - - Finally, in the middle, another enclave is shown with two hosts with - visible names and public IP addresses, pubhost4.b.com and - pubhost5.b.com. In addition, there are two private host names - privhost2 and privhost3. The duplication of privhost2 between - enclaves A and B would not be a problem as only DNS resolvers in - enclave A can access the DNS servers with the zone having the enclave - A version of privhost2 and only DNS resolvers in enclave B can access - the DNS servers with the zone having the enclave B version of - privhost2. - - Publicly visible host names are required by [RFC 1918] to have public - (i.e., globally unique) IP addresses. Private DNS names would - normally have private IP addresses, and all do in the figure above, - but this is not required. A public IP address could be stored under - a private name. And, of course, it is possible for the same physical - host to have multiple IP addresses, including a mix of public and - private. The dotted line in the figure above is intended to indicate - that privhost3 and pubhost4 are actually the same physical machine. - The could be accomplished equally well by storing a single public - address for that host under both the public and private names or by - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Local DNS Names - - - having the host answer to both a public IP address stored under the - public name and a private IP address stored under the private name. - In the later case you could even also store the public address along - with the private address under the private name. - - - -2.1 Local DNS Server Specifics - - A variety of second level names are provided in the .local zone each - of which is a delegation point to a zone with some number of name - servers in one of the private IP address space blocks. The multiple - second level names permit choice between the different private IP - blocks and different numbers of servers. Thus the actual fully - qualified name for the private host examples in the figure above - would be more like privhost1.a2.local, privhost2.a2.local, etc. (but - see Section 2.3 below). - - Glue records are provided to give private IP addresses for initial - name servers; however, it should be noted that the NS and A records - in the local zones will dominate the information stored in the .local - zone. This means that once a resolver has contacted a local server, - the list of NS RRs in the local zone on that server will control and - could contain more or different servers than were given at the chosen - .local delegation point. Nevertheless, the glue A records in the - global .local zone do place some constraints of the private IP - address of the local DNS servers implementing zones which are - children of .local. - - It is also possible for an enclave to locally configure its own - version of the .local zone. Depending on its enclave boundary - implementation, it might be able to constrain all of its internal - references to .local to use its own variant version. This version - could have whatever private addresses were desired for the name - servers involved. Such a configuration MAY be used, but it is - recommended that the globally accessible .local specified herein be - used for uniformity. That way, even a unconstrained resolver - starting from the normal root servers (i.e., an "out of the box" - resolver) will correctly resolve or fail to resolve names under - .local depending on the resolvers location in the network as - specified herein. - - It is only necessary for the local DNS servers to have private IP - addresses to achieve the effect of local names. However, care MUST - be taken that none of the local DNS servers or any server that might - cache their output is accessible by any network interface that has a - non-private IP address. Otherwise considerable confusion could - result if local names are resolved by a resolver outside a local - enclave to private IP addresses which have a different meaning for - that resolver. - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT Local DNS Names - - -2.2 Local in-addr.arpa Zones - - Inverse lookup of local names corresponding to private IP addresses - needs to be provided via the in-addr.arpa and ip6.int zones. Because - of the fixed naming within this zone, different names with different - numbers of servers or different addresses can not be provided. As - with the forward .local entries, the actual NS RRs in the servers - serving the private portions of the inverse in-addr.arpa will - dominate. When one of these is queried by a resolver, it can provide - information on additional servers for that particular subzone in the - private IP address portion of the in-addr.arpa tree. - - - -2.3 Name Conflicts - - The intention is that local names would only be used in the enclave - where the entities they refer to exist, and these names would not be - exported. However, experience indicates that. despite best efforts - to avoid it, some such names will leak out via email cc's, URL's in - HTML, etc. (Such leakage occurs regardless of how the local names - are formed or whether they are accessible via the default root zone.) - These leaked private names can cause confusion if they can conflict - with global names or names local to other enclaves. Use of the - .local top level domain assures no conflict with global names. To - assure no conflict with different local fully qualified names, the - domain name of the enclave SHOULD always be prefixed to .local. - - For example, a company might have - host1.company.example - as a globally accessible host and - host2.company.example.b3.local - as a host for internal use only. The global name could normally be - resolvable anywhere on the Internet while the local name could not be - resolved anywhere except within the company enclave. - - Note that different names were chosen for the initial label in the - two names above, i.e., host1 and host2. The reason for this is that, - in some environments, local hosts are referred to by an unqualified - names, such as host3. For DNS look up purposes, such a name must be - expanded into a fully qualified domain name and a "search list" of - possible suffix qualifications is tried. If, for example, both - host4.school.ac.example and host4.school.ac.example.b3.local existed, - then a local reference to "host4" would be ambiguous and could lead - to either machine depending on the order of qualifications tried. - This order could even be different in different pieces of local - software or on different local hosts, resulting in substantial - confusion. For this reason, it is strongly recommended that disjoint - name sets be used for global and local entity unqualified domain - names and that fully qualified domain names be used wherever - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT Local DNS Names - - - practical. - - - -2.4 Nested Enclaves - - It is possible to have enclaves within enclaves. In general the best - way to accomplish this is to use a different portion of the private - IP address space at each nesting level of enclave. (Private IP - address space can be reused in enclaves that are siblings or the - like.) Then similar entries to those proposed here for .local can be - made in the private zone referring to name servers with addresses in - the nested enclave's private IP address space. - - - -3. Other Names in .local - - Three additional second level domain names are assigned in the .local - top level domain for other types of local names. - - In particular, - link.local and - site.local - are reserved for use in qualifying IPv6 link local names and site - local names. - - In addition, loopback.local is assigned and given the loopback - address. - - - -4. Security Considerations - - This section discusses the strength of the privacy offered by using - subzones of .local and interactions with DNS security. - - - -4.1 Strength of Privacy Offered - - Local names, as proposed herein, are not intended to be a strong - security mechanism. - - The privacy of the DNS information protected by storing it in servers - with private IP addresses is weak. It is completely dependent on the - integrity of enclave perimeter routing to make these servers - inaccessible. And it may occasionally leak out in any case due to - inclusion in email address fields, web pages, and the like, although - such leakage should be no worse than current split DNS - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT Local DNS Names - - - implementations of DNS data hiding. - - Software should not depend on local names being accessible only - within a particular enclave as someone could deliberately create the - same names within a different enclave. This is true even if, as - recommended herein, the names incorporate the domain name of the - original enclave in an attempt to avoid such conflicts. - - - -4.2 Interaction with DNSSEC - - Although an enclave may derive some amount of security by virtue of - its isolation, it will normally be desirable to implement DNS - security [RFC 2535] within the enclave. The enclave owner should - generate their own keys and sign their subzone of .local. However, a - signed copy of their public key can not be included in the .local - zone as it is different for every enclave. Thus, to authenticate the - .local subzone contents, it will be necessary to sign the KEY RR at - the apex of the local subzone of .local with the .local zone key or - another key that is trusted by local resolvers or staticly configure - the public key for the .local subzone in local resolvers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT Local DNS Names - - -References - - RFC 1033 - M. Lottor, "Domain Administrators Operations Guide", - November 1987. - - RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", - STD 13, November 1987. - - RFC 1035 - P. Mockapetris, "Domain Names - Implementation and - Specifications", STD 13, November 1987. - - RFC 1591 - J. Postel, "Domain Name System Structure and Delegation", - 03/03/1994. - - RFC 1918 - Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. - Lear, "Address Allocation for Private Internets", 02/29/1996. - - RFC 1958 - B. Carpenter, "Architectural Principles of the Internet", - 06/06/1996. - - RFC 2373 - R. Hinden, S. Deering, "IP Version 6 Addressing - Architecture", July 1998 - - RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", - March 1999. - - RFC 2606 - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", - June 1999. - - - -Author's Address - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road, RR #1 - Carmel, NY 10512 USA - - Telephone: +1 914-276-2668 (h) - +1 914-784-7913 (w) - FAX: +1 914-784-3833 (w) - EMail: dee3@us.ibm.com - - - -Expiration and File Name - - This draft expires December 1999. - - Its file name is draft-ietf-dnsind-local-names-07.txt. - - -D. Eastlake 3rd [Page 11] - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 12] - diff --git a/doc/expired/draft-ietf-dnsind-rfc2052bis-02.txt b/doc/expired/draft-ietf-dnsind-rfc2052bis-02.txt deleted file mode 100644 index 7db98afb97..0000000000 --- a/doc/expired/draft-ietf-dnsind-rfc2052bis-02.txt +++ /dev/null @@ -1,560 +0,0 @@ - - - -Applications Area Arnt Gulbrandsen -INTERNET-DRAFT Troll Technologies - Paul Vixie -Obsoletes: RFC 2052 Internet Software Consortium - January 1999 - - A DNS RR for specifying the location of services (DNS SRV) - -Status of this Memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - -Abstract - - This document describes a DNS RR which specifies the location of the - server(s) for a specific protocol and domain (like a more general - form of MX). - -Overview and rationale - - Currently, one must either know the exact address of a server to - contact it, or broadcast a question. This has led to, for example, - ftp.whatever.com aliases [RFC 2219], the SMTP-specific MX RR, and - using MAC-level broadcasts to locate servers. - - The SRV RR allows administrators to use several servers for a single - domain, to move services from host to host with little fuss, and to - designate some hosts as primary servers for a service and others as - backups. - - Clients ask for a specific service/protocol for a specific domain - (the word domain is used here in the strict RFC 1034 sense), and get - back the names of any available servers. - - - - -Gulbrandsen and Vixie Proposed [Page 1] - -RFC 2052bis DNS SRV RR January 1999 - - - Note that where this document refers to "address records", it means A - RR's, AAAA RR's, or their most modern equivalent. - -Introductory example - - If a SRV-cognizant web-browser wants to retrieve - - http://www.example.com/ - - it does a lookup of - - _http._tcp.www.example.com - - and retrieves the document from one of the servers in the reply. The - example zone file near the end of this memo contains answering RRs - for this query. - -Definitions - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" - used in this document are to be interpreted as specified in BCP 14. - Other terms used in this document are defined in the DNS - specification, RFC 1034. - - -The format of the SRV RR - - Here is the format of the SRV RR, whose DNS type code is 33: - - _Service._Proto.Name TTL Class SRV Priority Weight Port Target - - (There is an example near the end of this document.) - - Service - The symbolic name of the desired service, as defined in Assigned - Numbers [STD 2] or locally. An underscore (_) is prepended to - the service identifier to avoid collisions with DNS labels that - occur in nature. - - Some widely used services, notably POP, don't have a single - universal name. If Assigned Numbers names the service - indicated, that name is the only name which is legal for SRV - lookups. Only locally defined services may be named locally. - The Service is case insensitive. - - Proto - The symbolic name of the desired protocol, with an underscore - (_) prepended to prevent collisions with DNS labels that occur - - - -Gulbrandsen and Vixie Proposed [Page 2] - -RFC 2052bis DNS SRV RR January 1999 - - - in nature. _TCP and _UDP are at present the most useful values - for this field, though any name defined by Assigned Numbers or - locally may be used (as for Service). The Proto is case - insensitive. - - Name - The domain this RR refers to. The SRV RR is unique in that the - name one searches for is not this name; the example near the end - shows this clearly. - - TTL - Standard DNS meaning [RFC 1035]. - - Class - Standard DNS meaning [RFC 1035]. SRV records occur in the IN - Class. - - Priority - As for MX, the priority of this target host. A client MUST - attempt to contact the target host with the lowest-numbered - priority it can reach; target hosts with the same priority - SHOULD be tried in an order defined by the weight field. The - range is 0-65535. This is a 16 bit binary integer in network - byte order. - - Weight - A load balancing mechanism. When selecting a target host among - the those that have the same priority, the chance of trying this - one first SHOULD be proportional to its weight, as specified - below. Larger weights lead to a higher probability of being - selected. The range of this number is 0-65535. This is a 16 - bit binary integer in network byte order. Domain administrators - are urged to use Weight 0 when there isn't any load balancing to - do, to make the RR easier to read for humans (less noisy). In - the presence records containing weights greater than 0, records - with weight 0 have a very small chance of being selected. - - To choose the target, the client SHOULD implement the effect of - this algorithm. This permits administrators to plan weights to - achieve the load distribution desired. Each time a target is - needed, the client should order the remaining (not previously - used) SRV RRs at the current priority in any random fashion, - except placing all those with weight 0 at the beginning of the - list. Compute the sum of the weights of those RRs, and with - each RR associate the running sum in the selected order. Then - choose a random number (not necessarily of integral value) - between 0 and the sum computed (inclusive), and select the RR - whose running sum value is the first in the selected order which - - - -Gulbrandsen and Vixie Proposed [Page 3] - -RFC 2052bis DNS SRV RR January 1999 - - - is greater than or equal to the random number selected. - - - Port - The port on this target host of this service. The range is - 0-65535. This is a 16 bit binary integer in network byte order. - This is often as specified in Assigned Numbers but need not be. - - Target - As for MX, the domain name of the target host. There MUST be - one or more address records for this name, the name MUST NOT be - an alias (in the sense of RFC 1034 or RFC 2181). Implementors - are urged, but not required, to return the address record(s) in - the Additional Data section. Unless and until permitted by - future standards action, name compression is not to be used for - this field. - - A Target of "." means that the service is decidedly not - available at this domain. - -Applicability Statement - - In general, it is expected that SRV records will be used by clients - for applications where the relevant protocol specification indicates - that clients should use the SRV record. The examples in this - document use familiar protocols as an aid in understanding. It is - not intended that those protocols will necessarily use SRV records. - -Domain administrator advice - - Expecting everyone to update their client applications when the first - internet site adds a SRV RR for some server is futile (even if - desirable). Therefore SRV would have to coexist with address record - lookups for existing protocols, and DNS administrators should try to - provide address records to support old clients: - - - Where the services for a single domain are spread over several - hosts, it seems advisable to have a list of address records at - the same DNS node as the SRV RR, listing reasonable (if perhaps - suboptimal) fallback hosts for Telnet, NNTP and other protocols - likely to be used with this name. Note that some programs only - try the first address they get back from e.g. gethostbyname(), - and we don't know how widespread this behavior is. - - - Where one service is provided by several hosts, one can either - provide address records for all the hosts (in which case the - round-robin mechanism, where available, will share the load - equally) or just for one (presumably the fastest). - - - -Gulbrandsen and Vixie Proposed [Page 4] - -RFC 2052bis DNS SRV RR January 1999 - - - - If a host is intended to provide a service only when the main - server(s) is/are down, it probably shouldn't be listed in - address records. - - - Hosts that are referenced by backup address records must use the - port number specified in Assigned Numbers for the service. - - - Designers of future protocols for which "secondary servers" is - not useful (or meaningful) may choose to not use SRV's support - for secondary servers. Clients for such protocols may use or - ignore SRV RRs with Priority higher than the RR with the lowest - Priority for a domain. - - Currently there's a practical limit of 512 bytes for DNS replies. - Until all resolvers can handle larger responses, domain - administrators are strongly advised to keep their SRV replies below - 512 bytes. - - All round numbers, wrote Dr. Johnson, are false, and these numbers - are very round: A reply packet has a 30-byte overhead plus the name - of the service ("_telnet._tcp.example.com" for instance); each SRV RR - adds 20 bytes plus the name of the target host; each NS RR in the NS - section is 15 bytes plus the name of the name server host; and - finally each A RR in the additional data section is 20 bytes or so, - and there are A's for each SRV and NS RR mentioned in the answer. - This size estimate is extremely crude, but shouldn't underestimate - the actual answer size by much. If an answer may be close to the - limit, using a DNS query tool (e.g. "dig") to look at the actual - answer is a good idea. - - -The "Weight" field - - Weight, the load balancing field, is not quite satisfactory, but the - actual load on typical servers changes much too quickly to be kept - around in DNS caches. It seems to the authors that offering - administrators a way to say "this machine is three times as fast as - that one" is the best that can practically be done. - - The only way the authors can see of getting a "better" load figure is - asking a separate server when the client selects a server and - contacts it. For short-lived services like SMTP an extra step in the - connection establishment seems too expensive, and for long-lived - services like telnet, the load figure may well be thrown off a minute - after the connection is established when someone else starts or - finishes a heavy job. - - - - - -Gulbrandsen and Vixie Proposed [Page 5] - -RFC 2052bis DNS SRV RR January 1999 - - -The Port number - - Currently, the translation from service name to port number happens - at the client, often using a file such as /etc/services. - - Moving this information to the DNS makes it less necessary to update - these files on every single computer of the net every time a new - service is added, and makes it possible to move standard services out - of the "root-only" port range on unix. - - -Usage rules - - A SRV-cognizant client SHOULD use this procedure to locate a list of - servers and connect to the preferred one: - - Do a lookup for QNAME=_service._protocol.target, QCLASS=IN, - QTYPE=SRV. - - If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV - RR which specifies the requested Service and Protocol in the - reply: - - If there is precisely one SRV RR, and its Target is "." - (the root domain), abort. - - Else, for all such RR's, build a list of (Priority, Weight, - Target) tuples - - Sort the list by priority (lowest number first) - - Create a new empty list - - For each distinct priority level - While there are still elements left at this priority - level - Select an element randomly, with probability - Weight, as specified above, and move it to the - tail of the new list - - For each element in the new list - - query the DNS for address records for the Target or - use any such records found in the Additional Data - section of the earlier SRV response. - - for each address record found, try to connect to the - (protocol, address, service). - - - -Gulbrandsen and Vixie Proposed [Page 6] - -RFC 2052bis DNS SRV RR January 1999 - - - else if the service desired is SMTP (and SMTP has been defined - elsewhere to expect SRV lookups) - - skip to RFC 974 (MX). - - else - - Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A - - for each address record found, try to connect to the - (protocol, address, service) - - - Notes: - - - Port numbers SHOULD NOT be used in place of the symbolic service - or protocol names (for the same reason why variant names cannot - be allowed: Applications would have to do two or more lookups). - - - If a truncated response comes back from an SRV query, the rules - described in [RFC2181] shall apply. - - - A client MAY use means other than Weight to choose among target - hosts with equal Priority. - - - A client MUST parse all of the RR's in the reply. - - - If the Additional Data section doesn't contain address records - for all the SRV RR's and the client may want to connect to the - target host(s) involved, the client MUST look up the address - record(s). (This happens quite often when the address record - has shorter TTL than the SRV or NS RR's.) - - - Future protocols could be designed to use SRV RR lookups as the - means by which clients locate their servers. - - -Fictional example - - This is (part of) the zone file for example.com, a still-unused - domain: - - $ORIGIN example.com. - @ SOA server.example.com. root.example.com. ( - 1995032001 3600 3600 604800 86400 ) - NS server.example.com. - NS ns1.ip-provider.net. - NS ns2.ip-provider.net. - - - -Gulbrandsen and Vixie Proposed [Page 7] - -RFC 2052bis DNS SRV RR January 1999 - - - _ftp._tcp SRV 0 0 21 server.example.com. - _finger._tcp SRV 0 0 79 server.example.com. - ; telnet - use old-slow-box or new-fast-box if either is - ; available, make three quarters of the logins go to - ; new-fast-box. - _telnet._tcp SRV 0 1 23 old-slow-box.example.com. - SRV 0 3 23 new-fast-box.example.com. - ; if neither old-slow-box or new-fast-box is up, switch to - ; using the sysdmin's box and the server - SRV 1 0 23 sysadmins-box.example.com. - SRV 1 0 23 server.example.com. - ; HTTP - server is the main server, new-fast-box is the backup - ; (On new-fast-box, the HTTP daemon runs on port 8000) - _http._tcp SRV 0 0 80 server.example.com. - SRV 10 0 8000 new-fast-box.example.com. - ; since we want to support both http://example.com/ and - ; http://www.example.com/ we need the next two RRs as well - _http._tcp.www SRV 0 0 80 server.example.com. - SRV 10 0 8000 new-fast-box.example.com. - ; SMTP - mail goes to the server, and to the IP provider if - ; the net is down - _smtp._tcp SRV 0 0 25 server.example.com. - SRV 1 0 25 mailhost.ip-provider.net. - @ MX 0 server.example.com. - MX 1 mailhost.ip-provider.net. - ; NNTP - use the IP provider's NNTP server - _nntp._tcp SRV 0 0 119 nntphost.ip-provider.net. - ; IDB is an locally defined protocol - _idb._tcp SRV 0 0 2025 new-fast-box.example.com. - ; addresses - server A 172.30.79.10 - old-slow-box A 172.30.79.11 - sysadmins-box A 172.30.79.12 - new-fast-box A 172.30.79.13 - ; backup address records - new-fast-box and old-slow-box are - ; included, naturally, and server is too, but might go - ; if the load got too bad - @ A 172.30.79.10 - A 172.30.79.11 - A 172.30.79.13 - ; backup address record for www.example.com - www A 172.30.79.10 - ; NO other services are supported - *._tcp SRV 0 0 0 . - *._udp SRV 0 0 0 . - - In this example, a telnet connection to "example.com." needs an SRV - lookup of "_telnet._tcp.example.com." and possibly A lookups of "new- - - - -Gulbrandsen and Vixie Proposed [Page 8] - -RFC 2052bis DNS SRV RR January 1999 - - - fast-box.example.com." and/or the other hosts named. The size of the - SRV reply is approximately 365 bytes: - - 30 bytes general overhead - 20 bytes for the query string, "_telnet._tcp.example.com." - 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new- - fast-box", "old-slow-box", "server" and "sysadmins-box" - - "example.com" in the query section is quoted here and doesn't - need to be counted again. - 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server", - "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is - quoted and only needs to be counted once. - 120 bytes for the 6 address records (assuming IPv4 only) mentioned - by the SRV and NS RR's. - - -IANA Considerations - - The IANA has assigned RR type value 33 to the SRV RR. No other IANA - services are required by this document. - - -Changes from RFC 2052 - - This document obsoletes RFC 2052. The major change from that - previous, experimental, version of this specification is that now the - protocol and service labels are prepended with an underscore, to - lower the probability of an accidental clash with a similar name used - for unrelated purposes. Aside from that, changes are only intended - to increase the clarity and completeness of the document. - -Security Considerations - - The authors believes this RR to not cause any new security problems. - Some problems become more visible, though. - - - The ability to specify ports on a fine-grained basis obviously - changes how a router can filter packets. It becomes impossible - to block internal clients from accessing specific external - services, slightly harder to block internal users from running - unauthorized services, and more important for the router - operations and DNS operations personnel to cooperate. - - - There is no way a site can keep its hosts from being referenced - as servers (as, indeed, some sites become unwilling secondary - MXes today). This could lead to denial of service. - - - With SRV, DNS spoofers can supply false port numbers, as well as - - - -Gulbrandsen and Vixie Proposed [Page 9] - -RFC 2052bis DNS SRV RR January 1999 - - - host names and addresses. Because this vunerability exists - already, with names and addresses, this is not a new - vunerability, merely a slightly extended one, with little - practical effect. - -References - - STD 2: Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, - October 1994 (as currently updated by the IANA). - - RFC 1034: Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - RFC 1035: Mockapetris, P., "Domain names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - RFC 974: Partridge, C., "Mail routing and the domain system", RFC - 974, January 1986. - - BCP 14: Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - RFC 2181: Elz, R., Bush, R., "Clarifications to the DNS - Specification", RFC 2181, July 1997 - - RFC 2219: Hamilton, M., Wright, R., "Use of DNS Aliases for Network - Services", BCP 17, RFC 2219, October 1997 - -Acknowledgements - - The algorithm used to select from the weighted SRV RRs of equal - priority is adapted from one supplied by Dan Bernstein. - -Authors' Addresses - - Arnt Gulbrandsen Paul Vixie - Troll Tech Internet Software Consortium - Postboks 6133 Etterstad 950 Charter Street - N-0602 Oslo, Norway Redwood City, CA 94063 - +47 22646966 +1 650 779 7001 - - - - - - - - - - - -Gulbrandsen and Vixie Proposed [Page 10] - diff --git a/doc/expired/draft-ietf-dnsind-rollover-00.txt b/doc/expired/draft-ietf-dnsind-rollover-00.txt deleted file mode 100644 index fb2e231c01..0000000000 --- a/doc/expired/draft-ietf-dnsind-rollover-00.txt +++ /dev/null @@ -1,648 +0,0 @@ -INTERNET-DRAFT DNSIND Key Rollover -UPDATES RFC 1996 April 1999 - Expires October 1999 -draft-ietf-dnsind-rollover-00.txt - - - - Domain Name System (DNS) Security Key Rollover - ------ ---- ------ ----- -------- --- -------- - - Donald E. Eastlake 3rd, Mark Andrews - - - -Status of This Document - - This draft, file name draft-ietf-dnsind-rollover-00.txt, is intended - to be become a Proposed Standard RFC. Distribution of this document - is unlimited. Comments should be sent to the DNS working group - mailing list or to the authors. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - -Abstract - - Deployment of Domain Name System (DNS) security with good cryptologic - practice will involve large volumes of key rollover traffic. A - standard format and protocol for such messages will be necessary for - this to be practical and is specified herein. - - [Note: this draft has been moved to dnsind from dnssec as part of the - ongoing combination of these working groups. It would have been - draft-ietf-dnssec-rollover-01.txt otherwise.] - - - - -D. Eastlake 3rd, M. Andrews [Page 1] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. Key Rollover Scenario...................................3 - 3. Rollover Operation......................................5 - 3.1 Rollover to Parent.....................................5 - 3.2 Rollover to Children...................................6 - 4. Secure Zone Cuts and Joinders...........................7 - 5. Security Considerations.................................8 - 6. IANA Considerations.....................................9 - - References................................................10 - Authors Address...........................................10 - Expiration and File Name..................................11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, M. Andrews [Page 2] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - -1. Introduction - - The Domain Name System (DNS) [RFC 1034, 1035] is the global - hierarchical replicated distributed database system for Internet - addressing, mail proxy, and other information. The DNS has been - extended to include digital signatures and cryptographic keys as - described in [RFC 2535]. - - The principle security service provided for DNS data is data origin - authentication. The owner of each zone signs the data in that zone - with a private key known only to the zone owner. Anyone that knows - the corresponding public key can then authenticate that zone data is - from the zone owner. To avoid having to preconfigure resolvers with - all zone's public keys, keys are stored in the DNS with each zone's - key signed by its parent (if the parent is secure). - - To obtain high levels of security, keys must be periodically changed, - or "rolled over". The longer a private key is used, the more likely - it is to be compromised due to cryptanalysis, accident, or treachery - [RFC 2541]. - - In a widely deployed DNS security system, the volume of update - traffic will be large. Just consider the .com zone. If only 10% of - its children are secure and change their keys only once a year, you - are talking about hundreds of thousands of new child public keys that - must be securely sent to the .com manager to sign and return with - their new parent signature. And when .com rolls over its private - key, it will needs to send hundred of thousands of new signatures on - the existing child public keys to the child zones. - - It will be impractical to handle such update volumes manually on a - case by case basis. The bulk of such key rollover updates must be - automated. - - The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" - in this document are to be interpreted as described in [RFC 2119]. - - - -2. Key Rollover Scenario - - Although DNSSEC provides for the storage of other keys in the DNS for - other purposes, DNSSEC zone keys are included solely for the purpose - of being retrieved to authenticate DNSSEC signatures. Thus, when a - zone key is being rolled over, the old public key should be left in - the zone, along with the addition of the new public key, for as long - as it will reasonably be needed to authenticate old signatures that - have been cached or are held by applications. Similarly, old parent - SIGs should be retained for a short time after a parent KEY(s) roll - over and new parent SIGs have been installed. - - -D. Eastlake 3rd, M. Andrews [Page 3] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - - If DNSSEC were universally deployed and all DNS server's clocks were - synchronized and zone transfers were instantaneous etc., it might be - possible to avoid ever having duplicate old/new KEY/SIG RRsets due to - simultaneous expiration of SIGs everywhere in the DNS. But these - assumptions do not hold. Security aware DNS servers decrease the TTL - of secure RRs served as the expiration of their authenticating SIG(s) - approaches but some dithered fudge must generally be left due to - clock skew, RR retention by applications, and the like. Retaining - old KEYs for a while after rolling over to new KEYs will be necessary - in practical cases. - - Assume a middle zone with a secure parent and a secure child wishes - to role over its KEY RRset. This RRset would probably be one KEY RR - per crypto algorithm used to secure the zone, but for this scenario, - we will simply assume it is one KEY RR. The old KEY RR and two SIG - RRs will exist at the apex of the middle zone. (These RRs may also - exist at the leaf node for this zone in its parent if the parent - chooses to store them there.) The contents of the middle zone and the - zone KEY RRs of its secure child will have SIGs under the old key. - - The middle zone owner needs to communicate with its parent to obtain - a new parental signature covering both the old and new KEY RRs and - covering just the new KEY RR. The signature on both is needed so the - old KEY can be retain for the period it might be needed to - authenticate old SIGs. The middle zone would probably want to obtain - these in advance so that it can install them at the right time along - with its new SIG RRs covering the content of its zone. Finally, it - needs to give new SIG RRs to its child that cover its KEY RRs so it - must signal its children to ask for such SIG RRs. - - BEFORE ROLLOVER SHORTLY AFTER AFTER ROLLOVER - - p.x KEY P1 p.x KEY P1 p.x KEY P1 - p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1 - p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP - - m.p.x KEY M1 m.p.x KEY M2 m.p.x KEY M2 - m.p.x SIG(KEY) P1 m.p.x KEY M1 m.p.x SIG(KEY) P1 - m.p.x SIG(KEY) M1 m.p.x SIG(KEY) P1 m.p.x SIG(KEY) M2 - m.p.x SIG(KEY) M2 - - c.m.p.x KEY C1 c.m.p.x KEY C1 c.m.p.x KEY C1 - c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) M2 c.m.p.x SIG(KEY) M2 - c.m.p.x SIG(KEY) C1 c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) C1 - c.m.p.x SIG(KEY) C1 - - p = parent, m = middle, c = child, GP = grandparent key - P* = parent key, M* = middle zone key, C* = child key - - - - -D. Eastlake 3rd, M. Andrews [Page 4] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - -3. Rollover Operation - - Rollover operations use a DNS request syntactically identical to the - UPDATE request [RFC 2136] (except that the operation code is ROLLOVER - which is equal to (TBD)) and use a new form of NOTIFY [RFC 1996]. - Considerations for such requests to the parent and children of a zone - are givens below. - - All rollover operations involve significant amounts of cryptographic - calculations. Appropriate rate limiting SHOULD be applied to avoid - denial of service attacks. - - [This draft does not consider cross-certification key rollover.] - - - -3.1 Rollover to Parent - - A zone rolling over its KEY RRset sends an upward ROLLOVER request to - its parent. Actually, it will normally do two upward ROLLOVERs, one - for a combined KEY RRset of its old and new KEYs and one for just its - new KEY RRset, as discussed above. - - The server selection algorithm in [RFC 2136] section 4 should be - used. A child needs to be configured with or determine the name of - its parent but SHOULD NOT remember the location of its parent other - than via normal DNS caching of address RRs so that rollover will - continue to work if its parent servers are moved. - - The ROLLOVER request Zone should be specified as the parent zone. - The request Update section has the new KEY RRset on which the parent - signature is requested along with the requesting zone's SIG(s) under - its old KEY(s) as RRs to be "added" to the parent zone. The - inception and expiration times in this child SIG or SIGs are the - requested inception and expiration times for the new parent SIG(s). - The "prerequisites" section has the old child KEY RRset with the - parent SIG (see next paragraph). - - An upward ROLLOVER request MUST be signed and if not signed a BADAUTH - response generated. The signature MUST be under the previous zone - KEY, so the parent can validate it, or under a valid TSIG key - [draft-ietf-dnsind-tsig-*.txt] arranged with the parent. Including - the "prerequisite" section as specified above enables a parent that - keeps no record of its children's KEYs to still authenticate a - child's ROLLOVER request based on the old child KEY because the - parent is presented with its own SIG on the old KEY. - - If the ROLLOVER command is erroneous or violates parental policy, an - Error response is returned. If a parent retains copies of its - children's KEYs, it may use that knowledge to validate ROLLOVER - - -D. Eastlake 3rd, M. Andrews [Page 5] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - - request SIGs and ignore the "prerequisites" section. - - If the ROLLOVER command is OK and the parent can sign online, its - response MAY include the new parent SIG(s) in the response Update - section. This response MUST be sent to the originator of the - request. - - If the parent can not sign online, it should return a response with - an empty Update section and queue the SIG(s) calculation request. - This response MUST be sent to the originator of the request. - - ROLLOVER response messages MUST always include the actual parent's - SOA signed with a key the child should recognize in the Additional - Information section (see section 4 below). - - Regardless of whether the server has sent the new signatures above, - it MUST, once it has calculated the new SIG(s), send a ROLLOVER to - the child zone using the DNS port (53) and the server selection - algorithm defined in RFC 2136, Section 4. This ROLLOVER reqeust - contains the KEY RRset that triggered it and the new SIG(s). There - are several reasons for sending the ROLLOVER response regardless of - whether the new SIG RR(s) were sent in the original response. One is - to provide an indication to the operators of the zone in the event - someone is trying to hijack the zone. Another is that this maximizes - the probability of the response getting through. - - Although the parent zone need not hold or serve the child's key, if - it does the ROLLOVER command REQUEST SHOULD NOT automatically update - the parent zone. A later UPDATE command can be used to actually put - the new KEY into the parent zone if desired and supported by parent - policy. - - This document does not cover the question of parental policy on key - rollovers. Parents may have restrictions on how far into the future - they will sign KEY RRsets, what algorithms or key lengths they will - support, might require payment for the service, etc. The signing of - a future KEY by a parent is, to some extent, a granting of future - authoritative existence to the controller of the child private key - even if the child zone ownership should change. The only effective - way of invalidating such future signed child public keys would be for - the parent to roll over its key(s), which might be an expensive - operation. - - - -3.2 Rollover to Children - - When a secure zone is going to rollover its key(s), it needs to re- - sign the zone keys of any secure children under its new key(s). The - parent simply notifIES the child via a rollover NOTIFY [RFC 1996] - - -D. Eastlake 3rd, M. Andrews [Page 6] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - - that the parent KEY(s) have changed. The child then proceeds to do - an upward ROLLOVER request, as described in 3.1 above to obtain the - new parental SIG(s). - - A rollover NOTIFY is a NOTIFY request [RFC 1996] that has a QTYPE of - SIG and the owner name of the child zone. The answer section has the - current parent SOA signed by a key the child will know (see section - 4). - - A rollover NOTIFY MUST be signed and if not signed a BADAUTH response - generated. The signature MUST be under the previous parental zone - KEY, so the child can validate it, or under a valid TSIG key [draft- - ietf-dnsind-tsig-*.txt] negotiated between parent and child. - - The rollover NOTIFY can be sent to any of the nameservers for the - child using the nameserver selection algorithm defined in RFC 2136, - Section 4. Nameservers for the child zone receiving a rollover - NOTIFY query will forward the rollover NOTIFY in the same manner as - an UPDATE is forwarded. - - Unless the master server is configured to initiate an automatic - ROLLOVER it MUST seek to inform its operators that a rollover NOTIFY - request has been received. This could be done by a number of methods - including generating a log message, generating an email request to - the child zone's SOA RNAME or any other method defined in the - server's configuration for the zone. The default SHOULD be to send - mail to the zone's SOA RNAME. As with all rollover operations, care - should be taken to rate limit these messages so prevent them being - used to facilitate a denial of service attack. - - Once the message has been sent (or suppressed if so configured) to - the child zone's administrator the master server for the child zone - is free to respond to the rollover NOTIFY request. - - - -4. Secure Zone Cuts and Joinders - - There are two other events that have some similarity to key rollover. - - The first is when a secure zone the is more than one level deep has a - zone cut introduced inside it. For example, assume zone example.com - has a.b.c.example.com, d.b.c.example.com and e.example.com in it. A - zone cut could be introduced such that b.c.example.com became a - separate child zone of example.com. A real world exampe would be a - company that structures its DNS as host.branch.company.example. It - might start out will all of these names in one zone but later decide - to delegate all or some of the branches to branch zone file - maintainers. - - - -D. Eastlake 3rd, M. Andrews [Page 7] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - - The second is when a secure zone absorbs a child zone eliminating a - zone cut. This is simply the inverse of the previous paragraph. - - From the point of view of the parent zone above the splitting zone or - above the upper of the two combining zones, there is no change. - - When a zone is split by introducing a cut, the newly created child - must be properly configured. - - However, from the point of view of a child of the splitting zone - which becomes a grandchild or a grandchild that becomes a child due - to joinder, there is a change in parent name. Therefore, in general, - there is a change in parent KEY(s). Unless the entity that handles - rollovers for the zone whose parent name has changed is appropriately - updated, future automated rollover will fail because it will be sent - to the old parent. - - For this reason and so that other consistency checks can be made, the - parent SOA and SIG(SOA) are always included in the Answer section of - rollover NOTIFY requests and in ROLLOVER responsess. For automated - rollover to the new cut or joined state to work, these SOAs must be - signed with old KEY(s) of the former parent so the signatures can be - validated by the zone whose parent name is changing. In the case of - a joinder, if the private key of the pinched out middle zone is not - available, then manual update of the former grandchild, now child, - will be necessary. In the case of introducing a cut, operational - coordination with the former parent, now grandparent, signing the - initial updates to the former child, now grandchild, will be needed - to automate the reconfiguration of the zones. - - - -5. Security Considerations - - The security of ROLLOVER or UPDATE requests is essential, otherwise - false children could steal parental authorization or a false parent - could cause a child to install an invalid signature on its zone key, - etc. - - A ROLLOVER request can be authenticated by request SIG(s)under the - old zone KEY(s) of the requestor [RFC 2535]. The response SHOULD - have transaction SIG(s) under the old zone KEY(s) of the responder. - (This public key security could be used to rollover a zone to the - unsecured state but at that point it would generally not be possible - to roll back without manual intervention.) - - Alternatively, if there is a prior arrangement between a child and a - parent, ROLLOVER requests and responses can be secured and - authenticated using TSIG [draft-ietf-dnsind-tsig-*.txt]. (TSIG - security could be used to rollover a zone to unsecured and to - - -D. Eastlake 3rd, M. Andrews [Page 8] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - - rollover an unsecured zone to the secured state.) - - A server that implements online signing SHOULD have the ability to - black list a zone and force manual processing or demand that a - particular signature be used to generate the ROLLOVER request. This - it to allow ROLLOVER to be used even after a private key has been - compromised. - - - -6. IANA Considerations - - The DNS operation code (TBD) is assigned to ROLLOVER. There are no - other IANA considerations in this document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, M. Andrews [Page 9] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - -References - - [RFC 1034] - "Domain names - concepts and facilities", P. - Mockapetris, 11/01/1987. - - [RFC 1035] - "Domain names - implementation and specification", P. - Mockapetris, 11/01/1987. - - [RFC 1996] - "A Mechanism for Prompt Notification of Zone Changes - (DNS NOTIFY)", P. Vixie, August 1996. - - [RFC 2119] - "Key words for use in RFCs to Indicate Requirement - Levels", S. Bradner. March 1997. - - [RFC 2136] - "Dynamic Updates in the Domain Name System (DNS - UPDATE)", P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April - 1997. - - [draft-ietf-dnsind-tsig-*.txt] - - [RFC 2535] - "Domain Name System Security Extensions", D. Eastlake. - March 1999. - - [RFC 2541] - "DNS Security Operational Considerations", D. Eastlake. - March 1999. - - - -Authors Address - - Donald E. Eastlake 3rd - IBM - 65 Sindegan Hill Road, RR #1 - Carmel, NY 10512 - - Telephone: +1 914-276-2668 (h) - +1 914-784-7913 (w) - FAX: +1 914-784-3833 (w) - EMail: dee3@us.ibm.com - - - Mark Andrews - Internet Software Consortium - 1 Seymour Street - Dundas Valley, NSW 2117 - AUSTRALIA - - Telephone: +61-2-9871-4742 - Email: marka@isc.org - - - -D. Eastlake 3rd, M. Andrews [Page 10] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - -Expiration and File Name - - This draft expires in October 1999. - - Its file name is draft-ietf-dnsind-rollover-00.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, M. Andrews [Page 11] - - diff --git a/doc/expired/draft-ietf-dnsind-sec-rr-00.txt b/doc/expired/draft-ietf-dnsind-sec-rr-00.txt deleted file mode 100644 index 81ab5155ad..0000000000 --- a/doc/expired/draft-ietf-dnsind-sec-rr-00.txt +++ /dev/null @@ -1,663 +0,0 @@ -DNSIND WG Edward Lewis -INTERNET DRAFT NAI Labs -Category: I-D Jerry Scharf - ISC - Olafur Gudmundsson - NAI Labs - June 25, 1999 - The SEC Resource Record - - -Status of this Memo - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. - -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other -groups may also distribute working documents as Internet- Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference -material or to cite them other than as "work in progress." - -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt - -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html. - -Comments should be sent to the authors or the DNSIND WG mailing list -namedroppers@internic.net. - -This draft expires on December 25, 1999. - -Copyright Notice - -Copyright (C) The Internet Society (1999). All rights reserved. - -Abstract - -A new DNS reseource record, the SECurity RR, is defined to address -concerns about the parent zone's holding of the child zone's KEY RR -set. These concerns are addressed in a manner that retains the -information needed by a secure resolver when asking a parent zone -about the child zone. This proposal updates RFC 2535 and RFC 2181. - -1. Introduction - -DNS security extensions require a signed zone to hold KEY RR sets for -each of its delegations. This requirement has four negative -implications for the top level domains, which, for the most part, -consist of delegation points. (These issues also impact other -delegating zones, these problems are not unique to the TLDs.) -Addressing these concerns by removing the requirement for the KEY RR -in the parent has an adverse effect on secure resolution of DNS - -Expires December 25, 1999 [Page 1] -Internet Draft June 25, 1999 - -signatures. A new DNS reseource record, the SECurity RR, is defined -to address these concerns. - -The Zone Key Referral, described in another draft by the same authors, -is one proposed response to the concerns about parent's holding child -keys. However, that proposal has two drawbacks. One, it results in -two KEY RR sets at a delegation, one in the parent and one in the -child, which differ. It also does not address the expression of -security parameters, such as whether or not the child zone uses the -NXT record (which is currently mandatory). - -This document will begin by repeating the arguments against the -holding of keys at the parent as presented in the Zone Key Referral. -The document will then present the need for information about the -child to be held in parent. Following this, the SEC RR will be -defined, its master file representation discussed, and implications on -name servers. - -(Editorial note. Sections 1.1 through 1.5 are copied nearly verbatim -from the Zone Key Referral so that retirement of that draft will not -cause a problem.) - -1.1 Reasons for removing the KEY data from the parent - -There are a number of different reasons for the removal of the KEY RR -from the parent. Reasons include: - - o the performance impact that holding keys has on name servers - o the problem of updating a widely delegated parent zone on demand - o statements in RFC 2181 on authoritative data at delegations - o perceived liability of the operator of a name server or registry - -1.2 Performance Issues - -A sample zone will be used to illustrate the problem. The example -will part from reality mostly in the length of zone names, which -changes the size of the owner and resource record data fields. - -Expires December 25, 1999 [Page 2] -Internet Draft June 25, 1999 - - # $ORIGIN test. - # @ IN SOA - # IN SIG SOA - # IN KEY <1024 bit zone key> - # IN SIG KEY - # IN SIG KEY - # IN NS ns.test. - # IN SIG NS - # IN NXT my-org.test. NS SOA SIG KEY NXT - # IN SIG NXT - # - # my-org IN KEY <1024 bit zone key> - # IN KEY <1024 bit zone key> - # IN SIG KEY - # IN NS ns1.my-org.test. - # IN NS ns2.my-org.test. - # IN NXT that-org.test. NS SIG KEY NXT - # IN SIG NXT - # - # that-org IN KEY 0xC100 3 255 - # IN SIG KEY - # IN NS ns1.that-org.test. - # IN NS ns2.that-org.test. - # IN NXT test. NS SIG KEY NXT - # IN SIG NXT - -In this zone file, "my-org" is a delegation point of interest with two -registered public keys. Presumably, one key is for signatures -generated currently and the other is for still living and valid but -older signatures. "that-org" is another delegation point, with a NULL -key. This signifies that this zone is unsecured. - -To analyze the performance impact of the storing of keys, the number -of bytes used to represent the RRs in the procotol format is used. -The actual number of bytes stored will likely be higher, accounting -for data structure overhead and alignment. The actual number of bytes -transferred will be lower due to DNS name compression. - -The number of bytes for my-org's two 1024-bit keys, two NS records, -NXT and the associated signatures is 526. (1024 bit RSA/MD5 keys were -used for the calculation.) The bytes needed for that-org (with the -NULL key) is 346. Currently, there are close to 2 million entries in -com., so if we take my-org as a typical domain, over 1GB on memory -will be needed for com. The zone keys used in the example are set to -1024 bits. This number may range from as low as 512 bits upwards to -over 3000 bits. - -The increased size of the data held for the zone cuts will have two -impacts at the transport and below layers. Bandwidth beyond that -currently needed will be used to carry the KEY records. The inclusion -of all of the child's keys will also push DNS over the UDP size limit -and start using TCP - which could cause critical problems for current - -Expires December 25, 1999 [Page 3] -Internet Draft June 25, 1999 - -heavily used name servers, like the root and TLD name servers. EDNS0 -[RFC-to-be] addresses expansion of UDP message size, which alleviates -this problem. - -Another impact, not illustrated by the example, is the frequency of -updates. If each time a public key for my-org is added or deleted, -the SOA serial number will have to increase, and the SOA signed again. -If an average zone changes the contents of its key RR set once per -month, there will be on average 45 updates per minute in a zone of 2 -million delegations. (This estimate does not address the fact that -signatures also expire, requiring a new signing of the zone -periodically.) - -1.3 Security Incident Recovery (w/ respect to keys only) - -Once a zone administrator is alerted that any key's private -counterpart has been discovered (exposed), the first action to be -taken is to stop advertising the public key in DNS. This doesn't end -the availability of the key - it will be residing in caches and given -in answers from those caches - but is the closest action resembling -revokation available in DNS. - -Stopping the advertisement in the zone's name servers is as quick as -altering the master file and restarting the name server. Having to do -this in two places will will only delay the time until the recovery is -complete. - -For example, a registrar of a top level domain has decided to update -its zone only on Mondays and Fridays due to the size of the zone. A -customer/delegatee is the victim of a break in, in which one of the -items taken is the file of private keys used to sign DNS data. If this -occurs on a Tuesday, the thief has until Friday to use the keys before -they disappear from the DNS, even if the child stops publishing them -immediately. - -If the public key set is in the parent zone, and the parent zone is -not able to make the change quickly, the public key cannot be revoked -quickly. If the parent only refers to there being a key at the child -zone, then the child has the agility to change the keys - even issue a -NULL key, which will force all signatures in the zone to become -suspect. - -1.4 DNS Clarifications - -RFC 2181, section 6, clarifies the status of data appearing at a zone -cut. Data at a zone cut is served authoritatively from the servers -listed in the NS set present at the zone cut. The data is not -(necessarily) served authoritatively from the parent. (The exception -is in servers handling both the parent and child zone.) - -Section 6 also mentions that there are two exceptions created by -DNSSEC, the NXT single record set and the KEY set. This proposal -addresses the exception relating to the KEY set, by removing the set - -Expires December 25, 1999 [Page 4] -Internet Draft June 25, 1999 - -from the parent. The SEC RR is introduced and belongs in the parent -zone, there is no counterpart in the child (at the apex). - -1.5 Liability - -Liability is a legal concept, so it is not wise to attempt an -engineering solution to it. However, the perceived liability incurred -in using DNSSEC by registrars may prevent the adoption of DNSSEC. -Hence DNSSEC should be engineered in such a way to address the -concern. - -One source of liability is the notion that by advertising a public key -for a child zone, a parent zone is providing a service of security. -With that comes responsibility. By having the parent merely indicate -that a child has a key (or has no key), the parent is providing less -in the way of security. If the parent is wrong, the potential loss is -less. Instead of falsely authenticated data, configuration errors -will be apparent to the resolving client. - -Whether or not the KEY RR remains advertised in the parent zone or the -SEC RR is in place, the parent zone administrators still have to -adhere to proper key handling practices, which are being documented in -DNSOP draft. In particular, the parent has to be sure that the keys -it is signing for a child have been submitted by the true -administrator of the the child zone, and not submitted by an imposter. - -1.6 The needs of the resolver - -Now that the reasons for removing the child's keys from the parent -zone have been presented, reasons why something must take their place -are presented. A "secure" resolver is a DNS resolver that receives an -answer and, if a signature arrives, verifies the signature. Most -often, this operation will happen in resolvers that are part of name -servers, as opposed to general purpose hosts. - -The first step in authenticating a DNS response is to see if the data -is accompanied by a signature. There are five possible outcomes. -Three results are not desirable, a signature may arrive but shouldn't, -no signature arrives but should, or a signature arrives but uses the -wrong cryptographic algorthm Two outcomes can be considered -successful, a signature arriving with the correct algorithm or no -signature arrives and shouldn't. (There is one other case - a -signature generated with an inappropriate key - which is a matter -beyond the scope of this draft.) - -Since the resolver can not instantly know whether a signature is -expected, the resolver must start a discovery process. This process -can be done by the resolver querying zones between the root and the -desired domain for information about the next successive zones. -(Optimizing this search is not presented here.) For this search to be -successful, the parent must hold something that indicates the status -of the child's security, so the resolver may search with certainty. -While refraining from using the word "policy" to describe the data, -the phrase "security parameters" is used. - -Expires December 25, 1999 [Page 5] -Internet Draft June 25, 1999 - -The security parameters of a zone are not entirely defined yet, and -will remain open until a critical mass of operations experience is -gained. Initially, the following information is known to be needed. - -The set of algorithms in use by the zone. -KEY RRs and SIG RRs have protocol fields indicating how the key is -made. For now, two are in distribution, a value of 1 for RSA/MD5 and -3 for DSA. Unfortunately, the value are numeric in 8 bits, so a -bitmap representation cannot be used. - -The mechanism for negative answers. -Currently, the NXT is mandatory, liked by some administrators and -disliked by other administrators. NXTs cannot be made optional, doing -so makes them obsolete. (An attacker can make the responses look like -a zone doesn't use NXTs, even if the zone does.) If the choice of NXT -or no NXT can be securely indicated, then this is solved. There have -been discussions on alternatives to the NXT record. By allowing a -zone to indicate the style of negative answer in use, alternatives can -be installed in experimental zones. - -Signature policy. -This is an untested issue. Expressing a policy, such as whether -multiple algorithms are used, whether verification of one signature -needed or all signatures, etc., has not been fully studied. - -2. The SEC RR - -The SEC RR is a record that describes the DNS security parameters of -the owner. The owner MUST also have an NS RR set, i.e., the owner -MUST be a cut point. A signed zone MUST have a SEC RR set for each -delegation point. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Negative Answer Bitmap | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Security Parameters ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - The RDATA of the SEC RR - -The SEC RR RDATA contains two data fields. One is a 16-bit field -acting as a bitmap to indicate the means used to signify a negative -answer. The other field is an unbounded field of option-value pairs -indicating other salient settings for the zone. The latter field is -not padded to any particular byte boundary. - -The SEC RR is answered authoritatively from the parent zone, and is -signed by the parent. A properly configured delegation point in the -parent would have just an SEC RR, records used for negative answering, -and a glue NS set. The corresponding point in the child (the zone's -apex) would have the SOA, KEY set, NS records, negative answer - -Expires December 25, 1999 [Page 6] -Internet Draft June 25, 1999 - -records, and other desired and legal RR sets. SIG RR's appear in both -the parent and child side of the delegation. - -There is no other special processing of the SEC RR set. It is used in -a reply as an answer when it is the subject of a direct query (QTYPE -IS SEC) or when a QTYPE=ANY reaches the delegating zone. If a name -server is authoritative for both the parent and child, the SEC is -included in the ANY reply for the delegation point. - -(Editorial note: this region is in particular need of careful review.) - -The SEC RR for a name SHOULD be supplied optionally in the additional -data section if the CD bit is not set whenever a zone's NS or KEY set -is requested. If a request for a KEY set is sent to a parent-only -server and the server is not recursive, the server should add the SEC -record to the additional section of the referral message. - -If a name server authoritative for a child zone is asked for its SEC -RR and the server has never learned the SEC RR (whether through -caching the record or by also loading the parent zone), the server MAY -answer with a negative answer. The resolver seeking a SEC RR SHOULD -know to ask for this from a parent-serving name server. - -2.1 Negative Answer Bitmap - -The Negative Answer Bitmap indicates the mechanism for use in denying -the existance of data. The bitmap is 16 bits, the most significant -bit called 0, least significant is 15. - - Bit 0 = The parent doesn't know what the child uses (1=Yes) - Bit 1 = The child signs its negative answers (1=Yes) - Bit 2 = The child follows traditional DNS rules (1=yes) - Bit 3 = The child uses the NXT record (1=yes) - Bit 14 = The child uses a locally defined mechanism (1=yes) - Bit 15 = The length of the bit field has been extended (1=yes) - -Bits 4 through 14 are currently unassigned, and are under the purview -of IANA. Bit 15 MUST BE zero. (This specification must be -superceeded to define an extension mechanism.) - -A zone may use multiple mechanisms to indicate a negative answer. A -zone SHOULD expect that a resolver finding any one of the mechanisms -used in a reply indicates a negative answer, i.e. the mechanisms are -OR'd together. - -The only illegal values for this bit field are: - Bit 0 = 1 and any other bit turned on - Bit 0 = 0, Bit 1 = 1, and no other bit turned on - Bit 15 = 1 - -2.1.1 Bit 0 (Better titles will be attached later) - -The situation in which this bit is on should not arise, but it is -defined to be safe. The philosophy behind this is that security - -Expires December 25, 1999 [Page 7] -Internet Draft June 25, 1999 - -parameters should always be made explicit, including when a sitation -is unclear. - -2.1.2 Bit 1 - -This bit indicates that the child attachs SIG records to the resource -records used in the negative answer. For example, this may indicate -that the reslover should expect to see a SIG (NXT) when an NXT is -returned. - -2.1.3 Bit 2 - -The child will answer with an SOA or any of the other means used in -the past to indicate a negative answer. (I think a reference to the -negative answer/cache document should go here.) - -2.1.4. Bit 3 - -The child uses the NXT as defined in RFC 2535. This document declares -that the use of the NXT is optional, a deviation from RFC 2535. - -2.1.5 Bit 14 - -The child is using a mechanism that is not globally defined. A zone -should be in such a state for only experimental reasons and realize -that in this state, the negative answers it gives may not be useful to -the general population of resolvers. - -2.1.6 Bit 15 - -As of this specification, this bit must be 0 (zero). - -2.1.7 Unallocated bits - -The remainder of the bits must also be zero. A procedure will be -defined for allocating them. - -2.2 Security Parameters - -The Security parameters is a sequence of options and values. An -option is a numeric indicatior of the parameter. The value is usually -either a yes or no, or a enumerated value. In rare instances, an -option may require variable length data, in this case a triplet of -option-length-value is used. The presence of the length field is -indicated by the most significant bit in the option field being 1. -Due to the nature of the SEC RR, the length field is not commonly -used. - -The option field is 8 bits. The most significant bit of the options -field is turned on if there is a length field. The value field is -also 8 bits. If the option-length-value is needed, the length is 8 -bits and contains the number of octets comprising the value. No -padding is used. - -Expires December 25, 1999 [Page 8] -Internet Draft June 25, 1999 - -An option may appear multiple times in the Security Parameters. The -sequencing of the options is not significant. If two options - -contradict each other, this is an error, and is noted by the resolver. -A self-contradictory SEC RR is a security error and data from the zone -covered by it SHOULD be considered at risk. - -Option Values are - 0 Reserved - 1 Zone is unsigned - 2 Key Algorithm in use - 3 Signing policy - 0x70-0x7F Locally defined (no length field) - 0xF0-0xFF Locally defined (uses length field) - -All unassigned option values are under the control of IANA. Values 0 -to 127 do not use the length field, values 128 to 255 do use the -length field. The option value is to be treated as unsigned. - -2.2.1 Option 0 - -This option is reserved for future definition. - -2.2.2 Option 1 - -The parent has not signed a KEY RR for the child, therefore the child -zone has no DNSSEC approved signing keys. If this option is not -present, then the resolver SHOULD assume that there are zone keys in -the child zone. - -If the value of this is non-zero, this assertion is true. If the -value is zero, this assertion is false. If the parent has signed keys -for the child, the value is zero, however, in this case, the parent -SHOULD NOT include this option in the security parameters. - -It is tempting to exclude an unsigned zone option from this list, -relying on the absence of any in use key algorithms (option 2) to -imply that the zone is unsigned. The unsigned option is included to -make this information explicit, so that when analyzing a running zone, -it is obvious to an administrator that a zone is unsigned. - -2.2.3 Option 2 - -The parent has signed a key for the child which claims a particular -algorithm. This value field is equal to that of the algorithm field -of the triggering KEY RR. - -Option 2 can be repeated for different algorithms. It is not -necessary to have multiple Option 2 entries with the same key -algorithm value. - -If Option 1 and Option 2 appear in the same SEC RR, this is a -self-contradictory record. If neither Option 1 nor Option 2 appear, -this also constitues a self-contradictory record. - -Expires December 25, 1999 [Page 9] -Internet Draft June 25, 1999 - -2.2.4 Option 3 - -The child has the option to require that all material signatures -(those generated by DNSSEC-approved signing keys) must be validated -(within any temporal constraints) for the data to be considered valid. -The child may instead require that just one of the signatures be -validated. This may be a reflection of the manner in which a zone's -administration is shared amongst organizations. - -If Option 3 is not present (and Option 2 is), the resolver SHOULD -assume that ALL (temporally valid) signatures are required. If the -parent includes at least one Option 2, it SHOULD specify an Option 3, -with a value indicated by the child. - -Values for Option 3 are - 0 Reserved - 1 All signatures are required - 2 One signature is required - 256 Locally defined - -All remaining values are under the control of IANA. - -(Editorial note: whether the assumption that all signatures are -necessary or just one is sufficient in the absence of this option is -open to WG debate.) - -2.2.5 Options 0x70-0x7F - -This option is reserved for an organization to use locally, in an -experimental fashion. This option does not use the length field. -Global interpretation of this option is undefined. - -2.2.6 Options 0xF0-0xFF - -This option is reserved for an organization to use locally, in an -experimental fashion. This option uses the length field. Global -interpretation of this option is undefined. - -3. Master File Representation - -The SEC RR fields are to be represented as hexidecimal fields, with a -preceeding '0x', or in decimal format. Hexidecimal SHOULD be used. - -For example, the SEC RR representing a zone that use signed NXT -records, and has one or more DSA keys, one or more RSA keys, and -requires that just one signature be verified would be: - -myzone.test. 3500 IN SEC 0x5000 0x0201 0203 0302 - -(0x020102030302 is one field, hence one 0x prefix.) - -Hex values for the security parameters MAY BE separated by -whitespace, as shown. DNS data display routines SHOULD substitute - -Expires December 25, 1999 [Page 10] -Internet Draft June 25, 1999 - -mnemonics for these values, but MUST write the numeric form in master -files. - -4. Signature Policy - -The SEC RR must be signed by one or more zone keys of the parent -(delgating) zone, and the signatures must adhere to the parent's -policy. - -The SEC RR for the root zone is the lone exception, it appears at the -apex of the root zone, and must be signed sufficiently by the root's -zone key or keys. - -5. Cache Considerations - -When a SEC RR set for a name is held in a cache, it will have a -credibility rating indicating that the data came from the parent -(unless the parent and child share servers). When data about the same -name arrives from the child, with a higher credibility, the newly -arrived data MUST NOT cause the cache to remove the SEC RR. - -6. IANA Considerations - -IANA is requested to assign this RR an type parameter for DNS, and to -assign the indicated option numbers and values when requests are -approved. The procedure for requesting new options and values will be -defined in future versions of this specfication. - -7. Security Considerations - -This record is designed to address the concerns of securing delegation -points and resolving the security of DNS answers. This record is -important to the security because it supplies needed information and -eases the burden of security on the DNS. - -The SEC RR does require one piece of additional information not -addressed to date to be communicated from the parent to the child. -This is the signature policy. This will be needed in the operations -documents. - -Editorial Note: This document would benefit by a companion document -describing the process of evaluating the signatures in DNS. Such a -document would provide clearer input to the security parameters field. - -8. Editorial Considerations - -Although somewhat detailed in this current description, this record is -still in the formative state. The -00 document has been quickly -written to test the waters for interest. - -9. References - -RFC 2535 is the prime DNSSEC definition. RFC 2181 is the Clarify -document. EDNS0 reference needed... - -Expires December 25, 1999 [Page 11] -Internet Draft June 25, 1999 - -10. Acknowledgements - -This record is a successor to the Zone Key Referral, originally -promoted by John Gilmore and Jerry Scharf. A DNSSEC workshop -sponsored by the NIC-SE in May 1999 provided the enlightenment that -expanded the Zone Key Referral into the SEC RR proposal. - -11. Author's Addresses - -Edward Lewis Jerry Scharf Olafur Gudmundsson -NAI Labs Internet Software Consortium NAI Labs -3060 Washington Road 950 Charter St 3060 Washington Rd -Glenwood, MD 21738 Redwood City, CA 94063 Glenwood, MD 21738 -+1 443 259 2352 +1 650 779 7060 +1 443 259 2389 - - -12. Full Copyright Statement - -Copyright (C) The Internet Society (1999). All Rights Reserved. - -This document and translations of it may be copied and furnished to -others, and derivative works that comment on or otherwise explain it -or assist in its implmentation may be prepared, copied, published and -distributed, in whole or in part, without restriction of any kind, -provided that the above copyright notice and this paragraph are -included on all such copies and derivative works. However, this -document itself may not be modified in any way, such as by removing -the copyright notice or references to the Internet Society or other -Internet organizations, except as needed for the purpose of -developing Internet standards in which case the procedures for -copyrights defined in the Internet Standards process must be -followed, or as required to translate it into languages other than -English. - -The limited permissions granted above are perpetual and will not be -revoked by the Internet Society or its successors or assigns. - -This document and the information contained herein is provided on an -"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING -TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING -BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION -HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF -MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." - -Expires December 25, 1999 [Page 12] diff --git a/doc/expired/draft-ietf-dnsind-sigalgopt-00.txt b/doc/expired/draft-ietf-dnsind-sigalgopt-00.txt deleted file mode 100644 index c27dd9891c..0000000000 --- a/doc/expired/draft-ietf-dnsind-sigalgopt-00.txt +++ /dev/null @@ -1,164 +0,0 @@ -Network Working Group R. Austein -draft-ietf-dnsind-sigalgopt-00.txt On Sabbatical - P. Vixie - Internet Software Consortium - October 1999 - - - DNS SIGALGOPT - - -Status of this document - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - - - The list of Internet-Draft Shadow Directories can be accessed at - - - Distribution of this document is unlimited. Please send comments to - the namedroppers@internic.net mailing list. - -Abstract - - This document describes a mechanism for conserving packet space in a - DNS response message in the presence of multiple DNSSEC signature - algorithms. - -Motivation and Scope - - DNSSEC [DNSSEC] specifies a general framework for attaching - cryptographic signatures to DNS resource records. The framework - includes provisions for multiple signature protocols, possibly even - on a per-name basis. While this open-ended framework is good and - useful, it poses a problem when multiple signature protocols are in - use and DNS message sizes are limited by the underlying UDP transport - packet size. EDNS0 [EDNS0] provides a way to specify a larger - - - -Austein & Vixie Expires 18 April 2000 [Page 1] - -draft-ietf-dnsind-sigalgopt-00.txt October 1999 - - - payload size, but this still does not entirely solve the problem for - large RRsets. Worse, in cases where multiple signature algorithms - generate a response packet so large that it must be truncated, the - signatures that fit into the truncated response will be useless if - the resolver doesn't know how to verify signatures generated with - that algorithm. - - This note proposes a way for a resolver to indicate which signature - algorithms it understands to a name server in the form of an ordered - list. When this mechanism is in use, the name server can conserve - packet space by (a) not sending signatures with algorithms that the - resolver will not understand, and (b) not sending multiple signatures - for the same resource records. - -Mechanism - - [DNSSEC] SIG RRs include a one-octet code indicating the algorithm - associated with a particular signature. The SIGALGOPT option defined - below allows the resolver to specify an ordered list of signature - algorithms using the same one-octet codes that DNSSEC uses. - - SIGALGOPT is encoded n the variable RDATA part of the OPT pseudo-RR - in the DNS request (see [EDNS0]). - - The OPTION-CODE for SIGALGOPT is [TBD]. - - The OPTION-DATA for SIGALGOPT is an ordered list of the one-octet - codes used by DNSSEC. - - If the SIGALGOPT option in a query specifies multiple signature - algorithms and signatures using more than one of those algorithms are - available in the zone, the server must respond with the signatures - corresponding to the first algorithm on the SIGALGOPT list that - matches, omitting any signatures corresponding to the remaining - algorithms. - - We have deliberately not provided a mechanism to return all the - matching signatures, because the purpose of the SIGALGOPT mechanism - is to minimize packet size. If the resolver wants to see all - available signatures, it should just leave off the SIGALGOPT option - entirely. - -Security Considerations - - Good question. What horrible things could a bad guy do by - creating/altering/deleting SIGALGOPT? Are any of the possible - attacks more interesting than denial of service? - - - - -Austein & Vixie Expires 18 April 2000 [Page 2] - -draft-ietf-dnsind-sigalgopt-00.txt October 1999 - - -IANA Considerations - - SIGALGOPT will need an option code. - - The signature algorithm codes themselves are borrowed from DNSSEC and - do not create any new issues for IANA. - -References - - [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and - facilities", RFC 1034, November 1987. - - [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation - and specification", RFC 1035, November 1987. - - [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - -Author's addresses: - - Rob Austein - On Sabbatical - sra@hactrn.net - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - +1 650 779 7001 - vixie@isc.org - - - - - - - - - - - - - - - - - - -Austein & Vixie Expires 18 April 2000 [Page 3] diff --git a/doc/expired/draft-ietf-dnsind-test-tlds-13.txt b/doc/expired/draft-ietf-dnsind-test-tlds-13.txt deleted file mode 100644 index f0315eccbf..0000000000 --- a/doc/expired/draft-ietf-dnsind-test-tlds-13.txt +++ /dev/null @@ -1,290 +0,0 @@ - -INTERNET-DRAFT Reserved TLDs - February 1999 - Expires August 1999 - - - - - Reserved Top Level DNS Names - -------- --- ----- --- ----- - - Donald E. Eastlake 3rd - Aliza R. Panitz - - - - - Status of This Document - - This draft is file name draft-ietf-dnsind-test-tlds-13.txt. - Distribution of this document is unlimited. Comments should be sent - to the DNS mailing list or to the - authors. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - - - - - - - - - - - - - - - -D. Eastlake, A. Panitz [Page 1] - - -INTERNET-DRAFT Reserved TLDs - - -Abstract - - To reduce the likelihood of conflict and confusion, a few top level - domain names are reserved for use in private testing, as examples in - documentation, and the like. In addition, a few second level domain - names reserved for use as examples are documented. - - - -Table of Contents - - Status of This Document....................................1 - - Abstract...................................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. TLDs for Testing, & Documentation Examples..............3 - 3. Reserved Example Second Level Domain Names..............4 - 4. IANA Considerations.....................................4 - 5. Security Considerations.................................4 - - References.................................................5 - Authors Addresses..........................................5 - Expiration and File Name...................................5 - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake, A. Panitz [Page 2] - - -INTERNET-DRAFT Reserved TLDs - - -1. Introduction - - The global Internet Domain Name System is documented in [RFC 1034, - 1035, 1591] and numerous additional Requests for Comment. It defines - a tree of names starting with root, ".", immediately below which are - top level domain names such as ".com" and ".us". Below top level - domain names there are normally additional levels of names. - - - -2. TLDs for Testing, & Documentation Examples - - There is a need for top level domain (TLD) names that can be used for - creating names which, without fear of conflicts with current or - future actual TLD names in the global DNS, can be used for private - testing of existing DNS related code, examples in documentation, DNS - related experimentation, invalid DNS names, or other similar uses. - - For example, without guidance, a site might set up some local - additional unused top level domains for testing of its local DNS code - and configuration. Later, these TLDs might come into actual use on - the global Internet. As a result, local attempts to reference the - real data in these zones could be thwarted by the local test - versions. Or test or example code might be written that accesses a - TLD that is in use with the thought that the test code would only be - run in a restricted testbed net or the example never actually run. - Later, the test code could escape from the testbed or the example be - actually coded and run on the Internet. Depending on the nature of - the test or example, it might be best for it to be referencing a TLD - permanently reserved for such purposes. - - To safely satisfy these needs, four domain names are reserved as - listed and described below. - - .test - .example - .invalid - .localhost - - ".test" is recommended for use in testing of current or new DNS - related code. - - ".example" is recommended for use in documentation or as - examples. - - ".invalid" is intended for use in online construction of domain - names that are sure to be invalid and which it is obvious at a glance - are invalid. - - The ".localhost" TLD has traditionally been statically defined - - -D. Eastlake, A. Panitz [Page 3] - - -INTERNET-DRAFT Reserved TLDs - - - in host DNS implementations as having an A record pointing to the - loop back IP address and is reserved for such use. Any other use - would conflict with widely deployed code which assumes this use. - - - - -3. Reserved Example Second Level Domain Names - - The Internet Assigned Numbers Authority (IANA) also currently has the - following second level domain names reserved which can be used as - examples. - - example.com - example.net - example.org - - - -4. IANA Considerations - - IANA has agreed to the four top level domain name reservations - specified in this document and will reserve them for the uses - indicated. - - - -5. Security Considerations - - Confusion and conflict can be caused by the use of a current or - future top level domain name in experimentation or testing, as an - example in documentation, to indicate invalid names, or as a synonym - for the loop back address. Test and experimental software can escape - and end up being run against the global operational DNS. Even - examples used "only" in documentation can end up being coded and - released or cause conflicts due to later real use and the possible - acquisition of intellectual property rights in such "example" names. - - The reservation of several top level domain names for these purposes - will minimize such confusion and conflict. - - - - - - - - - - - - -D. Eastlake, A. Panitz [Page 4] - - -INTERNET-DRAFT Reserved TLDs - - -References - - RFC 1034 - P. Mockapetris, "Domain names - concepts and facilities", - 11/01/1987. - - RFC 1035 - P. Mockapetris, "Domain names - implementation and - specification", 11/01/1987. - - RFC 1591 - J. Postel, "Domain Name System Structure and Delegation", - 03/03/1994. - - - -Authors Addresses - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road, RR #1 - Carmel, NY 10512 - - Telephone: +1 914-276-1668(h) - +1 914-784-7913(w) - FAX: +1 914-784-3833(3) - email: dee3@us.ibm.com - - - Aliza R. Panitz - 500 Stamford Dr. No. 310 - Newark, DE 19711 USA - - Telephone: +1 302-738-1554 - email: buglady@fuschia.net - - - -Expiration and File Name - - This draft expires August 1999. - - Its file name is draft-ietf-dnsind-test-tlds-13.txt. - - - - - - - - - - - - -D. Eastlake, A. Panitz [Page 5] - diff --git a/doc/expired/draft-ietf-dnsind-verify-00.txt b/doc/expired/draft-ietf-dnsind-verify-00.txt deleted file mode 100644 index 1837fe9e7f..0000000000 --- a/doc/expired/draft-ietf-dnsind-verify-00.txt +++ /dev/null @@ -1,158 +0,0 @@ - - - INTERNET-DRAFT Mark Andrews (ISC) - February 1999 - - - Verifying Resource Records Without Knowing Their Contents - - - Status of This Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - Abstract - - DNSSEC [RFC2065] provides a mechanism to cryptographically verify a - DNS resource record provided we can get it into canonical form. - - The problem is how do we do this without knowing the contents of all - resource record types? - - This document provides one possible solution to this problem. - - 1 - Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - - Expires August 1999 [Page 1] - - INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998 - - - 2 - Method - - In order to be able to canonicalise a resource record a resolver needs - to know where in the data domain names exist so that the resolver can - decompress the domain names and convert the uppercase ASCII in ordinary - labels to lowercase prior to the data being feed into the encryption - routines. - - This document propose that all new resource record types defined MUST - have a header at the start of the data section locating where the domain - names are in the data section. A new resource record for the purpose of - this document is any type NOT referenced in section 3 Old Types. Meta - queries such as MAILA (254), MAILB (253), AXFR (252) and IXFR (251) are - not covered by this document as they do not return data of this type. - - This table would be a series of unsigned 16 bit words in network order. - The first word contains the length of the table as 16 bit words not - counting the first word. Subsequent words contain the offset from the - start of the data to the start of relevent domain name in the data - assuming all domain names are uncompressed. Offsets in the table are in - the same order as domain names in the data. - - 3 Old Types - - The following types are deemed old and are NOT covered by this document. - A (1), NS (2), MD (3), MF (4), CNAME (5), SOA (6), MB (7), MG (8), MR - (9), NULL (10), WKS (11), PTR (12), HINFO (13), MINFO (14), MX (15), TXT - (16), RP (17), AFSDB (18), X25 (19), ISDN (20), RT (21), NSAP (22), - NSAP-PTR (23), SIG (24), KEY (25), PX (26), GPOS (27), AAAA (28), LOC - (29), NXT (30), EID (31), NIMLOC (32), SRV (33), ATMA (34), NAPTR (35), - KX (36), CERT (37), A6 (38), DNAME (39), UINFO (100), UID (101), GID - (102), UNSPEC (103), OPT (XXX), TKEY (249) and TSIG (250). - - - 4 Security Considerations - - It is believed that this document does not introduce any significant - additional security threats other that those that already exist when - using data from the DNS but rather enhances security by allowing new - resource record types to be checked by security aware resolvers. - - 5 IANA Considerations - - This document places no requirements apon IANA. - - - - - Expires August 1999 [Page 2] - - INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998 - - - References - - - [RFC2065] - Eastlake, D. 3rd. and Kaufman, C,. "Domain Name System Security - Extensions," RFC 2065, January 1997 - - - [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Lev­ - els," BCP 14, RFC 2119, March 1997 - - - Author's Address - - Mark Andrews - Internet Software Consortium - 1 Seymour St. - Dundas Valley - NSW 2117 - AUSTRALIA - +61 2 9871 4742 - - - - - - - - - - - - - - - - - - - - - - - - - - - Expires August 1999 [Page 3] - diff --git a/doc/expired/draft-ietf-dnssec-ar-00.txt b/doc/expired/draft-ietf-dnssec-ar-00.txt deleted file mode 100644 index fc1c3a332a..0000000000 --- a/doc/expired/draft-ietf-dnssec-ar-00.txt +++ /dev/null @@ -1,618 +0,0 @@ - - - - - -Domain Name System Security Working Group R. Watson -INTERNET DRAFT November 1997 - Expires in six months - - - DNSsec Authentication Referral Record (AR) - - -Status of this Document - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), - munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or - ftp.isi.edu (US West Coast). - -Abstract - - Authentication Referrals allow DNS to refer to authentication - mechanisms that supplement or replace the KEY RRs of DNSsec. - - Five Authentication Service types are defined: DNSsec, Kerberos IV, - Kerberos V, Network Information Service (NIS+), and Radius. - - - - - - - - - - - - - - - - - - -Watson [Page 1] - -Internet DRAFT DNSsec Authentication Referral November 1997 - - -1. Introduction - - Domain Name System Security [DNSSEC] extends the Domain Name System - (DNS) [RFC1034, RFC1035] to provide for data origin authentication, - public key distribution, and query and transaction authentication, - all based on public key cryptography and public key based digital - signatures. In many organizations, it is desirable to provide a - centralized source for authentication data, especially in - environments where multiple systems are used (for example, KerberosIV - and NIS+). Systems have been defined for distributing user - information in the DNS name-space [HESIOD], but DNS has traditionally - lacked the security necessary to safely distribute sensitive - authentication information. Authentication Referrals use DNSsec's - authenticated data capabilities to distribute mappings from entities - to authentication mechanisms. - -1.1 Keywords Used - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. - -1.2 Definition of Terms - - Service Desiring Authentication (SDA): A service requiring a user to - authenticate before providing access. For example, the login program - on a UNIX host is an SDA. - - Authentication Service: A type of authentication system that allows - an SDA to verify the identity of a Client communicating with the SDA. - Services are typically accessed using an Authentication Server such - as a KerberosIV or Radius server. In a referral, both the type of - authentication service and the server address are provided. - - Client: An entity that wishes to connect to a service, in particular, - to an SDA. Clients are identified using a unique DNS Fully Qualified - Domain Name (FQDN), which contains records providing information on - verifying authentication. Authentication Client may refer to both - humans and hosts in this document. - - Authentication Username: In the event that an Authentication Service - is used, the Username may differ from the Client's FQDN in DNS. - - Authentication Realm: Some distributed authentication systems allow - for multiple "realms" in which authentication takes place. Realms - typically represent a set of identities and services over which a - single authority is responsible for authentication. Where - appropriate, referrals contain the name of the realm against which - - - -Watson [Page 2] - -Internet DRAFT DNSsec Authentication Referral November 1997 - - - they should be made. - - Authentication Server: Many authentication systems rely on a - centralized database, which may be found on the Authentication - Server. This database can be identified using the DNS FQDN for the - host. It is assumed that the Authentication Service type will - provide all other information necessary to communicate with the - Authentication Server. - -1.3 Authentication in DNSsec - - DNSsec provides a mechanism for the authentication of entities it - describes via KEY records containing public keys. This is adequate - for IP Security [IPSEC] and other key-based protocols (such as Secure - Shell [SSH]), but it is not useful for individual user - authentication. Typically such an authentication process involves - the encryption of data using the Client's public key (extracted from - DNSsec), which must then be decrypted by the Client and returned in - some other form (often encrypted with the SDA's public key to protect - both the challenge and the response). Users may be reluctant to - replace their traditional alpha-numeric password with 514-bit private - keys and then perform computation-intensive key manipulation and - signature-operations in their heads. While devices are available - that perform this function in a more accessible manner, they are not - yet mainstream, and a standard has not yet been proposed for - interaction between these devices and DNSsec-based authentication - systems. - - Existing distributed authentication systems commonly rely on a - password (shared secret) or a variable challenge-response mechanism - using a system-specific protocol. For example, both KerberosIV - [KERBEROSIV] and Radius [RADIUS] use protocols employing different - packet formats and privacy mechanisms. Because DNS was designed as a - publicly accessible distributed database, no mechanism for the - distribution of private data is provided, which makes the inclusion - of password data in the system both difficult and inappropriate. - - The AR resource record (RR type TBD) allows DNSsec to refer an SDA to - an Authentication Service when direct authentication based on the KEY - RR cannot be used. - -2. Authentication Referral Resource Record Format - - To provide storage for authentication referral information, a new RR - type is defined with the mnemonic AR. More than one AR RR MAY exist - in an RRset; the RRset MUST contain the complete list of - authentication mechanisms allowed for the DNS name. - - - - -Watson [Page 3] - -Internet DRAFT DNSsec Authentication Referral November 1997 - - -2.1 Record Format - - NAME The domain name of the entity to be authenticated. - TYPE AR (TBD) - CLASS IN (HS may also be appropriate) - TTL (as appropriate) - RdLen (variable) - RDATA - - Field Name Data Type Notes - ------------------------ ----------- ------------------------- - Authentication Server dname FQDN of the server that - will provide - authentication data - Authentication Realm dname Realm in which - authentication occurs - Authentication Service 16-bit int Authentication Service - Type as defined in 2.3 - Username Length 16-bit int Length of Authentication - Username string in octets - Authentication Username 8-bit int[] UTF-8 encoded name whose - use is defined by the - service type. - Other Data undefined Ignore any following - RDATA - - All integer values are stored in network byte order. The - Authentication Username field is an octet stream of length Username - Length. - - Meaning of Authentication Realm, Authentication Server, - Authentication Username are specific to each Authentication Service - type. - -2.2 Text Representation - - A simple text representation for the AR RR might be: - - NAME. IN AR [Server] [Realm] [AuthMnemonic] [Username] - -2.3 Authentication Service Types - - Different Authentication Services types will be assigned numeric - value. New services MUST be registered with IANA.* A mnemonic is - associated with each type to simplify textual representation. - - - - - - -Watson [Page 4] - -Internet DRAFT DNSsec Authentication Referral November 1997 - - - Value Mnemonic Authentication Service Name - ------ ----------- --------------------------- - 0 DNSSEC DNSsec - 1 KERBEROS_V4 Kerberos IV - 2 KERBEROS_V5 Kerberos V - 3 RADIUS Radius - 4 NISPLUS NIS+ - - * A method for registration will be described in detail in a later - version of this document. - -2.3.1 DNSsec Referral - - It may be desirable to refer authentication to another FQDN. For - example, an organization may have several user zones defined, but one - Client may exist in several of them. Rather than requiring separate - AR RRs, authentication may be forwarded to one canonical AR RR - containing other useful data, or to a record with a KEY RR. Some - fields defined across the AR record are not used: - - Field Name Value - ------------------------ ---------------------------------- - Authentication Server (empty) - Authentication Realm (empty) - Authentication Service 0 (DNSSEC) - Username Length (as appropriate) - Authentication Username FQDN of the entity referred to - - When using DNSsec referrals, it is important to avoid referral loops. - The appropriate interpretation order of coexisting KEY and AR records - is discussed in section 3. Referrals may point to either another AR - record or a record with authentication KEYs. If a DNSsec referral - record points to a non-existent name or no authentication information - is available at that name, the authentication MUST fail. - -2.3.1.1 DNSsec Referral Example - - NAME ROBERT.USER.WATSON.ORG. - TYPE AR (TBD) - CLASS IN - TTL 3600 - RdLen (as appropriate) - - - - - - - - - -Watson [Page 5] - -Internet DRAFT DNSsec Authentication Referral November 1997 - - - RDATA - - Field Name Value - ------------------------ ---------------------------------- - Authentication Server (empty) - Authentication Realm (empty) - Authentication Service 0 (DNSSEC) - Username Length 19 - Authentication Username rnw.andrew.cmu.edu. - - A textual representation of this record in zone USER.WATSON.ORG would - appears as: - - ROBERT IN AR (. . DNSSEC "rnw.andrew.cmu.edu.") - -2.3.2 Kerberos IV Referral - - The Authentication Username is a "principal.instance" pair where - instance may be alphanumeric, null, or the wildcard "*". For - authentication against user robert in realm WATSON.ORG, an - appropriate Authentication Username would be "robert.", indicating - that no instance is to be used. To require authentication against - another instance, the form "robert.admin" is appropriate. In some - circumstances, a wild-card Username entry might be used, "robert.*", - indicating that the Client MAY be prompted for a specific instance. - - Field Name Value - ----------------------- -------------------------------------- - Authentication Server Kerberos IV Server - Authentication Realm Kerberos IV Realm - Authentication Service 1 (Kerberos IV) - Username Length (length of Username in octets) - Authentication Username Kerberos IV principal.instance - -2.3.2.1 Kerberos IV Referral Example - - NAME ROBERT.USER.WATSON.ORG. - TYPE AR (TBD) - CLASS IN - TTL 3600 - RdLen (as appropriate) - - - - - - - - - - -Watson [Page 6] - -Internet DRAFT DNSsec Authentication Referral November 1997 - - - RDATA - - Field Name Value - ----------------------- ---------------------- - Authentication Server KERBEROS.WATSON.ORG. - Authentication Realm WATSON.ORG. - Authentication Service 1 (KERBEROS_V4) - Username Length 12 - Authentication Username robert.admin - - A textual representation of this record in zone USER.WATSON.ORG would - appear as: - - ROBERT IN AR (KERBEROS.WATSON.ORG. WATSON.ORG. - KERBEROS_V4 "robert.admin") - -2.3.3. Kerberos V Referral - - The specifics of this type will be specified in a future draft. It - is expected that Kerberos V referrals will be almost identical to - Kerberos IV, but with the "." principal/instance separator replaced - with a "/". - -2.3.4 Radius Referral - - Field Name Value - ----------------------- --------------------------------- - Authentication Server Radius Server - Authentication Realm (empty) - Authentication Service 3 (RADIUS) - Username Length (as appropriate) - Authentication Username Radius Username - -2.3.4.1 Radius Referral Example - - NAME ROBERT.USER.WATSON.ORG. - TYPE AR (TBD) - CLASS IN - TTL 3600 - RdLen (as appropriate) - - - - - - - - - - - -Watson [Page 7] - -Internet DRAFT DNSsec Authentication Referral November 1997 - - - RDATA - - Field Name Value - ----------------------- ---------------------- - Authentication Server RADIUS.WATSON.ORG. - Authentication Realm (empty) - Authentication Service 5 (RADIUS) - Username Length 6 - Authentication Username robert - - A textual representation of this record in zone USER.WATSON.ORG would - appear as: - - ROBERT IN AR (RADIUS.WATSON.ORG. . - RADIUS "robert") - -2.3.5 NIS+ Referral - - NIS+ referral will be documented in a separate document. Due to the - complex interactions between NIS and DNS, there are additional - concerns that must be addressed in greater detail than is appropriate - here. - -2.4 DNS Server Handling of the AR Resource Record - - When returning an AR RR as part of an RRset, a DNS server MAY include - Additional Records [RFC1034: Section 3.7] that it anticipates the SDA - requires. - -3. AR Resource Record Evaluation - - When performing a lookup on a Client's DNS entry, a signed RRset is - returned containing KEY RRs, SIG RRs, other data, and possibly an AR - RR. If KEY RRs are present and are permitted for use in user - authentication, public/private key authentication may take place. - Alternatively, the SDA may choose a different authentication - mechanism from the list of AR RRs. - -3.1 Authentication Rules - - Multiple AR RRs of different Authentication Service types may exist. - Similarly, multiple RRs of the same type may exist in an RRset. When - multiple RRs are returned, the SDA must select some subset of these - to try. A combination of local policy and and the desire for load - balancing determines the correct use of these RRs. - - Where multiple AR RRs of different Authentication Service type exist, - one of the available Services SHOULD be selected. This choice could - - - -Watson [Page 8] - -Internet DRAFT DNSsec Authentication Referral November 1997 - - - be made by local site policy (i.e., only to accept authentication by - Kerberos, or to not allow AR referral to another DNSsec name), or - with Client interaction (the user is prompted for the mechanism they - wish to authenticate against). If one Authentication Service fails, - the choice to retry against the same service or against different - Services should be made in accordance with local security policy. - - Where multiple RRs with the same Authentication Service Type exist - but different Authentication Realm or Username are present, the SDA - should make a choice in accordance with local site policy. For - example, a site might choose only to accept authentication to their - own Kerberos realm. - - Load balancing is desirable in the event that multiple RRs with the - same Authentication Realm, Authentication Service, and Username are - present. Such sets of related AR RRs may be considered to be - redundant records. DNS round-robin may be relied upon to reorder - them. - -3.1.1 Successful Authentication - - If the chain of signatures validates the initial Client records as - well as any further records referenced if a DNSsec referral is - performed, an authentication attempt MAY be performed. If an - attempted authentication succeeds, the SDA MUST accept the - authentication as valid. - -3.1.2 Failure in Authentication - - If any break in the signature chain occurs in DNSsec verification of - the records required for authentication, the authentication SHOULD - fail. If alternate mechanisms exist for authenticating the - Authentication Server, they MAY be used. - - If an Authentication Service is selected, and the authentication - fails for non-technical reasons [different word?], then the - authentication MUST fail. If a technical failure occurs (such as - being unable to contact the Authentication Server), the SDA MAY - select another AR record to attempt or MAY retry on the same server. - If no further AR records are present and any retries have also - failed, then the authentication MUST fail. - -4. Security Considerations - - It is expected that some system of access control will be used to - determine what, if any, services are provided to the authenticated - Client. - - - - -Watson [Page 9] - -Internet DRAFT DNSsec Authentication Referral November 1997 - - -4.1 DNSsec Use - - Spoofing of AR RRs could result in unauthorized authentication. - DNSsec MUST be used to verify the authenticity of the AR RRs, as well - as the chain to the DNS root. For example, if an AR refers to - Kerberos IV, DNSsec MUST be used to verify the retrieval of the - Client's AR record, and the retrieval of the Kerberos IV Server's IP - address from Authentication Server FQDN. - -4.2 The Weakest Link - - While DNSsec provides strong cryptography to protect data - authenticity and to allow expiration, many distributed security - mechanisms are not as strong. For example, while an AR record may be - valid, an NIS server connection may be spoofed, hijacked, - eavesdropped, etc. - -4.3 Local Site Policy - - Local site policy is relied upon for a number of key decisions in the - authentication process. For example, before attempting to follow an - AR chain, the SDA must first confirm that the initial name provided - is allowed to authenticate to it. It must also determine which - authentication service types in the AR list for the name are - appropriate for use. An SDA MAY choose not to accept authenticatino - to a weak Authentication Service. The definition of weak SHOULD be - defined in a local site policy. - - A site might accept initial attempts at authentication to - *.user.watson.org. On a successful and verified referral, it might - then be willing to accept authentication against any strong - Authentication Service (e.g., KerberosIV or KerberosV), but not - against weaker services (e.g., NIS). - - If AR information can be verified externally, do so. For example, if - Kerberos IV server to realm mapping information exists in a local - krb.conf, consistency should be verified. - - Correct logging practice, as well as approaches for dealing with - various types of failures given the varied mechanisms provided may - also involve significant local determination. All authentication - events SHOULD be logged. Selective reporting of errors to the Client - may also improve security. - - - - - - - - -Watson [Page 10] - -Internet DRAFT DNSsec Authentication Referral November 1997 - - -5. References - - [RFC1034] P. Mockapetris, ``Domain Names - Concepts and - Facilities,'' RFC 1034, ISI, November 1987. - - [RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification,'' RFC 1034, ISI, November 1987. - - [DNSSEC] D. Eastlake, C. Kaufman, ``Domain System Security - Extensions,'' RFC 2065, CyberCash & Irix, January 1997. - - [HESIOD] S. Dryer, ``The Hesiod Name Server,'' MIT, January 1988. - - [IPSEC] R. Atkinson, ``Security Architecture for the Internet - Protocol,'' RFC 1825, Navy Research Laboratory, August - 1995. - - [SSH] M. Ylonen, T. Kivinen, M. Saarinen, ``SSH Transport Layer - Protocol,'' draft-ietf-secsh-transport-02.txt, SSH, - October 1997. - - [KERBEROSIV] S. Miller, B. Neuman, J. Schiller, J. Saltzer, ``Kerberos - Authentication and Authorization System,'' MIT, December - 1988. - - [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, ``Remote - Authentication Dial In User Service (RADIUS),'' RFC 2138, - April 1997. - -6. Author's Address - - Robert Watson - Carnegie Mellon University - SMC 4105 - PO Box 3015 - Pittsburgh, PA 15230 - - Phone: (412) 862-2696 - - Email: robert+ietf@cyrus.watson.org - - - - - - - - - - - -Watson [Page 11] - diff --git a/doc/expired/draft-ietf-dnssec-as-map-05.txt b/doc/expired/draft-ietf-dnssec-as-map-05.txt deleted file mode 100644 index caaf932ca7..0000000000 --- a/doc/expired/draft-ietf-dnssec-as-map-05.txt +++ /dev/null @@ -1,522 +0,0 @@ - -INTERNET-DRAFT Mapping AS Number into the DNS - July 1997 - Expires January 1998 - - - - - Mapping Autonomous Systems Number into the Domain Name System - ------- ---------- ------- ------ ---- --- ------ ---- ------ - - Donald E. Eastlake 3rd - - - -Status of This Document - - This draft, file name draft-ietf-dnssec-as-map-05.txt, is intended to - be become a Best Current Practice RFC concerning utilization of the - Domain Name System (DNS) to support routing security. Distribution of - this document is unlimited. Comments should be sent to the DNS - Security Working Group mailing list or to the - author. - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - To learn the current status of any Internet-Draft, please check the - 1id-abstracts.txt listing contained in the Internet-Drafts Shadow - Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), - nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), - munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -Abstract - - One requirement of secure routing is that independent routing - entities, such as those identified by Internet Autonomous System - Numbers, be able to authenticate messages to each other. Additions - have developed to the Domain Name System to enable it to be used for - authenticated public key distribution [RFC 2065]. This draft maps - all Autonomous System numbers into DNS Domain Names so that the DNS - security can be used to distribute their public keys. - - [Changes from previous version are to accommodate AS numbers larger - than 16 bits and to delegate on decimal boundaries rather than binary - boundaries.] - - - -Acknowledgements - - The contributions of the following persons, listed in alphabetic - order, to this draft are gratefully acknowledged: - - Ran Atkinson - - Christian Huitema - - Tony Li - - Michael A. Patton. - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -Table of Contents - - Status of This Document....................................1 - - Abstract...................................................2 - Acknowledgements...........................................2 - - Table of Contents..........................................3 - - 1. Introduction............................................4 - - 2. Autonomous System Number Mapping........................5 - - 3. Meaning of RRs..........................................6 - - 4. Security Considerations.................................8 - References.................................................8 - Author's Address...........................................8 - Expiration and File Name...................................9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -1. Introduction - - There are a number of elements required to secure routing in the - Internet. One of these is a way that independently operated routing - domains be able to authenticate messages to each other. - - Sharing a private symmetric key between each pair of such domains is - impractical. Assuming 2**16 Autonomous System routing entities, - which is what is allowed in current versions of BGP, [RFC 1771], this - would imply approximately 2**31 pairs, an impractical number of keys - to securely generate, install, and periodically replace. - - The solution is to use public key technology whereby each routing - domain has a private key it can use to sign messages. Other domains - that know the corresponding public key can then authenticate these - messages. Such authenticated messages can be used to set up and - maintain efficient symmetric keys on an as needed basis. - - But how do the domains securely obtain the Autonomous System number - to public key mapping? - - Extensions have been developed for the Domain Name System that enable - it to be conveniently used for authenticated public key distribution - [RFC 2065]. A variety of key types can be supported. All that is - required is a mapping of Autonomous System numbers into domain names, - which is provided by this draft. - - It should be noted that the public keys retrieved from DNS will - likely be used primarily to authenticate initial connection set up - messages. Autonomous Systems that need to converse with any - frequency will probably negotiate more efficient symmetric session - keys. - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -2. Autonomous System Number Mapping - - Autonomous System (AS) numbers are usually written as decimal number - and when blocks of AS numbers are delegated to a registry, it is - normally on decimal boundaries. Their current use in BGP is limited - to 16 bits providing a maximum value of 65,535. For example, ANS is - autonomous system 690. However, there is no inherent size limit in - the AS concept. AS numbers are mapped into a domain name as - described below. - - Write the AS number, as usual, as a decimal number without any - "thousands" punctuation. If it is less than 5 digits, add leading - zeros to bring it up to five digits. Then simply reverse the order - of the digits, put a period between them, and append ".length.in- - as.arpa" where "length" is the number of AS digits. This mapping is - analogous to the IPv4 address mapping into the in-addr.arpa DNS - domain. - - Thus the domain name correspond to Autonomous System 690 (decimal) is - - 0.9.6.0.0.5.in-as.arpa. - - the domain corresponding to the largest possible AS number in BGP is - - 5.3.5.5.6.5.in-as.arpa. - - the domain corresponding to AS number 65,000 is - - 0.0.0.5.6.5.in-as.arpa. - - and the domain correspond to a hypothetical future greater than 16 - bit AS number 1,234,567 is - - 7.6.5.4.3.2.1.7.in-as.arpa. - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -3. Meaning of RRs - - The following guidance is given for some resource record (RR) types - that could be stored under the names mapped from AS numbers. The KEY - RR is given first, followed by the SIG RR, the NXT RR, and then some - additional RR types in alphabetic order. - - KEY: This type of RR associates a public key with the owner name - which, in this case, corresponds to an Autonomous System (AS). Under - DNS security as proposed in RFC 2065 the KEY RR can be used to store - a variety of digital keys. A KEY for use in securing routing - communications between ASs will have the end entity flag bit on, the - authentication use prohibited flag bit off, and a protocol byte or - flag bit indicating routing communications use. Such a public key can - be used to authenticate communications with or between ASs. The - existence of such KEY RRs in the primary reason for mapping AS names - into the DNS. - - SIG: The SIG signature resource record authenticates the RRs - that it signs as described in RFC 2065. Assuming the signer who - generated the SIG is trustworthy, such as the in-as.arpa zone owner, - then the signed RRs can be trusted. - - NXT: An NXT RR is used in DNS security to provide authenticated - denial of the existence of types and names as described in RFC 2065. - - A, AAAA: Type A or AAAA RRs SHOULD NOT be placed at AS nodes. - AS domain names are reserved for Autonomous Systems only and should - NOT be used for a host or any type of end entity other than an - Autonomous System. - - CNAME: This type of RR is an alias pointing to another domain - name. An AS could have a CNAME pointing to a different AS but this - is not likely to be very useful as AS RRs will normally be looked up - when the AS number is actually encountered in use. - - MX: There is no special use for an MX RR for an AS name. It - could point to a host that would accept mail related to that AS. - - NS: The presence of NS records under an AS name means that it - has been carved out as a subzone. This gives the AS complete control - over the zone refresh parameters and control over the creation of - inferior names. No special meaning is currently assigned to such - inferior names so, although this is not advised, they could be used - for hosts or whatever. In this case, the will also be a zone KEY at - the AS name, indicated by having the zone flag bit on. - - PTR: The part of the forward domain tree that administratively - corresponds to the AS SHOULD be indicated by a PTR RR. If some - entity, say example.xx, has several ASs, there would be PTRs to - - -Donald E. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - - example.xx from several names in the in-as.arpa hierarchy. - - RP: A Responsible Person RR SHOULD appear under each AS name - telling you who you should contact in the case of problems with that - AS - - TXT: Text RRs can be used for comments, postal address, or - similar notes under an AS name. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -4. Security Considerations - - This document concerns a means to map Internet Autonomous System - numbers into the Domain Name System (DNS) so that DNS can be used to - provide secure distribution of Autonomous System's public keys. The - security of the resulting AS to key mapping is dependent on the - security of the DNS security extensions and of the DNS zone where the - key is stored. - - The most obvious way of using the AS keys retrieved from DNS is to - authenticate communications with a directly connected AS. However, - this does not prove that any routing information exchanged is - actually correct and note that routing information communicated over - this secured path may be indirectly forwarded from or to yet other - ASs. - - - -References - - [RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris, - November 1987 - - [RFC 1035] - Domain Names - Implementation and Specifications, P. - Mockapetris, November 1987. - - [RFC 1771] - Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP- - 4)", 03/21/1995. - - [RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C. - Kaufman, January 1997. - - - -Author's Address - - Donald E. Eastlake 3rd - CyberCash, Inc. - 318 Acton Street - Carlisle, MA 01741 USA - - Telephone: +1 508 287 4877 - +1 703 620-4200 (main office, Reston, VA) - FAX: +1 508 371 7148 - EMail: dee@cybercash.com - - - - - - - -Donald E. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT Mapping AS Numbers into the DNS - - -Expiration and File Name - - This draft expires January 1998. - - Its file name is draft-ietf-dnssec-as-map-05.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 9] - diff --git a/doc/expired/draft-ietf-dnssec-indirect-key-01.txt b/doc/expired/draft-ietf-dnssec-indirect-key-01.txt deleted file mode 100644 index a4804b79f6..0000000000 --- a/doc/expired/draft-ietf-dnssec-indirect-key-01.txt +++ /dev/null @@ -1,464 +0,0 @@ - -INTERNET-DRAFT Indirect KEY RRs - November 1997 - Expires May 1998 - - - - Indirect KEY RRs in the Domain Name System - -------- --- --- -- --- ------ ---- ------ - - Donald E. Eastlake 3rd - - - -Status of This Document - - This draft, file name draft-ietf-dnssec-indirect-key-01.txt, is - intended to be become a Proposed Standard RFC. Distribution of this - document is unlimited. Comments should be sent to the DNSSEC mailing - list or to the author. - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - To learn the current status of any Internet-Draft, please check the - 1id-abstracts.txt listing contained in the Internet-Drafts Shadow - Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), - nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), - munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). - - - -Abstract - - RFC 2065 defines a means for storing cryptogrpahic public keys in the - Domain Name System. An additional code point is defined for the KEY - resource record (RR) algorithm field to indicate that the key itself - is not stored in the KEY RR but is pointed to by the KEY RR. - Encodings to indicate different types of key and pointer formats are - specified. - - - - - - - - -Donald E. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT Indirect KEY RRs - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - - 2. The Indirect KEY RR Algorithm...........................4 - 2.1 The Target Type Field..................................4 - 2.2 The Target Algorithm Field.............................5 - 2.3 The Hash Fields........................................5 - - 3. Performance Considerations..............................7 - 4. Security Considerations.................................7 - - References.................................................8 - Author's Address...........................................8 - Expiration and File Name...................................8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT Indirect KEY RRs - - -1. Introduction - - The Domain Name System (DNS) security extensions [RFC 2065] provide - for the general storage of public keys in the domain name system via - the KEY resource record (RR). These KEY RRs are used in support of - DNS security and may be used to support other security protocols. - KEY RRs can be associated with users, zones, and hosts or other end - entities named in the DNS. - - For reasons given below, in many cases it will be desireable to store - a key or keys elsewhere and merely point to it from the KEY RR. - Indirect key storage makes it possible to point to a key service via - a URL, to have a compact pointer to a larger key or set of keys, to - point to a certificate either inside DNS [see draft-ietf-dnssec- - certs-*.txt] or outside the DNS, and where appropriate, to store a - key or key set applicable to many DNS entries in some place and point - to it from those entries. - - However, to simplify DNSSEC implementation, this technique MUST NOT - be used for KEY RRs used in for verification in DNSSEC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Indirect KEY RRs - - -2. The Indirect KEY RR Algorithm - - Domain Name System (DNS) KEY Resource Record (RR) [RFC 2065] - algorithm number 252 is defined as the indirect key algorithm. This - algorithm MAY NOT be used for zone keys in support of DNS security. - All KEYs used in DNSSEC validation must be stored directly in the - DNS. - - When the algorithm byte of a KEY RR has thae value 252, the "public - key" portion of the RR is formated as follows: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | target type | target alg. | hash type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | hash size | hash (variable size) / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ - | / - / pointer (varible size) / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - - -2.1 The Target Type Field - - Target type specifies the type of the key containing data being - pointed at. - - Target types 0 and 65535 are reserved. - - Target type 1 indicates that the pointer is a domain name from which - KEY RRs [RFC 2065] should be retrieved. Name compression in the - pointer field is prohibited. - - Target type 2 indicates that the pointer is a null terminated - character string which is a URL [RFC 1738]. For exisiting data - transfer URL schemes, such as ftp, http, shttp, etc., the data is the - same as the public key portion of a KEY RR. (New URL schmes may be - defined which return multiple keys.) - - Target type 2 indicates that the pointer is a domain name from which - CERT RRs [draft-ietf-dnssec-certs-*.txt] should be retrieved. Name - compression in the pointer field is prohibiited. - - Target type 3 indicates that the pointer is a null terminated - character string which is a URL [RFC 1738]. For exisiting data - transfer URL schemes, such as ftp, http, shttp, etc., the data is the - same as the entire RDATA portion of a CERT RR [draft-ietf-dnssec- - - -Donald E. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Indirect KEY RRs - - - certs-*.txt]. (New URL schmes may be defined which return multiple - such data blocks.) - - Target type 4 indicates that the pointer is a null terminated - character string which is a URL [RFC 1738]. For exisiting data - transfer URL schemes, such as ftp, http, shttp, etc., the data is a - PKCS#1 format key. (New URL schmes may be defined which return - multiple keys.) - - The target types 5 through 255 are available for assignment by IANA. - - Target type 256 through 511 (i.e., 256 + n) indicate that the pointer - is a null terminated character string which is a URL [RFC 1738]. For - exisiting data transfer URL schemes, such as ftp, http, shttp, etc., - the data is a certificate of the type indicated by a CERT RR [draft- - ietf-dnssec-certs-*.txt] certificate type of n. That is, target - types 257, 258, and 259 are PKIX, SPKI, and PGP certificates and - target types 509 and 510 are URL and OID private certificate types. - (New URL schmes may be defined which return multiple such - certificates.) - - Target types 512 through 65534 are available for assignment by IANA. - - - -2.2 The Target Algorithm Field - - The algorithm field is as defined in RFC 2065. if non-zero, it - specifies the algorithm type of the target key or keys pointed. If - zero, it does not specify what algorithm the target key or keys apply - to. - - - -2.3 The Hash Fields - - If the indirecting KEY RR is retrieved from an appropriately secure - DNS zone with a resolver implementing DNS security, then there would - be a high level of confidence in the entire value of the KEY RR - including any direct keys. This may or may not be true of any - indirect key pointed to. If that key is embodied in a certificate or - retrieved via a secure protocol such as SHTTP, it may also be secure. - But an indirecting KEY RR could, for example, simply have an FTP URL - pointing to a binary key stored elsewhere, the retrieval of which - would not be secure. - - The hash option in algorithm 252 KEY RRs provides a means of - extending the security of the indirecting KEY RR to the actual key - material pointed at. By inclduing a hash in a secure indirecting RR, - this secure hash can be checked against the hash of the actual keying - - -Donald E. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Indirect KEY RRs - - - material - - Type Hash Algorithm - ---- -------------- - 0 indicates no hash present - 1 MD5 [RFC 1321] - 2 SHA-1 - 3 RIPEMD - 4-254 available for assignment - 255 reserved - - The hash size field is an unsigned octet count of the hash size. For - some hash algorithms it may be fixed by the algorithm choice but this - will not always be the case. For example, hash size is used to - distinguish between RIPEMD-128 (16 octets) and RIPEMD-160 (20 - octets). If the hash algorithm is 0, the hash size MUST be zero and - no hash octets are present. - - The hash field itself is variable size with its length specified by - the hash size field. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Indirect KEY RRs - - -3. Performance Considerations - - With current public key technology, an indirect key will sometimes be - shorter than the keying material it points at. This may improve DNS - permformace in the retrieval of the initial KEY RR. However, an - additional retrieval step then needs to be done to get the actualy - keying material which must be added to the overall time to get the - public key. - - - -4. Security Considerations - - The indirecting step of using an indirect KEY RR adds complexity and - additional steps where security could go wrong. If the indirect key - RR was retrieved from a zone that was insecure for the resolver, you - have no security. If the indirect key RR, although secure itself, - point to a key which can not be securely retrieved and is not - validatated by a secure hash in the indirect key RR, you have no - security. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT Indirect KEY RRs - - -References - - PKCS#1 - - RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", - STD 13, November 1987. - - RFC 1035 - P. Mockapetris, "Domain Names - Implementation and - Specifications", STD 13, November 1987. - - RFC 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992. - - RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform - Resource Locators (URL)", December 1994. - - RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security - Extensions", 01/03/1997. - - draft-ietf-dnssec-certs-*.txt - - - -Author's Address - - Donald E. Eastlake 3rd - CyberCash, Inc. - 318 Acton Street - Carlisle, MA 01741 USA - - Telephone: +1 978 287 4877 - +1 703 620-4200 (main office, Reston, VA) - FAX: +1 978 371 7148 - EMail: dee@cybercash.com - - - -Expiration and File Name - - This draft expires May 1998. - - Its file name is draft-ietf-dnssec-indirect-key-01.txt. - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 8] - diff --git a/doc/expired/draft-ietf-dnssec-key-handling-00.txt b/doc/expired/draft-ietf-dnssec-key-handling-00.txt deleted file mode 100644 index 919b0be3bf..0000000000 --- a/doc/expired/draft-ietf-dnssec-key-handling-00.txt +++ /dev/null @@ -1,473 +0,0 @@ -Domain Name System Security WG Edward Lewis -INTERNET DRAFT Olafur Gudmundsson - Trusted Information Systems - November 21, 1997 - - - - Zone KEY RRSet Signing Procedure - - - -0.0 Status of this Memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its - areas, and its working groups. Note that other groups may also - distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet- - Drafts as reference material or to cite them other than as - ``work in progress.'' - - To learn the current status of any Internet-Draft, please check - the ``1id-abstracts.txt'' listing contained in the Internet- - Drafts Shadow Directories on ftp.is.co.za (Africa), - ds.internic.net (US East Coast), nic.nordu.net (Europe), - ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). - - This Internet Draft expires on 21 May 1998. - - Please send comments to the authors and dns-security@tis.com. - -1.0 Abstract - - Under the security extensions to DNS, as defined in RFC 2065 and - RFC 2137, a secured zone will have a KEY RRSet associated with - the domain name at the apex of the zone. This document covers - the manner in which this RRSet is generated, signed, and inserted - into the name servers. - -1.5 Change Log - - Version 01 - draft-lewis-dnskey-handling-01.txt: - - Minor editorial changes. - Added paragraph in section 3.1 elaborating on off-net versus off- - net signing. - Added paragraph in section 4.0, step 2, requiring proof of - private key ownership. - Added Change Log section. - - Version 02 - draft-ietf-dnssec-key-handling-00.txt: - Minor editorial changes. - Dynamic update reference changed from a draft to an RFC. - -Expires November 21, 1997 [Page 1] - -Internet Draft May 21, 1998 - -2.0 Introduction - - Under the security extensions to DNS, as defined in RFC 2065 - [RFC2065] and [RFC2137], a secured zone will have a KEY RRSet - associated with the domain name at the apex of the zone. At - least one of the KEY RR's will be a public key that is used - to verify SIG RR's in the zone. The SIG(KEY) RR covering this - RRSet must itself be signed by some other domain name, "some - other" being required to build a chain of trusted verifications. - (The alternative to requiring a different signer is to have - each name server hold all the public keys it will ever need in - a trusted place, which is not a scaleable solution.) A key - administration protocol external to the existing DNS protocol - is needed to produce the signature of the KEY RR's and to get - it into the DNS name servers. - - As this is a first document on the subject, the "administration - protocol" will be described more as an "administrative procedure - or method." - - The challenge is to design a secure procedure for handling the - unsigned public keys as they move from the place of generation - to a place where they are signed. The procedure must also - eventually lead to the insertion of the keys and signature into - the zone master file on a primary name server. The place of - generation and the place of the signing are recommended to be - disconnected from the Internet in order to protect the private - keys produced and/or used in the procedure. The two locations - may also be disconnected from each other. - - The security of the public keys in this procedure is crucial to - the operation of the secure zone. An attack in which a false - public key is submitted for signing would enable a masquerade of - the true zone data by the attacker. - -2.1 Terminology convention - - In the literature on DNS, different terms are used to describe - the relationship of zones. "Super-zone and sub-zone," "parent - and child," and "delegator and delegatee" each refer to two - zones joined at a "zone cut." For each of the set of terms, the - former is the zone above the cut point, the latter is below the - cut point. In this document, we use the terms delegator and - delegatee. - -3.0 DNSSEC Configuration Variants - - There are a number of variants in the way in which DNSSEC can be - configured that impact a discussion of key management. The - discussion in section 4.0 will assume a nominal configuration - (defined in section 3.4) to simplify this document. In this - section, pertinent configuration decisions are described, and - how the choices make a particular configuration differ from the - so-called nominal configuration. - -Expires November 21, 1997 [Page 2] - -Internet Draft May 21, 1998 - -3.1 Off/On-Net Signing - - In DNSSEC the configuration of DNS operations and signing fall - into two categories. The most secure is the use of an "off-net" - signer. The alternative is to use an "on-net" signer. These - two alternatives correspond to the Mode A and Mode B distinction - in UPDATE. (Mode A's initial zone signing is performed off- - net.) - - The decision whether off-net or on-net signing is used is based - upon the risk assessment of the site's network management. An - on-net key is more vulnerable to attack than an off-net key just - by being present somewhere on the network. Off-net signing is - recommended for tighter security. Being behind a firewall might - be deemed insufficient if the administration does not trust the - protection in other parts of the network. This is matter of - choice for sites. - - In off-net signing, the machinery performing the act of creating - the keyed signature is not reachable from the network the DNS - (name server set) is serving. I.e., there is no direct - mechanism for data transfer from the signing machine to a name - server. Without loss of generality, the DNS served network may - be thought of as the Internet. - - The off-net signer need not be a stand-alone machine it may be - on an "air-gapped" (not physically connected) network. This - network may be just a very local network (i.e., within one - office or machine room), reserved for sensitive network - administration use. For the purposes of this document, this - will be labeled the back-room network (even if just a stand- - alone machine is on it). - - The back-room network needs to be able to get information from - the Internet to derive the unsigned zone master files (among - other things). The back-room network generates the signed - files, which are inserted to the Internet DNS servers. The - mechanism to carry this out may be removable "static" media. - - ADDED for draft-01: - - (The preceding discussion focuses on the original signing of a - zone. Dynamic update requests for both off-net and on-net - situations are signed on-net, in the case of off-net, a - different key is used to sign the updates. The choice of off- - net or on-net is a comparison of the administrative effort to - maintain off-net signing versus the risk of an on-net private- - key compromise.) - - For the purposes of this document, if off-net signing is used, - we assume key generation is also performed off-net. - - On-net signing simply means the signer is accessible over the - Internet. If the back-room network exists, it is connected to - -Expires November 21, 1997 [Page 3] - -Internet Draft May 21, 1998 - - the Internet. In the procedures described below, the steps used - to transfer information from the Internet to the back-room - network are obviously unnecessary. - -3.2 Relationship of Zone and Key Signer - - In a nominal state, a zone's delegator will also be the signer - of the delegated zone's KEY RR set. E.g., for a zone named - "xz.test." with an NS RRSet at that name, the domain name - "test." would be the delegator of "xz.test." and signer of its - KEY RRSet. However, there may be cases in which some other - entity is the signer. - - The role and composition of the "other entity" is not yet - defined, and may or may not ever be defined. This entity has - been referred to as a Signing Authority, whose sole purpose is - to sign records for clients. This may be more or less a - certification authority for DNS KEY RRSets. For the purposes of - this document, this entity will be assumed to be the delegating - zone, and it will be referred to as the "signing entity." - -3.3 Name Server Topology - - The separation between two delegated zones may mean that the two - do not share any name servers, such as most names under .COM and - .COM itself. In general, the set of name servers for two zones - may overlap. This document will focus on cases in which zones - do not share name servers or other facilities. - - If the two zones share the same name servers they likely will - share the mechanism for the generation of zone keys. In this - case, the transfer of information between the zones becomes a - moot point because the problem may degenerate into accessing a - file in a shared file system. For zones sharing a back-room - network, the data for the two zones (between the off-net and on- - net machines) can be transferred together. - -3.4 The Nominal Configuration - - The nominal configuration used within the context of this - document is that the zones involved (one being the zone - generating the keys and the other zone performs the signing) - each employ off-line signing, and employ distinct sets of name - servers. In addition, the zone performing the signing is the - zone above the delegation point that creates the zone which is - generating and requesting the signing of its keys. - -4.0 Key Signing Protocol/Procedure - - The steps described here assume the nominal configuration in - section 3.4. In some configurations, the steps listed in this - section may degenerate into null or very simple operations. - Additionally, some steps can be carried out in parallel even - with the nominal configuration, so the strict ordering described - -Expires November 21, 1997 [Page 4] - -Internet Draft May 21, 1998 - - here need not be followed. - - Step 0. A delegation needs to be instituted. A means to - authenticate both the delegator to the delegatee and vice versa - is also needed. - - A delegation may only need to be created once. A NS RRSet and a - KEY RRSet must be installed by the delegating zone. Until a key - pair is generated the KEY RRSet will have a null zone key, - indicating that the delegated zone is initially unsecured. - - Instituting means to authenticate the participants must occur - initially, and then again if the means of authentication (e.g., - a secret key) is ever compromised. - - How a delegation comes about is a subject for registries and/or - local network administration policies and procedures. These - groups should be aware of the responsibilities entailed in - instituting DNS security, especially the need for an active - recurring relationship, as the remaining steps describe. - - It is assumed that at some point, the delegated zone acquires a - trusted public key(s) for at least one other entity. This could - be for root, the delegating zone, or for a signing authority. - These keys may be DNS zone keys or keys for some application, - e.g., trusted mail. This will enable the use of other secure - services to achieve the following steps. Selecting the services - may be within the scope of this document, but which should be - selected is still open for discussion. - - Step 1. Delegated zone generates zone keys. A new pair may be - generated without changing the other pairs in use (assuming - others exist). - - Step 2. The delegated zone sends keys to the signing entity. - All of the public key information, encoded in such a way that - the KEY RR's can be generated from it, crosses from the back- - room net to the Internet, and is shipped securely to the signing - entity. (Implementing "securely" is still an open issue.) It - is important that both the delegated zone and the signing entity - authenticate themselves to each other. - - All public keys must be included, both newly generated and those - in current use. Keys are retired through omission. - - ADDED for draft-01: - - The delegated zone must prove ownership of the private keys - corresponding to each public key. This may be done by signing - the collection of public key data with each of the private keys. - Thus the submission would consist of one copy of each public key - and as many signatures as there were public keys. (For example, - submitting five public keys would require sending all five plus - five signatures.) This signing is only done to prove the - -Expires November 21, 1997 [Page 5] - -Internet Draft May 21, 1998 - - ownership of the private key, not for authentication. - - Step 3. The signing entity signs the key set. The algorithm - used to sign the KEY RRSet need not be the same as the - algorithm(s) for which the keys were generated. - - Step 4. The delegated zone receives KEY RRSet and SIG(KEY) RR - from the signing entity. The delegated zone must verify the - keys and signature locally. The zone must also verify that the - KEY RRSet is identical to the set of keys submitted for - signature in step 2, to protect against a masquerader from - submitting keys for signature. Once the records are signed, - there is no requirement for enhanced security while transmitting - the information across the Internet because the DNS signature - provides non-repudiation. - - Step 5. Delegating zone gets the KEY RRSet and SIG(KEY) RR. - The KEY RRSet and the SIG(KEY) RR are sent from the signing - entity to the delegating zone's master files and optionally the - name servers. In the nominal case, the signing entity and the - delegating zone are one in the same, so this may be a trivial - step. (The latter is to ensure the public key will be available - for verifications once the signing process - step 7 - is - finished.) - - Step 6. The delegating zone signs its zone data. This step may - be done in parallel with steps 2-5. Note: signing a zone does - not require that a new key pair be generated. - - Step 7. The new zone data enters DNS. The KEY RRSet, SIG(KEY - RR) and the rest of the signed zone data and signatures traverse - from the back-room network and are inserted into the DNS primary - name server serving the Internet side. - - Steps 1 through 7 are repeated whenever a new key pair is - required. Note that the signing in step 6 may not sign all - records; some records may have signature records from older keys - that are sufficient. - -5.0 Resigning a KEY RRSet - - When the delegating zone resigns itself, the KEY RRSet of a - delegated zone may be resigned. In this case, the newly created - SIG(RR) must be sent to the delegatee for inclusion. - - The signing of a delegatee's keys in the manner of the previous - paragraph may be prompted by a request from the delegatee. A - SIG(RR) record may be approaching its expiration date, although - the KEY RRSet it is verifying has not changed. - -6.0 Open Issues - - This section is intentionally left undeveloped to encourage more - feedback. - -Expires November 21, 1997 [Page 6] - -Internet Draft May 21, 1998 - - - Timing of steps, required response times. - - The signing cycles of zones will likely be out of phase of each - other. If they were not, then there would be "signing crunches" - which would add variability to the spacing of events in the - procedure. One issue is how this should be addressed. Should - there be a recommended limit on signing entity's response? - Should this even be specified? - - Can secure e-mail be used? Perhaps, and discussions to this - effect have occurred, using secure e-mail as a conduit for (at - least) the unsigned keys. - -7.0 Operational Considerations - - A widely delegated zone, such as .COM, or a zone publishing KEY - RR's for others, such as a large Internet access provider, - should expect a huge performance impact in signing the KEY - RRSets for it delegations. Running on a Pentium 166MHz - computer, simply signing the current .COM records, requires 40 - hours. (Measured in January 1997.) This covers just the NXT - RRSets and a few other records. Having to sign a KEY RRSet for - each member of the zone will require about the same computing - resources, and much more overhead in the handling of the - individual KEY RRSets. - -8.0 Security Considerations - - This document discusses a procedure for handling the keys used - by DNS for its security and the keys for applications employing - DNS for key distribution. Once in DNS, keys are protected by - the presence of a keyed hash, which can be used to verify the - source and integrity of the public key data. During the process - described here, the keyed hash is not yet present, leaving the - keys vulnerable to modification. The security of this process - is crucial to the usefulness of DNS as a key distribution - mechanism. At this point many issue remain to be resolved, a - thorough security analysis of the process is premature. - -9.0 References - - [RFC2065] "Domain Name System Security Extensions," D. Eastlake, - 3rd, and C. Kaufman - http://ds.internic.net/rfc/rfc2065.txt - - [RFC2137] "Secure Domain Name System Dynamic Update," D. - Eastlake, 3rd - http://ds.internic.net/rfc/rfc2137.txt - - - - - - -Expires November 21, 1997 [Page 7] - -Internet Draft May 21, 1998 - -10.0 Author's Addresses - - Edward Lewis Olafur Gudmundsson - Trusted Information Systems Trusted Information Systems - 3060 Washington Road 3060 Washington Road - Glenwood, MD 21738 Glenwood, MD 21738 - +1 301 854 5794 +1 301 854 5700 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires November 21, 1997 [Page 8] - - diff --git a/doc/expired/draft-ietf-dnssec-rollover-00.txt b/doc/expired/draft-ietf-dnssec-rollover-00.txt deleted file mode 100644 index 4aab0f5de1..0000000000 --- a/doc/expired/draft-ietf-dnssec-rollover-00.txt +++ /dev/null @@ -1,521 +0,0 @@ - -INTERNET-DRAFT DNSSEC Key Rollover - October 1998 - Expires April 1999 - - - - - Domain Name System (DNS) Security Key Rollover - ------ ---- ------ ----- -------- --- -------- - - Donald E. Eastlake 3rd, Mark Andrews - - - -Status of This Document - - This draft, file name draft-ietf-dnssec-rollover-00.txt, is intended - to be become a Proposed Standard RFC. Distribution of this document - is unlimited. Comments should be sent to the DNS security mailing - list or to the authors. - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - - - -Abstract - - Practical deployment of Domain Name System (DNS) security with good - cryptologic practice will involve large volumes of key rollover - traffic. A standard format and protocol for such messages is - specified. - - - - - - - - - -D. Eastlake 3rd, M. Andrews [Page 1] - - -INTERNET-DRAFT October 1998 DNSSEC Key Rollover - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. Key Rollover Scenarios..................................3 - 3. Rollover Operation......................................4 - 3.1 Rollover to Parent.....................................4 - 3.2 Rollover to Children...................................5 - 4. Rollover NOTIFY.........................................6 - 5. Security Considerations.................................7 - - References.................................................8 - Authors Address............................................8 - Expiration and File Name...................................9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, M. Andrews [Page 2] - - -INTERNET-DRAFT October 1998 DNSSEC Key Rollover - - -1. Introduction - - The Domain Name System (DNS) [RFC 1034, RFC 1035] is the global - hierarchical replicated distributed database system for Internet - addressing, mail proxy, and other information. The DNS has been - extended to include digital signatures and cryptographic keys as - described in [draft-ietf-dnssec-secext2-*]. - - The principle security service provided for DNS data is data origin - authentication. The owner of each zone signs the data in that zone - with a private key known only to the zone owner. Anyone that knows - the corresponding public key can then authenticate that zone data is - from the zone owner. To avoid having to preconfigure resolvers with - all zone's public keys, keys are stored in the DNS with each zone's - key signed by its parent (if the parent is secure). - - To obtain high levels of security, keys must be periodically changed, - or "rolled over". The longer a private key is used, the more likely - it is to be compromised due to cryptanalysis, accident, or treachery - [draft-ietf-dnssec-secops-*.txt]. - - In a widely deployed DNS security system, the volume of update - traffic will be large. Just consider the .com zone. If only 10% of - its children are secure and change their keys only once a year, you - are talking about hundreds of thousands of new child public keys that - must be securely sent to the .com manager to sign and return with - their new parent signature. And when .com rolls over its private - key, it will needs to send hundreds of thousands of new signatures on - the existing child public keys to the child zones. - - The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" - in this document are to be interpreted as described in RFC 2119. - - - -2. Key Rollover Scenarios - - Although DNSSEC provides for the storage of other keys in the DNS for - a variety of purposes, DNSSEC zone keys are included solely for the - purpose of being retrieved to authenticate DNSSEC signatures. Thus, - when a zone key is being rolled over, the old public key should be - left in the zone, along with the addition of the new public key, for - as long as it will reasonably be needed to authenticate old - signatures that have been cached or are held by applications. If - DNSSEC were universally deployed and all DNS server's clocks were - synchronized and zone transfers were instantaneous etc., it might be - possible to avoid ever having duplicate old/new KEY RRsets but they - will be necessary in practical cases. Security aware DNS servers - decrease the TTL of secure RRs served as the expiration of their - authenticating SIG(s) approaches but some dithered fudge must - - -D. Eastlake 3rd, M. Andrews [Page 3] - - -INTERNET-DRAFT October 1998 DNSSEC Key Rollover - - - generally be left due to clock skew and to avoid massive load on - large zones due to the signatures on their entire contents expiring - simultaneously. - - Assume a zone with a secure parent and secure children wishes to role - over its KEY RRset. This RRset would probably be one KEY RR per - crypto algorithm used to secure the zone, but for this scenario, we - will simply assume it is one KEY RR. The old KEY RR and two SIG RRs - will exist at the apex of the zone and these RRs may also exist at - the leaf node for this zone in its parent. The contents of the zone - and the zone KEY RRs of its secure children will have SIGs under the - old key. - - The zone owner needs to communicate with its parent to obtain a new - parental signature covering both the old and new KEY RRs and covering - just the new KEY RR. It would probably want to obtain these in - advance so that it can install them at the right time along with its - new SIG RRs covering the content of the zone. Finally, it needs to - give new SIG RRs to its children that cover their KEY RRs if it has - these, or signal its children to ask for such SIG RRs. - - - -3. Rollover Operation - - Rollover operations use a DNS request syntactically identical to the - UPDATE request [RFC 2136] except that the operation is ROLLOVER which - is equal to TBD. Considerations for such request to the parent and - children of a zone are given in the subsections. - - [This draft does not currently consider cross-certification key - rollover.] - - - -3.1 Rollover to Parent - - A zone rolling over its KEY RRset sends a ROLLOVER command to the - parent. The Zone should be specified as the parent zone and no - Prerequisites are included. The Update section has the KEY RRset on - which the parent signature is requested along with the requesting - zone's SIG(s) under its old KEY(s) as RRs to be added to the parent - zone. The inception and expiration times in this SIG are the - requested inception and expiration times for the parent SIG. - - If the ROLLOVER command is erroneous or violates parental policy, an - Error response is returned. - - If the ROLLOVER command is OK and the parent can sign online, its - response may include the new parent SIG(s) in the Update section. - - -D. Eastlake 3rd, M. Andrews [Page 4] - - -INTERNET-DRAFT October 1998 DNSSEC Key Rollover - - - This response MUST be sent to the originator of the request. - - If the parent can not sign online, it should return a response with - an empty Update section and queue the SIG(s) calculation request. - This response MUST be sent to the originator of the request. - - Regardless of whether the server has sent the new signatures above, - it MUST, once it has calculated the new SIG(s), send a ROLLOVER to - the child zone using the DNS port (53) and the server selection - algorithm defined in RFC 2136, Section 4. This ROLLOVER reqeust - contains the KEY RRset that triggered it and the new SIG(s). This - downward ROLLOVER request is distinguished from those in Section 3.2 - below in that the Zone section is the parental zone. - - The reason for sending the ROLLOVER request regardless of whether the - new SIG RR(s) were sent in the original response is to provide an - indication to the operators of the zone in the event someone is - trying to hijack the zone. - - Although the parent zone need not hold or serve the child's key, the - ROLLOVER command MUST NOT actually update the parent zone. A later - UPDATE command can be used to actually put the new KEY into the - parent zone if desired and supported by parent policy. - - This document does not cover the question of parental policy on key - rollovers. Parents may have restrictions on how far into the future - they will sign KEY RRsets, what algorithms or key lengths they will - support, might require payment for the service, etc. The signing of - a future KEY by a parent is, to some extent a granting to the - controller of the child private key of future authoritative existence - even if the child zone ownership should change. The only effective - way of invalidating such future signed child public keys would be for - the parent to roll over its key(s), which might be an expensive - operation. - - - -3.2 Rollover to Children - - When a zone is going to rollover its key(s), it needs to re-sign the - zone keys of any secure children under its new key(s). - - If the parent holds the KEY RRset for the child (whether or not it - actually serves it from the parent zone), it can simply do a ROLLOVER - request to to child specifying the child as the Zone in the request - and the new SIG(KEY)s to be added in the Update section. The - inception and expiration times in the SIG(s) indicate the time during - which the parent will be utilizing the new parent key. It is up to - the child when and how it adds the new parental SIG(s). The ROLLOVER - request may optionally indicate the deletion of old parental SIG(s) - - -D. Eastlake 3rd, M. Andrews [Page 5] - - -INTERNET-DRAFT October 1998 DNSSEC Key Rollover - - - but SHOULD only do so if the corresponding key is being withdrawn by - the parent in advance of the expiration time in the old SIG(s). It - is up to the child when and how it deletes the old parental SIG(s). - Even if the expiration of the old SIG(s) equals the inception time of - the new SIG(s), the child should serve both signatures for a fudge - time to account for clock skew. - - A ROLLOVER request is used instead of an UPDATE because serves may - wish to support ROLLOVER via special techniques, such as notification - to the operator, even when they have not implemented UPDATE. With - adequate advance notice, even manual cut and paste editing of the - master file and restarting of a DNS server process could work. - - If the parent does not retain knowledge of the child KEY RRset, then - the parent simply notifies the child via a ROLLOVER NOTIFY (see - Section 4 below) that the parent KEY(s) have changed. The child then - proceeds to do an upward ROLLOVER request to obtain the new parental - SIG(s). (This requires that a different method, such as TSIG, be - used to secure such ROLLOVER requests since we are assuming the - parent does not have authoritative knowledge of the child public key. - See Section 5 below.) - - The NOTIFY technique MAY also be used by parents who retain knowledge - of their children's KEY RRsets. - - - -4. Rollover NOTIFY - - A ROLLOVER NOTIFY informs a child zone that the parent zone want it - to resubmit its keys for resigning. - - A ROLLOVER NOTIFY MUST be signed and if not signed a BADAUTH response - generated. - - A ROLLOVER NOTIFY is a NOTIFY reqeust [RFC 1996] that has a QTYPE of - SIG and the owner name of the child zone. The answer section is - empty. - - The ROLLOVER NOTIFY can be sent to any of the nameservers for the - child using the nameserver selection algorithm defined in RFC 2136, - Section 4. - - Nameservers for the child zone receiving a ROLLOVER NOTIFY query will - forward the ROLLOVER NOTIFY in the saem manner as an UPDATE is - forwarded. - - Unless the master server is configured to initiate an automatic - ROLLOVER it MUST seek to inform its operators that a ROLLOVER NOTIFY - request has been received. This could be done by a number of methods - - -D. Eastlake 3rd, M. Andrews [Page 6] - - -INTERNET-DRAFT October 1998 DNSSEC Key Rollover - - - including generating a log message, generating an email request to - the child zone's SOA RNAME or any other method defined in the - server's configuration for the zone. The default should be to send - mail to the zone's SOA RNAME. Care should be taken to rate limit - these message so prevent them being used to facilitate a denial of - service attack. - - Once the message has been sent (or suppressed) to the child zone's - administrator the master server for the child zone is free to respond - to the ROLLOVER NOTIFY request. - - - -5. Security Considerations - - The security of ROLLOVER or UPDATE requests is essential, otherwise - false children could steal parental authorization or a false parent - could cause a child to install an invalid signature on its zone key, - etc. - - A ROLLOVER request can be authentication by request SIG(s)under the - old zone KEY(s) of the requestor [draft-ietf-dnssec-secext2-*.txt]. - The response SHOULD have transaction SIG(s) under the old zone KEY(s) - of the responder. (This public key security could be used to - rollover a zone to the unsecured state but at that point it would - generally not be possible to roll back without manual intervention.) - - Alternatively, if there is a prior arrangement between a child and a - parent, ROLLOVER requests and responses can be secured and - authenticated using TSIG [draft-ietf-dnssec-tsig-*.txt]. (TSIG - security could be used to rollover a zone to unsecured and to - rollover an unsecured zone to the secured state.) - - A server that implements online signing SHOULD have the ability to - black list a zone and force manual processing or demand that a - particular signature be used to generate the ROLLOVER request. This - it to allow ROLLOVER to be used even after a private key has been - compromised. - - - - - - - - - - - - - - -D. Eastlake 3rd, M. Andrews [Page 7] - - -INTERNET-DRAFT October 1998 DNSSEC Key Rollover - - -References - - [RFC 1034] - P. Mockapetris, "Domain names - concepts and - facilities", 11/01/1987. - - [RFC 1035] - P. Mockapetris, "Domain names - implementation and - specification", 11/01/1987. - - [RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", August 1996. - - [RFC 2136] - Dynamic Updates in the Domain Name System (DNS UPDATE). - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. - - [draft-ietf-dnsind-tsig-*.txt] - - [draft-ietf-dnssec-update2-*.txt] - - [draft-ietf-dnssec-secext2-*.txt] - - [draft-ietf-dnssec-secops-*.txt] - - - -Authors Address - - Donald E. Eastlake 3rd - IBM - 318 Acton Street - Carlisle, MA 01741 USA - - Telephone: +1 978-287-4877 - +1 914-784-7913 - FAX: +1 978-371-7148 - EMail: dee3@us.ibm.com - - - Mark Andrews - Internet Software Consortium - 1 Seymour Street - Dundas Valley, NSW 2117 - AUSTRALIA - - Telephone: +61-2-9871-4742 - Email: marka@isc.org - - - - - - - -D. Eastlake 3rd, M. Andrews [Page 8] - - -INTERNET-DRAFT October 1998 DNSSEC Key Rollover - - -Expiration and File Name - - This draft expires in April 1999. - - Its file name is draft-ietf-dnssec-rollover-00.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, M. Andrews [Page 9] diff --git a/doc/expired/draft-ietf-dnssec-secfail-00.txt b/doc/expired/draft-ietf-dnssec-secfail-00.txt deleted file mode 100644 index 67b22bb7e5..0000000000 --- a/doc/expired/draft-ietf-dnssec-secfail-00.txt +++ /dev/null @@ -1,291 +0,0 @@ -Internet-Draft B. Wellington, O. Gudmundsson -DNSSEC Working Group TISLabs - August 1998 - - - - Intermediate Security Failures in DNSSEC - - - - Status of this Memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet- Drafts - as reference material or to cite them other than as "work in - progress." - - To view the entire list of current Internet-Drafts, please check - the "1id-abstracts.txt" listing contained in the Internet-Drafts - Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net - (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au - (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US - West Coast). - - Distribution of this memo is unlimited. - - - - Abstract - - This document identifies the situations where a signature - verification fails in a recursive security aware DNS server, and - how DNS servers should handle these cases, and the errors that - should be reported to DNS resolvers. This document proposes a new - error to be returned by DNSSEC capable servers. - - A DNSSEC server acting as a recursive server MUST validate the - signatures on RRsets in a response it passes on; this draft - addresses the case when the data it receives fails signature - - - - - - - - - - - -Wellington, Gudmundsson Expires February 1999 [Page 1] - - -Internet-Draft dnssec-secfail-00.txt August 1998 - - - verification. The end resolver must be notified of this occurence - in such a way that it will not confuse it with another error. - - - - 1. Description - - A DNS [RFC1034, RFC1035] transaction is defined by a query/response - pair. The resolver (client) sends a query to a name server. The - name server will respond if it contains the necessary information, - or forward the request to an authoritative server. The response - consists of the answer to the query, as well as authority records - showing that the response came from a valid source, and additional - records. - - DNSSEC [RFC2065, SECEXT2] adds security to the DNS protocol. Each - RRset (set of DNS records with the same name/class/type) is - digitally signed, and the signature is verified by any server or - resolver who receives it. The receiver must therefore have a valid - key for verifying that data, as specified by a name/footprint pair. - A key's validity is determined by recursively verifying that it was - signed by a valid key; this recursion ends when a trusted key is - reached. Trusted keys must be obtained out of band, for example - through manual configuration. - - Consider a recursive name server (R) that forwards a query to - another server (S). R receives an response from S, and attempts to - verify the included RRsets using a key that it trusts. Note that - this key may either be implicitly trusted or authenticated. The - signature verification fails for one or more RRsets in the answer - or authority section. The name server must communicate this error - in its response. To do this, a new return code (RCODE) will be - used, denoted SECFAIL (value TBD). - - When a resolver receives a DNS response with an RCODE of SECFAIL, - that one of the following is true: - 1) server S has sent invalid data to server R. - 2) the data has been corrupted (possibly maliciously) between R and S. - 3) server R has preconfigured S's key incorrectly. - 4) There is more than one KEY with the same footprint and algorithm - for that name, and server R contains one different from the one used - by S to sign the data. This should not happen. - - None of the current RCODE values sufficiently describe the case - where the data exists, but cannot be successfully retrieved and/or - transmitted. It is the responsibility of both R and the resolver - to attempt to identify the source of the problem. - - - - - -Wellington, Gudmundsson Expires February 1999 [Page 2] - - -Internet-Draft dnssec-secfail-00.txt August 1998 - - - 2. Proposal - - When the recursive name server (R) fails to verify a signed RRset - in the answer or authority section of a response that it receives, - it sets the RCODE of the response to SECFAIL before forwarding the - response to the entity that originated the query. There are - several possible modifications that could be made to the data by R: - 1) all records could be passed unchanged - 2) all records could be dropped - 3) only the records that failed verification could be dropped - 4) the SIGs of all records that failed verification could be dropped - A solution to this problem has not yet been decided. - - If R receives a response with SECFAIL set, it does no processing on - the response, simply forwarding it if necessary. An intelligent - resolver MAY use additional queries to determine which of the - RRsets was invalid. The ERR record [ERR] or EDNS [EDNS] could also - be used to provide a more fine-grained description of the error. - - When R fails to verify an RRset, it can determine whether or not - the key used has successfully verified other data (a flag or - timestamp could be stored along with the key). If it has, then the - key has not been misconfigured, and the error is due to data - corruption (possibly malicious) or a data error on the - authoritative server (S). R cannot further quantify the problem. - If the key has never successfully verified data, then the problem - may be a misconfigured key, or it could be due to malicious - corruption or a very unreliable network. In any case, this should - be logged, and the maintainer of R should determine (out of band) - whether the preconfigured key is erroneous. R MAY elect to retry - the query; this would succeed if the error was due to transient - network problems or a partial attack. Unless a retransmission - yields success, R should always send a response with SECFAIL set. - - - - 3. Limitations - - If the path between a resolver and an authoritative server is - several hops, there is no way to determine at which recursive - server the SECFAIL error occurred. The data will be passed through - successive servers unchanged. - - There is no way to distinguish a server continuously reporting - invalid data from an active attack. For instance, if a server has - an preconfigured key that is invalid, all queries using that key - will fail. An attack could easily simulate this behavior. There - is no way to split SECFAIL into more specific errors, since the - - - - -Wellington, Gudmundsson Expires February 1999 [Page 3] - - -Internet-Draft dnssec-secfail-00.txt August 1998 - - - cause of the error cannot always be determined. - - - - 4. Security Considerations - - Unless transaction signatures of some form are used [RFC2065, - TSIG], the RCODE field of a DNS response is not protected, so the - SECFAIL RCODE could be added or stripped by an attacker. - - - - 5. References - - -[EDNS] P. Vixie, "Extensions to DNS (EDNS)", Internet - Draft , March 1998 - - -[ERR] R. Watson, O. Gudmundsson, "Error Record (ERR) - for DNS" Internet Draft , March 1998 - - -[RFC1034] P. Mockapetris, "Domain Names - Concepts and - Facilities", RFC 1034, ISI, November 1987. - - -[RFC1035] P. Mockapetris, "Domain Names - Implementation - and Specification", RFC 1034, ISI, November 1987. - - -[RFC2065] D. Eastlake, C. Kaufman, "Domain Name System - Security Extensions", RFC 2065, January 1997. - - -[SECEXT2] D. Eastlake, "Domain Name System Security Exten­ - sions", Internet Draft , April 1998. - - -[TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret - Key Transaction Signatures for DNS (TSIG)" Inter­ - net Draft , June - 1998. - - - - - - - -Wellington, Gudmundsson Expires February 1999 [Page 4] - - -Internet-Draft dnssec-secfail-00.txt August 1998 - - -6. Author address - - Brian Wellington, Olafur Gudmundsson - TIS Labs at Network Associates - 3060 Washington Road - Glenwood, MD 21738 - +1 301 854 6889 - bwelling@tis.com, ogud@tis.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wellington, Gudmundsson Expires February 1999 [Page 5] - - diff --git a/doc/expired/draft-ietf-dnssec-simple-update-01.txt b/doc/expired/draft-ietf-dnssec-simple-update-01.txt deleted file mode 100644 index 83b8c9c47b..0000000000 --- a/doc/expired/draft-ietf-dnssec-simple-update-01.txt +++ /dev/null @@ -1,278 +0,0 @@ - -DNSSEC Working Group Brian Wellington (TISLabs) -INTERNET-DRAFT February 1999 - - - -Updates: RFC 2065, RFC 2136, [TSIG] -Replaces: RFC 2137, [update2] - - - - Simple Secure Domain Name System (DNS) Dynamic Update - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Abstract - - This draft proposes an alternative method for performing secure - Domain Name System (DNS) dynamic updates. The method described here - is both simple and flexible enough to represent any policy decisions. - Secure communication based on request/transaction signatures [TSIG] - is used to provide authentication and authorization. - - - - - - - - - -Expires August 1999 [Page 1] - -INTERNET-DRAFT Simple Secure Dynamic Update February 1999 - - -1 - Introduction - -Dynamic update operations for the Domain Name System are defined in -[RFC2136], but no mechanisms for security have been defined. Request -and transaction signatures are defined in [TSIG]. - -Familiarity with the DNS system [RFC1034, RFC1035] as well as the -proposals mentioned above is assumed. Familiarity with DNS Security -[RFC2065, secext2] is assumed in section (4). - -1.1 - Overview of DNS Dynamic Update - -DNS dynamic update defines a new DNS opcode and a new interpretation of -the DNS message if that opcode is used. An update can specify -insertions or deletions of data, along with prerequisites necessary for -the updates to occur. All tests and changes for a DNS update request -are restricted to a single zone, and are performed at the primary server -for the zone. The primary server for a dynamic zone must increment the -zone SOA serial number when an update occurs or before the next -retrieval of the SOA. - -1.2 - Overview of DNS Transaction Security - -[TSIG] provides a means for two processes that share a secret key to -authenticate DNS requests and responses sent between them. This is done -by appending TSIG digital signature (keyed hash) RRs to those messages. -Keyed hashes are simple to calculate and verify, and do not require -caching of data. - -2 - Authentication - -TSIG records are attached to all secure dynamic update messages. This -allows the server to verifiably determine the originator of the message. -It can then use this information in the decision of whether to accept -the update. DNSSEC SIG records may be included in an update message, -but MAY NOT be used for authentication purposes in the update protocol. -If a message fails the authentication test due to an unauthorized key, -the failure is indicated with the REFUSED rcode. Other TSIG or dynamic -update errors are returned unchanged. - - - - - - - - - - - - -Expires August 1999 [Page 2] - -INTERNET-DRAFT Simple Secure Dynamic Update February 1999 - - -3 - Policy - -All policy is dictated by the server and is configurable by the zone -administrator. The server's policy defines criteria which determine if -the key used to sign the update is permitted to update the records -requested. By default, a key cannot make any changes to the zone; the -key's scope must be explicitly enabled. There are several reasons that -this process is implemented in the server and not the protocol (as in -[RFC2137, update2], where the signatory bits of KEY records may define -the policy). - -3.1 - Flexibility - -Storing policy in the signatory fields of DNS keys is overly -restrictive. Only a fixed number of bits are present, which means that -only a fixed number of policy decisions are representable. There are -many decisions that do not fit into the framework imposed by the -signatory field; a zone administrator cannot effectively impose a policy -not implemented in the draft defining the field. - -There may be any number of policies applied in the process of -authorization, and there are no restrictions on the scope of these -policies. Implementation of the policies is beyond the scope of this -document. - -3.2 - Simplicity - -Policy decisions in the server could be used as an adjunct to policy -fields in the KEY records. This could lead to confusion if the policies -are inconsistent. Furthermore, since there is no need to expose -policies, a central configuration point is more logical. - -3.3 - Extendibility - -If a policy is changed, there are no changes made to the DNS protocol or -the data on the wire. This means that new policies can be defined at -any point without adverse effects or interoperability concerns. - - - - - - - - - - - - - - -Expires August 1999 [Page 3] - -INTERNET-DRAFT Simple Secure Dynamic Update February 1999 - - -4 - Interaction with DNSSEC - -A successful update request may or may not include SIG records for each -RRset. Since SIG records are not used for authentication in this -protocol, they are not required. If the updated zone is signed, the -server will generate SIG records for each incoming RRset with the Zone -key (which MUST be online). If there are any non-DNSSEC SIG records -present, they are retained. If there are SIG records that have been -generated by the appropriate zone KEY, these SIGs are verified and -retained if the verification is successful. DNSSEC SIG records -generated by other KEYs are dropped. The server will generate SIG -records for each set with the Zone key, unless one has already been -verified. The server will also generate a new SOA record and possibly -new NXT records, and sign these with the Zone key. - -The server MUST update the SOA record and MAY generate new NXT records -when an update is received. Unlike traditional dynamic update, the -client is forbidden from updating SOA 1 NXT records. - -5 - Security considerations - -For a secure zone to support dynamic update, the Zone key MUST be online -(unlike [RFC2137]). No additional protection is offered by having the -Zone key offline and an Update key online, since compromising any key -that can sign the zone's data compromises the zone itself. - -6 - References - -[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' - RFC 1034, ISI, November 1987. - -[RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification,'' RFC 1035, ISI, November 1987. - -[RFC2065] D. Eastlake, C. Kaufman, ``Domain Name System Security - Extensions,'' RFC 2065, CyberCash & Iris, January 1997. - -[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic - Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore - & Cisco & DEC, April 1997. - -[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC - 2137, CyberCash, April 1997. - -[secext2] D. Eastlake ``Domain Name System Security Extensions,'' - draft-ietf-dnssec-secext2-07.txt, IBM, December 1998. - - - - - -Expires August 1999 [Page 4] - -INTERNET-DRAFT Simple Secure Dynamic Update February 1999 - - -[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington - ``Secret Key Transaction Signatures for DNS (TSIG),'' draft- - ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs, - February 1999. - -[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic - Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite - Systems Company, August 1998. - -7 - Author's Address - - - Brian Wellington - TISLabs at Network Associates - 3060 Washington Road, Route 97 - Glenwood, MD 21738 - +1 443 259 2369 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires August 1999 [Page 5] - diff --git a/doc/expired/draft-ietf-dnssec-tkey-01.txt b/doc/expired/draft-ietf-dnssec-tkey-01.txt deleted file mode 100644 index 9349a36ab7..0000000000 --- a/doc/expired/draft-ietf-dnssec-tkey-01.txt +++ /dev/null @@ -1,1045 +0,0 @@ - - -DNSSEC Working Group Donald E. Eastlake, 3rd -INTERNET-DRAFT IBM -Expires: March 1999 September 1998 - - - - Secret Key Establishment for DNS (TKEY RR) - ------ --- ------------- --- --- ----- --- - - Donald E. Eastlake 3rd - - - -Status of This Document - - This draft, file name draft-ietf-dnssec-tkey-01.txt, is intended to - be become a Proposed Standard RFC. Distribution of this document is - unlimited. Comments should be sent to the DNS security mailing list - or to the author. - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 1] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -Abstract - - [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating and - securing Domain Name System (DNS) queries and responses using shared - secret keys via the TSIG resource record (RR). However, it provides - no mechanism for setting up such keys other than manual exchange. - This document describes a TKEY RR that can be used in a number of - different modes to establish shared secret keys between a DNS - resolver and server. - - [changes from last draft: add IANA considerations section, make time - fields module 2**32, minor edits, update author info, ...] - - - -Acknowledgments - - The substantial comments and ideas of the following persons (listed - in alphabetic order) have been incorporated herein and are gratefully - acknowledged: - - Olafur Gudmundsson - - Stuart Kwan - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 2] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -Table of Contents - - Status of This Document....................................1 - - Abstract...................................................2 - Acknowledgments............................................2 - - Table of Contents..........................................3 - - 1. Introduction............................................4 - 1.1 General Principles.....................................4 - 1.2 Overview of Contents...................................5 - - 2. The TKEY Resource Record................................6 - - 3. Exchange via Resolver Query.............................8 - 3.1 Query for Server Assigned Keying.......................8 - 3.2 Query for Diffie-Hellman Exchanged Keying..............9 - 3.3 Query for GSS-API Established.........................10 - - 4. Spontaneous Server Inclusion...........................11 - 4.1 Spontaneous Server Assigned Keying....................11 - 4.2 Spontaneous Diffie-Hellman Keying.....................11 - 4.3 Spontaneous GSS-API Exchange..........................11 - 4.4 Spontaneous Key Deletion..............................12 - - 5. TKEY Dynamic Update Requests...........................13 - 5.1 Exchange via TKEY 'Add'...............................13 - 5.2 TKEY Deletion.........................................13 - - 6. Methods of Encryption..................................14 - - 7. IANA Considerations....................................15 - - 8. Security Considerations................................16 - - References................................................17 - - Author's Address..........................................18 - Expiration and File Name..................................18 - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 3] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -1. Introduction - - The Domain Name System (DNS) is a hierarchical, distributed, highly - available database used for mapping between domain names and - addresses, for email routing, and for other information [RFC 1034, - 1035]. It has been extended to provide for public key security and - dynamic update [RFC 2136, draft-ietf-dnssec-secext2-*.txt, draft- - ietf-dnssec-update2-*.txt]. - - [draft-ietf-dnsind-tsig-*.txt] provides a means of more efficiently - authenticating and securing DNS messages using shared secret keys via - the TSIG resource record (RR) but provides no mechanism for setting - up such keys other than manual exchange. This document describes a - TKEY RR that can be used in a number of different modes to establish - such shared secret keys between a DNS resolver and server. - - - -1.1 General Principles - - TKEY is a meta-RR that is not stored or cached in the DNS and does - not appear in zone files. It supports a variety of modes for the - establishment and deletion of shared secret keys between DNS entities - such as resolvers and servers. The establishment of such a key - requires that state be maintained at both the resolver and the server - and the allocation of the resources to maintain such state may - require mutual agreement. In the absence of such agreement, servers - are free to return errors for any attempt to use TKEY and resolvers - are free to ignore any TKEY RRs they receive. - - In all cases herein, the term "resolver" includes that part of a - server which makes full and incremental [RFC 1995] zone transfer - queries as well as other queries. - - Servers are not required to implement any particular mode or modes of - the defined modes of TKEY shared secret key establishment or deletion - and may return errors for any they do not support. Based on - experience, in the future more modes may be added or some modes - described herein may be deprecated. - - The means by which the shared secret keying material exchanged via - TKEY is actually used in any particular TSIG algorithm is algorithm - dependent and is defined in connection with that algorithm. - - Note that this keying material and TSIGs that use it are associated - with DNS hosts. They are not tied to zones. They may be used to - authenticate queries and responses but they do not provide zone - stored DNS data origin authentication [draft-ietf-dnssec-secext2- - *.txt]. - - - -Donald E. Eastlake, 3rd [Page 4] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - - Two modes of TKEY, the server assigned and resolver assigned modes, - perform encryption which may effect their export or inport status for - some countries. All other aspects of DNS security, including the - SIG, KEY, NXT, and TSIG RRs and all other defined modes of TKEY - perform authentication (signatures and signature verification) only. - - - -1.2 Overview of Contents - - Section 2 below specifies the TKEY resource record (RR) and provides - a high level description of its constituent fields. - - Section 3 discusses key exchange via queries for type TKEY. This is - applicable to the server assigned, Diffie-Hellman exchange, and GSS- - API establishment modes. - - Section 4 discusses spontaneous inclusion of TKEY RRs in responses by - servers. This is applicable to key deletion and to server assigned - and Diffie-Hellman exchange key establishment. - - Section 5 discusses use of dynamic update requests for type TKEY. - This supports optional key exchange via resolver update request, - which is applicable to key deletion and to the resolver assigned - mode. - - Section 6 describes encryption methods for transmitting secret key - information. - - Section 7 covers IANA considerations in assignment of TKEY modes. - - Finally, Section 8 touches on some security considerations. - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 5] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -2. The TKEY Resource Record - - The TKEY resource record (RR) has the structure given below. Its RR - type code is 249. - - Field Type Comment - ----- ---- ------- - - NAME domain see description below - TTYPE u_int16_t TKEY - CLASS u_int16_t ignored, should be zero - TTL u_int32_t SHOULD be zero - RDLEN u_int16_t size of RDATA - RDATA: Algorithhm: domain - Inception: u_int32_t - Expiration: u_int32_t - Mode: u_int16_t - Error: u_int16_t - Key Size: u_int16_t - Key Data: octet-stream - Other Size: u_int16_t - Other Data: octet-stream undefined by this protocol - - The Name field's meaning differs somewhat with mode and context as - explained in subsequent sections. - - The TTL field SHOULD always be zero to be sure that older DNS - implementations do not cache TKEY RRs. - - The algorithm name is a domain name with the same meaning as in - [draft-ietf-dnsind-tsig-*.txt]. The algorithm determines how the - secret keying material exchanged using the TKEY RR is actually used - to derive the algorithm specific key that is used. - - The inception time and expiration time are in number of seconds since - the beginning of 1 January 1970 GMT ignoring leap seconds treated as - modulo 2**32 using ring arithmetic [RFC 1982]. In messages between a - DNS resolver to a DNS server where these fields are meaningful, they - are the either requested validity interval for the keying material - asked for or specify the validity interval of keying material - provided. To avoid reply attack, to keying material used to - authenticate TKEY keying material MUST NOT have a lifetime of more - then 2**31 seconds. This applies to keying material used in either a - TSIG or a SIG(0) transacation or request signature. - - The mode field specifies the general scheme for key agreement. Note - that implementation of TKEY as a whole and of any particular mode is - optional. The following values of the Mode octet are defined or - reserved: - - - -Donald E. Eastlake, 3rd [Page 6] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - - Value Description - ----- ----------- - 0 - reserved - 1 server/responder assignment - 2 Diffie-Hellman exchange - 3 GSS-API negotiation - 4 resolver/querier assignment - 5 key deletion - 6-65534 - available, see IANA considerations section - 65535 -reserved - - The error code field is an extended RCODE. The following values are - defined: - Value Description - ----- ----------- - 0 - no error - 1-15 a DNS RCODE - 16 BADSIG - 17 BADKEY - 18 BADTIME - 19 BADMODE - - The key data size field is an unsigned 16 bit integer in network - order which specifies the size of the key exchange data field in - octets. The meaning of the key data depends on the mode. - - The Other Size and Other Data fields are not used. The RDLEN field - MUST equal the length of the RDATA section through the end of other - data or the RR is to be considered malformed and rejected. - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 7] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -3. Exchange via Resolver Query - - One method for a resolver and a server to establish a shared secret - key for use in TSIG is through queries from the resolver for type - TKEY. Such queries MUST either be accompanied by one or more TKEY - RRs in the additional information section to indicate the mode(s) in - use and other information where required or the resolver and server - must have a prior agreement that supplies any information that would - otherwise have had to be conveyed by TKEY RR(s) in the query. - - For TKEY(s) appearing in a query, the TKEY RR name SHOULD be a domain - locally unique at the resolver (or globally unique), less than 128 - octets long, and meaningful to the resolver to distinguish keys - and/or key agreement sessions. (For resolvers not wishing to make - this use of the name, it may be specified as root to minimize - length.) For TKEY(s) appearing in a response to a query, the TKEY RR - name SHOULD be a globally unique server assigned domain. If the TKEY - in a response is the result of a query containing a TKEY with a non- - root name, that query TKEY name SHOULD be incorporated as the prefix - of the response TKEY name. - - Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY - ignore the recursive header bit in TKEY queries they receive. - - For every mode defined below, the inception and expiration times in a - query TKEY are set to the time interval for which the resolver wishes - the requested key to be valid and they are set in a successful - response to the actual time interval during which the server will - consider the key valid. Future modes may be defined which ignore the - inception and expiration time fields. - - - -3.1 Query for Server Assigned Keying - - In server assigned keying, the DNS server host generates the keying - material and it is sent to the resolver encrypted under a resolver - host key. See section 6 for description of encryption methods. - - A resolver sends a query for type TKEY accompanied by a TKEY RR - specifying the "server assignment" mode and a resolver host KEY RR to - be used in encrypting the response, both in the additional - information section. The TKEY algorithm field is set to the signature - algorithm the resolver plans to use. It is recommended that any "key - data" provided in the query TKEY be strongly mixed with server - generated randomness [RFC 1750] to derive the keying material to be - used. The KEY that appears in the query SHOULD have a zero TTL. It - need not be accompanied by a SIG(KEY) and if the query is signed by - the resolver host and that signature is verified, then any SIG(KEY) - provided MAY be ignored for key exchange purposes. The KEY RR in - - -Donald E. Eastlake, 3rd [Page 8] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - - such a query SHOULD have a name that corresponds to the resolver host - but it is only essential that it be a public key for which the - resolver has the corresponding private key so it can decrypt the - response data. - - Accepting and responding to an unsigned query of this sort may drain - some entropy from an entropy pool being maintained by the server and - used for secret key generation and so might enable an entropy - exhaustion attack. In addition, some significant amount of - computational resources may be used in the public key encryption of - response data. To protect against these effects, a server SHOULD - require such a query to be signed and MAY rate limit responses. - - The server response contains a TKEY in its answer section with the - server assigned mode. If the error field is non-zero, the query - failed for the reason given. If the error field is zero, the KEY RR - provided in the query will be echoed back and the key data portion of - the response TKEY RR will be the server assigned keying data - encrypted under the public key in the KEY RR. The name of the TKEY - RR will be the server assigned name of the key and SHOULD be globally - unique. - - - -3.2 Query for Diffie-Hellman Exchanged Keying - - Diffie-Hellman (DH) key exchange is means whereby two parties can - derive some shared secret information without requiring any secrecy - of the messages they exchange [Schneier]. Provisions have been made - for the storage of DH public keys in the DNS [draft-ietf-dnssec-dhk- - *.txt]. - - A client sends a query for type TKEY accompanied by a TKEY RR in the - additional information section specifying the "Diffie-Hellman" mode - and accompanied by a KEY RR specifying a client host Diffie-Hellman - key. The TKEY algorithm field is set to the signature algorithm the - resolver plans to use and any "key data" provided is ignored by the - server. - - Accepting and responding to an unsigned query of this sort may use - significant computation at the server; however, if the server - requires that the request be signed, then if no shared secret is in - place to permit a TSIG to be used on the request, it would be - necessary to use a SIG(0) the verification of which would impose its - own computational load. - - The server response contains a TKEY in its answer section with the - Diffie-Hellman mode. If the error field is non-zero, the query failed - for the reason given. If the error field is zero, the client host - supplied Diffie-Hellman KEY should be echoed back and a server host - - -Donald E. Eastlake, 3rd [Page 9] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - - Diffie-Hellman KEY RR will also be present. - - Both parties can calculate the same shared secret quantity from the - pair of Diffie-Hellman keys used [Schneier] provided they use the - same modulus. If the server host does not have an appropriate - Diffie-Hellman key to use for the exchange, it should return the - BADKEY error. - - - -3.3 Query for GSS-API Established - - This is described in a separate document [draft-skwan-gss-tsig-*.txt] - which should be seen for the full description. Basically, when an - acceptable symmetric key is not yet in place, the resolver can send a - query for type TKEY with a TKEY specifying the GSS-API mode in the - additional information section and a GSS-API token in the key data - portion. The server responds with a TKEY specifying the GSS-API mode - and a GSS-API token in the key data portion. The resolver and server - feed these tokens to their local GSS implementation and interate - until an error is encountered or a key (GSS-API session) is - established. A similar exchange can be used to delete a GSS-API - session. - - Any issues of possible encryption of the GSS-API token data being - transmitted are handled by the GSS-API level. In addition, the GSS- - API level provides authentication so that this mode of TKEY query and - response MAY be, but do not need to be, signed with TSIG or SIG(0). - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 10] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -4. Spontaneous Server Inclusion - - A DNS server may include TKEY RRs spontaneously as additional - information in responses. This SHOULD only be done if the server - knows the querier understands TKEY and has this option implemented. - This technique can be used to establish a server assigned key, a - Diffie-Hellman exchange key, for GSS-API exchange, and to delete a - key. A disadvantage of this technique is that there is no way for - the server to get any immediate error or success indication back and, - in the case of UDP, no way to even know if the DNS response reached - the resolver. - - - -4.1 Spontaneous Server Assigned Keying - - A server can include in the additional information section of a - response a server assignment mode TKEY with encrypted keying material - in its key data section along with a KEY RR specifying the client - public key used for the encryption. Such a response SHOULD be signed - but the KEY RR need not be signed by a SIG(KEY). A server should - only do this if there is sufficient room in a query and it has reason - to believe the resolver will understand such additional data. The - KEY RR used MUST be one for which the resolver host has the - corresponding private key or it will not be able to decrypt the - keying material. - - - -4.2 Spontaneous Diffie-Hellman Keying - - A server can include in the additional information section of a - response a Diffie-Hellman exchange mode TKEY along with two KEY RRs - specifying the client and server host public keys used for the - exchange. Such a response SHOULD be signed but the KEY RRs need not - be signed by a SIG(KEY). A server should only do this if there is - sufficient room in a query and it has reason to believe the resolver - host will understand such additional data. - - - -4.3 Spontaneous GSS-API Exchange - - A server can spontaneously include in the additional information - section of a response, a GSS-API mode TKEY. The information in the - key data section of such a TKEY is a GSS-API token which SHOULD be - fed by the resolver to its local GSS-API implementation. If such a - response is signed, the signature must verify before processing the - data. To the extent that GSS-API provides its own security, such a - response may not need to be signed. To the extent that GSS-API - - -Donald E. Eastlake, 3rd [Page 11] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - - handles duplicated messages, such a spontaneous TKEY can be sent - repeatedly, until, perhaps, a response via a GSS-API mode TKEY query - is received. - - - -4.4 Spontaneous Key Deletion - - A server can hint to a client that it has deleted a symmetric key by - spontaneously including a TKEY RR in the additional information - section of a response with the key's name and specifying the key - deletion mode. Such a response SHOULD be signed. If authenticated, - it deletes all keys with the given name whose effective time period - overlaps the inception to expiration period given in the TKEY. (If - the inception time of one symmetric key is equal to the expiration - time of another, or vice versa, they do not overlap.) Failure by a - client to receive or properly process such additional information in - a response would simply mean that the client might use a key that the - server had discarded and then get an error indication. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 12] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -5. TKEY Dynamic Update Requests - - If a DNS server supports dynamic update [RFC 2136], then dynamic - update request can be used to exchange resolver assigned symmetric - keys as described in section 5.1 below and to delete previously - exchanged keys from a server as described in section 5.2 below. - - - -5.1 Exchange via TKEY 'Add' - - Optionally, a server can accept resolver assigned keys. The keying - material must be encrypted under a server host key for protection in - transmission as described in Section 6. - - The resolver sends an update request to add a TKEY RR that specifies - the keying data with a KEY RR in the additional information section - specifying the server host public key used to encrypt the data. The - name of the key and the keying data are completely controlled by the - sending resolver so a globally unique key name SHOULD be used. The - server SHOULD require that this request be signed with a TSIG, if - there already exists an appropriate shared secret, or a SIG(0) by the - resolver host. The KEY RR used MUST be one for which the server has - the corresponding private key or it will not be able to decrypt the - keying material. - - - -5.2 TKEY Deletion - - Keys established via TKEY can be treated as soft state. Since DNS - transactions are originated by the resolver, the resolver can simply - toss keys, although it may have to go through another key exchange if - it later needs one. Similarly, the server can discard keys although - that will result in an error on receiving a query with a TSIG using - the discarded key. - - The key expiration provided in the TKEY and the ability of each party - to discard keys may be adequate but servers that support dynamic - update [RFC 2136] may optionally implement key deletion whereby the - server discards a key on receipt from a resolver of a delete request - for a TKEY with the key's name. The mode and most fields of the TKEY - being "deleted" are ignored. But, to allow for the possibility of - multiple keys with the same name but different time periods, the only - key deleted are those whose time period overlaps with that specified - by the inception and expiration in the TKEY being "deleted". - - - - - - -Donald E. Eastlake, 3rd [Page 13] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -6. Methods of Encryption - - For the server assigned and resolver assigned key exchange, the - keying material is sent within the key data field of a TKEY RR - encrypted under the private key corresponding to the public key in an - accompanying KEY RR [draft-ietf-dnssec-secext2-*.txt]. The secret - keying material being send will generally be fairly short, usually - less than 256 bits, because that is adequate for very strong - protection with modern keyed hash or symmetric algorithms. - - If the KEY RR specifies the RSA algorithm, then the keying material - is encrypted as per the description of RSA encryption in PKCS-1. - (Note, the secret keying material being sent is directly RSA - encrypted in PKCS-1 format, It is not "enveloped" under some other - symmetric algorithm.) In the unlikely event that the keying material - will not fit within one RSA modulus of the chosen public key, - additional RSA encryption blocks are included. The length of each - block is clear from the public RSA key specified and the PKCS-1 - padding makes it clear what part of the encrypted data is actually - keying material and what part is formatting or the required at least - eight bytes of random [RFC 1750] padding. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 14] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -7. IANA Considerations - - Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF - can only be assigned by an IETF standards action excluding - Experimental Standards (and 1 through 5 are assigned by this Proposed - Standard). Special consideration should be given before the - allocation of meaning for Mode field values 0x0000 and 0xFFFF. - - Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF - are allocated by an IETF consensus (i.e., at this time, an IESG vote) - excluding Experimental Standards. - - Mode field values 0x1000 through 0xEFFF are allocated based on RFC - documentation of their use or the issuance of an Experimental - Standard. - - Mode values should not be changed when the status of their use - changes. I.E. a mode value assigned for an Experimental Standard - should not be changed later just because that standard's status is - changed to Proposed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 15] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -8. Security Considerations - - To avoid different interpretations of the inception and expiration - times in TKEY RRs, resovlers and servers exchanging them must have - the same idea of what time it is. One way of doing this is with the - NTP protocol [RFC 2030] but that or any other time synchronization - MUST be done securely. - - It is recommended that the server require TKEY queries be signed. - However, for currently defined modes, relatively little damage will - be done if an unsigned query of this sort is accepted and processed, - as described below for each mode. In addition, requiring that a TKEY - query be signed by a TSIG (if there exists an acceptable exchanged - key between the parties) or a SIG(0) may itself impose significant - computational requirements on the server, particularly in verifying - SIG(0) public key signatures. - - Responses to TKEY queries SHOULD always have DNS transaction - signatures to protect the integrity of any keying data, error codes, - etc. This signature, if present, MUST use a previously established - secret (TSIG) or public (SIG(0)) key and MUST NOT use any key that - the response to be verified is itself providing. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 16] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -References - - PKCS-1 - RSA Encryption Standard (An RSA Laboratories Technical - Note). - - RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", - STD 13, November 1987. - - RFC 1035 - P. Mockapetris, "Domain Names - Implementation and - Specifications", STD 13, November 1987. - - RFC 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness - Recommendations for Security", December 1994. - - RFC 1982 - Robert Elz, Rrandy Bush, "Serial Number Arithmetic", - 09/03/1996. - - RFC 1995 - Masatka Ohta, "Incremental Zone Transfer in DNS", August - 1996. - - RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 - for IPv4, IPv6 and OSI", October 1996. - - RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. - - draft-ietf-dnsind-tsig-*.txt - P. Vixie, O. Gudmundsson, D. - Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". - - draft-ietf-dnssec-dhk-*.txt - D. Eastlake - - draft-ietf-dnssec-update2-*.txt - Donald E. Eastlake 3rd, "Secure - Domain Name System Dynamic Update". - - draft-ietf-dnssec-secext2-*.txt - Donald E. Eastlake 3rd, "Domain - Name System Security Extensions". - - draft-skwan-gss-tsig-*.txt - S. Kwan, P. Garg, R. Viswanathan, "GSS - Algorithm for TSIG (GSS-TSIG)" - - [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C", 1996, John Wiley and Sons - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 17] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -Author's Address - - Donald E. Eastlake 3rd - IBM - 318 Acton Street - Carlisle, MA 01741 USA - - Telephone: +1 978 287 4877 - +1 914 784 7913 - FAX: +1 978 371 7148 - email: dee3@us.ibm.com - - - -Expiration and File Name - - This draft expires March 1999. - - Its file name is draft-ietf-dnssec-tkey-01.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 18] - diff --git a/doc/expired/draft-ietf-dnssec-update2-00.txt b/doc/expired/draft-ietf-dnssec-update2-00.txt deleted file mode 100644 index 860f5fa92a..0000000000 --- a/doc/expired/draft-ietf-dnssec-update2-00.txt +++ /dev/null @@ -1,871 +0,0 @@ - - -INTERNET-DRAFT Donald E. Eastlake 3rd -OBSOLETES RFC 2137 Transfinite Systems Company -Expires: February 1999 August 1998 - - - - Secure Domain Name System (DNS) Dynamic Update - ------ ------ ---- ------ ----- ------- ------ - - - - - -Status of This Document - - This draft, file name draft-ietf-dnssec-update2-00.txt, is intended - to become a Proposed Standard RFC obsoleting RFC 2137. Distribution - of this document is unlimited. Comments should be sent to the DNS - security mailing list or the author. - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - -Abstract - - Revised Domain Name System (DNS) protocol extensions to authenticate - the data in DNS and provide key distribution services have been - defined in draft-ietf-dnssec-secext2-*.txt, which obsoletes the - original DNS security protocol definition in RFC 2065. In addition, - symetric key DNS transaction signatures have been defined in draft- - ietf-dnsind-tsig-*.txt. Secure DNS Dynamic Update operations were - also been defined [RFC 2137] in connection RFC 2065. This document - updates secure dynamic update in light of draft-ietf-dnssec-secext2- - *.txt and draft-ietf-dnsind-tsig-*.txt. It describes how to use - digital signatures covering requests and data to secure updates and - restrict updates to those authorized to perform them as indicated by - the updater's possession of cryptographic keys. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - -Table of Contents - - Status of This Document....................................1 - - Abstract...................................................2 - - Table of Contents..........................................3 - - 1. Introduction............................................4 - 1.1. Overview of DNS Dynamic Update........................4 - 1.2. Overview of Public Key DNS Security...................4 - 1.3 Overview of Secret Key DNS Security....................5 - - 2. Two Basic Modes.........................................6 - 2.1. Mode A................................................6 - 2.2. Mode B................................................7 - - 3. Keys....................................................8 - 3.1. Update Keys...........................................8 - 3.1.1. Public Update Key Name Scope........................8 - 3.1.2. Public Update Key Class Scope.......................8 - 3.1.3. Public Update Key Signatory Field...................9 - 3.2. Zone Keys and Update Modes...........................10 - 3.3. Wildcard Public Key Punch Through....................11 - - 4. Update Signatures......................................13 - 4.1. Update Request Signatures............................13 - 4.2. Update Data Signatures...............................13 - - 5. Security Considerations................................14 - 6. IANA Considerations....................................14 - - References................................................15 - Author's Address..........................................15 - Expiration and File Name..................................15 - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - -1. Introduction - - Dynamic update operations have been defined for the Domain Name - System (DNS) in RFC 2136 but that RFC does not include a description - of security for those updates. Public key means of securing DNS data - and transactions and using it for public key distribution were - defined in RFC 2065 which has been updated by draft-ietf-dnssec- - sexect2-*.txt, and secret key means of securing DNS transactions are - defined in draft-ietf-dnsind-tsig-*.txt. - - This document provides techniques based on the updated DNS security - RFC draft-ietf-dnssec-sexect2-*.txt and draft-ietf-dnsind-tsig-*.txt - to authenticate DNS updates of secure zones. (Secret key signatures - could be used to authenticate updates on non-secured DNS zones. That - case In not considered in this document.) - - Familiarity with the DNS system [RFC 1034, 1035] is assumed. - Familiarity with the DNS security and dynamic update will be helpful. - - - -1.1. Overview of DNS Dynamic Update - - DNS dynamic update defines a new DNS opcode, new DNS request and - response structure if that opcode is used, and new error codes. An - update can specify complex combinations of deletion and insertion - (with or without pre-existence testing) of resource records (RRs) - with one or more owner names; however, all testing and changes for - any particular DNS update request are restricted to a single zone. - Updates occur at the primary server for a zone. - - The primary server for a dynamic zone must increment the zone SOA - serial number when an update occurs or the next time the SOA is - retrieved if one or more updates have occurred since the previous SOA - retrieval and the updates themselves did not update the SOA. - - - -1.2. Overview of Public Key DNS Security - - DNS security authenticates data in the DNS by also storing digital - signatures in the DNS as SIG resource records (RRs). A SIG RR - provides a digital signature on the set of all RRs with the same - owner name and class as the SIG and whose type is the type covered by - the SIG. The SIG RR cryptographically binds the covered RR set to - the signer, signature inception and expiration date, etc. There are - one or more keys associated with every secure zone and all data in - the secure zone is signed either by a zone key or by a dynamic update - key tracing its authority to a zone key. - - - -Donald E. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - - DNS security also defines transaction SIGs and request SIGs. - - Transaction SIGs appear at the end of a response. They authenticate - the response and bind it to the corresponding request using the key - of the host where the responding DNS server is. - - Request SIGs appear at the end of a request and authenticate the - request with the key of the submitting entity. - - DNS security also permits the storage of public keys in the DNS via - KEY RRs. These KEY RRs are also, of course, authenticated by SIG - RRs. KEY RRs for zones may be stored in their superzone and/or their - authoritive subzone servers so that the secure DNS tree of zones can - be traversed by a security aware resolver. - - - -1.3 Overview of Secret Key DNS Security - - draft-ietf-dnsind-tsig-*.txt provides a means for two processes that - share a secret key to authenticate DNS requests and responses sent - between them by appending TSIG digital signature RRs to those - requests and responses. Secret key digital signatures are generally - much faster to calculate and verify than public key digital - signatures. In addition, the need, in general, to cache KEY RRs and - perform the KEY-SIG chain verifications is avoided. - - However, the cost for this speed and simplicity in TSIG use is the - requirement to securely achieve key distribution or agreement between - the communicating processes and to achieve agreement as to the - authority represented by a correct TSIG on a requested using a - partciular key. - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - -2. Two Basic Modes - - A dynamic secure zone is any secure DNS zone that - (1) has a zone KEY RR signatory field indicates that updates are - implemented and either - (2a) contains one or more KEY RRs that can authorize dynamic - updates, i.e., entity or user KEY RRs with the signatory field - non-zero, or - (2b) has a primary server with one or more secret keys configured - to authorize updates requests and shared with one or more - update requesters. - - Note: 2a and 2b can both be true for a zone. - - There are two basic modes of dynamic secure zone which relate to the - update strategy, mode A and mode B. A summary comparison table is - given below and then each mode is described. - - SUMMARY OF DYNAMIC SECURE ZONE MODES - - CRITERIA: | MODE A | MODE B - =========================+====================+=================== - Definition: | Zone Key Off line | Zone Key On line - =========================+====================+=================== - Server Workload | Medium | High - -------------------------+--------------------+------------------- - Key Restrictions | Fine grain | Coarse grain - -------------------------+--------------------+------------------- - Dynamic Data Temporality | Transient | Permanent - -------------------------+--------------------+------------------- - Dynamic Key Rollover | No | Yes - -------------------------+--------------------+------------------- - - NOTE: The Mode A / Mode B distinction only effects the validation - and performance of update requests. It has no effect on retrievals. - - - -2.1. Mode A - - For mode A, the zone owner private key and static zone master file - are kept off-line for maximum security of the static zone contents. - - As a consequence, any dynamicly added or changed RRs are signed in - the secure zone by their authorizing dynamic update key and they are - backed up, along with this SIG RR, in a separate online dynamic - master file. In this type of zone, server computation is generally - reduced since the server need only check signatures on the update - data and request, which have already been signed by the updater - (generally a much faster operation than signing data) and update the - - -Donald E. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - - NXT RRs which need to be changed, if any. Because the dynamicly - added RRs retain their update KEY signed SIG, finer grained control - of updates can be implemented via the KEY RR signatory field (unique - name restriction and weak update key restriction). Because dynamic - data is only stored in the online dynamic master file and only - authenticated by dynamic keys which expire, updates are transient in - nature. Key rollover for an entity that can authorize dynamic - updates is more cumbersome since the authority of their key must be - traceable to a zone key and so, in general, they must securely - communicate a new key to the zone authority for manual transfer to - the off line static master file. NOTE: for this mode the zone SOA and - NXT RRs must be signed by a dynamic update key, which will be an end - entity key with an owner name of the zone name, and that private key - must be kept on line so that the SOA and NXTs can be changed for - updates. - - - -2.2. Mode B - - For mode B, the zone owner private key and master file are kept on- - line at the zone primary server. When authenticated updates succeed, - SIGs under the zone key for the resulting data (as well as possible - NXT and SOA changes) are calculated and these SIG (and possible - SOA/NXT) changes are entered into the zone and the unified on-line - master file. - - As a consequence, this mode generally requires more computational - effort on the part of the server as it computes zone data signatures - in addition to verifying the signatures on requests. Because signing - generally takes more effort than verification, these signatures - generally will take more effort to calculate than it would take to - verify the data signatures required in Mode A. Because the zone key - is used to sign all the zone data, the information as to who - originated the current state of dynamic RR sets and even that data is - the result of a dynamic update as opposed to coming from an original - master file, is lost, making unavailable the fine grain control of - some values of the KEY RR signatory field. In addition, the - incorporation of the updates into the primary master file and their - authentication by the zone key makes them permanent in nature. - Maintaining the zone key on-line also means that dynamic update keys - which are signed by the zone key can be dynamically updated in real - time since the zone key is available to dynamically sign new values. - - - - - - - - - -Donald E. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - -3. Keys - - Dynamic update requests depend on update keys as described in section - 3.1 below. In addition, the zone secure dynamic update mode and - availability of some options is indicated in the zone KEY(s). - Finally, a special rule is used in searching for KEYs to validate - updates as described in section 3.3. - - - -3.1. Update Keys - - All update requests to a secure zone must include signature(s) by one - or more private or secret keys that together can authorize that - update. In order for the Domain Name System (DNS) server executing - the update request to confirm this (1) any secret keys must be know - to it, along with the authority represented by the secret key, and - (2) any private key or keys must have the corresponding public key or - keys available to and authenticatable by that server as specially - flagged KEY Resource Records (RRs). - - The scope of authority of any secret keys is as configured at the - Server. Methods of describing and configuring such authority are not - discussed in this document. - - The scope of authority of public update keys is indicated by their - KEY RR owner name, class, and signatory field flags as described - below. In addition, such KEY RRs MUST be entity or user keys and not - have the authentication use prohibited bit on. - - All parts of the actual update MUST be within the scope/authority of - at least one of the keys used for a request SIG or TSIG on the update - request as described in section 4. - - - -3.1.1. Public Update Key Name Scope - - The owner name of any update authorizing KEY RR must (1) be the same - as the owner name of any RRs being added or deleted or (2) a wildcard - name including within its extended scope (see section 3.3) the name - of any RRs being added or deleted and those RRs must be in the same - zone. - - - -3.1.2. Public Update Key Class Scope - - The class of any update authorizing KEY RR must be the same as the - class of any RR's being added or deleted. - - -Donald E. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - -3.1.3. Public Update Key Signatory Field - - The four bit "signatory field" (see draft-ietf-dnssec-secext2-*.txt) - of any update authorizing KEY RR must be non-zero. The bits have the - meanings described below for non-zone keys (see section 3.2 for zone - type keys). - - UPDATE KEY RR SIGNATORY FIELD BITS - - 0 1 2 3 - +-----------+-----------+-----------+-----------+ - | zone | strong | unique | general | - +-----------+-----------+-----------+-----------+ - - Bit 0, zone control - If nonzero, this key is authorized to attach, - detach, and move zones by creating and deleting NS, glue A, and - zone KEY RR(s). If zero, the key can not authorize any update - that would effect such RRs. This bit is meaningful for both - type A and type B dynamic secure zones. An update attempting to - add an NS or zone KEY RR to a node (i.e., make the node a - delegation point) is illegal if there are any deeper nodes in - the zone. - - NOTE: do not confuse the "zone" signatory field bit with the - "zone" key type bit. - - Bit 1, strong update - If zero, the key can only authorize updates - where any existing RRs of the same owner and class are - authenticated by a SIG using the same key. If nonzero, this key - is authorized to add and delete RRs even if there are other RRs - with the same owner name and class that are authenticated by a - SIG signed with a different dynamic update KEY. This bit is - meaningful only for type A dynamic zones that have a zone KEY - advertising that the feature is available. It is ignored in - type B dynamic zones. - - Keeping this bit zero on multiple KEY RRs with the same or - nested wild card owner names permits multiple entities to exist - that can create and delete names but can not effect RRs with - different owner names from any they created. In effect, this - creates two levels of dynamic update key, strong and weak, where - weak keys are prohibited from interfering with each other but a - strong key can interfere with any weak keys or other strong - keys. - - Bit 2, unique name update - This bit is useful only if the owner name - is a wildcard. (Any dynamic update KEY with a non-wildcard name - is, in effect, a unique name update key.) If zero, this key is - authorized to add and updates RRs for any number of names within - its wildcard scope. If nonzero, this key is authorized to add - - -Donald E. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - - and update RRs for only a single owner name. If there already - exist RRs with one or more names signed by this key, they may be - updated but no new name created until the number of existing - names is reduced to zero. This bit is meaningful only for mode - A dynamic zones that have a zone KEY advertising that the - feature is available. It is ignored in mode B dynamic zones. - - This bit can be used to restrict a KEY from flooding a zone with - new names. In conjunction with a local administratively imposed - limit on the number of dynamic RRs with a particular name, it - can completely restrict a KEY from flooding a zone with RRs. - - Bit 3, general update - The general update signatory field bit has no - special meaning. If the other three bits are all zero, it must - be one so that the field is non-zero to designate that the key - is an update key. The meaning of all values of the signatory - field with the general bit on and one or more other signatory - field bits on is reserved. - - All the signatory bit update authorizations described above only - apply if the update is within the name and class scope as per - sections 3.1.1 and 3.1.2. - - - -3.2. Zone Keys and Update Modes - - Zone type keys are automatically authorized to sign anything in their - zone, of course, regardless of the value of their signatory field. - For zone keys, the signatory field bits have different means than - they they do for update keys, as shown below. The signatory field - MUST be zero if dynamic update is not supported for a secure zone and - MUST be non-zero if it is. - - - ZONE KEY RR SIGNATORY FIELD BITS - - 0 1 2 3 - +-----------+-----------+-----------+-----------+ - | mode | strong | unique | general | - +-----------+-----------+-----------+-----------+ - - Bit 0, mode - This bit indicates the update mode for this zone. Zero - indicates mode A while a one indicates mode B. - - Bit 1, strong update - If nonzero, this indicates that the "strong" - key feature described in section 3.1.3 above is implemented and - enabled for this secure zone. If zero, the feature is not - available and all update keys are treated as strong. Has no - effect if the zone is a mode B secure update zone. - - -Donald E. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - - Bit 2, unique name update - If nonzero, this indicates that the - "unique name" feature described in section 3.1.3 above is - implemented and enabled for this secure zone. If zero, this - feature is not available and no wildcard update key is treated - as restricted to a single name. Has no effect if the zone is a - mode B secure update zone. - - Bit 3, general - This bit has no special meaning. If dynamic update - for a zone is supported and the other bits in the zone key - signatory field are zero, it must be a one. The meaning of zone - keys where the signatory field has the general bit and one or - more other bits on is reserved. - - If there are multiple zone KEY RRs with non-zero signatory fields and - zone policy is in transition, they might have different signatory - field values. In that case, strong and unique name restrictions MUST - be enforced as long as there is a non-expired zone key being - advertised that indicates mode A with the strong or unique name bit - on respectively. Mode B updates (i.e., no data signatures) MUST be - supported as long as there is a non-expired zone key that indicates - mode B. Mode A or mode ambiguous updates may be treated as mode B - updates at server option if non-expired zone keys indicate that both - are supported. - - A server that will be executing update operations on a zone, that is, - the primary master server, MUST NOT advertize a zone key that will - attract requests for a mode or features that it can not support. - - - -3.3. Wildcard Public Key Punch Through - - Just as a zone key is valid throughout the entire zone, public update - keys with wildcard names are valid throughout their extended scope, - within the zone. That is, they remain valid for any name that would - match them, even existing specific names within their apparent scope. - - (If this were not so, then whenever a name within a wildcard scope - was created by dynamic update using a wildcard named public update - key for authorization, it would be necessary to first create a copy - of the KEY RR with this name, because otherwise the existence of the - more specific name would hide the authorizing KEY RR and would make - later updates impossible. An updater could create such a KEY RR but - could not zone sign it with their authorizing signer. They would - have to sign it with the same key using the wildcard name as signer. - (This would create update KEYs signed by update KEYs which was - permitted in RFC 2065 but, for simplicity, is prohibit in draft- - ietf-dnssec-secext2-*.txt which requires all KEYs to be signed by - zone keys.) Thus in creating, for example, one hundred type A RRs - authorized by a *.1.1.1.in-addr.arpa KEY RR, without key punch - - -Donald E. Eastlake 3rd [Page 11] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - - through 100 As, 100 KEYs, and 200 SIGs would have to be created as - opposed to merely 100 As and 100 SIGs with wildcard key punch - through.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 12] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - -4. Update Signatures - - Two kinds of signatures can appear in updates. Request signatures, - which are always required, cover the entire request and authenticate - the DNS header, including opcode, counts, etc., as well as the data. - Data signatures, on the other hand, appear only among the RRs to be - added and are only required for mode A operation. These two types of - signatures are described further below. - - - -4.1. Update Request Signatures - - An update can effect multiple owner names in a zone. It may be that - these different names are covered by different public or secret - dynamic update keys. For every owner name effected, the updater must - know a private or secret key valid to authorize updates for that name - (and the zone's class) and must prove this by appending request SIG - and/or TSIG RRs under each such key. - - Request signatures occur in the Additional Information section. As - specified in draft-ietf-dnssec-secext2-*.txt, a public request - signature is a SIG RR occurring at the end of a request with a type - covered field of zero. As specified in draft-ietf-dnsind-tsig-*.txt, - a secret key request signature is a TSIG RR occuring at the end of - the request. Each request SIG or TSIG signs the entire request, - including DNS header, but excluding any other request signatures and - with the ARCOUNT in the DNS header set to what it would be without - the request signatures. - - - -4.2. Update Data Signatures - - Mode A dynamic secure zones require that the update requester provide - SIG RRs that will authenticate the after-update state of all RR sets - that are changed by the update and are non-empty after the update. - These SIG RRs appear in the request as RRs to be added and the - request must delete any previous data SIG RRs that are invalidated by - the request. - - In Mode B dynamic secure zones, all zone data is authenticated by - zone key SIG RRs. In this case, data signatures need not be included - with the update. A prospective updater can determine which mode an - updatable secure zone is using by examining the signatory field bits - of the zone KEY RR or RRs (see section 3.2). - - - - - - -Donald E. Eastlake 3rd [Page 13] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - -5. Security Considerations - - Any secure zone permitting dynamic updates is inherently less secure - than a static secure zone maintained off line as recommended in - draft-ietf-dnssec-secops-*.txt. If nothing else, secure dynamic - update requires on line change to and re-signing of the zone SOA - resource record (RR) to increase the SOA serial number. This means - that compromise of the primary server host could lead to arbitrary - serial number changes. - - Isolation of dynamic RRs to separate zones from those holding most - static RRs can limit the damage that could occur from breach of a - dynamic zone's security. - - - -6. IANA Considerations - - Allocations of values of the KEY RR Signatory field described herein - as "reserved" requires an IETF consensus. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 14] - - -INTERNET-DRAFT Secure DNS Update August 1998 - - -References - - [RFC1035] - Domain Names - Implementation and Specifications, P. - Mockapetris, November 1987. - - [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, - November 1987. - - [RFC2065] - Domain Name System Security Extensions. D. Eastlake, 3rd, - C. Kaufman. January 1997 - - [RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE). - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. - - [RFC2137] - Secure Domain Name System Dynamic Update. D. Eastlake. - April 1997. - - draft-ietf-dnsind-tsig-*.txt - - draft-ietf-dnssec-secext2-*.txt. - - draft-ietf-dnssec-secops-*.txt. - - - -Author's Address - - Donald E. Eastlake, 3rd - Transfinite Systems Company - 318 Acton Street - Carlisle, MA 01741 USA - - Telephone: +1 978-287-4877 - +1 978-371-7148 (fax) - email: dee3@torque.pothole.com - - - -Expiration and File Name - - This draft expires February 1999. - - Its file name is draft-ietf-dnssec-update2-00.txt. - - - - - - - - - -Donald E. Eastlake 3rd [Page 15] - diff --git a/doc/expired/draft-ietf-ipngwg-2292bis-00.txt b/doc/expired/draft-ietf-ipngwg-2292bis-00.txt deleted file mode 100644 index c25ce740ed..0000000000 --- a/doc/expired/draft-ietf-ipngwg-2292bis-00.txt +++ /dev/null @@ -1,3531 +0,0 @@ - - - - - - -INTERNET-DRAFT W. Richard Stevens (Consultant) -Expires: December 24, 1999 Matt Thomas (Consultant) -Obsoletes RFC 2292 Erik Nordmark (Sun) - June 24, 1999 - - - Advanced Sockets API for IPv6 - - - - -Abstract - - A separate specification [RFC-2553] contain changes to the sockets - API to support IP version 6. Those changes are for TCP and UDP-based - applications and will support most end-user applications in use - today: Telnet and FTP clients and servers, HTTP clients and servers, - and the like. - - But another class of applications exists that will also be run under - IPv6. We call these "advanced" applications and today this includes - programs such as Ping, Traceroute, routing daemons, multicast routing - daemons, router discovery daemons, and the like. The API feature - typically used by these programs that make them "advanced" is a raw - socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge - of the packet header formats used by these protocols. To provide - portability for applications that use raw sockets under IPv6, some - standardization is needed for the advanced API features. - - There are other features of IPv6 that some applications will need to - access: interface identification (specifying the outgoing interface - and determining the incoming interface) and IPv6 extension headers - that are not addressed in [RFC-2553]: The Routing header (source - routing), Hop-by-Hop options, and Destination options. This document - provides API access to these features too. - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 1] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet Draft expires December 24, 1999. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 2] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - -Table of Contents - - 1. Introduction .................................................... 6 - - 2. Common Structures and Definitions ............................... 7 - 2.1. The ip6_hdr Structure ...................................... 7 - 2.1.1. IPv6 Next Header Values ............................. 8 - 2.1.2. IPv6 Extension Headers .............................. 8 - 2.2. The icmp6_hdr Structure .................................... 10 - 2.2.1. ICMPv6 Type and Code Values ......................... 11 - 2.2.2. ICMPv6 Neighbor Discovery Type and Code Values ...... 12 - 2.3. Address Testing Macros ..................................... 14 - 2.4. Protocols File ............................................. 15 - - 3. IPv6 Raw Sockets ................................................ 15 - 3.1. Checksums .................................................. 17 - 3.2. ICMPv6 Type Filtering ...................................... 17 - - 4. Access to IPv6 and Extension Headers ............................ 20 - 4.1. TCP Implications ........................................... 21 - 4.2. UDP and Raw Socket Implications ............................ 22 - - 5. Packet Information .............................................. 23 - 5.1. Specifying/Receiving the Interface ......................... 24 - 5.2. Specifying/Receiving Source/Destination Address ............ 25 - 5.3. Specifying/Receiving the Hop Limit ......................... 25 - 5.4. Specifying the Next Hop Address ............................ 26 - 5.5. Additional Errors with sendmsg() and setsockopt() .......... 26 - - 6. Routing Header Option ........................................... 27 - 6.1. inet6_rth_space ............................................ 28 - 6.2. inet6_rth_init ............................................. 29 - 6.3. inet6_rth_add .............................................. 29 - 6.4. inet6_rth_reverse .......................................... 29 - 6.5. inet6_rth_segments ......................................... 30 - 6.6. inet6_rth_getaddr .......................................... 30 - - 7. Hop-By-Hop Options .............................................. 30 - 7.1. Receiving Hop-by-Hop Options ............................... 31 - 7.2. Sending Hop-by-Hop Options ................................. 31 - - 8. Destination Options ............................................. 32 - 8.1. Receiving Destination Options .............................. 32 - 8.2. Sending Destination Options ................................ 33 - - 9. Hop-by-Hop and Destination Options Processing ................... 33 - 9.1. inet6_opt_init ............................................. 34 - 9.2. inet6_opt_append ........................................... 34 - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 3] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - 9.3. inet6_opt_finish ........................................... 35 - 9.4. inet6_opt_set_val .......................................... 35 - 9.5. inet6_opt_next ............................................. 35 - 9.6. inet6_opt_find ............................................. 36 - 9.7. inet6_opt_get_val .......................................... 36 - - 10. Ordering of Ancillary Data and IPv6 Extension Headers ........... 37 - - 11. IPv6-Specific Options with IPv4-Mapped IPv6 Addresses ........... 37 - - 12. Extended interfaces for rresvport, rcmd and rexec ............... 38 - 12.1. rresvport_af .............................................. 38 - 12.2. rcmd_af ................................................... 38 - 12.3. rexec_af .................................................. 39 - - 13. Future Items .................................................... 39 - 13.1. Flow Labels ............................................... 39 - 13.2. Path MTU Discovery and UDP ................................ 39 - 13.3. Neighbor Reachability and UDP ............................. 39 - - 14. Summary of New Definitions ...................................... 39 - - 15. Security Considerations ......................................... 42 - - 16. Compatibility with RFC 2292 ..................................... 43 - - 17. Change History .................................................. 43 - - 18. TODO and Open Issues ............................................ 44 - - 19. References ...................................................... 45 - - 20. Acknowledgments ................................................. 46 - - 21. Authors' Addresses .............................................. 46 - - 22. Appendix A: Ancillary Data ...................................... 46 - 22.1. The msghdr Structure ...................................... 47 - 22.2. The cmsghdr Structure ..................................... 48 - 22.3. Ancillary Data Object Macros .............................. 49 - 22.3.1. CMSG_FIRSTHDR ...................................... 50 - 22.3.2. CMSG_NXTHDR ........................................ 51 - 22.3.3. CMSG_DATA .......................................... 52 - 22.3.4. CMSG_SPACE ......................................... 52 - 22.3.5. CMSG_LEN ........................................... 53 - - 23. Appendix B: Examples using the inet6_rth_XXX() functions ........ 53 - 23.1. Sending a Routing Header .................................. 53 - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 4] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - 23.2. Receiving Routing Headers ................................. 58 - - 24. Appendix C: Examples using the inet6_opt_XXX() functions ........ 60 - 24.1. Building options .......................................... 60 - 24.2. Parsing received options .................................. 62 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 5] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - -1. Introduction - - A separate specification [RFC-2553] contain changes to the sockets - API to support IP version 6. Those changes are for TCP and UDP-based - applications. This document defines some the "advanced" features of - the sockets API that are required for applications to take advantage - of additional features of IPv6. - - Today, the portability of applications using IPv4 raw sockets is - quite high, but this is mainly because most IPv4 implementations - started from a common base (the Berkeley source code) or at least - started with the Berkeley headers. This allows programs such as Ping - and Traceroute, for example, to compile with minimal effort on many - hosts that support the sockets API. With IPv6, however, there is no - common source code base that implementors are starting from, and the - possibility for divergence at this level between different - implementations is high. To avoid a complete lack of portability - amongst applications that use raw IPv6 sockets, some standardization - is necessary. - - There are also features from the basic IPv6 specification that are - not addressed in [RFC-2553]: sending and receiving Routing headers, - Hop-by-Hop options, and Destination options, specifying the outgoing - interface, and being told of the receiving interface. - - This document can be divided into the following main sections. - - 1. Definitions of the basic constants and structures required for - applications to use raw IPv6 sockets. This includes structure - definitions for the IPv6 and ICMPv6 headers and all associated - constants (e.g., values for the Next Header field). - - 2. Some basic semantic definitions for IPv6 raw sockets. For - example, a raw ICMPv4 socket requires the application to - calculate and store the ICMPv4 header checksum. But with IPv6 - this would require the application to choose the source IPv6 - address because the source address is part of the pseudo header - that ICMPv6 now uses for its checksum computation. It should be - defined that with a raw ICMPv6 socket the kernel always - calculates and stores the ICMPv6 header checksum. - - 3. Packet information: how applications can obtain the received - interface, destination address, and received hop limit, along - with specifying these values on a per-packet basis. There are a - class of applications that need this capability and the technique - should be portable. - - 4. Access to the optional Routing header, Hop-by-Hop, and - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 6] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - Destination extension headers. - - 5. Additional features required for improved IPv6 application - portability. - - The packet information along with access to the extension headers - (Routing header, Hop-by-Hop options, and Destination options) are - specified using the "ancillary data" fields that were added to the - 4.3BSD Reno sockets API in 1990. The reason is that these ancillary - data fields are part of the Posix.1g standard and should therefore be - adopted by most vendors. - - This document does not address application access to either the - authentication header or the encapsulating security payload header. - - All examples in this document omit error checking in favor of brevity - and clarity. - - We note that many of the functions and socket options defined in this - document may have error returns that are not defined in this - document. Many of these possible error returns will be recognized - only as implementations proceed. - - Datatypes in this document follow the Posix.1g format: intN_t means a - signed integer of exactly N bits (e.g., int16_t) and uintN_t means an - unsigned integer of exactly N bits (e.g., uint32_t). - - Note that we use the (unofficial) terminology ICMPv4, IGMPv4, and - ARPv4 to avoid any confusion with the newer ICMPv6 protocol. - - -2. Common Structures and Definitions - - Many advanced applications examine fields in the IPv6 header and set - and examine fields in the various ICMPv6 headers. Common structure - definitions for these headers are required, along with common - constant definitions for the structure members. - - Two new headers are defined: and . - - When an include file is specified, that include file is allowed to - include other files that do the actual declaration or definition. - - -2.1. The ip6_hdr Structure - - The following structure is defined as a result of including - . Note that this is a new header. - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 7] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - struct ip6_hdr { - union { - struct ip6_hdrctl { - uint32_t ip6_un1_flow; /* 8 bits traffic class, 24 bits flow-ID */ - uint16_t ip6_un1_plen; /* payload length */ - uint8_t ip6_un1_nxt; /* next header */ - uint8_t ip6_un1_hlim; /* hop limit */ - } ip6_un1; - uint8_t ip6_un2_vfc; /* 4 bits version, top 4 bits tclass */ - } ip6_ctlun; - struct in6_addr ip6_src; /* source address */ - struct in6_addr ip6_dst; /* destination address */ - }; - - #define ip6_vfc ip6_ctlun.ip6_un2_vfc - #define ip6_flow ip6_ctlun.ip6_un1.ip6_un1_flow - #define ip6_plen ip6_ctlun.ip6_un1.ip6_un1_plen - #define ip6_nxt ip6_ctlun.ip6_un1.ip6_un1_nxt - #define ip6_hlim ip6_ctlun.ip6_un1.ip6_un1_hlim - #define ip6_hops ip6_ctlun.ip6_un1.ip6_un1_hlim - - - -2.1.1. IPv6 Next Header Values - - IPv6 defines many new values for the Next Header field. The - following constants are defined as a result of including - . - - #define IPPROTO_HOPOPTS 0 /* IPv6 Hop-by-Hop options */ - #define IPPROTO_IPV6 41 /* IPv6 header */ - #define IPPROTO_ROUTING 43 /* IPv6 Routing header */ - #define IPPROTO_FRAGMENT 44 /* IPv6 fragmentation header */ - #define IPPROTO_ESP 50 /* encapsulating security payload */ - #define IPPROTO_AH 51 /* authentication header */ - #define IPPROTO_ICMPV6 58 /* ICMPv6 */ - #define IPPROTO_NONE 59 /* IPv6 no next header */ - #define IPPROTO_DSTOPTS 60 /* IPv6 Destination options */ - - Berkeley-derived IPv4 implementations also define IPPROTO_IP to be 0. - This should not be a problem since IPPROTO_IP is used only with IPv4 - sockets and IPPROTO_HOPOPTS only with IPv6 sockets. - - -2.1.2. IPv6 Extension Headers - - Six extension headers are defined for IPv6. We define structures for - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 8] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - all except the Authentication header and Encapsulating Security - Payload header, both of which are beyond the scope of this document. - The following structures are defined as a result of including - . - - /* Hop-by-Hop options header */ - struct ip6_hbh { - uint8_t ip6h_nxt; /* next header */ - uint8_t ip6h_len; /* length in units of 8 octets */ - /* followed by options */ - }; - - /* Destination options header */ - struct ip6_dest { - uint8_t ip6d_nxt; /* next header */ - uint8_t ip6d_len; /* length in units of 8 octets */ - /* followed by options */ - }; - - /* Routing header */ - struct ip6_rthdr { - uint8_t ip6r_nxt; /* next header */ - uint8_t ip6r_len; /* length in units of 8 octets */ - uint8_t ip6r_type; /* routing type */ - uint8_t ip6r_segleft; /* segments left */ - /* followed by routing type specific data */ - }; - - /* Type 0 Routing header */ - struct ip6_rthdr0 { - uint8_t ip6r0_nxt; /* next header */ - uint8_t ip6r0_len; /* length in units of 8 octets */ - uint8_t ip6r0_type; /* always zero */ - uint8_t ip6r0_segleft; /* segments left */ - uint32_t ip6r0_reserved; /* reserved field */ - struct in6_addr ip6r0_addr[1]; /* up to 127 addresses */ - }; - - /* Fragment header */ - struct ip6_frag { - uint8_t ip6f_nxt; /* next header */ - uint8_t ip6f_reserved; /* reserved field */ - uint16_t ip6f_offlg; /* offset, reserved, and flag */ - uint32_t ip6f_ident; /* identification */ - }; - - #if BYTE_ORDER == BIG_ENDIAN - #define IP6F_OFF_MASK 0xfff8 /* mask out offset from _offlg */ - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 9] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - #define IP6F_RESERVED_MASK 0x0006 /* reserved bits in ip6f_offlg */ - #define IP6F_MORE_FRAG 0x0001 /* more-fragments flag */ - #else /* BYTE_ORDER == LITTLE_ENDIAN */ - #define IP6F_OFF_MASK 0xf8ff /* mask out offset from _offlg */ - #define IP6F_RESERVED_MASK 0x0600 /* reserved bits in ip6f_offlg */ - #define IP6F_MORE_FRAG 0x0100 /* more-fragments flag */ - #endif - - Defined constants for fields larger than 1 byte depend on the byte - ordering that is used. This API assumes that the fields in the - protocol headers are left in the network byte order, which is big- - endian for the Internet protocols. If not, then either these - constants or the fields being tested must be converted at run-time, - using something like htons() or htonl(). - - (Note: We show an implementation that supports both big-endian and - little-endian byte ordering, assuming a hypothetical compile-time #if - test to determine the byte ordering. The constant that we show, - BYTE_ORDER, with values of BIG_ENDIAN and LITTLE_ENDIAN, are for - example purposes only. If an implementation runs on only one type of - hardware it need only define the set of constants for that hardware's - byte ordering.) - - -2.2. The icmp6_hdr Structure - - The ICMPv6 header is needed by numerous IPv6 applications including - Ping, Traceroute, router discovery daemons, and neighbor discovery - daemons. The following structure is defined as a result of including - . Note that this is a new header. - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 10] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - struct icmp6_hdr { - uint8_t icmp6_type; /* type field */ - uint8_t icmp6_code; /* code field */ - uint16_t icmp6_cksum; /* checksum field */ - union { - uint32_t icmp6_un_data32[1]; /* type-specific field */ - uint16_t icmp6_un_data16[2]; /* type-specific field */ - uint8_t icmp6_un_data8[4]; /* type-specific field */ - } icmp6_dataun; - }; - - #define icmp6_data32 icmp6_dataun.icmp6_un_data32 - #define icmp6_data16 icmp6_dataun.icmp6_un_data16 - #define icmp6_data8 icmp6_dataun.icmp6_un_data8 - #define icmp6_pptr icmp6_data32[0] /* parameter prob */ - #define icmp6_mtu icmp6_data32[0] /* packet too big */ - #define icmp6_id icmp6_data16[0] /* echo request/reply */ - #define icmp6_seq icmp6_data16[1] /* echo request/reply */ - #define icmp6_maxdelay icmp6_data16[0] /* mcast group membership */ - - - -2.2.1. ICMPv6 Type and Code Values - - In addition to a common structure for the ICMPv6 header, common - definitions are required for the ICMPv6 type and code fields. The - following constants are also defined as a result of including - . - - #define ICMP6_DST_UNREACH 1 - #define ICMP6_PACKET_TOO_BIG 2 - #define ICMP6_TIME_EXCEEDED 3 - #define ICMP6_PARAM_PROB 4 - - #define ICMP6_INFOMSG_MASK 0x80 /* all informational messages */ - - #define ICMP6_ECHO_REQUEST 128 - #define ICMP6_ECHO_REPLY 129 - #define ICMP6_MEMBERSHIP_QUERY 130 - #define ICMP6_MEMBERSHIP_REPORT 131 - #define ICMP6_MEMBERSHIP_REDUCTION 132 - - #define ICMP6_DST_UNREACH_NOROUTE 0 /* no route to destination */ - #define ICMP6_DST_UNREACH_ADMIN 1 /* communication with */ - /* destination */ - /* admin. prohibited */ - #define ICMP6_DST_UNREACH_NOTNEIGHBOR 2 /* not a neighbor */ - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 11] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - #define ICMP6_DST_UNREACH_ADDR 3 /* address unreachable */ - #define ICMP6_DST_UNREACH_NOPORT 4 /* bad port */ - - #define ICMP6_TIME_EXCEED_TRANSIT 0 /* Hop Limit == 0 in transit */ - #define ICMP6_TIME_EXCEED_REASSEMBLY 1 /* Reassembly time out */ - - #define ICMP6_PARAMPROB_HEADER 0 /* erroneous header field */ - #define ICMP6_PARAMPROB_NEXTHEADER 1 /* unrecognized Next Header */ - #define ICMP6_PARAMPROB_OPTION 2 /* unrecognized IPv6 option */ - - The five ICMP message types defined by IPv6 neighbor discovery - (133-137) are defined in the next section. - - -2.2.2. ICMPv6 Neighbor Discovery Type and Code Values - - The following structures and definitions are defined as a result of - including . - - #define ND_ROUTER_SOLICIT 133 - #define ND_ROUTER_ADVERT 134 - #define ND_NEIGHBOR_SOLICIT 135 - #define ND_NEIGHBOR_ADVERT 136 - #define ND_REDIRECT 137 - - struct nd_router_solicit { /* router solicitation */ - struct icmp6_hdr nd_rs_hdr; - /* could be followed by options */ - }; - - #define nd_rs_type nd_rs_hdr.icmp6_type - #define nd_rs_code nd_rs_hdr.icmp6_code - #define nd_rs_cksum nd_rs_hdr.icmp6_cksum - #define nd_rs_reserved nd_rs_hdr.icmp6_data32[0] - - struct nd_router_advert { /* router advertisement */ - struct icmp6_hdr nd_ra_hdr; - uint32_t nd_ra_reachable; /* reachable time */ - uint32_t nd_ra_retransmit; /* retransmit timer */ - /* could be followed by options */ - }; - - #define nd_ra_type nd_ra_hdr.icmp6_type - #define nd_ra_code nd_ra_hdr.icmp6_code - #define nd_ra_cksum nd_ra_hdr.icmp6_cksum - #define nd_ra_curhoplimit nd_ra_hdr.icmp6_data8[0] - #define nd_ra_flags_reserved nd_ra_hdr.icmp6_data8[1] - #define ND_RA_FLAG_MANAGED 0x80 - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 12] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - #define ND_RA_FLAG_OTHER 0x40 - #define nd_ra_router_lifetime nd_ra_hdr.icmp6_data16[1] - - struct nd_neighbor_solicit { /* neighbor solicitation */ - struct icmp6_hdr nd_ns_hdr; - struct in6_addr nd_ns_target; /* target address */ - /* could be followed by options */ - }; - - #define nd_ns_type nd_ns_hdr.icmp6_type - #define nd_ns_code nd_ns_hdr.icmp6_code - #define nd_ns_cksum nd_ns_hdr.icmp6_cksum - #define nd_ns_reserved nd_ns_hdr.icmp6_data32[0] - - struct nd_neighbor_advert { /* neighbor advertisement */ - struct icmp6_hdr nd_na_hdr; - struct in6_addr nd_na_target; /* target address */ - /* could be followed by options */ - }; - - #define nd_na_type nd_na_hdr.icmp6_type - #define nd_na_code nd_na_hdr.icmp6_code - #define nd_na_cksum nd_na_hdr.icmp6_cksum - #define nd_na_flags_reserved nd_na_hdr.icmp6_data32[0] - #if BYTE_ORDER == BIG_ENDIAN - #define ND_NA_FLAG_ROUTER 0x80000000 - #define ND_NA_FLAG_SOLICITED 0x40000000 - #define ND_NA_FLAG_OVERRIDE 0x20000000 - #else /* BYTE_ORDER == LITTLE_ENDIAN */ - #define ND_NA_FLAG_ROUTER 0x00000080 - #define ND_NA_FLAG_SOLICITED 0x00000040 - #define ND_NA_FLAG_OVERRIDE 0x00000020 - #endif - - struct nd_redirect { /* redirect */ - struct icmp6_hdr nd_rd_hdr; - struct in6_addr nd_rd_target; /* target address */ - struct in6_addr nd_rd_dst; /* destination address */ - /* could be followed by options */ - }; - - #define nd_rd_type nd_rd_hdr.icmp6_type - #define nd_rd_code nd_rd_hdr.icmp6_code - #define nd_rd_cksum nd_rd_hdr.icmp6_cksum - #define nd_rd_reserved nd_rd_hdr.icmp6_data32[0] - - struct nd_opt_hdr { /* Neighbor discovery option header */ - uint8_t nd_opt_type; - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 13] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - uint8_t nd_opt_len; /* in units of 8 octets */ - /* followed by option specific data */ - }; - - #define ND_OPT_SOURCE_LINKADDR 1 - #define ND_OPT_TARGET_LINKADDR 2 - #define ND_OPT_PREFIX_INFORMATION 3 - #define ND_OPT_REDIRECTED_HEADER 4 - #define ND_OPT_MTU 5 - - struct nd_opt_prefix_info { /* prefix information */ - uint8_t nd_opt_pi_type; - uint8_t nd_opt_pi_len; - uint8_t nd_opt_pi_prefix_len; - uint8_t nd_opt_pi_flags_reserved; - uint32_t nd_opt_pi_valid_time; - uint32_t nd_opt_pi_preferred_time; - uint32_t nd_opt_pi_reserved2; - struct in6_addr nd_opt_pi_prefix; - }; - - #define ND_OPT_PI_FLAG_ONLINK 0x80 - #define ND_OPT_PI_FLAG_AUTO 0x40 - - struct nd_opt_rd_hdr { /* redirected header */ - uint8_t nd_opt_rh_type; - uint8_t nd_opt_rh_len; - uint16_t nd_opt_rh_reserved1; - uint32_t nd_opt_rh_reserved2; - /* followed by IP header and data */ - }; - - struct nd_opt_mtu { /* MTU option */ - uint8_t nd_opt_mtu_type; - uint8_t nd_opt_mtu_len; - uint16_t nd_opt_mtu_reserved; - uint32_t nd_opt_mtu_mtu; - }; - - We note that the nd_na_flags_reserved flags have the same byte - ordering problems as we discussed with ip6f_offlg. - - -2.3. Address Testing Macros - - The basic API ([RFC-2553]) defines some macros for testing an IPv6 - address for certain properties. This API extends those definitions - with additional address testing macros, defined as a result of - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 14] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - including . - - int IN6_ARE_ADDR_EQUAL(const struct in6_addr *, - const struct in6_addr *); - - - -2.4. Protocols File - - Many hosts provide the file /etc/protocols that contains the names of - the various IP protocols and their protocol number (e.g., the value - of the protocol field in the IPv4 header for that protocol, such as 1 - for ICMP). Some programs then call the function getprotobyname() to - obtain the protocol value that is then specified as the third - argument to the socket() function. For example, the Ping program - contains code of the form - - struct protoent *proto; - - proto = getprotobyname("icmp"); - - s = socket(PF_INET, SOCK_RAW, proto->p_proto); - - Common names are required for the new IPv6 protocols in this file, to - provide portability of applications that call the getprotoXXX() - functions. - - We define the following protocol names with the values shown. These - are taken from ftp://ftp.isi.edu/in-notes/iana/assignments/protocol- - numbers. - - hopopt 0 # hop-by-hop options for ipv6 - ipv6 41 # ipv6 - ipv6-route 43 # routing header for ipv6 - ipv6-frag 44 # fragment header for ipv6 - esp 50 # encapsulating security payload for ipv6 - ah 51 # authentication header for ipv6 - ipv6-icmp 58 # icmp for ipv6 - ipv6-nonxt 59 # no next header for ipv6 - ipv6-opts 60 # destination options for ipv6 - - - -3. IPv6 Raw Sockets - - Raw sockets bypass the transport layer (TCP or UDP). With IPv4, raw - sockets are used to access ICMPv4, IGMPv4, and to read and write IPv4 - datagrams containing a protocol field that the kernel does not - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 15] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - process. An example of the latter is a routing daemon for OSPF, - since it uses IPv4 protocol field 89. With IPv6 raw sockets will be - used for ICMPv6 and to read and write IPv6 datagrams containing a - Next Header field that the kernel does not process. Examples of the - latter are a routing daemon for OSPF for IPv6 and RSVP (protocol - field 46). - - All data sent via raw sockets MUST be in network byte order and all - data received via raw sockets will be in network byte order. This - differs from the IPv4 raw sockets, which did not specify a byte - ordering and used the host's byte order for certain IP header fields. - - Another difference from IPv4 raw sockets is that complete packets - (that is, IPv6 packets with extension headers) cannot be sent or - received using the IPv6 raw sockets API. Instead, ancillary data - objects are used to transfer the extension headers and hoplimit - information, as described later in this document. Should an - application need access to the complete IPv6 packet, some other - technique, such as the datalink interfaces BPF or DLPI, must be used. - - All fields in the IPv6 header that an application might want to - change (i.e., everything other than the version number) can be - modified using ancillary data and/or socket options by the - application for output. All fields in a received IPv6 header (other - than the version number and Next Header fields) and all extension - headers are also made available to the application as ancillary data - on input. Hence there is no need for a socket option similar to the - IPv4 IP_HDRINCL socket option and on receipt the application will - only receive the payload i.e. the data after the IPv6 header and all - the extension headers. - - When writing to a raw socket the kernel will automatically fragment - the packet if its size exceeds the path MTU, inserting the required - fragmentation headers. On input the kernel reassembles received - fragments, so the reader of a raw socket never sees any fragment - headers. - - When we say "an ICMPv6 raw socket" we mean a socket created by - calling the socket function with the three arguments PF_INET6, - SOCK_RAW, and IPPROTO_ICMPV6. - - Most IPv4 implementations give special treatment to a raw socket - created with a third argument to socket() of IPPROTO_RAW, whose value - is normally 255. We note that this value has no special meaning to - an IPv6 raw socket (and the IANA currently reserves the value of 255 - when used as a next-header field). (Note: This feature was added to - IPv4 in 1988 by Van Jacobson to support traceroute, allowing a - complete IP header to be passed by the application, before the - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 16] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - IP_HDRINCL socket option was added.) - - -3.1. Checksums - - The kernel will calculate and insert the ICMPv6 checksum for ICMPv6 - raw sockets, since this checksum is mandatory. - - For other raw IPv6 sockets (that is, for raw IPv6 sockets created - with a third argument other than IPPROTO_ICMPV6), the application - must set the new IPV6_CHECKSUM socket option to have the kernel (1) - compute and store a checksum for output, and (2) verify the received - checksum on input, discarding the packet if the checksum is in error. - This option prevents applications from having to perform source - address selection on the packets they send. The checksum will - incorporate the IPv6 pseudo-header, defined in Section 8.1 of - [RFC-2460]. This new socket option also specifies an integer offset - into the user data of where the checksum is located. - - int offset = 2; - setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, sizeof(offset)); - - By default, this socket option is disabled. Setting the offset to -1 - also disables the option. By disabled we mean (1) the kernel will - not calculate and store a checksum for outgoing packets, and (2) the - kernel will not verify a checksum for received packets. - - (Note: Since the checksum is always calculated by the kernel for an - ICMPv6 socket, applications are not able to generate ICMPv6 packets - with incorrect checksums (presumably for testing purposes) using this - API.) - - -3.2. ICMPv6 Type Filtering - - ICMPv4 raw sockets receive most ICMPv4 messages received by the - kernel. (We say "most" and not "all" because Berkeley-derived - kernels never pass echo requests, timestamp requests, or address mask - requests to a raw socket. Instead these three messages are processed - entirely by the kernel.) But ICMPv6 is a superset of ICMPv4, also - including the functionality of IGMPv4 and ARPv4. This means that an - ICMPv6 raw socket can potentially receive many more messages than - would be received with an ICMPv4 raw socket: ICMP messages similar to - ICMPv4, along with neighbor solicitations, neighbor advertisements, - and the three multicast listener discovery messages. - - Most applications using an ICMPv6 raw socket care about only a small - subset of the ICMPv6 message types. To transfer extraneous ICMPv6 - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 17] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - messages from the kernel to user can incur a significant overhead. - Therefore this API includes a method of filtering ICMPv6 messages by - the ICMPv6 type field. - - Each ICMPv6 raw socket has an associated filter whose datatype is - defined as - - struct icmp6_filter; - - This structure, along with the macros and constants defined later in - this section, are defined as a result of including the - header. - - The current filter is fetched and stored using getsockopt() and - setsockopt() with a level of IPPROTO_ICMPV6 and an option name of - ICMP6_FILTER. - - Six macros operate on an icmp6_filter structure: - - void ICMP6_FILTER_SETPASSALL (struct icmp6_filter *); - void ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *); - - void ICMP6_FILTER_SETPASS ( int, struct icmp6_filter *); - void ICMP6_FILTER_SETBLOCK( int, struct icmp6_filter *); - - int ICMP6_FILTER_WILLPASS (int, - const struct icmp6_filter *); - int ICMP6_FILTER_WILLBLOCK(int, - const struct icmp6_filter *); - - The first argument to the last four macros (an integer) is an ICMPv6 - message type, between 0 and 255. The pointer argument to all six - macros is a pointer to a filter that is modified by the first four - macros examined by the last two macros. - - The first two macros, SETPASSALL and SETBLOCKALL, let us specify that - all ICMPv6 messages are passed to the application or that all ICMPv6 - messages are blocked from being passed to the application. - - The next two macros, SETPASS and SETBLOCK, let us specify that - messages of a given ICMPv6 type should be passed to the application - or not passed to the application (blocked). - - The final two macros, WILLPASS and WILLBLOCK, return true or false - depending whether the specified message type is passed to the - application or blocked from being passed to the application by the - filter pointed to by the second argument. - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 18] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - When an ICMPv6 raw socket is created, it will by default pass all - ICMPv6 message types to the application. - - As an example, a program that wants to receive only router - advertisements could execute the following: - - struct icmp6_filter myfilt; - - fd = socket(PF_INET6, SOCK_RAW, IPPROTO_ICMPV6); - - ICMP6_FILTER_SETBLOCKALL(&myfilt); - ICMP6_FILTER_SETPASS(ND_ROUTER_ADVERT, &myfilt); - setsockopt(fd, IPPROTO_ICMPV6, ICMP6_FILTER, &myfilt, sizeof(myfilt)); - - The filter structure is declared and then initialized to block all - messages types. The filter structure is then changed to allow router - advertisement messages to be passed to the application and the filter - is installed using setsockopt(). - - The icmp6_filter structure is similar to the fd_set datatype used - with the select() function in the sockets API. The icmp6_filter - structure is an opaque datatype and the application should not care - how it is implemented. All the application does with this datatype - is allocate a variable of this type, pass a pointer to a variable of - this type to getsockopt() and setsockopt(), and operate on a variable - of this type using the six macros that we just defined. - - Nevertheless, it is worth showing a simple implementation of this - datatype and the six macros. - - struct icmp6_filter { - uint32_t icmp6_filt[8]; /* 8*32 = 256 bits */ - }; - - #define ICMP6_FILTER_WILLPASS(type, filterp) \ - ((((filterp)->icmp6_filt[(type) >> 5]) & (1 << ((type) & 31))) != 0) - #define ICMP6_FILTER_WILLBLOCK(type, filterp) \ - ((((filterp)->icmp6_filt[(type) >> 5]) & (1 << ((type) & 31))) == 0) - #define ICMP6_FILTER_SETPASS(type, filterp) \ - ((((filterp)->icmp6_filt[(type) >> 5]) |= (1 << ((type) & 31)))) - #define ICMP6_FILTER_SETBLOCK(type, filterp) \ - ((((filterp)->icmp6_filt[(type) >> 5]) &= ~(1 << ((type) & 31)))) - #define ICMP6_FILTER_SETPASSALL(filterp) \ - memset((filterp), 0xFF, sizeof(struct icmp6_filter)) - #define ICMP6_FILTER_SETBLOCKALL(filterp) \ - memset((filterp), 0, sizeof(struct icmp6_filter)) - - (Note: These sample definitions have two limitations that an - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 19] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - implementation may want to change. The first four macros evaluate - their first argument two times. The second two macros require the - inclusion of the header for the memset() function.) - - -4. Access to IPv6 and Extension Headers - - Applications need to be able to control IPv6 header and extension - header content when sending as well as being able to receive the - content of these headers. This is done by defining socket option - types which can be used both with setsockopt and with ancillary data. - Ancillary data is discussed in Appendix A. The following optional - information can be exchanged between the application and the kernel: - - 1. The send/receive interface and source/destination address, - 2. The hop limit, - 3. Next hop address, - 4. Routing header. - 5. Hop-by-Hop options, and - 6. Destination options (both before and after a Routing header). - - First, to receive any of this optional information (other than the - next hop address, which can only be set), the application must call - setsockopt() to turn on the corresponding flag: - - int on = 1; - - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on)); - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on)); - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on)); - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDRDSTOPTS, - &on, sizeof(on)); - - When any of these options are enabled, the corresponding data is - returned as control information by recvmsg(), as one or more - ancillary data objects. - - Two different mechanisms exist for sending this optional information: - - 1. Using setsockopt to specify the option content for a socket. - These are known an "sticky" options since they effect all - transmitted packets on the socket until either the a new - setsockopt is done or the options are overridden using ancillary - data. - - 2. Using ancillary data to specify the option content for a single - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 20] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - datagram. This only applies to datagram and raw sockets; not to - TCP sockets. - - - The three socket option parameters and the three cmsghdr fields that - describe the options/ancillary data objects are summarized as: - - opt level/ optname/ optval/ - cmsg_level cmsg_type cmsg_data[] - ------------ ------------ ------------------------ - IPPROTO_IPV6 IPV6_PKTINFO in6_pktinfo structure - IPPROTO_IPV6 IPV6_HOPLIMIT int - IPPROTO_IPV6 IPV6_NEXTHOP socket address structure - IPPROTO_IPV6 IPV6_RTHDR implementation dependent - IPPROTO_IPV6 IPV6_HOPOPTS implementation dependent - IPPROTO_IPV6 IPV6_DSTOPTS implementation dependent - IPPROTO_IPV6 IPV6_RTHDRDSTOPTS implementation dependent - - - All these options are described in detail in following sections. All - the constants beginning with IPV6_ are defined as a result of - including the header. - - (Note: We intentionally use the same constant for the cmsg_level - member as is used as the second argument to getsockopt() and - setsockopt() (what is called the "level"), and the same constant for - the cmsg_type member as is used as the third argument to getsockopt() - and setsockopt() (what is called the "option name"). This is - consistent with the existing use of ancillary data in 4.4BSD: - returning the destination address of an IPv4 datagram.) - - (Note: It is up to the implementation what it passes as ancillary - data for the Routing header option, Hop-by-Hop option, and - Destination options, since the API to these features is through a set - of inet6_rth_XXX() and inet6_opt_XXX() functions that we define - later. These functions serve two purposes: to simplify the interface - to these features (instead of requiring the application to know the - intimate details of the extension header formats), and to hide the - actual implementation from the application. Nevertheless, we show - some examples of these features that store the actual extension - header as the ancillary data. Implementations need not use this - technique.) - - -4.1. TCP Implications - - It is not possible to use ancillary data to transmit the above - options for TCP since there is not a one-to-one mapping between send - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 21] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - operations and the TCP segments being transmitted. Instead an - application can use setsockopt to specify them as sticky options. - When the application uses setsockopt to specify the above options it - is expected that TCP will start using the new information when - sending segments. However, TCP may or may not use the new - information when retransmitting segments that were originally sent - when the old sticky options were in effect. - - Applications using TCP can use ancillary data (after enabling the - desired IPV6_RECVxxx options) to receive the IPv6 and extension - header information. However, since there is not a one-to-one mapping - between received TCP segments and recv operations seen by the - application, when different TCP segments have different IPv6 and - extension headers the application might not be able to observe all - received headers. For efficiency reasons it is recommended that a - TCP implementation not send ancillary data items with every received - segment but instead try to detect the points in the data stream when - the requested IPv6 and extension header content changes and only send - a single ancillary data item at the time of the change. Also, TCP - should send ancillary data items at the start of the connection and - when the application enables a new IPV6_RECVxxx option. - - For example, assume an application has enabled IPV6_RECVHOPLIMIT - before a connection is established. Then the first recvmsg() would - have an IPV6_HOPLIMIT item indicating the hop limit in the first data - segment. Should the hoplimit in the received data segment change a - subsequent recvmsg() will also have an IPV6_HOPLIMIT item. However, - the application must be prepared to handle ancillary data items even - though the hop limit did not change. Note that should the hop limit - in received ACK-only segments be different than the hop limit in data - segments the application might only be able to observe the hop limit - in the received data segments. - - The above example was for hop limit but the application should be - prepared to handle the corresponding behavior for the other option - information. - - The above recvmsg() behavior allows the application to detect changes - in the received IPv6 and extension headers without resorting to - periodic getsockopt() calls. - - -4.2. UDP and Raw Socket Implications - - The receive behavior for UDP and raw sockets is quite - straightforward. After the application has enabled an IPV6_RECVxxx - socket option it will receive ancillary data items for every - recvmsg() call containing the requested information. If the - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 22] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - application asks for e.g., IPV6_RTHDR and a received datagram does - not contain a Routing header an implementation might either exclude - the IPV6_RTHDR ancillary data item or pass up an item with zero - length (cmsg_data being zero length). Note that due to buffering in - the socket implementation there might be some packets queued when an - IPV6_RECVxxx option is enabled and they might not have the ancillary - data information. - - For sending the application has the choice between using sticky - options and ancillary data. The application can also use both having - the sticky options specify the "default" and using ancillary data to - override the default options. Note that if any ancillary data is - specified in a call to sendmsg(), all of the sticky options are - overridden for that datagram. For example, if the application has - set IPV6_RTHDR using a sticky option and later passes IPV6_HOPLIMIT - as ancillary data this will override the IPV6_RTHDR sticky option and - no Routing header will be sent with that datagram. - - -5. Packet Information - - There are four pieces of information that an application can specify - for an outgoing packet using ancillary data: - - 1. the source IPv6 address, - 2. the outgoing interface index, - 3. the outgoing hop limit, and - 4. the next hop address. - - Three similar pieces of information can be returned for a received - packet as ancillary data: - - 1. the destination IPv6 address, - 2. the arriving interface index, and - 3. the arriving hop limit. - - - The first two pieces of information are contained in an in6_pktinfo - structure that is set with setsockopt() or sent as ancillary data - with sendmsg() and received as ancillary data with recvmsg(). This - structure is defined as a result of including the - header. - - struct in6_pktinfo { - struct in6_addr ipi6_addr; /* src/dst IPv6 address */ - unsigned int ipi6_ifindex; /* send/recv interface index */ - }; - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 23] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - In the socket option and cmsghdr level will be IPPROTO_IPV6, the type - will be IPV6_PKTINFO, and the first byte of the option value and - cmsg_data[] will be the first byte of the in6_pktinfo structure. An - application can clear any sticky IPV6_PKTINFO option by either doing - a setsockopt for option with optlen being zero, or by doing a - "regular" setsockopt with ipi6_addr being in6addr_any and - ipi6_ifindex being zero. - - This information is returned as ancillary data by recvmsg() only if - the application has enabled the IPV6_RECVPKTINFO socket option: - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on)); - - - (Note: The hop limit is not contained in the in6_pktinfo structure - for the following reason. Some UDP servers want to respond to client - requests by sending their reply out the same interface on which the - request was received and with the source IPv6 address of the reply - equal to the destination IPv6 address of the request. To do this the - application can enable just the IPV6_RECVPKTINFO socket option and - then use the received control information from recvmsg() as the - outgoing control information for sendmsg(). The application need not - examine or modify the in6_pktinfo structure at all. But if the hop - limit were contained in this structure, the application would have to - parse the received control information and change the hop limit - member, since the received hop limit is not the desired value for an - outgoing packet.) - - -5.1. Specifying/Receiving the Interface - - Interfaces on an IPv6 node are identified by a small positive - integer, as described in Section 4 of [RFC-2553]. That document also - describes a function to map an interface name to its interface index, - a function to map an interface index to its interface name, and a - function to return all the interface names and indexes. Notice from - this document that no interface is ever assigned an index of 0. - - When specifying the outgoing interface, if the ipi6_ifindex value is - 0, the kernel will choose the outgoing interface. If the application - specifies an outgoing interface for a multicast packet, the interface - specified by the ancillary data overrides any interface specified by - the IPV6_MULTICAST_IF socket option (described in [RFC-2553]), for - that call to sendmsg() only. - - When the IPV6_PKTINFO socket option is enabled, the received - interface index is always returned as the ipi6_ifindex member of the - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 24] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - in6_pktinfo structure. - - -5.2. Specifying/Receiving Source/Destination Address - - The source IPv6 address can be specified by calling bind() before - each output operation, but supplying the source address together with - the data requires less overhead (i.e., fewer system calls) and - requires less state to be stored and protected in a multithreaded - application. - - When specifying the source IPv6 address as ancillary data, if the - ipi6_addr member of the in6_pktinfo structure is the unspecified - address (IN6ADDR_ANY_INIT or in6addr_any), then (a) if an address is - currently bound to the socket, it is used as the source address, or - (b) if no address is currently bound to the socket, the kernel will - choose the source address. If the ipi6_addr member is not the - unspecified address, but the socket has already bound a source - address, then the ipi6_addr value overrides the already-bound source - address for this output operation only. - - The kernel must verify that the requested source address is indeed a - unicast address assigned to the node. - - When the in6_pktinfo structure is returned as ancillary data by - recvmsg(), the ipi6_addr member contains the destination IPv6 address - from the received packet. - - -5.3. Specifying/Receiving the Hop Limit - - The outgoing hop limit is normally specified with either the - IPV6_UNICAST_HOPS socket option or the IPV6_MULTICAST_HOPS socket - option, both of which are described in [RFC-2553]. Specifying the - hop limit as ancillary data lets the application override either the - kernel's default or a previously specified value, for either a - unicast destination or a multicast destination, for a single output - operation. Returning the received hop limit is useful for programs - such as Traceroute and for IPv6 applications that need to verify that - the received hop limit is 255 (e.g., that the packet has not been - forwarded). - - The received hop limit is returned as ancillary data by recvmsg() - only if the application has enabled the IPV6_RECVHOPLIMIT socket - option: - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on)); - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 25] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - In the cmsghdr structure containing this ancillary data, the - cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be - IPV6_HOPLIMIT, and the first byte of cmsg_data[] will be the first - byte of the integer hop limit. - - Nothing special need be done to specify the outgoing hop limit: just - specify the control information as ancillary data for sendmsg() or - using setsockopt(). As specified in [RFC-2553], the interpretation - of the integer hop limit value is - - x < -1: return an error of EINVAL - x == -1: use kernel default - 0 <= x <= 255: use x - x >= 256: return an error of EINVAL - - - -5.4. Specifying the Next Hop Address - - The IPV6_NEXTHOP ancillary data object specifies the next hop for the - datagram as a socket address structure. In the cmsghdr structure - containing this ancillary data, the cmsg_level member will be - IPPROTO_IPV6, the cmsg_type member will be IPV6_NEXTHOP, and the - first byte of cmsg_data[] will be the first byte of the socket - address structure. - - This is a privileged option. (Note: It is implementation defined and - beyond the scope of this document to define what "privileged" means. - Unix systems use this term to mean the process must have an effective - user ID of 0.) - - If the socket address structure contains an IPv6 address (e.g., the - sin6_family member is AF_INET6), then the node identified by that - address must be a neighbor of the sending host. If that address - equals the destination IPv6 address of the datagram, then this is - equivalent to the existing SO_DONTROUTE socket option. - - -5.5. Additional Errors with sendmsg() and setsockopt() - - With the IPV6_PKTINFO socket option there are no additional errors - possible with the call to recvmsg(). But when specifying the - outgoing interface or the source address, additional errors are - possible from sendmsg() or setsockopt(). Note that some - implementations might only be able to return this type of errors for - setsockopt(). The following are examples, but some of these may not - be provided by some implementations, and some implementations may - define additional errors: - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 26] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - ENXIO The interface specified by ipi6_ifindex does not exist. - - ENETDOWN The interface specified by ipi6_ifindex is not enabled - for IPv6 use. - - EADDRNOTAVAIL ipi6_ifindex specifies an interface but the address - ipi6_addr is not available for use on that interface. - - EHOSTUNREACH No route to the destination exists over the interface - specified by ifi6_ifindex. - - -6. Routing Header Option - - Source routing in IPv6 is accomplished by specifying a Routing header - as an extension header. There can be different types of Routing - headers, but IPv6 currently defines only the Type 0 Routing header - [RFC-2460]. This type supports up to 127 intermediate nodes (limited - by the length field in the extension header). With this maximum - number of intermediate nodes, a source, and a destination, there are - 128 hops. - - Source routing with IPv4 sockets API (the IP_OPTIONS socket option) - requires the application to build the source route in the format that - appears as the IPv4 header option, requiring intimate knowledge of - the IPv4 options format. This IPv6 API, however, defines eight - functions that the application calls to build and examine a Routing - header, and the ability to use sticky options or ancillary data to - communicate this information between the application and the kernel. - - Three functions build a Routing header: - - inet6_rth_space() - return #bytes required for Routing header - inet6_rth_init() - initialize buffer data for Routing header - inet6_rth_add() - add one IPv6 address to the Routing header - - Three functions deal with a returned Routing header: - - inet6_rth_reverse() - reverse a Routing header - inet6_rth_segments() - return #segments in a Routing header - inet6_rth_getaddr() - fetch one address from a Routing header - - The function prototypes for these functions are all in the - header. - - To receive a Routing header the application must enable the - IPV6_RECVRTHDR socket option: - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 27] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); - - To send a Routing header the application specifies it either as - ancillary data in a call to sendmsg() or using setsockopt(). - - The application can remove any sticky Routing header by calling - setsockopt() for IPV6_RTHDR with a zero option length. - - When using ancillary data a Routing header is passed between the - application and the kernel as follows: The cmsg_level member has a - value of IPPROTO_IPV6 and the cmsg_type member has a value of - IPV6_RTHDR. The contents of the cmsg_data[] member is implementation - dependent and should not be accessed directly by the application, but - should be accessed using the six functions that we are about to - describe. - - The following constant is defined in the header: - - #define IPV6_RTHDR_TYPE_0 0 /* IPv6 Routing header type 0 */ - - When a Routing header is specified, the destination address specified - for connect(), sendto(), or sendmsg() is the final destination - address of the datagram. The Routing header then contains the - addresses of all the intermediate nodes. - - -6.1. inet6_rth_space - - - size_t inet6_rth_space(int type, int segments); - - This function returns the number of bytes required to hold a Routing - header of the specified type containing the specified number of - segments (addresses). For an IPv6 Type 0 Routing header, the number - of segments must be between 0 and 127, inclusive. The return value - is just the space for the Routing header. When the application uses - ancillary data it must pass the returned length to CMSG_LEN to - determine how much memory is needed for the ancillary data object - (including the cmsghdr structure). - - If the return value is 0, then either the type of the Routing header - is not supported by this implementation or the number of segments is - invalid for this type of Routing header. - - (Note: This function returns the size but does not allocate the space - required for the ancillary data. This allows an application to - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 28] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - allocate a larger buffer, if other ancillary data objects are - desired, since all the ancillary data objects must be specified to - sendmsg() as a single msg_control buffer.) - - -6.2. inet6_rth_init - - - void *inet6_rth_init(void *bp, int bp_len, int type, int segments); - - This function initializes the buffer pointed to by bp to contain a - Routing header of the specified type. When the application uses - ancillary data the application must initialize any cmsghdr fields. - - The caller must allocate the buffer and its size can be determined by - calling inet6_rth_space(). - - Upon success the return value is the pointer to the buffer (bp), and - this is then used as the first argument to the next two functions. - Upon an error the return value is NULL. - - -6.3. inet6_rth_add - - - int inet6_rth_add(void *bp, const struct in6_addr *addr); - - This function adds the IPv6 address pointed to by addr to the end of - the Routing header being constructed. - - If successful, the segleft member of the Routing Header is updated to - account for the new address in the Routing header and the return - value of the function is 0. Upon an error the return value of the - function is -1. - - -6.4. inet6_rth_reverse - - - int inet6_rth_reverse(const void *in, void *out) - - This function takes a Routing header extension header (pointed to by - the first argument) and writes a new Routing header that sends - datagrams along the reverse of that route. Both arguments are - allowed to point to the same buffer (that is, the reversal can occur - in place). - - The return value of the function is 0 on success, or -1 upon an - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 29] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - error. - - -6.5. inet6_rth_segments - - - int inet6_rth_segments(const void *bp); - - This function returns the number of segments (addresses) contained in - the Routing header described by bp. On success the return value is - zero or greater. The return value of the function is -1 upon an - error. - - -6.6. inet6_rth_getaddr - - - struct in6_addr *inet6_rth_getaddr(const void *bp, int index); - - This function returns a pointer to the IPv6 address specified by - index (which must have a value between 0 and one less than the value - returned by inet6_rth_segments()) in the Routing header described by - bp. An application should first call inet6_rth_segments() to obtain - the number of segments in the Routing header. - - Upon an error the return value of the function is NULL. - - -7. Hop-By-Hop Options - - A variable number of Hop-by-Hop options can appear in a single Hop- - by-Hop options header. Each option in the header is TLV-encoded with - a type, length, and value. - - Today only three Hop-by-Hop options are defined for IPv6 [RFC-2460]: - Jumbo Payload, Pad1, and PadN, although a proposal exists for a - router-alert Hop-by-Hop option. The Jumbo Payload option should not - be passed back to an application and an application should receive an - error if it attempts to set it. This option is processed entirely by - the kernel. It is indirectly specified by datagram-based - applications as the size of the datagram to send and indirectly - passed back to these applications as the length of the received - datagram. The two pad options are for alignment purposes and are - automatically inserted by a sending kernel when needed and ignored by - the receiving kernel. This section of the API is therefore defined - for future Hop-by-Hop options that an application may need to specify - and receive. - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 30] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - Individual Hop-by-Hop options (and Destination options, which are - described shortly, and which are very similar to the Hop-by-Hop - options) may have specific alignment requirements. For example, the - 4-byte Jumbo Payload length should appear on a 4-byte boundary, and - IPv6 addresses are normally aligned on an 8-byte boundary. These - requirements and the terminology used with these options are - discussed in Section 4.2 and Appendix B of [RFC-2460]. The alignment - of first byte of each option is specified by two values, called x and - y, written as "xn + y". This states that the option must appear at - an integer multiple of x bytes from the beginning of the options - header (x can have the values 1, 2, 4, or 8), plus y bytes (y can - have a value between 0 and 7, inclusive). The Pad1 and PadN options - are inserted as needed to maintain the required alignment. The - functions below need to know the alignment of the end of the option - (which is always in the form "xn," where x can have the values 1, 2, - 4, or 8) and the total size of the data portion of the option. These - are passed as the "align" and "len" arguments to inet6_opt_append(). - - Multiple Hop-by-Hop options must be specified by the application by - placing them in a single extension header. - - Finally, we note that use of some Hop-by-Hop options or some - Destination options, might require special privilege. That is, - normal applications (without special privilege) might be forbidden - from setting certain options in outgoing packets, and might never see - certain options in received packets. - - -7.1. Receiving Hop-by-Hop Options - - To receive Hop-by-Hop options the application must enable the - IPV6_RECVHOPOPTS socket option: - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on)); - - When using ancillary data a Hop-by-hop options is passed between the - application and the kernel as follows: The cmsg_level member will be - IPPROTO_IPV6 and the cmsg_type member will be IPV6_HOPOPTS. These - options are then processed by calling the inet6_opt_next(), - inet6_opt_find(), and inet6_opt_get_val() functions, described - shortly. - - -7.2. Sending Hop-by-Hop Options - - To send a Hop-by-Hop options header, the application specifies the - header either as ancillary data in a call to sendmsg() or using - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 31] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - setsockopt(). - - The application can remove any sticky Hop-by-Hop extension header by - calling setsockopt() for IPV6_HOPOPTS with a zero option length. - - All the Hop-by-Hop options must specified by a single ancillary data - object. The cmsg_level member is set to IPPROTO_IPV6 and the - cmsg_type member is set to IPV6_HOPOPTS. The option is normally - constructed using the inet6_opt_init(), inet6_opt_append(), - inet6_opt_finish(), and inet6_set_val() functions, described shortly. - - Additional errors may be possible from sendmsg() and setsockopt() if - the specified option is in error. - - -8. Destination Options - - A variable number of Destination options can appear in one or more - Destination option headers. As defined in [RFC-2460], a Destination - options header appearing before a Routing header is processed by the - first destination plus any subsequent destinations specified in the - Routing header, while a Destination options header appearing after a - Routing header is processed only by the final destination. As with - the Hop-by-Hop options, each option in a Destination options header - is TLV-encoded with a type, length, and value. - - Today no Destination options are defined for IPv6 [RFC-2460], - although proposals exist to use Destination options with Mobile IPv6. - - -8.1. Receiving Destination Options - - To receive Destination options appearing after a Routing header (or - in a packet without a Routing header) the application must enable the - IPV6_RECVDSTOPTS socket option: - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); - - To receive Destination options appearing before a Routing header the - application must enable the IPV6_RECVRTHDRDSTOPTS socket option: - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDRDSTOPTS, - &on, sizeof(on)); - - All the Destination options appearing before a Routing header are - returned as one ancillary data object described by a cmsghdr - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 32] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - structure (with cmsg_type set to IPV6_RTHDRDSTOPTS) and all the - Destination options appearing after a Routing header (or in a packet - without a Routing header) are returned as another ancillary data - object described by a cmsghdr structure (with cmsg_type set to - IPV6_DSTOPTS). For all these ancillary data objects, the cmsg_level - member will be IPPROTO_IPV6. - - These options are then processed by calling the inet6_opt_next(), - inet6_opt_find(), and inet6_opt_get_value() functions. - - -8.2. Sending Destination Options - - To send a Destination options header, the application specifies it - either as ancillary data in a call to sendmsg() or using - setsockopt(). - - The application can remove any sticky Destination extension header by - calling setsockopt() for IPV6_RTHDRDSTOPTS/IPV6_DSTOPTS with a zero - option length. - - As described earlier, one set of Destination options can appear - before a Routing header, and one set can appear after a Routing - header (or in a packet with no Routing header). Each set can consist - of one or more options but each set is a single extension header. - - When using ancillary data a Destination options header is passed - between the application and the kernel as follows: The set preceding - a Routing header are specified with the cmsg_level member is set to - IPPROTO_IPV6 and the cmsg_type member is set to IPV6_RTHDRDSTOPTS. - Any setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently - ignore when sending packets unless a Routing header is also - specified. - - The set of Destination options after a Routing header, which are also - used when no Routing header is present, are specified with the - cmsg_level member is set to IPPROTO_IPV6 and the cmsg_type member is - set to IPV6_DSTOPTS. - - The Destination options are normally constructed using the - inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and - inet6_set_val() functions, described shortly. - - Additional errors may be possible from sendmsg() and setsockopt() if - the specified option is in error. - - -9. Hop-by-Hop and Destination Options Processing - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 33] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - Building and parsing the Hop-by-Hop and Destination options is - complicated for the reasons given earlier. We therefore define a set - of functions to help the application. The function prototypes for - these functions are all in the header. - - The first 3 functions (init, append, and finish) are used both to - calculate the needed buffer size for the options, and to actually - encode the options once the application has allocated a buffer for - the header. In order to only calculate the size the application must - pass a NULL extbuf and a zero extlen to those functions. - - -9.1. inet6_opt_init - - - int inet6_opt_init(void *extbuf, size_t extlen); - - This function returns the number of bytes needed for the empty - extension header i.e. without any options. If extbuf is not NULL it - also initializes the extension header to have the correct length - field. If the extlen value is too small or not a multiple of 8 the - function fails and returns -1. - - -9.2. inet6_opt_append - - - int inet6_opt_append(void *extbuf, size_t extlen, int prevlen, - uint8_t type, size_t len, uint_t align, - void **databufp); - - Prevlen should be the length returned by inet6_opt_init() or a - previous inet6_opt_append(). This function returns the updated total - length taking into account adding an option with length 'len' and - alignment 'align'. If extbuf is not NULL then, in addition to - returning the length, the function inserts any needed pad option, - initializes the option (setting the type and length fields) and - returns a pointer to the location for the option content in databufp. - If the option does not fit in the extension header buffer the - function returns -1. - - type is the 8-bit option type. len is the length of the option data - (i.e. excluding the option type and option length fields). - - Once inet6_opt_append() has been called the application can use the - databuf directly, or use inet6_opt_set_val() to specify the content - of the option. - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 34] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - The option type must have a value from 2 to 255, inclusive. (0 and 1 - are reserved for the Pad1 and PadN options, respectively.) - - The option data length must have a value between 0 and 255, - inclusive, and is the length of the option data that follows. - - The align parameter must have a value of 1, 2, 4, or 8. The len - value can not exceed the value of align. - - -9.3. inet6_opt_finish - - - int inet6_opt_finish(void *extbuf, size_t extlen, int prevlen); - - Prevlen should be the length returned by inet6_opt_init() or - inet6_opt_append(). This function returns the updated total length - taking into account the final padding of the extension header to make - it a multiple of 8 bytes. If extbuf is not NULL the function also - initializes the option by inserting a Pad1 or PadN option of the - proper length. - - If the necessary pad does not fit in the extension header buffer the - function returns -1. - - -9.4. inet6_opt_set_val - - - int inet6_opt_set_val(void *databuf, size_t offset, void *val, - int vallen); - - Databuf should be a pointer returned by inet6_opt_append(). This - function inserts data items of various sizes (1, 2, 4, or 8 bytes) in - the data portion of the option. val should point to the data to be - inserted. Offset specifies where in the data portion of the option - the value should be inserted; the first byte after the option type - and length is accessed by specifying an offset of zero. - - The function returns the offset for the next field (i.e., offset + - vallen) which can be used when composing option content with multiple - fields. - - -9.5. inet6_opt_next - - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 35] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - int inet6_opt_next(void *extbuf, size_t extlen, int prevlen, - uint8_t *typep, size_t *lenp, - void **databufp); - - This function parses received extension headers returning the next - option. Extbuf and extlen specifies the extension header. Prevlen - should either be zero (for the first option) or the length returned - previous inet6_opt_next() or inet6_opt_find(). It specifies the - position where to continue scanning the extension buffer. The next - option is returned by updating typep, lenp, and databufp. This - function returns the updated "previous" length taking into account - the option that was returned. - - -9.6. inet6_opt_find - - - int inet6_opt_find(void *extbuf, size_t extlen, int prevlen, - uint8_t type, size_t *lenp, - void **databufp); - - This function is similar to the previously described inet6_opt_next() - function, except this function lets the caller specify the option - type to be searched for, instead of always returning the next option - in the extension header. - - If an option of the specified type is located, the function returns - the updated "previous" total length taking into account the option - that was returned and any options that didn't match the type. - - If an option of the specified type is not located, the return value - is -1. If an error occurs, the return value is -1. - - -9.7. inet6_opt_get_val - - - int inet6_opt_get_val(void *databuf, size_t offset, void *val, - int vallen); - - Databuf should be a pointer returned by inet6_opt_next() or - inet6_opt_find(). This function extracts data items of various sizes - (1, 2, 4, or 8 bytes) in the data portion of the option. val should - point to the destination for the extracted data. Offset specifies - from where in the data portion of the option the value should be - extracted; the first byte after the option type and length is - accessed by specifying an offset of zero. - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 36] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - The function returns the offset for the next field (i.e., offset + - vallen) which can be used when extracting option content with - multiple fields. - - -10. Ordering of Ancillary Data and IPv6 Extension Headers - - Three IPv6 extension headers can be specified by the application and - returned to the application using ancillary data with sendmsg() and - recvmsg(): the Routing header, Hop-by-Hop options, and Destination - options. When multiple ancillary data objects are transferred via - recvmsg() and these objects represent any of these three extension - headers, their placement in the control buffer is directly tied to - their location in the corresponding IPv6 datagram. This API imposes - some ordering constraints for using these ancillary data objects with - sendmsg(). - - All Hop-by-Hop options must be specified in a single ancillary data - object. Should multiple be specified the implementation might choose - an arbitrary one or drop the packet. - - All Destination options that precede a Routing header must be - specified in a single ancillary data object. If there is no Routing - header ancillary data object the IPV6_RTHDRDSTOPTS object will be - silently ignored. - - All Destination options that follow a Routing header (or are used - without a Routing header) must be specified in a single ancillary - data object. - - If Destination options are specified in the control buffer after a - Routing header, or if Destination options are specified without a - Routing header, the kernel will place those Destination options after - an authentication header and/or an encapsulating security payload - header, if present. - - -11. IPv6-Specific Options with IPv4-Mapped IPv6 Addresses - - The various socket options and ancillary data specifications defined - in this document apply only to true IPv6 sockets. It is possible to - create an IPv6 socket that actually sends and receives IPv4 packets, - using IPv4-mapped IPv6 addresses, but the mapping of the options - defined in this document to an IPv4 datagram is beyond the scope of - this document. - - In general, attempting to specify an IPv6-only option, such as the - Hop-by-Hop options, Destination options, or Routing header on an IPv6 - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 37] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - socket that is using IPv4-mapped IPv6 addresses, will probably result - in an error. Some implementations, however, may provide access to - the packet information (source/destination address, send/receive - interface, and hop limit) on an IPv6 socket that is using IPv4-mapped - IPv6 addresses. - - -12. Extended interfaces for rresvport, rcmd and rexec - - TBD - - -12.1. rresvport_af - - The rresvport() function is used by the rcmd() function, and this - function is in turn called by many of the "r" commands such as - rlogin. While new applications are not being written to use the - rcmd() function, legacy applications such as rlogin will continue to - use it and these will be ported to IPv6. - - rresvport() creates an IPv4/TCP socket and binds a "reserved port" to - the socket. Instead of defining an IPv6 version of this function we - define a new function that takes an address family as its argument. - - #include - - int rresvport_af(int *port, int family); - - This function behaves the same as the existing rresvport() function, - but instead of creating an IPv4/TCP socket, it can also create an - IPv6/TCP socket. The family argument is either AF_INET or AF_INET6, - and a new error return is EAFNOSUPPORT if the address family is not - supported. - - (Note: There is little consensus on which header defines the - rresvport() and rcmd() function prototypes. 4.4BSD defines it in - , others in , and others don't define the function - prototypes at all.) - - -12.2. rcmd_af - - TBD - - int rcmd_af(char **ahost, unsigned short rport, const char *locuser, - const char *remuser, const char *cmd, int *fd2p, int af) - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 38] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - -12.3. rexec_af - - TBD - - int rexec_af(char **ahost, unsigned short rport, const char *name, - const char *pass, const char *cmd, int *fd2p, int af) - - - -13. Future Items - - Some additional items may require standardization, but no concrete - proposals have been made for the API to perform these tasks. These - may be addressed in a later document. - - -13.1. Flow Labels - - Earlier revisions of this document specified a set of - inet6_flow_XXX() functions to assign, share, and free IPv6 flow - labels. Consensus, however, indicated that it was premature to - specify this part of the API. - - -13.2. Path MTU Discovery and UDP - - A standard method may be desirable for a UDP application to determine - the "maximum send transport-message size" (Section 5.1 of [RFC-1981]) - to a given destination. This would let the UDP application send - smaller datagrams to the destination, avoiding fragmentation. - - -13.3. Neighbor Reachability and UDP - - A standard method may be desirable for a UDP application to tell the - kernel that it is making forward progress with a given peer (Section - 7.3.1 of [RFC-2461]). This could save unneeded neighbor - solicitations and neighbor advertisements. - - -14. Summary of New Definitions - - The following list summarizes the constants and structure, - definitions discussed in this memo, sorted by header. - - ICMP6_DST_UNREACH - ICMP6_DST_UNREACH_ADDR - ICMP6_DST_UNREACH_ADMIN - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 39] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - ICMP6_DST_UNREACH_NOPORT - ICMP6_DST_UNREACH_NOROUTE - ICMP6_DST_UNREACH_NOTNEIGHBOR - ICMP6_ECHO_REPLY - ICMP6_ECHO_REQUEST - ICMP6_INFOMSG_MASK - ICMP6_MEMBERSHIP_QUERY - ICMP6_MEMBERSHIP_REDUCTION - ICMP6_MEMBERSHIP_REPORT - ICMP6_PACKET_TOO_BIG - ICMP6_PARAMPROB_HEADER - ICMP6_PARAMPROB_NEXTHEADER - ICMP6_PARAMPROB_OPTION - ICMP6_PARAM_PROB - ICMP6_TIME_EXCEEDED - ICMP6_TIME_EXCEED_REASSEMBLY - ICMP6_TIME_EXCEED_TRANSIT - ND_NA_FLAG_OVERRIDE - ND_NA_FLAG_ROUTER - ND_NA_FLAG_SOLICITED - ND_NEIGHBOR_ADVERT - ND_NEIGHBOR_SOLICIT - ND_OPT_MTU - ND_OPT_PI_FLAG_AUTO - ND_OPT_PI_FLAG_ONLINK - ND_OPT_PREFIX_INFORMATION - ND_OPT_REDIRECTED_HEADER - ND_OPT_SOURCE_LINKADDR - ND_OPT_TARGET_LINKADDR - ND_RA_FLAG_MANAGED - ND_RA_FLAG_OTHER - ND_REDIRECT - ND_ROUTER_ADVERT - ND_ROUTER_SOLICIT - - struct icmp6_filter{}; - struct icmp6_hdr{}; - struct nd_neighbor_advert{}; - struct nd_neighbor_solicit{}; - struct nd_opt_hdr{}; - struct nd_opt_mtu{}; - struct nd_opt_prefix_info{}; - struct nd_opt_rd_hdr{}; - struct nd_redirect{}; - struct nd_router_advert{}; - struct nd_router_solicit{}; - - IPPROTO_AH - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 40] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - IPPROTO_DSTOPTS - IPPROTO_ESP - IPPROTO_FRAGMENT - IPPROTO_HOPOPTS - IPPROTO_ICMPV6 - IPPROTO_IPV6 - IPPROTO_NONE - IPPROTO_ROUTING - IPV6_RECVDSTOPTS - IPV6_RECVHOPLIMIT - IPV6_RECVHOPOPTS - IPV6_RECVPKTINFO - IPV6_RECVRTHDR - IPV6_RECVRTHDRDSTOPTS - IPV6_DSTOPTS - IPV6_HOPLIMIT - IPV6_HOPOPTS - IPV6_NEXTHOP - IPV6_PKTINFO - IPV6_RTHDR - IPV6_RTHDRDSTOPTS - IPV6_RTHDR_TYPE_0 - struct in6_pktinfo{}; - - IP6F_OFF_MASK - IP6F_RESERVED_MASK - IP6F_MORE_FRAG - struct ip6_dest{}; - struct ip6_frag{}; - struct ip6_hbh{}; - struct ip6_hdr{}; - struct ip6_rthdr{}; - struct ip6_rthdr0{}; - - struct cmsghdr{}; - struct msghdr{}; - - - The following list summarizes the function and macro prototypes - discussed in this memo, sorted by header. - - void ICMP6_FILTER_SETBLOCK(int, struct icmp6_filter *); - void ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *); - void ICMP6_FILTER_SETPASS(int, struct icmp6_filter *); - void ICMP6_FILTER_SETPASSALL(struct icmp6_filter *); - int ICMP6_FILTER_WILLBLOCK(int, - const struct icmp6_filter *); - int ICMP6_FILTER_WILLPASS(int, - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 41] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - const struct icmp6_filter *); - - int IN6_ARE_ADDR_EQUAL(const struct in6_addr *, - const struct in6_addr *); - - int inet6_opt_append(void *, size_t, int, - uint8_t, size_t, uint_8, void **); - int inet6_opt_get_val(void *, size_t, void *, int); - int inet6_opt_find(void *, size_t, int, uint8_t , - size_t *, void **); - int inet6_opt_finish(void *, size_t, int); - int inet6_opt_init(void *, size_t); - int inet6_opt_next(void *, size_t, int, uint8_t *, - size_t *, void **); - int inet6_opt_set_val(void *, size_t, void *, int); - - int inet6_rth_add(void *, - const struct in6_addr *); - struct in6_addr inet6_rth_getaddr(const void *, - int); - void *inet6_rth_init(void *, int, int, int); - int inet6_rth_reverse(const void *, void *); - int inet6_rth_segments(const void *); - size_t inet6_rth_space(int, int); - - unsigned char *CMSG_DATA(const struct cmsghdr *); - struct cmsghdr *CMSG_FIRSTHDR(const struct msghdr *); - unsigned int CMSG_LEN(unsigned int); - struct cmsghdr *CMSG_NXTHDR(const struct msghdr *mhdr, - const struct cmsghdr *); - unsigned int CMSG_SPACE(unsigned int); - - int rresvport_af(int *, int); - int rcmd_af(char **, unsigned short, const char *, - const char *, const char *, int *, int); - int rexec_af(char **, unsigned short , const char *, - const char *, const char *, int *, int); - - - -15. Security Considerations - - The setting of certain Hop-by-Hop options and Destination options may - be restricted to privileged processes. Similarly some Hop-by-Hop - options and Destination options may not be returned to nonprivileged - applications. - - The ability to specify an arbitrary source address using IPV6_PKTINFO - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 42] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - must be prevented; at least for non-privileged processes. - - -16. Compatibility with RFC 2292 - - The intent is that implementations that so desire should be able to - conform to both this document and to RFC 2292. - - This is possible since this document doesn't redefine any of the - existing socket options and since it uses new names for the - inet6_XXX() functions that take different arguments. - - Thus implementations that wish to provide support for RFC 2292 can - retain the support for IPV6_PKTOPTIONS, allow the setting of - IPV6_RTHDR etc to a sizeof(int) value to enable receipt of ancillary - data, and provide the old (as well as the new) inet6_XXX() functions. - - -17. Change History - - Changes from RFC 2292: - - - Removed the IPV6_PKTOPTIONS socket option by allowing sticky - options to be set with individual setsockopt calls. This - simplifies the protocol stack implementation by not having to - handle options within options and also clarifies the failure - semantics when some option is incorrectly formatted. - - - Added the IPV6_RTHDRDSTOPTS for a Destination header before the - Routing header. This is necessary to allow setting these - Destination headers without IPV6_PKTOPTIONS. - - - Removed the ability to be able to specify Hop-by-Hop and - Destination options using multiple ancillary data items. The - application, using the inet6_option_*() routines, is responsible - for formatting the whole extension header. This removes the need - for the protocol stack to somehow guess the alignment - restrictions on options when concatenating them together. - - - Added separate IPV6_RECVxxx options to enable the receipt of the - corresponding ancillary data items. This makes the API cleaner - since it allows the application to retrieve with getsockopt the - sticky options it has set with setsockopt. - - - Clarified how sticky options are turned off. - - - Clarified how and when TCP returns ancillary data. - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 43] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - Removed the support for the loose/strict Routing header since - that has been removed from the IPv6 specification. - - - Modified the inet6_rthdr_XXX() functions to not assume a cmsghdr - structure in order to work with both sticky options and ancillary - data. Renamed the functions to inet6_rth_XXX() to allow - implementations to provide both the old and new functions. - - - Modified the inet6_option_XXX() functions to not assume a cmsghdr - structure in order to work with both sticky options and ancillary - data. Renamed the functions to inet6_opt_XXX() to allow - implementations to provide both the old and new functions. - - - The new inet6_opt_XXX() functions were made different that the - old as to not require structure declarations but instead use - functions to add the individual fields to the option. - - - Changed inet6_rthdr_getaddr() to operate on index O through N-1 - (used to be 1 through N). - - - Changed the comments in the struct ip6_hdr from "priority" to - "traffic class". - - - Clarified the alignment issues involving ancillary data to allow - for separate alignment of cmsghdr structures and the data. Made - CMSG_SPACE() return an upper bound on the needed space. - - - Added rcmd_af() and rexec_af(). - - -18. TODO and Open Issues - - Items left to do: - - - Add mechanism to avoid fragmentation by sending at the minimum - IPv6 MTU. Suggest an IPV6_USE_MIN_MTU socket option. - - - Add MTU notification so that UDP and raw socket applications can - participate in path MTU discovery. Suggest an ancillary data - item which might be received without any data (i.e. recvmsg - returns zero): IPV6_PATHMTU The receipt of this ancillary data - item is enabled with IPV6_RECVPATHMTU. - - - Add Reachability confirmation for UDP and raw socket - applications. Suggest an ancillary data item for sendmsg() - called IPV6_REACHCONF which takes no value (i.e. it is zero - length). - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 44] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - Open issues: - - - Should we make the content of IPV6_RTHDR, IPV6_HOPOPTS etc be - specified as the extension header format (struct ip6_rthdr etc) - instead of the current "implementation dependent"? - - - Are the new inet6_opt_set_val() and inet6_opt_get_val() useful? - There implementation is just an assignment/bcopy based on the - length of the data item. - - - "If the application asks for e.g., IPV6_RTHDR and a received - datagram does not contain a Routing header an implementation - might either exclude the IPV6_RTHDR ancillary data item or pass - up an item with zero length (cmsg_data being zero length)." - Discussion: Do we want the above behavior? Or always exclude the - ancillary data item? - - - Should we add option definitions (IPV6OPT_PAD1 etc) and all the - different flags for the headers defined in section 2? - - - "Note that if any ancillary data is specified in a call to - sendmsg(), all of the sticky options are overridden for that - datagram." We could instead define that a zero-length cmsghdr - (for the specific level and type) is needed to override an - individual sticky options instead. Should we? - - - The examples use CMSG_LEN and CMSG_SPACE interchangeably. The - latter only needs to be used when there are multiple ancillary - data items in a control buffer. This should be clarified - somewhere. - - -19. References - - - [RFC-2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 - (IPv6), Specification", RFC 2460, Dec. 1998. - - [RFC-2553] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W., - "Basic Socket Interface Extensions for IPv6", RFC 2553, - March 1999. - - [RFC-1981] McCann, J., Deering, S., Mogul, J, "Path MTU Discovery - for IP version 6", RFC 1981, Aug. 1996. - - [RFC-2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 45] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - Discovery for IP Version 6 (IPv6)", RFC 2461, Dec. 1998. - - -20. Acknowledgments - - Matt Thomas and Jim Bound have been working on the technical details - in this draft for over a year. Keith Sklower is the original - implementor of ancillary data in the BSD networking code. Craig Metz - provided lots of feedback, suggestions, and comments based on his - implementing many of these features as the document was being - written. - - The following provided comments on earlier drafts: Pascal Anelli, - Hamid Asayesh, Ran Atkinson, Karl Auerbach, Hamid Asayesh, Matt - Crawford, Sam T. Denton, Richard Draves, Francis Dupont, Bob - Gilligan, Tim Hartrick, Masaki Hirabaru, Yoshinobu Inoue, Mukesh - Kacker, A. N. Kuznetsov, Pedro Marques, Jack McCann, der Mouse, John - Moy, Thomas Narten, Steve Parker, Charles Perkins, Tom Pusateri, - Pedro Roque, Sameer Shah, Peter Sjodin, Stephen P. Spackman, Jinmei - Tatuya, Karen Tracey, Quaizar Vohra, Carl Williams, Steve Wise, and - Kazu Yamamoto. - - -21. Authors' Addresses - - W. Richard Stevens - 1202 E. Paseo del Zorro - Tucson, AZ 85718 - Email: rstevens@kohala.com - - - Matt Thomas - 3am Software Foundry - 8053 Park Villa Circle - Cupertino, CA 95014 - Email: matt@3am-software.com - - - Erik Nordmark - Sun Microsystems, Inc. - 901 San Antonio Road - Palo Alto, CA 94303, USA - Email: erik.nordmark@eng.sun.com - - - -22. Appendix A: Ancillary Data - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 46] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - 4.2BSD allowed file descriptors to be transferred between separate - processes across a UNIX domain socket using the sendmsg() and - recvmsg() functions. Two members of the msghdr structure, - msg_accrights and msg_accrightslen, were used to send and receive the - descriptors. When the OSI protocols were added to 4.3BSD Reno in - 1990 the names of these two fields in the msghdr structure were - changed to msg_control and msg_controllen, because they were used by - the OSI protocols for "control information", although the comments in - the source code call this "ancillary data". - - Other than the OSI protocols, the use of ancillary data has been - rare. In 4.4BSD, for example, the only use of ancillary data with - IPv4 is to return the destination address of a received UDP datagram - if the IP_RECVDSTADDR socket option is set. With Unix domain sockets - ancillary data is still used to send and receive descriptors. - - Nevertheless the ancillary data fields of the msghdr structure - provide a clean way to pass information in addition to the data that - is being read or written. The inclusion of the msg_control and - msg_controllen members of the msghdr structure along with the cmsghdr - structure that is pointed to by the msg_control member is required by - the Posix.1g sockets API standard. - - - -22.1. The msghdr Structure - - The msghdr structure is used by the recvmsg() and sendmsg() - functions. Its Posix.1g definition is: - - struct msghdr { - void *msg_name; /* ptr to socket address structure */ - socklen_t msg_namelen; /* size of socket address structure */ - struct iovec *msg_iov; /* scatter/gather array */ - size_t msg_iovlen; /* # elements in msg_iov */ - void *msg_control; /* ancillary data */ - socklen_t msg_controllen; /* ancillary data buffer length */ - int msg_flags; /* flags on received message */ - }; - - The structure is declared as a result of including . - - (Note: Before Posix.1g the two "void *" pointers were typically "char - *", and the two socklen_t members and the size_t member were - typically integers. Earlier drafts of Posix.1g had the two socklen_t - members as size_t, but Draft 6.6 of Posix.1g, apparently the final - draft, changed these to socklen_t to simplify binary portability for - 64-bit implementations and to align Posix.1g with X/Open's Networking - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 47] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - Services, Issue 5. The change in msg_control to a "void *" pointer - affects any code that increments this pointer.) - - (Note: Before Posix.1g the cmsg_len member was an integer, and not a - socklen_t. See the Note in the previous section for why socklen_t is - used here.) - - Most Berkeley-derived implementations limit the amount of ancillary - data in a call to sendmsg() to no more than 108 bytes (an mbuf). - This API requires a minimum of 10240 bytes of ancillary data, but it - is recommended that the amount be limited only by the buffer space - reserved by the socket (which can be modified by the SO_SNDBUF socket - option). (Note: This magic number 10240 was picked as a value that - should always be large enough. 108 bytes is clearly too small as the - maximum size of a Routing header is 2048 bytes.) - - -22.2. The cmsghdr Structure - - The cmsghdr structure describes ancillary data objects transferred by - recvmsg() and sendmsg(). Its Posix.1g definition is: - - struct cmsghdr { - socklen_t cmsg_len; /* #bytes, including this header */ - int cmsg_level; /* originating protocol */ - int cmsg_type; /* protocol-specific type */ - /* followed by unsigned char cmsg_data[]; */ - }; - - This structure is declared as a result of including . - - As shown in this definition, normally there is no member with the - name cmsg_data[]. Instead, the data portion is accessed using the - CMSG_xxx() macros, as described shortly. Nevertheless, it is common - to refer to the cmsg_data[] member. - - When ancillary data is sent or received, any number of ancillary data - objects can be specified by the msg_control and msg_controllen - members of the msghdr structure, because each object is preceded by a - cmsghdr structure defining the object's length (the cmsg_len member). - Historically Berkeley-derived implementations have passed only one - object at a time, but this API allows multiple objects to be passed - in a single call to sendmsg() or recvmsg(). The following example - shows two ancillary data objects in a control buffer. - - - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 48] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - |<--------------------------- msg_controllen -------------------------->| - | OR | - |<--------------------------- msg_controllen ----------------------->| - | | - |<----- ancillary data object ----->|<----- ancillary data object ----->| - |<------ min CMSG_SPACE() --------->|<------ min CMSG_SPACE() --------->| - | | | - |<---------- cmsg_len ---------->| |<--------- cmsg_len ----------->| | - |<--------- CMSG_LEN() --------->| |<-------- CMSG_LEN() ---------->| | - | | | | | - +-----+-----+-----+--+-----------+--+-----+-----+-----+--+-----------+--+ - |cmsg_|cmsg_|cmsg_|XX| |XX|cmsg_|cmsg_|cmsg_|XX| |XX| - |len |level|type |XX|cmsg_data[]|XX|len |level|type |XX|cmsg_data[]|XX| - +-----+-----+-----+--+-----------+--+-----+-----+-----+--+-----------+--+ - ^ - | - msg_control - points here - - - The fields shown as "XX" are possible padding, between the cmsghdr - structure and the data, and between the data and the next cmsghdr - structure, if required by the implementation. While sending an - application may or may not include padding at the end of last - ancillary data in msg_controllen and implementations must accept both - as valid. On receiving a portable application must provide space for - padding at the end of the last ancillary data as implementations may - copy out the padding at the end of the control message buffer and - include it in the received msg_controllen. When recvmsg() is called - if msg_controllen is too small for all the ancillary data items - including any trailing padding after the last item an implementation - may set MSG_CTRUNC. - - -22.3. Ancillary Data Object Macros - - To aid in the manipulation of ancillary data objects, three macros - from 4.4BSD are defined by Posix.1g: CMSG_DATA(), CMSG_NXTHDR(), and - CMSG_FIRSTHDR(). Before describing these macros, we show the - following example of how they might be used with a call to recvmsg(). - - - - - - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 49] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - struct msghdr msg; - struct cmsghdr *cmsgptr; - - /* fill in msg */ - - /* call recvmsg() */ - - for (cmsgptr = CMSG_FIRSTHDR(&msg); cmsgptr != NULL; - cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) { - if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) { - u_char *ptr; - - ptr = CMSG_DATA(cmsgptr); - /* process data pointed to by ptr */ - } - } - - We now describe the three Posix.1g macros, followed by two more that - are new with this API: CMSG_SPACE() and CMSG_LEN(). All these macros - are defined as a result of including . - - -22.3.1. CMSG_FIRSTHDR - - - struct cmsghdr *CMSG_FIRSTHDR(const struct msghdr *mhdr); - - CMSG_FIRSTHDR() returns a pointer to the first cmsghdr structure in - the msghdr structure pointed to by mhdr. The macro returns NULL if - there is no ancillary data pointed to the by msghdr structure (that - is, if either msg_control is NULL or if msg_controllen is less than - the size of a cmsghdr structure). - - One possible implementation could be - - #define CMSG_FIRSTHDR(mhdr) \ - ( (mhdr)->msg_controllen >= sizeof(struct cmsghdr) ? \ - (struct cmsghdr *)(mhdr)->msg_control : \ - (struct cmsghdr *)NULL ) - - (Note: Most existing implementations do not test the value of - msg_controllen, and just return the value of msg_control. The value - of msg_controllen must be tested, because if the application asks - recvmsg() to return ancillary data, by setting msg_control to point - to the application's buffer and setting msg_controllen to the length - of this buffer, the kernel indicates that no ancillary data is - available by setting msg_controllen to 0 on return. It is also - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 50] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - easier to put this test into this macro, than making the application - perform the test.) - - -22.3.2. CMSG_NXTHDR - - - struct cmsghdr *CMSG_NXTHDR(const struct msghdr *mhdr, - const struct cmsghdr *cmsg); - - CMSG_NXTHDR() returns a pointer to the cmsghdr structure describing - the next ancillary data object. mhdr is a pointer to a msghdr - structure and cmsg is a pointer to a cmsghdr structure. If there is - not another ancillary data object, the return value is NULL. - - The following behavior of this macro is new to this API: if the value - of the cmsg pointer is NULL, a pointer to the cmsghdr structure - describing the first ancillary data object is returned. That is, - CMSG_NXTHDR(mhdr, NULL) is equivalent to CMSG_FIRSTHDR(mhdr). If - there are no ancillary data objects, the return value is NULL. This - provides an alternative way of coding the processing loop shown - earlier: - - struct msghdr msg; - struct cmsghdr *cmsgptr = NULL; - - /* fill in msg */ - - /* call recvmsg() */ - - while ((cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) != NULL) { - if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) { - u_char *ptr; - - ptr = CMSG_DATA(cmsgptr); - /* process data pointed to by ptr */ - } - } - - - One possible implementation could be: - - - - - - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 51] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - #define CMSG_NXTHDR(mhdr, cmsg) \ - (((cmsg) == NULL) ? CMSG_FIRSTHDR(mhdr) : \ - (((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len) \ - + ALIGN_D(sizeof(struct cmsghdr)) > \ - (u_char *)((mhdr)->msg_control) + (mhdr)->msg_controllen) ? \ - (struct cmsghdr *)NULL : \ - (struct cmsghdr *)((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len)))) - - The macros ALIGN_H() and ALIGN_D(), which are implementation - dependent, round their arguments up to the next even multiple of - whatever alignment is required for the start of the cmsghdr structure - and the data, respectively. (This is probably a multiple of 4 or 8 - bytes.) They are often the same macro in implementations platforms - where alignment requirement for header and data is chosen to be - identical. - - -22.3.3. CMSG_DATA - - - unsigned char *CMSG_DATA(const struct cmsghdr *cmsg); - - CMSG_DATA() returns a pointer to the data (what is called the - cmsg_data[] member, even though such a member is not defined in the - structure) following a cmsghdr structure. - - One possible implementation could be: - - #define CMSG_DATA(cmsg) ( (u_char *)(cmsg) + \ - ALIGN_D(sizeof(struct cmsghdr)) ) - - - -22.3.4. CMSG_SPACE - - - unsigned int CMSG_SPACE(unsigned int length); - - This macro is new with this API. Given the length of an ancillary - data object, CMSG_SPACE() returns an upper bound on the space - required by the object and its cmsghdr structure, including any - padding needed to satisfy alignment requirements. This macro can be - used, for example, to allocate space dynamically for the ancillary - data. This macro should not be used to initialize the cmsg_len - member of a cmsghdr structure; instead use the CMSG_LEN() macro. - - One possible implementation could be: - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 52] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - #define CMSG_SPACE(length) ( ALIGN_D(sizeof(struct cmsghdr)) + \ - ALIGN_H(length) ) - - - -22.3.5. CMSG_LEN - - - unsigned int CMSG_LEN(unsigned int length); - - This macro is new with this API. Given the length of an ancillary - data object, CMSG_LEN() returns the value to store in the cmsg_len - member of the cmsghdr structure, taking into account any padding - needed to satisfy alignment requirements. - - One possible implementation could be: - - #define CMSG_LEN(length) ( ALIGN_D(sizeof(struct cmsghdr)) + length ) - - Note the difference between CMSG_SPACE() and CMSG_LEN(), shown also - in the figure in Section 4.2: the former accounts for any required - padding at the end of the ancillary data object and the latter is the - actual length to store in the cmsg_len member of the ancillary data - object. - - -23. Appendix B: Examples using the inet6_rth_XXX() functions - - Here we show an example for both sending Routing headers and - processing and reversing a received Routing header. - - -23.1. Sending a Routing Header - - As an example of these Routing header functions defined in this - document, we go through the function calls for the example on p. 17 - of [RFC-2460]. The source is S, the destination is D, and the three - intermediate nodes are I1, I2, and I3. - - S -----> I1 -----> I2 -----> I3 -----> D - - src: * S S S S S - dst: D I1 I2 I3 D D - A[1]: I1 I2 I1 I1 I1 I1 - A[2]: I2 I3 I3 I2 I2 I2 - A[3]: I3 D D D I3 I3 - #seg: 3 3 2 1 0 3 - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 53] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - src and dst are the source and destination IPv6 addresses in the IPv6 - header. A[1], A[2], and A[3] are the three addresses in the Routing - header. #seg is the Segments Left field in the Routing header. - - The six values in the column beneath node S are the values in the - Routing header specified by the sending application using sendmsg() - of setsockopt(). The function calls by the sender would look like: - - void *extptr; - int extlen; - struct msghdr msg; - struct cmsghdr *cmsgptr; - int cmsglen; - struct sockaddr_in6 I1, I2, I3, D; - - extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3); - cmsglen = CMSG_LEN(extlen); - cmsgptr = malloc(cmsglen); - cmsgptr->cmsg_len = cmsglen; - cmsgptr->cmsg_level = IPPROTO_IPV6; - cmsgptr->cmsg_type = IPV6_RTHDR; - - optptr = CMSG_DATA(cmsgptr); - optptr = inet6_rth_init(optptr, optlen, IPV6_RTHDR_TYPE_0, 3); - - inet6_rth_add(optptr, &I1.sin6_addr); - inet6_rth_add(optptr, &I2.sin6_addr); - inet6_rth_add(optptr, &I3.sin6_addr); - - msg.msg_control = cmsgptr; - msg.msg_controllen = cmsglen; - - /* finish filling in msg{}, msg_name = D */ - /* call sendmsg() */ - - We also assume that the source address for the socket is not - specified (i.e., the asterisk in the figure). - - The four columns of six values that are then shown between the five - nodes are the values of the fields in the packet while the packet is - in transit between the two nodes. Notice that before the packet is - sent by the source node S, the source address is chosen (replacing - the asterisk), I1 becomes the destination address of the datagram, - the two addresses A[2] and A[3] are "shifted up", and D is moved to - A[3]. - - The columns of values that are shown beneath the destination node are - the values returned by recvmsg(), assuming the application has - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 54] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - enabled both the IPV6_RECVPKTINFO and IPV6_RECVRTHDR socket options. - The source address is S (contained in the sockaddr_in6 structure - pointed to by the msg_name member), the destination address is D - (returned as an ancillary data object in an in6_pktinfo structure), - and the ancillary data object specifying the Routing header will - contain three addresses (I1, I2, and I3). The number of segments in - the Routing header is known from the Hdr Ext Len field in the Routing - header (a value of 6, indicating 3 addresses). - - The return value from inet6_rth_segments() will be 3 and - inet6_rth_getaddr(0) will return I1, inet6_rth_getaddr(1) will return - I2, and inet6_rth_getaddr(2) will return I3, - - If the receiving application then calls inet6_rth_reverse(), the - order of the three addresses will become I3, I2, and I1. - - We can also show what an implementation might store in the ancillary - data object as the Routing header is being built by the sending - process. If we assume a 32-bit architecture where sizeof(struct - cmsghdr) equals 12, with a desired alignment of 4-byte boundaries, - then the call to inet6_rth_space(3) returns 68: 12 bytes for the - cmsghdr structure and 56 bytes for the Routing header (8 + 3*16). - - The call to inet6_rth_init() initializes the ancillary data object to - contain a Type 0 Routing header: - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_len = 20 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_level = IPPROTO_IPV6 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_type = IPV6_RTHDR | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=0 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The first call to inet6_rth_add() adds I1 to the list. - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 55] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_len = 36 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_level = IPPROTO_IPV6 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_type = IPV6_RTHDR | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=1 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[1] = I1 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - cmsg_len is incremented by 16, and the Segments Left field is - incremented by 1. - - The next call to inet6_rth_add() adds I2 to the list. - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 56] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_len = 52 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_level = IPPROTO_IPV6 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_type = IPV6_RTHDR | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=2 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[1] = I1 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[2] = I2 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - cmsg_len is incremented by 16, and the Segments Left field is - incremented by 1. - - The last call to inet6_rth_add() adds I3 to the list. - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 57] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_len = 68 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_level = IPPROTO_IPV6 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_type = IPV6_RTHDR | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=3 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[1] = I1 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[2] = I2 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[3] = I3 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - cmsg_len is incremented by 16, and the Segments Left field is - incremented by 1. - - -23.2. Receiving Routing Headers - - This example assumes that the application has enabled IPV6_RECVRTHDR - socket option. The application prints and reverses a source route - and uses that to echo the received data. - - struct sockaddr_in6 addr; - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 58] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - struct msghdr msg; - struct iovec iov; - struct cmsghdr *cmsgptr; - size_t cmsgspace; - void *optptr; - int optlen; - - int segments; - int i; - char databuf[8192]; - - segments = 100; /* Enough */ - optlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, segments); - cmsgspace = CMSG_SPACE(optlen); - cmsgptr = malloc(cmsgspace); - if (cmsgptr == NULL) { - perror("malloc"); - exit(1); - } - optptr = CMSG_DATA(cmsgptr); - - msg.msg_control = (char *)cmsgptr; - msg.msg_controllen = cmsgspace; - msg.msg_name = (struct sockaddr *)&addr; - msg.msg_namelen = sizeof (addr); - msg.msg_iov = &iov; - msg.msg_iovlen = 1; - iov.iov_base = databuf; - iov.iov_len = sizeof (databuf); - msg.msg_flags = 0; - if (recvmsg(s, &msg, 0) == -1) { - perror("recvmsg"); - return; - } - if (msg.msg_controllen != 0 && - cmsgptr->cmsg_level == IPPROTO_IPV6 && - cmsgptr->cmsg_type == IPV6_RTHDR) { - struct in6_addr *in6; - char asciiname[INET6_ADDRSTRLEN]; - struct ip6_rthdr0 *rthdr; - - rthdr = (struct ip6_rthdr0 *)optptr; - segments = inet6_rth_segments(optptr); - printf("route (%d segments, %d left): ", - segments, rthdr->ip6r0_segleft); - for (i = 0; i < segments; i++) { - in6 = inet6_rth_getaddr(optptr, i); - if (in6 == NULL) - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 59] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - printf(" "); - else - printf("%s ", inet_ntop(AF_INET6, - (void *)in6->s6_addr, - asciiname, INET6_ADDRSTRLEN)); - } - if (inet6_rth_reverse(optptr, optptr) == -1) { - printf("reverse failed"); - return; - } - } - iov.iov_base = databuf; - iov.iov_len = strlen(databuf); - if (sendmsg(s, &msg, 0) == -1) - perror("sendmsg"); - if (cmsgptr != NULL) - free(cmsgptr); - - Note: The above example is a simple illustration. It skips some - error checks involving the MSG_TRUNC and MSG_CTRUNC flags. - - -24. Appendix C: Examples using the inet6_opt_XXX() functions - - This shows how Hop-by-Hop and Destination options can be both built - as well as parsed using the inet6_opt_XXX() functions. This examples - assume that there are defined values for OPT_X and OPT_Y. - - -24.1. Building options - - We now provide an example that builds two Hop-by-Hop options using - the example in Appendix B of [RFC-2460]. - - void *extbuf; - size_t extlen; - int currentlen; - void *databuf; - size_t offset; - uint8_t value1; - uint16_t value2; - uint32_t value4; - uint64_t value8; - - /* Estimate the length */ - currentlen = inet6_opt_init(NULL, 0); - if (currentlen == -1) - return (-1); - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 60] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_X, 12, 8, NULL); - if (currentlen == -1) - return (-1); - currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_Y, 7, 4, NULL); - if (currentlen == -1) - return (-1); - currentlen = inet6_opt_finish(NULL, 0, currentlen); - if (currentlen == -1) - return (-1); - extlen = currentlen; - - extbuf = malloc(extlen); - if (extbuf == NULL) { - perror("malloc"); - return (-1); - } - currentlen = inet6_opt_init(extbuf, extlen); - if (currentlen == -1) - return (-1); - - currentlen = inet6_opt_append(extbuf, extlen, currentlen, - OPT_X, 12, 8, &databuf); - if (currentlen == -1) - return (-1); - /* Insert value 0x12345678 for 4-octet field */ - offset = 0; - value4 = 0x12345678; - offset = inet6_opt_set_val(databuf, offset, &value4, sizeof (value4)); - /* Insert value 0x0102030405060708 for 8-octet field */ - value8 = 0x0102030405060708; - offset = inet6_opt_set_val(databuf, offset, &value8, sizeof (value8)); - - currentlen = inet6_opt_append(extbuf, extlen, currentlen, - OPT_Y, 7, 4, &databuf); - if (currentlen == -1) - return (-1); - /* Insert value 0x01 for 1-octet field */ - offset = 0; - value1 = 0x01; - offset = inet6_opt_set_val(databuf, offset, &value1, sizeof (value1)); - /* Insert value 0x1331 for 2-octet field */ - value2 = 0x1331; - offset = inet6_opt_set_val(databuf, offset, &value2, sizeof (value2)); - /* Insert value 0x01020304 for 4-octet field */ - value4 = 0x01020304; - offset = inet6_opt_set_val(databuf, offset, &value4, sizeof (value4)); - - currentlen = inet6_opt_finish(extbuf, extlen, currentlen); - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 61] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - if (currentlen == -1) - return (-1); - /* extbuf and extlen are now completely formatted */ - - - -24.2. Parsing received options - - This example parses and prints the content of the two options in the - previous example. - - int - print_opt(void *extbuf, size_t extlen) - { - ip6_dest_t *ext; - int currentlen; - uint8_t type; - size_t len; - void *databuf; - size_t offset; - uint8_t value1; - uint16_t value2; - uint32_t value4; - uint64_t value8; - - ext = (ip6_dest_t *)extbuf; - printf("nxt %u, len %u (bytes %d)\n", ext->ip6d_nxt, - ext->ip6d_len, (ext->ip6d_len + 1) * 8); - - currentlen = 0; - while (1) { - currentlen = inet6_opt_next(extbuf, extlen, currentlen, - &type, &len, &databuf); - if (currentlen == -1) - break; - printf("Received opt %u len %u\n", - type, len); - switch (type) { - case IPV6OPT_PAD1: - printf("PAD1\n"); - break; - case IPV6OPT_PADN: - printf("PADN (N=%d)\n", len + 2); - break; - case OPT_X: - offset = 0; - offset = inet6_opt_get_val(databuf, offset, - &value4, sizeof (value4)); - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 62] - -INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 - - - printf("X 4-byte field %x\n", value4); - offset = inet6_opt_get_val(databuf, offset, - &value8, sizeof (value8)); - printf("X 8-byte field %llx\n", value8); - break; - case OPT_Y: - offset = 0; - offset = inet6_opt_get_val(databuf, offset, - &value1, sizeof (value1)); - printf("Y 1-byte field %x\n", value1); - offset = inet6_opt_get_val(databuf, offset, - &value2, sizeof (value2)); - printf("Y 2-byte field %x\n", value2); - offset = inet6_opt_get_val(databuf, offset, - &value4, sizeof (value4)); - printf("Y 4-byte field %x\n", value4); - break; - default: - printf("Unknown option %u\n", type); - break; - } - } - return (0); - } - - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-00.txt [Page 63] - diff --git a/doc/expired/draft-ietf-ipngwg-bsd-api-new-06.txt b/doc/expired/draft-ietf-ipngwg-bsd-api-new-06.txt deleted file mode 100644 index ffcfb0e6d2..0000000000 --- a/doc/expired/draft-ietf-ipngwg-bsd-api-new-06.txt +++ /dev/null @@ -1,2176 +0,0 @@ - -Internet Engineering Task Force R.E. Gilligan (FreeGate) -INTERNET-DRAFT S. Thomson (Bellcore) -Obsoletes RFC 2133 Jim Bound (Compaq) - W. R. Stevens (Consultant) - January 25, 1999 - - - - - - - Basic Socket Interface Extensions for IPv6 - - - - -Status of this Memo - - This document is a submission by the Internet Protocol IPv6 - Working Group of the Internet Engineering Task Force (IETF). - Comments should be submitted to the ipng@sunroof.eng.sun.com - mailing list. - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its - areas, and its working groups. Note that other groups may also - distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet- - Drafts as reference material or to cite them other than as - "work in progress." - - To view the entire list of current Internet-Drafts, please check - the "1id-abstracts.txt" listing contained in the Internet-Drafts - Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net - (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East - Coast), or ftp.isi.edu (US West Coast). - - Distribution of this memo is unlimited. - - -Abstract - -The de facto standard application program interface (API) for TCP/IP -applications is the "sockets" interface. Although this API was -developed for Unix in the early 1980s it has also been implemented on a -wide variety of non-Unix systems. TCP/IP applications written using the -sockets API have in the past enjoyed a high degree of portability and we -would like the same portability with IPv6 applications. But changes are -required to the sockets API to support IPv6 and this memo describes -these changes. These include a new socket address structure to carry -IPv6 addresses, new address conversion functions, and some new socket -options. These extensions are designed to provide access to the basic -IPv6 features required by TCP and UDP applications, including -multicasting, while introducing a minimum of change into the system and -providing complete compatibility for existing IPv4 applications. -Additional extensions for advanced IPv6 features (raw sockets and access -to the IPv6 extension headers) are defined in another document [4]. - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 1] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -Table of Contents: - -1. Introduction.................................................3 -2. Design Considerations........................................3 -2.1 What Needs to be Changed....................................3 -2.2 Data Types..................................................5 -2.3 Headers.....................................................5 -2.4 Structures..................................................5 -3. Socket Interface.............................................5 -3.1 IPv6 Address Family and Protocol Family.....................5 -3.2 IPv6 Address Structure......................................6 -3.3 Socket Address Structure for 4.3BSD-Based Systems...........6 -3.4 Socket Address Structure for 4.4BSD-Based Systems...........7 -3.5 The Socket Functions........................................8 -3.6 Compatibility with IPv4 Applications........................9 -3.7 Compatibility with IPv4 Nodes...............................9 -3.8 IPv6 Wildcard Address......................................10 -3.9 IPv6 Loopback Address......................................11 -3.10 Portability Additions.....................................11 -4. Interface Identification....................................13 -4.1 Name-to-Index..............................................14 -4.2 Index-to-Name..............................................14 -4.3 Return All Interface Names and Indexes.....................15 -4.4 Free Memory................................................15 -5. Socket Options..............................................15 -5.1 Unicast Hop Limit..........................................16 -5.2 Sending and Receiving Multicast Packets....................16 -6. Library Functions...........................................18 -6.1 Nodename-to-Address Translation............................18 -6.2 Address-To-Nodename Translation............................21 -6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....22 -6.4 Protocol-Independent Nodename and Service Name Translation.22 -6.5 Socket Address Structure to Nodename and Service Name......25 -6.6 Address Conversion Functions...............................26 -6.7 Address Testing Macros.....................................27 -7. Summary of New Definitions..................................28 -8. Security Considerations.....................................29 -9. Year 2000 Considerations....................................29 -Changes From RFC 2133..........................................30 -Acknowledgments................................................32 -References.....................................................33 -Authors' Addresses.............................................33 - - - - - - - - - - - - - - - - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 2] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -1. Introduction - -While IPv4 addresses are 32 bits long, IPv6 interfaces are identified by -128-bit addresses. The socket interface makes the size of an IP address -quite visible to an application; virtually all TCP/IP applications for -BSD-based systems have knowledge of the size of an IP address. Those -parts of the API that expose the addresses must be changed to -accommodate the larger IPv6 address size. IPv6 also introduces new -features (e.g., traffic class and flowlabel), some of which must be made -visible to applications via the API. This memo defines a set of -extensions to the socket interface to support the larger address size -and new features of IPv6. - - - -2. Design Considerations - -There are a number of important considerations in designing changes to -this well-worn API: - - - The API changes should provide both source and binary - compatibility for programs written to the original API. That - is, existing program binaries should continue to operate when - run on a system supporting the new API. In addition, existing - applications that are re-compiled and run on a system supporting - the new API should continue to operate. Simply put, the API - changes for IPv6 should not break existing programs. An additonal - mechanism for implementations to verify this is to verify the new - symbols are protected by Feature Test Macros as described in IEEE Std - 1003.1. (Such Feature Test Macros are not defined by this RFC.) - - - The changes to the API should be as small as possible in order - to simplify the task of converting existing IPv4 applications to - IPv6. - - - Where possible, applications should be able to use this - API to interoperate with both IPv6 and IPv4 hosts. Applications - should not need to know which type of host they are - communicating with. - - - IPv6 addresses carried in data structures should be 64-bit - aligned. This is necessary in order to obtain optimum - performance on 64-bit machine architectures. - -Because of the importance of providing IPv4 compatibility in the API, -these extensions are explicitly designed to operate on machines that -provide complete support for both IPv4 and IPv6. A subset of this API -could probably be designed for operation on systems that support only -IPv6. However, this is not addressed in this memo. - - - -2.1 What Needs to be Changed - -The socket interface API consists of a few distinct components: - - - Core socket functions. - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 3] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - - - Address data structures. - - - Name-to-address translation functions. - - - Address conversion functions. - -The core socket functions -- those functions that deal with such things -as setting up and tearing down TCP connections, and sending and -receiving UDP packets -- were designed to be transport independent. -Where protocol addresses are passed as function arguments, they are -carried via opaque pointers. A protocol-specific address data structure -is defined for each protocol that the socket functions support. -Applications must cast pointers to these protocol-specific address -structures into pointers to the generic "sockaddr" address structure -when using the socket functions. These functions need not change for -IPv6, but a new IPv6-specific address data structure is needed. - -The "sockaddr_in" structure is the protocol-specific data structure for -IPv4. This data structure actually includes 8-octets of unused space, -and it is tempting to try to use this space to adapt the sockaddr_in -structure to IPv6. Unfortunately, the sockaddr_in structure is not -large enough to hold the 16-octet IPv6 address as well as the other -information (address family and port number) that is needed. So a new -address data structure must be defined for IPv6. - -IPv6 addresses are scoped [2] so they could be link-local, site, -organization, global, or other scopes at this time undefined. To -support applications that want to be able to identify a set of -interfaces for a specific scope, the IPv6 sockaddr_in structure must -support a field that can be used by an implementation to identify a set -of interfaces identifying the scope for an IPv6 address. - -The name-to-address translation functions in the socket interface are -gethostbyname() and gethostbyaddr(). These are left as is and new -functions are defined to support IPv4 and IPv6. Additionally, the POSIX -1003.g draft [3] specifies a new nodename-to-address translation -function which is protocol independent. This function can also be used -with IPv4 and IPv6. - -The address conversion functions -- inet_ntoa() and inet_addr() -- -convert IPv4 addresses between binary and printable form. These -functions are quite specific to 32-bit IPv4 addresses. We have designed -two analogous functions that convert both IPv4 and IPv6 addresses, and -carry an address type parameter so that they can be extended to other -protocol families as well. - -Finally, a few miscellaneous features are needed to support IPv6. New -interfaces are needed to support the IPv6 traffic class, flow label, and -hop limit header fields. New socket options are needed to control the -sending and receiving of IPv6 multicast packets. - -The socket interface will be enhanced in the future to provide access to -other IPv6 features. These extensions are described in [4]. - - - - - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 4] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -2.2 Data Types - -The data types of the structure elements given in this memo are intended -to be examples, not absolute requirements. Whenever possible, data -types from Draft 6.6 (March 1997) of POSIX 1003.1g are used: uintN_t -means an unsigned integer of exactly N bits (e.g., uint16_t). We also -assume the argument data types from 1003.1g when possible (e.g., the -final argument to setsockopt() is a size_t value). Whenever buffer -sizes are specified, the POSIX 1003.1 size_t data type is used (e.g., -the two length arguments to getnameinfo()). - - - -2.3 Headers - -When function prototypes and structures are shown we show the headers -that must be #included to cause that item to be defined. - - - -2.4 Structures - -When structures are described the members shown are the ones that must -appear in an implementation. Additional, nonstandard members may also -be defined by an implementation. As an additional precaution -nonstandard members could be verified by Feature Test Macros as -described in IEEE Std 1003.1. (Such Feature Test Macros are not defined -by this RFC.) - -The ordering shown for the members of a structure is the recommended -ordering, given alignment considerations of multibyte members, but an -implementation may order the members differently. - - - -3. Socket Interface - -This section specifies the socket interface changes for IPv6. - - - -3.1 IPv6 Address Family and Protocol Family - -A new address family name, AF_INET6, is defined in . The -AF_INET6 definition distinguishes between the original sockaddr_in -address data structure, and the new sockaddr_in6 data structure. - -A new protocol family name, PF_INET6, is defined in . -Like most of the other protocol family names, this will usually be -defined to have the same value as the corresponding address family name: - - #define PF_INET6 AF_INET6 - -The PF_INET6 is used in the first argument to the socket() function to -indicate that an IPv6 socket is being created. - - - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 5] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -3.2 IPv6 Address Structure - -A new in6_addr structure holds a single IPv6 address and is defined as a -result of including : - - struct in6_addr { - uint8_t s6_addr[16]; /* IPv6 address */ - }; - -This data structure contains an array of sixteen 8-bit elements, which -make up one 128-bit IPv6 address. The IPv6 address is stored in network -byte order. - -The structure in6_addr above is usually implemented with an embedded -union with extra fields that force the desired alignment level in a -manner similar to BSD implementations of "struct in_addr". Those -additional implementation details are omitted here for simplicity. - -An example is as follows: - -struct in6_addr { - union { - uint8_t _S6_u8[16]; - uint32_t _S6_u32[4]; - uint64_t _S6_u64[2]; - } _S6_un; -}; -#define s6_addr _S6_un._S6_u8 - - - -3.3 Socket Address Structure for 4.3BSD-Based Systems - -In the socket interface, a different protocol-specific data structure is -defined to carry the addresses for each protocol suite. Each protocol- -specific data structure is designed so it can be cast into a protocol- -independent data structure -- the "sockaddr" structure. Each has a -"family" field that overlays the "sa_family" of the sockaddr data -structure. This field identifies the type of the data structure. - -The sockaddr_in structure is the protocol-specific address data -structure for IPv4. It is used to pass addresses between applications -and the system in the socket functions. The following sockaddr_in6 -structure holds IPv6 addresses and is defined as a result of including -the header: - - struct sockaddr_in6 { - sa_family_t sin6_family; /* AF_INET6 */ - in_port_t sin6_port; /* transport layer port # */ - uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */ - struct in6_addr sin6_addr; /* IPv6 address */ - uint32_t sin6_scope_id; /* set of interfaces for a scope */ - }; - -This structure is designed to be compatible with the sockaddr data -structure used in the 4.3BSD release. - -The sin6_family field identifies this as a sockaddr_in6 structure. This - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 6] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -field overlays the sa_family field when the buffer is cast to a sockaddr -data structure. The value of this field must be AF_INET6. - -The sin6_port field contains the 16-bit UDP or TCP port number. This -field is used in the same way as the sin_port field of the sockaddr_in -structure. The port number is stored in network byte order. - -The sin6_flowinfo field is a 32-bit field that contains two pieces of -information: the traffic class and the flow label. The contents and -interpretation of this member is specified in [1]. The sin6_flowinfo -field SHOULD be set to zero by an implementation prior to using the -sockaddr_in6 structure by an application on receive operations. - -The sin6_addr field is a single in6_addr structure (defined in the -previous section). This field holds one 128-bit IPv6 address. The -address is stored in network byte order. - -The ordering of elements in this structure is specifically designed so -that when sin6_addr field is aligned on a 64-bit boundary, the start of -the structure will also be aligned on a 64-bit boundary. This is done -for optimum performance on 64-bit architectures. - -The sin6_scope_id field is a 32-bit integer that identifies a set of -interfaces as appropriate for the scope of the address carried in the -sin6_addr field. For a link scope sin6_addr sin6_scope_id would be an -interface index. For a site scope sin6_addr, sin6_scope_id would be a -site identifier. The mapping of sin6_scope_id to an interface or set of -interfaces is left to implementation and future specifications on the -subject of site identifiers. - -Notice that the sockaddr_in6 structure will normally be larger than the -generic sockaddr structure. On many existing implementations the -sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both -being 16 bytes. Any existing code that makes this assumption needs to -be examined carefully when converting to IPv6. - - - -3.4 Socket Address Structure for 4.4BSD-Based Systems - -The 4.4BSD release includes a small, but incompatible change to the -socket interface. The "sa_family" field of the sockaddr data structure -was changed from a 16-bit value to an 8-bit value, and the space saved -used to hold a length field, named "sa_len". The sockaddr_in6 data -structure given in the previous section cannot be correctly cast into -the newer sockaddr data structure. For this reason, the following -alternative IPv6 address data structure is provided to be used on -systems based on 4.4BSD. It is defined as a result of including the - header. - - struct sockaddr_in6 { - uint8_t sin6_len; /* length of this struct */ - sa_family_t sin6_family; /* AF_INET6 */ - in_port_t sin6_port; /* transport layer port # */ - uint32_t sin6_flowinfo; /* IPv6 flow information */ - struct in6_addr sin6_addr; /* IPv6 address */ - uint32_t sin6_scope_id; /* set of interfaces for a scope */ - }; - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 7] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -The only differences between this data structure and the 4.3BSD variant -are the inclusion of the length field, and the change of the family -field to a 8-bit data type. The definitions of all the other fields are -identical to the structure defined in the previous section. - -Systems that provide this version of the sockaddr_in6 data structure -must also declare SIN6_LEN as a result of including the -header. This macro allows applications to determine whether they are -being built on a system that supports the 4.3BSD or 4.4BSD variants of -the data structure. - - - -3.5 The Socket Functions - -Applications call the socket() function to create a socket descriptor -that represents a communication endpoint. The arguments to the socket() -function tell the system which protocol to use, and what format address -structure will be used in subsequent functions. For example, to create -an IPv4/TCP socket, applications make the call: - - s = socket(PF_INET, SOCK_STREAM, 0); - -To create an IPv4/UDP socket, applications make the call: - - s = socket(PF_INET, SOCK_DGRAM, 0); - -Applications may create IPv6/TCP and IPv6/UDP sockets by simply using -the constant PF_INET6 instead of PF_INET in the first argument. For -example, to create an IPv6/TCP socket, applications make the call: - - s = socket(PF_INET6, SOCK_STREAM, 0); - -To create an IPv6/UDP socket, applications make the call: - - s = socket(PF_INET6, SOCK_DGRAM, 0); - -Once the application has created a PF_INET6 socket, it must use the -sockaddr_in6 address structure when passing addresses in to the system. -The functions that the application uses to pass addresses into the -system are: - - bind() - connect() - sendmsg() - sendto() - -The system will use the sockaddr_in6 address structure to return -addresses to applications that are using PF_INET6 sockets. The -functions that return an address from the system to an application are: - - accept() - recvfrom() - recvmsg() - getpeername() - getsockname() - -No changes to the syntax of the socket functions are needed to support - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 8] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -IPv6, since all of the "address carrying" functions use an opaque -address pointer, and carry an address length as a function argument. - - - -3.6 Compatibility with IPv4 Applications - -In order to support the large base of applications using the original -API, system implementations must provide complete source and binary -compatibility with the original API. This means that systems must -continue to support PF_INET sockets and the sockaddr_in address -structure. Applications must be able to create IPv4/TCP and IPv4/UDP -sockets using the PF_INET constant in the socket() function, as -described in the previous section. Applications should be able to hold -a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets -simultaneously within the same process. - -Applications using the original API should continue to operate as they -did on systems supporting only IPv4. That is, they should continue to -interoperate with IPv4 nodes. - - - -3.7 Compatibility with IPv4 Nodes - -The API also provides a different type of compatibility: the ability for -IPv6 applications to interoperate with IPv4 applications. This feature -uses the IPv4-mapped IPv6 address format defined in the IPv6 addressing -architecture specification [2]. This address format allows the IPv4 -address of an IPv4 node to be represented as an IPv6 address. The IPv4 -address is encoded into the low-order 32 bits of the IPv6 address, and -the high-order 96 bits hold the fixed prefix 0:0:0:0:0:FFFF. IPv4- -mapped addresses are written as follows: - - ::FFFF: - -These addresses can be generated automatically by the getipnodebyname() -function when the specified host has only IPv4 addresses (as described -in Section 6.1). - -Applications may use PF_INET6 sockets to open TCP connections to IPv4 -nodes, or send UDP packets to IPv4 nodes, by simply encoding the -destination's IPv4 address as an IPv4-mapped IPv6 address, and passing -that address, within a sockaddr_in6 structure, in the connect() or -sendto() call. When applications use PF_INET6 sockets to accept TCP -connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the -system returns the peer's address to the application in the accept(), -recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded -this way. - -Few applications will likely need to know which type of node they are -interoperating with. However, for those applications that do need to -know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is -provided. - - - - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 9] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -3.8 IPv6 Wildcard Address - -While the bind() function allows applications to select the source IP -address of UDP packets and TCP connections, applications often want the -system to select the source address for them. With IPv4, one specifies -the address as the symbolic constant INADDR_ANY (called the "wildcard" -address) in the bind() call, or simply omits the bind() entirely. - -Since the IPv6 address type is a structure (struct in6_addr), a symbolic -constant can be used to initialize an IPv6 address variable, but cannot -be used in an assignment. Therefore systems provide the IPv6 wildcard -address in two forms. - -The first version is a global variable named "in6addr_any" that is an -in6_addr structure. The extern declaration for this variable is defined -in : - - extern const struct in6_addr in6addr_any; - -Applications use in6addr_any similarly to the way they use INADDR_ANY in -IPv4. For example, to bind a socket to port number 23, but let the -system select the source address, an application could use the following -code: - - struct sockaddr_in6 sin6; - . . . - sin6.sin6_family = AF_INET6; - sin6.sin6_flowinfo = 0; - sin6.sin6_port = htons(23); - sin6.sin6_addr = in6addr_any; /* structure assignment */ - . . . - if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) - . . . - -The other version is a symbolic constant named IN6ADDR_ANY_INIT and is -defined in . This constant can be used to initialize an -in6_addr structure: - - struct in6_addr anyaddr = IN6ADDR_ANY_INIT; - -Note that this constant can be used ONLY at declaration time. It can -not be used to assign a previously declared in6_addr structure. For -example, the following code will not work: - - /* This is the WRONG way to assign an unspecified address */ - struct sockaddr_in6 sin6; - . . . - sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */ - -Be aware that the IPv4 INADDR_xxx constants are all defined in host byte -order but the IPv6 IN6ADDR_xxx constants and the IPv6 in6addr_xxx -externals are defined in network byte order. - - - - - - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 10] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -3.9 IPv6 Loopback Address - -Applications may need to send UDP packets to, or originate TCP -connections to, services residing on the local node. In IPv4, they can -do this by using the constant IPv4 address INADDR_LOOPBACK in their -connect(), sendto(), or sendmsg() call. - -IPv6 also provides a loopback address to contact local TCP and UDP -services. Like the unspecified address, the IPv6 loopback address is -provided in two forms -- a global variable and a symbolic constant. - -The global variable is an in6_addr structure named "in6addr_loopback." -The extern declaration for this variable is defined in : - - extern const struct in6_addr in6addr_loopback; - -Applications use in6addr_loopback as they would use INADDR_LOOPBACK in -IPv4 applications (but beware of the byte ordering difference mentioned -at the end of the previous section). For example, to open a TCP -connection to the local telnet server, an application could use the -following code: - - struct sockaddr_in6 sin6; - . . . - sin6.sin6_family = AF_INET6; - sin6.sin6_flowinfo = 0; - sin6.sin6_port = htons(23); - sin6.sin6_addr = in6addr_loopback; /* structure assignment */ - . . . - if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) - . . . - -The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined in -. It can be used at declaration time ONLY; for example: - - struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT; - -Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to -a previously declared IPv6 address variable. - - - -3.10 Portability Additions - -One simple addition to the sockets API that can help application writers -is the "struct sockaddr_storage". This data structure can simplify -writing code portable across multiple address families and platforms. -This data structure is designed with the following goals. - - - It has a large enough implementation specific maximum size to store - the desired set of protocol specific socket address data structures. - Specifically, it is at least large enough to accommodate sockaddr_in - and sockaddr_in6 and possibly other protocol specific socket - addresses too. - - It is aligned at an appropriate boundary so protocol specific socket - address data structure pointers can be cast to it and access their - fields without alignment problems. (e.g. pointers to sockaddr_in6 - and/or sockaddr_in can be cast to it and access fields without alignment - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 11] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - - problems). - - It has the initial field(s) isomorphic to the fields of the - "struct sockaddr" data structure on that implementation which - can be used as a discriminants for deriving the protocol in use. - These initial field(s) would on most implementations either be a - single field of type "sa_family_t" (isomorphic to sa_family field, - 16 bits) or two fields of type uint8_t and sa_family_t respectively, - (isomorphic to sa_len and sa_family_t, 8 bits each). - -An example implementation design of such a data structure would be as -follows. - -/* - * Desired design of maximum size and alignment - */ -#define _SS_MAXSIZE 128 /* Implementation specific max size */ -#define _SS_ALIGNSIZE (sizeof (int64_t)) - /* Implementation specific desired alignment */ -/* - * Definitions used for sockaddr_storage structure paddings design. - */ -#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) -#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+ - _SS_PAD1SIZE + _SS_ALIGNSIZE)) -struct sockaddr_storage { - sa_family_t __ss_family; /* address family */ - /* Following fields are implementation specific */ - char __ss_pad1[_SS_PAD1SIZE]; - /* 6 byte pad, this is to make implementation - /* specific pad up to alignment field that */ - /* follows explicit in the data structure */ - int64_t __ss_align; /* field to force desired structure */ - /* storage alignment */ - char __ss_pad2[_SS_PAD2SIZE]; - /* 112 byte pad to achieve desired size, */ - /* _SS_MAXSIZE value minus size of ss_family */ - /* __ss_pad1, __ss_align fields is 112 */ -}; - -On implementations where sockaddr data structure includes a "sa_len", -field this data structure would look like this: - -/* - * Definitions used for sockaddr_storage structure paddings design. - */ -#define _SS_PAD1SIZE (_SS_ALIGNSIZE - - (sizeof (uint8_t) + sizeof (sa_family_t)) -#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+ - _SS_PAD1SIZE + _SS_ALIGNSIZE)) -struct sockaddr_storage { - uint8_t __ss_len; /* address length */ - sa_family_t __ss_family; /* address family */ - /* Following fields are implementation specific */ - char __ss_pad1[_SS_PAD1SIZE]; - /* 6 byte pad, this is to make implementation - /* specific pad up to alignment field that */ - /* follows explicit in the data structure */ - int64_t __ss_align; /* field to force desired structure */ - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 12] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - - /* storage alignment */ - char __ss_pad2[_SS_PAD2SIZE]; - /* 112 byte pad to achieve desired size, */ - /* _SS_MAXSIZE value minus size of ss_len, */ - /* __ss_family, __ss_pad1, __ss_align fields is 112 */ -}; - -The above example implementation illustrates a data structure which will -align on a 64 bit boundary. An implementation specific field -"__ss_align" along "__ss_pad1" is used to force a 64-bit alignment which -covers proper alignment good enough for needs of sockaddr_in6 (IPv6), -sockaddr_in (IPv4) address data structures. The size of padding fields -__ss_pad1 depends on the chosen alignment boundary. The size of padding -field __ss_pad2 depends on the value of overall size chosen for the -total size of the structure. This size and alignment are represented in -the above example by implementation specific (not required) constants -_SS_MAXSIZE (chosen value 128) and _SS_ALIGNMENT (with chosen value 8). -Constants _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value -112) are also for illustration and not required. The implementation -specific definitions and structure field names above start with an -underscore to denote implementation private namespace. Portable code is -not expected to access or reference those fields or constants. - -The sockaddr_storage structure solves the problem of declaring storage -for automatic variables which is large enough and aligned enough for -storing socket address data structure of any family. For example, code -with a file descriptor and without the context of the address family can -pass a pointer to a variable of this type where a pointer to a socket -address structure is expected in calls such as getpeername() and -determine the address family by accessing the received content after the -call. - -The sockaddr_storage structure may also be useful and applied to certain -other interfaces where a generic socket address large enough and aligned -for use with multiple address families may be needed. A discussion of -those interfaces is outside the scope of this document. - -Also, much existing code assumes that any socket address structure can -fit in a generic sockaddr structure. While this has been true for IPv4 -socket address structures, it has always been false for Unix domain -socket address structures (but in practice this has not been a problem) -and it is also false for IPv6 socket address structures (which can be a -problem). - -So now an application can do the following: - - struct sockaddr_storage __ss; - struct sockaddr_in6 *sin6; - sin6 = (struct sockaddr_in6 *) &__ss; - - - -4. Interface Identification - -This API uses an interface index (a small positive integer) to identify -the local interface on which a multicast group is joined (Section 5.3). -Additionally, the advanced API [4] uses these same interface indexes to -identify the interface on which a datagram is received, or to specify - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 13] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -the interface on which a datagram is to be sent. - -Interfaces are normally known by names such as "le0", "sl1", "ppp2", and -the like. On Berkeley-derived implementations, when an interface is -made known to the system, the kernel assigns a unique positive integer -value (called the interface index) to that interface. These are small -positive integers that start at 1. (Note that 0 is never used for an -interface index.) There may be gaps so that there is no current -interface for a particular positive interface index. - -This API defines two functions that map between an interface name and -index, a third function that returns all the interface names and -indexes, and a fourth function to return the dynamic memory allocated by -the previous function. How these functions are implemented is left up -to the implementation. 4.4BSD implementations can implement these -functions using the existing sysctl() function with the NET_RT_IFLIST -command. Other implementations may wish to use ioctl() for this -purpose. - - - -4.1 Name-to-Index - -The first function maps an interface name into its corresponding index. - - #include - - unsigned int if_nametoindex(const char *ifname); - -If the specified interface name does not exist, the return value is 0, -and errno is set to ENXIO. If there was a system error (such as -running out of memory), the return value is 0 and errno is set to the -proper value (e.g., ENOMEM). - - - -4.2 Index-to-Name - -The second function maps an interface index into its corresponding name. - - #include - - char *if_indextoname(unsigned int ifindex, char *ifname); - -The ifname argument must point to a buffer of at least IF_NAMESIZE bytes -into which the interface name corresponding to the specified index is -returned. (IF_NAMESIZE is also defined in and its value -includes a terminating null byte at the end of the interface name.) This -pointer is also the return value of the function. If there is no -interface corresponding to the specified index, NULL is returned, and -errno is set to ENXIO, if there was a system error (such as running out -of memory), if_indextoname returns NULL and errno would be set to the -proper value (e.g., ENOMEM). - - - - - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 14] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -4.3 Return All Interface Names and Indexes - -The if_nameindex structure holds the information about a single -interface and is defined as a result of including the header. - - struct if_nameindex { - unsigned int if_index; /* 1, 2, ... */ - char *if_name; /* null terminated name: "le0", ... */ - }; - -The final function returns an array of if_nameindex structures, one -structure per interface. - - struct if_nameindex *if_nameindex(void); - -The end of the array of structures is indicated by a structure with an -if_index of 0 and an if_name of NULL. The function returns a NULL -pointer upon an error, and would set errno to the appropriate value. - -The memory used for this array of structures along with the interface -names pointed to by the if_name members is obtained dynamically. This -memory is freed by the next function. - - - -4.4 Free Memory - -The following function frees the dynamic memory that was allocated by -if_nameindex(). - - #include - - void if_freenameindex(struct if_nameindex *ptr); - -The argument to this function must be a pointer that was returned by -if_nameindex(). - -Currently net/if.h doesn't have prototype definitions for functions and -it is recommended that these definitions be defined in net/if.h as well -and the struct if_nameindex{}. - - - -5. Socket Options - -A number of new socket options are defined for IPv6. All of these new -options are at the IPPROTO_IPV6 level. That is, the "level" parameter -in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 when using -these options. The constant name prefix IPV6_ is used in all of the new -socket options. This serves to clearly identify these options as -applying to IPv6. - -The declaration for IPPROTO_IPV6, the new IPv6 socket options, and -related constants defined in this section are obtained by including the -header . - - - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 15] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -5.1 Unicast Hop Limit - -A new setsockopt() option controls the hop limit used in outgoing -unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, and -it is used at the IPPROTO_IPV6 layer. The following example illustrates -how it is used: - - int hoplimit = 10; - - if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, - (char *) &hoplimit, sizeof(hoplimit)) == -1) - perror("setsockopt IPV6_UNICAST_HOPS"); - -When the IPV6_UNICAST_HOPS option is set with setsockopt(), the option -value given is used as the hop limit for all subsequent unicast packets -sent via that socket. If the option is not set, the system selects a -default value. The integer hop limit value (called x) is interpreted as -follows: - - x < -1: return an error of EINVAL - x == -1: use kernel default - 0 <= x <= 255: use x - x >= 256: return an error of EINVAL - -The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine -the hop limit value that the system will use for subsequent unicast -packets sent via that socket. For example: - - int hoplimit; - size_t len = sizeof(hoplimit); - - if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, - (char *) &hoplimit, &len) == -1) - perror("getsockopt IPV6_UNICAST_HOPS"); - else - printf("Using %d for hop limit.\n", hoplimit); - - - -5.2 Sending and Receiving Multicast Packets - -IPv6 applications may send UDP multicast packets by simply specifying an -IPv6 multicast address in the address argument of the sendto() function. - -Three socket options at the IPPROTO_IPV6 layer control some of the -parameters for sending multicast packets. Setting these options is not -required: applications may send multicast packets without using these -options. The setsockopt() options for controlling the sending of -multicast packets are summarized below. These three options can also be -used with getsockopt(). - - IPV6_MULTICAST_IF - - Set the interface to use for outgoing multicast packets. - The argument is the index of the interface to use. - - Argument type: unsigned int - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 16] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - - IPV6_MULTICAST_HOPS - - Set the hop limit to use for outgoing multicast packets. - (Note a separate option - IPV6_UNICAST_HOPS - is - provided to set the hop limit to use for outgoing - unicast packets.) - - The interpretation of the argument is the same - as for the IPV6_UNICAST_HOPS option: - - x < -1: return an error of EINVAL - x == -1: use kernel default - 0 <= x <= 255: use x - x >= 256: return an error of EINVAL - - If IPV6_MULTICAST_HOPS is not set, the default is 1 - (same as IPv4 today) - - Argument type: int - - IPV6_MULTICAST_LOOP - - If a multicast datagram is sent to a group to which the sending host - itself belongs (on the outgoing interface), a copy of the datagram is - looped back by the IP layer for local delivery if this option is set to - 1. If this option is set to 0 a copy is not looped back. Other option - values return an error of EINVAL. - - If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same as - IPv4 today). - - Argument type: unsigned int - -The reception of multicast packets is controlled by the two setsockopt() -options summarized below. An error of EOPNOTSUPP is returned if these -two options are used with getsockopt(). - - IPV6_JOIN_GROUP - - Join a multicast group on a specified local interface. - If the interface index is specified as 0, - the kernel chooses the local interface. - For example, some kernels look up the multicast group - in the normal IPv6 routing table and using the resulting interface. - - Argument type: struct ipv6_mreq - - IPV6_LEAVE_GROUP - - Leave a multicast group on a specified interface. - - Argument type: struct ipv6_mreq - -The argument type of both of these options is the ipv6_mreq structure, -defined as a result of including the header; - - struct ipv6_mreq { - struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 17] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - - unsigned int ipv6mr_interface; /* interface index */ - }; - -Note that to receive multicast datagrams a process must join the -multicast group and bind the UDP port to which datagrams will be sent. -Some processes also bind the multicast group address to the socket, in -addition to the port, to prevent other datagrams destined to that same -port from being delivered to the socket. - - - -6. Library Functions - -New library functions are needed to perform a variety of operations with -IPv6 addresses. Functions are needed to lookup IPv6 addresses in the -Domain Name System (DNS). Both forward lookup (nodename-to-address -translation) and reverse lookup (address-to-nodename translation) need -to be supported. Functions are also needed to convert IPv6 addresses -between their binary and textual form. - -We note that the two existing functions, gethostbyname() and -gethostbyaddr(), are left as-is. New functions are defined to handle -both IPv4 and IPv6 addresses. - - - -6.1 Nodename-to-Address Translation - -The commonly used function gethostbyname() is inadequate for many -applications, first because it provides no way for the caller to specify -anything about the types of addresses desired (IPv4 only, IPv6 only, -IPv4-mapped IPv6 are OK, etc.), and second because many implementations -of this function are not thread safe. RFC 2133 defined a function named -gethostbyname2() but this function was also inadequate, first because -its use required setting a global option (RES_USE_INET6) when IPv6 -addresses were required, and second because a flag argument is needed to -provide the caller with additional control over the types of addresses -required. - -The following function is new and must be thread safe: - - #include - #include - - struct hostent *getipnodebyname(const char *name, int af, int flags - int *error_num); - -The name argument can be either a node name or a numeric address string -(i.e., a dotted-decimal IPv4 address or an IPv6 hex address). The af -argument specifies the address family, either AF_INET or AF_INET6. The -error_num value is returned to the caller, via a pointer, with the -appropriate error code in error_num, to support thread safe error code -returns. error_num will be set to one of the following values: - - HOST_NOT_FOUND - - No such host is known. - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 18] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - - NO_ADDRESS - - The server recognised the request and the name but no address - is available. Another type of request to the name server for - the domain might return an answer. - - NO_RECOVERY - - An unexpected server failure occurred which cannot be recovered. - - TRY_AGAIN - - A temporary and possibly transient error occurred, such as a - failure of a server to respond. - - -The flags argument specifies the types of addresses that are searched -for, and the types of addresses that are returned. We note that a -special flags value of AI_DEFAULT (defined below) should handle most -applications. - -That is, porting simple applications to use IPv6 replaces the call - - hptr = gethostbyname(name); - -with - - hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num); - -and changes any subsequent error diagnosis code to use error_num instead -of externally declared variables, such as h_errno. - -Applications desiring finer control over the types of addresses searched -for and returned, can specify other combinations of the flags argument. - -A flags of 0 implies a strict interpretation of the af argument: - - - If flags is 0 and af is AF_INET, then the caller wants only IPv4 - addresses. A query is made for A records. If successful, the IPv4 - addresses are returned and the h_length member of the hostent - structure will be 4, else the function returns a NULL pointer. - - - If flags is 0 and if af is AF_INET6, then the caller wants only - IPv6 addresses. A query is made for AAAA records. If successful, - the IPv6 addresses are returned and the h_length member of the - hostent structure will be 16, else the function returns a NULL - pointer. - -Other constants can be logically-ORed into the flags argument, to modify -the behavior of the function. - - - If the AI_V4MAPPED flag is specified along with an af of - AF_INET6, then the caller will accept IPv4-mapped IPv6 - addresses. That is, if no AAAA records are found then a query - is made for A records and any found are returned as IPv4-mapped - IPv6 addresses (h_length will be 16). The AI_V4MAPPED flag is - ignored unless af equals AF_INET6. - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 19] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - - - The AI_ALL flag is used in conjunction with the AI_V4MAPPED - flag, and is only used with the IPv6 address family. When AI_ALL - is logically or'd with AI_V4MAPPED flag then the caller wants - all addresses: IPv6 and IPv4-mapped IPv6. A query is first made - for AAAA records and if successful, the IPv6 addresses are returned. - Another query is then made for A records and any found are returned - as IPv4-mapped IPv6 addresses. h_length will be 16. Only if both - queries fail does the function return a NULL pointer. This flag is - ignored unless af equals AF_INET6. - - - The AI_ADDRCONFIG flag specifies that a query for AAAA records - should occur only if the node has at least one IPv6 source address - configured and a query for A records should occur only if the - node has at least one IPv4 source address configured. - - For example, if the node has no IPv6 source addresses configured, - and af equals AF_INET6, and the node name being looked up has both - AAAA and A records, then: - - (a) if only AI_ADDRCONFIG is specified, the function returns a - NULL pointer; - (b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A records - are returned as IPv4-mapped IPv6 addresses; - -The special flags value of AI_DEFAULT is defined as - - #define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG) - -We noted that the getipnodebyname() function must allow the name -argument to be either a node name or a literal address string (i.e., a -dotted-decimal IPv4 address or an IPv6 hex address). This saves -applications from having to call inet_pton() to handle literal address -strings. - -There are four scenarios based on the type of literal address string and -the value of the af argument. - -The two simple cases are: - -When name is a dotted-decimal IPv4 address and af equals AF_INET, or -when name is an IPv6 hex address and af equals AF_INET6. The members of -the returned hostent structure are: h_name points to a copy of the name -argument, h_aliases is a NULL pointer, h_addrtype is a copy of the af -argument, h_length is either 4 (for AF_INET) or 16 (for AF_INET6), -h_addr_list[0] is a pointer to the 4-byte or 16-byte binary address, and -h_addr_list[1] is a NULL pointer. - -When name is a dotted-decimal IPv4 address and af equals AF_INET6, and -flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is returned: -h_name points to an IPv6 hex address containing the IPv4-mapped IPv6 -address, h_aliases is a NULL pointer, h_addrtype is AF_INET6, h_length -is 16, h_addr_list[0] is a pointer to the 16-byte binary address, and -h_addr_list[1] is a NULL pointer. If AI_V4MAPPED is set (with or -without AI_ALL) return IPv4-mapped otherwise return NULL. - -It is an error when name is an IPv6 hex address and af equals AF_INET. -The function's return value is a NULL pointer and error_num equals -HOST_NOT_FOUND. - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 20] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -6.2 Address-To-Nodename Translation - -The following function has the same arguments as the existing -gethostbyaddr() function, but adds an error number. - - #include - #include - - struct hostent *getipnodebyaddr(const void *src, size_t len, int af, - int *error_num); - -As with getipnodebyname(), getipnodebyaddr() must be thread safe. The -error_num value is returned to the caller with the appropriate error -code, to support thread safe error code returns. The following error -conditions may be returned for error_num: - - HOST_NOT_FOUND - - No such host is known. - - NO_ADDRESS - - The server recognized the request and the name but no address - is available. Another type of request to the name server for - the domain might return an answer. - - NO_RECOVERY - - An unexpected server failure occurred which cannot be recovered. - - TRY_AGAIN - - A temporary and possibly transient error occurred, such as a - failure of a server to respond. - - -One possible source of confusion is the handling of IPv4-mapped IPv6 -addresses and IPv4-compatible IPv6 addresses, but the following logic -should apply. - - 1. If af is AF_INET6, and if len equals 16, and if the IPv6 address - is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, - then skip over the first 12 bytes of the IPv6 address, set af to - AF_INET, and set len to 4. - - 2. If af is AF_INET, lookup the name for the given IPv4 address - (e.g., query for a PTR record in the in-addr.arpa domain). - - 3. If af is AF_INET6, lookup the name for the given IPv6 address - (e.g., query for a PTR record in the ip6.int domain). - - 4. If the function is returning success, then the single address that - is returned in the hostent structure is a copy of the first argument - to the function with the same address family that was passed as - an argument to this function. - -All four steps listed are performed, in order. Also note that the IPv6 -hex addresses "::" and "::1" MUST NOT be treated as IPv4-compatible - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 21] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -addresses, and if the address is "::", HOST_NOT_FOUND MUST be returned -and a query of the address not performed. - -Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return false -for "::" and "::1". - - - -6.3 Freeing memory for getipnodebyname and getipnodebyaddr - -The hostent structure does not change from its existing definition. -This structure, and the information pointed to by this structure, are -dynamically allocated by getipnodebyname and getipnodebyaddr. The -following function frees this memory: - - #include - - void freehostent(struct hostent *ptr); - - - -6.4 Protocol-Independent Nodename and Service Name Translation - -Nodename-to-address translation is done in a protocol-independent -fashion using the getaddrinfo() function that is taken from the -Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g -(Protocol Independent Interfaces) draft specification [3]. - -The official specification for this function will be the final POSIX -standard, with the following additional requirements: - - - getaddrinfo() (along with the getnameinfo() function described in - the next section) must be thread safe. - - - The AI_NUMERICHOST is new with this document. - - - All fields in socket address structures returned by getaddrinfo() - that are not filled in through an explicit argument (e.g., - sin6_flowinfo and sin_zero) must be set to 0. (This makes it easier - to compare socket address structures.) - - - getaddrinfo() must fill in the length field of a socket address structure - (e.g., sin6_len) on systems that support this field. - -We are providing this independent description of the function because -POSIX standards are not freely available (as are IETF documents). - - #include - #include - - int getaddrinfo(const char *nodename, const char *servname, - const struct addrinfo *hints, - struct addrinfo **res); - -The addrinfo structure is defined as a result of including the -header. - - struct addrinfo { - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 22] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - - int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */ - int ai_family; /* PF_xxx */ - int ai_socktype; /* SOCK_xxx */ - int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ - size_t ai_addrlen; /* length of ai_addr */ - char *ai_canonname; /* canonical name for nodename */ - struct sockaddr *ai_addr; /* binary address */ - struct addrinfo *ai_next; /* next structure in linked list */ - }; - -The return value from the function is 0 upon success or a nonzero error -code. The following names are the nonzero error codes from -getaddrinfo(), and are defined in : - - EAI_ADDRFAMILY address family for nodename not supported - EAI_AGAIN temporary failure in name resolution - EAI_BADFLAGS invalid value for ai_flags - EAI_FAIL non-recoverable failure in name resolution - EAI_FAMILY ai_family not supported - EAI_MEMORY memory allocation failure - EAI_NODATA no address associated with nodename - EAI_NONAME nodename nor servname provided, or not known - EAI_SERVICE servname not supported for ai_socktype - EAI_SOCKTYPE ai_socktype not supported - EAI_SYSTEM system error returned in errno - -The nodename and servname arguments are pointers to null-terminated -strings or NULL. One or both of these two arguments must be a non-NULL -pointer. In the normal client scenario, both the nodename and servname -are specified. In the normal server scenario, only the servname is -specified. A non-NULL nodename string can be either a node name or a -numeric host address string (i.e., a dotted-decimal IPv4 address or an -IPv6 hex address). A non-NULL servname string can be either a service -name or a decimal port number. - -The caller can optionally pass an addrinfo structure, pointed to by the -third argument, to provide hints concerning the type of socket that the -caller supports. In this hints structure all members other than -ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or a NULL -pointer. A value of PF_UNSPEC for ai_family means the caller will -accept any protocol family. A value of 0 for ai_socktype means the -caller will accept any socket type. A value of 0 for ai_protocol means -the caller will accept any protocol. For example, if the caller handles -only TCP and not UDP, then the ai_socktype member of the hints structure -should be set to SOCK_STREAM when getaddrinfo() is called. If the -caller handles only IPv4 and not IPv6, then the ai_family member of the -hints structure should be set to PF_INET when getaddrinfo() is called. -If the third argument to getaddrinfo() is a NULL pointer, this is the -same as if the caller had filled in an addrinfo structure initialized to -zero with ai_family set to PF_UNSPEC. - -Upon successful return a pointer to a linked list of one or more -addrinfo structures is returned through the final argument. The caller -can process each addrinfo structure in this list by following the -ai_next pointer, until a NULL pointer is encountered. In each returned -addrinfo structure the three members ai_family, ai_socktype, and -ai_protocol are the corresponding arguments for a call to the socket() -function. In each addrinfo structure the ai_addr member points to a - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 23] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -filled-in socket address structure whose length is specified by the -ai_addrlen member. - -If the AI_PASSIVE bit is set in the ai_flags member of the hints -structure, then the caller plans to use the returned socket address -structure in a call to bind(). In this case, if the nodename argument -is a NULL pointer, then the IP address portion of the socket address -structure will be set to INADDR_ANY for an IPv4 address or -IN6ADDR_ANY_INIT for an IPv6 address. - -If the AI_PASSIVE bit is not set in the ai_flags member of the hints -structure, then the returned socket address structure will be ready for -a call to connect() (for a connection-oriented protocol) or either -connect(), sendto(), or sendmsg() (for a connectionless protocol). In -this case, if the nodename argument is a NULL pointer, then the IP -address portion of the socket address structure will be set to the -loopback address. - -If the AI_CANONNAME bit is set in the ai_flags member of the hints -structure, then upon successful return the ai_canonname member of the -first addrinfo structure in the linked list will point to a null- -terminated string containing the canonical name of the specified -nodename. - -If the AI_NUMERICHOST bit is set in the ai_flags member of the hints -structure, then a non-NULL nodename string must be a numeric host -address string. Otherwise an error of EAI_NONAME is returned. This -flag prevents any type of name resolution service (e.g., the DNS) from -being called. - -All of the information returned by getaddrinfo() is dynamically -allocated: the addrinfo structures, and the socket address structures -and canonical node name strings pointed to by the addrinfo structures. -To return this information to the system the function freeaddrinfo() is -called: - - #include - #include - - void freeaddrinfo(struct addrinfo *ai); - -The addrinfo structure pointed to by the ai argument is freed, along -with any dynamic storage pointed to by the structure. This operation is -repeated until a NULL ai_next pointer is encountered. - -To aid applications in printing error messages based on the EAI_xxx -codes returned by getaddrinfo(), the following function is defined. - - #include - #include - - char *gai_strerror(int ecode); - -The argument is one of the EAI_xxx values defined earlier and the return -value points to a string describing the error. If the argument is not -one of the EAI_xxx values, the function still returns a pointer to a -string whose contents indicate an unknown error. - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 24] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -6.5 Socket Address Structure to Nodename and Service Name - -The POSIX 1003.1g specification includes no function to perform the -reverse conversion from getaddrinfo(): to look up a nodename and service -name, given the binary address and port. Therefore, we define the -following function: - - #include - #include - - int getnameinfo(const struct sockaddr *sa, socklen_t salen, - char *host, size_t hostlen, - char *serv, size_t servlen, - int flags); - -This function looks up an IP address and port number provided by the -caller in the DNS and system-specific database, and returns text strings -for both in buffers provided by the caller. The function indicates -successful completion by a zero return value; a non-zero return value -indicates failure. - -The first argument, sa, points to either a sockaddr_in structure (for -IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP address -and port number. The salen argument gives the length of the sockaddr_in -or sockaddr_in6 structure. - -The function returns the nodename associated with the IP address in the -buffer pointed to by the host argument. The caller provides the size of -this buffer via the hostlen argument. The service name associated with -the port number is returned in the buffer pointed to by serv, and the -servlen argument gives the length of this buffer. The caller specifies -not to return either string by providing a zero value for the hostlen or -servlen arguments. Otherwise, the caller must provide buffers large -enough to hold the nodename and the service name, including the -terminating null characters. - -Unfortunately most systems do not provide constants that specify the -maximum size of either a fully-qualified domain name or a service name. -Therefore to aid the application in allocating buffers for these two -returned strings the following constants are defined in : - - #define NI_MAXHOST 1025 - #define NI_MAXSERV 32 - -The first value is actually defined as the constant MAXDNAME in recent -versions of BIND's header (older versions of BIND -define this constant to be 256) and the second is a guess based on the -services listed in the current Assigned Numbers RFC. - -The final argument is a flag that changes the default actions of this -function. By default the fully-qualified domain name (FQDN) for the -host is looked up in the DNS and returned. If the flag bit NI_NOFQDN is -set, only the nodename portion of the FQDN is returned for local hosts. - -If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be -located in the DNS, the numeric form of the host's address is returned -instead of its name (e.g., by calling inet_ntop() instead of -getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 25] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -returned if the host's name cannot be located in the DNS. - -If the flag bit NI_NUMERICSERV is set, the numeric form of the service -address is returned (e.g., its port number) instead of its name. The -two NI_NUMERICxxx flags are required to support the "-n" flag that many -commands provide. - -A fifth flag bit, NI_DGRAM, specifies that the service is a datagram -service, and causes getservbyport() to be called with a second argument -of "udp" instead of its default of "tcp". This is required for the few -ports (e.g. 512-514) that have different services for UDP and TCP. - -These NI_xxx flags are defined in along with the AI_xxx flags -already defined for getaddrinfo(). - - - -6.6 Address Conversion Functions - -The two functions inet_addr() and inet_ntoa() convert an IPv4 address -between binary and text form. IPv6 applications need similar functions. -The following two functions convert both IPv6 and IPv4 addresses: - - #include - #include - - int inet_pton(int af, const char *src, void *dst); - - const char *inet_ntop(int af, const void *src, - char *dst, size_t size); - -The inet_pton() function converts an address in its standard text -presentation form into its numeric binary form. The af argument -specifies the family of the address. Currently the AF_INET and AF_INET6 -address families are supported. The src argument points to the string -being passed in. The dst argument points to a buffer into which the -function stores the numeric address. The address is returned in network -byte order. Inet_pton() returns 1 if the conversion succeeds, 0 if the -input is not a valid IPv4 dotted-decimal string or a valid IPv6 address -string, or -1 with errno set to EAFNOSUPPORT if the af argument is -unknown. The calling application must ensure that the buffer referred -to by dst is large enough to hold the numeric address (e.g., 4 bytes for -AF_INET or 16 bytes for AF_INET6). - -If the af argument is AF_INET, the function accepts a string in the -standard IPv4 dotted-decimal form: - - ddd.ddd.ddd.ddd - -where ddd is a one to three digit decimal number between 0 and 255. -Note that many implementations of the existing inet_addr() and -inet_aton() functions accept nonstandard input: octal numbers, -hexadecimal numbers, and fewer than four numbers. inet_pton() does not -accept these formats. - -If the af argument is AF_INET6, then the function accepts a string in -one of the standard IPv6 text forms defined in Section 2.2 of the -addressing architecture specification [2]. - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 26] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -The inet_ntop() function converts a numeric address into a text string -suitable for presentation. The af argument specifies the family of the -address. This can be AF_INET or AF_INET6. The src argument points to a -buffer holding an IPv4 address if the af argument is AF_INET, or an IPv6 -address if the af argument is AF_INET6, the address must be in network -byte order. The dst argument points to a buffer where the function will -store the resulting text string. The size argument specifies the size -of this buffer. The application must specify a non-NULL dst argument. -For IPv6 addresses, the buffer must be at least 46-octets. For IPv4 -addresses, the buffer must be at least 16-octets. In order to allow -applications to easily declare buffers of the proper size to store IPv4 -and IPv6 addresses in string form, the following two constants are -defined in : - - #define INET_ADDRSTRLEN 16 - #define INET6_ADDRSTRLEN 46 - -The inet_ntop() function returns a pointer to the buffer containing the -text string if the conversion succeeds, and NULL otherwise. Upon -failure, errno is set to EAFNOSUPPORT if the af argument is invalid or -ENOSPC if the size of the result buffer is inadequate. - - - -6.7 Address Testing Macros - -The following macros can be used to test for special IPv6 addresses. - - #include - - int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *); - int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *); - int IN6_IS_ADDR_MULTICAST (const struct in6_addr *); - int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *); - int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *); - int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *); - int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *); - - int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *); - int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *); - -The first seven macros return true if the address is of the specified -type, or false otherwise. The last five test the scope of a multicast -address and return true if the address is a multicast address of the -specified scope or false if the address is either not a multicast -address or not of the specified scope. Note that IN6_IS_ADDR_LINKLOCAL -and IN6_IS_ADDR_SITELOCAL return true only for the two local-use IPv6 -unicast addresses. These two macros do not return true for IPv6 -multicast addresses of either link-local scope or site-local scope. - - - - - - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 27] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -7. Summary of New Definitions - -The following list summarizes the constants, structure, and extern -definitions discussed in this memo, sorted by header. - - IF_NAMESIZE - struct if_nameindex{}; - - AI_ADDRCONFIG - AI_DEFAULT - AI_ALL - AI_CANONNAME - AI_NUMERICHOST - AI_PASSIVE - AI_V4MAPPED - EAI_ADDRFAMILY - EAI_AGAIN - EAI_BADFLAGS - EAI_FAIL - EAI_FAMILY - EAI_MEMORY - EAI_NODATA - EAI_NONAME - EAI_SERVICE - EAI_SOCKTYPE - EAI_SYSTEM - NI_DGRAM - NI_MAXHOST - NI_MAXSERV - NI_NAMEREQD - NI_NOFQDN - NI_NUMERICHOST - NI_NUMERICSERV - struct addrinfo{}; - - IN6ADDR_ANY_INIT - IN6ADDR_LOOPBACK_INIT - INET6_ADDRSTRLEN - INET_ADDRSTRLEN - IPPROTO_IPV6 - IPV6_JOIN_GROUP - IPV6_LEAVE_GROUP - IPV6_MULTICAST_HOPS - IPV6_MULTICAST_IF - IPV6_MULTICAST_LOOP - IPV6_UNICAST_HOPS - SIN6_LEN - extern const struct in6_addr in6addr_any; - extern const struct in6_addr in6addr_loopback; - struct in6_addr{}; - struct ipv6_mreq{}; - struct sockaddr_in6{}; - - AF_INET6 - PF_INET6 - struct sockaddr_storage; - -The following list summarizes the function and macro prototypes - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 28] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -discussed in this memo, sorted by header. - - int inet_pton(int, const char *, void *); - const char *inet_ntop(int, const void *, - char *, size_t); - - char *if_indextoname(unsigned int, char *); - unsigned int if_nametoindex(const char *); - void if_freenameindex(struct if_nameindex *); - struct if_nameindex *if_nameindex(void); - - int getaddrinfo(const char *, const char *, - const struct addrinfo *, - struct addrinfo **); - int getnameinfo(const struct sockaddr *, socklen_t, - char *, size_t, char *, size_t, int); - void freeaddrinfo(struct addrinfo *); - char *gai_strerror(int); - struct hostent *getipnodebyname(const char *, int, int, - int *); - struct hostent *getipnodebyaddr(const void *, size_t, int, - int *); - void freehostent(struct hostent *); - - int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); - int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); - int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); - int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); - int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); - int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *); - - - - -8. Security Considerations - -IPv6 provides a number of new security mechanisms, many of which need to -be accessible to applications. Companion memos detailing the extensions -to the socket interfaces to support IPv6 security are being written. - - - -9. Year 2000 Considerations - -There are no issues for this draft concerning the Year 2000 issue -regarding the use of dates. - - - - - - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 29] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -Changes From RFC 2133 - -Changes made in the March 1998 Edition (-01 draft): - - Changed all "hostname" to "nodename" for consistency with other IPv6 - documents. - - Section 3.3: changed comment for sin6_flowinfo to be "traffic class & - flow info" and updated corresponding text description to current - definition of these two fields. - - Section 3.10 ("Portability Additions") is new. - - Section 6: a new paragraph was added reiterating that the existing - gethostbyname() and gethostbyaddr() are not changed. - - Section 6.1: change gethostbyname3() to getnodebyname(). Add - AI_DEFAULT to handle majority of applications. Renamed - AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and IPv4 - addresses too. Defined exactly what getnodebyname() must return if - the name argument is a numeric address string. - - Section 6.2: change gethostbyaddr() to getnodebyaddr(). Reword items - 2 and 3 in the description of how to handle IPv4-mapped and IPv4- - compatible addresses to "lookup a name" for a given address, instead - of specifying what type of DNS query to issue. - - Section 6.3: added two more requirements to getaddrinfo(). - - Section 7: added the following constants to the list for : - AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED. Add union sockaddr_union and - SA_LEN to the lists for . - - Updated references. - -Changes made in the November 1997 Edition (-00 draft): - - The data types have been changed to conform with Draft 6.6 of the - Posix 1003.1g standard. - - Section 3.2: data type of s6_addr changed to "uint8_t". - - Section 3.3: data type of sin6_family changed to "sa_family_t". data - type of sin6_port changed to "in_port_t", data type of sin6_flowinfo - changed to "uint32_t". - - Section 3.4: same as Section 3.3, plus data type of sin6_len changed - to "uint8_t". - - Section 6.2: first argument of gethostbyaddr() changed from "const - char *" to "const void *" and second argument changed from "int" to - "size_t". - - Section 6.4: second argument of getnameinfo() changed from "size_t" - to "socklen_t". - - The wording was changed when new structures were defined, to be more - explicit as to which header must be included to define the structure: - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 30] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - - Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section 3.4 - (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3 - (ipv6_mreq{}), and Section 6.3 (addrinfo{}). - - Section 4: NET_RT_LIST changed to NET_RT_IFLIST. - - Section 5.1: The IPV6_ADDRFORM socket option was removed. - - Section 5.3: Added a note that an option value other than 0 or 1 for - IPV6_MULTICAST_LOOP returns an error. Added a note that - IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP can - also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and - IPV6_DROP_MEMBERSHIP cannot be used with getsockopt(). - - Section 6.1: Removed the description of gethostbyname2() and its - associated RES_USE_INET6 option, replacing it with gethostbyname3(). - - Section 6.2: Added requirement that gethostbyaddr() be thread safe. - Reworded step 4 to avoid using the RES_USE_INET6 option. - - Section 6.3: Added the requirement that getaddrinfo() and - getnameinfo() be thread safe. Added the AI_NUMERICHOST flag. - - Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and - IN6_IS_ADDR_SITELOCAL macros. - -Changes made to the draft -01 specification Sept 98 - - Changed priority to traffic class in the spec. - - Added the need for scope identification in section 2.1. - - Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and 3.4. - - Changed 3.10 to use generic storage structure to support holding IPv6 - addresses and removed the SA_LEN macro. - - Distinguished between invalid input parameters and system failures - for Interface Identification in Section 4.1 and 4.2. - - Added defaults for multicast operations in section 5.2 and changed - the names from ADD to JOIN and DROP to LEAVE to be consistent with - IPv6 multicast terminology. - - Changed getnodebyname to getipnodebyname, getnodebyaddr to - getipnodebyaddr, and added MT safe error code to function parameters - in section 6. - - Moved freehostent to its own sub-section after getipnodebyaddr now - 6.3 (so this bumps all remaining sections in section 6. - - Clarified the use of AI_ALL and AI_V4MAPPED that these are dependent - on the AF parameter and must be used as a conjunction in section 6.1. - - Removed the restriction that literal addresses cannot be used with a - flags argument in section 6.1. - - Added Year 2000 Section to the draft - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 31] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - - Deleted Reference to the following because the attached is deleted from - the ID directory and has expired. But the logic from the aforementioned - draft still applies, so that was kept in Section 6.2 bullets after 3rd - paragraph. - [7] P. Vixie, "Reverse Name Lookups of Encapsulated IPv4 Addresses - in IPv6", Internet-Draft, , - May 1996. - - Deleted the following reference as it is no longer referenced. - And the draft has expired. - [3] D. McDonald, "A Simple IP Security API Extension to BSD Sockets", - Internet-Draft, , - March 1997. - - Deleted the following reference as it is no longer referenced. - [4] C. Metz, "Network Security API for Sockets", - Internet-Draft, , - January 1998. - - Update current references to current status. - - Added alignment notes for in6_addr and sin6_addr. - - Clarified further that AI_V4MAPPED must be used with a dotted IPv4 - literal address for getipnodebyname(), when address family is - AF_INET6. - - Added text to clarify "::" and "::1" when used by getipnodebyaddr(). - - - - -Acknowledgments - -Thanks to the many people who made suggestions and provided feedback to -this document, including: Werner Almesberger, Ran Atkinson, Fred Baker, -Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve Deering, -Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom Herbert, -Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron -Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave Mitton, Thomas Narten, -Josh Osborne, Craig Partridge, Jean-Luc Richier, Erik Scoredos, Keith -Sklower, Matt Thomas, Harvey Thompson, Dean D. Throop, Karen Tracey, -Glenn Trewitt, Paul Vixie, David Waitzman, Carl Williams, and Kazu -Yamamoto, - -The getaddrinfo() and getnameinfo() functions are taken from an earlier -Internet Draft by Keith Sklower. As noted in that draft, William Durst, -Steven Wise, Michael Karels, and Eric Allman provided many useful -discussions on the subject of protocol-independent name-to-address -translation, and reviewed early versions of Keith Sklower's original -proposal. Eric Allman implemented the first prototype of getaddrinfo(). -The observation that specifying the pair of name and service would -suffice for connecting to a service independent of protocol details was -made by Marshall Rose in a proposal to X/Open for a "Uniform Network -Interface". - -Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh Kacker -made many contributions to this document. Ramesh Govindan made a number - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 32] - - -INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 - - -of contributions and co-authored an earlier version of this memo. - - - -References - - [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) - Specification", RFC 2460 Draft Standard. - - [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", - RFC 2373, July 1998 Draft Standard. - - [3] IEEE, "Protocol Independent Interfaces", - IEEE Std 1003.1g, DRAFT 6.6, - March 1997. - - [4] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6", - RFC 2292, February 1998. - - - - -Authors' Addresses - -Robert E. Gilligan -FreeGate Corporation -1208 E. Arques Ave. -Sunnyvale, CA 94086 -Phone: +1 408 617 1004 -Email: gilligan@freegate.net - -Susan Thomson -Bell Communications Research -MRE 2P-343, 445 South Street -Morristown, NJ 07960 -Telephone: +1 201 829 4514 -Email: set@thumper.bellcore.com - -Jim Bound -Compaq Computer Corporation -110 Spitbrook Road ZK3-3/U14 -Nashua, NH 03062-2698 -Phone: +1 603 884 0400 -Email: bound@zk3.dec.com - -W. Richard Stevens -1202 E. Paseo del Zorro -Tucson, AZ 85718-2826 -Phone: +1 520 297 9416 -Email: rstevens@kohala.com - - - - - - - - - - -draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 33] diff --git a/doc/expired/draft-ietf-ipngwg-rfc2292bis-01.txt b/doc/expired/draft-ietf-ipngwg-rfc2292bis-01.txt deleted file mode 100644 index 017ef839fa..0000000000 --- a/doc/expired/draft-ietf-ipngwg-rfc2292bis-01.txt +++ /dev/null @@ -1,4044 +0,0 @@ -INTERNET-DRAFT W. Richard Stevens (Consultant) -Expires: December 24, 1999 Matt Thomas (Consultant) -Obsoletes RFC 2292 Erik Nordmark (Sun) - Oct 22, 1999 - - - Advanced Sockets API for IPv6 - - - - -Abstract - - A separate specification [RFC-2553] contain changes to the sockets - API to support IP version 6. Those changes are for TCP and UDP-based - applications and will support most end-user applications in use - today: Telnet and FTP clients and servers, HTTP clients and servers, - and the like. - - But another class of applications exists that will also be run under - IPv6. We call these "advanced" applications and today this includes - programs such as Ping, Traceroute, routing daemons, multicast routing - daemons, router discovery daemons, and the like. The API feature - typically used by these programs that make them "advanced" is a raw - socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge - of the packet header formats used by these protocols. To provide - portability for applications that use raw sockets under IPv6, some - standardization is needed for the advanced API features. - - There are other features of IPv6 that some applications will need to - access: interface identification (specifying the outgoing interface - and determining the incoming interface) and IPv6 extension headers - that are not addressed in [RFC-2553]: The Routing header (source - routing), Hop-by-Hop options, and Destination options. This document - provides API access to these features too. - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 1] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet Draft expires April 22, 2000. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 2] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - -Table of Contents - - 1. Introduction .................................................... 6 - - 2. Common Structures and Definitions ............................... 7 - 2.1. The ip6_hdr Structure ...................................... 8 - 2.1.1. IPv6 Next Header Values ............................. 8 - 2.1.2. IPv6 Extension Headers .............................. 9 - 2.1.3. IPv6 Options ........................................ 10 - 2.2. The icmp6_hdr Structure .................................... 12 - 2.2.1. ICMPv6 Type and Code Values ......................... 13 - 2.2.2. ICMPv6 Neighbor Discovery Type and Code Values ...... 14 - 2.2.3. Multicast Listener Discovery Type and Code Values ... 16 - 2.2.4. ICMPv6 Router Renumbering Type and Code Values ...... 17 - 2.3. Address Testing Macros ..................................... 19 - 2.4. Protocols File ............................................. 19 - - 3. IPv6 Raw Sockets ................................................ 20 - 3.1. Checksums .................................................. 21 - 3.2. ICMPv6 Type Filtering ...................................... 21 - - 4. Access to IPv6 and Extension Headers ............................ 24 - 4.1. TCP Implications ........................................... 26 - 4.2. UDP and Raw Socket Implications ............................ 27 - - 5. Extensions to Socket Ancillary Data ............................. 27 - - 6. Packet Information .............................................. 28 - 6.1. Specifying/Receiving the Interface ......................... 29 - 6.2. Specifying/Receiving Source/Destination Address ............ 29 - 6.3. Specifying/Receiving the Hop Limit ......................... 30 - 6.4. Specifying the Next Hop Address ............................ 31 - 6.5. Additional Errors with sendmsg() and setsockopt() .......... 31 - - 7. Routing Header Option ........................................... 32 - 7.1. inet6_rth_space ............................................ 33 - 7.2. inet6_rth_init ............................................. 33 - 7.3. inet6_rth_add .............................................. 34 - 7.4. inet6_rth_reverse .......................................... 34 - 7.5. inet6_rth_segments ......................................... 35 - 7.6. inet6_rth_getaddr .......................................... 35 - - 8. Hop-By-Hop Options .............................................. 35 - 8.1. Receiving Hop-by-Hop Options ............................... 36 - 8.2. Sending Hop-by-Hop Options ................................. 37 - - 9. Destination Options ............................................. 37 - 9.1. Receiving Destination Options .............................. 37 - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 3] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - 9.2. Sending Destination Options ................................ 38 - - 10. Hop-by-Hop and Destination Options Processing ................... 39 - 10.1. inet6_opt_init ............................................ 39 - 10.2. inet6_opt_append .......................................... 39 - 10.3. inet6_opt_finish .......................................... 40 - 10.4. inet6_opt_set_val ......................................... 41 - 10.5. inet6_opt_next ............................................ 41 - 10.6. inet6_opt_find ............................................ 41 - 10.7. inet6_opt_get_val ......................................... 42 - - 11. Additional Advanced API Functions ............................... 42 - 11.1. Sending with the Minimum MTU .............................. 42 - 11.2. Path MTU Discovery and UDP ................................ 43 - 11.3. Neighbor Reachability and UDP ............................. 43 - - 12. Ordering of Ancillary Data and IPv6 Extension Headers ........... 44 - - 13. IPv6-Specific Options with IPv4-Mapped IPv6 Addresses ........... 44 - - 14. Extended interfaces for rresvport, rcmd and rexec ............... 45 - 14.1. rresvport_af .............................................. 45 - 14.2. rcmd_af ................................................... 45 - 14.3. rexec_af .................................................. 46 - - 15. Summary of New Definitions ...................................... 46 - - 16. Security Considerations ......................................... 49 - - 17. Change History .................................................. 49 - - 18. TODO and Open Issues ............................................ 52 - - 19. References ...................................................... 52 - - 20. Acknowledgments ................................................. 53 - - 21. Authors' Addresses .............................................. 53 - - 22. Appendix A: Ancillary Data Overview ............................. 54 - 22.1. The msghdr Structure ...................................... 54 - 22.2. The cmsghdr Structure ..................................... 55 - 22.3. Ancillary Data Object Macros .............................. 57 - 22.3.1. CMSG_FIRSTHDR ...................................... 57 - 22.3.2. CMSG_NXTHDR ........................................ 58 - 22.3.3. CMSG_DATA .......................................... 59 - 22.3.4. CMSG_SPACE ......................................... 60 - 22.3.5. CMSG_LEN ........................................... 60 - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 4] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - 23. Appendix B: Examples using the inet6_rth_XXX() functions ........ 61 - 23.1. Sending a Routing Header .................................. 61 - 23.2. Receiving Routing Headers ................................. 66 - - 24. Appendix C: Examples using the inet6_opt_XXX() functions ........ 68 - 24.1. Building options .......................................... 68 - 24.2. Parsing received options .................................. 70 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 5] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - -1. Introduction - - A separate specification [RFC-2553] contain changes to the sockets - API to support IP version 6. Those changes are for TCP and UDP-based - applications. This document defines some the "advanced" features of - the sockets API that are required for applications to take advantage - of additional features of IPv6. - - Today, the portability of applications using IPv4 raw sockets is - quite high, but this is mainly because most IPv4 implementations - started from a common base (the Berkeley source code) or at least - started with the Berkeley header files. This allows programs such as - Ping and Traceroute, for example, to compile with minimal effort on - many hosts that support the sockets API. With IPv6, however, there - is no common source code base that implementors are starting from, - and the possibility for divergence at this level between different - implementations is high. To avoid a complete lack of portability - amongst applications that use raw IPv6 sockets, some standardization - is necessary. - - There are also features from the basic IPv6 specification that are - not addressed in [RFC-2553]: sending and receiving Routing headers, - Hop-by-Hop options, and Destination options, specifying the outgoing - interface, and being told of the receiving interface. - - This document can be divided into the following main sections. - - 1. Definitions of the basic constants and structures required for - applications to use raw IPv6 sockets. This includes structure - definitions for the IPv6 and ICMPv6 headers and all associated - constants (e.g., values for the Next Header field). - - 2. Some basic semantic definitions for IPv6 raw sockets. For - example, a raw ICMPv4 socket requires the application to - calculate and store the ICMPv4 header checksum. But with IPv6 - this would require the application to choose the source IPv6 - address because the source address is part of the pseudo header - that ICMPv6 now uses for its checksum computation. It should be - defined that with a raw ICMPv6 socket the kernel always - calculates and stores the ICMPv6 header checksum. - - 3. Packet information: how applications can obtain the received - interface, destination address, and received hop limit, along - with specifying these values on a per-packet basis. There are a - class of applications that need this capability and the technique - should be portable. - - 4. Access to the optional Routing header, Hop-by-Hop, and - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 6] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - Destination extension headers. - - 5. Additional features required for improved IPv6 application - portability. - - The packet information along with access to the extension headers - (Routing header, Hop-by-Hop options, and Destination options) are - specified using the "ancillary data" fields that were added to the - 4.3BSD Reno sockets API in 1990. The reason is that these ancillary - data fields are part of the Posix.1g standard and should therefore be - adopted by most vendors. - - This document does not address application access to either the - authentication header or the encapsulating security payload header. - - All examples in this document omit error checking in favor of brevity - and clarity. - - We note that many of the functions and socket options defined in this - document may have error returns that are not defined in this - document. Many of these possible error returns will be recognized - only as implementations proceed. - - Datatypes in this document follow the Posix.1g format: intN_t means a - signed integer of exactly N bits (e.g., int16_t) and uintN_t means an - unsigned integer of exactly N bits (e.g., uint32_t). - - Note that we use the (unofficial) terminology ICMPv4, IGMPv4, and - ARPv4 to avoid any confusion with the newer ICMPv6 protocol. - - -2. Common Structures and Definitions - - Many advanced applications examine fields in the IPv6 header and set - and examine fields in the various ICMPv6 headers. Common structure - definitions for these protocol headers are required, along with - common constant definitions for the structure members. - - This API assumes that the fields in the protocol headers are left in - the network byte order, which is big-endian for the Internet - protocols. If not, then either these constants or the fields being - tested must be converted at run-time, using something like htons() or - htonl(). - - Two new header files are defined: and - . - - When an include file is specified, that include file is allowed to - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 7] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - include other files that do the actual declaration or definition. - - -2.1. The ip6_hdr Structure - - The following structure is defined as a result of including - . Note that this is a new header. - - struct ip6_hdr { - union { - struct ip6_hdrctl { - uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 24 bits flow-ID */ - uint16_t ip6_un1_plen; /* payload length */ - uint8_t ip6_un1_nxt; /* next header */ - uint8_t ip6_un1_hlim; /* hop limit */ - } ip6_un1; - uint8_t ip6_un2_vfc; /* 4 bits version, top 4 bits tclass */ - } ip6_ctlun; - struct in6_addr ip6_src; /* source address */ - struct in6_addr ip6_dst; /* destination address */ - }; - - #define ip6_vfc ip6_ctlun.ip6_un2_vfc - #define ip6_flow ip6_ctlun.ip6_un1.ip6_un1_flow - #define ip6_plen ip6_ctlun.ip6_un1.ip6_un1_plen - #define ip6_nxt ip6_ctlun.ip6_un1.ip6_un1_nxt - #define ip6_hlim ip6_ctlun.ip6_un1.ip6_un1_hlim - #define ip6_hops ip6_ctlun.ip6_un1.ip6_un1_hlim - - - -2.1.1. IPv6 Next Header Values - - IPv6 defines many new values for the Next Header field. The - following constants are defined as a result of including - . - - #define IPPROTO_HOPOPTS 0 /* IPv6 Hop-by-Hop options */ - #define IPPROTO_IPV6 41 /* IPv6 header */ - #define IPPROTO_ROUTING 43 /* IPv6 Routing header */ - #define IPPROTO_FRAGMENT 44 /* IPv6 fragmentation header */ - #define IPPROTO_ESP 50 /* encapsulating security payload */ - #define IPPROTO_AH 51 /* authentication header */ - #define IPPROTO_ICMPV6 58 /* ICMPv6 */ - #define IPPROTO_NONE 59 /* IPv6 no next header */ - #define IPPROTO_DSTOPTS 60 /* IPv6 Destination options */ - - Berkeley-derived IPv4 implementations also define IPPROTO_IP to be 0. - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 8] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - This should not be a problem since IPPROTO_IP is used only with IPv4 - sockets and IPPROTO_HOPOPTS only with IPv6 sockets. - - -2.1.2. IPv6 Extension Headers - - Six extension headers are defined for IPv6. We define structures for - all except the Authentication header and Encapsulating Security - Payload header, both of which are beyond the scope of this document. - The following structures are defined as a result of including - . - - /* Hop-by-Hop options header */ - struct ip6_hbh { - uint8_t ip6h_nxt; /* next header */ - uint8_t ip6h_len; /* length in units of 8 octets */ - /* followed by options */ - }; - - /* Destination options header */ - struct ip6_dest { - uint8_t ip6d_nxt; /* next header */ - uint8_t ip6d_len; /* length in units of 8 octets */ - /* followed by options */ - }; - - /* Routing header */ - struct ip6_rthdr { - uint8_t ip6r_nxt; /* next header */ - uint8_t ip6r_len; /* length in units of 8 octets */ - uint8_t ip6r_type; /* routing type */ - uint8_t ip6r_segleft; /* segments left */ - /* followed by routing type specific data */ - }; - - /* Type 0 Routing header */ - struct ip6_rthdr0 { - uint8_t ip6r0_nxt; /* next header */ - uint8_t ip6r0_len; /* length in units of 8 octets */ - uint8_t ip6r0_type; /* always zero */ - uint8_t ip6r0_segleft; /* segments left */ - uint32_t ip6r0_reserved; /* reserved field */ - /* followed by up to 127 struct in6_addr */ - }; - - /* Fragment header */ - struct ip6_frag { - uint8_t ip6f_nxt; /* next header */ - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 9] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - uint8_t ip6f_reserved; /* reserved field */ - uint16_t ip6f_offlg; /* offset, reserved, and flag */ - uint32_t ip6f_ident; /* identification */ - }; - - #if BYTE_ORDER == BIG_ENDIAN - #define IP6F_OFF_MASK 0xfff8 /* mask out offset from _offlg */ - #define IP6F_RESERVED_MASK 0x0006 /* reserved bits in ip6f_offlg */ - #define IP6F_MORE_FRAG 0x0001 /* more-fragments flag */ - #else /* BYTE_ORDER == LITTLE_ENDIAN */ - #define IP6F_OFF_MASK 0xf8ff /* mask out offset from _offlg */ - #define IP6F_RESERVED_MASK 0x0600 /* reserved bits in ip6f_offlg */ - #define IP6F_MORE_FRAG 0x0100 /* more-fragments flag */ - #endif - - - -2.1.3. IPv6 Options - - Eleven options are defined for IPv6 at the time of writing this - document. We define structures for all except the unspecified EID - option. The following structures are defined as a result of - including . - - /* IPv6 options */ - structip6_opt { - uint8_tip6o_type; - uint8_tip6o_len; - }; - - /* - * The high-order 3 bits of the option type define the behavior - * when processing an unknown option and whether or not the option - * content changes in flight. - */ - #defineIP6OPT_TYPE(o)((o) & 0xc0) - #defineIP6OPT_TYPE_SKIP0x00 - #defineIP6OPT_TYPE_DISCARD0x40 - #defineIP6OPT_TYPE_FORCEICMP0x80 - #defineIP6OPT_TYPE_ICMP0xc0 - #defineIP6OPT_MUTABLE0x20 - - #defineIP6OPT_PAD10x00/* 00 0 00000 */ - #defineIP6OPT_PADN0x01/* 00 0 00001 */ - #defineIP6OPT_JUMBO0xc2/* 11 0 00010 = 194 */ - #defineIP6OPT_NSAP_ADDR0xc3/* 11 0 00011 */ - #defineIP6OPT_TUNNEL_LIMIT0x04/* 00 0 00100 */ - #defineIP6OPT_ROUTER_ALERT0x05/* 00 0 00101 */ - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 10] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - #defineIP6OPT_BINDING_UPDATE0xc6/* 11 0 00110 */ - #defineIP6OPT_BINDING_ACK0x07/* 00 0 00111 */ - #defineIP6OPT_BINDING_REQ0x08/* 00 0 01000 */ - #defineIP6OPT_HOME_ADDRESS0xc9/* 11 0 01001 */ - #defineIP6OPT_EID0x8a/* 10 0 01010 */ - - /* Jumbo Payload Option */ - structip6_opt_jumbo { - uint8_tip6oj_type; - uint8_tip6oj_len; - uint8_t ip6oj_jumbo_len[4]; - }; - #defineIP6OPT_JUMBO_LEN6 - - /* NSAP Address Option */ - structip6_opt_nsap { - uint8_tip6on_type; - uint8_tip6on_len; - uint8_t ip6on_src_nsap_len; - uint8_t ip6on_dst_nsap_len; - /* followed by source NSAP */ - /* followed by destination NSAP */ - }; - - /* Tunnel Limit Option */ - structip6_opt_tunnel { - uint8_tip6ot_type; - uint8_tip6ot_len; - uint8_t ip6ot_encap_limit; - }; - - /* Router Alert Option */ - structip6_opt_router { - uint8_tip6or_type; - uint8_tip6or_len; - uint8_t ip6or_value[2]; - }; - - /* Router alert values (in network byte order) */ - #ifdef _BIG_ENDIAN - #defineIP6_ALERT_MLD0x0000 - #defineIP6_ALERT_RSVP0x0001 - #defineIP6_ALERT_AN0x0002 - #else - #defineIP6_ALERT_MLD0x0000 - #defineIP6_ALERT_RSVP0x0100 - #defineIP6_ALERT_AN0x0200 - #endif - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 11] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - /* Binding Update Option */ - structip6_opt_binding_update { - uint8_tip6ou_type; - uint8_tip6ou_len; - uint8_t ip6ou_flags; - uint8_t ip6ou_prefixlen; - uint8_t ip6ou_seqno[2]; - uint8_t ip6ou_lifetime[4]; - uint8_t ip6ou_coa[16];/* Optional based on flags */ - /* followed by sub-options */ - }; - - /* Binding Update Flags */ - #defineIP6_BUF_ACK0x80/* Request a binding ack */ - #defineIP6_BUF_HOME0x40/* Home Registration */ - #defineIP6_BUF_COA0x20/* Care-of-address present in option */ - #defineIP6_BUF_ROUTER0x10/* Sending mobile node is a router */ - - /* Binding Ack Option */ - structip6_opt_binding_ack { - uint8_tip6oa_type; - uint8_tip6oa_len; - uint8_t ip6oa_status; - uint8_t ip6oa_seqno[2]; - uint8_t ip6oa_lifetime[4]; - uint8_t ip6oa_refresh[4]; - /* followed by sub-options */ - }; - - /* Binding Request Option */ - structip6_opt_binding_request { - uint8_tip6or_type; - uint8_tip6or_len; - /* followed by sub-options */ - }; - - /* Home Address Option */ - structip6_opt_home_address { - uint8_tip6oh_type; - uint8_tip6oh_len; - uint8_t ip6oh_addr[16];/* Home Address */ - /* followed by sub-options */ - }; - - - -2.2. The icmp6_hdr Structure - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 12] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - The ICMPv6 header is needed by numerous IPv6 applications including - Ping, Traceroute, router discovery daemons, and neighbor discovery - daemons. The following structure is defined as a result of including - . Note that this is a new header. - - struct icmp6_hdr { - uint8_t icmp6_type; /* type field */ - uint8_t icmp6_code; /* code field */ - uint16_t icmp6_cksum; /* checksum field */ - union { - uint32_t icmp6_un_data32[1]; /* type-specific field */ - uint16_t icmp6_un_data16[2]; /* type-specific field */ - uint8_t icmp6_un_data8[4]; /* type-specific field */ - } icmp6_dataun; - }; - - #define icmp6_data32 icmp6_dataun.icmp6_un_data32 - #define icmp6_data16 icmp6_dataun.icmp6_un_data16 - #define icmp6_data8 icmp6_dataun.icmp6_un_data8 - #define icmp6_pptr icmp6_data32[0] /* parameter prob */ - #define icmp6_mtu icmp6_data32[0] /* packet too big */ - #define icmp6_id icmp6_data16[0] /* echo request/reply */ - #define icmp6_seq icmp6_data16[1] /* echo request/reply */ - #define icmp6_maxdelay icmp6_data16[0] /* mcast group membership */ - - - -2.2.1. ICMPv6 Type and Code Values - - In addition to a common structure for the ICMPv6 header, common - definitions are required for the ICMPv6 type and code fields. The - following constants are also defined as a result of including - . - - #define ICMP6_DST_UNREACH 1 - #define ICMP6_PACKET_TOO_BIG 2 - #define ICMP6_TIME_EXCEEDED 3 - #define ICMP6_PARAM_PROB 4 - - #define ICMP6_INFOMSG_MASK 0x80 /* all informational messages */ - - #define ICMP6_ECHO_REQUEST 128 - #define ICMP6_ECHO_REPLY 129 - #define ICMP6_MEMBERSHIP_QUERY 130 - #define ICMP6_MEMBERSHIP_REPORT 131 - #define ICMP6_MEMBERSHIP_REDUCTION 132 - - #define ICMP6_DST_UNREACH_NOROUTE 0 /* no route to destination */ - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 13] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - #define ICMP6_DST_UNREACH_ADMIN 1 /* communication with */ - /* destination */ - /* admin. prohibited */ - #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source address */ - #define ICMP6_DST_UNREACH_ADDR 3 /* address unreachable */ - #define ICMP6_DST_UNREACH_NOPORT 4 /* bad port */ - - #define ICMP6_TIME_EXCEED_TRANSIT 0 /* Hop Limit == 0 in transit */ - #define ICMP6_TIME_EXCEED_REASSEMBLY 1 /* Reassembly time out */ - - #define ICMP6_PARAMPROB_HEADER 0 /* erroneous header field */ - #define ICMP6_PARAMPROB_NEXTHEADER 1 /* unrecognized Next Header */ - #define ICMP6_PARAMPROB_OPTION 2 /* unrecognized IPv6 option */ - - The five ICMP message types defined by IPv6 neighbor discovery - (133-137) are defined in the next section. - - -2.2.2. ICMPv6 Neighbor Discovery Type and Code Values - - The following structures and definitions are defined as a result of - including . - - #define ND_ROUTER_SOLICIT 133 - #define ND_ROUTER_ADVERT 134 - #define ND_NEIGHBOR_SOLICIT 135 - #define ND_NEIGHBOR_ADVERT 136 - #define ND_REDIRECT 137 - - struct nd_router_solicit { /* router solicitation */ - struct icmp6_hdr nd_rs_hdr; - /* could be followed by options */ - }; - - #define nd_rs_type nd_rs_hdr.icmp6_type - #define nd_rs_code nd_rs_hdr.icmp6_code - #define nd_rs_cksum nd_rs_hdr.icmp6_cksum - #define nd_rs_reserved nd_rs_hdr.icmp6_data32[0] - - struct nd_router_advert { /* router advertisement */ - struct icmp6_hdr nd_ra_hdr; - uint32_t nd_ra_reachable; /* reachable time */ - uint32_t nd_ra_retransmit; /* retransmit timer */ - /* could be followed by options */ - }; - - #define nd_ra_type nd_ra_hdr.icmp6_type - #define nd_ra_code nd_ra_hdr.icmp6_code - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 14] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - #define nd_ra_cksum nd_ra_hdr.icmp6_cksum - #define nd_ra_curhoplimit nd_ra_hdr.icmp6_data8[0] - #define nd_ra_flags_reserved nd_ra_hdr.icmp6_data8[1] - #define ND_RA_FLAG_MANAGED 0x80 - #define ND_RA_FLAG_OTHER 0x40 - #define nd_ra_router_lifetime nd_ra_hdr.icmp6_data16[1] - - struct nd_neighbor_solicit { /* neighbor solicitation */ - struct icmp6_hdr nd_ns_hdr; - struct in6_addr nd_ns_target; /* target address */ - /* could be followed by options */ - }; - - #define nd_ns_type nd_ns_hdr.icmp6_type - #define nd_ns_code nd_ns_hdr.icmp6_code - #define nd_ns_cksum nd_ns_hdr.icmp6_cksum - #define nd_ns_reserved nd_ns_hdr.icmp6_data32[0] - - struct nd_neighbor_advert { /* neighbor advertisement */ - struct icmp6_hdr nd_na_hdr; - struct in6_addr nd_na_target; /* target address */ - /* could be followed by options */ - }; - - #define nd_na_type nd_na_hdr.icmp6_type - #define nd_na_code nd_na_hdr.icmp6_code - #define nd_na_cksum nd_na_hdr.icmp6_cksum - #define nd_na_flags_reserved nd_na_hdr.icmp6_data32[0] - #if BYTE_ORDER == BIG_ENDIAN - #define ND_NA_FLAG_ROUTER 0x80000000 - #define ND_NA_FLAG_SOLICITED 0x40000000 - #define ND_NA_FLAG_OVERRIDE 0x20000000 - #else /* BYTE_ORDER == LITTLE_ENDIAN */ - #define ND_NA_FLAG_ROUTER 0x00000080 - #define ND_NA_FLAG_SOLICITED 0x00000040 - #define ND_NA_FLAG_OVERRIDE 0x00000020 - #endif - - struct nd_redirect { /* redirect */ - struct icmp6_hdr nd_rd_hdr; - struct in6_addr nd_rd_target; /* target address */ - struct in6_addr nd_rd_dst; /* destination address */ - /* could be followed by options */ - }; - - #define nd_rd_type nd_rd_hdr.icmp6_type - #define nd_rd_code nd_rd_hdr.icmp6_code - #define nd_rd_cksum nd_rd_hdr.icmp6_cksum - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 15] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - #define nd_rd_reserved nd_rd_hdr.icmp6_data32[0] - - struct nd_opt_hdr { /* Neighbor discovery option header */ - uint8_t nd_opt_type; - uint8_t nd_opt_len; /* in units of 8 octets */ - /* followed by option specific data */ - }; - - #define ND_OPT_SOURCE_LINKADDR 1 - #define ND_OPT_TARGET_LINKADDR 2 - #define ND_OPT_PREFIX_INFORMATION 3 - #define ND_OPT_REDIRECTED_HEADER 4 - #define ND_OPT_MTU 5 - - struct nd_opt_prefix_info { /* prefix information */ - uint8_t nd_opt_pi_type; - uint8_t nd_opt_pi_len; - uint8_t nd_opt_pi_prefix_len; - uint8_t nd_opt_pi_flags_reserved; - uint32_t nd_opt_pi_valid_time; - uint32_t nd_opt_pi_preferred_time; - uint32_t nd_opt_pi_reserved2; - struct in6_addr nd_opt_pi_prefix; - }; - - #define ND_OPT_PI_FLAG_ONLINK 0x80 - #define ND_OPT_PI_FLAG_AUTO 0x40 - - struct nd_opt_rd_hdr { /* redirected header */ - uint8_t nd_opt_rh_type; - uint8_t nd_opt_rh_len; - uint16_t nd_opt_rh_reserved1; - uint32_t nd_opt_rh_reserved2; - /* followed by IP header and data */ - }; - - struct nd_opt_mtu { /* MTU option */ - uint8_t nd_opt_mtu_type; - uint8_t nd_opt_mtu_len; - uint16_t nd_opt_mtu_reserved; - uint32_t nd_opt_mtu_mtu; - }; - - We note that the nd_na_flags_reserved flags have the same byte - ordering problems as we discussed with ip6f_offlg. - - -2.2.3. Multicast Listener Discovery Type and Code Values - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 16] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - The following structures and definitions are defined as a result of - including . - - struct mld_hdr { - struct icmp6_hdr mld_hdr; - struct in6_addr mld_addr; /* multicast address */ - }; - #define mld_type mld_hdr.icmp6_type - #define mld_code mld_hdr.icmp6_code - #define mld_cksum mld_hdr.icmp6_cksum - #define mld_maxdelay mld_hdr.icmp6_data16[0] - #define mld_reserved mld_hdr.icmp6_data16[1] - - - -2.2.4. ICMPv6 Router Renumbering Type and Code Values - - The following structures and definitions are defined as a result of - including . - - struct icmp6_router_renum { /* router renumbering header */ - struct icmp6_hdr rr_hdr; - u_int8_t rr_segnum; - u_int8_t rr_flags; - u_int16_t rr_maxdelay; - u_int32_t rr_reserved; - }; - #define rr_type rr_hdr.icmp6_type - #define rr_code rr_hdr.icmp6_code - #define rr_cksum rr_hdr.icmp6_cksum - #define rr_seqnum rr_hdr.icmp6_data32[0] - - /* Router renumbering flags */ - #define ICMP6_RR_FLAGS_TEST 0x80 - #define ICMP6_RR_FLAGS_REQRESULT 0x40 - #define ICMP6_RR_FLAGS_FORCEAPPLY 0x20 - #define ICMP6_RR_FLAGS_SPECSITE 0x10 - #define ICMP6_RR_FLAGS_PREVDONE 0x08 - - - struct rr_pco_match { /* match prefix part */ - u_int8_t rpm_code; - u_int8_t rpm_len; - u_int8_t rpm_ordinal; - u_int8_t rpm_matchlen; - u_int8_t rpm_minlen; - u_int8_t rpm_maxlen; - u_int16_t rpm_reserved; - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 17] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - struct in6_addr rpm_prefix; - }; - - /* PCI code values */ - #define RPM_PCO_ADD 1 - #define RPM_PCO_CHANGE 2 - #define RPM_PCO_SETGLOBAL 3 - - struct rr_pco_use { /* use prefix part */ - u_int8_t rpu_uselen; - u_int8_t rpu_keeplen; - u_int8_t rpu_ramask; - u_int8_t rpu_raflags; - u_int32_t rpu_vltime; - u_int32_t rpu_pltime; - u_int32_t rpu_flags; - struct in6_addr rpu_prefix; - }; - #define ICMP6_RR_PCOUSE_RAFLAGS_ONLINK 0x20 - #define ICMP6_RR_PCOUSE_RAFLAGS_AUTO 0x10 - - #if BYTE_ORDER == BIG_ENDIAN - #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80000000 - #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40000000 - #elif BYTE_ORDER == LITTLE_ENDIAN - #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80 - #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40 - #endif - - struct rr_result { /* router renumbering result message */ - u_int16_t rrr_flags; - u_int8_t rrr_ordinal; - u_int8_t rrr_matchedlen; - u_int32_t rrr_ifid; - struct in6_addr rrr_prefix; - }; - - #if BYTE_ORDER == BIG_ENDIAN - #define ICMP6_RR_RESULT_FLAGS_OOB 0x0002 - #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0001 - #elif BYTE_ORDER == LITTLE_ENDIAN - #define ICMP6_RR_RESULT_FLAGS_OOB 0x0200 - #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0100 - #endif - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 18] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - -2.3. Address Testing Macros - - The basic API ([RFC-2553]) defines some macros for testing an IPv6 - address for certain properties. This API extends those definitions - with additional address testing macros, defined as a result of - including . - - int IN6_ARE_ADDR_EQUAL(const struct in6_addr *, - const struct in6_addr *); - - This macro returns non-zero if the addresses are equal; otherwise it - returns zero. - - -2.4. Protocols File - - Many hosts provide the file /etc/protocols that contains the names of - the various IP protocols and their protocol number (e.g., the value - of the protocol field in the IPv4 header for that protocol, such as 1 - for ICMP). Some programs then call the function getprotobyname() to - obtain the protocol value that is then specified as the third - argument to the socket() function. For example, the Ping program - contains code of the form - - struct protoent *proto; - - proto = getprotobyname("icmp"); - - s = socket(PF_INET, SOCK_RAW, proto->p_proto); - - Common names are required for the new IPv6 protocols in this file, to - provide portability of applications that call the getprotoXXX() - functions. - - We define the following protocol names with the values shown. These - are taken from ftp://ftp.isi.edu/in-notes/iana/assignments/protocol- - numbers. - - hopopt 0 # hop-by-hop options for ipv6 - ipv6 41 # ipv6 - ipv6-route 43 # routing header for ipv6 - ipv6-frag 44 # fragment header for ipv6 - esp 50 # encapsulating security payload for ipv6 - ah 51 # authentication header for ipv6 - ipv6-icmp 58 # icmp for ipv6 - ipv6-nonxt 59 # no next header for ipv6 - ipv6-opts 60 # destination options for ipv6 - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 19] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - -3. IPv6 Raw Sockets - - Raw sockets bypass the transport layer (TCP or UDP). With IPv4, raw - sockets are used to access ICMPv4, IGMPv4, and to read and write IPv4 - datagrams containing a protocol field that the kernel does not - process. An example of the latter is a routing daemon for OSPF, - since it uses IPv4 protocol field 89. With IPv6 raw sockets will be - used for ICMPv6 and to read and write IPv6 datagrams containing a - Next Header field that the kernel does not process. Examples of the - latter are a routing daemon for OSPF for IPv6 and RSVP (protocol - field 46). - - All data sent via raw sockets MUST be in network byte order and all - data received via raw sockets will be in network byte order. This - differs from the IPv4 raw sockets, which did not specify a byte - ordering and used the host's byte order for certain IP header fields. - - Another difference from IPv4 raw sockets is that complete packets - (that is, IPv6 packets with extension headers) cannot be sent or - received using the IPv6 raw sockets API. Instead, ancillary data - objects are used to transfer the extension headers and hoplimit - information, as described in Section 6. Should an application need - access to the complete IPv6 packet, some other technique, such as the - datalink interfaces BPF or DLPI, must be used. - - All fields in the IPv6 header that an application might want to - change (i.e., everything other than the version number) can be - modified using ancillary data and/or socket options by the - application for output. All fields in a received IPv6 header (other - than the version number and Next Header fields) and all extension - headers are also made available to the application as ancillary data - on input. Hence there is no need for a socket option similar to the - IPv4 IP_HDRINCL socket option and on receipt the application will - only receive the payload i.e. the data after the IPv6 header and all - the extension headers. - - When writing to a raw socket the kernel will automatically fragment - the packet if its size exceeds the path MTU, inserting the required - fragmentation headers. On input the kernel reassembles received - fragments, so the reader of a raw socket never sees any fragment - headers. - - When we say "an ICMPv6 raw socket" we mean a socket created by - calling the socket function with the three arguments PF_INET6, - SOCK_RAW, and IPPROTO_ICMPV6. - - Most IPv4 implementations give special treatment to a raw socket - created with a third argument to socket() of IPPROTO_RAW, whose value - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 20] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - is normally 255, to have it mean that the application will send down - complete packets including the IPv4 header. (Note: This feature was - added to IPv4 in 1988 by Van Jacobson to support traceroute, allowing - a complete IP header to be passed by the application, before the - IP_HDRINCL socket option was added.) We note that this value has no - special meaning to an IPv6 raw socket (and the IANA currently - reserves the value of 255 when used as a next-header field). - - -3.1. Checksums - - The kernel will calculate and insert the ICMPv6 checksum for ICMPv6 - raw sockets, since this checksum is mandatory. - - For other raw IPv6 sockets (that is, for raw IPv6 sockets created - with a third argument other than IPPROTO_ICMPV6), the application - must set the new IPV6_CHECKSUM socket option to have the kernel (1) - compute and store a checksum for output, and (2) verify the received - checksum on input, discarding the packet if the checksum is in error. - This option prevents applications from having to perform source - address selection on the packets they send. The checksum will - incorporate the IPv6 pseudo-header, defined in Section 8.1 of - [RFC-2460]. This new socket option also specifies an integer offset - into the user data of where the checksum is located. - - int offset = 2; - setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, sizeof(offset)); - - By default, this socket option is disabled. Setting the offset to -1 - also disables the option. By disabled we mean (1) the kernel will - not calculate and store a checksum for outgoing packets, and (2) the - kernel will not verify a checksum for received packets. - - An attempt to set IPV6_CHECKSUM for an ICMPv6 socket will fail. - - (Note: Since the checksum is always calculated by the kernel for an - ICMPv6 socket, applications are not able to generate ICMPv6 packets - with incorrect checksums (presumably for testing purposes) using this - API.) - - -3.2. ICMPv6 Type Filtering - - ICMPv4 raw sockets receive most ICMPv4 messages received by the - kernel. (We say "most" and not "all" because Berkeley-derived - kernels never pass echo requests, timestamp requests, or address mask - requests to a raw socket. Instead these three messages are processed - entirely by the kernel.) But ICMPv6 is a superset of ICMPv4, also - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 21] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - including the functionality of IGMPv4 and ARPv4. This means that an - ICMPv6 raw socket can potentially receive many more messages than - would be received with an ICMPv4 raw socket: ICMP messages similar to - ICMPv4, along with neighbor solicitations, neighbor advertisements, - and the three multicast listener discovery messages. - - Most applications using an ICMPv6 raw socket care about only a small - subset of the ICMPv6 message types. To transfer extraneous ICMPv6 - messages from the kernel to user can incur a significant overhead. - Therefore this API includes a method of filtering ICMPv6 messages by - the ICMPv6 type field. - - Each ICMPv6 raw socket has an associated filter whose datatype is - defined as - - struct icmp6_filter; - - This structure, along with the macros and constants defined later in - this section, are defined as a result of including the - . - - The current filter is fetched and stored using getsockopt() and - setsockopt() with a level of IPPROTO_ICMPV6 and an option name of - ICMP6_FILTER. - - Six macros operate on an icmp6_filter structure: - - void ICMP6_FILTER_SETPASSALL (struct icmp6_filter *); - void ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *); - - void ICMP6_FILTER_SETPASS ( int, struct icmp6_filter *); - void ICMP6_FILTER_SETBLOCK( int, struct icmp6_filter *); - - int ICMP6_FILTER_WILLPASS (int, - const struct icmp6_filter *); - int ICMP6_FILTER_WILLBLOCK(int, - const struct icmp6_filter *); - - The first argument to the last four macros (an integer) is an ICMPv6 - message type, between 0 and 255. The pointer argument to all six - macros is a pointer to a filter that is modified by the first four - macros examined by the last two macros. - - The first two macros, SETPASSALL and SETBLOCKALL, let us specify that - all ICMPv6 messages are passed to the application or that all ICMPv6 - messages are blocked from being passed to the application. - - The next two macros, SETPASS and SETBLOCK, let us specify that - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 22] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - messages of a given ICMPv6 type should be passed to the application - or not passed to the application (blocked). - - The final two macros, WILLPASS and WILLBLOCK, return true or false - depending whether the specified message type is passed to the - application or blocked from being passed to the application by the - filter pointed to by the second argument. - - When an ICMPv6 raw socket is created, it will by default pass all - ICMPv6 message types to the application. - - As an example, a program that wants to receive only router - advertisements could execute the following: - - struct icmp6_filter myfilt; - - fd = socket(PF_INET6, SOCK_RAW, IPPROTO_ICMPV6); - - ICMP6_FILTER_SETBLOCKALL(&myfilt); - ICMP6_FILTER_SETPASS(ND_ROUTER_ADVERT, &myfilt); - setsockopt(fd, IPPROTO_ICMPV6, ICMP6_FILTER, &myfilt, sizeof(myfilt)); - - The filter structure is declared and then initialized to block all - messages types. The filter structure is then changed to allow router - advertisement messages to be passed to the application and the filter - is installed using setsockopt(). - - The icmp6_filter structure is similar to the fd_set datatype used - with the select() function in the sockets API. The icmp6_filter - structure is an opaque datatype and the application should not care - how it is implemented. All the application does with this datatype - is allocate a variable of this type, pass a pointer to a variable of - this type to getsockopt() and setsockopt(), and operate on a variable - of this type using the six macros that we just defined. - - Nevertheless, it is worth showing a simple implementation of this - datatype and the six macros. - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 23] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - struct icmp6_filter { - uint32_t icmp6_filt[8]; /* 8*32 = 256 bits */ - }; - - #define ICMP6_FILTER_WILLPASS(type, filterp) \ - ((((filterp)->icmp6_filt[(type) >> 5]) & (1 << ((type) & 31))) != 0) - #define ICMP6_FILTER_WILLBLOCK(type, filterp) \ - ((((filterp)->icmp6_filt[(type) >> 5]) & (1 << ((type) & 31))) == 0) - #define ICMP6_FILTER_SETPASS(type, filterp) \ - ((((filterp)->icmp6_filt[(type) >> 5]) |= (1 << ((type) & 31)))) - #define ICMP6_FILTER_SETBLOCK(type, filterp) \ - ((((filterp)->icmp6_filt[(type) >> 5]) &= ~(1 << ((type) & 31)))) - #define ICMP6_FILTER_SETPASSALL(filterp) \ - memset((filterp), 0xFF, sizeof(struct icmp6_filter)) - #define ICMP6_FILTER_SETBLOCKALL(filterp) \ - memset((filterp), 0, sizeof(struct icmp6_filter)) - - (Note: These sample definitions have two limitations that an - implementation may want to change. The first four macros evaluate - their first argument two times. The second two macros require the - inclusion of the header for the memset() function.) - - -4. Access to IPv6 and Extension Headers - - Applications need to be able to control IPv6 header and extension - header content when sending as well as being able to receive the - content of these headers. This is done by defining socket option - types which can be used both with setsockopt and with ancillary data. - Ancillary data is discussed in Appendix A. The following optional - information can be exchanged between the application and the kernel: - - 1. The send/receive interface and source/destination address, - 2. The hop limit, - 3. Next hop address, - 4. Routing header. - 5. Hop-by-Hop options, and - 6. Destination options (both before and after a Routing header). - - First, to receive any of this optional information (other than the - next hop address, which can only be set), the application must call - setsockopt() to turn on the corresponding flag: - - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 24] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - int on = 1; - - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on)); - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on)); - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on)); - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDRDSTOPTS, - &on, sizeof(on)); - - When any of these options are enabled, the corresponding data is - returned as control information by recvmsg(), as one or more - ancillary data objects. - - Two different mechanisms exist for sending this optional information: - - 1. Using setsockopt to specify the option content for a socket. - These are known an "sticky" options since they affect all - transmitted packets on the socket until either the a new - setsockopt is done or the options are overridden using ancillary - data. - - 2. Using ancillary data to specify the option content for a single - datagram. This only applies to datagram and raw sockets; not to - TCP sockets. - - - The three socket option parameters and the three cmsghdr fields that - describe the options/ancillary data objects are summarized as: - - opt level/ optname/ optval/ - cmsg_level cmsg_type cmsg_data[] - ------------ ------------ ------------------------ - IPPROTO_IPV6 IPV6_PKTINFO in6_pktinfo structure - IPPROTO_IPV6 IPV6_HOPLIMIT int - IPPROTO_IPV6 IPV6_NEXTHOP socket address structure - IPPROTO_IPV6 IPV6_RTHDR ip6_rthdr structure - IPPROTO_IPV6 IPV6_HOPOPTS ip6_hbh structure - IPPROTO_IPV6 IPV6_DSTOPTS ip6_dest structure - IPPROTO_IPV6 IPV6_RTHDRDSTOPTS ip6_dest structure - - - All these options are described in detail in Section 6, 7, 8 and 9. - All the constants beginning with IPV6_ are defined as a result of - including the . - - Issuing getsockopt() for the above options will return the sticky - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 25] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - option value i.e. the value set with setsockopt(). - - Note: We intentionally use the same constant for the cmsg_level - member as is used as the second argument to getsockopt() and - setsockopt() (what is called the "level"), and the same constant for - the cmsg_type member as is used as the third argument to getsockopt() - and setsockopt() (what is called the "option name"). - - The application does not explicitly need to access the data - structures for the Routing header option, Hop-by-Hop option, and - Destination options, since the API to these features is through a set - of inet6_rth_XXX() and inet6_opt_XXX() functions that we define in - Section 8 and Section 10. Those functions simplify the interface to - these features instead of requiring the application to know the - intimate details of the extension header formats. - - -4.1. TCP Implications - - It is not possible to use ancillary data to transmit the above - options for TCP since there is not a one-to-one mapping between send - operations and the TCP segments being transmitted. Instead an - application can use setsockopt to specify them as sticky options. - When the application uses setsockopt to specify the above options it - is expected that TCP will start using the new information when - sending segments. However, TCP may or may not use the new - information when retransmitting segments that were originally sent - when the old sticky options were in effect. - - Applications using TCP can use ancillary data (after enabling the - desired IPV6_RECVxxx options) to receive the IPv6 and extension - header information. However, since there is not a one-to-one mapping - between received TCP segments and recv operations seen by the - application, when different TCP segments have different IPv6 and - extension headers the application might not be able to observe all - received headers. For efficiency reasons it is recommended that a - TCP implementation not send ancillary data items with every received - segment but instead try to detect the points in the data stream when - the requested IPv6 and extension header content changes and only send - a single ancillary data item at the time of the change. Also, TCP - should send ancillary data items at the start of the connection and - when the application enables a new IPV6_RECVxxx option. - - For example, assume an application has enabled IPV6_RECVHOPLIMIT - before a connection is established. Then the first recvmsg() would - have an IPV6_HOPLIMIT item indicating the hop limit in the first data - segment. Should the hoplimit in the received data segment change a - subsequent recvmsg() will also have an IPV6_HOPLIMIT item. However, - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 26] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - the application must be prepared to handle ancillary data items even - though the hop limit did not change. Note that should the hop limit - in received ACK-only segments be different than the hop limit in data - segments the application might only be able to observe the hop limit - in the received data segments. - - The above example was for hop limit but the application should be - prepared to handle the corresponding behavior for the other option - information. - - The above recvmsg() behavior allows the application to detect changes - in the received IPv6 and extension headers without resorting to - periodic getsockopt() calls. - - -4.2. UDP and Raw Socket Implications - - The receive behavior for UDP and raw sockets is quite - straightforward. After the application has enabled an IPV6_RECVxxx - socket option it will receive ancillary data items for every - recvmsg() call containing the requested information. However, if the - information is not present in the packet the ancillary data item will - not be included. For example, if the application enables - IPV6_RECVRTHDR and a received datagram does not contain a Routing - header there will not be an IPV6_RTHDR ancillary data item. Note - that due to buffering in the socket implementation there might be - some packets queued when an IPV6_RECVxxx option is enabled and they - might not have the ancillary data information. - - For sending the application has the choice between using sticky - options and ancillary data. The application can also use both having - the sticky options specify the "default" and using ancillary data to - override the default options. Note that if any ancillary data is - specified in a call to sendmsg(), all of the sticky options are - overridden for that datagram. For example, if the application has - set IPV6_RTHDR using a sticky option and later passes IPV6_HOPLIMIT - as ancillary data this will override the IPV6_RTHDR sticky option and - no Routing header will be sent with that datagram. - - -5. Extensions to Socket Ancillary Data - - This specification uses ancillary data as defined in Posix.1g which - the following compatible extensions: - - - CMSG_NEXTHDR has been extended to handle a NULL 2nd argument to - mean "get the first header". See Section 22.3.2. - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 27] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - A new CMSG_SPACE macro is defined. It is used to determine how - much space need to be allocated for an ancillary data item. See - Section 22.3.4. - - - A new CMSG_LEN macro is defined. It returns the value to store - in the cmsg_len member of the cmsghdr structure, taking into - account any padding needed to satisfy alignment requirements. - See Section 22.3.5. - - -6. Packet Information - - There are four pieces of information that an application can specify - for an outgoing packet using ancillary data: - - 1. the source IPv6 address, - 2. the outgoing interface index, - 3. the outgoing hop limit, and - 4. the next hop address. - - Three similar pieces of information can be returned for a received - packet as ancillary data: - - 1. the destination IPv6 address, - 2. the arriving interface index, and - 3. the arriving hop limit. - - - The first two pieces of information are contained in an in6_pktinfo - structure that is set with setsockopt() or sent as ancillary data - with sendmsg() and received as ancillary data with recvmsg(). This - structure is defined as a result of including the . - - struct in6_pktinfo { - struct in6_addr ipi6_addr; /* src/dst IPv6 address */ - unsigned int ipi6_ifindex; /* send/recv interface index */ - }; - - In the socket option and cmsghdr level will be IPPROTO_IPV6, the type - will be IPV6_PKTINFO, and the first byte of the option value and - cmsg_data[] will be the first byte of the in6_pktinfo structure. An - application can clear any sticky IPV6_PKTINFO option by either doing - a setsockopt for option with optlen being zero, or by doing a - "regular" setsockopt with ipi6_addr being in6addr_any and - ipi6_ifindex being zero. - - This information is returned as ancillary data by recvmsg() only if - the application has enabled the IPV6_RECVPKTINFO socket option: - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 28] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on)); - - - (Note: The hop limit is not contained in the in6_pktinfo structure - for the following reason. Some UDP servers want to respond to client - requests by sending their reply out the same interface on which the - request was received and with the source IPv6 address of the reply - equal to the destination IPv6 address of the request. To do this the - application can enable just the IPV6_RECVPKTINFO socket option and - then use the received control information from recvmsg() as the - outgoing control information for sendmsg(). The application need not - examine or modify the in6_pktinfo structure at all. But if the hop - limit were contained in this structure, the application would have to - parse the received control information and change the hop limit - member, since the received hop limit is not the desired value for an - outgoing packet.) - - -6.1. Specifying/Receiving the Interface - - Interfaces on an IPv6 node are identified by a small positive - integer, as described in Section 4 of [RFC-2553]. That document also - describes a function to map an interface name to its interface index, - a function to map an interface index to its interface name, and a - function to return all the interface names and indexes. Notice from - this document that no interface is ever assigned an index of 0. - - When specifying the outgoing interface, if the ipi6_ifindex value is - 0, the kernel will choose the outgoing interface. If the application - specifies an outgoing interface for a multicast packet, the interface - specified by the ancillary data overrides any interface specified by - the IPV6_MULTICAST_IF socket option (described in [RFC-2553]), for - that call to sendmsg() only. - - When the IPV6_PKTINFO socket option is enabled, the received - interface index is always returned as the ipi6_ifindex member of the - in6_pktinfo structure. - - -6.2. Specifying/Receiving Source/Destination Address - - The source IPv6 address can be specified by calling bind() before - each output operation, but supplying the source address together with - the data requires less overhead (i.e., fewer system calls) and - requires less state to be stored and protected in a multithreaded - application. - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 29] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - When specifying the source IPv6 address as ancillary data, if the - ipi6_addr member of the in6_pktinfo structure is the unspecified - address (IN6ADDR_ANY_INIT or in6addr_any), then (a) if an address is - currently bound to the socket, it is used as the source address, or - (b) if no address is currently bound to the socket, the kernel will - choose the source address. If the ipi6_addr member is not the - unspecified address, but the socket has already bound a source - address, then the ipi6_addr value overrides the already-bound source - address for this output operation only. - - The kernel must verify that the requested source address is indeed a - unicast address assigned to the node. - - When the in6_pktinfo structure is returned as ancillary data by - recvmsg(), the ipi6_addr member contains the destination IPv6 address - from the received packet. - - -6.3. Specifying/Receiving the Hop Limit - - The outgoing hop limit is normally specified with either the - IPV6_UNICAST_HOPS socket option or the IPV6_MULTICAST_HOPS socket - option, both of which are described in [RFC-2553]. Specifying the - hop limit as ancillary data lets the application override either the - kernel's default or a previously specified value, for either a - unicast destination or a multicast destination, for a single output - operation. Returning the received hop limit is useful for programs - such as Traceroute and for IPv6 applications that need to verify that - the received hop limit is 255 (e.g., that the packet has not been - forwarded). - - The received hop limit is returned as ancillary data by recvmsg() - only if the application has enabled the IPV6_RECVHOPLIMIT socket - option: - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on)); - - In the cmsghdr structure containing this ancillary data, the - cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be - IPV6_HOPLIMIT, and the first byte of cmsg_data[] will be the first - byte of the integer hop limit. - - Nothing special need be done to specify the outgoing hop limit: just - specify the control information as ancillary data for sendmsg() or - using setsockopt(). As specified in [RFC-2553], the interpretation - of the integer hop limit value is - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 30] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - x < -1: return an error of EINVAL - x == -1: use kernel default - 0 <= x <= 255: use x - x >= 256: return an error of EINVAL - - - -6.4. Specifying the Next Hop Address - - The IPV6_NEXTHOP ancillary data object specifies the next hop for the - datagram as a socket address structure. In the cmsghdr structure - containing this ancillary data, the cmsg_level member will be - IPPROTO_IPV6, the cmsg_type member will be IPV6_NEXTHOP, and the - first byte of cmsg_data[] will be the first byte of the socket - address structure. - - This is a privileged option. (Note: It is implementation defined and - beyond the scope of this document to define what "privileged" means. - Unix systems use this term to mean the process must have an effective - user ID of 0.) - - If the socket address structure contains an IPv6 address (e.g., the - sin6_family member is AF_INET6), then the node identified by that - address must be a neighbor of the sending host. If that address - equals the destination IPv6 address of the datagram, then this is - equivalent to the existing SO_DONTROUTE socket option. - - -6.5. Additional Errors with sendmsg() and setsockopt() - - With the IPV6_PKTINFO socket option there are no additional errors - possible with the call to recvmsg(). But when specifying the - outgoing interface or the source address, additional errors are - possible from sendmsg() or setsockopt(). Note that some - implementations might only be able to return this type of errors for - setsockopt(). The following are examples, but some of these may not - be provided by some implementations, and some implementations may - define additional errors: - - ENXIO The interface specified by ipi6_ifindex does not exist. - - ENETDOWN The interface specified by ipi6_ifindex is not enabled - for IPv6 use. - - EADDRNOTAVAIL ipi6_ifindex specifies an interface but the address - ipi6_addr is not available for use on that interface. - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 31] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - EHOSTUNREACH No route to the destination exists over the interface - specified by ifi6_ifindex. - - -7. Routing Header Option - - Source routing in IPv6 is accomplished by specifying a Routing header - as an extension header. There can be different types of Routing - headers, but IPv6 currently defines only the Type 0 Routing header - [RFC-2460]. This type supports up to 127 intermediate nodes (limited - by the length field in the extension header). With this maximum - number of intermediate nodes, a source, and a destination, there are - 128 hops. - - Source routing with IPv4 sockets API (the IP_OPTIONS socket option) - requires the application to build the source route in the format that - appears as the IPv4 header option, requiring intimate knowledge of - the IPv4 options format. This IPv6 API, however, defines eight - functions that the application calls to build and examine a Routing - header, and the ability to use sticky options or ancillary data to - communicate this information between the application and the kernel - using the IPV6_RTHDR option. - - Three functions build a Routing header: - - inet6_rth_space() - return #bytes required for Routing header - inet6_rth_init() - initialize buffer data for Routing header - inet6_rth_add() - add one IPv6 address to the Routing header - - Three functions deal with a returned Routing header: - - inet6_rth_reverse() - reverse a Routing header - inet6_rth_segments() - return #segments in a Routing header - inet6_rth_getaddr() - fetch one address from a Routing header - - The function prototypes for these functions are defined as a result - of including the . - - To receive a Routing header the application must enable the - IPV6_RECVRTHDR socket option: - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); - - To send a Routing header the application specifies it either as - ancillary data in a call to sendmsg() or using setsockopt(). - - The application can remove any sticky Routing header by calling - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 32] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - setsockopt() for IPV6_RTHDR with a zero option length. - - When using ancillary data a Routing header is passed between the - application and the kernel as follows: The cmsg_level member has a - value of IPPROTO_IPV6 and the cmsg_type member has a value of - IPV6_RTHDR. The contents of the cmsg_data[] member is implementation - dependent and should not be accessed directly by the application, but - should be accessed using the six functions that we are about to - describe. - - The following constant is defined as a result of including the - : - - #define IPV6_RTHDR_TYPE_0 0 /* IPv6 Routing header type 0 */ - - When a Routing header is specified, the destination address specified - for connect(), sendto(), or sendmsg() is the final destination - address of the datagram. The Routing header then contains the - addresses of all the intermediate nodes. - - -7.1. inet6_rth_space - - - size_t inet6_rth_space(int type, int segments); - - This function returns the number of bytes required to hold a Routing - header of the specified type containing the specified number of - segments (addresses). For an IPv6 Type 0 Routing header, the number - of segments must be between 0 and 127, inclusive. The return value - is just the space for the Routing header. When the application uses - ancillary data it must pass the returned length to CMSG_LEN() to - determine how much memory is needed for the ancillary data object - (including the cmsghdr structure). - - If the return value is 0, then either the type of the Routing header - is not supported by this implementation or the number of segments is - invalid for this type of Routing header. - - (Note: This function returns the size but does not allocate the space - required for the ancillary data. This allows an application to - allocate a larger buffer, if other ancillary data objects are - desired, since all the ancillary data objects must be specified to - sendmsg() as a single msg_control buffer.) - - -7.2. inet6_rth_init - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 33] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - void *inet6_rth_init(void *bp, int bp_len, int type, int segments); - - This function initializes the buffer pointed to by bp to contain a - Routing header of the specified type and sets ip6r0_len based on the - segments parameter. bp_len is only used to verify that the buffer is - large enough. The ip6r0_segleft field is set to zero; - inet6_rth_add() will increment it. - - When the application uses ancillary data the application must - initialize any cmsghdr fields. - - The caller must allocate the buffer and its size can be determined by - calling inet6_rth_space(). - - Upon success the return value is the pointer to the buffer (bp), and - this is then used as the first argument to the next two functions. - Upon an error the return value is NULL. - - -7.3. inet6_rth_add - - - int inet6_rth_add(void *bp, const struct in6_addr *addr); - - This function adds the IPv6 address pointed to by addr to the end of - the Routing header being constructed. - - If successful, the segleft member of the Routing Header is updated to - account for the new address in the Routing header and the return - value of the function is 0. Upon an error the return value of the - function is -1. - - -7.4. inet6_rth_reverse - - - int inet6_rth_reverse(const void *in, void *out) - - This function takes a Routing header extension header (pointed to by - the first argument) and writes a new Routing header that sends - datagrams along the reverse of that route. Both arguments are - allowed to point to the same buffer (that is, the reversal can occur - in place). - - The return value of the function is 0 on success, or -1 upon an - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 34] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - error. - - -7.5. inet6_rth_segments - - - int inet6_rth_segments(const void *bp); - - This function returns the number of segments (addresses) contained in - the Routing header described by bp. On success the return value is - zero or greater. The return value of the function is -1 upon an - error. - - -7.6. inet6_rth_getaddr - - - struct in6_addr *inet6_rth_getaddr(const void *bp, int index); - - This function returns a pointer to the IPv6 address specified by - index (which must have a value between 0 and one less than the value - returned by inet6_rth_segments()) in the Routing header described by - bp. An application should first call inet6_rth_segments() to obtain - the number of segments in the Routing header. - - Upon an error the return value of the function is NULL. - - -8. Hop-By-Hop Options - - A variable number of Hop-by-Hop options can appear in a single Hop- - by-Hop options header. Each option in the header is TLV-encoded with - a type, length, and value. - - Today only four Hop-by-Hop options are defined for IPv6 [RFC-2460]: - Jumbo Payload, Pad1, PadN, and router-alert. The two pad options are - for alignment purposes and are automatically inserted by the - inet6_opt_XXX() routines and ignored by the inet6_opt_XXX() routines - on the receive side. - - This section of the API is therefore defined for future Hop-by-Hop - options (as well as destination options) that an application may need - to specify and receive. This IPv6 API defines seven functions that - the application calls to build and examine a Hop-by_Hop options - header, and the ability to use sticky options or ancillary data to - communicate this information between the application and the kernel. - This uses the IPV6_HOPOPTS for hob-by-hop options. - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 35] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - Four functions build a options header: - - inet6_opt_init() - initialize buffer data for options header - inet6_opt_append() - add one TLV option to the options header - inet6_opt_finish() - finish adding TLV options to the options header - inet6_opt_set_val() - add one component of the option content to the option - - Three functions deal with a returned options header: - - inet6_opt_next() - extract the next option from the options header - inet6_opt_find() - extract an option of a specified type from the header - inet6_opt_get_val() - retrieve one component of the option content - - - Individual Hop-by-Hop options (and Destination options, which are - described in Section 9 and are very similar to the Hop-by-Hop - options) may have specific alignment requirements. For example, the - 4-byte Jumbo Payload length should appear on a 4-byte boundary, and - IPv6 addresses are normally aligned on an 8-byte boundary. These - requirements and the terminology used with these options are - discussed in Section 4.2 and Appendix B of [RFC-2460]. The alignment - of first byte of each option is specified by two values, called x and - y, written as "xn + y". This states that the option must appear at - an integer multiple of x bytes from the beginning of the options - header (x can have the values 1, 2, 4, or 8), plus y bytes (y can - have a value between 0 and 7, inclusive). The Pad1 and PadN options - are inserted as needed to maintain the required alignment. The - functions below need to know the alignment of the end of the option - (which is always in the form "xn," where x can have the values 1, 2, - 4, or 8) and the total size of the data portion of the option. These - are passed as the "align" and "len" arguments to inet6_opt_append(). - - Multiple Hop-by-Hop options must be specified by the application by - placing them in a single extension header. - - Finally, we note that use of some Hop-by-Hop options or some - Destination options, might require special privilege. That is, - normal applications (without special privilege) might be forbidden - from setting certain options in outgoing packets, and might never see - certain options in received packets. - - -8.1. Receiving Hop-by-Hop Options - - To receive Hop-by-Hop options the application must enable the - IPV6_RECVHOPOPTS socket option: - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 36] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on)); - - When using ancillary data a Hop-by-hop options is passed between the - application and the kernel as follows: The cmsg_level member will be - IPPROTO_IPV6 and the cmsg_type member will be IPV6_HOPOPTS. These - options are then processed by calling the inet6_opt_next(), - inet6_opt_find(), and inet6_opt_get_val() functions, described in - Section 10.6. - - -8.2. Sending Hop-by-Hop Options - - To send a Hop-by-Hop options header, the application specifies the - header either as ancillary data in a call to sendmsg() or using - setsockopt(). - - The application can remove any sticky Hop-by-Hop extension header by - calling setsockopt() for IPV6_HOPOPTS with a zero option length. - - All the Hop-by-Hop options must specified by a single ancillary data - object. The cmsg_level member is set to IPPROTO_IPV6 and the - cmsg_type member is set to IPV6_HOPOPTS. The option is normally - constructed using the inet6_opt_init(), inet6_opt_append(), - inet6_opt_finish(), and inet6_set_val() functions, described in - Section 10. - - Additional errors may be possible from sendmsg() and setsockopt() if - the specified option is in error. - - -9. Destination Options - - A variable number of Destination options can appear in one or more - Destination option headers. As defined in [RFC-2460], a Destination - options header appearing before a Routing header is processed by the - first destination plus any subsequent destinations specified in the - Routing header, while a Destination options header appearing after a - Routing header is processed only by the final destination. As with - the Hop-by-Hop options, each option in a Destination options header - is TLV-encoded with a type, length, and value. - - Today no Destination options are defined for IPv6 [RFC-2460], - although proposals exist to use Destination options with Mobile IPv6. - - -9.1. Receiving Destination Options - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 37] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - To receive Destination options appearing after a Routing header (or - in a packet without a Routing header) the application must enable the - IPV6_RECVDSTOPTS socket option: - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); - - To receive Destination options appearing before a Routing header the - application must enable the IPV6_RECVRTHDRDSTOPTS socket option: - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDRDSTOPTS, - &on, sizeof(on)); - - All the Destination options appearing before a Routing header are - returned as one ancillary data object described by a cmsghdr - structure (with cmsg_type set to IPV6_RTHDRDSTOPTS) and all the - Destination options appearing after a Routing header (or in a packet - without a Routing header) are returned as another ancillary data - object described by a cmsghdr structure (with cmsg_type set to - IPV6_DSTOPTS). For all these ancillary data objects, the cmsg_level - member will be IPPROTO_IPV6. - - These options are then processed by calling the inet6_opt_next(), - inet6_opt_find(), and inet6_opt_get_value() functions. - - -9.2. Sending Destination Options - - To send a Destination options header, the application specifies it - either as ancillary data in a call to sendmsg() or using - setsockopt(). - - The application can remove any sticky Destination extension header by - calling setsockopt() for IPV6_RTHDRDSTOPTS/IPV6_DSTOPTS with a zero - option length. - - As described in Section 6 one set of Destination options can appear - before a Routing header, and one set can appear after a Routing - header (or in a packet with no Routing header). Each set can consist - of one or more options but each set is a single extension header. - - When using ancillary data a Destination options header is passed - between the application and the kernel as follows: The set preceding - a Routing header are specified with the cmsg_level member is set to - IPPROTO_IPV6 and the cmsg_type member is set to IPV6_RTHDRDSTOPTS. - Any setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently - ignore when sending packets unless a Routing header is also - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 38] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - specified. - - The set of Destination options after a Routing header, which are also - used when no Routing header is present, are specified with the - cmsg_level member is set to IPPROTO_IPV6 and the cmsg_type member is - set to IPV6_DSTOPTS. - - The Destination options are normally constructed using the - inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and - inet6_set_val() functions, described in Section 10. - - Additional errors may be possible from sendmsg() and setsockopt() if - the specified option is in error. - - -10. Hop-by-Hop and Destination Options Processing - - Building and parsing the Hop-by-Hop and Destination options is - complicated for the reasons given earlier. We therefore define a set - of functions to help the application. These functions assume the - formatting rules specified in Appendix B in [RFC-2460] i.e. that the - largest field is placed last in the option. - - The function prototypes for these functions are defined as a result - of including the . - - The first 3 functions (init, append, and finish) are used both to - calculate the needed buffer size for the options, and to actually - encode the options once the application has allocated a buffer for - the header. In order to only calculate the size the application must - pass a NULL extbuf and a zero extlen to those functions. - - -10.1. inet6_opt_init - - - int inet6_opt_init(void *extbuf, size_t extlen); - - This function returns the number of bytes needed for the empty - extension header i.e. without any options. If extbuf is not NULL it - also initializes the extension header to have the correct length - field. If the extlen value is not a positive (i.e., non-zero) - multiple of 8 the function fails and returns -1. - - -10.2. inet6_opt_append - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 39] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - int inet6_opt_append(void *extbuf, size_t extlen, int prevlen, - uint8_t type, size_t len, uint_t align, - void **databufp); - - Prevlen should be the length returned by inet6_opt_init() or a - previous inet6_opt_append(). This function returns the updated total - length taking into account adding an option with length 'len' and - alignment 'align'. If extbuf is not NULL then, in addition to - returning the length, the function inserts any needed pad option, - initializes the option (setting the type and length fields) and - returns a pointer to the location for the option content in databufp. - If the option does not fit in the extension header buffer the - function returns -1. - - type is the 8-bit option type. len is the length of the option data - (i.e. excluding the option type and option length fields). - - Once inet6_opt_append() has been called the application can use the - databuf directly, or use inet6_opt_set_val() to specify the content - of the option. - - The option type must have a value from 2 to 255, inclusive. (0 and 1 - are reserved for the Pad1 and PadN options, respectively.) - - The option data length must have a value between 0 and 255, - inclusive, and is the length of the option data that follows. - - The align parameter must have a value of 1, 2, 4, or 8. The align - value can not exceed the value of len. - - -10.3. inet6_opt_finish - - - int inet6_opt_finish(void *extbuf, size_t extlen, int prevlen); - - Prevlen should be the length returned by inet6_opt_init() or - inet6_opt_append(). This function returns the updated total length - taking into account the final padding of the extension header to make - it a multiple of 8 bytes. If extbuf is not NULL the function also - initializes the option by inserting a Pad1 or PadN option of the - proper length. - - If the necessary pad does not fit in the extension header buffer the - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 40] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - function returns -1. - - -10.4. inet6_opt_set_val - - - int inet6_opt_set_val(void *databuf, size_t offset, void *val, - int vallen); - - Databuf should be a pointer returned by inet6_opt_append(). This - function inserts data items of various sizes (1, 2, 4, or 8 bytes) in - the data portion of the option. val should point to the data to be - inserted. Offset specifies where in the data portion of the option - the value should be inserted; the first byte after the option type - and length is accessed by specifying an offset of zero. - - The function returns the offset for the next field (i.e., offset + - vallen) which can be used when composing option content with multiple - fields. - - -10.5. inet6_opt_next - - - int inet6_opt_next(void *extbuf, size_t extlen, int prevlen, - uint8_t *typep, size_t *lenp, - void **databufp); - - This function parses received extension headers returning the next - option. Extbuf and extlen specifies the extension header. Prevlen - should either be zero (for the first option) or the length returned - by a previous call to inet6_opt_next() or inet6_opt_find(). It - specifies the position where to continue scanning the extension - buffer. The next option is returned by updating typep, lenp, and - databufp. This function returns the updated "previous" length - computed by advancing past the option that was returned. This - returned "previous" length can then be passed to subsequent calls to - inet6_opt_next(). This function does not return any PAD1 or PADN - options. When there are no more options the return value is -1. - - -10.6. inet6_opt_find - - - int inet6_opt_find(void *extbuf, size_t extlen, int prevlen, - uint8_t type, size_t *lenp, - void **databufp); - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 41] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - This function is similar to the previously described inet6_opt_next() - function, except this function lets the caller specify the option - type to be searched for, instead of always returning the next option - in the extension header. - - If an option of the specified type is located, the function returns - the updated "previous" total length computed by advancing past the - option that was returned and past any options that didn't match the - type. This returned "previous" length can then be passed to - subsequent calls to inet6_opt_find() for finding the next occurance - of the same option type. - - If an option of the specified type is not located, the return value - is -1. If an error occurs, the return value is -1. - - -10.7. inet6_opt_get_val - - - int inet6_opt_get_val(void *databuf, size_t offset, void *val, - int vallen); - - Databuf should be a pointer returned by inet6_opt_next() or - inet6_opt_find(). This function extracts data items of various sizes - (1, 2, 4, or 8 bytes) in the data portion of the option. val should - point to the destination for the extracted data. Offset specifies - from where in the data portion of the option the value should be - extracted; the first byte after the option type and length is - accessed by specifying an offset of zero. - - The function returns the offset for the next field (i.e., offset + - vallen) which can be used when extracting option content with - multiple fields. XXX Perhaps we should add a note to point out that - robust receivers should verify alignment before calling - inet6_opt_get_val(). XXX Or check alignment and fail by returning - -1? - - -11. Additional Advanced API Functions - - - -11.1. Sending with the Minimum MTU - - Some applications might not want to incur the overhead of path MTU - discovery, especially if the applications only send a single datagram - to a destination. A potential example is a DNS server. - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 42] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - This specification defines a mechanism to avoid fragmentation by - sending at the minimum IPv6 MTU (1280 bytes). This can be enabled - using the IPV6_USE_MIN_MTU socket option. - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on)); - - By default, this socket option is disabled. Setting the value to 0 - also disables the option. This option can also be sent as ancillary - data. - - -11.2. Path MTU Discovery and UDP - - UDP and raw socket applications need to be able to determine the - "maximum send transport-message size" (Section 5.1 of [RFC-1981]) to - a given destination so that those applications can participate in - path MTU discovery. This lets those applications send smaller - datagrams to the destination, avoiding fragmentation. - - This is accomplished using a new ancillary data item (IPV6_PATHMTU) - which is delivered to recvmsg() without any actual data. The - application enable the receipt of IPV6_PATHMTU ancillary data items - by enabing IPV6_RECVPATHMTU. - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPATHMTU, &on, sizeof(on)); - - By default, this socket option is disabled. Setting the value to 0 - also disables the option. - - When the application is sending packets too big for the path MTU - recvmsg will return zero (indicating no data) but there will be a - cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will - indicate that cmsg_data is 4 bytes long. CMSG_DATA will point to an - integer carrying the path MTU to use. - - -11.3. Neighbor Reachability and UDP - - UDP and raw socket application might know that communication is - making forward progress i.e. that the path from the node to the next - hop is working. In such a case the applications, similarly to TCP as - specified in [RFC-2461], has the option indicate to the internet - layer that the neighbor is reachable. See section 7.3.1 of - [RFC-2461]. This could save unneeded neighbor solicitation and - neighbor advertisement messages. - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 43] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - This is done by including an ancilary data item with cmsg_type being - IPV6_REACHCONF and with no attached CMSG_DATA. - - -12. Ordering of Ancillary Data and IPv6 Extension Headers - - Three IPv6 extension headers can be specified by the application and - returned to the application using ancillary data with sendmsg() and - recvmsg(): the Routing header, Hop-by-Hop options, and Destination - options. When multiple ancillary data objects are transferred via - recvmsg() and these objects represent any of these three extension - headers, their placement in the control buffer is directly tied to - their location in the corresponding IPv6 datagram. This API imposes - some ordering constraints for using these ancillary data objects with - sendmsg(). - - All Hop-by-Hop options must be specified in a single ancillary data - object. Should multiple hop-by-hop ancillary data objects be - specified the implementation might choose an arbitrary one or drop - the packet. - - All Destination options that precede a Routing header must be - specified in a single ancillary data object. If there is no Routing - header ancillary data object the IPV6_RTHDRDSTOPTS object will be - silently ignored. - - All Destination options that follow a Routing header (or are used - without a Routing header) must be specified in a single ancillary - data object. - - If Destination options are specified in the control buffer after a - Routing header, or if Destination options are specified without a - Routing header, the kernel will place those Destination options after - an authentication header and/or an encapsulating security payload - header, if present. - - -13. IPv6-Specific Options with IPv4-Mapped IPv6 Addresses - - The various socket options and ancillary data specifications defined - in this document apply only to true IPv6 sockets. It is possible to - create an IPv6 socket that actually sends and receives IPv4 packets, - using IPv4-mapped IPv6 addresses, but the mapping of the options - defined in this document to an IPv4 datagram is beyond the scope of - this document. - - In general, attempting to specify an IPv6-only option, such as the - Hop-by-Hop options, Destination options, or Routing header on an IPv6 - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 44] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - socket that is using IPv4-mapped IPv6 addresses, will probably result - in an error. Some implementations, however, may provide access to - the packet information (source/destination address, send/receive - interface, and hop limit) on an IPv6 socket that is using IPv4-mapped - IPv6 addresses. - - -14. Extended interfaces for rresvport, rcmd and rexec - - TBD - - -14.1. rresvport_af - - The rresvport() function is used by the rcmd() function, and this - function is in turn called by many of the "r" commands such as - rlogin. While new applications are not being written to use the - rcmd() function, legacy applications such as rlogin will continue to - use it and these will be ported to IPv6. - - rresvport() creates an IPv4/TCP socket and binds a "reserved port" to - the socket. Instead of defining an IPv6 version of this function we - define a new function that takes an address family as its argument. - - #include - - int rresvport_af(int *port, int family); - - This function behaves the same as the existing rresvport() function, - but instead of creating an AF_INET TCP socket, it can also create an - AF_INET6 TCP socket. The family argument is either AF_INET or - AF_INET6, and a new error return is EAFNOSUPPORT if the address - family is not supported. - - (Note: There is little consensus on which header defines the - rresvport() and rcmd() function prototypes. 4.4BSD defines it in - , others in , and others don't define the function - prototypes at all.) - - -14.2. rcmd_af - - The existing rcmd() function can not transparently use AF_INET6 - sockets since the an application would not be prepared to handle - AF_INET6 addresses returned by e.g. getpeername on the file - descriptor created by rcmd. Thus a new function is needed. - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 45] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - int rcmd_af(char **ahost, unsigned short rport, const char *locuser, - const char *remuser, const char *cmd, int *fd2p, int af) - - This function behaves the same as the existing rcmd() function, but - instead of creating an AF_INET TCP socket, it can also create an - AF_INET6 TCP socket. The family argument is either AF_INET or - AF_INET6, and a new error return is EAFNOSUPPORT if the address - family is not supported. - - -14.3. rexec_af - - The existing rexec() function can not transparently use AF_INET6 - sockets since the an application would not be prepared to handle - AF_INET6 addresses returned by e.g. getpeername on the file - descriptor created by rexec. Thus a new function is needed. - - int rexec_af(char **ahost, unsigned short rport, const char *name, - const char *pass, const char *cmd, int *fd2p, int af) - - This function behaves the same as the existing rexec() function, but - instead of creating an AF_INET TCP socket, it can also create an - AF_INET6 TCP socket. The family argument is either AF_INET or - AF_INET6, and a new error return is EAFNOSUPPORT if the address - family is not supported. - - -15. Summary of New Definitions - - The following list summarizes the constants and structure, - definitions discussed in this memo, sorted by header. - - ICMP6_DST_UNREACH - ICMP6_DST_UNREACH_ADDR - ICMP6_DST_UNREACH_ADMIN - ICMP6_DST_UNREACH_NOPORT - ICMP6_DST_UNREACH_NOROUTE - ICMP6_DST_UNREACH_BEYONDSCOPE - ICMP6_ECHO_REPLY - ICMP6_ECHO_REQUEST - ICMP6_INFOMSG_MASK - ICMP6_MEMBERSHIP_QUERY - ICMP6_MEMBERSHIP_REDUCTION - ICMP6_MEMBERSHIP_REPORT - ICMP6_PACKET_TOO_BIG - ICMP6_PARAMPROB_HEADER - ICMP6_PARAMPROB_NEXTHEADER - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 46] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - ICMP6_PARAMPROB_OPTION - ICMP6_PARAM_PROB - ICMP6_TIME_EXCEEDED - ICMP6_TIME_EXCEED_REASSEMBLY - ICMP6_TIME_EXCEED_TRANSIT - ND_NA_FLAG_OVERRIDE - ND_NA_FLAG_ROUTER - ND_NA_FLAG_SOLICITED - ND_NEIGHBOR_ADVERT - ND_NEIGHBOR_SOLICIT - ND_OPT_MTU - ND_OPT_PI_FLAG_AUTO - ND_OPT_PI_FLAG_ONLINK - ND_OPT_PREFIX_INFORMATION - ND_OPT_REDIRECTED_HEADER - ND_OPT_SOURCE_LINKADDR - ND_OPT_TARGET_LINKADDR - ND_RA_FLAG_MANAGED - ND_RA_FLAG_OTHER - ND_REDIRECT - ND_ROUTER_ADVERT - ND_ROUTER_SOLICIT - - struct icmp6_filter{}; - struct icmp6_hdr{}; - struct nd_neighbor_advert{}; - struct nd_neighbor_solicit{}; - struct nd_opt_hdr{}; - struct nd_opt_mtu{}; - struct nd_opt_prefix_info{}; - struct nd_opt_rd_hdr{}; - struct nd_redirect{}; - struct nd_router_advert{}; - struct nd_router_solicit{}; - - IPPROTO_AH - IPPROTO_DSTOPTS - IPPROTO_ESP - IPPROTO_FRAGMENT - IPPROTO_HOPOPTS - IPPROTO_ICMPV6 - IPPROTO_IPV6 - IPPROTO_NONE - IPPROTO_ROUTING - IPV6_RECVDSTOPTS - IPV6_RECVHOPLIMIT - IPV6_RECVHOPOPTS - IPV6_RECVPKTINFO - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 47] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - IPV6_RECVRTHDR - IPV6_RECVRTHDRDSTOPTS - IPV6_DSTOPTS - IPV6_HOPLIMIT - IPV6_HOPOPTS - IPV6_NEXTHOP - IPV6_PKTINFO - IPV6_RTHDR - IPV6_RTHDRDSTOPTS - IPV6_RTHDR_TYPE_0 - IPV6_USE_MIN_MTU - IPV6_RECVPATHMTU - IPV6_PATHMTU - IPV6_REACHCONF - struct in6_pktinfo{}; - - IP6F_OFF_MASK - IP6F_RESERVED_MASK - IP6F_MORE_FRAG - struct ip6_dest{}; - struct ip6_frag{}; - struct ip6_hbh{}; - struct ip6_hdr{}; - struct ip6_rthdr{}; - struct ip6_rthdr0{}; - - struct cmsghdr{}; - struct msghdr{}; - - - The following list summarizes the function and macro prototypes - discussed in this memo, sorted by header. - - void ICMP6_FILTER_SETBLOCK(int, struct icmp6_filter *); - void ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *); - void ICMP6_FILTER_SETPASS(int, struct icmp6_filter *); - void ICMP6_FILTER_SETPASSALL(struct icmp6_filter *); - int ICMP6_FILTER_WILLBLOCK(int, - const struct icmp6_filter *); - int ICMP6_FILTER_WILLPASS(int, - const struct icmp6_filter *); - - int IN6_ARE_ADDR_EQUAL(const struct in6_addr *, - const struct in6_addr *); - - int inet6_opt_append(void *, size_t, int, - uint8_t, size_t, uint_8, void **); - int inet6_opt_get_val(void *, size_t, void *, int); - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 48] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - int inet6_opt_find(void *, size_t, int, uint8_t , - size_t *, void **); - int inet6_opt_finish(void *, size_t, int); - int inet6_opt_init(void *, size_t); - int inet6_opt_next(void *, size_t, int, uint8_t *, - size_t *, void **); - int inet6_opt_set_val(void *, size_t, void *, int); - - int inet6_rth_add(void *, - const struct in6_addr *); - struct in6_addr inet6_rth_getaddr(const void *, - int); - void *inet6_rth_init(void *, int, int, int); - int inet6_rth_reverse(const void *, void *); - int inet6_rth_segments(const void *); - size_t inet6_rth_space(int, int); - - unsigned char *CMSG_DATA(const struct cmsghdr *); - struct cmsghdr *CMSG_FIRSTHDR(const struct msghdr *); - unsigned int CMSG_LEN(unsigned int); - struct cmsghdr *CMSG_NXTHDR(const struct msghdr *mhdr, - const struct cmsghdr *); - unsigned int CMSG_SPACE(unsigned int); - - int rresvport_af(int *, int); - int rcmd_af(char **, unsigned short, const char *, - const char *, const char *, int *, int); - int rexec_af(char **, unsigned short , const char *, - const char *, const char *, int *, int); - - - -16. Security Considerations - - The setting of certain Hop-by-Hop options and Destination options may - be restricted to privileged processes. Similarly some Hop-by-Hop - options and Destination options may not be returned to nonprivileged - applications. - - The ability to specify an arbitrary source address using IPV6_PKTINFO - must be prevented; at least for non-privileged processes. - - -17. Change History - - Changes from RFC 2292: - - - Removed the IPV6_PKTOPTIONS socket option by allowing sticky - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 49] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - options to be set with individual setsockopt calls. This - simplifies the protocol stack implementation by not having to - handle options within options and also clarifies the failure - semantics when some option is incorrectly formatted. - - - Added the IPV6_RTHDRDSTOPTS for a Destination header before the - Routing header. This is necessary to allow setting these - Destination headers without IPV6_PKTOPTIONS. - - - Removed the ability to be able to specify Hop-by-Hop and - Destination options using multiple ancillary data items. The - application, using the inet6_option_*() routines, is responsible - for formatting the whole extension header. This removes the need - for the protocol stack to somehow guess the alignment - restrictions on options when concatenating them together. - - - Added separate IPV6_RECVxxx options to enable the receipt of the - corresponding ancillary data items. This makes the API cleaner - since it allows the application to retrieve with getsockopt the - sticky options it has set with setsockopt. - - - Clarified how sticky options are turned off. - - - Clarified how and when TCP returns ancillary data. - - - Removed the support for the loose/strict Routing header since - that has been removed from the IPv6 specification. - - - Modified the inet6_rthdr_XXX() functions to not assume a cmsghdr - structure in order to work with both sticky options and ancillary - data. Renamed the functions to inet6_rth_XXX() to allow - implementations to provide both the old and new functions. - - - Modified the inet6_option_XXX() functions to not assume a cmsghdr - structure in order to work with both sticky options and ancillary - data. Renamed the functions to inet6_opt_XXX() to allow - implementations to provide both the old and new functions. - - - The new inet6_opt_XXX() functions were made different that the - old as to not require structure declarations but instead use - functions to add the individual fields to the option. - - - Changed inet6_rthdr_getaddr() to operate on index O through N-1 - (used to be 1 through N). - - - Changed the comments in the struct ip6_hdr from "priority" to - "traffic class". - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 50] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - Clarified the alignment issues involving ancillary data to allow - for separate alignment of cmsghdr structures and the data. Made - CMSG_SPACE() return an upper bound on the needed space. - - - Added rcmd_af() and rexec_af(). - - Changes since -00: - - - Changed ICMP unreachable code 2 name to be "beyond scope of - source address". - - - Added motivation for rcmd_af() and rexec_af(). - - - Added option definitions (IP6OPT_PAD1 etc) to ip6.h. - - - Added MLD and router renumbering definitions to icmp6.h - - - Removed ip6r0_addr field - replaced by a comment. - - - Made the content of IPV6_RTHDR, IPV6_HOPOPTS etc be specified as - the extension header format (struct ip6_rthdr etc) instead of the - previous "implementation dependent". - - - Removed attempt at RFC 2292 compatibility. - - - Excluded pad options from inet6_opt_next(). - - - Added IPV6_USE_MIN_MTU socket option for applications to avoid - fragmentation by sending at the minimum IPv6 MTU. - - - Added MTU notification so that UDP and raw socket applications - can participate in path MTU discovery. - - - Added Reachability confirmation for UDP and raw socket - applications. - - - Clarified that if the application asks for e.g., IPV6_RTHDR and a - received datagram does not contain a Routing header an - implementation will exclude the IPV6_RTHDR ancillary data item. - - - Removed the constraints for jumbo option. - - - Moved the new CMSG macros and changes from the appendix. - - - Add text about inet6_opt_ depending on 2260 appendix B formatting - rules i.e. largest field last in the option. - - - Specified that getsockopt() of a sticky option returns what was - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 51] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - set with setsockopt(). - - -18. TODO and Open Issues - - Items left to do: - - - Add credits for UDP MTU stuff - - - Move information about mapping from inet6_opt to setsockopt and - cmsg. - - - Clarify IPV6_RTHDRDSTOPTS's interaction with IPV6_RTHDR. - - - Make the new inet6_opt_set_val() and inet6_opt_get_val() check - the length of the data item. - - Open issues: - - - Anything special for mobility options? Restrict setting at API? - Filter out on receipt? If received what does the home address - option contain? - - - Specify "change" for TCP especially when there are multiple HBH - option headers etc. - - - Specify binding to scope-id => implies filtering of addresses - with that scope if the address you are bound to is link-local - etc. What about conflicts with bound scope-id and sendto/connect - scope-id? - - - Specify order for ifindex selection. Put in separate section. - Different cases for sending to link-local (scope_id including - nexthop scope_id) and global. Is multicast different? - - - bind() and sin6_scope_id. Should have been in Basic API. Error - checks when bind/sendto sin6_scope_id does not match? - - - Specify notion of default multicast interface? In Basic API? - - - What about site names and site ids? Need for interfaces to map? - Requires that site-prefixes pass name - does name need to use DNS - format to handle character sets? - - -19. References - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 52] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - [RFC-2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 - (IPv6), Specification", RFC 2460, Dec. 1998. - - [RFC-2553] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W., - "Basic Socket Interface Extensions for IPv6", RFC 2553, - March 1999. - - [RFC-1981] McCann, J., Deering, S., Mogul, J, "Path MTU Discovery - for IP version 6", RFC 1981, Aug. 1996. - - [RFC-2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor - Discovery for IP Version 6 (IPv6)", RFC 2461, Dec. 1998. - - -20. Acknowledgments - - Matt Thomas and Jim Bound have been working on the technical details - in this draft for over a year. Keith Sklower is the original - implementor of ancillary data in the BSD networking code. Craig Metz - provided lots of feedback, suggestions, and comments based on his - implementing many of these features as the document was being - written. - - The following provided comments on earlier drafts: Pascal Anelli, - Hamid Asayesh, Ran Atkinson, Karl Auerbach, Hamid Asayesh, Jim Bound, - Don Coolidge, Matt Crawford, Sam T. Denton, Richard Draves, Francis - Dupont, Bob Gilligan, Jun-ichiro Hagino, Gerri Harter, Tim Hartrick, - Bob Halley, Masaki Hirabaru, Yoshinobu Inoue, Mukesh Kacker, A. N. - Kuznetsov, Sam Manthorpe, Pedro Marques, Jack McCann, der Mouse, John - Moy, Thomas Narten, Steve Parker, Charles Perkins, Ken Powell, Tom - Pusateri, Pedro Roque, Sameer Shah, Peter Sjodin, Stephen P. - Spackman, Jinmei Tatuya, Karen Tracey, Sowmini Varadhan, Quaizar - Vohra, Carl Williams, Steve Wise, Eric Wong, Farrell Woods, Kazu - Yamamoto, and Vlad Yasevich. - - -21. Authors' Addresses - - W. Richard Stevens - 1202 E. Paseo del Zorro - Tucson, AZ 85718 - Email: rstevens@kohala.com - - - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 53] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - Matt Thomas - 3am Software Foundry - 8053 Park Villa Circle - Cupertino, CA 95014 - Email: matt@3am-software.com - - - Erik Nordmark - Sun Microsystems, Inc. - 901 San Antonio Road - Palo Alto, CA 94303, USA - Email: erik.nordmark@eng.sun.com - - - -22. Appendix A: Ancillary Data Overview - - 4.2BSD allowed file descriptors to be transferred between separate - processes across a UNIX domain socket using the sendmsg() and - recvmsg() functions. Two members of the msghdr structure, - msg_accrights and msg_accrightslen, were used to send and receive the - descriptors. When the OSI protocols were added to 4.3BSD Reno in - 1990 the names of these two fields in the msghdr structure were - changed to msg_control and msg_controllen, because they were used by - the OSI protocols for "control information", although the comments in - the source code call this "ancillary data". - - Other than the OSI protocols, the use of ancillary data has been - rare. In 4.4BSD, for example, the only use of ancillary data with - IPv4 is to return the destination address of a received UDP datagram - if the IP_RECVDSTADDR socket option is set. With Unix domain sockets - ancillary data is still used to send and receive descriptors. - - Nevertheless the ancillary data fields of the msghdr structure - provide a clean way to pass information in addition to the data that - is being read or written. The inclusion of the msg_control and - msg_controllen members of the msghdr structure along with the cmsghdr - structure that is pointed to by the msg_control member is required by - the Posix.1g sockets API standard. - - - -22.1. The msghdr Structure - - The msghdr structure is used by the recvmsg() and sendmsg() - functions. Its Posix.1g definition is: - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 54] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - struct msghdr { - void *msg_name; /* ptr to socket address structure */ - socklen_t msg_namelen; /* size of socket address structure */ - struct iovec *msg_iov; /* scatter/gather array */ - size_t msg_iovlen; /* # elements in msg_iov */ - void *msg_control; /* ancillary data */ - socklen_t msg_controllen; /* ancillary data buffer length */ - int msg_flags; /* flags on received message */ - }; - - The structure is declared as a result of including . - - (Note: Before Posix.1g the two "void *" pointers were typically "char - *", and the two socklen_t members and the size_t member were - typically integers. Earlier drafts of Posix.1g had the two socklen_t - members as size_t, but Draft 6.6 of Posix.1g, apparently the final - draft, changed these to socklen_t to simplify binary portability for - 64-bit implementations and to align Posix.1g with X/Open's Networking - Services, Issue 5. The change in msg_control to a "void *" pointer - affects any code that increments this pointer.) - - (Note: Before Posix.1g the cmsg_len member was an integer, and not a - socklen_t. See the Note in the previous section for why socklen_t is - used here.) - - Most Berkeley-derived implementations limit the amount of ancillary - data in a call to sendmsg() to no more than 108 bytes (an mbuf). - This API requires a minimum of 10240 bytes of ancillary data, but it - is recommended that the amount be limited only by the buffer space - reserved by the socket (which can be modified by the SO_SNDBUF socket - option). (Note: This magic number 10240 was picked as a value that - should always be large enough. 108 bytes is clearly too small as the - maximum size of a Routing header is 2048 bytes.) - - -22.2. The cmsghdr Structure - - The cmsghdr structure describes ancillary data objects transferred by - recvmsg() and sendmsg(). Its Posix.1g definition is: - - struct cmsghdr { - socklen_t cmsg_len; /* #bytes, including this header */ - int cmsg_level; /* originating protocol */ - int cmsg_type; /* protocol-specific type */ - /* followed by unsigned char cmsg_data[]; */ - }; - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 55] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - This structure is declared as a result of including . - - As shown in this definition, normally there is no member with the - name cmsg_data[]. Instead, the data portion is accessed using the - CMSG_xxx() macros, as described in Section 22.3. Nevertheless, it is - common to refer to the cmsg_data[] member. - - When ancillary data is sent or received, any number of ancillary data - objects can be specified by the msg_control and msg_controllen - members of the msghdr structure, because each object is preceded by a - cmsghdr structure defining the object's length (the cmsg_len member). - Historically Berkeley-derived implementations have passed only one - object at a time, but this API allows multiple objects to be passed - in a single call to sendmsg() or recvmsg(). The following example - shows two ancillary data objects in a control buffer. - - |<--------------------------- msg_controllen -------------------------->| - | OR | - |<--------------------------- msg_controllen ----------------------->| - | | - |<----- ancillary data object ----->|<----- ancillary data object ----->| - |<------ min CMSG_SPACE() --------->|<------ min CMSG_SPACE() --------->| - | | | - |<---------- cmsg_len ---------->| |<--------- cmsg_len ----------->| | - |<--------- CMSG_LEN() --------->| |<-------- CMSG_LEN() ---------->| | - | | | | | - +-----+-----+-----+--+-----------+--+-----+-----+-----+--+-----------+--+ - |cmsg_|cmsg_|cmsg_|XX| |XX|cmsg_|cmsg_|cmsg_|XX| |XX| - |len |level|type |XX|cmsg_data[]|XX|len |level|type |XX|cmsg_data[]|XX| - +-----+-----+-----+--+-----------+--+-----+-----+-----+--+-----------+--+ - ^ - | - msg_control - points here - - - The fields shown as "XX" are possible padding, between the cmsghdr - structure and the data, and between the data and the next cmsghdr - structure, if required by the implementation. While sending an - application may or may not include padding at the end of last - ancillary data in msg_controllen and implementations must accept both - as valid. On receiving a portable application must provide space for - padding at the end of the last ancillary data as implementations may - copy out the padding at the end of the control message buffer and - include it in the received msg_controllen. When recvmsg() is called - if msg_controllen is too small for all the ancillary data items - including any trailing padding after the last item an implementation - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 56] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - may set MSG_CTRUNC. - - -22.3. Ancillary Data Object Macros - - To aid in the manipulation of ancillary data objects, three macros - from 4.4BSD are defined by Posix.1g: CMSG_DATA(), CMSG_NXTHDR(), and - CMSG_FIRSTHDR(). Before describing these macros, we show the - following example of how they might be used with a call to recvmsg(). - - struct msghdr msg; - struct cmsghdr *cmsgptr; - - /* fill in msg */ - - /* call recvmsg() */ - - for (cmsgptr = CMSG_FIRSTHDR(&msg); cmsgptr != NULL; - cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) { - if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) { - u_char *ptr; - - ptr = CMSG_DATA(cmsgptr); - /* process data pointed to by ptr */ - } - } - - We now describe the three Posix.1g macros, followed by two more that - are new with this API: CMSG_SPACE() and CMSG_LEN(). All these macros - are defined as a result of including . - - -22.3.1. CMSG_FIRSTHDR - - - struct cmsghdr *CMSG_FIRSTHDR(const struct msghdr *mhdr); - - CMSG_FIRSTHDR() returns a pointer to the first cmsghdr structure in - the msghdr structure pointed to by mhdr. The macro returns NULL if - there is no ancillary data pointed to by the msghdr structure (that - is, if either msg_control is NULL or if msg_controllen is less than - the size of a cmsghdr structure). - - One possible implementation could be - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 57] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - #define CMSG_FIRSTHDR(mhdr) \ - ( (mhdr)->msg_controllen >= sizeof(struct cmsghdr) ? \ - (struct cmsghdr *)(mhdr)->msg_control : \ - (struct cmsghdr *)NULL ) - - (Note: Most existing implementations do not test the value of - msg_controllen, and just return the value of msg_control. The value - of msg_controllen must be tested, because if the application asks - recvmsg() to return ancillary data, by setting msg_control to point - to the application's buffer and setting msg_controllen to the length - of this buffer, the kernel indicates that no ancillary data is - available by setting msg_controllen to 0 on return. It is also - easier to put this test into this macro, than making the application - perform the test.) - - -22.3.2. CMSG_NXTHDR - - - struct cmsghdr *CMSG_NXTHDR(const struct msghdr *mhdr, - const struct cmsghdr *cmsg); - - CMSG_NXTHDR() returns a pointer to the cmsghdr structure describing - the next ancillary data object. mhdr is a pointer to a msghdr - structure and cmsg is a pointer to a cmsghdr structure. If there is - not another ancillary data object, the return value is NULL. - - The following behavior of this macro is new to this API: if the value - of the cmsg pointer is NULL, a pointer to the cmsghdr structure - describing the first ancillary data object is returned. That is, - CMSG_NXTHDR(mhdr, NULL) is equivalent to CMSG_FIRSTHDR(mhdr). If - there are no ancillary data objects, the return value is NULL. This - provides an alternative way of coding the processing loop shown - earlier: - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 58] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - struct msghdr msg; - struct cmsghdr *cmsgptr = NULL; - - /* fill in msg */ - - /* call recvmsg() */ - - while ((cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) != NULL) { - if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) { - u_char *ptr; - - ptr = CMSG_DATA(cmsgptr); - /* process data pointed to by ptr */ - } - } - - - One possible implementation could be: - - #define CMSG_NXTHDR(mhdr, cmsg) \ - (((cmsg) == NULL) ? CMSG_FIRSTHDR(mhdr) : \ - (((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len) \ - + ALIGN_D(sizeof(struct cmsghdr)) > \ - (u_char *)((mhdr)->msg_control) + (mhdr)->msg_controllen) ? \ - (struct cmsghdr *)NULL : \ - (struct cmsghdr *)((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len)))) - - The macros ALIGN_H() and ALIGN_D(), which are implementation - dependent, round their arguments up to the next even multiple of - whatever alignment is required for the start of the cmsghdr structure - and the data, respectively. (This is probably a multiple of 4 or 8 - bytes.) They are often the same macro in implementations platforms - where alignment requirement for header and data is chosen to be - identical. - - -22.3.3. CMSG_DATA - - - unsigned char *CMSG_DATA(const struct cmsghdr *cmsg); - - CMSG_DATA() returns a pointer to the data (what is called the - cmsg_data[] member, even though such a member is not defined in the - structure) following a cmsghdr structure. - - One possible implementation could be: - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 59] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - #define CMSG_DATA(cmsg) ( (u_char *)(cmsg) + \ - ALIGN_D(sizeof(struct cmsghdr)) ) - - - -22.3.4. CMSG_SPACE - - - unsigned int CMSG_SPACE(unsigned int length); - - This macro is new with this API. Given the length of an ancillary - data object, CMSG_SPACE() returns an upper bound on the space - required by the object and its cmsghdr structure, including any - padding needed to satisfy alignment requirements. This macro can be - used, for example, when allocating space dynamically for the - ancillary data. This macro should not be used to initialize the - cmsg_len member of a cmsghdr structure; instead use the CMSG_LEN() - macro. - - One possible implementation could be: - - #define CMSG_SPACE(length) ( ALIGN_D(sizeof(struct cmsghdr)) + \ - ALIGN_H(length) ) - - - -22.3.5. CMSG_LEN - - - unsigned int CMSG_LEN(unsigned int length); - - This macro is new with this API. Given the length of an ancillary - data object, CMSG_LEN() returns the value to store in the cmsg_len - member of the cmsghdr structure, taking into account any padding - needed to satisfy alignment requirements. - - One possible implementation could be: - - #define CMSG_LEN(length) ( ALIGN_D(sizeof(struct cmsghdr)) + length ) - - Note the difference between CMSG_SPACE() and CMSG_LEN(), shown also - in the figure in Section 4.2: the former accounts for any required - padding at the end of the ancillary data object and the latter is the - actual length to store in the cmsg_len member of the ancillary data - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 60] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - object. - - -23. Appendix B: Examples using the inet6_rth_XXX() functions - - Here we show an example for both sending Routing headers and - processing and reversing a received Routing header. - - -23.1. Sending a Routing Header - - As an example of these Routing header functions defined in this - document, we go through the function calls for the example on p. 17 - of [RFC-2460]. The source is S, the destination is D, and the three - intermediate nodes are I1, I2, and I3. - - S -----> I1 -----> I2 -----> I3 -----> D - - src: * S S S S S - dst: D I1 I2 I3 D D - A[1]: I1 I2 I1 I1 I1 I1 - A[2]: I2 I3 I3 I2 I2 I2 - A[3]: I3 D D D I3 I3 - #seg: 3 3 2 1 0 3 - - src and dst are the source and destination IPv6 addresses in the IPv6 - header. A[1], A[2], and A[3] are the three addresses in the Routing - header. #seg is the Segments Left field in the Routing header. - - The six values in the column beneath node S are the values in the - Routing header specified by the sending application using sendmsg() - of setsockopt(). The function calls by the sender would look like: - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 61] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - void *extptr; - int extlen; - struct msghdr msg; - struct cmsghdr *cmsgptr; - int cmsglen; - struct sockaddr_in6 I1, I2, I3, D; - - extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3); - cmsglen = CMSG_SPACE(extlen); - cmsgptr = malloc(cmsglen); - cmsgptr->cmsg_len = CMSG_LEN(extlen); - cmsgptr->cmsg_level = IPPROTO_IPV6; - cmsgptr->cmsg_type = IPV6_RTHDR; - - optptr = CMSG_DATA(cmsgptr); - optptr = inet6_rth_init(optptr, optlen, IPV6_RTHDR_TYPE_0, 3); - - inet6_rth_add(optptr, &I1.sin6_addr); - inet6_rth_add(optptr, &I2.sin6_addr); - inet6_rth_add(optptr, &I3.sin6_addr); - - msg.msg_control = cmsgptr; - msg.msg_controllen = cmsglen; - - /* finish filling in msg{}, msg_name = D */ - /* call sendmsg() */ - - We also assume that the source address for the socket is not - specified (i.e., the asterisk in the figure). - - The four columns of six values that are then shown between the five - nodes are the values of the fields in the packet while the packet is - in transit between the two nodes. Notice that before the packet is - sent by the source node S, the source address is chosen (replacing - the asterisk), I1 becomes the destination address of the datagram, - the two addresses A[2] and A[3] are "shifted up", and D is moved to - A[3]. - - The columns of values that are shown beneath the destination node are - the values returned by recvmsg(), assuming the application has - enabled both the IPV6_RECVPKTINFO and IPV6_RECVRTHDR socket options. - The source address is S (contained in the sockaddr_in6 structure - pointed to by the msg_name member), the destination address is D - (returned as an ancillary data object in an in6_pktinfo structure), - and the ancillary data object specifying the Routing header will - contain three addresses (I1, I2, and I3). The number of segments in - the Routing header is known from the Hdr Ext Len field in the Routing - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 62] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - header (a value of 6, indicating 3 addresses). - - The return value from inet6_rth_segments() will be 3 and - inet6_rth_getaddr(0) will return I1, inet6_rth_getaddr(1) will return - I2, and inet6_rth_getaddr(2) will return I3, - - If the receiving application then calls inet6_rth_reverse(), the - order of the three addresses will become I3, I2, and I1. - - We can also show what an implementation might store in the ancillary - data object as the Routing header is being built by the sending - process. If we assume a 32-bit architecture where sizeof(struct - cmsghdr) equals 12, with a desired alignment of 4-byte boundaries, - then the call to inet6_rth_space(3) returns 68: 12 bytes for the - cmsghdr structure and 56 bytes for the Routing header (8 + 3*16). - - The call to inet6_rth_init() initializes the ancillary data object to - contain a Type 0 Routing header: - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_len = 20 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_level = IPPROTO_IPV6 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_type = IPV6_RTHDR | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=0 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The first call to inet6_rth_add() adds I1 to the list. - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 63] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_len = 36 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_level = IPPROTO_IPV6 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_type = IPV6_RTHDR | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=1 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[1] = I1 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - cmsg_len is incremented by 16, and the Segments Left field is - incremented by 1. - - The next call to inet6_rth_add() adds I2 to the list. - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 64] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_len = 52 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_level = IPPROTO_IPV6 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_type = IPV6_RTHDR | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=2 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[1] = I1 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[2] = I2 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - cmsg_len is incremented by 16, and the Segments Left field is - incremented by 1. - - The last call to inet6_rth_add() adds I3 to the list. - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 65] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_len = 68 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_level = IPPROTO_IPV6 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | cmsg_type = IPV6_RTHDR | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=3 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[1] = I1 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[2] = I2 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Address[3] = I3 + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - cmsg_len is incremented by 16, and the Segments Left field is - incremented by 1. - - -23.2. Receiving Routing Headers - - This example assumes that the application has enabled IPV6_RECVRTHDR - socket option. The application prints and reverses a source route - and uses that to echo the received data. - - struct sockaddr_in6 addr; - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 66] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - struct msghdr msg; - struct iovec iov; - struct cmsghdr *cmsgptr; - size_t cmsgspace; - void *optptr; - int optlen; - - int segments; - int i; - char databuf[8192]; - - segments = 100; /* Enough */ - optlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, segments); - cmsgspace = CMSG_SPACE(optlen); - cmsgptr = malloc(cmsgspace); - if (cmsgptr == NULL) { - perror("malloc"); - exit(1); - } - optptr = CMSG_DATA(cmsgptr); - - msg.msg_control = (char *)cmsgptr; - msg.msg_controllen = cmsgspace; - msg.msg_name = (struct sockaddr *)&addr; - msg.msg_namelen = sizeof (addr); - msg.msg_iov = &iov; - msg.msg_iovlen = 1; - iov.iov_base = databuf; - iov.iov_len = sizeof (databuf); - msg.msg_flags = 0; - if (recvmsg(s, &msg, 0) == -1) { - perror("recvmsg"); - return; - } - if (msg.msg_controllen != 0 && - cmsgptr->cmsg_level == IPPROTO_IPV6 && - cmsgptr->cmsg_type == IPV6_RTHDR) { - struct in6_addr *in6; - char asciiname[INET6_ADDRSTRLEN]; - struct ip6_rthdr0 *rthdr; - - rthdr = (struct ip6_rthdr0 *)optptr; - segments = inet6_rth_segments(optptr); - printf("route (%d segments, %d left): ", - segments, rthdr->ip6r0_segleft); - for (i = 0; i < segments; i++) { - in6 = inet6_rth_getaddr(optptr, i); - if (in6 == NULL) - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 67] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - printf(" "); - else - printf("%s ", inet_ntop(AF_INET6, - (void *)in6->s6_addr, - asciiname, INET6_ADDRSTRLEN)); - } - if (inet6_rth_reverse(optptr, optptr) == -1) { - printf("reverse failed"); - return; - } - } - iov.iov_base = databuf; - iov.iov_len = strlen(databuf); - if (sendmsg(s, &msg, 0) == -1) - perror("sendmsg"); - if (cmsgptr != NULL) - free(cmsgptr); - - Note: The above example is a simple illustration. It skips some - error checks involving the MSG_TRUNC and MSG_CTRUNC flags. - - -24. Appendix C: Examples using the inet6_opt_XXX() functions - - This shows how Hop-by-Hop and Destination options can be both built - as well as parsed using the inet6_opt_XXX() functions. This examples - assume that there are defined values for OPT_X and OPT_Y. - - -24.1. Building options - - We now provide an example that builds two Hop-by-Hop options using - the example in Appendix B of [RFC-2460]. - - void *extbuf; - size_t extlen; - int currentlen; - void *databuf; - size_t offset; - uint8_t value1; - uint16_t value2; - uint32_t value4; - uint64_t value8; - - /* Estimate the length */ - currentlen = inet6_opt_init(NULL, 0); - if (currentlen == -1) - return (-1); - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 68] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_X, 12, 8, NULL); - if (currentlen == -1) - return (-1); - currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_Y, 7, 4, NULL); - if (currentlen == -1) - return (-1); - currentlen = inet6_opt_finish(NULL, 0, currentlen); - if (currentlen == -1) - return (-1); - extlen = currentlen; - - extbuf = malloc(extlen); - if (extbuf == NULL) { - perror("malloc"); - return (-1); - } - currentlen = inet6_opt_init(extbuf, extlen); - if (currentlen == -1) - return (-1); - - currentlen = inet6_opt_append(extbuf, extlen, currentlen, - OPT_X, 12, 8, &databuf); - if (currentlen == -1) - return (-1); - /* Insert value 0x12345678 for 4-octet field */ - offset = 0; - value4 = 0x12345678; - offset = inet6_opt_set_val(databuf, offset, &value4, sizeof (value4)); - /* Insert value 0x0102030405060708 for 8-octet field */ - value8 = 0x0102030405060708; - offset = inet6_opt_set_val(databuf, offset, &value8, sizeof (value8)); - - currentlen = inet6_opt_append(extbuf, extlen, currentlen, - OPT_Y, 7, 4, &databuf); - if (currentlen == -1) - return (-1); - /* Insert value 0x01 for 1-octet field */ - offset = 0; - value1 = 0x01; - offset = inet6_opt_set_val(databuf, offset, &value1, sizeof (value1)); - /* Insert value 0x1331 for 2-octet field */ - value2 = 0x1331; - offset = inet6_opt_set_val(databuf, offset, &value2, sizeof (value2)); - /* Insert value 0x01020304 for 4-octet field */ - value4 = 0x01020304; - offset = inet6_opt_set_val(databuf, offset, &value4, sizeof (value4)); - - currentlen = inet6_opt_finish(extbuf, extlen, currentlen); - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 69] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - if (currentlen == -1) - return (-1); - /* extbuf and extlen are now completely formatted */ - - - -24.2. Parsing received options - - This example parses and prints the content of the two options in the - previous example. - - int - print_opt(void *extbuf, size_t extlen) - { - ip6_dest_t *ext; - int currentlen; - uint8_t type; - size_t len; - void *databuf; - size_t offset; - uint8_t value1; - uint16_t value2; - uint32_t value4; - uint64_t value8; - - ext = (ip6_dest_t *)extbuf; - printf("nxt %u, len %u (bytes %d)\n", ext->ip6d_nxt, - ext->ip6d_len, (ext->ip6d_len + 1) * 8); - - currentlen = 0; - while (1) { - currentlen = inet6_opt_next(extbuf, extlen, currentlen, - &type, &len, &databuf); - if (currentlen == -1) - break; - printf("Received opt %u len %u\n", - type, len); - switch (type) { - case OPT_X: - offset = 0; - offset = inet6_opt_get_val(databuf, offset, - &value4, sizeof (value4)); - printf("X 4-byte field %x\n", value4); - offset = inet6_opt_get_val(databuf, offset, - &value8, sizeof (value8)); - printf("X 8-byte field %llx\n", value8); - break; - case OPT_Y: - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 70] - - -INTERNET-DRAFT Advanced Sockets API for IPv6 Oct 22, 1999 - - - offset = 0; - offset = inet6_opt_get_val(databuf, offset, - &value1, sizeof (value1)); - printf("Y 1-byte field %x\n", value1); - offset = inet6_opt_get_val(databuf, offset, - &value2, sizeof (value2)); - printf("Y 2-byte field %x\n", value2); - offset = inet6_opt_get_val(databuf, offset, - &value4, sizeof (value4)); - printf("Y 4-byte field %x\n", value4); - break; - default: - printf("Unknown option %u\n", type); - break; - } - } - return (0); - } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-01.txt [Page 71] - - diff --git a/doc/expired/draft-schroeppel-dnsind-ecc-00.txt b/doc/expired/draft-schroeppel-dnsind-ecc-00.txt deleted file mode 100644 index 39a1639810..0000000000 --- a/doc/expired/draft-schroeppel-dnsind-ecc-00.txt +++ /dev/null @@ -1,869 +0,0 @@ -INTERNET-DRAFT ECC in the DNS -Expires April 2000 October 1999 -draft-schroeppel-dnsind-ecc-00.txt - - - - - Elliptic Curve KEYs and SIGs in the DNS - -------- ----- ---- --- ---- -- --- --- - - Richard C. Schroeppel - Donald Eastlake 3rd - - -Status of This Document - - This draft, file name draft-schroeppel-dnsind-ecc-00.txt, is intended - to be become a Proposed Standard RFC. Distribution of this document - is unlimited. Comments should be sent to the DNS mailing list - or to the authors. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - -Abstract - - A standard method for storing elliptic curve cryptographic keys and - signatures in the Domain Name System is described which utilizes DNS - KEY and SIG resource records. - - - - - - - - - -R. Schroeppel, et al [Page 1] - - -INTERNET-DRAFT ECC in the DNS - - -Acknowledgement - - The assistance of Hilarie K. Orman in the production of this document - is greatfully acknowledged. - - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Acknowledgement............................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. Elliptic Curve KEY Resource Records.....................3 - 3. The Elliptic Curve Equation.............................9 - 4. How do I Compute Q, G, and Y?..........................10 - 5. Elliptic Curve SIG Resource Records....................11 - 6. Performance Considerations.............................13 - 7. Security Considerations................................13 - 8. IANA Considerations....................................13 - - References................................................14 - - Authors' Addresses........................................15 - Expiration and File Name..................................15 - - - - - - - - - - - - - - - - - - - - - - - - -R. Schroeppel, et al [Page 2] - - -INTERNET-DRAFT ECC in the DNS - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information. The DNS has been extended to include digital - signatures and cryptographic keys as described in [RFC 2535]. Thus - the DNS can now be secured and used for secure key distribution. - - Elliptic curve keys can be used for signatures, as shown herein, and - also for key agreement and encryption. This document describes how to - store elliptic curve cryptographic (ECC) keys and signatures in the - DNS. Familiarity with ECC cryptography is assumed [Menezes]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - - - -2. Elliptic Curve KEY Resource Records - - Elliptic curve public keys are stored in the DNS as KEY RRs using - algorithm number 4 (see [RFC 2535]). The structure of the RDATA - portion of this RR is as shown below. The first 4 octets, including - the flags, protocol, and algorithm fields are common to all KEY RRs. - The remainder is the "public key" part of the KEY RR. - - The period of key validity is not in the KEY RR but is indicated by - the SIG RR(s) which signs and authenticates the KEY RR(s) at that - domain name and class. - - The research world continues to churn on the issue of which is the - best elliptic curve system, which finite field to use, and how to - best represent elements in the field. - - We have defined representations for every type of finite field, and - every type of elliptic curve. The reader should be aware that there - is a unique finite field with a particular number of elements, but - many possible representations of that field and its elements. If two - different representations of a field are given, they are - interconvertible with a tedious but practical precomputation, - followed by a fast computation for each field element to be - converted. It is perfectly reasonable for an algorithm to work - internally with one field representation, and convert to and from a - different external representation. - - - - - - - -R. Schroeppel, et al [Page 3] - - -INTERNET-DRAFT ECC in the DNS - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | KEY flags | protocol | algorithm=4 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |S M -FMT- A B Z| - +-+-+-+-+-+-+-+-+ - | LP | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | P (length determined from LP) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LF | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | F (length determined from LF) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEG | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEGH | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEGI | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEGJ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TRDV | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |S| LH | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | H (length determined from LH) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |S| LK | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | K (length determined from LK) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Q (length determined from LQ) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LA | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | A (length determined from LA) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ALTA | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LB | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | B (length determined from LB) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | C (length determined from LC) .../ - - -R. Schroeppel, et al [Page 4] - - -INTERNET-DRAFT ECC in the DNS - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LG | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | G (length determined from LG) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LY | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Y (length determined from LY) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - SMFMTABZ is a flags octet as follows: - - S = 1 indicates that the remaining 7 bits of the octet selects - one of 128 predefined choices of finite field, element - representation, elliptic curve, and signature parameters. - MFMTABZ are omitted, as are all parameters from LP through G. - LY and Y are retained. - - If S = 0, the remaining parameters are as in the picture and - described below. - - M determines the type of field underlying the elliptic curve. - - M = 0 if the field is a GF[2^N] field; - - M = 1 if the field is a (mod P) or GF[P^D] field with P>2. - - FMT is a three bit field describing the format of the field - representation. - - FMT = 0 for a (mod P) field. - > 0 for an extension field, either GF[2^D] or GF[P^D]. - The degree D of the extension, and the field polynomial - must be specified. The field polynomial is always monic - (leading coefficient 1.) - - FMT = 1 The field polynomial is given explicitly; D is implied. - - If FMT >=2, the degree D is given explicitly. - - = 2 The field polynomial is implicit. - = 3 The field polynomial is a binomial. P>2. - = 4 The field polynomial is a trinomial. - = 5 The field polynomial is the quotient of a trinomial by a - short polynomial. P=2. - = 6 The field polynomial is a pentanomial. P=2. - - Flags A and B apply to the elliptic curve parameters. - - - - -R. Schroeppel, et al [Page 5] - - -INTERNET-DRAFT ECC in the DNS - - - A = 1 When P>=5, the curve parameter A is negated. If P=2, then - A=1 indicates that the A parameter is special. See the - ALTA parameter below, following A. The combination A=1, - P=3 is forbidden. - - B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, - then B=1 indicates an alternate elliptic curve equation is - used. When P=2 and B=1, an additional curve parameter C - is present. - - The Z bit SHOULD be set to zero on creation of KEY RR and MUST - be ignored when processing a KEY RR (when S=0). - - Most of the remaining parameters are present in some formats and - absent in others. The presence or absence of a parameter is - determined entirely by the flags. When a parameter occurs, it is in - the order defined by the picture. - - Of the remaining parameters, PFHKQABCGY are variable length. When - present, each is preceded by a one-octet length field as shown in the - diagram above. The length field does not include itself. The length - field may have values from 0 through 110. The parameter length in - octets is determined by a conditional formula: If LL<=64, the - parameter length is LL. If LL>64, the parameter length is 16 times - (LL-60). In some cases, a parameter value of 0 is sensible, and MAY - be represented by an LL value of 0, with the data field omitted. A - length value of 0 represents a parameter value of 0, not an absent - parameter. (The data portion occupies 0 space.) There is no - requirement that a parameter be represented in the minimum number of - octets; high-order 0 octets are allowed at the front end. Parameters - are always right adjusted, in a field of length defined by LL. The - octet-order is always most-significant first, least-significant last. - The parameters H and K may have an optional sign bit stored in the - unused high-order bit of their length fields. - - LP defines the length of the prime P. P must be an odd prime. The - parameters LP,P are present if and only if the flag M=1. If M=0, the - prime is 2. - - LF,F define an explicit field polynomial. This parameter pair is - present only when FMT = 1. The length of a polynomial coefficient is - ceiling(log2 P) bits. Coefficients are in the numerical range [0,P- - 1]. The coefficients are packed into fixed-width fields, from higher - order to lower order. All coefficients must be present, including - any 0s and also the leading coefficient (which is required to be 1). - The coefficients are right justified into the octet string of length - specified by LF, with the low-order "constant" coefficient at the - right end. As a concession to storage efficiency, the higher order - bits of the leading coefficient may be elided, discarding high-order - 0 octets and reducing LF. The degree is calculated by determining - - -R. Schroeppel, et al [Page 6] - - -INTERNET-DRAFT ECC in the DNS - - - the bit position of the left most 1-bit in the F data (counting the - right most bit as position 0), and dividing by ceiling(log2 P). The - division must be exact, with no remainder. In this format, all of - the other degree and field parameters are omitted. The next - parameters will be LQ,Q. - - If FMT>=2, the degree of the field extension is specified explicitly, - usually along with other parameters to define the field polynomial. - - DEG is a two octet field that defines the degree of the field - extension. The finite field will have P^DEG elements. DEG is - present when FMT>=2. - - When FMT=2, the field polynomial is specified implicitly. No other - parameters are required to define the field; the next parameters - present will be the LQ,Q pair. The implicit field poynomial is the - lexicographically smallest irreducible (mod P) polynomial of the - correct degree. The ordering of polynomials is by highest-degree - coefficients first -- the leading coefficient 1 is most important, - and the constant term is least important. Coefficients are ordered - by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial - of degree D is X^D (which is not irreducible). The next is X^D+1, - which is sometimes irreducible, followed by X^D-1, which isn't. - Assuming odd P, this series continues to X^D - (P-1)/2, and then goes - to X^D + X, X^D + X + 1, X^D + X - 1, etc. - - When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be - odd. The polynomial is determined by the degree and the low order - term K. Of all the field parameters, only the LK,K parameters are - present. The high-order bit of the LK octet stores on optional sign - for K; if the sign bit is present, the field polynomial is X^DEG - K. - - When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + - K. When P=2, the H and K parameters are implicitly 1, and are - omitted from the representation. Only DEG and DEGH are present; the - next parameters are LQ,Q. When P>2, then LH,H and LK,K are - specified. Either or both of LH, LK may contain a sign bit for its - parameter. - - When FMT=5, then P=2 (only). The field polynomial is the exact - quotient of a trinomial divided by a small polynomial, the trinomial - divisor. The small polynomial is right-adjusted in the two octet - field TRDV. DEG specifies the degree of the field. The degree of - TRDV is calculated from the position of the high-order 1 bit. The - trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If - DEGH is 0, the middle term is omitted from the trinomial. The - quotient must be exact, with no remainder. - - When FMT=6, then P=2 (only). The field polynomial is a pentanomial, - with the degrees of the middle terms given by the three 2-octet - - -R. Schroeppel, et al [Page 7] - - -INTERNET-DRAFT ECC in the DNS - - - values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + - X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI - > DEGJ > 0. - - DEGH, DEGI, DEGJ are two-octet fields that define the degree of - a term in a field polynomial. DEGH is present when FMT = 4, - 5, or 6. DEGI and DEGJ are present only when FMT = 6. - - TRDV is a two-octet right-adjusted binary polynomial of degree < - 16. It is present only for FMT=5. - - LH and H define the H parameter, present only when FMT=4 and P - is odd. The high bit of LH is an optional sign bit for H. - - LK and K define the K parameter, present when FMT = 3 or 4, and - P is odd. The high bit of LK is an optional sign bit for K. - - The remaining parameters are concerned with the elliptic curve and - the signature algorithm. - - LQ defines the length of the prime Q. Q is a prime > 2^159. - - In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data - member of the pair is an element from the finite field defined - earlier. The length field defines a long octet string. Field - elements are represented as (mod P) polynomials of degree < DEG, with - DEG or fewer coefficients. The coefficients are stored from left to - right, higher degree to lower, with the constant term last. The - coefficients are represented as integers in the range [0,P-1]. Each - coefficient is allocated an area of ceiling(log2 P) bits. The field - representation is right-justified; the "constant term" of the field - element ends at the right most bit. The coefficients are fitted - adjacently without regard for octet boundaries. (Example: if P=5, - three bits are used for each coefficient. If the field is GF[5^75], - then 225 bits are required for the coefficients, and as many as 29 - octets may be needed in the data area. Fewer octets may be used if - some high-order coefficients are 0.) If a flag requires a field - element to be negated, each non-zero coefficient K is replaced with - P-K. To save space, 0 bits may be removed from the left end of the - element representation, and the length field reduced appropriately. - This would normally only happen with A,B,C, because the designer - chose curve parameters with some high-order 0 coefficients or bits. - - If the finite field is simply (mod P), then the field elements are - simply numbers (mod P), in the usual right-justified notation. If - the finite field is GF[2^D], the field elements are the usual right- - justified polynomial basis representation. - - - - - -R. Schroeppel, et al [Page 8] - - -INTERNET-DRAFT ECC in the DNS - - - LA,A is the first parameter of the elliptic curve equation. - When P>=5, the flag A = 1 indicates A should be negated (mod - P). When P=2 (indicated by the flag M=0), the flag A = 1 - indicates that the parameter pair LA,A is replaced by the two - octet parameter ALTA. In this case, the parameter A in the - curve equation is x^ALTA, where x is the field generator. - Parameter A often has the value 0, which may be indicated by - LA=0 (with no A data field), and sometimes A is 1, which may - be represented with LA=1 and a data field of 1, or by setting - the A flag and using an ALTA value of 0. - - LB,B is the second parameter of the elliptic curve equation. - When P>=5, the flag B = 1 indicates B should be negated (mod - P). When P=2 or 3, the flag B selects an alternate curve - equation. - - LC,C is the third parameter of the elliptic curve equation, - present only when P=2 (indicated by flag M=0) and flag B=1. - - LG,G defines a point on the curve, of order Q. The W-coordinate - of the curve point is given explicitly; the Z-coordinate is - implicit. - - LY,Y is the user's public signing key, another curve point of - order Q. The W-coordinate is given explicitly; the Z- - coordinate is implicit. The LY,Y parameter pair is always - present. - - - -3. The Elliptic Curve Equation - - (The coordinates of an elliptic curve point are named W,Z instead of - the more usual X,Y to avoid confusion with the Y parameter of the - signing key.) - - The elliptic curve equation is determined by the flag octet, together - with information about the prime P. The primes 2 and 3 are special; - all other primes are treated identically. - - If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 - + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. - If A and/or B is negative (i.e., in the range from P/2 to P), and - P>=5, space may be saved by putting the sign bit(s) in the A and B - bits of the flags octet, and the magnitude(s) in the parameter - fields. - - If M=1 and P=3, the B flag has a different meaning: it specifies an - alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of - the right-hand-side is different. When P=3, this equation is more - - -R. Schroeppel, et al [Page 9] - - -INTERNET-DRAFT ECC in the DNS - - - commonly used. - - If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + - A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A - parameter can often be 0 or 1, or be chosen as a single-1-bit value. - The flag B is used to select an alternate curve equation, Z^2 + C*Z = - W^3 + A*W + B. This is the only time that the C parameter is used. - - - -4. How do I Compute Q, G, and Y? - - The number of points on the curve is the number of solutions to the - curve equation, + 1 (for the "point at infinity"). The prime Q must - divide the number of points. Usually the curve is chosen first, then - the number of points is determined with Schoof's algorithm. This - number is factored, and if it has a large prime divisor, that number - is taken as Q. - - G must be a point of order Q on the curve, satisfying the equation - - Q * G = the point at infinity (on the elliptic curve) - - G may be chosen by selecting a random [RFC 1750] curve point, and - multiplying it by (number-of-points-on-curve/Q). G must not itself - be the "point at infinity"; in this astronomically unlikely event, a - new random curve point is recalculated. - - G is specified by giving its W-coordinate. The Z-coordinate is - calculated from the curve equation. In general, there will be two - possible Z values. The rule is to choose the "positive" value. - - In the (mod P) case, the two possible Z values sum to P. The smaller - value is less than P/2; it is used in subsequent calculations. In - GF[P^D] fields, the highest-degree non-zero coefficient of the field - element Z is used; it is chosen to be less than P/2. - - In the GF[2^N] case, the two possible Z values xor to W (or to the - parameter C with the alternate curve equation). The numerically - smaller Z value (the one which does not contain the highest-order 1 - bit of W (or C)) is used in subsequent calculations. - - Y is specified by giving the W-coordinate of the user's public - signature key. The Z-coordinate value is determined from the curve - equation. As with G, there are two possible Z values; the same rule - is followed for choosing which Z to use. - - - - - - -R. Schroeppel, et al [Page 10] - - -INTERNET-DRAFT ECC in the DNS - - - During the key generation process, a random [RFC 1750] number X must - be generated such that 1 <= X <= Q-1. X is the private key and is - used in the final step of public key generation where Y is computed - as - - Y = X * G (as points on the elliptic curve) - - If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 - in the (mod P) case, or the high-order non-zero coefficient of Z > - P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the - GF[2^N] case), then X must be replaced with Q-X. This will - correspond to the correct Z-coordinate. - - - -5. Elliptic Curve SIG Resource Records - - The signature portion of the SIG RR RDATA area, when using the EC - algorithm, is shown below. See [RFC 2535] for fields in the SIG RR - RDATA which precede the signature itself. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | R, (length determined from LQ) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | S, (length determined from LQ) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - R and S are integers (mod Q). Their length is specified by the LQ - field of the corresponding KEY RR and can also be calculated from the - SIG RR's RDLENGTH. They are right justified, high-order-octet first. - The same conditional formula for calculating the length from LQ is - used as for all the other length fields above. - - The data signed is determined as specified in [RFC 2535]. Then the - following steps are taken where Q, P, G, and Y are as specified in - the public key [Schneier]: - - hash = SHA-1 ( data ) - - Generate random [RFC 1750] K such that 0 < K < Q. (Never sign - two different messages with the same K. K should be chosen - from a very large space: If an opponent learns a K value for - a single signature, the user's signing key is compromised, - and a forger can sign arbitrary messages. There is no harm - in signing the same message multiple times with the same key - or different keys.) - - - - -R. Schroeppel, et al [Page 11] - - -INTERNET-DRAFT ECC in the DNS - - - R = (the W-coordinate of ( K*G on the elliptic curve )) - interpreted as an integer, and reduced (mod Q). (R must not - be 0. In this astronomically unlikely event, generate a new - random K and recalculate R.) - - S = ( K^(-1) * (hash + X*R) ) mod Q. - - S must not be 0. In this astronomically unlikely event, - generate a new random K and recalculate R and S. - - If S > Q/2, set S = Q - S. - - The pair (R,S) is the signature. - - Another party verifies the signature as follows: - - Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a - valid EC sigature. - - hash = SHA-1 ( data ) - - Sinv = S^(-1) mod Q. - - - U1 = (hash * Sinv) mod Q. - - U2 = (R * Sinv) mod Q. - - (U1 * G + U2 * Y) is computed on the elliptic curve. - - V = (the W-coordinate of this point) interpreted as an integer - and reduced (mod Q). - - The signature is valid if V = R. - - The reason for requiring S < Q/2 is that, otherwise, both (R,S) and - (R,Q-S) would be valid signatures for the same data. Note that a - signature that is valid for hash(data) is also valid for hash(data)+Q - or hash(data)-Q, if these happen to fall in the range [0,2^160-1]. - It's believed to be computationally infeasible to find data that - hashes to an assigned value, so this is only a cosmetic blemish. The - blemish can be eliminated by using Q > 2^160, at the cost of having - slightly longer signatures, 42 octets instead of 40. - - We must specify how a field-element E ("the W-coordinate") is to be - interpreted as an integer. The field-element E is regarded as a - radix-P integer, with the digits being the coefficients in the - polynomial basis representation of E. The digits are in the ragne - [0,P-1]. In the two most common cases, this reduces to "the obvious - thing". In the (mod P) case, E is simply a residue mod P, and is - - -R. Schroeppel, et al [Page 12] - - -INTERNET-DRAFT ECC in the DNS - - - taken as an integer in the range [0,P-1]. In the GF[2^D] case, E is - in the D-bit polynomial basis representation, and is simply taken as - an integer in the range [0,(2^D)-1]. For other fields GF[P^D], it's - necessary to do some radix conversion arithmetic. - - - -6. Performance Considerations - - Elliptic curve signatures use smaller moduli or field sizes than RSA - and DSA, so signature generation is significantly faster. Creation - of a curve is slow, but not done very often. Key generation is - faster than RSA or DSA. Signature verification is faster than DSA, - but slower than RSA. - - Current DNS implementations are optimized for small transfers, - typically less than 512 octets including DNS overhead. While larger - transfers will perform correctly and work is underway to make larger - transfers more efficient, it is still advisable at this time to make - reasonable efforts to minimize the size of KEY RR sets stored within - the DNS consistent with adequate security. Keep in mind that in a - secure zone, an authenticating SIG RR will also be returned. - - - -7. Security Considerations - - Many of the general security consideration in [RFC 2535] apply. Some - specific key generation considerations are given above. Of course, - the elliptic curve key stored in the DNS for an entity should not be - trusted unless it has been obtain via a trusted DNS resolver that - vouches for its security or unless the application using the key has - done a similar authentication. - - - -8. IANA Considerations - - Assignment of meaning to the remaining ECC KEY flag bit or to values - of fields outside the ranges for which meaning in defined in this - document requires an IETF consensus as defined in [RFC 2434]. - - - - - - - - - - - -R. Schroeppel, et al [Page 13] - - -INTERNET-DRAFT ECC in the DNS - - -References - - [RFC 1034] - P. Mockapetris, "Domain names - concepts and - facilities", 11/01/1987. - - [RFC 1035] - P. Mockapetris, "Domain names - implementation and - specification", 11/01/1987. - - [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness - Recommendations for Security", 12/29/1994. - - [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", March 1997. - - [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", October 1998. - - [RFC 2535] - D. Eastlake,"Domain Name System Security Extensions", - March 1999. - - [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C", 1996, John Wiley and Sons - - [Menezes] - Alfred Menezes, "Elliptic Curve Public Key - Cryptosystems", 1993 Kluwer. - - [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", - 1986, Springer Graduate Texts in mathematics #106. - - - - - - - - - - - - - - - - - - - - - - - - -R. Schroeppel, et al [Page 14] - - -INTERNET-DRAFT ECC in the DNS - - -Authors' Addresses - - Rich Schroeppel - 500 S. Maple Drive - Woodland Hills, Utah 84653 USA - - Telephone: 1-801-423-7998(h) - 1-505-844-9079(w) - Email: rcs@cs.arizona.edu - rschroe@sandia.gov - - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road - Carmel, NY 10512 USA - - Telephone: +1 914-276-2668(h) - +1 914-784-7913(w) - FAX: +1 914-784-3833(w) - EMail: dee3@us.ibm.com - - - -Expiration and File Name - - This draft expires in April 2000. - - Its file name is draft-schroeppel-dnsind-ecc-00.txt. - - - - - - - - - - - - - - - - - - - - - - - -R. Schroeppel, et al [Page 15] - diff --git a/doc/rfc/fetch b/doc/rfc/fetch deleted file mode 100755 index 17ce40fe85..0000000000 --- a/doc/rfc/fetch +++ /dev/null @@ -1,6 +0,0 @@ -#!/bin/sh -f -for i in $* -do - i=`echo $i | sed -e 's/^rfc//' -e 's/\.txt$//'` - fetch "http://www.ietf.org/rfc/rfc${i}.txt" -done diff --git a/doc/rfc/index b/doc/rfc/index deleted file mode 100644 index e02b2bd18a..0000000000 --- a/doc/rfc/index +++ /dev/null @@ -1,170 +0,0 @@ - 952: DOD INTERNET HOST TABLE SPECIFICATION -1032: DOMAIN ADMINISTRATORS GUIDE -1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE -1034: DOMAIN NAMES - CONCEPTS AND FACILITIES -1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION -1101: DNS Encoding of Network Names and Other Types -1122: Requirements for Internet Hosts -- Communication Layers -1123: Requirements for Internet Hosts -- Application and Support -1183: New DNS RR Definitions (AFSDB, RP, X25, ISDN and RT) -1348: DNS NSAP RRs -1535: A Security Problem and Proposed Correction - With Widely Deployed DNS Software -1536: Common DNS Implementation Errors and Suggested Fixes -1537: Common DNS Data File Configuration Errors -1591: Domain Name System Structure and Delegation -1611: DNS Server MIB Extensions -1612: DNS Resolver MIB Extensions -1706: DNS NSAP Resource Records -1712: DNS Encoding of Geographical Location -1750: Randomness Recommendations for Security -1876: A Means for Expressing Location Information in the Domain Name System -1886: DNS Extensions to support IP version 6 -1912: Common DNS Operational and Configuration Errors -1982: Serial Number Arithmetic -1995: Incremental Zone Transfer in DNS -1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) -2052: A DNS RR for specifying the location of services (DNS SRV) -2104: HMAC: Keyed-Hashing for Message Authentication -2119: Key words for use in RFCs to Indicate Requirement Levels -2133: Basic Socket Interface Extensions for IPv6 -2136: Dynamic Updates in the Domain Name System (DNS UPDATE) -2137: Secure Domain Name System Dynamic Update -2163: Using the Internet DNS to Distribute MIXER - Conformant Global Address Mapping (MCGAM) -2168: Resolution of Uniform Resource Identifiers using the Domain Name System -2181: Clarifications to the DNS Specification -2230: Key Exchange Delegation Record for the DNS -2308: Negative Caching of DNS Queries (DNS NCACHE) -2317: Classless IN-ADDR.ARPA delegation -2373: IP Version 6 Addressing Architecture -2374: An IPv6 Aggregatable Global Unicast Address Format -2375: IPv6 Multicast Address Assignments -2418: IETF Working Group Guidelines and Procedures -2535: Domain Name System Security Extensions -2536: DSA KEYs and SIGs in the Domain Name System (DNS) -2537: RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) -2538: Storing Certificates in the Domain Name System (DNS) -2539: Storage of Diffie-Hellman Keys in the Domain Name System (DNS) -2540: Detached Domain Name System (DNS) Information -2541: DNS Security Operational Considerations -2553: Basic Socket Interface Extensions for IPv6 -2671: Extension Mechanisms for DNS (EDNS0) -2672: Non-Terminal DNS Name Redirection -2673: Binary Labels in the Domain Name System -2782: A DNS RR for specifying the location of services (DNS SRV) -2825: A Tangled Web: Issues of I18N, Domain Names, and the - Other Internet protocols -2826: IAB Technical Comment on the Unique DNS Root -2845: Secret Key Transaction Authentication for DNS (TSIG) -2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering -2915: The Naming Authority Pointer (NAPTR) DNS Resource Record -2929: Domain Name System (DNS) IANA Considerations -2930: Secret Key Establishment for DNS (TKEY RR) -2931: DNS Request and Transaction Signatures ( SIG(0)s ) -3007: Secure Domain Name System (DNS) Dynamic Update -3008: Domain Name System Security (DNSSEC) Signing Authority -3056: Connection of IPv6 Domains via IPv4 Clouds -3071: Reflections on the DNS, RFC 1591, and Categories of Domains -3090: DNS Security Extension Clarification on Zone Status -3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) -3123: A DNS RR Type for Lists of Address Prefixes (APL RR) -3152: Delegation of IP6.ARPA -3197: Applicability Statement for DNS MIB Extensions -3225: Indicating Resolver Support of DNSSEC -3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements -3258: Distributing Authoritative Name Servers via Shared Unicast Addresses -3363: Representing Internet Protocol version 6 (IPv6) - Addresses in the Domain Name System (DNS) -3364: Tradeoffs in Domain Name System (DNS) Support - for Internet Protocol version 6 (IPv6) -3425: Obsoleting IQUERY -3445: Limiting the Scope of the KEY Resource Record (RR) -3467: Role of the Domain Name System (DNS) -3490: Internationalizing Domain Names In Applications (IDNA) -3491: Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) -3492: Punycode:A Bootstring encoding of Unicode for - Internationalized Domain Names in Applications (IDNA) -3493: Basic Socket Interface Extensions for IPv6 -3513: Internet Protocol Version 6 (IPv6) Addressing Architecture -3596: DNS Extensions to Support IP Version 6 -3597: Handling of Unknown DNS Resource Record (RR) Types -3645: Generic Security Service Algorithm for - Secret Key Transaction Authentication for DNS (GSS-TSIG) -3655: Redefinition of DNS Authenticated Data (AD) bit -3658: Delegation Signer (DS) Resource Record (RR) -3755: Legacy Resolver Compatibility for Delegation Signer (DS) -3757: Domain Name System KEY (DNSKEY) Resource Record (RR) - Secure Entry Point (SEP) Flag -3833: Threat Analysis of the Domain Name System (DNS) -3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format -3901: DNS IPv6 Transport Operational Guidelines -4025: A Method for Storing IPsec Keying Material in DNS -4033: DNS Security Introduction and Requirements -4034: Resource Records for the DNS Security Extensions -4035: Protocol Modifications for the DNS Security Extensions -4074: Common Misbehavior Against DNS Queries for IPv6 Addresses -4159: Deprecation of "ip6.int" -4193: Unique Local IPv6 Unicast Addresses -4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints -4294: IPv6 Node Requirements -4339: IPv6 Host Configuration of DNS Server Information Approaches -4343: Domain Name System (DNS) Case Insensitivity Clarification -4367: What's in a Name: False Assumptions about DNS Names -4398: Storing Certificates in the Domain Name System (DNS) -4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record -4408: Sender Policy Framework (SPF) for Authorizing Use of Domains - in E-Mail, Version 1 -4470: Minimally Covering NSEC Records and DNSSEC On-line Signing -4471: Derivation of DNS Name Predecessor and Successor -4472: Operational Considerations and Issues with IPv6 DNS -4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) -4634: US Secure Hash Algorithms (SHA and HMAC-SHA) -4635: HMAC SHA TSIG Algorithm Identifiers -4641: DNSSEC Operational Practices -4648: The Base16, Base32, and Base64 Data Encodings -4697: Observed DNS Resolution Misbehavior -4701: A DNS Resource Record (RR) for Encoding - Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) -4892: Requirements for a Mechanism Identifying a Name Server Instance -4955: DNS Security (DNSSEC) Experiments -4956: DNS Security (DNSSEC) Opt-In -5001: DNS Name Server Identifier (NSID) Option -5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors -5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence -5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extension -5395: Domain Name System (DNS) IANA Considerations -5452: Measures for Making DNS More Resilient against Forged Answers -5507: Design Choices When Expanding the DNS -5625: DNS Proxy Implementation Guidelines -5702: Use of SHA-2 Algorithms with RSA in - DNSKEY and RRSIG Resource Records for DNSSEC -5933: Use of GOST Signature Algorithms in DNSKEY - and RRSIG Resource Records for DNSSEC -5936: DNS Zone Transfer Protocol (AXFR) -5952: A Recommendation for IPv6 Address Text Representation -5966: DNS Transport over TCP - Implementation Requirements -6052: IPv6 Addressing of IPv4/IPv6 Translators -6147: DNS64: DNS Extensions for Network Address Translation - from IPv6 Clients to IPv4 Servers -6168: Requirements for Management of Name Servers for the DNS -6303: Locally Served DNS Zones -6605: Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC -6672: DNAME Redirection in the DNS -6698: The DNS-Based Authentication of Named Entities (DANE) - Transport Layer Security (TLS) Protocol: TLSA -6742: DNS Resource Records for the - Identifier-Locator Network Protocol (ILNP) -6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) -6844: DNS Certification Authority Authorization (CAA) Resource Record -6891: Extension Mechanisms for DNS (EDNS(0)) -7043: Resource Records for EUI-48 and EUI-64 Addresses in the DNS -7314: Extension Mechanisms for DNS (EDNS) EXPIRE Option -7534: AS112 Nameserver Operations -7477: Child-to-Parent Synchronization in DNS -7535: AS112 Redirection Using DNAME -7793: Adding 100.64.0.0/10 Prefixes to the - IPv4 Locally-Served DNS Zones Registry -7830: The EDNS(0) Padding Option -7873: Domain Name System (DNS) Cookies -8020: NXDOMAIN: There Really Is Nothing Underneath diff --git a/doc/rfc/rfc1032.txt b/doc/rfc/rfc1032.txt deleted file mode 100644 index 0e82721cee..0000000000 --- a/doc/rfc/rfc1032.txt +++ /dev/null @@ -1,781 +0,0 @@ -Network Working Group M. Stahl -Request for Comments: 1032 SRI International - November 1987 - - - DOMAIN ADMINISTRATORS GUIDE - - -STATUS OF THIS MEMO - - This memo describes procedures for registering a domain with the - Network Information Center (NIC) of Defense Data Network (DDN), and - offers guidelines on the establishment and administration of a domain - in accordance with the requirements specified in RFC-920. It is - intended for use by domain administrators. This memo should be used - in conjunction with RFC-920, which is an official policy statement of - the Internet Activities Board (IAB) and the Defense Advanced Research - Projects Agency (DARPA). Distribution of this memo is unlimited. - -BACKGROUND - - Domains are administrative entities that provide decentralized - management of host naming and addressing. The domain-naming system - is distributed and hierarchical. - - The NIC is designated by the Defense Communications Agency (DCA) to - provide registry services for the domain-naming system on the DDN and - DARPA portions of the Internet. - - As registrar of top-level and second-level domains, as well as - administrator of the root domain name servers on behalf of DARPA and - DDN, the NIC is responsible for maintaining the root server zone - files and their binary equivalents. In addition, the NIC is - responsible for administering the top-level domains of "ARPA," "COM," - "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it - becomes feasible for other appropriate organizations to assume those - responsibilities. - - It is recommended that the guidelines described in this document be - used by domain administrators in the establishment and control of - second-level domains. - -THE DOMAIN ADMINISTRATOR - - The role of the domain administrator (DA) is that of coordinator, - manager, and technician. If his domain is established at the second - level or lower in the tree, the DA must register by interacting with - the management of the domain directly above his, making certain that - - - -Stahl [Page 1] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - his domain satisfies all the requirements of the administration under - which his domain would be situated. To find out who has authority - over the name space he wishes to join, the DA can ask the NIC - Hostmaster. Information on contacts for the top-level and second- - level domains can also be found on line in the file NETINFO:DOMAIN- - CONTACTS.TXT, which is available from the NIC via anonymous FTP. - - The DA should be technically competent; he should understand the - concepts and procedures for operating a domain server, as described - in RFC-1034, and make sure that the service provided is reliable and - uninterrupted. It is his responsibility or that of his delegate to - ensure that the data will be current at all times. As a manager, the - DA must be able to handle complaints about service provided by his - domain name server. He must be aware of the behavior of the hosts in - his domain, and take prompt action on reports of problems, such as - protocol violations or other serious misbehavior. The administrator - of a domain must be a responsible person who has the authority to - either enforce these actions himself or delegate them to someone - else. - - Name assignments within a domain are controlled by the DA, who should - verify that names are unique within his domain and that they conform - to standard naming conventions. He furnishes access to names and - name-related information to users both inside and outside his domain. - He should work closely with the personnel he has designated as the - "technical and zone" contacts for his domain, for many administrative - decisions will be made on the basis of input from these people. - -THE DOMAIN TECHNICAL AND ZONE CONTACT - - A zone consists of those contiguous parts of the domain tree for - which a domain server has complete information and over which it has - authority. A domain server may be authoritative for more than one - zone. The domain technical/zone contact is the person who tends to - the technical aspects of maintaining the domain's name server and - resolver software, and database files. He keeps the name server - running, and interacts with technical people in other domains and - zones to solve problems that affect his zone. - -POLICIES - - Domain or host name choices and the allocation of domain name space - are considered to be local matters. In the event of conflicts, it is - the policy of the NIC not to get involved in local disputes or in the - local decision-making process. The NIC will not act as referee in - disputes over such matters as who has the "right" to register a - particular top-level or second-level domain for an organization. The - NIC considers this a private local matter that must be settled among - - - -Stahl [Page 2] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - the parties involved prior to their commencing the registration - process with the NIC. Therefore, it is assumed that the responsible - person for a domain will have resolved any local conflicts among the - members of his domain before registering that domain with the NIC. - The NIC will give guidance, if requested, by answering specific - technical questions, but will not provide arbitration in disputes at - the local level. This policy is also in keeping with the distributed - hierarchical nature of the domain-naming system in that it helps to - distribute the tasks of solving problems and handling questions. - - Naming conventions for hosts should follow the rules specified in - RFC-952. From a technical standpoint, domain names can be very long. - Each segment of a domain name may contain up to 64 characters, but - the NIC strongly advises DAs to choose names that are 12 characters - or fewer, because behind every domain system there is a human being - who must keep track of the names, addresses, contacts, and other data - in a database. The longer the name, the more likely the data - maintainer is to make a mistake. Users also will appreciate shorter - names. Most people agree that short names are easier to remember and - type; most domain names registered so far are 12 characters or fewer. - - Domain name assignments are made on a first-come-first-served basis. - The NIC has chosen not to register individual hosts directly under - the top-level domains it administers. One advantage of the domain - naming system is that administration and data maintenance can be - delegated down a hierarchical tree. Registration of hosts at the - same level in the tree as a second-level domain would dilute the - usefulness of this feature. In addition, the administrator of a - domain is responsible for the actions of hosts within his domain. We - would not want to find ourselves in the awkward position of policing - the actions of individual hosts. Rather, the subdomains registered - under these top-level domains retain the responsibility for this - function. - - Countries that wish to be registered as top-level domains are - required to name themselves after the two-letter country code listed - in the international standard ISO-3166. In some cases, however, the - two-letter ISO country code is identical to a state code used by the - U.S. Postal Service. Requests made by countries to use the three- - letter form of country code specified in the ISO-3166 standard will - be considered in such cases so as to prevent possible conflicts and - confusion. - - - - - - - - - -Stahl [Page 3] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - -HOW TO REGISTER - - Obtain a domain questionnaire from the NIC hostmaster, or FTP the - file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA. - - Fill out the questionnaire completely. Return it via electronic mail - to HOSTMASTER@SRI-NIC.ARPA. - - The APPENDIX to this memo contains the application form for - registering a top-level or second-level domain with the NIC. It - supersedes the version of the questionnaire found in RFC-920. The - application should be submitted by the person administratively - responsible for the domain, and must be filled out completely before - the NIC will authorize establishment of a top-level or second-level - domain. The DA is responsible for keeping his domain's data current - with the NIC or with the registration agent with which his domain is - registered. For example, the CSNET and UUCP managements act as - domain filters, processing domain applications for their own - organizations. They pass pertinent information along periodically to - the NIC for incorporation into the domain database and root server - files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT - outlines this procedure. It is highly recommended that the DA review - this information periodically and provide any corrections or - additions. Corrections should be submitted via electronic mail. - -WHICH DOMAIN NAME? - - The designers of the domain-naming system initiated several general - categories of names as top-level domain names, so that each could - accommodate a variety of organizations. The current top-level - domains registered with the DDN Network Information Center are ARPA, - COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country - domains. To join one of these, a DA needs to be aware of the purpose - for which it was intended. - - "ARPA" is a temporary domain. It is by default appended to the - names of hosts that have not yet joined a domain. When the system - was begun in 1984, the names of all hosts in the Official DoD - Internet Host Table maintained by the NIC were changed by adding - of the label ".ARPA" in order to accelerate a transition to the - domain-naming system. Another reason for the blanket name changes - was to force hosts to become accustomed to using the new style - names and to modify their network software, if necessary. This - was done on a network-wide basis and was directed by DCA in DDN - Management Bulletin No. 22. Hosts that fall into this domain will - eventually move to other branches of the domain tree. - - - - - -Stahl [Page 4] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - "COM" is meant to incorporate subdomains of companies and - businesses. - - "EDU" was initiated to accommodate subdomains set up by - universities and other educational institutions. - - "GOV" exists to act as parent domain for subdomains set up by - government agencies. - - "MIL" was initiated to act as parent to subdomains that are - developed by military organizations. - - "NET" was introduced as a parent domain for various network-type - organizations. Organizations that belong within this top-level - domain are generic or network-specific, such as network service - centers and consortia. "NET" also encompasses network - management-related organizations, such as information centers and - operations centers. - - "ORG" exists as a parent to subdomains that do not clearly fall - within the other top-level domains. This may include technical- - support groups, professional societies, or similar organizations. - - One of the guidelines in effect in the domain-naming system is that a - host should have only one name regardless of what networks it is - connected to. This implies, that, in general, domain names should - not include routing information or addresses. For example, a host - that has one network connection to the Internet and another to BITNET - should use the same name when talking to either network. For a - description of the syntax of domain names, please refer to Section 3 - of RFC-1034. - -VERIFICATION OF DATA - - The verification process can be accomplished in several ways. One of - these is through the NIC WHOIS server. If he has access to WHOIS, - the DA can type the command "whois domain ". - The reply from WHOIS will supply the following: the name and address - of the organization "owning" the domain; the name of the domain; its - administrative, technical, and zone contacts; the host names and - network addresses of sites providing name service for the domain. - - - - - - - - - - -Stahl [Page 5] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - Example: - - @whois domain rice.edu - - Rice University (RICE-DOM) - Advanced Studies and Research - Houston, TX 77001 - - Domain Name: RICE.EDU - - Administrative Contact: - Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834 - Technical Contact, Zone Contact: - Riffle, Vicky R. (VRR) rif@RICE.EDU - (713) 527-8101 ext 3844 - - Domain servers: - - RICE.EDU 128.42.5.1 - PENDRAGON.CS.PURDUE.EDU 128.10.2.5 - - - Alternatively, the DA can send an electronic mail message to - SERVICE@SRI-NIC.ARPA. In the subject line of the message header, the - DA should type "whois domain ". The requested - information will be returned via electronic mail. This method is - convenient for sites that do not have access to the NIC WHOIS - service. - - The initial application for domain authorization should be submitted - via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA. The - questionnaire described in the appendix may be used or a separate - application can be FTPed from host SRI-NIC.ARPA. The information - provided by the administrator will be reviewed by hostmaster - personnel for completeness. There will most likely be a few - exchanges of correspondence via electronic mail, the preferred method - of communication, prior to authorization of the domain. - -HOW TO GET MORE INFORMATION - - An informational table of the top-level domains and their root - servers is contained in the file NETINFO:DOMAINS.TXT online at SRI- - NIC.ARPA. This table can be obtained by FTPing the file. - Alternatively, the information can be acquired by opening a TCP or - UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA, - and invoking the command "ALL-DOM". - - - - - -Stahl [Page 6] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - The following online files, all available by FTP from SRI-NIC.ARPA, - contain pertinent domain information: - - - NETINFO:DOMAINS.TXT, a table of all top-level domains and the - network addresses of the machines providing domain name - service for them. It is updated each time a new top-level - domain is approved. - - - NETINFO:DOMAIN-INFO.TXT contains a concise list of all - top-level and second-level domain names registered with the - NIC and is updated monthly. - - - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the - top level and second-level domains, but includes the - administrative, technical and zone contacts for each as well. - - - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be - completed before registering a top-level or second-level - domain. - - For either general or specific information on the domain system, do - one or more of the following: - - 1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA - - 2. Call the toll-free NIC hotline at (800) 235-3155 - - 3. Use FTP to get background RFCs and other files maintained - online at the NIC. Some pertinent RFCs are listed below in - the REFERENCES section of this memo. - - - - - - - - - - - - - - - - - - - - - -Stahl [Page 7] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - -REFERENCES - - The references listed here provide important background information - on the domain-naming system. Path names of the online files - available via anonymous FTP from the SRI-NIC.ARPA host are noted in - brackets. - - 1. Defense Communications Agency DDN Defense Communications - System, DDN Management Bulletin No. 22, Domain Names - Transition, March 1984. - [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ] - - 2. Defense Communications Agency DDN Defense Communications - System, DDN Management Bulletin No. 32, Phase I of the Domain - Name Implementation, January 1987. - [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ] - - 3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname - Server", RFC-953, DDN Network Information Center, SRI - International, October 1985. [ RFC:RFC953.TXT ] - - 4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD - Internet Host Table Specification", RFC-952, DDN Network - Information Center, SRI International, October 1985. - [ RFC:RFC952.TXT ] - - 5. ISO, "Codes for the Representation of Names of Countries", - ISO-3166, International Standards Organization, May 1981. - [ Not online ] - - 6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031, - Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ] - - 7. Lottor, M.K., "Domain Administrators Operations Guide", - RFC-1033, DDN Network Information Center, SRI International, - July 1987. [ RFC:RFC1033.TXT ] - - 8. Mockapetris, P., "Domain Names - Concepts and Facilities", - RFC-1034, USC Information Sciences Institute, October 1987. - [ RFC:RFC1034.TXT ] - - 9. Mockapetris, P., "Domain Names - Implementation and - Specification", RFC-1035, USC Information Sciences Institute, - October 1987. [ RFC:RFC1035.TXT ] - - 10. Mockapetris, P., "The Domain Name System", Proceedings of the - IFIP 6.5 Working Conference on Computer Message Services, - Nottingham, England, May 1984. Also as ISI/RS-84-133, June - - - -Stahl [Page 8] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - 1984. [ Not online ] - - 11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server - Design for Distributed Systems", Proceedings of the Seventh - International Conference on Computer Communication, October - 30 to November 3 1984, Sidney, Australia. Also as - ISI/RS-84-132, June 1984. [ Not online ] - - 12. Partridge, C., "Mail Routing and the Domain System", RFC-974, - CSNET-CIC, BBN Laboratories, January 1986. - [ RFC:RFC974.TXT ] - - 13. Postel, J., "The Domain Names Plan and Schedule", RFC-881, - USC Information Sciences Institute, November 1983. - [ RFC:RFC881.TXT ] - - 14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010 - USC Information Sciences Institute, May 1986. - [ RFC:RFC1010.TXT ] - - 15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020, - SRI, November 1987. - [ RFC:RFC1020.TXT ] - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Stahl [Page 9] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - -APPENDIX - - The following questionnaire may be FTPed from SRI-NIC.ARPA as - NETINFO:DOMAIN-TEMPLATE.TXT. - - --------------------------------------------------------------------- - - To establish a domain, the following information must be sent to the - NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA): - - NOTE: The key people must have electronic mailboxes and NIC - "handles," unique NIC database identifiers. If you have access to - "WHOIS", please check to see if you are registered and if so, make - sure the information is current. Include only your handle and any - changes (if any) that need to be made in your entry. If you do not - have access to "WHOIS", please provide all the information indicated - and a NIC handle will be assigned. - - (1) The name of the top-level domain to join. - - For example: COM - - (2) The NIC handle of the administrative head of the organization. - Alternately, the person's name, title, mailing address, phone number, - organization, and network mailbox. This is the contact point for - administrative and policy questions about the domain. In the case of - a research project, this should be the principal investigator. - - For example: - - Administrator - - Organization The NetWorthy Corporation - Name Penelope Q. Sassafrass - Title President - Mail Address The NetWorthy Corporation - 4676 Andrews Way, Suite 100 - Santa Clara, CA 94302-1212 - Phone Number (415) 123-4567 - Net Mailbox Sassafrass@ECHO.TNC.COM - NIC Handle PQS - - (3) The NIC handle of the technical contact for the domain. - Alternately, the person's name, title, mailing address, phone number, - organization, and network mailbox. This is the contact point for - problems concerning the domain or zone, as well as for updating - information about the domain or zone. - - - - -Stahl [Page 10] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - For example: - - Technical and Zone Contact - - Organization The NetWorthy Corporation - Name Ansel A. Aardvark - Title Executive Director - Mail Address The NetWorthy Corporation - 4676 Andrews Way, Suite 100 - Santa Clara, CA. 94302-1212 - Phone Number (415) 123-6789 - Net Mailbox Aardvark@ECHO.TNC.COM - NIC Handle AAA2 - - (4) The name of the domain (up to 12 characters). This is the name - that will be used in tables and lists associating the domain with the - domain server addresses. [While, from a technical standpoint, domain - names can be quite long (programmers beware), shorter names are - easier for people to cope with.] - - For example: TNC - - (5) A description of the servers that provide the domain service for - translating names to addresses for hosts in this domain, and the date - they will be operational. - - A good way to answer this question is to say "Our server is - supplied by person or company X and does whatever their standard - issue server does." - - For example: Our server is a copy of the one operated by - the NIC; it will be installed and made operational on - 1 November 1987. - - (6) Domains must provide at least two independent servers for the - domain. Establishing the servers in physically separate locations - and on different PSNs is strongly recommended. A description of the - server machine and its backup, including - - - - - - - - - - - - - -Stahl [Page 11] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - (a) Hardware and software (using keywords from the Assigned - Numbers RFC). - - (b) Host domain name and network addresses (which host on which - network for each connected network). - - (c) Any domain-style nicknames (please limit your domain-style - nickname request to one) - - For example: - - - Hardware and software - - VAX-11/750 and UNIX, or - IBM-PC and MS-DOS, or - DEC-1090 and TOPS-20 - - - Host domain names and network addresses - - BAR.FOO.COM 10.9.0.193 on ARPANET - - - Domain-style nickname - - BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET) - - (7) Planned mapping of names of any other network hosts, other than - the server machines, into the new domain's naming space. - - For example: - - BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM - BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM - BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM - - - (8) An estimate of the number of hosts that will be in the domain. - - (a) Initially - (b) Within one year - (c) Two years - (d) Five years. - - For example: - - (a) Initially = 50 - (b) One year = 100 - (c) Two years = 200 - (d) Five years = 500 - - - -Stahl [Page 12] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - (9) The date you expect the fully qualified domain name to become - the official host name in HOSTS.TXT. - - Please note: If changing to a fully qualified domain name (e.g., - FOO.BAR.COM) causes a change in the official host name of an - ARPANET or MILNET host, DCA approval must be obtained beforehand. - Allow 10 working days for your requested changes to be processed. - - ARPANET sites should contact ARPANETMGR@DDN1.ARPA. MILNET sites - should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for - further instructions. - - (10) Please describe your organization briefly. - - For example: The NetWorthy Corporation is a consulting - organization of people working with UNIX and the C language in an - electronic networking environment. It sponsors two technical - conferences annually and distributes a bimonthly newsletter. - - --------------------------------------------------------------------- - - This example of a completed application corresponds to the examples - found in the companion document RFC-1033, "Domain Administrators - Operations Guide." - - (1) The name of the top-level domain to join. - - COM - - (2) The NIC handle of the administrative contact person. - - NIC Handle JAKE - - (3) The NIC handle of the domain's technical and zone - contact person. - - NIC Handle DLE6 - - (4) The name of the domain. - - SRI - - (5) A description of the servers. - - Our server is the TOPS20 server JEEVES supplied by ISI; it - will be installed and made operational on 1 July 1987. - - - - - -Stahl [Page 13] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - (6) A description of the server machine and its backup: - - (a) Hardware and software - - DEC-1090T and TOPS20 - DEC-2065 and TOPS20 - - (b) Host domain name and network address - - KL.SRI.COM 10.1.0.2 on ARPANET, 128.18.10.6 on SRINET - STRIPE.SRI.COM 10.4.0.2 on ARPANET, 128.18.10.4 on SRINET - - (c) Domain-style nickname - - None - - (7) Planned mapping of names of any other network hosts, other than - the server machines, into the new domain's naming space. - - SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM - SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM - - (8) An estimate of the number of hosts that will be directly within - this domain. - - (a) Initially = 50 - (b) One year = 100 - (c) Two years = 200 - (d) Five years = 500 - - (9) A date when you expect the fully qualified domain name to become - the official host name in HOSTS.TXT. - - 31 September 1987 - - (10) Brief description of organization. - - SRI International is an independent, nonprofit, scientific - research organization. It performs basic and applied research - for government and commercial clients, and contributes to - worldwide economic, scientific, industrial, and social progress - through research and related services. - - - - - - - - - -Stahl [Page 14] - diff --git a/doc/rfc/rfc1033.txt b/doc/rfc/rfc1033.txt deleted file mode 100644 index 37029fd9ae..0000000000 --- a/doc/rfc/rfc1033.txt +++ /dev/null @@ -1,1229 +0,0 @@ -Network Working Group M. Lottor -Request For Comments: 1033 SRI International - November 1987 - - - DOMAIN ADMINISTRATORS OPERATIONS GUIDE - - - -STATUS OF THIS MEMO - - This RFC provides guidelines for domain administrators in operating a - domain server and maintaining their portion of the hierarchical - database. Familiarity with the domain system is assumed. - Distribution of this memo is unlimited. - -ACKNOWLEDGMENTS - - This memo is a formatted collection of notes and excerpts from the - references listed at the end of this document. Of particular mention - are Paul Mockapetris and Kevin Dunlap. - -INTRODUCTION - - A domain server requires a few files to get started. It will - normally have some number of boot/startup files (also known as the - "safety belt" files). One section will contain a list of possible - root servers that the server will use to find the up-to-date list of - root servers. Another section will list the zone files to be loaded - into the server for your local domain information. A zone file - typically contains all the data for a particular domain. This guide - describes the data formats that can be used in zone files and - suggested parameters to use for certain fields. If you are - attempting to do anything advanced or tricky, consult the appropriate - domain RFC's for more details. - - Note: Each implementation of domain software may require different - files. Zone files are standardized but some servers may require - other startup files. See the appropriate documentation that comes - with your software. See the appendix for some specific examples. - -ZONES - - A zone defines the contents of a contiguous section of the domain - space, usually bounded by administrative boundaries. There will - typically be a separate data file for each zone. The data contained - in a zone file is composed of entries called Resource Records (RRs). - - - - -Lottor [Page 1] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - You may only put data in your domain server that you are - authoritative for. You must not add entries for domains other than - your own (except for the special case of "glue records"). - - A domain server will probably read a file on start-up that lists the - zones it should load into its database. The format of this file is - not standardized and is different for most domain server - implementations. For each zone it will normally contain the domain - name of the zone and the file name that contains the data to load for - the zone. - -ROOT SERVERS - - A resolver will need to find the root servers when it first starts. - When the resolver boots, it will typically read a list of possible - root servers from a file. - - The resolver will cycle through the list trying to contact each one. - When it finds a root server, it will ask it for the current list of - root servers. It will then discard the list of root servers it read - from the data file and replace it with the current list it received. - - Root servers will not change very often. You can get the names of - current root servers from the NIC. - - FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to - NIC@SRI-NIC.ARPA. - - As of this date (June 1987) they are: - - SRI-NIC.ARPA 10.0.0.51 26.0.0.73 - C.ISI.EDU 10.0.0.52 - BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 - A.ISI.EDU 26.3.0.103 - -RESOURCE RECORDS - - Records in the zone data files are called resource records (RRs). - They are specified in RFC-883 and RFC-973. An RR has a standard - format as shown: - - [] [] - - The record is divided into fields which are separated by white space. - - - - The name field defines what domain name applies to the given - - - -Lottor [Page 2] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - RR. In some cases the name field can be left blank and it will - default to the name field of the previous RR. - - - - TTL stands for Time To Live. It specifies how long a domain - resolver should cache the RR before it throws it out and asks a - domain server again. See the section on TTL's. If you leave - the TTL field blank it will default to the minimum time - specified in the SOA record (described later). - - - - The class field specifies the protocol group. If left blank it - will default to the last class specified. - - - - The type field specifies what type of data is in the RR. See - the section on types. - - - - The data field is defined differently for each type and class - of data. Popular RR data formats are described later. - - The domain system does not guarantee to preserve the order of - resource records. Listing RRs (such as multiple address records) in - a certain order does not guarantee they will be used in that order. - - Case is preserved in names and data fields when loaded into the name - server. All comparisons and lookups in the name server are case - insensitive. - - Parenthesis ("(",")") are used to group data that crosses a line - boundary. - - A semicolon (";") starts a comment; the remainder of the line is - ignored. - - The asterisk ("*") is used for wildcarding. - - The at-sign ("@") denotes the current default domain name. - - - - - - - - -Lottor [Page 3] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -NAMES - - A domain name is a sequence of labels separated by dots. - - Domain names in the zone files can be one of two types, either - absolute or relative. An absolute name is the fully qualified domain - name and is terminated with a period. A relative name does not - terminate with a period, and the current default domain is appended - to it. The default domain is usually the name of the domain that was - specified in the boot file that loads each zone. - - The domain system allows a label to contain any 8-bit character. - Although the domain system has no restrictions, other protocols such - as SMTP do have name restrictions. Because of other protocol - restrictions, only the following characters are recommended for use - in a host name (besides the dot separator): - - "A-Z", "a-z", "0-9", dash and underscore - -TTL's (Time To Live) - - It is important that TTLs are set to appropriate values. The TTL is - the time (in seconds) that a resolver will use the data it got from - your server before it asks your server again. If you set the value - too low, your server will get loaded down with lots of repeat - requests. If you set it too high, then information you change will - not get distributed in a reasonable amount of time. If you leave the - TTL field blank, it will default to what is specified in the SOA - record for the zone. - - Most host information does not change much over long time periods. A - good way to set up your TTLs would be to set them at a high value, - and then lower the value if you know a change will be coming soon. - You might set most TTLs to anywhere between a day (86400) and a week - (604800). Then, if you know some data will be changing in the near - future, set the TTL for that RR down to a lower value (an hour to a - day) until the change takes place, and then put it back up to its - previous value. - - Also, all RRs with the same name, class, and type should have the - same TTL value. - -CLASSES - - The domain system was designed to be protocol independent. The class - field is used to identify the protocol group that each RR is in. - - The class of interest to people using TCP/IP software is the class - - - -Lottor [Page 4] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - "Internet". Its standard designation is "IN". - - A zone file should only contain RRs of the same class. - -TYPES - - There are many defined RR types. For a complete list, see the domain - specification RFCs. Here is a list of current commonly used types. - The data for each type is described in the data section. - - Designation Description - ========================================== - SOA Start Of Authority - NS Name Server - - A Internet Address - CNAME Canonical Name (nickname pointer) - HINFO Host Information - WKS Well Known Services - - MX Mail Exchanger - - PTR Pointer - -SOA (Start Of Authority) - - [] [] SOA ( - - - - - ) - - The Start Of Authority record designates the start of a zone. The - zone ends at the next SOA record. - - is the name of the zone. - - is the name of the host on which the master zone file - resides. - - is a mailbox for the person responsible for the zone. It is - formatted like a mailing address but the at-sign that normally - separates the user from the host name is replaced with a dot. - - is the version number of the zone file. It should be - incremented anytime a change is made to data in the zone. - - - - -Lottor [Page 5] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - is how long, in seconds, a secondary name server is to - check with the primary name server to see if an update is needed. A - good value here would be one hour (3600). - - is how long, in seconds, a secondary name server is to retry - after a failure to check for a refresh. A good value here would be - 10 minutes (600). - - is the upper limit, in seconds, that a secondary name server - is to use the data before it expires for lack of getting a refresh. - You want this to be rather large, and a nice value is 3600000, about - 42 days. - - is the minimum number of seconds to be used for TTL values - in RRs. A minimum of at least a day is a good value here (86400). - - There should only be one SOA record per zone. A sample SOA record - would look something like: - - @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( - 45 ;serial - 3600 ;refresh - 600 ;retry - 3600000 ;expire - 86400 ) ;minimum - - -NS (Name Server) - - [] [] NS - - The NS record lists the name of a machine that provides domain - service for a particular domain. The name associated with the RR is - the domain name and the data portion is the name of a host that - provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide - name lookup service for the domain COM then the following entries - would be used: - - COM. NS SRI-NIC.ARPA. - NS C.ISI.EDU. - - Note that the machines providing name service do not have to live in - the named domain. There should be one NS record for each server for - a domain. Also note that the name "COM" defaults for the second NS - record. - - NS records for a domain exist in both the zone that delegates the - domain, and in the domain itself. - - - -Lottor [Page 6] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -GLUE RECORDS - - If the name server host for a particular domain is itself inside the - domain, then a 'glue' record will be needed. A glue record is an A - (address) RR that specifies the address of the server. Glue records - are only needed in the server delegating the domain, not in the - domain itself. If for example the name server for domain SRI.COM was - KL.SRI.COM, then the NS record would look like this, but you will - also need to have the following A record. - - SRI.COM. NS KL.SRI.COM. - KL.SRI.COM. A 10.1.0.2 - - -A (Address) - - [] [] A
- - The data for an A record is an internet address in dotted decimal - form. A sample A record might look like: - - SRI-NIC.ARPA. A 10.0.0.51 - - There should be one A record for each address of a host. - -CNAME ( Canonical Name) - - [] [] CNAME - - The CNAME record is used for nicknames. The name associated with the - RR is the nickname. The data portion is the official name. For - example, a machine named SRI-NIC.ARPA may want to have the nickname - NIC.ARPA. In that case, the following RR would be used: - - NIC.ARPA. CNAME SRI-NIC.ARPA. - - There must not be any other RRs associated with a nickname of the - same class. - - Nicknames are also useful when a host changes it's name. In that - case, it is usually a good idea to have a CNAME pointer so that - people still using the old name will get to the right place. - - - - - - - - - -Lottor [Page 7] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -HINFO (Host Info) - - [] [] HINFO - - The HINFO record gives information about a particular host. The data - is two strings separated by whitespace. The first string is a - hardware description and the second is software. The hardware is - usually a manufacturer name followed by a dash and model designation. - The software string is usually the name of the operating system. - - Official HINFO types can be found in the latest Assigned Numbers RFC, - the latest of which is RFC-1010. The Hardware type is called the - Machine name and the Software type is called the System name. - - Some sample HINFO records: - - SRI-NIC.ARPA. HINFO DEC-2060 TOPS20 - UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX - - -WKS (Well Known Services) - - [] [] WKS
- - The WKS record is used to list Well Known Services a host provides. - WKS's are defined to be services on port numbers below 256. The WKS - record lists what services are available at a certain address using a - certain protocol. The common protocols are TCP or UDP. A sample WKS - record for a host offering the same services on all address would - look like: - - Official protocol names can be found in the latest Assigned Numbers - RFC, the latest of which is RFC-1010. - - SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP - WKS 10.0.0.51 UDP TIME - WKS 26.0.0.73 TCP TELNET FTP SMTP - WKS 26.0.0.73 UDP TIME - -MX (Mail Exchanger) (See RFC-974 for more details.) - - [] [] MX - - MX records specify where mail for a domain name should be delivered. - There may be multiple MX records for a particular name. The - preference value specifies the order a mailer should try multiple MX - records when delivering mail. Zero is the highest preference. - Multiple records for the same name may have the same preference. - - - -Lottor [Page 8] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - A host BAR.FOO.COM may want its mail to be delivered to the host - PO.FOO.COM and would then use the MX record: - - BAR.FOO.COM. MX 10 PO.FOO.COM. - - A host BAZ.FOO.COM may want its mail to be delivered to one of three - different machines, in the following order: - - BAZ.FOO.COM. MX 10 PO1.FOO.COM. - MX 20 PO2.FOO.COM. - MX 30 PO3.FOO.COM. - - An entire domain of hosts not connected to the Internet may want - their mail to go through a mail gateway that knows how to deliver - mail to them. If they would like mail addressed to any host in the - domain FOO.COM to go through the mail gateway they might use: - - FOO.COM. MX 10 RELAY.CS.NET. - *.FOO.COM. MX 20 RELAY.CS.NET. - - Note that you can specify a wildcard in the MX record to match on - anything in FOO.COM, but that it won't match a plain FOO.COM. - -IN-ADDR.ARPA - - The structure of names in the domain system is set up in a - hierarchical way such that the address of a name can be found by - tracing down the domain tree contacting a server for each label of - the name. Because of this 'indexing' based on name, there is no easy - way to translate a host address back into its host name. - - In order to do the reverse translation easily, a domain was created - that uses hosts' addresses as part of a name that then points to the - data for that host. In this way, there is now an 'index' to hosts' - RRs based on their address. This address mapping domain is called - IN-ADDR.ARPA. Within that domain are subdomains for each network, - based on network number. Also, for consistency and natural - groupings, the 4 octets of a host number are reversed. - - For example, the ARPANET is net 10. That means there is a domain - called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at - 51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA - (who's address is 10.0.0.51). Since the NIC is also on the MILNET - (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN- - ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format - of these special pointers is defined below along with the examples - for the NIC. - - - - -Lottor [Page 9] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -PTR - - [] [] PTR - - The PTR record is used to let special names point to some other - location in the domain tree. They are mainly used in the IN- - ADDR.ARPA records for translation of addresses to names. PTR's - should use official names and not aliases. - - For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73 - would have the following records in the respective zone files for net - 10 and net 26: - - 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. - 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. - -GATEWAY PTR's - - The IN-ADDR tree is also used to locate gateways on a particular - network. Gateways have the same kind of PTR RRs as hosts (as above) - but in addition they have other PTRs used to locate them by network - number alone. These records have only 1, 2, or 3 octets as part of - the name depending on whether they are class A, B, or C networks, - respectively. - - Lets take the SRI-CSL gateway for example. It connects 3 different - networks, one class A, one class B and one class C. It will have the - standard RR's for a host in the CSL.SRI.COM zone: - - GW.CSL.SRI.COM. A 10.2.0.2 - A 128.18.1.1 - A 192.12.33.2 - - Also, in 3 different zones (one for each network), it will have one - of the following number to name translation pointers: - - 2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - - In addition, in each of the same 3 zones will be one of the following - gateway location pointers: - - 10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - 18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - 33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - - - - - -Lottor [Page 10] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -INSTRUCTIONS - - Adding a subdomain. - - To add a new subdomain to your domain: - - Setup the other domain server and/or the new zone file. - - Add an NS record for each server of the new domain to the zone - file of the parent domain. - - Add any necessary glue RRs. - - Adding a host. - - To add a new host to your zone files: - - Edit the appropriate zone file for the domain the host is in. - - Add an entry for each address of the host. - - Optionally add CNAME, HINFO, WKS, and MX records. - - Add the reverse IN-ADDR entry for each host address in the - appropriate zone files for each network the host in on. - - Deleting a host. - - To delete a host from the zone files: - - Remove all the hosts' resource records from the zone file of - the domain the host is in. - - Remove all the hosts' PTR records from the IN-ADDR zone files - for each network the host was on. - - Adding gateways. - - Follow instructions for adding a host. - - Add the gateway location PTR records for each network the - gateway is on. - - Deleting gateways. - - Follow instructions for deleting a host. - - Also delete the gateway location PTR records for each network - - - -Lottor [Page 11] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - the gateway was on. - -COMPLAINTS - - These are the suggested steps you should take if you are having - problems that you believe are caused by someone else's name server: - - - 1. Complain privately to the responsible person for the domain. You - can find their mailing address in the SOA record for the domain. - - 2. Complain publicly to the responsible person for the domain. - - 3. Ask the NIC for the administrative person responsible for the - domain. Complain. You can also find domain contacts on the NIC in - the file NETINFO:DOMAIN-CONTACTS.TXT - - 4. Complain to the parent domain authorities. - - 5. Ask the parent authorities to excommunicate the domain. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 12] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -EXAMPLE DOMAIN SERVER DATABASE FILES - - The following examples show how zone files are set up for a typical - organization. SRI will be used as the example organization. SRI has - decided to divided their domain SRI.COM into a few subdomains, one - for each group that wants one. The subdomains are CSL and ISTC. - - Note the following interesting items: - - There are both hosts and domains under SRI.COM. - - CSL.SRI.COM is both a domain name and a host name. - - All the domains are serviced by the same pair of domain servers. - - All hosts at SRI are on net 128.18 except hosts in the CSL domain - which are on net 192.12.33. Note that a domain does not have to - correspond to a physical network. - - The examples do not necessarily correspond to actual data in use - by the SRI domain. - - SRI Domain Organization - - +-------+ - | COM | - +-------+ - | - +-------+ - | SRI | - +-------+ - | - +----------++-----------+ - | | | - +-------+ +------+ +-------+ - | CSL | | ISTC | | Hosts | - +-------+ +------+ +-------+ - | | - +-------+ +-------+ - | Hosts | | Hosts | - +-------+ +-------+ - - - - - - - - - - -Lottor [Page 13] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "CONFIG.CMD". Since bootstrap files are not standardized, this - file is presented using a pseudo configuration file syntax.] - - load root server list from file ROOT.SERVERS - load zone SRI.COM. from file SRI.ZONE - load zone CSL.SRI.COM. from file CSL.ZONE - load zone ISTC.SRI.COM. from file ISTC.ZONE - load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE - load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 14] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "ROOT.SERVERS". Again, the format of this file is not - standardized.] - - ;list of possible root servers - SRI-NIC.ARPA 10.0.0.51 26.0.0.73 - C.ISI.EDU 10.0.0.52 - BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 - A.ISI.EDU 26.3.0.103 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 15] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "SRI.ZONE"] - - SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( - 870407 ;serial - 1800 ;refresh every 30 minutes - 600 ;retry every 10 minutes - 604800 ;expire after a week - 86400 ;default of an hour - ) - - SRI.COM. NS KL.SRI.COM. - NS STRIPE.SRI.COM. - MX 10 KL.SRI.COM. - - ;SRI.COM hosts - - KL A 10.1.0.2 - A 128.18.10.6 - MX 10 KL.SRI.COM. - - STRIPE A 10.4.0.2 - STRIPE A 128.18.10.4 - MX 10 STRIPE.SRI.COM. - - NIC CNAME SRI-NIC.ARPA. - - Blackjack A 128.18.2.1 - HINFO VAX-11/780 UNIX - WKS 128.18.2.1 TCP TELNET FTP - - CSL A 192.12.33.2 - HINFO FOONLY-F4 TOPS20 - WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER - MX 10 CSL.SRI.COM. - - - - - - - - - - - - - - - - - -Lottor [Page 16] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "CSL.ZONE"] - - CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( - 870330 ;serial - 1800 ;refresh every 30 minutes - 600 ;retry every 10 minutes - 604800 ;expire after a week - 86400 ;default of a day - ) - - CSL.SRI.COM. NS KL.SRI.COM. - NS STRIPE.SRI.COM. - A 192.12.33.2 - - ;CSL.SRI.COM hosts - - A CNAME CSL.SRI.COM. - B A 192.12.33.3 - HINFO FOONLY-F4 TOPS20 - WKS 192.12.33.3 TCP TELNET FTP SMTP - GW A 10.2.0.2 - A 192.12.33.1 - A 128.18.1.1 - HINFO PDP-11/23 MOS - SMELLY A 192.12.33.4 - HINFO IMAGEN IMAGEN - SQUIRREL A 192.12.33.5 - HINFO XEROX-1100 INTERLISP - VENUS A 192.12.33.7 - HINFO SYMBOLICS-3600 LISPM - HELIUM A 192.12.33.30 - HINFO SUN-3/160 UNIX - ARGON A 192.12.33.31 - HINFO SUN-3/75 UNIX - RADON A 192.12.33.32 - HINFO SUN-3/75 UNIX - - - - - - - - - - - - - - - -Lottor [Page 17] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "ISTC.ZONE"] - - ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. ( - 870406 ;serial - 1800 ;refresh every 30 minutes - 600 ;retry every 10 minutes - 604800 ;expire after a week - 86400 ;default of a day - ) - - ISTC.SRI.COM. NS KL.SRI.COM. - NS STRIPE.SRI.COM. - MX 10 SPAM.ISTC.SRI.COM. - - ; ISTC hosts - - joyce A 128.18.4.2 - HINFO VAX-11/750 UNIX - bozo A 128.18.0.6 - HINFO SUN UNIX - sundae A 128.18.0.11 - HINFO SUN UNIX - tsca A 128.18.0.201 - A 10.3.0.2 - HINFO VAX-11/750 UNIX - MX 10 TSCA.ISTC.SRI.COM. - tsc CNAME tsca - prmh A 128.18.0.203 - A 10.2.0.51 - HINFO PDP-11/44 UNIX - spam A 128.18.4.3 - A 10.2.0.107 - HINFO VAX-11/780 UNIX - MX 10 SPAM.ISTC.SRI.COM. - - - - - - - - - - - - - - - - - -Lottor [Page 18] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "SRINET.ZONE"] - - 18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( - 870406 ;serial - 1800 ;refresh every 30 minutes - 600 ;retry every 10 minutes - 604800 ;expire after a week - 86400 ;default of a day - ) - - 18.128.IN-ADDR.ARPA. NS KL.SRI.COM. - NS STRIPE.SRI.COM. - PTR GW.CSL.SRI.COM. - - ; SRINET [128.18.0.0] Address Translations - - ; SRI.COM Hosts - 1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM. - - ; ISTC.SRI.COM Hosts - 2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM. - 6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM. - 11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM. - 201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM. - 203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM. - 3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM. - - ; CSL.SRI.COM Hosts - 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 19] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "SRI-CSL-NET.ZONE"] - - 33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( - 870404 ;serial - 1800 ;refresh every 30 minutes - 600 ;retry every 10 minutes - 604800 ;expire after a week - 86400 ;default of a day - ) - - 33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM. - NS STRIPE.SRI.COM. - PTR GW.CSL.SRI.COM. - - ; SRI-CSL-NET [192.12.33.0] Address Translations - - ; SRI.COM Hosts - 2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM. - - ; CSL.SRI.COM Hosts - 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - 3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM. - 4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM. - 5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM. - 7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM. - 30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM. - 31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM. - 32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM. - - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 20] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -APPENDIX - - BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD - UNIX - - This section describes two BIND implementation specific files; the - boot file and the cache file. BIND has other options, files, and - specifications that are not described here. See the Name Server - Operations Guide for BIND for details. - - The boot file for BIND is usually called "named.boot". This - corresponds to file "CONFIG.CMD" in the example section. - - -------------------------------------------------------- - cache . named.ca - primary SRI.COM SRI.ZONE - primary CSL.SRI.COM CSL.ZONE - primary ISTC.SRI.COM ISTC.ZONE - primary 18.128.IN-ADDR.ARPA SRINET.ZONE - primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE - -------------------------------------------------------- - - The cache file for BIND is usually called "named.ca". This - corresponds to file "ROOT.SERVERS" in the example section. - - ------------------------------------------------- - ;list of possible root servers - . 1 IN NS SRI-NIC.ARPA. - NS C.ISI.EDU. - NS BRL-AOS.ARPA. - NS C.ISI.EDU. - ;and their addresses - SRI-NIC.ARPA. A 10.0.0.51 - A 26.0.0.73 - C.ISI.EDU. A 10.0.0.52 - BRL-AOS.ARPA. A 192.5.25.82 - A 192.5.22.82 - A 128.20.1.2 - A.ISI.EDU. A 26.3.0.103 - ------------------------------------------------- - - - - - - - - - - - -Lottor [Page 21] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -REFERENCES - - [1] Dunlap, K., "Name Server Operations Guide for BIND", CSRG, - Department of Electrical Engineering and Computer Sciences, - University of California, Berkeley, California. - - [2] Partridge, C., "Mail Routing and the Domain System", RFC-974, - CSNET CIC BBN Laboratories, January 1986. - - [3] Mockapetris, P., "Domains Names - Concepts and Facilities", - RFC-1034, USC/Information Sciences Institute, November 1987. - - [4] Mockapetris, P., "Domain Names - Implementations Specification", - RFC-1035, USC/Information Sciences Institute, November 1987. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 22] - diff --git a/doc/rfc/rfc1034.txt b/doc/rfc/rfc1034.txt deleted file mode 100644 index 55cdb21fe6..0000000000 --- a/doc/rfc/rfc1034.txt +++ /dev/null @@ -1,3077 +0,0 @@ -Network Working Group P. Mockapetris -Request for Comments: 1034 ISI -Obsoletes: RFCs 882, 883, 973 November 1987 - - - DOMAIN NAMES - CONCEPTS AND FACILITIES - - - -1. STATUS OF THIS MEMO - -This RFC is an introduction to the Domain Name System (DNS), and omits -many details which can be found in a companion RFC, "Domain Names - -Implementation and Specification" [RFC-1035]. That RFC assumes that the -reader is familiar with the concepts discussed in this memo. - -A subset of DNS functions and data types constitute an official -protocol. The official protocol includes standard queries and their -responses and most of the Internet class data formats (e.g., host -addresses). - -However, the domain system is intentionally extensible. Researchers are -continuously proposing, implementing and experimenting with new data -types, query types, classes, functions, etc. Thus while the components -of the official protocol are expected to stay essentially unchanged and -operate as a production service, experimental behavior should always be -expected in extensions beyond the official protocol. Experimental or -obsolete features are clearly marked in these RFCs, and such information -should be used with caution. - -The reader is especially cautioned not to depend on the values which -appear in examples to be current or complete, since their purpose is -primarily pedagogical. Distribution of this memo is unlimited. - -2. INTRODUCTION - -This RFC introduces domain style names, their use for Internet mail and -host address support, and the protocols and servers used to implement -domain name facilities. - -2.1. The history of domain names - -The impetus for the development of the domain system was growth in the -Internet: - - - Host name to address mappings were maintained by the Network - Information Center (NIC) in a single file (HOSTS.TXT) which - was FTPed by all hosts [RFC-952, RFC-953]. The total network - - - -Mockapetris [Page 1] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - bandwidth consumed in distributing a new version by this - scheme is proportional to the square of the number of hosts in - the network, and even when multiple levels of FTP are used, - the outgoing FTP load on the NIC host is considerable. - Explosive growth in the number of hosts didn't bode well for - the future. - - - The network population was also changing in character. The - timeshared hosts that made up the original ARPANET were being - replaced with local networks of workstations. Local - organizations were administering their own names and - addresses, but had to wait for the NIC to change HOSTS.TXT to - make changes visible to the Internet at large. Organizations - also wanted some local structure on the name space. - - - The applications on the Internet were getting more - sophisticated and creating a need for general purpose name - service. - - -The result was several ideas about name spaces and their management -[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a -common thread was the idea of a hierarchical name space, with the -hierarchy roughly corresponding to organizational structure, and names -using "." as the character to mark the boundary between hierarchy -levels. A design using a distributed database and generalized resources -was described in [RFC-882, RFC-883]. Based on experience with several -implementations, the system evolved into the scheme described in this -memo. - -The terms "domain" or "domain name" are used in many contexts beyond the -DNS described here. Very often, the term domain name is used to refer -to a name with structure indicated by dots, but no relation to the DNS. -This is particularly true in mail addressing [Quarterman 86]. - -2.2. DNS design goals - -The design goals of the DNS influence its structure. They are: - - - The primary goal is a consistent name space which will be used - for referring to resources. In order to avoid the problems - caused by ad hoc encodings, names should not be required to - contain network identifiers, addresses, routes, or similar - information as part of the name. - - - The sheer size of the database and frequency of updates - suggest that it must be maintained in a distributed manner, - with local caching to improve performance. Approaches that - - - -Mockapetris [Page 2] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - attempt to collect a consistent copy of the entire database - will become more and more expensive and difficult, and hence - should be avoided. The same principle holds for the structure - of the name space, and in particular mechanisms for creating - and deleting names; these should also be distributed. - - - Where there tradeoffs between the cost of acquiring data, the - speed of updates, and the accuracy of caches, the source of - the data should control the tradeoff. - - - The costs of implementing such a facility dictate that it be - generally useful, and not restricted to a single application. - We should be able to use names to retrieve host addresses, - mailbox data, and other as yet undetermined information. All - data associated with a name is tagged with a type, and queries - can be limited to a single type. - - - Because we want the name space to be useful in dissimilar - networks and applications, we provide the ability to use the - same name space with different protocol families or - management. For example, host address formats differ between - protocols, though all protocols have the notion of address. - The DNS tags all data with a class as well as the type, so - that we can allow parallel use of different formats for data - of type address. - - - We want name server transactions to be independent of the - communications system that carries them. Some systems may - wish to use datagrams for queries and responses, and only - establish virtual circuits for transactions that need the - reliability (e.g., database updates, long transactions); other - systems will use virtual circuits exclusively. - - - The system should be useful across a wide spectrum of host - capabilities. Both personal computers and large timeshared - hosts should be able to use the system, though perhaps in - different ways. - -2.3. Assumptions about usage - -The organization of the domain system derives from some assumptions -about the needs and usage patterns of its user community and is designed -to avoid many of the the complicated problems found in general purpose -database systems. - -The assumptions are: - - - The size of the total database will initially be proportional - - - -Mockapetris [Page 3] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - to the number of hosts using the system, but will eventually - grow to be proportional to the number of users on those hosts - as mailboxes and other information are added to the domain - system. - - - Most of the data in the system will change very slowly (e.g., - mailbox bindings, host addresses), but that the system should - be able to deal with subsets that change more rapidly (on the - order of seconds or minutes). - - - The administrative boundaries used to distribute - responsibility for the database will usually correspond to - organizations that have one or more hosts. Each organization - that has responsibility for a particular set of domains will - provide redundant name servers, either on the organization's - own hosts or other hosts that the organization arranges to - use. - - - Clients of the domain system should be able to identify - trusted name servers they prefer to use before accepting - referrals to name servers outside of this "trusted" set. - - - Access to information is more critical than instantaneous - updates or guarantees of consistency. Hence the update - process allows updates to percolate out through the users of - the domain system rather than guaranteeing that all copies are - simultaneously updated. When updates are unavailable due to - network or host failure, the usual course is to believe old - information while continuing efforts to update it. The - general model is that copies are distributed with timeouts for - refreshing. The distributor sets the timeout value and the - recipient of the distribution is responsible for performing - the refresh. In special situations, very short intervals can - be specified, or the owner can prohibit copies. - - - In any system that has a distributed database, a particular - name server may be presented with a query that can only be - answered by some other server. The two general approaches to - dealing with this problem are "recursive", in which the first - server pursues the query for the client at another server, and - "iterative", in which the server refers the client to another - server and lets the client pursue the query. Both approaches - have advantages and disadvantages, but the iterative approach - is preferred for the datagram style of access. The domain - system requires implementation of the iterative approach, but - allows the recursive approach as an option. - - - - - -Mockapetris [Page 4] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -The domain system assumes that all data originates in master files -scattered through the hosts that use the domain system. These master -files are updated by local system administrators. Master files are text -files that are read by a local name server, and hence become available -through the name servers to users of the domain system. The user -programs access name servers through standard programs called resolvers. - -The standard format of master files allows them to be exchanged between -hosts (via FTP, mail, or some other mechanism); this facility is useful -when an organization wants a domain, but doesn't want to support a name -server. The organization can maintain the master files locally using a -text editor, transfer them to a foreign host which runs a name server, -and then arrange with the system administrator of the name server to get -the files loaded. - -Each host's name servers and resolvers are configured by a local system -administrator [RFC-1033]. For a name server, this configuration data -includes the identity of local master files and instructions on which -non-local master files are to be loaded from foreign servers. The name -server uses the master files or copies to load its zones. For -resolvers, the configuration data identifies the name servers which -should be the primary sources of information. - -The domain system defines procedures for accessing the data and for -referrals to other name servers. The domain system also defines -procedures for caching retrieved data and for periodic refreshing of -data defined by the system administrator. - -The system administrators provide: - - - The definition of zone boundaries. - - - Master files of data. - - - Updates to master files. - - - Statements of the refresh policies desired. - -The domain system provides: - - - Standard formats for resource data. - - - Standard methods for querying the database. - - - Standard methods for name servers to refresh local data from - foreign name servers. - - - - - -Mockapetris [Page 5] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -2.4. Elements of the DNS - -The DNS has three major components: - - - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are - specifications for a tree structured name space and data - associated with the names. Conceptually, each node and leaf - of the domain name space tree names a set of information, and - query operations are attempts to extract specific types of - information from a particular set. A query names the domain - name of interest and describes the type of resource - information that is desired. For example, the Internet - uses some of its domain names to identify hosts; queries for - address resources return Internet host addresses. - - - NAME SERVERS are server programs which hold information about - the domain tree's structure and set information. A name - server may cache structure or set information about any part - of the domain tree, but in general a particular name server - has complete information about a subset of the domain space, - and pointers to other name servers that can be used to lead to - information from any part of the domain tree. Name servers - know the parts of the domain tree for which they have complete - information; a name server is said to be an AUTHORITY for - these parts of the name space. Authoritative information is - organized into units called ZONEs, and these zones can be - automatically distributed to the name servers which provide - redundant service for the data in a zone. - - - RESOLVERS are programs that extract information from name - servers in response to client requests. Resolvers must be - able to access at least one name server and use that name - server's information to answer a query directly, or pursue the - query using referrals to other name servers. A resolver will - typically be a system routine that is directly accessible to - user programs; hence no protocol is necessary between the - resolver and the user program. - -These three components roughly correspond to the three layers or views -of the domain system: - - - From the user's point of view, the domain system is accessed - through a simple procedure or OS call to a local resolver. - The domain space consists of a single tree and the user can - request information from any section of the tree. - - - From the resolver's point of view, the domain system is - composed of an unknown number of name servers. Each name - - - -Mockapetris [Page 6] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - server has one or more pieces of the whole domain tree's data, - but the resolver views each of these databases as essentially - static. - - - From a name server's point of view, the domain system consists - of separate sets of local information called zones. The name - server has local copies of some of the zones. The name server - must periodically refresh its zones from master copies in - local files or foreign name servers. The name server must - concurrently process queries that arrive from resolvers. - -In the interests of performance, implementations may couple these -functions. For example, a resolver on the same machine as a name server -might share a database consisting of the the zones managed by the name -server and the cache managed by the resolver. - -3. DOMAIN NAME SPACE and RESOURCE RECORDS - -3.1. Name space specifications and terminology - -The domain name space is a tree structure. Each node and leaf on the -tree corresponds to a resource set (which may be empty). The domain -system makes no distinctions between the uses of the interior nodes and -leaves, and this memo uses the term "node" to refer to both. - -Each node has a label, which is zero to 63 octets in length. Brother -nodes may not have the same label, although the same label can be used -for nodes which are not brothers. One label is reserved, and that is -the null (i.e., zero length) label used for the root. - -The domain name of a node is the list of the labels on the path from the -node to the root of the tree. By convention, the labels that compose a -domain name are printed or read left to right, from the most specific -(lowest, farthest from the root) to the least specific (highest, closest -to the root). - -Internally, programs that manipulate domain names should represent them -as sequences of labels, where each label is a length octet followed by -an octet string. Because all domain names end at the root, which has a -null string for a label, these internal representations can use a length -byte of zero to terminate a domain name. - -By convention, domain names can be stored with arbitrary case, but -domain name comparisons for all present domain functions are done in a -case-insensitive manner, assuming an ASCII character set, and a high -order zero bit. This means that you are free to create a node with -label "A" or a node with label "a", but not both as brothers; you could -refer to either using "a" or "A". When you receive a domain name or - - - -Mockapetris [Page 7] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -label, you should preserve its case. The rationale for this choice is -that we may someday need to add full binary domain names for new -services; existing services would not be changed. - -When a user needs to type a domain name, the length of each label is -omitted and the labels are separated by dots ("."). Since a complete -domain name ends with the root label, this leads to a printed form which -ends in a dot. We use this property to distinguish between: - - - a character string which represents a complete domain name - (often called "absolute"). For example, "poneria.ISI.EDU." - - - a character string that represents the starting labels of a - domain name which is incomplete, and should be completed by - local software using knowledge of the local domain (often - called "relative"). For example, "poneria" used in the - ISI.EDU domain. - -Relative names are either taken relative to a well known origin, or to a -list of domains used as a search list. Relative names appear mostly at -the user interface, where their interpretation varies from -implementation to implementation, and in master files, where they are -relative to a single origin domain name. The most common interpretation -uses the root "." as either the single origin or as one of the members -of the search list, so a multi-label relative name is often one where -the trailing dot has been omitted to save typing. - -To simplify implementations, the total number of octets that represent a -domain name (i.e., the sum of all label octets and label lengths) is -limited to 255. - -A domain is identified by a domain name, and consists of that part of -the domain name space that is at or below the domain name which -specifies the domain. A domain is a subdomain of another domain if it -is contained within that domain. This relationship can be tested by -seeing if the subdomain's name ends with the containing domain's name. -For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". - -3.2. Administrative guidelines on use - -As a matter of policy, the DNS technical specifications do not mandate a -particular tree structure or rules for selecting labels; its goal is to -be as general as possible, so that it can be used to build arbitrary -applications. In particular, the system was designed so that the name -space did not have to be organized along the lines of network -boundaries, name servers, etc. The rationale for this is not that the -name space should have no implied semantics, but rather that the choice -of implied semantics should be left open to be used for the problem at - - - -Mockapetris [Page 8] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -hand, and that different parts of the tree can have different implied -semantics. For example, the IN-ADDR.ARPA domain is organized and -distributed by network and host address because its role is to translate -from network or host numbers to names; NetBIOS domains [RFC-1001, RFC- -1002] are flat because that is appropriate for that application. - -However, there are some guidelines that apply to the "normal" parts of -the name space used for hosts, mailboxes, etc., that will make the name -space more uniform, provide for growth, and minimize problems as -software is converted from the older host table. The political -decisions about the top levels of the tree originated in RFC-920. -Current policy for the top levels is discussed in [RFC-1032]. MILNET -conversion issues are covered in [RFC-1031]. - -Lower domains which will eventually be broken into multiple zones should -provide branching at the top of the domain so that the eventual -decomposition can be done without renaming. Node labels which use -special characters, leading digits, etc., are likely to break older -software which depends on more restrictive choices. - -3.3. Technical guidelines on use - -Before the DNS can be used to hold naming information for some kind of -object, two needs must be met: - - - A convention for mapping between object names and domain - names. This describes how information about an object is - accessed. - - - RR types and data formats for describing the object. - -These rules can be quite simple or fairly complex. Very often, the -designer must take into account existing formats and plan for upward -compatibility for existing usage. Multiple mappings or levels of -mapping may be required. - -For hosts, the mapping depends on the existing syntax for host names -which is a subset of the usual text representation for domain names, -together with RR formats for describing host addresses, etc. Because we -need a reliable inverse mapping from address to host name, a special -mapping for addresses into the IN-ADDR.ARPA domain is also defined. - -For mailboxes, the mapping is slightly more complex. The usual mail -address @ is mapped into a domain name by -converting into a single label (regardles of dots it -contains), converting into a domain name using the usual -text format for domain names (dots denote label breaks), and -concatenating the two to form a single domain name. Thus the mailbox - - - -Mockapetris [Page 9] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by -HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this -design also must take into account the scheme for mail exchanges [RFC- -974]. - -The typical user is not concerned with defining these rules, but should -understand that they usually are the result of numerous compromises -between desires for upward compatibility with old usage, interactions -between different object definitions, and the inevitable urge to add new -features when defining the rules. The way the DNS is used to support -some object is often more crucial than the restrictions inherent in the -DNS. - -3.4. Example name space - -The following figure shows a part of the current domain name space, and -is used in many examples in this RFC. Note that the tree is a very -small subset of the actual name space. - - | - | - +---------------------+------------------+ - | | | - MIL EDU ARPA - | | | - | | | - +-----+-----+ | +------+-----+-----+ - | | | | | | | - BRL NOSC DARPA | IN-ADDR SRI-NIC ACC - | - +--------+------------------+---------------+--------+ - | | | | | - UCI MIT | UDEL YALE - | ISI - | | - +---+---+ | - | | | - LCS ACHILLES +--+-----+-----+--------+ - | | | | | | - XX A C VAXA VENERA Mockapetris - -In this example, the root domain has three immediate subdomains: MIL, -EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named -XX.LCS.MIT.EDU. All of the leaves are also domains. - -3.5. Preferred name syntax - -The DNS specifications attempt to be as general as possible in the rules - - - -Mockapetris [Page 10] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -for constructing domain names. The idea is that the name of any -existing object can be expressed as a domain name with minimal changes. -However, when assigning a domain name for an object, the prudent user -will select a name which satisfies both the rules of the domain system -and any existing rules for the object, whether these rules are published -or implied by existing programs. - -For example, when naming a mail domain, the user should satisfy both the -rules of this memo and those in RFC-822. When creating a new host name, -the old rules for HOSTS.TXT should be followed. This avoids problems -when old software is converted to use domain names. - -The following syntax will result in fewer problems with many -applications that use domain names (e.g., mail, TELNET). - - ::= | " " - - ::=