From 50851586b6af495346ec5397ea97a5279ae6c034 Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Mon, 30 Jul 2001 23:30:09 +0000 Subject: [PATCH] updated drafts --- ...0.txt => draft-ietf-dnsext-aaaa-a6-01.txt} | 308 +++++---- ... => draft-ietf-dnsext-ad-is-secure-03.txt} | 106 ++- ... => draft-ietf-dnsext-axfr-clarify-03.txt} | 143 ++-- ...draft-ietf-dnsext-delegation-signer-00.txt | 557 ---------------- ...draft-ietf-dnsext-delegation-signer-01.txt | 618 ++++++++++++++++++ doc/draft/draft-ietf-dnsext-dhcid-rr-02.txt | 448 ------------- doc/draft/draft-ietf-dnsext-dhcid-rr-03.txt | 504 ++++++++++++++ ...t => draft-ietf-dnsext-unknown-rrs-01.txt} | 112 ++-- ...> draft-ietf-dnsop-inaddr-required-02.txt} | 110 ++-- ...idna-02.txt => draft-ietf-idn-idna-03.txt} | 90 +-- ...ft-ietf-ipngwg-default-addr-select-05.txt} | 494 ++++---------- 11 files changed, 1792 insertions(+), 1698 deletions(-) rename doc/draft/{draft-ietf-dnsext-aaaa-a6-00.txt => draft-ietf-dnsext-aaaa-a6-01.txt} (74%) rename doc/draft/{draft-ietf-dnsext-ad-is-secure-02.txt => draft-ietf-dnsext-ad-is-secure-03.txt} (83%) rename doc/draft/{draft-ietf-dnsext-axfr-clarify-02.txt => draft-ietf-dnsext-axfr-clarify-03.txt} (85%) delete mode 100644 doc/draft/draft-ietf-dnsext-delegation-signer-00.txt create mode 100644 doc/draft/draft-ietf-dnsext-delegation-signer-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dhcid-rr-02.txt create mode 100644 doc/draft/draft-ietf-dnsext-dhcid-rr-03.txt rename doc/draft/{draft-ietf-dnsext-unknown-rrs-00.txt => draft-ietf-dnsext-unknown-rrs-01.txt} (84%) rename doc/draft/{draft-ietf-dnsop-inaddr-required-01.txt => draft-ietf-dnsop-inaddr-required-02.txt} (82%) rename doc/draft/{draft-ietf-idn-idna-02.txt => draft-ietf-idn-idna-03.txt} (82%) rename doc/draft/{draft-ietf-ipngwg-default-addr-select-04.txt => draft-ietf-ipngwg-default-addr-select-05.txt} (88%) diff --git a/doc/draft/draft-ietf-dnsext-aaaa-a6-00.txt b/doc/draft/draft-ietf-dnsext-aaaa-a6-01.txt similarity index 74% rename from doc/draft/draft-ietf-dnsext-aaaa-a6-00.txt rename to doc/draft/draft-ietf-dnsext-aaaa-a6-01.txt index ac62b2d2b3..9c634c094e 100644 --- a/doc/draft/draft-ietf-dnsext-aaaa-a6-00.txt +++ b/doc/draft/draft-ietf-dnsext-aaaa-a6-01.txt @@ -1,11 +1,13 @@ + + Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory -Expires: November 27, 2001 May 27, 2001 +Expires: January 19, 2002 July 19, 2001 Comparison of AAAA and A6 (do we really need A6?) - draft-ietf-dnsext-aaaa-a6-00.txt + draft-ietf-dnsext-aaaa-a6-01.txt Status of this Memo @@ -22,26 +24,23 @@ 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. +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 November 27, 2001. +be January 19, 2002. Abstract -At this moment, there are two resource record types defined for holding -IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6 [Crawford, -2000] . AAAA has been used for IPv6 network operation since 1996. -Questions arose whether we really need A6 or not, or whether it is -really possible to migrate to A6 or not. Some says AAAA is enough and -A6 is not necessary. Some says A6 is necessary and AAAA should get +At this moment, there are two DNS resource record types defined for +holding IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6 +[Crawford, 2000] . AAAA has been used for IPv6 network operation since +1996. Questions arose whether we really need A6 or not, or whether it +is really possible to migrate to A6 or not. Some says AAAA is enough +and A6 is not necessary. Some says A6 is necessary and AAAA should get deprecated. The draft tries to understand pros and cons between these two record @@ -56,10 +55,10 @@ working group minutes for more details. -HAGINO Expires: November 27, 2001 [Page 1] +HAGINO Expires: January 19, 2002 [Page 1] -DRAFT Comparison of AAAA and A6 May 2001 +DRAFT Comparison of AAAA and A6 July 2001 1. A brief summary of the IPv6 resource record types @@ -115,10 +114,10 @@ records. Here is an example taken from RFC2874: -HAGINO Expires: November 27, 2001 [Page 2] +HAGINO Expires: January 19, 2002 [Page 2] -DRAFT Comparison of AAAA and A6 May 2001 +DRAFT Comparison of AAAA and A6 July 2001 $ORIGIN X.EXAMPLE. N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 @@ -174,22 +173,23 @@ and as resolver libraries. On the contrary, the author knows of only one DNS server/resolver implementation that supports A6; BIND9. -HAGINO Expires: November 27, 2001 [Page 3] +HAGINO Expires: January 19, 2002 [Page 3] -DRAFT Comparison of AAAA and A6 May 2001 +DRAFT Comparison of AAAA and A6 July 2001 Almost all of the IPv6-ready operating systems ship with BIND4 or BIND8 -resolver library. Even for the implementations that use resolver -library other than BIND, they only support AAAA. Therefore, they cannot -query A6 records (unless aplications gets linked with BIND9 libraries -explicitly). +resolver library. [need to check situations with resolver libraries +based on non-BIND code] Therefore, they cannot query A6 records (unless +applications gets linked with BIND9 libraries explicitly). 2.2. IPv6 network IPv6 network has been deployed widely since 1996. Though many of the participants consider it to be experimental, commercial IPv6 services -has been deployed since around 1999, especially in asian countries. +has been deployed since around 1999, especially in Asian countries. +Even today, there are numerous IPv6 networks operated just as serious as +IPv4. 2.3. DNS database @@ -223,21 +223,21 @@ non-fragmented A6 records, and AAAA synthesis. AAAA records have been used on IPv6 network (also known as 6bone) since it has started in 1996 and has been working just fine ever since. AAAA -record is a straight extension of A records; it needs a single query- +record is a straight extension of A record; it needs a single query- response roundtrip to resolve a name into an IPv6 address. A6 was proposed to add network renumbering friendliness to AAAA. With AAAA, a full 128bit IPv6 address needs to be supplied in a DNS resource record. Therefore, in the event of network renumber, administrators need to update the whole DNS zone file with the new IPv6 address -prefixes. We will discuss the issues with renumbering in a dedicated -HAGINO Expires: November 27, 2001 [Page 4] +HAGINO Expires: January 19, 2002 [Page 4] -DRAFT Comparison of AAAA and A6 May 2001 +DRAFT Comparison of AAAA and A6 July 2001 +prefixes. We will discuss the issues with renumbering in a dedicated section. 3.2. Fragmented A6 records @@ -257,22 +257,29 @@ there will be more query roundtrips. There are only few possibilities to query fragments in parallel. In the above example, we can resolve A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others. -If the DNS record TTL is smaller than the communication delays between -the querier and the DNS servers, the querier will not be able to -reassemble a complete IPv6 record. With the following records, you -cannot reassemble an IPv6 address if the delay is larger than 1 second. -By the time you get the topmost 64 bits in the address, the lowermost 64 -bits get invalidated. If the querier tries to query lowermost 64 bits -again, the querier can go into an infinite loop (see the section on -security considration). [BIND 9.2.0snap: resolver does not go into -infinite loop, meaning that BIND 9.2.0snap resolver does not really -honor DNS record TTL during A6 reassembly] +At this moment, there is very little documents available, regarding to +the relationship between DNS record TTL and the query delays. For +example, if the DNS record TTL is smaller than the communication delays +between the querier and the DNS servers, what should happen? - ; resolver can go into an infinite loop if RTT > 1 second - $ORIGIN X.EXAMPLE. - $TTL 1 - N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 - SUBNET-1.IP6 A6 0 2345:00C1:CA11:1:: +o If we compute DNS record TTL based on the wallclock on the DNS server + side, the DNS records are already expired and the querier will not be + able to reassemble a complete IPv6 record. Worse, by setting up + records with very low TTL, we can let recursive DNS resolvers to go + into infinite loop by letting them chase a wrong A6 chain (see the + section on security considration) [BIND 9.2.0snap: resolver does not + go into infinite loop, meaning that BIND 9.2.0snap resolver does not + really honor DNS record TTL during A6 reassembly]. + +o If we compute it starting from the time the querier got the record, we + will have some jitter in TTL computation among multiple queriers. If + the query delays are long enough, the querier would end up having + inconsistent A6 fragments, and the IPv6 address can be bogus after + reassembly. With record types other than A6, we had no such problem, + since we have never tried to reassemble an address out of multiple DNS + records (with CNAME chain chasing a similar problem can arise, but the + failure mode is much simpler to diagnose as the records are considered + as an atomic entity). Some says that caches will avoid querying fragmented A6s again and again. However, most of the library resolver implementations do not @@ -281,6 +288,14 @@ nameserver will not be decreased by the cached records. The TTL problem (see above) is unavoidable for the library resolver without cache. [XXX will they interpret TTL field? BIND8 resolver does not] + + + +HAGINO Expires: January 19, 2002 [Page 5] + + +DRAFT Comparison of AAAA and A6 July 2001 + If some of the fragments are DNSSEC-signed and some are not, how should we treat that address? RFC2874 section 6 briefly talks about it, not sure if complete answer is given. @@ -289,14 +304,6 @@ It is much harder to implement A6 fragment reassemble code, than to implement AAAA record resolver. AAAA record resolver can be implemented as a straight extension of A record resolver. - - - -HAGINO Expires: November 27, 2001 [Page 5] - - -DRAFT Comparison of AAAA and A6 May 2001 - o It is much harder to design timeout handling for the A6 reassembly. There would be multiple timeout parameters, including (1) communcation timeout for a single A6 fragment, (2) communcation timeout for the @@ -318,9 +325,9 @@ In RFC2874, a suggestion is made to use limited number of fragments per an IPv6 address. However, there is no protocol limitation defined. The lack makes it easier for malicious parties to impose DoS attacks using lots of A6 fragments (see the section on security consideration). [BIND -9.2.0snap: The implementation limits the number of fragments to be -smaller than 16; It is not a protocol limitation but an implementation -choice. Not sure if it is the right choice or not] +9.2.0snap: The implementation limits the number of fragments within an +A6 chain to be smaller than 16; It is not a protocol limitation but an +implementation choice. Not sure if it is the right choice or not] With fragmented A6 records, in multi-prefix network configuration, it is not possible for us to limit the address on the DNS database to the @@ -331,6 +338,23 @@ to do so. It becomes mandatory for us to define the whole IPv6 address by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6 (renumber friendliness) goes away. + + + + + + + + + + + + +HAGINO Expires: January 19, 2002 [Page 6] + + +DRAFT Comparison of AAAA and A6 July 2001 + ; with the following record we would advertise both records $ORIGIN X.EXAMPLE. N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 @@ -349,13 +373,6 @@ by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6 A6 resource record type and A6 fragment/reassembly were introduced to help administrators on network renumber. When network gets renumbered, the administrator needs to update A6 fragment for the higher address - - -HAGINO Expires: November 27, 2001 [Page 6] - - -DRAFT Comparison of AAAA and A6 May 2001 - bits (prefixes) only. Again, we will discuss the issues with renumbering in a dedicated section. @@ -368,7 +385,7 @@ fragmented A6 records when we find a need for A6. >From the packet format point of view, the approach has no benefit against AAAA. Rather, there is a one-byte overhead to every -(unfragmented) A6 record compared to an AAAA record. +(unfragmented) A6 record compared to a AAAA record. If the nameserver/resolver programs hardcode A6 processing to handle no fragments, there will be no future possibility for us to introduce @@ -387,14 +404,22 @@ At this moment, end hosts support AAAA records only. Some people would like to see A6 deployment in DNS databases even with the lack of end hosts support. To workaround the deployment issues of A6, the following approach is proposed in IETF50 dnsext working group slot. It is called -``AAAA synthesis'': +``AAAA synthesis'' [Austein, 2001] : + + + + +HAGINO Expires: January 19, 2002 [Page 7] + + +DRAFT Comparison of AAAA and A6 July 2001 o Deploy A6 DNS records worldwide. The proposal was not specific about whether we would deploy fragmented A6 records, or non-fragmented A6 records (``A6 0''). o When a host queries AAAA record to a DNS server, the DNS server - queries A6 fragments, reassemble it, and respond with an AAAA record. + queries A6 fragments, reassemble it, and respond with a AAAA record. The approach needs to be diagnosed/specified in far more detail. For example, the following questions need to be answered: @@ -409,12 +434,6 @@ o Which nameserver should synthesize the AAAA record, in the DNS recursize query chain? Is the synthesis mandatory for every DNS server implementation? - -HAGINO Expires: November 27, 2001 [Page 7] - - -DRAFT Comparison of AAAA and A6 May 2001 - o What should we do if the A6 reassembly takes too much time? o What should we do about DNSSEC signatures? @@ -445,7 +464,14 @@ o Query AAAA records. o Query A records. o Sort the result based on destination address ordering rule. An - example of the ordering rule is presented as a draft [Draves, 2000] . + example of the ordering rule is presented as a draft [Draves, 2001] . + + + +HAGINO Expires: January 19, 2002 [Page 8] + + +DRAFT Comparison of AAAA and A6 July 2001 o Contact the destination addresses in sequence. @@ -467,13 +493,6 @@ connectivity today. If ISPs do assign static IPv6 address block to the customers, there is no need to renumber customer network that frequently (unless the customer decides to switch the upstream ISPs that often). NOTE: Roaming dialup users, like those who carry laptop computers - - -HAGINO Expires: November 27, 2001 [Page 8] - - -DRAFT Comparison of AAAA and A6 May 2001 - worldwide, seems to have a different issue from stationary dialup users. See [Hagino, 2000] for more discussions. @@ -494,17 +513,32 @@ presentation by JINMEI Tatsuya regarding to site renumbering experiment. It is recommend to read through the IETF49 minutes and slides. [XXX Fred Baker had a draft on this - where?] For the network renumbering to be successful, no configuration files should have hardcoded (numeric) IP -addresses. It is a very hard requrement to meet. We fail to satisfy +addresses. It is a very hard requirement to meet. We fail to satisfy this in many of the network renumbering events, and the failure causes a lot of troubles. At this moment there is no mechanism defined for ISPs to renumber -downstream customers at will. Router renumbering protocol [Crawford, -2000] is defined only for a single administrative domain (customers will -not want to share IPsec authentication key for routers, with the -upstream ISP). Even though it may sound interesting for ISPs, it would -cause a lot of (social and political) issues in doing so, so the author -would say it is rather unrealistic to pursue this route. +downstream customers at will. Even though it may sound interesting for +ISPs, it would cause a lot of (social and political) issues in doing so, +so the author would say it is rather unrealistic to pursue this route. +The only possible candidate, router renumbering protocol [Crawford, +2000] does not really fit into the situation. The protocol is defined +using IPsec authentication over site-local multicast packets. It would +be cumbersome to run router renumbering protocol across multiple + + +HAGINO Expires: January 19, 2002 [Page 9] + + +DRAFT Comparison of AAAA and A6 July 2001 + +administrative domains, as (1) customers will not want to share IPsec +authentication key for routers with the upstream ISP, and (2) customer +network will be administered as a separate site from the upstream ISP +(Even though router renumbering protocol could be used with unicast +addresess, it is not realistic to assume that we can maintain the list +of IPv6 addresses for all the routers in both customers' and ISPs' +networks). A6 was designed to help administators update zone files during network renumbering events. Even with AAAA, zone file modification itself is @@ -516,7 +550,10 @@ renumbering the network. With A6, we need to sign upper bits only with DNSSEC keys. Therefore, A6 will impose less zone signing cost on the event of network renumbering. As seen above, it is questionable if we renumber network that often, so it is questionable if A6 brings us an -overall benefit. +overall benefit. Note, however, even if we use A6 to facilitate more +frequent renumbering and lower signing cost, all glue records has to be +installed as non-fragmented A6 records (``A6 0''), and required to be +signed again on renumbering events. 5. Security consideration @@ -526,13 +563,6 @@ a brief summary: o There will be a higher delay imposed by query/reply roundtrips for fragmented A6 records. This could affect every services that relies - - -HAGINO Expires: November 27, 2001 [Page 9] - - -DRAFT Comparison of AAAA and A6 May 2001 - upon DNS records. o There is no upper limit defined for the number of A6 fragments for @@ -554,17 +584,24 @@ We would like to go into more details for some of these. When a DNS server is configured for AAAA synthesis, malicious parties can impose DoS attacks using the interaction between DNS TTL and query + + +HAGINO Expires: January 19, 2002 [Page 10] + + +DRAFT Comparison of AAAA and A6 July 2001 + delays. The attack can chew CPU time and/or memory, as well as some network bandwidth on a victim nameserver, by the following steps: -o Bad guy configures a record with very complex A6 chain, onto some - nameservers. (bad guy has to have controls over the servers). The - nameservers can be located anywhere in the world. The A6 chain should - have a very low TTL (like 1 or 0 seconds). The attack works better if - we have higher delays between the victim nameservers and the +o A bad guy configures a record with very complex A6 chain, onto some + nameservers. (the bad guy has to have controls over the servers). + The nameservers can be located anywhere in the world. The A6 chain + should have a very low TTL (like 1 or 0 seconds). The attack works + better if we have higher delays between the victim nameservers and the nameservers that serve A6 fragments. -o Bad guy queries the record using AAAA request, to the victim +o The bad guy queries the record using AAAA request, to the victim nameserver. o The victim nameserver will try to reassemble A6 fragments. During the @@ -574,6 +611,10 @@ o The victim nameserver will try to reassemble A6 fragments. During the (more traffic). The server can go into an infinite loop, if it tries to query the expired A6 fragments again. +Note, however, this problem could be considered as a problem in +recursize resolvers in general (like CNAME and NS chasing); A6 and AAAA +synthesis makes the problem more apparent, and more complex to diagnose. + To remedy this problem, we have a couple of solutions: (1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the @@ -584,14 +625,6 @@ To remedy this problem, we have a couple of solutions: (3) Impose a protocol limitation to the number of A6 fragments. - - - -HAGINO Expires: November 27, 2001 [Page 10] - - -DRAFT Comparison of AAAA and A6 May 2001 - (4) Do not query the expired records in A6 chain again. In other words, implement resolvers that ignore TTL on DNS records. Not sure if it is the right thing to do. @@ -610,15 +643,22 @@ believes that we need to pick one of them. Given the unlikeliness of frequent network renumbering, the author believes that the A6's benefit in lower zone signing cost is not significant. The benefit of A6 (in zone signing cost) is much less than + + +HAGINO Expires: January 19, 2002 [Page 11] + + +DRAFT Comparison of AAAA and A6 July 2001 + the expected complication that will be imposed by A6 operations. >From the above discussions, the author suggests to keep AAAA and -deprecate A6. The author believes that A6 can cause a lot of problem -than the benefits it may have. A6 will make IPv6 DNS operation more -complicated and vulnerable to attacks. AAAA is proven to work right in -our IPv6 network operation since 1996. AAAA has been working just fine -in existing IPv6 networks, and the author believes that it will in the -coming days. +deprecate A6 (move A6 document to historic state). The author believes +that A6 can cause a lot of problem than the benefits it may have. A6 +will make IPv6 DNS operation more complicated and vulnerable to attacks. +AAAA is proven to work right in our IPv6 network operation since 1996. +AAAA has been working just fine in existing IPv6 networks, and the +author believes that it will in the coming days. @@ -633,9 +673,13 @@ M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering" in RFC2874 (July 2000). ftp://ftp.isi.edu/in-notes/rfc2874.txt. -Draves, 2000. -Richard Draves, "Default Address Selection for IPv6," Internet Draft -(November 2000). work in progress material. +Austein, 2001. +R. Austein, "Tradeoffs in DNS support for IPv6" in draft-ietf-dnsext- +ipv6-dns-tradeoffs-00.txt (July 2001). work in progress material. + +Draves, 2001. +Richard Draves, "Default Address Selection for IPv6" in draft-ietf- +ipngwg-default-addr-select-04.txt (May 2001). work in progress material. Hagino, 2000. Jun-ichiro Hagino and Kazu Yamamoto, "Requirements for IPv6 dialup PPP @@ -644,13 +688,6 @@ work in progress material. Crawford, 2000. Matt Crawford, "Router Renumbering for IPv6" in RFC2894 (August 2000). - - -HAGINO Expires: November 27, 2001 [Page 11] - - -DRAFT Comparison of AAAA and A6 May 2001 - ftp://ftp.isi.edu/in-notes/rfc2894.txt. Thomson, 1998. @@ -663,6 +700,15 @@ Change history none. + + + + +HAGINO Expires: January 19, 2002 [Page 12] + + +DRAFT Comparison of AAAA and A6 July 2001 + Acknowledgements The draft was written based on discussions in IETF IPv6 and dnsext @@ -705,5 +751,17 @@ Author's address -HAGINO Expires: November 27, 2001 [Page 12] + + + + + + + + + + + + +HAGINO Expires: January 19, 2002 [Page 13] diff --git a/doc/draft/draft-ietf-dnsext-ad-is-secure-02.txt b/doc/draft/draft-ietf-dnsext-ad-is-secure-03.txt similarity index 83% rename from doc/draft/draft-ietf-dnsext-ad-is-secure-02.txt rename to doc/draft/draft-ietf-dnsext-ad-is-secure-03.txt index e3025e99a9..70e805d2e1 100644 --- a/doc/draft/draft-ietf-dnsext-ad-is-secure-02.txt +++ b/doc/draft/draft-ietf-dnsext-ad-is-secure-03.txt @@ -1,7 +1,7 @@ DNSEXT Working Group Brian Wellington INTERNET-DRAFT Olafur Gudmundsson - June 2001 + July 2001 Updates: RFC 2535 @@ -32,7 +32,7 @@ Status of this Memo Comments should be sent to the authors or the DNSEXT WG mailing list namedroppers@ops.ietf.org - This draft expires on December 18, 2001. + This draft expires on January 17, 2002. Copyright Notice @@ -50,9 +50,9 @@ Abstract -Expires December 2001 [Page 1] +Expires January 2002 [Page 1] -INTERNET-DRAFT AD bit set on secure answers June 2001 +INTERNET-DRAFT AD bit set on secure answers July 2001 1 - Introduction @@ -70,7 +70,7 @@ INTERNET-DRAFT AD bit set on secure answers June 2001 This draft proposes to redefine the AD bit such that it is only set if all data in the response has been cryptographically verified. Thus, a response containing properly delegated insecure data will not - have AD set, as will a response from a server configured without + have AD set, neither will a response from a server configured without DNSSEC keys. As before, data which failed to verify will not be returned. An application can then use the value of the AD bit to determine if the data is secure or not. @@ -101,16 +101,18 @@ INTERNET-DRAFT AD bit set on secure answers June 2001 "The AD bit MUST NOT be set on a response unless all of the RRsets in the answer and authority sections of the response are Authenticated." + "The AD bit SHOULD be set if and only if all RRs in the answer + section and any relevant negative response RRs in that authority - - -Expires December 2001 [Page 2] +Expires January 2002 [Page 2] -INTERNET-DRAFT AD bit set on secure answers June 2001 +INTERNET-DRAFT AD bit set on secure answers July 2001 + section are Authenticated." + AD should be set if and only if all RRs in the answer section, and any relevant negative response RRs in the authority section are Authenticated. @@ -122,12 +124,13 @@ INTERNET-DRAFT AD bit set on secure answers June 2001 authentication such as TSIG[RFC2845] or SIG(0)[RFC2931], and the resolver policy is that it can trust the server. - A DNS server following this modified specification will only set the - AD bit when it has cryptographically verified the data in the answer. - In the case of a primary server for a secure zone, the data MAY be - considered Authenticated, depending on local policy. Secondary - servers SHOULD NOT consider data Authenticated unless the zone was - transfered securely or the data was verified. + Any DNS server supporting the OK bit MUST support this definition of + the AD bit. A DNS server following this modified specification will + only set the AD bit when it has cryptographically verified the data + in the answer. In the case of a primary server for a secure zone, + the data MAY be considered Authenticated, depending on local policy. + Secondary servers SHOULD NOT consider data Authenticated unless the + zone was transfered securely or the data was verified. 3 - Interpretation of the AD bit @@ -140,7 +143,29 @@ INTERNET-DRAFT AD bit set on secure answers June 2001 This document redefines a bit in the DNS header. If a resolver trusts the value of the AD bit, it must be sure that the server is - using the updated definition. + using the updated definition, which is any server supporting the OK + bit. + + + + + + + + + + + + + + + + + +Expires January 2002 [Page 3] + +INTERNET-DRAFT AD bit set on secure answers July 2001 + 5 - IANA Considerations: @@ -159,14 +184,6 @@ References: [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 2535, March 1999. - - - -Expires December 2001 [Page 3] - -INTERNET-DRAFT AD bit set on secure answers June 2001 - - [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, ``Secret Key Transaction Authentication for DNS (TSIG)'', RFC 2845, May 2000. @@ -198,6 +215,14 @@ Full Copyright Statement 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 + + + +Expires January 2002 [Page 4] + +INTERNET-DRAFT AD bit set on secure answers July 2001 + + 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 @@ -218,5 +243,36 @@ Full Copyright Statement -Expires December 2001 [Page 4] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires January 2002 [Page 5] diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-02.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-03.txt similarity index 85% rename from doc/draft/draft-ietf-dnsext-axfr-clarify-02.txt rename to doc/draft/draft-ietf-dnsext-axfr-clarify-03.txt index 2482529c86..81e2b8e880 100644 --- a/doc/draft/draft-ietf-dnsext-axfr-clarify-02.txt +++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-03.txt @@ -1,7 +1,6 @@ - INTERNET-DRAFT Andreas Gustafsson -draft-ietf-dnsext-axfr-clarify-02.txt Nominum Inc. - June 2001 +draft-ietf-dnsext-axfr-clarify-03.txt Nominum Inc. + July 2001 DNS Zone Transfer Protocol Clarifications @@ -50,9 +49,9 @@ Abstract -Expires December 2001 [Page 1] +Expires January 2002 [Page 1] -draft-ietf-dnsext-axfr-clarify-02.txt June 2001 +draft-ietf-dnsext-axfr-clarify-03.txt July 2001 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -74,7 +73,9 @@ draft-ietf-dnsext-axfr-clarify-02.txt June 2001 If the master server is unable or unwilling to provide a zone transfer, it MUST respond with a single DNS message containing an - appropriate RCODE other than NOERROR. + appropriate RCODE other than NOERROR. If the master is not + authoritative for the requested zone, the RCODE SHOULD be 9 + (NOTAUTH). Slave servers should note that some master server implementations will simply close the connection when denying the slave access to the @@ -101,16 +102,17 @@ draft-ietf-dnsext-axfr-clarify-02.txt June 2001 A master MAY transmit multiple answer RRs per response message up to the largest number that will fit within the 65535 byte limit on TCP + + + +Expires January 2002 [Page 2] + +draft-ietf-dnsext-axfr-clarify-03.txt July 2001 + + DNS message size. In the case of a small zone, this can cause the entire transfer to be transmitted in a single response message. - - -Expires December 2001 [Page 2] - -draft-ietf-dnsext-axfr-clarify-02.txt June 2001 - - Slaves MUST accept messages containing any number of answer RRs. For compatibility with old slaves, masters that support sending multiple answers per message SHOULD be configurable to revert to the @@ -156,17 +158,18 @@ draft-ietf-dnsext-axfr-clarify-02.txt June 2001 response SHOULD have a question section identical to that in the request. Subsequent messages SHOULD NOT have a question section, though the final message MAY. The receiving slave server MUST accept + + + +Expires January 2002 [Page 3] + +draft-ietf-dnsext-axfr-clarify-03.txt July 2001 + + any combination of messages with and without a question section. 3.5. The authority section - - -Expires December 2001 [Page 3] - -draft-ietf-dnsext-axfr-clarify-02.txt June 2001 - - The master server MUST transmit messages with an empty authority section. Slaves MUST ignore any authority section contents they may receive from masters that do not comply with this requirement. @@ -175,7 +178,8 @@ draft-ietf-dnsext-axfr-clarify-02.txt June 2001 The additional section MAY contain additional RRs such as transaction signatures. The slave MUST ignore any unexpected RRs in the - additional section. + additional section. It MUST NOT treat additional section RRs as zone + data. 4. Zone data @@ -210,29 +214,30 @@ draft-ietf-dnsext-axfr-clarify-02.txt June 2001 RFC1034 states that "The first and last messages must contain the data for the top authoritative node of the zone". This is not consistent with existing practice. All known master implementations - send, and slave implementations expect to receive, the zone's SOA RR - as the first and last record of the transfer. Any other RRs at the - zone's apex are transmitted only once. - - Therefore, the quoted sentence is hereby changed to read "The first -Expires December 2001 [Page 4] +Expires January 2002 [Page 4] -draft-ietf-dnsext-axfr-clarify-02.txt June 2001 +draft-ietf-dnsext-axfr-clarify-03.txt July 2001 - and last RR transmitted must be the SOA record of the zone". + send, and slave implementations expect to receive, the zone's SOA RR + as the first and last record of the transfer. + + Therefore, the quoted sentence is hereby superseded by the sentence + "The first and last RR transmitted must be the SOA record of the + zone". The initial and final SOA record MUST be identical, with the possible exception of case and compression. In particular, they MUST have the - same serial number. + same serial number. The slave MUST consider the transfer to be + complete when, and only when, it has received the message containing + the second SOA record. The transmission order of all other RRs in the zone is undefined. - Each of them MUST be transmitted exactly once. As some older masters - do not comply with this requirement, slaves SHOULD silently ignore - duplicate RRs for interoperability. + Each of them SHOULD be transmitted only once, and slaves MUST ignore + any duplicate RRs received. 6. Security Considerations @@ -256,14 +261,23 @@ Acknowledgements Many people have contributed input and commentary to earlier versions of this document, including but not limited to Bob Halley, Dan - Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Levon Esibov, - Mark Andrews, Michael Patton, Peter Koch, and Sam Trenholme. + Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz, + Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam + Trenholme, and Brian Wellington. References [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987. + + + +Expires January 2002 [Page 5] + +draft-ietf-dnsext-axfr-clarify-03.txt July 2001 + + [RFC1035] - Domain Names - Implementation and Specifications, P. Mockapetris, November 1987. @@ -271,14 +285,6 @@ References S. Bradner, BCP 14, March 1997. [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P. - - - -Expires December 2001 [Page 5] - -draft-ietf-dnsext-axfr-clarify-02.txt June 2001 - - Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000. Author's Address @@ -320,6 +326,14 @@ Full Copyright Statement 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 + + + +Expires January 2002 [Page 6] + +draft-ietf-dnsext-axfr-clarify-03.txt July 2001 + + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." @@ -330,5 +344,46 @@ Full Copyright Statement -Expires December 2001 [Page 6] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires January 2002 [Page 7] diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-00.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-00.txt deleted file mode 100644 index ca51f4368e..0000000000 --- a/doc/draft/draft-ietf-dnsext-delegation-signer-00.txt +++ /dev/null @@ -1,557 +0,0 @@ - DNSEXT Working Group Olafur Gudmundsson - INTERNET-DRAFT May 2001 - - - Updates: RFC 1035, RFC 2535, RFC 3008. - - - Delegation Signer record in parent. - - -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 DNSEXT WG mailing list - namedroppers@ops.ietf.org - - This draft expires on November 30, 2001. - - Copyright Notice - - Copyright (C) The Internet Society (2001). All rights reserved. - - - -Abstract - - One of the biggest problems in DNS occur when records of the same type - can appear on both sides of an delegation. If the contents of these - sets differs clients can get confused. RFC2535 KEY records follows - the same model as for NS records, parent is responsible for the - records but the child is responsible for the contents. This document - - - -Gudmundsson Expires November 2001 [Page 1] - -INTERNET-DRAFT Delegation Signer Record May 2001 - - - proposes to store a different record in the parent that specifies - which one of the child's keys can sign the child's KEY set. This - change is not backwards compatible with RFC2535 but simplifies DNSSEC - operation. - - -1 - Introduction - - Familiarity with the DNS system [RFC1035], DNS security extensions - [RFC2535] and DNSSEC terminology [RFC3090] is important. - - When the same data can reside in two administratively different DNS - zones sources it is common that the data gets out of sync. NS record - in a zone indicates that there is a delegation at this name and the NS - record lists the authorative servers for the real zone. Based on - actual measurements 10-30% of all delegations in the Internet have - differing NS sets at parent and child. There are number of reasons for - this including lack of communication between parent and child, and - bogus nameservers are listed to meet registrar requirements. - - DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its - KEY set signed by the parent to create a verifiable chain of KEYs. - There is some debate, where the signed KEY set should reside, - parent[Parent] or child[RFC2535]. If the KEY set resides at the child, - frequent communication is needed between the two to transmit keysets - up to parent and signatures down to child. If the KEY set resides at - the parent[Parent] the communication is reduced having only child send - updated key sets to parent. DNSSEC requires that the parent store NULL - key set for unsecure children, this complicates resolution process as - in many cases as servers for both parent and child need to be queried - for KEY set. - - Further complication of the DNSSEC KEY model is that KEY record is - used to store DNS zone keys and public keys for other protocols. This - can lead to large key sets at delegation points. There are number of - potential problems with this. - 1. KEY set may become quite large if many applications/protocols store - their keys at the zone apex. Example of protocols are IPSEC, HTTP, - SMTP, SSH etc. - 2. Key set may require frequent updates, - 3. Probability of compromised/lost keys increases and triggers - emergency key rollover. - 4. Parent may refuse sign key sets with NON DNS zone keys. - 5. Parent may not have QoS on key changes that meets child's - expectations. - - Given these and other reasons there is good reason to explore - alternatives to using only KEY records to create chain of trust. - - - -Gudmundsson Expires November 2001 [Page 2] - -INTERNET-DRAFT Delegation Signer Record May 2001 - - - Some of these problems can be reduced or eliminated by operational - rules or protocol changes. To reduce the number of keys at apex, rule - to require applications to store their KEY records at the SRV name for - that application is one possibility. Another is to restrict KEY record - to DNS keys only and create a new type for all non DNS keys. Third - possible solution is to ban the storage of non DNS related keys at - zone apex. There are other possible solutions but they are outside the - scope of this draft. - -1.1 - Delegation Signer Record model - - This draft proposes an alternative to the KEY record chain of trust, - that uses a special record that can only reside at the parent. This - record will identify the key(s) that child will use to self sign its - KEY set. - - The chain of trust is now established by verifying the parent KEY set, - the DK set from the parent and then the KEY set at the child. This is - cryptographically equivalent to just using KEY records. - - Communication between the parent and child is reduced as the parent - only needs to know of changes in DNS zone KEY records used to sign the - apex KEY set. If other KEY records are stored at the zone apex, the - parent does not to be aware of them. - - If child wants to have frequent key rollover for its DNS keys it is - possible to do that without communicating to the parent, in this case - the child uses on strong key to sign its apex KEY set and other - smaller keys to sign the zone for a short time. - - This approach has the advantage that communication between the parent - and child is kept to a minimum and the child is the authority for the - KEY set with full control over the contents. The load on the parent - is reduced and it can maintain its zone as it sees fit. - - The main disadvantage of this approach is to double the number of - signatures that need to be verified for the each KEY set. The - advantage on the other hand is that child only needs to update data in - parent when it changes DNS signing key. - - - - - - - - - - - - -Gudmundsson Expires November 2001 [Page 3] - -INTERNET-DRAFT Delegation Signer Record May 2001 - - -1.2 - Reserved words - - The key words "CAN", "MUST", "MUST NOT", "SHOULD", "DOES NOT" and - "MAY" in this document are to be interpreted as described in RFC2119. - - - -2 - DK (Delegation KEY signer) record: - -2.1 Protocol change - - DK record MUST only appear at a delegation in the parent zone. The - record lists the child's keys that CAN sign the child's key set. - Insecure delegation MUST NOT have a DK record, the presence of DK - record SHOULD be considered a hint that the child might be secure. - Resolver MUST only trust KEY records that match a DK record. - NOTE: It has been suggested that NULL DK record for insecure children - is better than no record. The advantage is to have authenticated - denial of child's security status, the drawback is for large - delegating zones there will be many NULL DK records. - WG please comment on which approach is better. - - Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section - 2.7: Delegating zones MUST NOT store KEY records for delegations. The - only records that can appear at delegation in parent are NS, SIG, NXT - and DK. - - Zone MUST self sign its apex KEY set, it SHOULD sign it with a key - that corresponds to a DK record in the parent. - - If child apex KEY RRset is not signed with one of the keys specified - in the DK record the child is locally secure[RFC3090] and SHOULD only - be considered secure the resolver has been instructed to trust the key - used, via preconfiguration. - - Authorative server answering a query, that has the OK bit set[OKbit], - MUST include the DK set in the additional section if the answer is a - referral and there is space. Caching servers MAY return the DK record - in the additional section under the same condition. - - - - - - - - - - - - -Gudmundsson Expires November 2001 [Page 4] - -INTERNET-DRAFT Delegation Signer Record May 2001 - - -2.1.1 - Comments on protocol change - - DK record is the first DNS record to be only stored at the upper side - of a delegation. NS records appear at both sides as do SIG and NXT. - All other records can only appear at the lower side. This will cause - some problems as servers authorative for parent may reject DK record - even if the server understands unknown types. Similarly a nameserver - acting as a authorative for child and as a caching recursive server - may never return the DK record. A caching server does not care from - which side DK record comes from and thus should not have to be changed - if it supports unknown types. - - Secure resolvers need to know about the DK record and how to interpret - it. In the worst case, introducing the DK record, doubles the - signatures that need to be checked to validate a KEY set, this is a - small price to pay to have a cleaner delegations structure. - - Over the years there has been various discussions on that the - delegation model in DNS is broken as there is no real good way to - assert if delegation exists. In RFC2535 version of DNSSEC the - authentication of a delegation is the NS bit in the NXT bitmap at the - delegation point. Something more explicit is needed and the DK record - addresses this for secure delegations. - -2.2 Wire format of DK record - - There are two possible ways to represent the DK record at the parent - and this draft presents both for discussion, the WG is expected to - select one and only one. The two formats is either to reuse the RDATA - definition of the KEY record and the other one is to store an - identifier of the key. - -2.2.1 Compact DK format - - The DK record consists of algorithm, size, key tag and SHA-1 digest of - the public key KEY record allowed to sign the child's delegation. - - 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 tag | size | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | algorithm | SHA-1 digest | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | (20 bytes) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - - -Gudmundsson Expires November 2001 [Page 5] - -INTERNET-DRAFT Delegation Signer Record May 2001 - - - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | | - +-+-+-+-+-+-+-+-+ - - The key tag is calculated as specified in RFC2535, the size is the - size of the public key in bits as specified in the document specifying - the algorithm. Algorithm MUST be an algorithm number assigned in the - range 1..251. The SHA-1 digest is calculated over the canonical name - of the delegation followed by the RDATA of the KEY record. - -2.2.1.1 Justifications for fields - - The algorithm and size fields are here to allow resolvers to quickly - identify the candidate KEY records to examine. Key Tag is to allow - quick check if this is a good candidate. The key tag is redundant but - provides some greater assurance than SHA-1 digest on its own. SHA-1 is - a strong cryptographic checksum, it is hard for attacker to generate a - KEY record that has the same SHA-1 digest. Making sure that the KEY - record is a valid public key is much harder. Combining the SHA-1 all - the checks, the task of the attacker is as hard breaking the public - key. Even if someone creates a database of all SHA-1 key hashes seen - so far, the addition of the name renders that database useless for - attacks. - -2.2.2 Verbose DK format - - The RDATA of the DK record is identical to the KEY record as specified - in RFC2535 sections 3.1, 3.1.2, 3.1.3 and 3.2. - -2.3 Presentation format of DK record - - Only one of these subsections will be used in RFC. - - - - - - - - - - - - - - - - -Gudmundsson Expires November 2001 [Page 6] - -INTERNET-DRAFT Delegation Signer Record May 2001 - - -2.3.1 Presentation format for the compact DK record - - The presentation format of DK record consists of 2 numbers, followed - by either the name of the signature algorithm or the algorithm number. - The digest is to be presented in hex. - -2.3.2 Presentation format for the verbose DK record - - Identical to KEY record. - -2.4 Justifications for each format - -2.4.1 Justification for compact format - - This format allows concise representation of the keys that child will - use, thus keeping down the size of the answer for the delegation, - reducing the probability of packet overflow. The SHA-1 hash is strong - enough to uniquely identify the key. This is similar to PGP footprint. - - Each DK record has RDATA size of 25, regardless of the size of the - keys, keeping the answers from the parent smaller than if public key - was used. The smallest currently defined KEY record RDATA is 70 bytes. - - Compact DK format is also better suited to list trusted keys for - islands of security in configuration files. - -2.4.2 Justifications for verbose format - - Even though this format results in larger DK set the effect on - implementations is smaller. Supporting I/O for DK record type is a - matter of reusing the code for reading/writing KEY records. For - finding DK to KEY matches simple compare will do, instead of digesting - the public KEYS. - -3 Resolver Example - - This example uses compact notation for both DK and KEY for clarity. - - To create a chain of trust resolver goes from trusted KEY to DK to - KEY. - - Assume the key for domain example. is trusted. In zone example we - have - example. KEY - secure.example. DK tag=12345 size=1024 alg=dsa - secure.example. NS ns1.secure.example. - NS ns1.secure.example. - secure.example. NXT NS SIG NXT DK tail.example. - - - -Gudmundsson Expires November 2001 [Page 7] - -INTERNET-DRAFT Delegation Signer Record May 2001 - - - secure.example. SIG(NXT) - secure.example. SIG(DK) - - In zone secure.example. we have - secure.example. SOA - secure.example. NS ns1.secure.example. - NS ns1.secure.example. - secure.example. KEY - KEY - KEY - secure.example. SIG(KEY) - secure.example. SIG(SOA) - secure.example. SIG(NS) - - In this example the trusted key for example signs the DK record for - secure.example, making that a trusted record. The DK record states - what key is supposed to sign the KEY record at secure.example. In - this example secure.example. has three KEY records and the correct one - signs the KEY set, thus the key set is validated and trusted. One of - the other keys in the keyset actually signs the zone data, and - resolvers will trust the signatures as the key appears in the KEY set - that was correctly signed. - - This example has only one DK record for the child but there no reason - to outlaw multiple DK records. More than one DK record is needed - during signing key rollover. - -4 Acknowledgments - - Number of people have over the last few years contributed number of - ideas that are captured in this document. - -4 - Security Considerations: - - This document proposes a change to the validation chain of KEY records - in DNS. The change in is not believed to reduce security in the - overall system, in RFC2535 DNSSEC child must communicate keys to - parent and prudent parents will require some authentication on that - handshake. The modified protocol will require same authentication but - allows the child to exert more local control over its own KEY set. - - In the compact representation of DK record, there is a possibility - that an attacker can generate an valid KEY that matches all the checks - thus starting to forge data from the child. This is considered - impractical as on average more than 2**80 keys must be generated - before one is found that will match. - - - - - -Gudmundsson Expires November 2001 [Page 8] - -INTERNET-DRAFT Delegation Signer Record May 2001 - - - DK record is a change to DNSSEC protocol and there is some installed - base of implementations, as well as text books on how to set up - secured delegations. Implementations that do not understand DK record - will not be able to follow the KEY to DK to KEY chain and consider all - zone secured that way insecure. - -5 - IANA Considerations: - - IANA needs to allocate RR type code for DK from the standard RR type - space. - -References: - -[RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification'', STD 13, RFC 1035, November 1987. - - -[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC - 2535, March 1999. - -[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing - Authority'', RFC 3008, November 2000. - -[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone - Status'', RFC 3090, March 2001. - -[IDbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in - progress , April 2001. - -[Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone - KEYs'', work in progress , May 2001. - -Author Address - - Olafur Gudmundsson - 3826 Legation Street, NW - Washington, DC, 20015 - USA - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). 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 - - - -Gudmundsson Expires November 2001 [Page 9] - -INTERNET-DRAFT Delegation Signer Record May 2001 - - - 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." - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gudmundsson Expires November 2001 [Page 10] - diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-01.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-01.txt new file mode 100644 index 0000000000..9c3c892d3e --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-delegation-signer-01.txt @@ -0,0 +1,618 @@ + + + + + + + DNSEXT Working Group Olafur Gudmundsson + INTERNET-DRAFT July 2001 + + + Updates: RFC 1035, RFC 2535, RFC 3008. + + + Delegation Signer record in parent. + + +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 DNSEXT WG mailing list + namedroppers@ops.ietf.org + + This draft expires on January 15, 2002. + + Copyright Notice + + Copyright (C) The Internet Society (2001). All rights reserved. + + + +Abstract + + One of the biggest problems in DNS occur when records of the same type + can appear on both sides of an delegation. If the contents of these + sets differs clients can get confused. RFC2535 KEY records follows + the same model as for NS records, parent is responsible for the + records but the child is responsible for the contents. This document + + + +Gudmundsson Expires January 2002 [Page 1] + +INTERNET-DRAFT Delegation Signer Record July 2001 + + + proposes to store a different record in the parent that specifies + which one of the child's keys are authorized to sign the child's KEY + set. This change is not backwards compatible with RFC2535 but + simplifies DNSSEC operation. + + +1 - Introduction + + Familiarity with the DNS system [RFC1035], DNS security extensions + [RFC2535] and DNSSEC terminology [RFC3090] is important. + + When the same data can reside in two administratively different DNS + zones sources it is common that the data gets out of sync. NS record + in a zone indicates that there is a delegation at this name and the NS + record lists the authorative servers for the real zone. Based on + actual measurements 10-30% of all delegations in the Internet have + differing NS sets at parent and child. There are number of reasons for + this, including lack of communication between parent and child and + bogus name-servers being listed to meet registrar requirements. + + DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its + KEY set signed by the parent to create a verifiable chain of KEYs. + There is some debate, where the signed KEY set should reside, + parent[Parent] or child[RFC2535]. If the KEY set resides at the child, + frequent communication is needed between the two parties, to transmit + key sets up to parent and then the signed set or signatures down to + child. If the KEY set resides at the parent[Parent] the communication + is reduced having only child send updated key sets to parent. + DNSSEC[RFC2535] requires that the parent store NULL key set for + unsecure children, this complicates resolution process as in many + cases as servers for both parent and child need to be queried for KEY + set the [Parent] proposal simplifies this. + + Further complication of the DNSSEC KEY model is that KEY record is + used to store DNS zone keys and public keys for other protocols. This + can lead to large key sets at delegation points. There are number of + potential problems with this including: + 1. KEY set may become quite large if many applications/protocols store + their keys at the zone apex. Example of protocols are IPSEC, HTTP, + SMTP, SSH etc. + 2. Key set may require frequent updates. + 3. Probability of compromised/lost keys increases and triggers + emergency key rollover. + 4. Parent may refuse sign key sets with NON DNS zone keys. + 5. Parent may not have QoS on key changes that meets child's + expectations. + + + + + +Gudmundsson Expires January 2002 [Page 2] + +INTERNET-DRAFT Delegation Signer Record July 2001 + + + Given these and other reasons there is good reason to explore + alternatives to using only KEY records to create chain of trust. + + Some of these problems can be reduced or eliminated by operational + rules or protocol changes. To reduce the number of keys at apex, rule + to require applications to store their KEY records at the SRV name for + that application is one possibility. Another is to restrict KEY record + to DNS keys only and create a new type for all non DNS keys. Third + possible solution is to ban the storage of non DNS related keys at + zone apex. There are other possible solutions but they are outside the + scope of this document. + +1.1 - Delegation Signer Record model + + This document proposes an alternative to the KEY record chain of + trust, that uses a special record that can only reside at the parent. + This record will identify the key(s) that child will use to self sign + its own KEY set. + + The chain of trust is now established by verifying the parent KEY set, + the DS set from the parent and then the KEY set at the child. This is + cryptographically equivalent to just using KEY records. + + Communication between the parent and child is reduced as the parent + only needs to know of changes in DNS zone KEY(s) used to sign the apex + KEY set. If other KEY records are stored at the zone apex, the parent + does not need to be aware of them. + + This approach has the advantage that it minimizes the communication + between the parent and child and the child is the authority for the + KEY set with full control over the contents. This enables each to + operate and maintain each zone independent of each other. Thus if + child wants to have frequent key rollover for its DNS keys parent does + not need to be aware of it as the child can use one key to only sign + its apex KEY set and other keys to sign the other record sets in the + zone. The child can just as well use the same key to sign all records + in its zone. + + Another advantage is that this model fits well with slow rollout of + DNSSEC and islands of security model. In the islands of security model + someone that trusts "good.example." preconfigures a key from + "good.example." as a trusted keys and from then on trusts any data + that is signed by that key or has a chain of trust to that key. If + "example." starts advertising DS records "good.example." does not have + to change operations, by suspending self-signing. If DS records can + also be used to identify trusted keys instead of KEY records. + + + + + +Gudmundsson Expires January 2002 [Page 3] + +INTERNET-DRAFT Delegation Signer Record July 2001 + + + The main disadvantage of this approach is double the number of + signatures that need to be verified for the each delegation KEY set. + There is no impact on verifying other record sets. + + +1.2 - Reserved words + + The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document + are to be interpreted as described in RFC2119. + + + +2 - DS (Delegation KEY signer) record: + +2.1 Protocol change + + DS record MUST only appear at secure delegations in the parent zone. + The record lists the child's keys that SHOULD sign the child's key + set. Insecure delegation MUST NOT have a DS record, the presence of + DS record SHOULD be considered a hint that the child might be secure. + Resolver MUST only trust KEY records that match a DS record. + NOTE: It has been suggested that NULL DS record for insecure children + is better than no record. The advantage is to have authenticated + denial of child's security status, the drawback is for large + delegating zones there will be many NULL DS records. If parent uses + NXT records adding NXT record to the authority section in the cases + when no DS record exists at delegation will give the same result as + NULL DS record. + WG please comment on which approach is better. + + Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section + 2.7: Delegating zones MUST NOT store KEY records for delegations. The + only records that can appear at delegation in parent are NS, SIG, NXT + and DS. + + Zone MUST self sign its apex KEY set, it SHOULD sign it with a key + that corresponds to a DS record in the parent. The KEY used to sign + the apex KEY RRset CAN sign other RRsets in the zone. + + If child apex KEY RRset is not signed with one of the keys specified + in the DS record the child is locally secure[RFC3090] and SHOULD only + be considered secure the resolver has been instructed to trust the key + used, via preconfiguration. + + Authorative server answering a query, that has the OK bit set[OKbit], + MUST include the DS set in the additional section if the answer is a + referral and there is space. Caching servers SHOULD return the DS + record in the additional section under the same condition. + + + +Gudmundsson Expires January 2002 [Page 4] + +INTERNET-DRAFT Delegation Signer Record July 2001 + + +2.1.1 - Comments on protocol change + + Over the years there has been various discussions on that the + delegation model in DNS is broken as there is no real good way to + assert if delegation exists. In RFC2535 version of DNSSEC the + authentication of a delegation is the NS bit in the NXT bitmap at the + delegation point. Something more explicit is needed and the DS record + addresses this for secure delegations. + + DS record is the first DNS record to be only stored at the upper side + of a delegation. NS records appear at both sides as do SIG and NXT. + All other records can only appear at the lower side. This will cause + some problems as servers authorative for parent may reject DS record + even if the server understands unknown types, or not hand them out + unless explicitly asked. Similarly a nameserver acting as a + authorative for child and as a caching recursive server may never + return the DS record. A caching server does not care from which side + DS record comes from and thus should not have to be changed if it + supports unknown types. Different TTL values on the childs NS set and + parents DS set may cause the DS set to expire before the NS set. In + this case an non-DS aware server would ask the child server for the DS + set and get NXDOMAIN answer. DS aware server will know to ask the + parent for the DS record. + + Secure resolvers need to know about the DS record and how to interpret + it. In the worst case, introducing the DS record, doubles the + signatures that need to be checked to validate a KEY set. + Note: The working group must determine if the tradeoff between more + work in resolvers is justified by the operational simplification of + this model. The author think this is a small price to pay to have a + cleaner delegations structure. One argument put forward is that DNS + should be optimized for read when ever possible, and on the face of it + adding the DS record makes reading data from DNS more expensive. The + operational complexities and legal hurdles that KEY records in parents + or children make prevent DNSSEC to ever get deployed. + + + + + + + + + + + + + + + + +Gudmundsson Expires January 2002 [Page 5] + +INTERNET-DRAFT Delegation Signer Record July 2001 + + +2.2 Wire format of DS record + + The DS record consists of algorithm, size, key tag and SHA-1 digest of + the public key KEY record allowed to sign the child's delegation. + + 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 tag | size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | algorithm | SHA-1 digest | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (20 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+ + + The key tag is calculated as specified in RFC2535, the size is the + size of the public key in bits as specified in the document specifying + the algorithm. Algorithm MUST be an algorithm number assigned in the + range 1..251. The SHA-1 digest is calculated over the canonical name + of the delegation followed by the RDATA of the KEY record. + The size of the DS RDATA is 25 bytes, regardless of the key size. + NOTE: if 160 bits is to large the SHA-1 digest can be shortened but + that weakens the overall security of the system. + +2.2.1 Justifications for fields + + The algorithm and size fields are here to allow resolvers to quickly + identify the candidate KEY records to examine. Key Tag is to allow + quick check if this is a good candidate. The key tag is redundant but + provides some greater assurance than SHA-1 digest on its own. SHA-1 is + a strong cryptographic checksum, it is hard for attacker to generate a + KEY record that has the same SHA-1 digest. Making sure that the KEY + record is a valid public key is much harder. Combining the name of the + key and the key data as input to the digest provides stronger + assurance of the binding. Combining the SHA-1 with the other fields + makes the task of the attacker is as hard breaking the public key. + Even if someone creates a database of all SHA-1 key hashes seen so + far, the addition of the name renders that database useless for + attacks against random zones. + + + + +Gudmundsson Expires January 2002 [Page 6] + +INTERNET-DRAFT Delegation Signer Record July 2001 + + +2.3 Presentation format of DS record + + The presentation format of DS record consists of 2 numbers, followed + by either the name of the signature algorithm or the algorithm number. + The digest is to be presented in hex. + +2.4 Justifications for compact format + + This format allows concise representation of the keys that child will + use, thus keeping down the size of the answer for the delegation, + reducing the probability of packet overflow. The SHA-1 hash is strong + enough to uniquely identify the key. This is similar to the PGP + footprint. + + Each DS record has RDATA size of 25, regardless of the size of the + keys, keeping the answers from the parent smaller than if public key + was used. The smallest currently defined KEY record RDATA is 70 bytes. + + Compact DS format is also better suited to list trusted keys for + islands of security in configuration files. + +2.5 Transition issues for installed base + + RFC2535 compliant resolver will assume that all DS secured delegations + are locally secure. This is a bad thing, thus it might be necessary + for a transition period to support both DS and SIG@Child. The cost is + one more signatures in the answer and that early adopters have to + cumbersome communications that DS is supposed to solve. + + Resolvers will not get confused as they will select signatures with + the KEY they trust and ignore the other one. + +3 Resolver Example + + To create a chain of trust resolver goes from trusted KEY to DS to + KEY. + + Assume the key for domain example. is trusted. In zone "example." we + have + example. KEY + secure.example. DS tag=12345 size=1024 alg=dsa + secure.example. NS ns1.secure.example. + NS ns1.secure.example. s + secure.example. NXT NS SIG NXT DS tail.example. + secure.example. SIG(NXT) + secure.example. SIG(DS) + + + + + +Gudmundsson Expires January 2002 [Page 7] + +INTERNET-DRAFT Delegation Signer Record July 2001 + + + In zone "secure.example." we have + secure.example. SOA + secure.example. NS ns1.secure.example. + NS ns1.secure.example. + secure.example. KEY + KEY + KEY + secure.example. SIG(KEY) + secure.example. SIG(SOA) + secure.example. SIG(NS) + + In this example the trusted key for example signs the DS record for + "secure.example.", making that a trusted record. The DS record states + what key is supposed to sign the KEY record at secure.example. In + this example "secure.example." has three different KEY records and the + one corresponding to the KEY identified in the DS record signs the KEY + set, thus the key set is validated and trusted. Note that one of the + other keys in the keyset actually signs the zone data, and resolvers + will trust the signatures as the key appears in the KEY set. + + This example has only one DS record for the child but there no reason + to outlaw multiple DS records. More than one DS record is needed + during signing key rollover. It is strongly recommended that the DS + set be kept small. + +3.1 Resolver cost estimates for DS records + + From a RFC2535 resolver point of view for each delegation followed to + chase down an answer one KEY record has to be verified and possibly + some other records based on policy, for example the contents of the NS + set. Once the resolver gets to the appropriate delegation validating + the answer may require verifying one or more signatures. For a simple + A record lookup requires at least N delegations to be verified and 1 + RRset. For a DS enabled resolver the cost is 2N+1. For MX record the + cost where the target of the MX record is in the same zone as the MX + record the costs are N+2 and 2N+2. In the case of negative answer the + same holds ratios hold true. + Resolver may require an extra query to get the DS record but and this + may add to the overall cost of the query, but this is never worse than + chasing down NULL KEY records from the parent in RFC2535 DNSSEC. + DS adds processing overhead on resolvers, increases the size of + delegation answers. DS requires much less storage in large delegation + zones than SIG@Parent. + + + + + + + + +Gudmundsson Expires January 2002 [Page 8] + +INTERNET-DRAFT Delegation Signer Record July 2001 + + +4 Acknowledgments + + + Number of people have over the last few years contributed number of + ideas that are captured in this document. The core idea of using one + key to that has only the role of signing a key set, comes from + discussions with Bill Manning and Perry Metzger on how to put in a + single root key in all resolver that lives for a long time. Brian + Wellington, Dan Massey, Edward Lewis, Havard Eidnes, Jakob Schlyter, + Mark Kosters, Miek Gieben, Roy Arens, Scott Rosen have provided + usefull comments. + +4 - Security Considerations: + + This document proposes a change to the validation chain of KEY records + in DNS. The change in is not believed to reduce security in the + overall system, in RFC2535 DNSSEC child must communicate keys to + parent and prudent parents will require some authentication on that + handshake. The modified protocol will require same authentication but + allows the child to exert more local control over its own KEY set. + + In the representation of DS record, there is a possibility that an + attacker can generate an valid KEY that matches all the checks thus + starting to forge data from the child. This is considered impractical + as on average more than 2**80 keys must be generated before one is + found that will match. + + DS record is a change to DNSSEC protocol and there is some installed + base of implementations, as well as text books on how to set up + secured delegations. Implementations that do not understand DS record + will not be able to follow the KEY to DS to KEY chain and consider all + zone secured that way insecure. + +5 - IANA Considerations: + + IANA needs to allocate RR type code for DS from the standard RR type + space. + + + + + + + + + + + + + + +Gudmundsson Expires January 2002 [Page 9] + +INTERNET-DRAFT Delegation Signer Record July 2001 + + +References: + +[RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification'', STD 13, RFC 1035, November 1987. + + +[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC + 2535, March 1999. + +[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing + Authority'', RFC 3008, November 2000. + +[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone + Status'', RFC 3090, March 2001. + +[OKbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in + progress , April 2001. + +[Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone + KEYs'', work in progress , May 2001. + +Author Address + + Olafur Gudmundsson + 3826 Legation Street, NW + Washington, DC, 20015 + USA + + +Appendix A: Changes from Prior versions + +Changes from version 00 + Changed name from DK to DS based on working group comments. + Dropped verbose format based on WG comments. + Added text about TTL issue/problem in caching servers. + Added text about islands of security and clarified the cost impact. + Major editing of arguments and some reordering of text for clarity. + Added section on transition issues. + + + + + + + + + + + + +Gudmundsson Expires January 2002 [Page 10] + +INTERNET-DRAFT Delegation Signer Record July 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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." + + + + + + + + + + + + + + + + + + + + + + + + + +Gudmundsson Expires January 2002 [Page 11] diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-02.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-02.txt deleted file mode 100644 index 8ac88901e5..0000000000 --- a/doc/draft/draft-ietf-dnsext-dhcid-rr-02.txt +++ /dev/null @@ -1,448 +0,0 @@ - - -DNSEXT Working Group M. Stapp -Internet-Draft Cisco Systems, Inc. -Expires: August 31, 2001 T. Lemon - A. Gustafsson - Nominum, Inc. - March 2, 2001 - - - 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. - - This Internet-Draft will expire on August 31, 2001. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - A situation can arise where multiple DHCP clients request the same - DNS name from their (possibly distinct) DHCP servers. To resolve - such conflicts, 'Resolution of DNS Name Conflicts'[6] proposes - storing client identifiers in the DNS to unambiguously associate - domain names with the DHCP clients "owning" them. This memo defines - a distinct RR type for use by DHCP servers, the "DHCID" RR. - - - - - - -Stapp, et. al. Expires August 31, 2001 [Page 1] - -Internet-Draft A DNS RR for Encoding DHCP Information March 2001 - - -Table of Contents - - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . . 3 - 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 - 7. Appendix A: Base 64 Encoding . . . . . . . . . . . . . . . . . 5 - References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Stapp, et. al. Expires August 31, 2001 [Page 2] - -Internet-Draft A DNS RR for Encoding DHCP Information March 2001 - - -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 RFC 2119[1]. - -2. Introduction - - A set of procedures to allow DHCP[2] clients and servers to - automatically update the DNS (RFC1034[4], RFC1035[5]) is proposed in - "Resolution of DNS Name Conflicts"[6]. - - A situation can arise where multiple DHCP clients wish to use the - same DNS name. To resolve such conflicts, Resolution of DNS Name - Conflicts[6] proposes storing client identifiers in the DNS to - unambiguously associate domain names with the DHCP clients using - them. In the interest of clarity, it would be preferable for this - DHCP information to use a distinct RR type. - - This memo defines a distinct RR type for this purpose for use by - DHCP clients or servers, the "DHCID" RR. - -3. The DHCID RR - - The DHCID RR is defined with mnemonic DHCID and type code [TBD]. - -4. DHCID RDATA format - - The RDATA section of a DHCID RR in transmission contains RDLENGTH - bytes of binary data. The format of this data and its - interpretation by DHCP servers and clients are described below. - - DNS software should consider the RDATA section to be opaque. In DNS - master files, the RDATA is represented in base 64 encoding (see - Appendix A (Section 7)) 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 signature. These - substrings can span lines using the standard parenthesis. This - format is identical to that used for representing binary data in - DNSSEC (RFC2535[7]). - - DHCP clients or servers use the DHCID RR to associate a DHCP - client's identity with a DNS name, so that multiple DHCP clients and - servers may safely perform dynamic DNS updates to the same zone. - From the updater's perspective, the DHCID resource record consists - of a 16-bit identifier type, followed by one or more bytes - representing the actual identifier. - - The type code can have one of three classes of values. The first - - -Stapp, et. al. Expires August 31, 2001 [Page 3] - -Internet-Draft A DNS RR for Encoding DHCP Information March 2001 - - - class contains just the value zero. This type indicates that the - remaining contents of the DHCID record encode an identifier that is - based on the client's link-layer network address. - - The second class of types contains just the value 0xFFFF. This type - code is reserved for future extensibility. - - The third class of types contains all the values not included in the - first two - that is, every value other than zero or 0xFFFF. Types in - this class indicate that the remaining contents of the DHCID record - encode an identifier that is based on the DHCP option whose code is - the same as the specified type. The most common value in this class - at the time of the writing of this draft is 61, which is the DHCP - option code[3] for the Client Identifier option. - - The data following the type code (for type codes other than 0xFFFF) - is derived by running a one-way hash across the identifying - information. The details of this are specified in "Resolution of - DNS Name Conflicts"[6]. - - This RR MUST NOT be used for any purpose other than that detailed in - "Resolution of DNS Name Conflicts"[6]. Althought this RR contains - data that is opaque to DNS servers, the data must be consistent - across all entities that update and interpret this record. - Therefore, new data formats may only be defined through actions of - the DHC Working Group, as a result of revising [6]. - -4.1 Example - - A DHCP server allocating the IPv4 address 10.0.0.1 to a client - "client.org.nil" might use the client's link-layer address to - identify the client: - - client.org.nil. A 10.0.0.1 - client.org.nil. DHCID AAAYKREXIgqtwYgQo93/yNlJ - - A DHCP server allocating the IPv4 address 10.0.12.99 to a client - "chi.org.nil" might use the DHCP client identifier option to - identify the client: - - chi.org.nil. A 10.0.12.99 - chi.org.nil. DHCID AGGScSLaAYjdOhGMHKD/lJ2B - -5. Security Considerations - - The DHCID record as such does not introduce any new security - problems into the DNS. In order to avoid exposing private - information about DHCP clients to public scrutiny, a one-way-hash is - used to obscure all client information. - - -Stapp, et. al. Expires August 31, 2001 [Page 4] - -Internet-Draft A DNS RR for Encoding DHCP Information March 2001 - - -6. IANA Considerations - - IANA is requested to allocate an RR type number for the DHCID record - type. - -7. Appendix A: Base 64 Encoding - - The following encoding technique is taken from RFC 2045[8] by N. - Borenstein and N. Freed. It is reproduced here in an edited form - for convenience. - - A 65-character subset of US-ASCII is used, enabling 6 bits to be - represented per printable character. (The extra 65th character, "=", - is used to signify a special processing function.) - - The encoding process represents 24-bit groups of input bits as - output strings of 4 encoded characters. Proceeding from left to - right, a 24-bit input group is formed by concatenating 3 8-bit input - groups. These 24 bits are then treated as 4 concatenated 6-bit - groups, each of which is translated into a single digit in the base - 64 alphabet. - - Each 6-bit group is used as an index into an array of 64 printable - characters. The character referenced by the index is placed in the - output string. - - The Base 64 Alphabet - - Value Encoding Value Encoding Value Encoding Value Encoding - 0 A 17 R 34 i 51 z - 1 B 18 S 35 j 52 0 - 2 C 19 T 36 k 53 1 - 3 D 20 U 37 l 54 2 - 4 E 21 V 38 m 55 3 - 5 F 22 W 39 n 56 4 - 6 G 23 X 40 o 57 5 - 7 H 24 Y 41 p 58 6 - 8 I 25 Z 42 q 59 7 - 9 J 26 a 43 r 60 8 - 10 K 27 b 44 s 61 9 - 11 L 28 c 45 t 62 + - 12 M 29 d 46 u 63 / - 13 N 30 e 47 v - 14 O 31 f 48 w (pad) = - 15 P 32 g 49 x - 16 Q 33 h 50 y - - - Special processing is performed if fewer than 24 bits are available - - -Stapp, et. al. Expires August 31, 2001 [Page 5] - -Internet-Draft A DNS RR for Encoding DHCP Information March 2001 - - - at the end of the data being encoded. A full encoding quantum is - always completed at the end of a quantity. When fewer than 24 input - bits are available in an input group, zero bits are added (on the - right) to form an integral number of 6-bit groups. Padding at the - end of the data is performed using the '=' character. Since all - base 64 input is an integral number of octets, only the following - cases can arise: (1) the final quantum of encoding input is an - integral multiple of 24 bits; here, the final unit of encoded output - will be an integral multiple of 4 characters with no "=" padding, - (2) the final quantum of encoding input is exactly 8 bits; here, the - final unit of encoded output will be two characters followed by two - "=" padding characters, or (3) the final quantum of encoding input - is exactly 16 bits; here, the final unit of encoded output will be - three characters followed by one "=" padding character. - -References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - - [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar - 1997. - - [3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, Mar 1997. - - [4] Mockapetris, P., "Domain names - Concepts and Facilities", RFC - 1034, Nov 1987. - - [5] Mockapetris, P., "Domain names - Implementation and - Specification", RFC 1035, Nov 1987. - - [6] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients - (draft-ietf-dhc-dns-resolution-*)", July 2000. - - [7] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message Bodies", - RFC 2045, November 1996. - - - - - - - - - - -Stapp, et. al. Expires August 31, 2001 [Page 6] - -Internet-Draft A DNS RR for Encoding DHCP Information March 2001 - - -Authors' Addresses - - Mark Stapp - Cisco Systems, Inc. - 250 Apollo Dr. - Chelmsford, MA 01824 - USA - - Phone: 978.244.8498 - EMail: mjs@cisco.com - - - Ted Lemon - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - USA - - EMail: mellon@nominum.com - - - Andreas Gustafsson - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - USA - - EMail: gson@nominum.com - - - - - - - - - - - - - - - - - - - - - - - -Stapp, et. al. Expires August 31, 2001 [Page 7] - -Internet-Draft A DNS RR for Encoding DHCP Information March 2001 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). 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. - -Acknowledgement - - Funding for the RFC editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Stapp, et. al. Expires August 31, 2001 [Page 8] - diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-03.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-03.txt new file mode 100644 index 0000000000..1ae89ddb6e --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-03.txt @@ -0,0 +1,504 @@ + + +DNSEXT Working Group M. Stapp +Internet-Draft Cisco Systems, Inc. +Expires: January 18, 2002 T. Lemon + A. Gustafsson + Nominum, Inc. + July 20, 2001 + + + A DNS RR for Encoding DHCP Information (DHCID RR) + + +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. + + This Internet-Draft will expire on January 18, 2002. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + It is possible for multiple DHCP clients to attempt to update the + same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or + the clients themselves perform the DNS updates, conflicts can arise. + To resolve such conflicts, "Resolution of DNS Name Conflicts"[1] + proposes storing client identifiers in the DNS to unambiguously + associate domain names with the DHCP clients to which they refer. + This memo defines a distinct RR type for this purpose for use by + DHCP clients and servers, the "DHCID" RR. + + + + +Stapp, et. al. Expires January 18, 2002 [Page 1] + +Internet-Draft The DHCID RR July 2001 + + +Table of Contents + + 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . 3 + 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . . 4 + 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . . 4 + 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . . 4 + 3.5 Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 5 + 3.6 Updater Behavior . . . . . . . . . . . . . . . . . . . . . . 5 + 3.7 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 + References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 9 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et. al. Expires January 18, 2002 [Page 2] + +Internet-Draft The DHCID RR July 2001 + + +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 RFC 2119[2]. + +2. Introduction + + A set of procedures to allow DHCP[3] clients and servers to + automatically update the DNS (RFC1034[4], RFC1035[5]) is proposed in + "Resolution of DNS Name Conflicts"[1]. + + Conflicts can arise if multiple DHCP clients wish to use the same + DNS name. To resolve such conflicts, "Resolution of DNS Name + Conflicts"[1] proposes storing client identifiers in the DNS to + unambiguously associate domain names with the DHCP clients using + them. In the interest of clarity, it is preferable for this DHCP + information to use a distinct RR type. This memo defines a distinct + RR for this purpose for use by DHCP clients or servers, the "DHCID" + RR. + + In order to avoid exposing potentially sensitive identifying + information, the data stored is the result of a one-way MD5[6] hash + computation. The hash includes information from the DHCP client's + REQUEST message as well as the domain name itself, so that the data + stored in the DHCID RR will be dependent on both the client + identification used in the DHCP protocol interaction and the domain + name. This means that the DHCID RDATA will vary if a single client + is associated over time with more than one name. This makes it + difficult to 'track' a client as it is associated with various + domain names. + + The MD5 hash algorithm has been shown to be weaker than the SHA-1 + algorithm; it could therefore be argued that SHA-1 is a better + choice. However, SHA-1 is significantly slower than MD5. A + successful attack of MD5's weakness does not reveal the original + data that was used to generate the signature, but rather provides a + new set of input data that will produce the same signature. Because + we are using the MD5 hash to conceal the original data, the fact + that an attacker could produce a different plaintext resulting in + the same MD5 output is not significant concern. + +3. The DHCID RR + + The DHCID RR is defined with mnemonic DHCID and type code [TBD]. + +3.1 DHCID RDATA format + + The RDATA section of a DHCID RR in transmission contains RDLENGTH + + +Stapp, et. al. Expires January 18, 2002 [Page 3] + +Internet-Draft The DHCID RR July 2001 + + + bytes of binary data. The format of this data and its + interpretation by DHCP servers and clients are described below. + + DNS software should consider the RDATA section to be opaque. DHCP + clients or servers use the DHCID RR to associate a DHCP client's + identity with a DNS name, so that multiple DHCP clients and servers + may deterministically perform dynamic DNS updates to the same zone. + From the updater's perspective, the DHCID resource record RDATA + consists of a 16-bit identifier type, in network byte order, + followed by one or more bytes representing the actual identifier: + + < 16 bits > DHCP identifier used + < n bytes > MD5 digest + +3.2 DHCID Presentation Format + + In DNS master files, the RDATA is represented as a single block in + base 64 encoding and may be divided up into any number of white + space separated substrings, down to single base 64 digits, which are + concatenated to form the complete RDATA. These substrings can span + lines using the standard parentheses. This format is identical to + that used for representing binary data in RFC2535[7]. + +3.3 The DHCID RR Type Codes + + The type code can have one of three classes of values. The first + class contains just the value zero. This type indicates that the + remaining contents of the DHCID record encode an identifier that is + based on the client's link-layer network address. + + The second class of types contains just the value 0xFFFF. This type + code is reserved for future extensibility. + + The third class of types contains all the values not included in the + first two - that is, every value other than zero or 0xFFFF. Types in + this class indicate that the remaining contents of the DHCID record + encode an identifier that is based on the DHCP option whose code is + the same as the specified type. The most common value in this class + at the time of the writing of this specification is 0x3d (61 + decimal), which is the DHCP option code for the Client Identifier + option [8]. + +3.4 Computation of the RDATA + + The data following the type code (for type codes other than 0xFFFF) + is derived by running the MD5 hash algorithm across a buffer + containing the identifying information. The identifying information + includes some data from the DHCP client's DHCPREQUEST message, and + the FQDN which is the target of the update. + + +Stapp, et. al. Expires January 18, 2002 [Page 4] + +Internet-Draft The DHCID RR July 2001 + + + The domain name is represented in the buffer in dns wire-format as + described in RFC1035[5], section 3.1. The domain name MUST NOT be + compressed as described in RFC1035[5], section 4.1.4. Any uppercase + alphabetic ASCII character in a label MUST be converted to lowercase + before being used to compute the hash. + + When the updater is using the client's link-layer address as the + identifier, the first two bytes of the DHCID RDATA MUST be zero. To + generate the rest of the resource record, the updater computes a + one-way hash using the MD5 algorithm across a buffer containing the + client's network hardware type, link-layer address, and the FQDN + data. Specifically, the first byte of the buffer contains the + network hardware type as it appeared in the DHCP 'htype' field of + the client's DHCPREQUEST message. All of the significant bytes of + the chaddr field in the client's DHCPREQUEST message follow, in the + same order in which the bytes appear in the DHCPREQUEST message. The + number of significant bytes in the 'chaddr' field is specified in + the 'hlen' field of the DHCPREQUEST message. The FQDN data, as + specified above, follows. + + When the updater is using a DHCP option sent by the client in its + DHCPREQUEST message, the first two bytes of the DHCID RR MUST be the + option code of that option, in network byte order. For example, if + the DHCP client identifier option is being used, the first byte of + the DHCID RR should be zero, and the second byte should be 61 + decimal. The rest of the DHCID RR MUST contain the results of + computing an MD5 hash across the payload of the option being used, + followed by the FQDN. The payload of a DHCP option consists of the + bytes of the option following the option code and length. + + The "Resolution of DNS Name Conflicts"[1] specification describes + the selection process that updaters follow to choose an identifier + from the information presented in a client's DHCPREQUEST message. + +3.5 Use of the DHCID RR + + This RR MUST NOT be used for any purpose other than that detailed in + "Resolution of DNS Name Conflicts"[1]. Although this RR contains + data that is opaque to DNS servers, the data must be consistent + across all entities that update and interpret this record. + Therefore, new data formats may only be defined through actions of + the DHC Working Group, as a result of revising [1]. + +3.6 Updater Behavior + + The data in the DHCID RR allows updaters to determine whether more + than one DHCP client desires to use a particular FQDN. This allows + site administrators to establish policy about DNS updates. The DHCID + RR does not establish any policy itself. + + +Stapp, et. al. Expires January 18, 2002 [Page 5] + +Internet-Draft The DHCID RR July 2001 + + + Updaters use data from a DHCP client's request and the domain name + that the client desires to use to compute a client identity hash, + and then compare that hash to the data in any DHCID RRs on the name + that they wish to associate with the client's IP address. If an + updater discovers DHCID RRs whose RDATA does not match the client + identity that they have computed, the updater SHOULD conclude that a + different client is currently associated with the name in question. + The updater SHOULD then proceed according to the site's + administrative policy. That policy might dictate that a different + name be selected, or it might permit the updater to continue. + +3.7 Examples + +3.7.1 Example 1 + + A DHCP server allocating the IPv4 address 10.0.0.1 to a client with + Ethernet MAC address 01:02:03:04:05:06 using domain name + "client.org.nil" uses the client's link-layer address to identify + the client. The DHCID RDATA is composed by setting the two type + bytes to zero, and performing an MD5 hash computation across a + buffer containing the Ethernet MAC type byte, 0x01, the six bytes of + MAC address, and the domain name (represented as specified in + Section 3.4). + + client.org.nil. A 10.0.0.1 + client.org.nil. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU + +3.7.2 Example 2 + + A DHCP server allocates the IPv4 address 10.0.12.99 to a client + which included the DHCP client-identifier option data + 01:07:08:09:0a:0b:0c in its DHCP request. The server updates the + name "chi.org.nil" on the client's behalf, and uses the DHCP client + identifier option data as input in forming a DHCID RR. The DHCID + RDATA is formed by setting the two type bytes to the option code, + 0x003d, and performing an MD5 hash computation across a buffer + containing the seven bytes from the client-id option and the FQDN + (represented as specified in Section 3.4). + + chi.org.nil. A 10.0.12.99 + chi.org.nil. DHCID AD3dquu0xNqYn/4zw2FXy8X3 + +4. Security Considerations + + The DHCID record as such does not introduce any new security + problems into the DNS. In order to avoid exposing private + information about DHCP clients to public scrutiny, a one-way hash is + used to obscure all client information. In order to make it + difficult to 'track' a client by examining the names associated with + + +Stapp, et. al. Expires January 18, 2002 [Page 6] + +Internet-Draft The DHCID RR July 2001 + + + a particular hash value, the FQDN is included in the hash + computation. Thus, the RDATA is dependent on both the DHCP client + identification data and on each FQDN associated with the client. + + Administrators should be wary of permitting unsecured DNS updates to + zones which are exposed to the global Internet. Both DHCP clients + and servers SHOULD use some form of update authentication (e.g., + TSIG[9]) when performing DNS updates. + +5. IANA Considerations + + IANA is requested to allocate an RR type number for the DHCID record + type. + +References + + [1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients + (draft-ietf-dhc-dns-resolution-*)", March 2001. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar + 1997. + + [4] Mockapetris, P., "Domain names - Concepts and Facilities", RFC + 1034, Nov 1987. + + [5] Mockapetris, P., "Domain names - Implementation and + Specification", RFC 1035, Nov 1987. + + [6] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April + 1992. + + [7] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [8] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, Mar 1997. + + [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + + + + + + + +Stapp, et. al. Expires January 18, 2002 [Page 7] + +Internet-Draft The DHCID RR July 2001 + + +Authors' Addresses + + Mark Stapp + Cisco Systems, Inc. + 250 Apollo Dr. + Chelmsford, MA 01824 + USA + + Phone: 978.244.8498 + EMail: mjs@cisco.com + + + Ted Lemon + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + EMail: mellon@nominum.com + + + Andreas Gustafsson + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + EMail: gson@nominum.com + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et. al. Expires January 18, 2002 [Page 8] + +Internet-Draft The DHCID RR July 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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. + +Acknowledgement + + Funding for the RFC editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Stapp, et. al. Expires January 18, 2002 [Page 9] + diff --git a/doc/draft/draft-ietf-dnsext-unknown-rrs-00.txt b/doc/draft/draft-ietf-dnsext-unknown-rrs-01.txt similarity index 84% rename from doc/draft/draft-ietf-dnsext-unknown-rrs-00.txt rename to doc/draft/draft-ietf-dnsext-unknown-rrs-01.txt index 6c5cc994c3..3fc9875d74 100644 --- a/doc/draft/draft-ietf-dnsext-unknown-rrs-00.txt +++ b/doc/draft/draft-ietf-dnsext-unknown-rrs-01.txt @@ -1,6 +1,6 @@ INTERNET-DRAFT Andreas Gustafsson -draft-ietf-dnsext-unknown-rrs-00.txt Nominum Inc. - November 2000 +draft-ietf-dnsext-unknown-rrs-01.txt Nominum Inc. + July 2001 Handling of Unknown DNS RR Types @@ -49,9 +49,9 @@ Abstract -Expires May 2001 [Page 1] +Expires January 2002 [Page 1] -draft-ietf-dnsext-unknown-rrs-00.txt November 2000 +draft-ietf-dnsext-unknown-rrs-01.txt July 2001 fully realized. This memo proposes changes to name servers and to @@ -67,12 +67,16 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000 In this document, a "well known" RR type means one defined in RFC1035. - An "RR of unknown type" is an RR type whose RDATA format is not known - to the DNS implementation at hand, and which therefore cannot be - converted to a type-specific text format, compressed, or otherwise - handled in any type-specific way. This includes the case where the - RR's type is recognized but its RDATA format is class specific and - the RR is of a class for which the format is not known. + An "RR of unknown type" is an RR whose RDATA format is not known to + the DNS implementation at hand, such that it cannot be converted to a + type-specific text format, compressed, or otherwise handled in a + type-specific way, and whose type is not an assigned QTYPE or Meta- + TYPE in RFC2929 section 3.1 nor within the range reserved in that + section for assignment only to QTYPEs and Meta-TYPEs. + + In the case of a type whose RDATA format is 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 @@ -98,18 +102,18 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000 type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, NXT, NAPTR, and SRV (although the SRV RR is clearly defined to not allow compression of the target field, some existing name servers + + + +Expires January 2002 [Page 2] + +draft-ietf-dnsext-unknown-rrs-01.txt July 2001 + + compress it anyway). Future specifications for new RR types that contain domain names within their RDATA MUST NOT allow the use of name compression for - - - -Expires May 2001 [Page 2] - -draft-ietf-dnsext-unknown-rrs-00.txt November 2000 - - those names, and SHOULD explicitly state that the embedded domain names MUST NOT be compressed. @@ -154,18 +158,18 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000 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- + + + +Expires January 2002 [Page 3] + +draft-ietf-dnsext-unknown-rrs-01.txt July 2001 + + specific rules regarding compression, canonicalization, etc. The following are examples of RRs represented in this manner, illustrating various combinations of generic and type-specific - - - -Expires May 2001 [Page 3] - -draft-ietf-dnsext-unknown-rrs-00.txt November 2000 - - encodings for the different fields of the master file format: a.example. CLASS32 TYPE731 \# 6 abcd ( @@ -198,7 +202,7 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000 the canonical form, domain names embedded in the RDATA are converted to lower case. - To ensure backwards compatilbility, this canonical form remains + To ensure backwards compatibility, this canonical form remains unchanged for any RR types defined in RFC2931 or earlier. That is, the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, @@ -211,29 +215,28 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000 the octet sequence is the canonical form as revised by this specification. + + +Expires January 2002 [Page 4] + +draft-ietf-dnsext-unknown-rrs-01.txt July 2001 + + 8. Additional Section Processing Unknown RR types cause no additional section processing. Future RR - - - -Expires May 2001 [Page 4] - -draft-ietf-dnsext-unknown-rrs-00.txt November 2000 - - 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 +9. IANA Considerations The IANA is hereby requested to verify that specifications for new RR types requesting an RR type number comply with this specification. - In particular, the IANA MUST NOT assign numbers to RR types whose + In particular, the IANA MUST NOT assign numbers to new RR types whose specification allows embedded domain names to be compressed. - 10. Security Considerations +10. Security Considerations This specification is not believed to cause any new security problems, nor to solve any existing ones. @@ -250,11 +253,14 @@ References Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE). P. - Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. + Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997. - [RFC2535] Domain Name System Security Extensions. D. Eastlake. March + [RFC2535] Domain Name System Security Extensions. D. Eastlake, March 1999. + [RFC2929] Domain Name System (DNS) IANA Considerations. D. Eastlake, + E. Brunner-Williams, B. Manning, September 2000. + Author's Address Andreas Gustafsson @@ -263,22 +269,21 @@ Author's Address Redwood City, CA 94063 USA - Phone: +1 650 779 6004 + Phone: +1 650 381 6004 + + + +Expires January 2002 [Page 5] + +draft-ietf-dnsext-unknown-rrs-01.txt July 2001 + Email: Andreas.Gustafsson@nominum.com Full Copyright Statement - - - -Expires May 2001 [Page 5] - -draft-ietf-dnsext-unknown-rrs-00.txt November 2000 - - - Copyright (C) The Internet Society (2000). All Rights Reserved. + Copyright (C) The Internet Society (2001). 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 @@ -324,10 +329,5 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000 - - - - - -Expires May 2001 [Page 6] +Expires January 2002 [Page 6] diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-01.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-02.txt similarity index 82% rename from doc/draft/draft-ietf-dnsop-inaddr-required-01.txt rename to doc/draft/draft-ietf-dnsop-inaddr-required-02.txt index f73861d842..7584cd49be 100644 --- a/doc/draft/draft-ietf-dnsop-inaddr-required-01.txt +++ b/doc/draft/draft-ietf-dnsop-inaddr-required-02.txt @@ -1,9 +1,17 @@ + + + + + + INTERNET-DRAFT D. Senie Category: BCP Amaranth Networks Inc. -Expires in six months February 2001 +Expires in six months July 2001 Requiring DNS IN-ADDR Mapping - draft-ietf-dnsop-inaddr-required-01.txt + draft-ietf-dnsop-inaddr-required-02.txt. + + Status of this Memo @@ -26,8 +34,12 @@ Status of this Memo 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. + 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 @@ -56,7 +68,7 @@ Senie [Page 1] -Internet-Draft Requiring DNS IN-ADDR Mapping February 2001 +Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 From the early days of the Domain Name Service [RFC 883] a special @@ -116,7 +128,7 @@ Senie [Page 2] -Internet-Draft Requiring DNS IN-ADDR Mapping February 2001 +Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 export of that software is prohibited to some locales. Credit card @@ -137,7 +149,7 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001 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 web page accesses for users. + 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 @@ -146,27 +158,27 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001 4. Requirements + 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 adds 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. + All IP address space which is assigned and in use SHOULD be resolved - by IN-ADDR records. Internet providers and other users to whom a - block of addresses are delegated SHOULD provide for lookup of host - names from IP addresses. This may be provided directly or by - delegation to the user of the address block. The ISP is responsible - for one or the other. In the event of delegation, the user is - responsible for resolution. + by IN-ADDR records. All PTR records MUST use canonical names. + + Internet providers and other users to whom a block of addresses are + delegated SHOULD provide for lookup of host names from IP addresses. + This may be provided directly or by delegation to the user of the + address block. The ISP is responsible for one or the other. In the + event of delegation, the user is responsible for resolution. Only IP addresses not presently in use within a block, or which are not valid for use (zeros or ones broadcast addresses) are permitted to have no mapping. It should be noted that due to CIDR, many addresses which 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 can only be done with a - knowledge of the internal routing structure of the site. However, any - host which originates an IP packet necessarily will have a valid host - address, and must therefore have an IN-ADDR mapping. - - 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 required. Internet providers and end @@ -176,15 +188,23 @@ Senie [Page 3] -Internet-Draft Requiring DNS IN-ADDR Mapping February 2001 +Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 + to audit a site's degree of compliance can only be done with a + knowledge of the internal routing structure of the site. However, any + host which originates an IP packet necessarily will have a valid host + address, and must therefore have an IN-ADDR mapping. + + 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 required. Internet providers and end users with address blocks must verify their own internal networks are properly represented in IN-ADDR records, either by providing that service themselves, or delegating it to others. Those to whom blocks have been delegated SHOULD convey a policy to - degegatees requiring that they too provide IN-ADDR records and + delegatees requiring that they too provide IN-ADDR records and require and delegations below to do the same. ISPs may wish to provide IN-ADDR records for their clients if the customers are unable to provide this for themselves. @@ -196,6 +216,11 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001 anonimity, this is really not valid. Trace routes, whois lookups and other sources will still provide methods for discovering identity. + 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. References [RFC883] P.V. Mockapetris, "Domain names: Implementation @@ -214,6 +239,18 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001 [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation Guidelines", RFC2050, BCP 12, Novebmer 1996. + + + +Senie [Page 4] + + + + + +Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 + + [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date unknown, http://www.arin.net/regserv/initial-isp.html @@ -227,18 +264,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001 7. Acknowledgements - - - -Senie [Page 4] - - - - - -Internet-Draft Requiring DNS IN-ADDR Mapping February 2001 - - Thanks to Peter Koch and Gary Miller for their input, and to many people who encouraged me to write this document. @@ -269,19 +294,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001 - - - - - - - - - - - - - @@ -291,3 +303,5 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001 Senie [Page 5] + + diff --git a/doc/draft/draft-ietf-idn-idna-02.txt b/doc/draft/draft-ietf-idn-idna-03.txt similarity index 82% rename from doc/draft/draft-ietf-idn-idna-02.txt rename to doc/draft/draft-ietf-idn-idna-03.txt index 4d9afbcf86..c9a5bd7168 100644 --- a/doc/draft/draft-ietf-idn-idna-02.txt +++ b/doc/draft/draft-ietf-idn-idna-03.txt @@ -1,6 +1,6 @@ Internet Draft Patrik Faltstrom -draft-ietf-idn-idna-02.txt Cisco -June 16, 2001 Paul Hoffman +draft-ietf-idn-idna-03.txt Cisco +July 20, 2001 Paul Hoffman Expires in six months IMC & VPNC Internationalizing Host Names In Applications (IDNA) @@ -148,14 +148,14 @@ An IDNA-aware application can accept and display internationalized host names in two formats: the internationalized character set(s) supported by the application, and in an ACE. Applications MAY allow ACE input and output, but are not encouraged to do so except as an interface for -advanced users, possibly for debugging. ACE encoding is opaque and ugly, -and should thus only be exposed to users who absolutely need it. The -optional use, especially during a transition period, of ACE encodings in -the user interface is described in section 3. Since ACE can be rendered -either as the encoded ASCII glyphs or the proper decoded character -glyphs, the rendering engine for an application SHOULD have an option -for the user to select the preferred display; if it does, rendering the -ACE SHOULD NOT be the default. +special purposes, possibly for debugging. ACE encoding is opaque and +ugly, and should thus only be exposed to users who absolutely need it. +The optional use, especially during a transition period, of ACE +encodings in the user interface is described in section 3. Because name +parts encoded with ACE can be rendered either as the encoded ASCII +characters or the proper decoded characters, the application MAY have an +option for the user to select the preferred method of display; if it +does, rendering the ACE SHOULD NOT be the default. Host names are often stored and transported in many places. For example, they are part of documents such as mail messages and web pages. They are @@ -165,9 +165,13 @@ and the body content in HTTP. In protocols and document formats that define how to handle specification or negotiation of charsets, IDN host name parts can be -given in any charset allowed by the protocol or document format. If a +encoded in any charset allowed by the protocol or document format. If a protocol or document format only allows one charset, IDN host name parts -must be given in that charset. +must be given in that charset. In any place where a protocol or document +format allows transmition of the characters in IDN host name parts, IDN +host name parts SHOULD be transmitted using whatever character encoding +and escape mechanism that the protocol or document format uses at that +place. All protocols that have host names as protocol elements already have the capacity for handling host names in the ASCII charset. Thus, IDN host @@ -190,7 +194,7 @@ name parts encoded in ACE from the resolver. IDNA-aware applications MUST be able to work with both non-internationalized host name parts (those that conform to [STD13] and [STD3]) and internationalized host name parts. An IDNA-aware application -that is resolving a non-internationalized host name parts MUST NOT do +that is resolving a non-internationalized host name part MUST NOT do any preparation or conversion to ACE on any non-internationalized name part. @@ -227,11 +231,19 @@ characters in the decoded name, such as if the name contains characters that the output system cannot display, the application SHOULD show the name in ACE format instead of displaying the name with the replacement character (U+FFFD). This is to make it easier for the user to transfer -the name correctly to other programs using copy-and-paste techniques. -Programs that by default show the ACE form when they cannot show all the -characters in a name part SHOULD also have a mechanism to show the name -with as many characters as possible and replacement characters in the -positions where characters cannot be displayed. +the name correctly to other programs. Programs that by default show the +ACE form when they cannot show all the characters in a name part SHOULD +also have a mechanism to show the name with as many characters as +possible and replacement characters in the positions where characters +cannot be displayed. In many cases, the application doesn't know exactly +what the underlying rendering engine can or cannot display. + +In addition to the condition above, if an application decodes an ACE +name but finds that the decoded name was not properly prepared according +to [NAMEPREP] (for example, if it has illegal characters in it), the +application SHOULD show the name in ACE format and SHOULD NOT display +the name in its decoded form. This is to avoid security issues described +in [NAMEPREP]. 2.1.5 Automatic detection of ACE @@ -240,7 +252,7 @@ the host name is in ACE. This is possible by verifying the prefix in each of the labels, and seeing whether or not the label is in ACE. This MUST be done regardless of whether or not the communication channel used (such as keyboard input, cut and paste, application protocol, -application payload, and so on) has negotiated ACE. +application payload, and so on) is encoding with ACE. The reason for this requirement is that many applications are not ACE-aware. Applications that are not ACE-aware will send host names in @@ -249,14 +261,11 @@ has the characters that are valid in [STD13] as a subset. 2.1.6 Bidirectional text -In IDNA, bidirectional text is entered and displayed exactly as it is -specified in ISO/IEC 10646. Both ISO/IEC 10646 and the Unicode standard -have extensive discussion of how to deal with bidirectional text. Any -input mechanism and display mechanism that handles characters from -bidirectional scripts should already conform to those specifications. -Note that the formatting characters that manually change the direction -of display are prohibited by nameprep, thus making the task for input -and display mechanisms easier. +In IDNA, text storage and display follows the rules in the Unicode standard +[Unicode3.1]. In particular, all Unicode text is stored in logical order; +the Unicode standard has an extensive discussion of how to deal with reorder +glyphs for display when dealing with bidirectional text such as Arabic or +Hebrew. See [UAX9] for more information. 3. Name Server Considerations @@ -329,24 +338,30 @@ and Support" (RFC 1123), STD 3, October 1989. 1034) and "Domain names - implementation and specification" (RFC 1035, STD 13, November 1987. +[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm. +http://www.unicode.org/unicode/reports/tr9/ -B. Changes from the -01 draft +[Unicode3.1] The Unicode Standard, Version 3.1.0: The Unicode +Consortium. The Unicode Standard, Version 3.0. Reading, MA, +Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5, as amended +by: Unicode Standard Annex #27: Unicode 3.1 +. -1.1: Revised whole section to deal with more proposals. -2.1: Clarified the ASCII art -2.1.1: Changed the section title. Added the last three paragraphs. +B. Changes from the -02 draft -2.1.4: Added the second paragraph. +Editorial changes throughout -2.1.6: Added this section. +2.1.1: Major changes to the second paragraph. Added major text to fourth +paragraph. -2.1.5: Added this section. +2.1.4: Added to the end of the second paragraph. Added the third +paragraph. -3: Added note in the last sentence of second paragraph. +2.1.6: Complete change. -5: Added second and third paragraphs. +6: Added [Unicode3.1] and [UAX9]. C. Authors' Addresses @@ -354,8 +369,7 @@ C. Authors' Addresses Patrik Faltstrom Cisco Systems Arstaangsvagen 31 J -S-117 43 Stockholm -Sweden +S-117 43 Stockholm Sweden paf@cisco.com Paul Hoffman diff --git a/doc/draft/draft-ietf-ipngwg-default-addr-select-04.txt b/doc/draft/draft-ietf-ipngwg-default-addr-select-05.txt similarity index 88% rename from doc/draft/draft-ietf-ipngwg-default-addr-select-04.txt rename to doc/draft/draft-ietf-ipngwg-default-addr-select-05.txt index 6bc5adb182..ecc0ad12ee 100644 --- a/doc/draft/draft-ietf-ipngwg-default-addr-select-04.txt +++ b/doc/draft/draft-ietf-ipngwg-default-addr-select-05.txt @@ -2,34 +2,26 @@ IPng Working Group Richard Draves Internet Draft Microsoft Research -Document: draft-ietf-ipngwg-default-addr-select-04.txt May 14, 2001 +Document: draft-ietf-ipngwg-default-addr-select-05.txt June 4, 2001 Category: Standards Track Default Address Selection for IPv6 - Status of this Memo - This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. - 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 two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override @@ -42,20 +34,17 @@ Abstract selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. - All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. - 1. Introduction - The IPv6 addressing architecture [2] allows multiple unicast addresses to be assigned to interfaces. These addresses may have different reachability scopes (link-local, site-local, or global). These addresses may also be "preferred" or "deprecated" [3]. Privacy considerations have introduced the concepts of "public addresses" -Draves Standards Track - Expires December 2001 1 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 +Draves Standards Track - Expires January 2002 1 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 and "temporary addresses" [4]. The mobility architecture introduces @@ -64,14 +53,12 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 example, a node may have multiple interfaces, some of them tunnels or virtual interfaces, or a site may have multiple ISP attachments with a global prefix per ISP. - The end result is that IPv6 implementations will very often be faced with multiple possible source and destination addresses when initiating communication. It is desirable to have default algorithms, common across all implementations, for selecting source and destination addresses so that developers and administrators can reason about and predict the behavior of their systems. - Furthermore, dual or hybrid stack implementations, which support both IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 when initiating communication. For example, when DNS name @@ -87,7 +74,6 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 communication. The destination address selection algorithm solves this with a unified procedure for choosing among both IPv6 and IPv4 addresses. - This document specifies source address selection and destination address selection separately, but using a common framework so that together the two algorithms yield useful results. The algorithms @@ -96,7 +82,6 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 Furthermore, this document suggests a preferred method, longest matching prefix, for choosing among otherwise equivalent addresses in the absence of better information. - The framework also has policy hooks to allow administrative override of the default behavior. For example, using these hooks an administrator can specify a preferred source prefix for use with a @@ -104,33 +89,25 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 over addresses with another prefix. These hooks give an administrator flexibility in dealing with some multi-homing and transition scenarios, but they are certainly not a panacea. - The selection rules specified in this document MUST NOT be construed to override an application or upper-layer's explicit choice of a legal destination or source address. - - - -Draves Standards Track - Expires December 2001 2 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 +Draves Standards Track - Expires January 2002 2 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 1.1. Conventions used in this document - 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 [7]. - 2. Framework - Our framework for address selection derives from the most common implementation architecture, which separates the choice of destination address from the choice of source address. Consequently, the framework specifies two separate algorithms for these tasks. The algorithms are designed to work well together and they share a mechanism for administrative policy override. - In this implementation architecture, applications use APIs [8] like getaddrinfo() that return a list of addresses to the application. This list might contain both IPv6 and IPv4 addresses (sometimes @@ -143,7 +120,6 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 application might also specify a source address with bind(), but often the source address is left unspecified. Therefore the network layer does often choose a source address from several alternatives. - As a consequence, we intend that implementations of getaddrinfo() will use the destination address selection algorithm specified here to sort the list of IPv6 and IPv4 addresses that they return. @@ -152,11 +128,9 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 specified a source address. Application of this framework to source address selection in an IPv4 network layer may be possible but this is not explored further here. - Well-behaved applications should iterate through the list of addresses returned from getaddrinfo() until they find a working addresses. - The algorithms use several criteria in making their decisions. The combined effect is to prefer destination/source address pairs for which the two addresses are of equal scope or type, prefer smaller @@ -170,13 +144,12 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 address and a care-of address (indicating the mobile node is "at home" for that address), then the home/care-of address is preferred -Draves Standards Track - Expires December 2001 3 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 +Draves Standards Track - Expires January 2002 3 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 over addresses that are solely a home address or solely a care-of address. - The framework optionally allows for the possibility of administrative configuration of policy that can override the default behavior of the algorithms. The policy override takes the form of a @@ -185,15 +158,13 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 not configurable, or if an implementation has not been configured, then the default policy table specified in this document SHOULD be used. - 2.1. Scope Comparisons - Multicast destination addresses have a 4-bit scope field that controls the propagation of the multicast packet. The IPv6 - addressing architecture defines scope field values for node-local - (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), - and global (0xE) scopes [9]. - + addressing architecture defines scope field values for interface- + local (0x1), link-local (0x2), subnet-local (0x3), admin-local + (0x4), site-local (0x5), organization-local (0x8), and global (0xE) + scopes [9]. Use of the source address selection algorithm in the presence of multicast destination addresses requires the comparison of a unicast address scope with a multicast address scope. We map unicast link- @@ -202,22 +173,17 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 example, unicast site-local is equal to multicast site-local, which is smaller than multicast organization-local, which is smaller than unicast global, which is equal to multicast global. - We write Scope(A) to mean the scope of address A. For example, if A is a link-local unicast address and B is a site-local multicast address, then Scope(A) < Scope(B). - This mapping implicitly conflates unicast site boundaries and multicast site boundaries [9]. - 2.2. IPv4 Addresses and IPv4-Mapped Addresses - The destination address selection algorithm operates on both IPv6 and IPv4 addresses. For this purpose, IPv4 addresses should be represented as IPv4-mapped addresses [2]. For example, to lookup the precedence or other attributes of an IPv4 address in the policy table, lookup the corresponding IPv4-mapped IPv6 address. - IPv4 addresses are assigned scopes as follows. IPv4 auto- configuration addresses [6], which have the prefix 169.254/16, are assigned link-local scope. IPv4 private addresses [10], which have @@ -226,68 +192,54 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 have the prefix 127/8, are assigned link-local scope (analogously to the treatment of the IPv6 loopback address [9, section 4]). Other IPv4 addresses are assigned global scope. - -Draves Standards Track - Expires December 2001 4 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 +Draves Standards Track - Expires January 2002 4 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 IPv4 addresses should be treated as having "preferred" configuration status. - 2.3. IPv6 Addresses with Embedded IPv4 Addresses - IPv4-compatible addresses [2] and 6to4 addresses [12] contain an embedded IPv4 address. For the purposes of this document, these addresses should be treated as having global scope. - IPv4-compatible addresses should be treated as having "preferred" configuration status. - 2.4. Loopback Address and Other Format Prefixes - The loopback address should be treated as having link-local scope [9, section 4] and "preferred" configuration status. - NSAP addresses and other addresses with as-yet-undefined format prefixes should be treated as having global scope and "preferred" - configuration status. Later standards may supercede this treatment. - + configuration status. Later standards may supersede this treatment. 2.5. Policy Table - The policy table is a longest-matching-prefix lookup table, much like a routing table. Given an address A, a lookup in the policy table produces two values: a precedence value Precedence(A) and a classification or label Label(A). - The precedence value Precedence(A) is used for sorting destination addresses. If Precedence(A) > Precedence(B), we say that address A has higher precedence than address B, meaning that our algorithm will prefer to sort destination address A before destination address B. - The label value Label(A) allows for policies that prefer a particular source address prefix for use with a destination address prefix. The algorithms prefer to use a source address S with a destination address D if Label(S) = Label(D). - IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here. If an implementation is not configurable or has not been configured, then it SHOULD operate according to the algorithms specified here in conjunction with the following default policy table: - Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 - -Draves Standards Track - Expires December 2001 5 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 +Draves Standards Track - Expires January 2002 5 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 @@ -298,92 +250,92 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available. - Policy table entries for scoped address prefixes MAY be qualified - with an optional scope-id. If so, a prefix table entry only matches - against an address during a lookup if the scope-id also matches the - address's scope-id. - + with an optional zone index. If so, a prefix table entry only + matches against an address during a lookup if the zone index also + matches the address's zone index. 2.6. Common Prefix Length - We define the common prefix length CommonPrefixLen(A, B) of two addresses A and B as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common. It ranges from 0 to 128. - 3. Candidate Source Addresses - The source address selection algorithm uses the concept of a "candidate set" of potential source addresses for a given destination address. We write CandidateSource(A) to denote the candidate set for the address A. - It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination. (The "outgoing" interface.) On routers, the candidate set MAY include unicast addresses assigned to any - interface that could forward the destination address to the outgoing - interface. - - In some cases the destination address may be qualified with a scope- - id or other information that will constrain the candidate set. - + interface that forwards packets, subject to the restrictions + described below. + Discussion: The Neighbor Discovery Redirect mechanism [13] + requires that routers verify that the source address of a packet + identifies a neighbor before generating a Redirect, so it is + advantageous for hosts to choose source addresses assigned to the + outgoing interface. Implementations that wish to support the use + of global source addresses assigned to a loopback interface should + behave as if the loopback interface originates and forwards the + packet. + In some cases the destination address may be qualified with a zone + index or other information that will constrain the candidate set. For multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface. - + +Draves Standards Track - Expires January 2002 6 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + + Discussion: The restriction for multicast destination addresses is + necessary because currently-deployed multicast forwarding + algorithms use Reverse Path Forwarding (RPF) checks. For site-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same site as the outgoing interface. - In any case, anycast addresses, multicast addresses, and the unspecified address MUST NOT be included in a candidate set. - If an application or upper-layer specifies a source address that is not in the candidate set for the destination, then the network layer - MUST treat this is an error. If the application or upper-layer - specifies a source address that is in the candidate set for the - -Draves Standards Track - Expires December 2001 6 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - - destination, then the network layer MUST respect that choice. If the - application or upper-layer does not specify a source address, then - the network layer uses the source address selection algorithm - specified in the next section. - + MUST treat this is an error. The specified source address may + influence the candidate set, by affecting the choice of outgoing + interface. If the application or upper-layer specifies a source + address that is in the candidate set for the destination, then the + network layer MUST respect that choice. If the application or upper- + layer does not specify a source address, then the network layer uses + the source address selection algorithm specified in the next + section. + Discussion: 4. Source Address Selection - The source address selection algorithm chooses a source address for use with a destination address D. It is specified here in terms of the pair-wise comparison of addresses SA and SB. The pair-wise comparison can be used to select an address from the set CandidateSource(D). - This source address selection algorithm only applies to IPv6 destination addresses, not IPv4 addresses. - The pair-wise comparison consists of eight rules, which should be applied in order. If a rule chooses an address, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. If the eight rules fail to choose an address, some unspecified tie-breaker should be used. - Rule 1: Prefer same address. If SA = D, then choose SA. Similarly, if SB = D, then choose SB. - Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then choose SB and otherwise choose SA. Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then choose SA and otherwise choose SB. - + +Draves Standards Track - Expires January 2002 7 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + Rule 3: Avoid deprecated addresses. The addresses SA and SB have the same scope. If one of the source addresses is "preferred" and one of them is "deprecated", choose the one that is preferred. - Rule 4: Prefer home addresses. If SA is simultaneously a home address and care-of address and SB is not, then prefer SA. Similarly, if SB is simultaneously a home @@ -394,23 +346,16 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 An implementation may support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer care-of addresses over home addresses. - Rule 5: Prefer outgoing interface. If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA. Similarly, if SB is assigned to the interface that will be used to send to D and SA is assigned to a different interface, then prefer SB. - -Draves Standards Track - Expires December 2001 7 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - Rule 6: Prefer matching label. If Label(SA) = Label(D) and Label(SB) <> Label(D), then choose SA. Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then choose SB. - Rule 7: Prefer public addresses. If SA is a public address and SB is a temporary address, then prefer SA. Similarly, if SB is a public address and SA is a temporary @@ -419,7 +364,6 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 mechanism (for example, a socket option) to reverse the sense of this preference and prefer temporary addresses over public addresses. - This rule avoids applications potentially failing due to the relatively short lifetime of temporary addresses or due to the possibility of the reverse lookup of a temporary address either @@ -427,67 +371,61 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 privacy considerations outweigh these application compatibility concerns MAY reverse the sense of this rule and by default prefer temporary addresses over public addresses. - Rule 8: Use longest matching prefix. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then choose SB. - - Rule 8 may be superceded if the implementation has other means of + Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation + +Draves Standards Track - Expires January 2002 8 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + somehow knows which source address will result in the "best" communications performance. - Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability. - 5. Destination Address Selection - The destination address selection algorithm takes a list of destination addresses and sorts the addresses to produce a new list. It is specified here in terms of the pair-wise comparison of addresses DA and DB, where DA appears before DB in the original list. - The algorithm sorts together both IPv6 and IPv4 addresses. To find the attributes of an IPv4 address in the policy table, the IPv4 address should be represented as an IPv4-mapped address. - We write Source(D) to indicate the selected source address for a destination D. For IPv6 addresses, the previous section specifies the source address selection algorithm. Source address selection for IPv4 addresses is not specified in this document. - - - -Draves Standards Track - Expires December 2001 8 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - We say that Source(D) is undefined if there is no source address available for destination D. For IPv6 addresses, this is only the case if CandidateSource(D) is the empty set. - The pair-wise comparison of destination addresses consists of nine rules, which should be applied in order. If a rule determines a result, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. - Rule 1: Avoid unusable destinations. - If there is no route to DB or if Source(DB) is undefined, then sort - DA before DB. Similarly, if there is no route to DA or if Source(DA) + If there is no route to DB or the current next-hop neighbor for DB + is known to be unreachable or if Source(DB) is undefined, then sort + DA before DB. Similarly, if there is no route to DA or the current + next-hop neighbor for DA is known to be unreachable or if Source(DA) is undefined, then sort DB before DA. - + For IPv6 destination addresses, the Rule 2: Prefer matching scope. If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), then sort DA before DB. Similarly, if Scope(DA) <> Scope(Source(DA)) and Scope(DB) = Scope(Source(DB)), then sort DB before DA. - Rule 3: Avoid deprecated addresses. If Source(DA) is deprecated and Source(DB) is not, then sort DB before DA. Similarly, if Source(DA) is not deprecated and Source(DB) is deprecated, then sort DA before DB. - + +Draves Standards Track - Expires January 2002 9 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + Rule 4: Prefer home addresses. If Source(DA) is simultaneously a home address and care-of address and Source(DB) is not, then sort DA before DB. Similarly, if @@ -497,47 +435,34 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 of address, then sort DA before DB. Similarly, if Source(DA) is just a care-of address and Source(DB) is just a home address, then sort DB before DA. - Rule 5: Prefer matching label. If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), then sort DA before DB. Similarly, if Label(Source(DA)) <> Label(DA) and Label(Source(DB)) = Label(DB), then sort DB before DA. - Rule 6: Prefer higher precedence. If Precedence(DA) > Precedence(DB), then sort DA before DB. Similarly, if Precedence(DA) < Precedence(DB), then sort DB before DA. - Rule 7: Prefer smaller scope. If Scope(DA) < Scope(DB), then sort DA before DB. Similarly, if Scope(DA) > Scope(DB), then sort DB before DA. - Rule 8: Use longest matching prefix. If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then sort DA before DB. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then sort DB before DA. - -Draves Standards Track - Expires December 2001 9 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - Rule 9: Otherwise, leave the order unchanged. Sort DA before DB. - - Rules 8 and 9 may be superceded if the implementation has other + Rules 8 and 9 may be superseded if the implementation has other means of sorting destination addresses. For example, if the implementation somehow knows which destination addresses will result in the "best" communications performance. - 6. Interactions with Routing - This specification of source address selection assumes that routing (more precisely, selecting an outgoing interface on a node with multiple interfaces) is done before source address selection. However, implementations may use source address considerations as a tiebreaker when choosing among otherwise equivalent routes. - For example, suppose a node has interfaces on two different links, with both links having a working default router. Both of the interfaces have preferred global addresses. When sending to a global @@ -545,7 +470,11 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 interface over the other, then an implementation may preferentially choose the outgoing interface that will allow it to use the source address that shares a longer common prefix with the destination. - + +Draves Standards Track - Expires January 2002 10 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + Implementations may also use the choice of router to influence the choice of source address. For example, suppose a host is on a link with two routers. One router is advertising a global prefix A and @@ -553,9 +482,7 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 via the first router, the host may prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B. - 7. Implementation Considerations - The destination address selection algorithm needs information about potential source addresses. One possible implementation strategy is for getaddrinfo() to call down to the IPv6 network layer with a list @@ -566,7 +493,6 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 way to reduce this overhead is to cache the sorted address list in the resolver, so that subsequent calls for the same name do not need to resort the list. - Another implementation strategy is to call down to the network layer to retrieve source address information and then sort the list of addresses directly in the context of getaddrinfo(). To reduce @@ -574,15 +500,8 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 cached, amortizing the overhead of retrieving it across multiple calls to getaddrinfo(). In this approach, the implementation may not have knowledge of the outgoing interface for each destination, so it - - -Draves Standards Track - Expires December 2001 10 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - MAY use a looser definition of the candidate set during destination address ordering. - In any case, if the implementation uses cached and possibly stale information in its implementation of destination address selection, or if the ordering of a cached list of destination addresses is @@ -596,15 +515,17 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 counter value with derived state and then later comparing against the current value, the implementation can detect if the derived state is potentially stale. - 8. Security Considerations - This document has no direct impact on Internet infrastructure security. - Note that most source address selection algorithms, including the one specified in this document, expose a potential privacy concern. An unfriendly node can infer correlations among a target node's + +Draves Standards Track - Expires January 2002 11 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + addresses by probing the target node with request packets that force the target host to choose its source address for the reply packets. (Perhaps because the request packets are sent to an anycast or @@ -613,128 +534,101 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 reply packets.) By using different addresses for itself, the unfriendly node can cause the target node to expose the target's own addresses. - 9. Examples - This section contains a number of examples, first of default behavior and then demonstrating the utility of policy table configuration. These examples are provided for illustrative purposes; they should not be construed as normative. - 9.1. Default Source Address Selection - The source address selection rules, in conjunction with the default policy table, produce the following behavior: - Destination: 2001::1 Sources: 3ffe::1 vs fe80::1 Result: 3ffe::1 (prefer appropriate scope) - Destination: 2001::1 Sources: fe80::1 vs fec0::1 Result: fec0::1 (prefer appropriate scope) - -Draves Standards Track - Expires December 2001 11 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - Destination: fec0::1 Sources: fe80::1 vs 2001::1 Result: 2001::1 (prefer appropriate scope) - Destination: ff05::1 Sources: fe80::1 vs fec0::1 vs 2001::1 Result: fec0::1 (prefer appropriate scope) - Destination: 2001::1 Sources: 2001::1 (deprecated) vs 2002::1 Result: 2001::1 (prefer same address) - Destination: fec0::1 Sources: fec0::2 (deprecated) vs 2001::1 Result: fec0::2 (prefer appropriate scope) - Destination: 2001::1 Sources: 2001::2 vs 3ffe::2 Result: 2001::2 (longest-matching-prefix) - Destination: 2001::1 Sources: 2001::2 (care-of address) vs 3ffe::2 (home address) Result: 3ffe::2 (prefer home address) - + +Draves Standards Track - Expires January 2002 12 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + Destination: 2002:836b:2179::1 Sources: 2002:836b:2179::d5e3:7953:13eb:22e8 (temporary) vs 2001::2 Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label) - Destination: 2001::d5e3:0:0:1 Sources: 2001::2 vs 2001::d5e3:7953:13eb:22e8 (temporary) Result: 2001::2 (prefer public address) - 9.2. Default Destination Address Selection - The destination address selection rules, in conjunction with the default policy table and the source address selection rules, produce the following behavior: - Sources: 2001::2 or fe80::1 or 169.254.13.78 Destinations: 2001::1 vs 131.107.65.121 Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 169.254.13.78) (prefer matching scope) - Sources: fe80::1 or 131.107.65.117 Destinations: 2001::1 vs 131.107.65.121 Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src fe80::1) (prefer matching scope) - Sources: 2001::2 or fe80::1 or 10.1.2.4 Destinations: 2001::1 vs 10.1.2.3 Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer higher precedence) - - -Draves Standards Track - Expires December 2001 12 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - Sources: 2001::2 or fec0::2 or fe80::2 Destinations: 2001::1 vs fec0::1 vs fe80::1 Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then 2001::1 (src 2001::2) (prefer smaller scope) - Sources: 2001::2 (care-of address) or 3ffe::1 (home address) or fec0::2 (care-of address) or fe80::2 (care-of address) Destinations: 2001::1 vs fec0::1 Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home address) - Sources: 2001::2 or fec0::2 (deprecated) or fe80::2 Destinations: 2001::1 vs fec0::1 Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid deprecated addresses) - Sources: 2001::2 or 3f44::2 or fe80::2 Destinations: 2001::1 vs 3ffe::1 Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest matching prefix) - Sources: 2002:836b:4179::2 or fe80::2 Destinations: 2002:836b:4179::1 vs 2001::1 + +Draves Standards Track - Expires January 2002 13 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src 2002:836b:4179::2) (prefer matching label) - Sources: 2002:836b:4179::2 or 2001::2 or fe80::2 Destinations: 2002:836b:4179::1 vs 2001::1 Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src 2002:836b:4179::2) (prefer higher precedence) - 9.3. Configuring Preference for IPv6 vs IPv4 - The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. This means that applications will use IPv6 in preference to IPv4 when the two are equally suitable. An administrator can change the policy table to prefer IPv4 addresses by giving the ::ffff:0.0.0.0/96 prefix a higher precedence: - Prefix Precedence Label ::1/128 50 0 ::/0 40 1 @@ -744,31 +638,19 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 This change to the default policy table produces the following behavior: - Sources: 2001::2 or fe80::1 or 169.254.13.78 Destinations: 2001::1 vs 131.107.65.121 - - - -Draves Standards Track - Expires December 2001 13 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 169.254.13.78) (prefer matching scope) - Sources: fe80::1 or 131.107.65.117 Destinations: 2001::1 vs 131.107.65.121 Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src fe80::1) (prefer matching scope) - Sources: 2001::2 or fe80::1 or 10.1.2.4 Destinations: 2001::1 vs 10.1.2.3 New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) (prefer higher precedence) - 9.4. Configuring Preference for Scoped Addresses - The destination address selection rules give preference to destinations of smaller scope. For example, a site-local destination will be sorted before a global scope destination when the two are @@ -776,7 +658,11 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 table to reverse this preference and sort global destinations before site-local destinations, and site-local destinations before link- local destinations: - + +Draves Standards Track - Expires January 2002 14 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + Prefix Precedence Label ::1/128 50 0 ::/0 40 1 @@ -788,88 +674,61 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 This change to the default policy table produces the following behavior: - Sources: 2001::2 or fec0::2 or fe80::2 Destinations: 2001::1 vs fec0::1 vs fe80::1 New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then fe80::1 (src fe80::2) (prefer higher precedence) - Sources: 2001::2 (deprecated) or fec0::2 or fe80::2 Destinations: 2001::1 vs fec0::1 Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2) (avoid deprecated addresses) - 9.5. Configuring a Multi-Homed Site - Consider a site A that has a business-critical relationship with another site B. To support their business needs, the two sites have contracted for service with a special high-performance ISP. This is in addition to the normal Internet connection that both sites have with different ISPs. The high-performance ISP is expensive and the - - -Draves Standards Track - Expires December 2001 14 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - two sites wish to use it only for their business-critical traffic with each other. - Each site has two global prefixes, one from the high-performance ISP and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48 from the high-performance ISP and prefix 2007:0:aaaa::/48 from its normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high- performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All hosts in both sites register two addresses in the DNS. - The routing within both sites directs most traffic to the egress to the normal ISP, but the routing directs traffic sent to the other site's 2001 prefix to the egress to the high-performance ISP. To prevent unintended use of their high-performance ISP connection, the two sites implement ingress filtering to discard traffic entering from the high-performance ISP that is not from the other site. - The default policy table and address selection rules produce the following behavior: - Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b + +Draves Standards Track - Expires January 2002 15 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) (longest matching prefix) - In other words, when a host in site A initiates a connection to a host in site B, the traffic does not take advantage of their connections to the high-performance ISP. This is not their desired behavior. - Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then 2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) - In other words, when a host in site A initiates a connection to a host in some other site C, the reverse traffic may come back through the high-performance ISP. Again, this is not their desired behavior. - This situation demonstrates the limitations of the longest-matching- prefix heuristic in multi-homed situations. - However, the administrators of sites A and B can achieve their desired behavior via policy table configuration. For example, they can use the following policy table: - - - - - - - - - -Draves Standards Track - Expires December 2001 15 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - Prefix Precedence Label ::1 50 0 2001:aaaa:aaaa::/48 45 5 @@ -880,232 +739,181 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 ::ffff:0:0/96 10 4 This policy table produces the following behavior: - Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then 2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence) - In other words, when a host in site A initiates a connection to a host in site B, the traffic uses the high-performance ISP as desired. - Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then 2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) - In other words, when a host in site A initiates a connection to a host in some other site C, the traffic uses the normal ISP as desired. - + +Draves Standards Track - Expires January 2002 16 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + References 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. - 2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. - 3 S. Thompson, T. Narten, "IPv6 Stateless Address Autoconfig- uration", RFC 2462 , December 1998. - 4 T. Narten, R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. - 5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-13.txt, November 2000. - 6 S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local Addresses", draft-ietf-zeroconf-ipv4-linklocal-02.txt, March 2001. - 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - - -Draves Standards Track - Expires December 2001 16 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - - 8 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. - 9 S. Deering et. al, "IP Version 6 Scoped Address Architecture", draft-ietf-ipngwg-scoping-arch-02.txt, March 2001. - 10 Y. Rekhter et. al, "Address Allocation for Private Internets", RFC 1918, February 1996. - 11 F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. - 12 B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. - + 13 T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for + IP Version 6", RFC 2461, December 1998. Acknowledgments - The author would like to acknowledge the contributions of the IPng Working Group, particularly Marc Blanchet, Brian Carpenter, Matt - Crawford, Steve Deering, Jun-ichiro itojun Hagino, Tony Hain, M.T. - Hollinger, Erik Nordmark, Ken Powell, Markku Savela, Dave Thaler, - and Mauro Tortonesi. Please let the author know if you contributed - to the development of this draft and are not mentioned here. - + Crawford, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony + Hain, M.T. Hollinger, JINMEI Tatuya, Erik Nordmark, Ken Powell, + Markku Savela, Dave Thaler, Ole Troan, and Mauro Tortonesi. Please + let the author know if you contributed to the development of this + draft and are not mentioned here. + +Draves Standards Track - Expires January 2002 17 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + Author's Address - Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052 Phone: 1-425-936-2268 Email: richdr@microsoft.com - Revision History - +Changes from draft-ietf-ipngwg-default-addr-select-04 + Clarified candidate set formation for routers. + Added some explanatory discussion to the candidate set section. + Replaced usages of scope id with zone index. + Augmented the first destination-address selection rule, to avoid + destination addresses for which the current next-hop neighbor is + known to be unreachable. Changes from draft-ietf-ipngwg-default-addr-select-03 - Reversed the treatment of temporary addresses, so that unless an application specifies otherwise public addresses are preferred over temporary addresses. - Added text clarifying our expectation that applications should iterate through the list of possible destination addresses until finding a working address. - Removed references to getipnodebyname(). - Changes from draft-ietf-ipngwg-default-addr-select-02 - Changed scope treatment of IPv4-compatible and 6to4 addresses, so they are always considered to be global. Removed mention of IPX addresses. - -Draves Standards Track - Expires December 2001 17 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - Changed home address rules to favor addresses that are simultaneously home and care-of addresses, over addresses that are just home addresses or just care-of addresses. - Combined SrcLabel & DstLabel in the policy table into a single Label attribute. - Added mention of the invalidation counter technique in the implementation section. - + +Draves Standards Track - Expires January 2002 18 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + Changes from draft-ietf-ipngwg-default-addr-select-01 - Added Examples section, demonstrating default behavior and some policy table configuration scenarios. - Removed many uses of MUST. Remaining uses concern the candidate set of source addresses and the source address selection rule that prefers source addresses of appropriate scope. - Simplified the default policy table. Reordered the source address selection rules to reduce the influence of policy labels. Added more destination address selection rules. - Added scoping of v4-compatible and 6to4 addresses based on the embedded IPv4 address. - Changed references to anonymous addresses to use the new term, temporary addresses. - Clarified that a user-level implementation of destination address ordering, which does not have knowledge of the outgoing interface for each destination, may use a looser definition of the candidate set. - Clarified that an implementation should prevent an application or upper-layer from choosing a source address that is not in the candidate set and not prevent an application or upper-layer from choosing a source address that is in the candidate set. - Miscellaneous editorial changes, including adding some missing references. - Changes from draft-ietf-ipngwg-default-addr-select-00 - Changed the candidate set definition so that the strong host model is recommended but not required. Added a rule to source address selection to prefer addresses assigned to the outgoing interface. - Simplified the destination address selection algorithm, by having it use source address selection as a subroutine. - Added a rule to source address selection to handle anonymous/public addresses. - -Draves Standards Track - Expires December 2001 18 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 - - Added a rule to source address selection to handle home/care-of addresses. - Changed to allow destination address selection to sort both IPv6 and IPv4 addresses. Added entries in the default policy table for IPv4- mapped addresses. - Changed default precedences, so v4-compatible addresses have lower precedence than 6to4 addresses. - + +Draves Standards Track - Expires January 2002 19 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 + + Changes from draft-draves-ipngwg-simple-srcaddr-01 - Added framework discussion. - Added algorithm for destination address ordering. - Added mechanism to allow the specification of administrative policy that can override the default behavior. - Added section on routing interactions and TBD section on mobility interactions. - Changed the candidate set definition for source address selection, so that only addresses assigned to the outgoing interface are allowed. - Changed the loopback address treatment to link-local scope. - Changes from draft-draves-ipngwg-simple-srcaddr-00 - Minor wording changes because DHCPv6 also supports "preferred" and "deprecated" addresses. - Specified treatment of other format prefixes; now they are considered global scope, "preferred" addresses. - Reiterated that anycast and multicast addresses are not allowed as source addresses. - Recommended that source addresses be taken from the outgoing interface. Required this for multicast destinations. Added analogous requirements for link-local and site-local destinations. - Specified treatment of the loopback address. - Changed the second selection rule so that if both candidate source addresses have scope greater or equal than the destination address and only of them is preferred, the preferred address is chosen. - - - - - -Draves Standards Track - Expires December 2001 19 -draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 +Draves Standards Track - Expires January 2002 20 +draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 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 @@ -1119,41 +927,13 @@ draft-ietf-ipngwg-default-addr-select-04 May 14, 2001 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. - - - - - - - - - - - - - - - - - - - - - - - - - - -Draves Standards Track - Expires December 2001 20 \ No newline at end of file +Draves Standards Track - Expires January 2002 21 \ No newline at end of file