diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt deleted file mode 100644 index eaf68656cc..0000000000 --- a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt +++ /dev/null @@ -1,1501 +0,0 @@ -Network Working Group J. Ihren -Internet-Draft Autonomica AB -Expires: April 18, 2005 O. Kolkman - RIPE NCC - B. Manning - EP.net - October 18, 2004 - - - - An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for - DNSSEC Trust Anchors. - draft-ietf-dnsext-trustupdate-threshold-00 - - -Status of this Memo - - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - - 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 April 18, 2005. - - -Copyright Notice - - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - -Abstract - - - The DNS Security Extensions (DNSSEC) works by validating so called - chains of authority. The start of these chains of authority are - usually public keys that are anchored in the DNS clients. These keys - are known as the so called trust anchors. - - - - - -Ihren, et al. Expires April 18, 2005 [Page 1] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - This memo describes a method how these client trust anchors can be - replaced using the DNS validation and querying mechanisms (in-band) - when the key pairs used for signing by zone owner are rolled. - - - This memo also describes a method to establish the validity of trust - anchors for initial configuration, or priming, using out of band - mechanisms. - - -Table of Contents - - - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry - Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction and Background . . . . . . . . . . . . . . . . . 5 - 2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5 - 3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7 - 3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2 Threshold-based Trust Update . . . . . . . . . . . . . . . 8 - 3.3 Possible Trust Update States . . . . . . . . . . . . . . . 9 - 3.4 Implementation notes . . . . . . . . . . . . . . . . . . . 10 - 3.5 Possible transactions . . . . . . . . . . . . . . . . . . 11 - 3.5.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12 - 3.5.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12 - 3.5.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12 - 3.5.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12 - 3.6 Removal of trust anchors for a trust point . . . . . . . . 12 - 3.7 No need for resolver-side overlap of old and new keys . . 13 - 4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14 - 4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.1.1 Bootstrapping trust anchors using a priming key . . . 14 - 4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15 - 5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 6.1 Threshold-based Trust Update Security Considerations . . . 17 - 6.2 Priming Key Security Considerations . . . . . . . . . . . 17 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 - 8.2 Informative References . . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 - A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 - B. Document History . . . . . . . . . . . . . . . . . . . . . . . 23 - B.1 prior to version 00 . . . . . . . . . . . . . . . . . . . 23 - B.2 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23 - Intellectual Property and Copyright Statements . . . . . . . . 24 - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 2] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -1. Terminology - - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", - and "MAY" in this document are to be interpreted as described in - RFC2119 [1]. - - - The term "zone" refers to the unit of administrative control in the - Domain Name System. In this document "name server" denotes a DNS - name server that is authoritative (i.e. knows all there is to know) - for a DNS zone. A "zone owner" is the entity responsible for signing - and publishing a zone on a name server. The terms "authentication - chain", "bogus", "trust anchors" and "Island of Security" are defined - in [4]. Throughout this document we use the term "resolver" to mean - "Validating Stub Resolvers" as defined in [4]. - - - We use the term "security apex" as the zone for which a trust anchor - has been configured (by validating clients) and which is therefore, - by definition, at the root of an island of security. The - configuration of trust anchors is a client side issue. Therefore a - zone owner may not always know if their zone has become a security - apex. - - - A "stale anchor" is a trust anchor (a public key) that relates to a - key that is not used for signing. Since trust anchors indicate that - a zone is supposed to be secure a validator will mark the all data in - an island of security as bogus when all trust anchors become stale. - - - It is assumed that the reader is familiar with public key - cryptography concepts [REF: Schneier Applied Cryptography] and is - able to distinguish between the private and public parts of a key - based on the context in which we use the term "key". If there is a - possible ambiguity we will explicitly mention if a private or a - public part of a key is used. - - - The term "administrator" is used loosely throughout the text. In - some cases an administrator is meant to be a person, in other cases - the administrator may be a process that has been delegated certain - responsibilities. - - -1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points - - - Although the DNSSEC protocol does not make a distinction between - different keys the operational practice is that a distinction is made - between zone signing keys and key signing keys. A key signing key is - used to exclusively sign the DNSKEY Resource Record (RR) set at the - apex of a zone and the zone signing keys sign all the data in the - zone (including the DNSKEY RRset at the apex). - - - - - -Ihren, et al. Expires April 18, 2005 [Page 3] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - Keys that are intended to be used as the start of the authentication - chain for a particular zone, either because they are pointed to by a - parental DS RR or because they are configured as a trust anchor, are - called Secure Entry Point (SEP) keys. In practice these SEP keys - will be key signing keys. - - - In order for the mechanism described herein to work the keys that are - intended to be used as secure entry points MUST have the SEP [2] flag - set. In the examples it is assumed that keys with the SEP flag set - are used as key signing keys and thus exclusively sign the DNSKEY - RRset published at the apex of the zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 4] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -2. Introduction and Background - - - When DNSSEC signatures are validated the resolver constructs a chain - of authority from a pre-configured trust anchor to the DNSKEY - Resource Record (RR), which contains the public key that validates - the signature stored in an RRSIG RR. DNSSEC is designed so that the - administrator of a resolver can validate data in multiple islands of - security by configuring multiple trust anchors. - - - It is expected that resolvers will have more than one trust anchor - configured. Although there is no deployment experience it is not - unreasonable to expect resolvers to be configured with a number of - trust anchors that varies between order 1 and order 1000. Because - zone owners are expected to roll their keys, trust anchors will have - to be maintained (in the resolver end) in order not to become stale. - - - Since there is no global key maintenance policy for zone owners and - there are no mechanisms in the DNS to signal the key maintenance - policy it may be very hard for resolvers administrators to keep their - set of trust anchors up to date. For instance, if there is only one - trust anchor configured and the key maintenance policy is clearly - published, through some out of band trusted channel, then a resolver - administrator can probably keep track of key rollovers and update the - trust anchor manually. However, with an increasing number of trust - anchors all rolled according to individual policies that are all - published through different channels this soon becomes an - unmanageable problem. - - -2.1 Dangers of Stale Trust Anchors - - - Whenever a SEP key at a security apex is rolled there exists a danger - that "stale anchors" are created. A stale anchor is a trust anchor - (i.e. a public key configured in a validating resolver) that relates - to a private key that is no longer used for signing. - - - The problem with a stale anchors is that they will (from the - validating resolvers point of view) prove data to be false even - though it is actually correct. This is because the data is either - signed by a new key or is no longer signed and the resolver expects - data to be signed by the old (now stale) key. - - - This situation is arguably worse than not having a trusted key - configured for the secure entry point, since with a stale key no - lookup is typically possible (presuming that the default - configuration of a validating recursive nameserver is to not give out - data that is signed but failed to verify. - - - The danger of making configured trust anchors become stale anchors - - - - -Ihren, et al. Expires April 18, 2005 [Page 5] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - may be a reason for zone owners not to roll their keys. If a - resolver is configured with many trust anchors that need manual - maintenance it may be easy to not notice a key rollover at a security - apex, resulting in a stale anchor. - - - In Section 3 this memo sets out a lightweight, in-DNS, mechanism to - track key rollovers and modify the configured trust anchors - accordingly. The mechanism is stateless and does not need protocol - extensions. The proposed design is that this mechanism is - implemented as a "trust updating machine" that is run entirely - separate from the validating resolver except that the trust updater - will have influence over the trust anchors used by the latter. - - - In Section 4 we describe a method [Editors note: for now only the - frame work and a set of requirements] to install trust anchors. This - method can be used at first configuration or when the trust anchors - became stale (typically due to a failure to track several rollover - events). - - - The choice for which domains trust anchors are to be configured is a - local policy issue. So is the choice which trust anchors has - prevalence if there are multiple chains of trust to a given piece of - DNS data (e.g. when a parent zone and its child both have trust - anchors configured). Both issues are out of the scope of this - document. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 6] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -3. Threshold-based Trust Anchor Rollover - - -3.1 The Rollover - - - When a key pair is replaced all signatures (in DNSSEC these are the - RRSIG records) created with the old key will be replaced by new - signatures created by the new key. Access to the new public key is - needed to verify these signatures. - - - Since zone signing keys are in "the middle" of a chain of authority - they can be verified using the signature made by a key signing key. - Rollover of zone signing keys is therefore transparent to validators - and requires no action in the validator end. - - - But if a key signing key is rolled a resolver can determine its - authenticity by either following the authorization chain from the - parents DS record, an out-of-DNS authentication mechanism or by - relying on other trust anchors known for the zone in which the key is - rolled. - - - The threshold trust anchor rollover mechanism (or trust update), - described below, is based on using existing trust anchors to verify a - subset of the available signatures. This is then used as the basis - for a decision to accept the new keys as valid trust anchors. - - - Our example pseudo zone below contains a number of key signing keys - numbered 1 through Y and two zone signing keys A and B. During a key - rollover key 2 is replaced by key Y+1. The zone content changes - from: - - - example.com. DNSKEY key1 - example.com. DNSKEY key2 - example.com. DNSKEY key3 - ... - example.com. DNSKEY keyY - - - example.com. DNSKEY keyA - example.com. DNSKEY keyB - - - example.com. RRSIG DNSKEY ... (key1) - example.com. RRSIG DNSKEY ... (key2) - example.com. RRSIG DNSKEY ... (key3) - ... - example.com. RRSIG DNSKEY ... (keyY) - example.com. RRSIG DNSKEY ... (keyA) - example.com. RRSIG DNSKEY ... (keyB) - - - to: - - - - -Ihren, et al. Expires April 18, 2005 [Page 7] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - example.com. DNSKEY key1 - example.com. DNSKEY key3 - ... - example.com. DNSKEY keyY - example.com. DNSKEY keyY+1 - - - example.com. RRSIG DNSKEY ... (key1) - example.com. RRSIG DNSKEY ... (key3) - ... - example.com. RRSIG DNSKEY ... (keyY) - example.com. RRSIG DNSKEY ... (keyY+1) - example.com. RRSIG DNSKEY ... (keyA) - example.com. RRSIG DNSKEY ... (keyB) - - - When the rollover becomes visible to the verifying stub resolver it - will be able to verify the RRSIGs associated with key1, key3 ... - keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will - not be used for validation, since that key is previously unknown and - therefore not trusted. - - - Note that this example is simplified. Because of operational - considerations described in [5] having a period during which the two - key signing keys are both available is necessary. - - -3.2 Threshold-based Trust Update - - - The threshold-based trust update algorithm applies as follows. If - for a particular secure entry point - o if the DNSKEY RRset in the zone has been replaced by a more recent - one (as determined by comparing the RRSIG inception dates) - and - o if at least M configured trust anchors directly verify the related - RRSIGs over the new DNSKEY RRset - and - o the number of configured trust anchors that verify the related - RRSIGs over the new DNSKEY RRset exceed a locally defined minimum - number that should be greater than one - then all the trust anchors for the particular secure entry point are - replaced by the set of keys from the zones DNSKEY RRset that have the - SEP flag set. - - - The choices for the rollover acceptance policy parameter M is left to - the administrator of the resolver. To be certain that a rollover is - accepted up by resolvers using this mechanism zone owners should roll - as few SEP keys at a time as possible (preferably just one). That - way they comply to the most strict rollover acceptance policy of - M=N-1. - - - - - -Ihren, et al. Expires April 18, 2005 [Page 8] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - The value of M has an upper bound, limited by the number of of SEP - keys a zone owner publishes (i.e. N). But there is also a lower - bound, since it will not be safe to base the trust in too few - signatures. The corner case is M=1 when any validating RRSIG will be - sufficient for a complete replacement of the trust anchors for that - secure entry point. This is not a recommended configuration, since - that will allow an attacker to initiate rollover of the trust anchors - himself given access to just one compromised key. Hence M should in - be strictly larger than 1 as shown by the third requirement above. - - - If the rollover acceptance policy is M=1 then the result for the - rollover in our example above should be that the local database of - trust anchors is updated by removing key "key2" from and adding key - "keyY+1" to the key store. - - -3.3 Possible Trust Update States - - - We define five states for trust anchor configuration at the client - side. - PRIMING: There are no trust anchors configured. There may be priming - keys available for initial priming of trust anchors. - IN-SYNC: The set of trust anchors configured exactly matches the set - of SEP keys used by the zone owner to sign the zone. - OUT-OF-SYNC: The set of trust anchors is not exactly the same as the - set of SEP keys used by the zone owner to sign the zone but there - are enough SEP key in use by the zone owner that is also in the - trust anchor configuration. - UNSYNCABLE: There is not enough overlap between the configured trust - anchors and the set of SEP keys used to sign the zone for the new - set to be accepted by the validator (i.e. the number of - signatures that verify is not sufficient). - STALE: There is no overlap between the configured trust anchors and - the set of SEP keys used to sign the zone. Here validation of - data is no longer possible and hence we are in a situation where - the trust anchors are stale. - - - Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of - the automatic trust update mechanism. The PRIMING state is where a - validator is located before acquiring an up-to-date set of trust - anchors. The transition from PRIMING to IN-SYNC is manual (see - Section 4 below). - - - Example: assume a secure entry point with four SEP keys and a - validator with the policy that it will accept any update to the set - of trust anchors as long as no more than two signatures fail to - validate (i.e. M >= N-2) and at least two signature does validate - (i.e. M >= 2). In this case the rollover of a single key will move - the validator from IN-SYNC to OUT-OF-SYNC. When the trust update - - - - -Ihren, et al. Expires April 18, 2005 [Page 9] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - state machine updates the trust anchors it returns to state IN-SYNC. - - - If if for some reason it fails to update the trust anchors then the - next rollover (of a different key) will move the validator from - OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys - that are configured as trust anchors and that is sufficient to accpt - an automatic update of the trust anchors. - - - The UNSYNCABLE state is where a validator is located if it for some - reason fails to incorporate enough updates to the trust anchors to be - able to accept new updates according to its local policy. In this - example (i.e. with the policy specified above) this will either be - because M < N-2 or M < 2, which does not suffice to authenticate a - successful update of trust anchors. - - - Continuing with the previous example where two of the four SEP keys - have already rolled, but the validator has failed to update the set - of trust anchors. When the third key rolls over there will only be - one trust anchor left that can do successful validation. This is not - sufficient to enable automatic update of the trust anchors, hence the - new state is UNSYNCABLE. Note, however, that the remaining - up-to-date trust anchor is still enough to do successful validation - so the validator is still "working" from a DNSSEC point of view. - - - The STALE state, finally, is where a validator ends up when it has - zero remaining current trust anchors. This is a dangerous state, - since the stale trust anchors will cause all validation to fail. The - escape is to remove the stale trust anchors and thereby revert to the - PRIMING state. - - -3.4 Implementation notes - - - The DNSSEC protocol specification ordains that a DNSKEY to which a DS - record points should be self-signed. Since the keys that serve as - trust anchors and the keys that are pointed to by DS records serve - the same purpose, they are both secure entry points, we RECOMMEND - that zone owners who want to facilitate the automated rollover scheme - documented herein self-sign DNSKEYs with the SEP bit set and that - implementation check that DNSKEYs with the SEP bit set are - self-signed. - - - In order to maintain a uniform way of determining that a keyset in - the zone has been replaced by a more recent set the automatic trust - update machine SHOULD only accept new DNSKEY RRsets if the - accompanying RRSIGs show a more recent inception date than the - present set of trust anchors. This is also needed as a safe guard - against possible replay attacks where old updates are replayed - "backwards" (i.e. one change at a time, but going in the wrong - - - - -Ihren, et al. Expires April 18, 2005 [Page 10] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - direction, thereby luring the validator into the UNSYNCABLE and - finally STALE states). - - - In order to be resilient against failures the implementation should - collect the DNSKEY RRsets from (other) authoritative servers if - verification of the self signatures fails. - - - The threshold-based trust update mechanism SHOULD only be applied to - algorithms, as represented in the algorithm field in the DNSKEY/RRSIG - [3], that the resolver is aware of. In other words the SEP keys of - unknown algorithms should not be used when counting the number of - available signatures (the N constant) and the SEP keys of unknown - algorithm should not be entered as trust anchors. - - - When in state UNSYNCABLE or STALE manual intervention will be needed - to return to the IN-SYNC state. These states should be flagged. The - most appropriate action is human audit possibly followed by - re-priming (Section 4) the keyset (i.e. manual transfer to the - PRIMING state through removal of the configured trust anchors). - - - An implementation should regularly probe the the authoritative - nameservers for new keys. Since there is no mechanism to publish - rollover frequencies this document RECOMMENDS zone owners not to roll - their key signing keys more often than once per month and resolver - administrators to probe for key rollsovers (and apply the threshold - criterion for acceptance of trust update) not less often than once - per month. If the rollover frequency is higher than the probing - frequency then trust anchors may become stale. The exact relation - between the frequencies depends on the number of SEP keys rolled by - the zone owner and the value M configured by the resolver - administrator. - - - In all the cases below a transaction where the threshold criterion is - not satisfied should be considered bad (i.e. possibly spoofed or - otherwise corrupted data). The most appropriate action is human - audit. - - - There is one case where a "bad" state may be escaped from in an - automated fashion. This is when entering the STALE state where all - DNSSEC validation starts to fail. If this happens it is concievable - that it is better to completely discard the stale trust anchors - (thereby reverting to the PRIMING state where validation is not - possible). A local policy that automates removal of stale trust - anchors is therefore suggested. - - -3.5 Possible transactions - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 11] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -3.5.1 Single DNSKEY replaced - - - This is probably the most typical transaction on the zone owners - part. The result should be that if the threshold criterion is - satisfied then the key store is updated by removal of the old trust - anchor and addition of the new key as a new trust anchor. Note that - if the DNSKEY RRset contains exactly M keys replacement of keys is - not possible, i.e. for automatic rollover to work M must be stricly - less than N. - - -3.5.2 Addition of a new DNSKEY (no removal) - - - If the threshold criterion is satisfied then the new key is added as - a configured trust anchor. Not more than N-M keys can be added at - once, since otherwise the algorithm will fail. - - -3.5.3 Removal of old DNSKEY (no addition) - - - If the threshold criterion is satisfied then the old key is removed - from being a configured trust anchor. Note that it is not possible - to reduce the size of the DNSKEY RRset to a size smaller than the - minimum required value for M. - - -3.5.4 Multiple DNSKEYs replaced - - - Arguably it is not a good idea for the zone administrator to replace - several keys at the same time, but from the resolver point of view - this is exactly what will happen if the validating resolver for some - reason failed to notice a previous rollover event. - - - Not more than N-M keys can be replaced at one time or the threshold - criterion will not be satisfied. Or, expressed another way: as long - as the number of changed keys is less than or equal to N-M the - validator is in state OUT-OF-SYNC. When the number of changed keys - becomes greater than N-M the state changes to UNSYNCABLE and manual - action is needed. - - -3.6 Removal of trust anchors for a trust point - - - If the parent of a secure entry point gets signed and it's trusted - keys get configured in the key store of the validating resolver then - the configured trust anchors for the child should be removed entirely - unless explicitly configured (in the utility configuration) to be an - exception. - - - The reason for such a configuration would be that the resolver has a - local policy that requires maintenance of trusted keys further down - the tree hierarchy than strictly needed from the point of view. - - - - -Ihren, et al. Expires April 18, 2005 [Page 12] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - The default action when the parent zone changes from unsigned to - signed should be to remove the configured trust anchors for the - child. This form of "garbage collect" will ensure that the automatic - rollover machinery scales as DNSSEC deployment progresses. - - -3.7 No need for resolver-side overlap of old and new keys - - - It is worth pointing out that there is no need for the resolver to - keep state about old keys versus new keys, beyond the requirement of - tracking signature inception time for the covering RRSIGs as - described in Section 3.4. - - - From the resolver point of view there are only trusted and not - trusted keys. The reason is that the zone owner needs to do proper - maintenance of RRSIGs regardless of the resolver rollover mechanism - and hence must ensure that no key rolled out out the DNSKEY set until - there cannot be any RRSIGs created by this key still legally cached. - - - Hence the rollover mechanism is entirely stateless with regard to the - keys involved: as soon as the resolver (or in this case the rollover - tracking utility) detects a change in the DNSKEY RRset (i.e. it is - now in the state OUT-OF-SYNC) with a sufficient number of matching - RRSIGs the configured trust anchors are immediately updated (and - thereby the machine return to state IN-SYNC). I.e. the rollover - machine changes states (mostly oscillating between IN-SYNC and - OUT-OF-SYNC), but the status of the DNSSEC keys is stateless. - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 13] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -4. Bootstrapping automatic rollovers - - - It is expected that with the ability to automatically roll trust - anchors at trust points will follow a diminished unwillingness to - roll these keys, since the risks associated with stale keys are - minimized. - - - The problem of "priming" the trust anchors, or bringing them into - sync (which could happen if a resolver is off line for a long period - in which a set of SEP keys in a zone 'evolve' away from its trust - anchor configuration) remains. - - - For (re)priming we can rely on out of band technology and we propose - the following framework. - - -4.1 Priming Keys - - - If all the trust anchors roll somewhat frequently (on the order of - months or at most about a year) then it will not be possible to - design a device, or a software distribution that includes trust - anchors, that after being manufactured is put on a shelf for several - key rollover periods before being brought into use (since no trust - anchors that were known at the time of manufacture remain active). - - - To alleviate this we propose the concept of "priming keys". Priming - keys are ordinary DNSSEC Key Signing Keys with the characteristic - that - o The private part of a priming key signs the DNSKEY RRset at the - security apex, i.e. at least one RRSIG DNSKEY is created by a - priming key rather than by an "ordinary" trust anchor - o the public parts of priming keys are not included in the DNSKEY - RRset. Instead the public parts of priming keys are only - available out-of-band. - o The public parts of the priming keys have a validity period. - Within this period they can be used to obtain trust anchors. - o The priming key pairs are long lived (relative to the key rollover - period.) - - -4.1.1 Bootstrapping trust anchors using a priming key - - - To install the trust anchors for a particular security apex an - administrator of a validating resolver will need to: - o query for the DNSKEY RRset of the zone at the security apex; - o verify the self signatures of all DNSKEYs in the RRset; - o verify the signature of the RRSIG made with a priming key -- - verification using one of the public priming keys that is valid at - that moment is sufficient; - - - - - -Ihren, et al. Expires April 18, 2005 [Page 14] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - o create the trust anchors by extracting the DNSKEY RRs with the SEP - flag set. - The SEP keys with algorithms unknown to the validating resolver - SHOULD be ignored during the creation of the trust anchors. - - -4.1.2 Distribution of priming keys - - - The public parts of the priming keys SHOULD be distributed - exclusively through out-of-DNS mechanisms. The requirements for a - distribution mechanism are: - o it can carry the "validity" period for the priming keys; - o it can carry the self-signature of the priming keys; - o and it allows for verification using trust relations outside the - DNS. - A distribution mechanism would benefit from: - o the availability of revocation lists; - o the ability of carrying zone owners policy information such as - recommended values for "M" and "N" and a rollover frequency; - o and the technology on which is based is readily available. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 15] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -5. The Threshold Rollover Mechanism vs Priming - - - There is overlap between the threshold-based trust updater and the - Priming method. One could exclusively use the Priming method for - maintaining the trust anchors. However the priming method probably - relies on "non-DNS' technology and may therefore not be available for - all devices that have a resolver. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 16] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -6. Security Considerations - - -6.1 Threshold-based Trust Update Security Considerations - - - A clear issue for resolvers will be how to ensure that they track all - rollover events for the zones they have configure trust anchors for. - Because of temporary outages validating resolvers may have missed a - rollover of a KSK. The parameters that determine the robustness - against failures are: the length of the period between rollovers - during which the KSK set is stable and validating resolvers can - actually notice the change; the number of available KSKs (i.e. N) - and the number of signatures that may fail to validate (i.e. N-M). - - - With a large N (i.e. many KSKs) and a small value of M this - operation becomes more robust since losing one key, for whatever - reason, will not be crucial. Unfortunately the choice for the number - of KSKs is a local policy issue for the zone owner while the choice - for the parameter M is a local policy issue for the resolver - administrator. - - - Higher values of M increase the resilience against attacks somewhat; - more signatures need to verify for a rollover to be approved. On the - other hand the number of rollover events that may pass unnoticed - before the resolver reaches the UNSYNCABLE state goes down. - - - The threshold-based trust update intentionally does not provide a - revocation mechanism. In the case that a sufficient number of - private keys of a zone owner are simultaneously compromised the the - attacker may use these private keys to roll the trust anchors of (a - subset of) the resolvers. This is obviously a bad situation but it - is not different from most other public keys systems. - - - However, it is important to point out that since any reasonable trust - anchor rollover policy (in validating resolvers) will require more - than one RRSIG to validate this proposal does provide security - concious zone administrators with the option of not storing the - individual private keys in the same location and thereby decreasing - the likelihood of simultaneous compromise. - - -6.2 Priming Key Security Considerations - - - Since priming keys are not included in the DNSKEY RR set they are - less sensitive to packet size constraints and can be chosen - relatively large. The private parts are only needed to sign the - DNSKEY RR set during the validity period of the particular priming - key pair. Note that the private part of the priming key is used each - time when a DNSKEY RRset has to be resigned. In practice there is - therefore little difference between the usage pattern of the private - - - - -Ihren, et al. Expires April 18, 2005 [Page 17] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - part of key signing keys and priming keys. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 18] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -7. IANA Considerations - - - NONE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 19] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -8. References - - -8.1 Normative References - - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - - [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY - (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", - RFC 3757, May 2004. - - - [3] Arends, R., "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-10 (work in progress), - September 2004. - - -8.2 Informative References - - - [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, - "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-12 (work in progress), September - 2004. - - - [5] Kolkman, O., "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practices-01 (work in - progress), May 2004. - - - [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 - Public Key Infrastructure Certificate and CRL Profile", RFC - 2459, January 1999. - - - -Authors' Addresses - - - Johan Ihren - Autonomica AB - Bellmansgatan 30 - Stockholm SE-118 47 - Sweden - - - EMail: johani@autonomica.se - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 20] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - Olaf M. Kolkman - RIPE NCC - Singel 256 - Amsterdam 1016 AB - NL - - - Phone: +31 20 535 4444 - EMail: olaf@ripe.net - URI: http://www.ripe.net/ - - - - Bill Manning - EP.net - Marina del Rey, CA 90295 - USA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 21] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -Appendix A. Acknowledgments - - - The present design for in-band automatic rollovers of DNSSEC trust - anchors is the result of many conversations and it is no longer - possible to remember exactly who contributed what. - - - In addition we've also had appreciated help from (in no particular - order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt - Larson and Mark Kosters. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 22] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -Appendix B. Document History - - - This appendix will be removed if and when the document is submitted - to the RFC editor. - - - The version you are reading is tagged as $Revision: 1.1 $. - - - Text between square brackets, other than references, are editorial - comments and will be removed. - - -B.1 prior to version 00 - - - This draft was initially published as a personal submission under the - name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt. - - - Kolkman documented the ideas provided by Ihren and Manning. In the - process of documenting (and prototyping) Kolkman changed some of the - details of the M-N algorithms working. Ihren did not have a chance - to review the draft before Kolkman posted; - - - Kolkman takes responsibilities for omissions, fuzzy definitions and - mistakes. - - -B.2 version 00 - o The name of the draft was changed as a result of the draft being - adopted as a working group document. - o A small section on the concept of stale trust anchors was added. - o The different possible states are more clearly defined, including - examples of transitions between states. - o The terminology is changed throughout the document. The old term - "M-N" is replaced by "threshold" (more or less). Also the - interpretation of the constants M and N is significantly - simplified to bring the usage more in line with "standard" - threshold terminlogy. - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 23] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -Intellectual Property Statement - - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - -Disclaimer of Validity - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Copyright Statement - - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - -Acknowledgment - - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Ihren, et al. Expires April 18, 2005 [Page 24] \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt deleted file mode 100644 index 02852591ec..0000000000 --- a/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt +++ /dev/null @@ -1,729 +0,0 @@ - - - -Network Working Group M. StJohns -Internet-Draft Nominum, Inc. -Intended status: Informational November 29, 2006 -Expires: June 2, 2007 - - - Automated Updates of DNSSEC Trust Anchors - draft-ietf-dnsext-trustupdate-timers-05 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on June 2, 2007. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes a means for automated, authenticated and - authorized updating of DNSSEC "trust anchors". The method provides - protection against N-1 key compromises of N keys in the trust point - key set. Based on the trust established by the presence of a current - anchor, other anchors may be added at the same place in the - hierarchy, and, ultimately, supplant the existing anchor(s). - - This mechanism will require changes to resolver management behavior - - - -StJohns Expires June 2, 2007 [Page 1] - -Internet-Draft trustanchor-update November 2006 - - - (but not resolver resolution behavior), and the addition of a single - flag bit to the DNSKEY record. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 - 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 - 2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5 - 2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 - 2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 - 2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 - 2.4.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6 - 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 - 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8 - 6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9 - 6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9 - 6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 - 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 - 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10 - 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10 - 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11 - 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11 - 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11 - 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 - Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . . . . 13 - - - - - - - - - - - - - - -StJohns Expires June 2, 2007 [Page 2] - -Internet-Draft trustanchor-update November 2006 - - -1. Introduction - - As part of the reality of fielding DNSSEC (Domain Name System - Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has - come to the realization that there will not be one signed name space, - but rather islands of signed name space each originating from - specific points (i.e. 'trust points') in the DNS tree. Each of those - islands will be identified by the trust point name, and validated by - at least one associated public key. For the purpose of this document - we'll call the association of that name and a particular key a 'trust - anchor'. A particular trust point can have more than one key - designated as a trust anchor. - - For a DNSSEC-aware resolver to validate information in a DNSSEC - protected branch of the hierarchy, it must have knowledge of a trust - anchor applicable to that branch. It may also have more than one - trust anchor for any given trust point. Under current rules, a chain - of trust for DNSSEC-protected data that chains its way back to ANY - known trust anchor is considered 'secure'. - - Because of the probable balkanization of the DNSSEC tree due to - signing voids at key locations, a resolver may need to know literally - thousands of trust anchors to perform its duties. (e.g. Consider an - unsigned ".COM".) Requiring the owner of the resolver to manually - manage this many relationships is problematic. It's even more - problematic when considering the eventual requirement for key - replacement/update for a given trust anchor. The mechanism described - herein won't help with the initial configuration of the trust anchors - in the resolvers, but should make trust point key replacement/ - rollover more viable. - - As mentioned above, this document describes a mechanism whereby a - resolver can update the trust anchors for a given trust point, mainly - without human intervention at the resolver. There are some corner - cases discussed (e.g. multiple key compromise) that may require - manual intervention, but they should be few and far between. This - document DOES NOT discuss the general problem of the initial - configuration of trust anchors for the resolver. - -1.1. Compliance Nomenclature - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, [RFC2119]. - - - - - - - -StJohns Expires June 2, 2007 [Page 3] - -Internet-Draft trustanchor-update November 2006 - - -2. Theory of Operation - - The general concept of this mechanism is that existing trust anchors - can be used to authenticate new trust anchors at the same point in - the DNS hierarchy. When a zone operator adds a new SEP key (i.e. a - DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section - 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is - validated by an existing trust anchor, then the resolver can add the - new key to its valid set of trust anchors for that trust point. - - There are some issues with this approach which need to be mitigated. - For example, a compromise of one of the existing keys could allow an - attacker to add their own 'valid' data. This implies a need for a - method to revoke an existing key regardless of whether or not that - key is compromised. As another example, assuming a single key - compromise, we need to prevent an attacker from adding a new key and - revoking all the other old keys. - -2.1. Revocation - - Assume two trust anchor keys A and B. Assume that B has been - compromised. Without a specific revocation bit, B could invalidate A - simply by sending out a signed trust point key set which didn't - contain A. To fix this, we add a mechanism which requires knowledge - of the private key of a DNSKEY to revoke that DNSKEY. - - A key is considered revoked when the resolver sees the key in a self- - signed RRSet and the key has the REVOKE bit (see Section 7 below) set - to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this - key as a trust anchor or for any other purposes except validating the - RRSIG it signed over the DNSKEY RRSet specifically for the purpose of - validating the revocation. Unlike the 'Add' operation below, - revocation is immediate and permanent upon receipt of a valid - revocation at the resolver. - - A self-signed RRSet is a DNSKEY RRSet which contains the specific - DNSKEY and for which there is a corresponding validated RRSIG record. - It's not a special DNSKEY RRSet, just a way of describing the - validation requirements for that RRSet. - - N.B. A DNSKEY with the REVOKE bit set has a different fingerprint - than one without the bit set. This affects the matching of a DNSKEY - to DS records in the parent, or the fingerprint stored at a resolver - used to configure a trust point. - - In the given example, the attacker could revoke B because it has - knowledge of B's private key, but could not revoke A. - - - - -StJohns Expires June 2, 2007 [Page 4] - -Internet-Draft trustanchor-update November 2006 - - -2.2. Add Hold-Down - - Assume two trust point keys A and B. Assume that B has been - compromised. An attacker could generate and add a new trust anchor - key - C (by adding C to the DNSKEY RRSet and signing it with B), and - then invalidate the compromised key. This would result in both the - attacker and owner being able to sign data in the zone and have it - accepted as valid by resolvers. - - To mitigate but not completely solve this problem, we add a hold-down - time to the addition of the trust anchor. When the resolver sees a - new SEP key in a validated trust point DNSKEY RRSet, the resolver - starts an acceptance timer, and remembers all the keys that validated - the RRSet. If the resolver ever sees the DNSKEY RRSet without the - new key but validly signed, it stops the acceptance process for that - key and resets the acceptance timer. If all of the keys which were - originally used to validate this key are revoked prior to the timer - expiring, the resolver stops the acceptance process and resets the - timer. - - Once the timer expires, the new key will be added as a trust anchor - the next time the validated RRSet with the new key is seen at the - resolver. The resolver MUST NOT treat the new key as a trust anchor - until the hold down time expires AND it has retrieved and validated a - DNSKEY RRSet after the hold down time which contains the new key. - - N.B.: Once the resolver has accepted a key as a trust anchor, the key - MUST be considered a valid trust anchor by that resolver until - explictly revoked as described above. - - In the given example, the zone owner can recover from a compromise by - revoking B and adding a new key D and signing the DNSKEY RRSet with - both A and B. - - The reason this does not completely solve the problem has to do with - the distributed nature of DNS. The resolver only knows what it sees. - A determined attacker who holds one compromised key could keep a - single resolver from realizing that key had been compromised by - intercepting 'real' data from the originating zone and substituting - their own (e.g. using the example, signed only by B). This is no - worse than the current situation assuming a compromised key. - -2.3. Active Refresh - - A resolver which has been configured for automatic update of keys - from a particular trust point MUST query that trust point (e.g. do a - lookup for the DNSKEY RRSet and related RRSIG records) no less often - than the lesser of 15 days or half the original TTL for the DNSKEY - - - -StJohns Expires June 2, 2007 [Page 5] - -Internet-Draft trustanchor-update November 2006 - - - RRSet or half the RRSIG expiration interval and no more often than - once per hour. The expiration interval is the amount of time from - when the RRSIG was last retrieved until the expiration time in the - RRSIG. - - If the query fails, the resolver MUST repeat the query until - satisfied no more often than once an hour and no less often than the - lesser of 1 day or 10% of the original TTL or 10% of the original - expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 * - origTTL, .1 * expireInterval)). - -2.4. Resolver Parameters - -2.4.1. Add Hold-Down Time - - The add hold-down time is 30 days or the expiration time of the - original TTL of the first trust point DNSKEY RRSet which contained - the new key, whichever is greater. This ensures that at least two - validated DNSKEY RRSets which contain the new key MUST be seen by the - resolver prior to the key's acceptance. - -2.4.2. Remove Hold-Down Time - - The remove hold-down time is 30 days. This parameter is solely a key - management database bookeeping parameter. Failure to remove - information about the state of defunct keys from the database will - not adversely impact the security of this protocol, but may end up - with a database cluttered with obsolete key information. - -2.4.3. Minimum Trust Anchors per Trust Point - - A compliant resolver MUST be able to manage at least five SEP keys - per trust point. - - -3. Changes to DNSKEY RDATA Wire Format - - Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE' - flag. If this bit is set to '1', AND the resolver sees an - RRSIG(DNSKEY) signed by the associated key, then the resolver MUST - consider this key permanently invalid for all purposes except for - validating the revocation. - - -4. State Table - - The most important thing to understand is the resolver's view of any - key at a trust point. The following state table describes that view - - - -StJohns Expires June 2, 2007 [Page 6] - -Internet-Draft trustanchor-update November 2006 - - - at various points in the key's lifetime. The table is a normative - part of this specification. The initial state of the key is 'Start'. - The resolver's view of the state of the key changes as various events - occur. - - This is the state of a trust point key as seen from the resolver. - The column on the left indicates the current state. The header at - the top shows the next state. The intersection of the two shows the - event that will cause the state to transition from the current state - to the next. - - - NEXT STATE - -------------------------------------------------- - FROM |Start |AddPend |Valid |Missing|Revoked|Removed| - ---------------------------------------------------------- - Start | |NewKey | | | | | - ---------------------------------------------------------- - AddPend |KeyRem | |AddTime| | | - ---------------------------------------------------------- - Valid | | | |KeyRem |Revbit | | - ---------------------------------------------------------- - Missing | | |KeyPres| |Revbit | | - ---------------------------------------------------------- - Revoked | | | | | |RemTime| - ---------------------------------------------------------- - Removed | | | | | | | - ---------------------------------------------------------- - - - State Table - -4.1. Events - NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. - That key will become a new trust anchor for the named trust point - after it's been present in the RRSet for at least 'add time'. - KeyPres The key has returned to the valid DNSKEY RRSet. - KeyRem The resolver sees a valid DNSKEY RRSet that does not contain - this key. - AddTime The key has been in every valid DNSKEY RRSet seen for at - least the 'add time'. - RemTime A revoked key has been missing from the trust point DNSKEY - RRSet for sufficient time to be removed from the trust set. - RevBit The key has appeared in the trust anchor DNSKEY RRSet with - its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet - signed by this key. - - - - - -StJohns Expires June 2, 2007 [Page 7] - -Internet-Draft trustanchor-update November 2006 - - -4.2. States - Start The key doesn't yet exist as a trust anchor at the resolver. - It may or may not exist at the zone server, but either hasn't yet - been seen at the resolver or was seen but was absent from the last - DNSKEY RRSet (e.g. KeyRem event). - AddPend The key has been seen at the resolver, has its 'SEP' bit - set, and has been included in a validated DNSKEY RRSet. There is - a hold-down time for the key before it can be used as a trust - anchor. - Valid The key has been seen at the resolver and has been included in - all validated DNSKEY RRSets from the time it was first seen up - through the hold-down time. It is now valid for verifying RRSets - that arrive after the hold down time. Clarification: The DNSKEY - RRSet does not need to be continuously present at the resolver - (e.g. its TTL might expire). If the RRSet is seen, and is - validated (i.e. verifies against an existing trust anchor), this - key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. - Missing This is an abnormal state. The key remains as a valid trust - point key, but was not seen at the resolver in the last validated - DNSKEY RRSet. This is an abnormal state because the zone operator - should be using the REVOKE bit prior to removal. - Revoked This is the state a key moves to once the resolver sees an - RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains - this key with its REVOKE bit set to '1'. Once in this state, this - key MUST permanently be considered invalid as a trust anchor. - Removed After a fairly long hold-down time, information about this - key may be purged from the resolver. A key in the removed state - MUST NOT be considered a valid trust anchor. (Note: this state is - more or less equivalent to the "Start" state, except that it's bad - practice to re-introduce previously used keys - think of this as - the holding state for all the old keys for which the resolver no - longer needs to track state.) - - -5. Trust Point Deletion - - A trust point which has all of its trust anchors revoked is - considered deleted and is treated as if the trust point was never - configured. If there are no superior configured trust points, data - at and below the deleted trust point are considered insecure by the - resolver. If there ARE superior configured trust points, data at and - below the deleted trust point are evaluated with respect to the - superior trust point(s). - - Alternately, a trust point which is subordinate to another configured - trust point MAY be deleted by a resolver after 180 days where such - subordinate trust point validly chains to a superior trust point. - The decision to delete the subordinate trust anchor is a local - - - -StJohns Expires June 2, 2007 [Page 8] - -Internet-Draft trustanchor-update November 2006 - - - configuration decision. Once the subordinate trust point is deleted, - validation of the subordinate zone is dependent on validating the - chain of trust to the superior trust point. - - -6. Scenarios - Informative - - The suggested model for operation is to have one active key and one - stand-by key at each trust point. The active key will be used to - sign the DNSKEY RRSet. The stand-by key will not normally sign this - RRSet, but the resolver will accept it as a trust anchor if/when it - sees the signature on the trust point DNSKEY RRSet. - - Since the stand-by key is not in active signing use, the associated - private key may (and should) be provided with additional protections - not normally available to a key that must be used frequently. E.g. - locked in a safe, split among many parties, etc. Notionally, the - stand-by key should be less subject to compromise than an active key, - but that will be dependent on operational concerns not addressed - here. - -6.1. Adding a Trust Anchor - - Assume an existing trust anchor key 'A'. - 1. Generate a new key pair. - 2. Create a DNSKEY record from the key pair and set the SEP and Zone - Key bits. - 3. Add the DNSKEY to the RRSet. - 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - - 'A'. - 5. Wait a while (i.e. for various resolvers timers to go off and for - them to retrieve the new DNSKEY RRSet and signatures). - 6. The new trust anchor will be populated at the resolvers on the - schedule described by the state table and update algorithm - see - Section 2 above - -6.2. Deleting a Trust Anchor - - Assume existing trust anchors 'A' and 'B' and that you want to revoke - and delete 'A'. - 1. Set the revocation bit on key 'A'. - 2. Sign the DNSKEY RRSet with both 'A' and 'B'. - 'A' is now revoked. The operator should include the revoked 'A' in - the RRSet for at least the remove hold-down time, but then may remove - it from the DNSKEY RRSet. - - - - - - -StJohns Expires June 2, 2007 [Page 9] - -Internet-Draft trustanchor-update November 2006 - - -6.3. Key Roll-Over - - Assume existing keys A and B. 'A' is actively in use (i.e. has been - signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been - in the DNSKEY RRSet and is a valid trust anchor, but wasn't being - used to sign the RRSet.) - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'A'. - 4. Sign the RRSet with 'A' and 'B'. - 'A' is now revoked, 'B' is now the active key, and 'C' will be the - stand-by key once the hold-down expires. The operator should include - the revoked 'A' in the RRSet for at least the remove hold-down time, - but may then remove it from the DNSKEY RRSet. - -6.4. Active Key Compromised - - This is the same as the mechanism for Key Roll-Over (Section 6.3) - above assuming 'A' is the active key. - -6.5. Stand-by Key Compromised - - Using the same assumptions and naming conventions as Key Roll-Over - (Section 6.3) above: - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'B'. - 4. Sign the RRSet with 'A' and 'B'. - 'B' is now revoked, 'A' remains the active key, and 'C' will be the - stand-by key once the hold-down expires. 'B' should continue to be - included in the RRSet for the remove hold-down time. - -6.6. Trust Point Deletion - - To delete a trust point which is subordinate to another configured - trust point (e.g. example.com to .com) requires some juggling of the - data. The specific process is: - 1. Generate a new DNSKEY and DS record and provide the DS record to - the parent along with DS records for the old keys - 2. Once the parent has published the DSs, add the new DNSKEY to the - RRSet and revoke ALL of the old keys at the same time while - signing the DNSKEY RRSet with all of the old and new keys. - 3. After 30 days stop publishing the old, revoked keys and remove - any corresponding DS records in the parent. - Revoking the old trust point keys at the same time as adding new keys - that chain to a superior trust prevents the resolver from adding the - new keys as trust anchors. Adding DS records for the old keys avoids - a race condition where either the subordinate zone becomes unsecure - - - -StJohns Expires June 2, 2007 [Page 10] - -Internet-Draft trustanchor-update November 2006 - - - (because the trust point was deleted) or becomes bogus (because it - didn't chain to the superior zone). - - -7. IANA Considerations - - The IANA will need to assign a bit in the DNSKEY flags field (see - section 4.3 of [RFC3755]) for the REVOKE bit. There are no other - IANA actions required. - - -8. Security Considerations - - In addition to the following sections, see also Theory of Operation - above and especially Section 2.2 for related discussions. - -8.1. Key Ownership vs Acceptance Policy - - The reader should note that, while the zone owner is responsible for - creating and distributing keys, it's wholly the decision of the - resolver owner as to whether to accept such keys for the - authentication of the zone information. This implies the decision to - update trust anchor keys based on trust for a current trust anchor - key is also the resolver owner's decision. - - The resolver owner (and resolver implementers) MAY choose to permit - or prevent key status updates based on this mechanism for specific - trust points. If they choose to prevent the automated updates, they - will need to establish a mechanism for manual or other out-of-band - updates outside the scope of this document. - -8.2. Multiple Key Compromise - - This scheme permits recovery as long as at least one valid trust - anchor key remains uncompromised. E.g. if there are three keys, you - can recover if two of them are compromised. The zone owner should - determine their own level of comfort with respect to the number of - active valid trust anchors in a zone and should be prepared to - implement recovery procedures once they detect a compromise. A - manual or other out-of-band update of all resolvers will be required - if all trust anchor keys at a trust point are compromised. - -8.3. Dynamic Updates - - Allowing a resolver to update its trust anchor set based on in-band - key information is potentially less secure than a manual process. - However, given the nature of the DNS, the number of resolvers that - would require update if a trust anchor key were compromised, and the - - - -StJohns Expires June 2, 2007 [Page 11] - -Internet-Draft trustanchor-update November 2006 - - - lack of a standard management framework for DNS, this approach is no - worse than the existing situation. - - -9. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer (DS)", RFC 3755, May 2004. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -Editorial Comments - - [msj2] msj: To be assigned. - - -Author's Address - - Michael StJohns - Nominum, Inc. - 2385 Bay Road - Redwood City, CA 94063 - USA - - Phone: +1-301-528-4729 - Email: Mike.StJohns@nominum.com - URI: www.nominum.com - - - - - - - - - - - -StJohns Expires June 2, 2007 [Page 12] - -Internet-Draft trustanchor-update November 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -StJohns Expires June 2, 2007 [Page 13] - - diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt deleted file mode 100644 index 9cf88a5831..0000000000 --- a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt +++ /dev/null @@ -1,1063 +0,0 @@ -Internet-Draft dnsext-wcard January 9, 2006 - -DNSEXT Working Group E. Lewis -INTERNET DRAFT NeuStar -Expiration Date: July 9, 2006 January 9, 2006 -Updates RFC 1034, RFC 2672 - - The Role of Wildcards - in the Domain Name System - draft-ietf-dnsext-wcard-clarify-10.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that - any applicable patent or other IPR claims of which he or she is - aware have been or will be disclosed, and any of which he or she - becomes aware will be disclosed, in accordance with Section 6 of - BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - This Internet-Draft will expire on July 9, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This is an update to the wildcard definition of RFC 1034. The - interaction with wildcards and CNAME is changed, an error - condition removed, and the words defining some concepts central - to wildcards are changed. The overall goal is not to change - wildcards, but to refine the definition of RFC 1034. - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 1] - -Internet-Draft dnsext-wcard January 9, 2006 - -Table of Contents - -1. Introduction . . . . . . . . . . . . . . . . 3 -1 1 Motivation 3 -1 2 The Original Definition 3 -1 3 Roadmap to This Document 4 -1 3 1 New Terms 4 -1.3.2 Changed Text 5 -1.3.3 Considerations with Special Types 5 -1.4 Standards Terminology 5 -2. Wildcard Syntax . . . . . . . . . . . . . . . 6 -2.1 Identifying a Wildcard 6 -2.1.1 Wild Card Domain Name and Asterisk Label 6 -2.1.2 Asterisks and Other Characters 6 -2.1.3 Non-terminal Wild Card Domain Names 6 -2.2 Existence Rules 7 -2.2.1 An Example 7 -2.2.2 Empty Non-terminals 9 -2.2.3 Yet Another Definition of Existence 10 -2.3 When is a Wild Card Domain Name Not Special 10 -3. Impact of a Wild Card Domain Name On a Response . . . . . 10 -3.1 Step 2 10 -3.2 Step 3 11 -3.3 Part 'c' 11 -3.3.1 Closest Encloser and the Source of Synthesis 12 -3.3.2 Closest Encloser and Source of Synthesis Examples 12 -3.3.3 Type Matching 13 -4. Considerations with Special Types . . . . . . . . . 13 -4.1 SOA RRSet at a Wild Card Domain Name 13 -4.2 NS RRSet at a Wild Card Domain Name 14 -4.2.1 Discarded Notions 14 -4.3 CNAME RRSet at a Wild Card Domain Name 15 -4.4 DNAME RRSet at a Wild Card Domain Name 15 -4.5 SRV RRSet at a Wild Card Domain Name 16 -4.6 DS RRSet at a Wild Card Domain Name 16 -4.7 NSEC RRSet at a Wild Card Domain Name 17 -4.8 RRSIG at a Wild Card Domain Name 17 -4.9 Empty Non-terminal Wild Card Domain Name 17 -5. Security Considerations . . . . . . . . . . . . . 17 -6. IANA Considerations . . . . . . . . . . . . . 17 -7. References . . . . . . . . . . . . . 17 -8. Editor . . . . . . . . . . . . . 18 -9. Others Contributing to the Document . . . . . . . . 18 -10. Trailing Boilerplate . . . . . . . . . . . . . 19 - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 2] - -Internet-Draft dnsext-wcard January 9, 2006 - -1. Introduction - - In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the - synthesis of answers from special resource records called - wildcards. The definition in RFC 1034 is incomplete and has - proven to be confusing. This document describes the wildcard - synthesis by adding to the discussion and making limited - modifications. Modifications are made to close inconsistencies - that have led to interoperability issues. This description - does not expand the service intended by the original definition. - - Staying within the spirit and style of the original documents, - this document avoids specifying rules for DNS implementations - regarding wildcards. The intention is to only describe what is - needed for interoperability, not restrict implementation choices. - In addition, consideration is given to minimize any backwards - compatibility issues with implementations that comply with RFC - 1034's definition. - - This document is focused on the concept of wildcards as defined - in RFC 1034. Nothing is implied regarding alternative means of - synthesizing resource record sets, nor are alternatives discussed. - -1.1 Motivation - - Many DNS implementations diverge, in different ways, from the - original definition of wildcards. Although there is clearly a - need to clarify the original documents in light of this alone, - the impetus for this document lay in the engineering of the DNS - security extensions [RFC4033]. With an unclear definition of - wildcards the design of authenticated denial became entangled. - - This document is intended to limit its changes, documenting only - those based on implementation experience, and to remain as close - to the original document as possible. To reinforce that this - document is meant to clarify and adjust and not redefine wildcards, - relevant sections of RFC 1034 are repeated verbatim to facilitate - comparison of the old and new text. - -1.2 The Original Definition - - The definition of the wildcard concept is comprised by the - documentation of the algorithm by which a name server prepares - a response (in RFC 1034's section 4.3.2) and the way in which - a resource record (set) is identified as being a source of - synthetic data (section 4.3.3). - - This is the definition of the term "wildcard" as it appears in - RFC 1034, section 4.3.3. - - - -DNSEXT Working Group Expires July 9, 2006 [Page 3] - -Internet-Draft dnsext-wcard January 9, 2006 - -# In the previous algorithm, special treatment was given to RRs with -# owner names starting with the label "*". Such RRs are called -# wildcards. Wildcard RRs can be thought of as instructions for -# synthesizing RRs. When the appropriate conditions are met, the name -# server creates RRs with an owner name equal to the query name and -# contents taken from the wildcard RRs. - - This passage follows the algorithm in which the term wildcard - is first used. In this definition, wildcard refers to resource - records. In other usage, wildcard has referred to domain names, - and it has been used to describe the operational practice of - relying on wildcards to generate answers. It is clear from this - that there is a need to define clear and unambiguous terminology - in the process of discussing wildcards. - - The mention of the use of wildcards in the preparation of a - response is contained in step 3c of RFC 1034's section 4.3.2 - entitled "Algorithm." Note that "wildcard" does not appear in - the algorithm, instead references are made to the "*" label. - The portion of the algorithm relating to wildcards is - deconstructed in detail in section 3 of this document, this is - the beginning of the relevant portion of the "Algorithm." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if [...] -# the "*" label exists. - - The scope of this document is the RFC 1034 definition of - wildcards and the implications of updates to those documents, - such as DNSSEC. Alternate schemes for synthesizing answers are - not considered. (Note that there is no reference listed. No - document is known to describe any alternate schemes, although - there has been some mention of them in mailing lists.) - -1.3 Roadmap to This Document - - This document accomplishes these three items. - o Defines new terms - o Makes minor changes to avoid conflicting concepts - o Describes the actions of certain resource records as wildcards - -1.3.1 New Terms - - To help in discussing what resource records are wildcards, two - terms will be defined - "asterisk label" and "wild card domain - name". These are defined in section 2.1.1. - - To assist in clarifying the role of wildcards in the name server - algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest - encloser" are defined. These definitions are in section 3.3.2. - "Label match" is defined in section 3.2. - -DNSEXT Working Group Expires July 9, 2006 [Page 4] - -Internet-Draft dnsext-wcard January 9, 2006 - - The new terms are used to make discussions of wildcards clearer. - Terminology doesn't directly have an impact on implementations. - -1.3.2 Changed Text - - The definition of "existence" is changed superficially. This - change will not be apparent to implementations; it is needed to - make descriptions more precise. The change appears in section - 2.2.3. - - RFC 1034, section 4.3.3., seems to prohibit having two asterisk - labels in a wildcard owner name. With this document the - restriction is removed entirely. This change and its implications - are in section 2.1.3. - - The actions when a source of synthesis owns a CNAME RR are - changed to mirror the actions if an exact match name owns a - CNAME RR. This is an addition to the words in RFC 1034, - section 4.3.2, step 3, part c. The discussion of this is in - section 3.3.3. - - Only the latter change represents an impact to implementations. - The definition of existence is not a protocol impact. The change - to the restriction on names is unlikely to have an impact, as - RFC 1034 contained no specification on when and how to enforce the - restriction. - -1.3.3 Considerations with Special Types - - This document describes semantics of wildcard RRSets for - "interesting" types as well as empty non-terminal wildcards. - Understanding these situations in the context of wildcards has - been clouded because these types incur special processing if - they are the result of an exact match. This discussion is in - section 4. - - These discussions do not have an implementation impact, they cover - existing knowledge of the types, but to a greater level of detail. - -1.4 Standards Terminology - - This document does not use terms as defined in "Key words for use - in RFCs to Indicate Requirement Levels." [RFC2119] - - Quotations of RFC 1034 are denoted by a '#' in the leftmost - column. References to section "4.3.2" are assumed to refer - to RFC 1034's section 4.3.2, simply titled "Algorithm." - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 5] - -Internet-Draft dnsext-wcard January 9, 2006 - -2. Wildcard Syntax - - The syntax of a wildcard is the same as any other DNS resource - record, across all classes and types. The only significant - feature is the owner name. - - Because wildcards are encoded as resource records with special - names, they are included in zone transfers and incremental zone - transfers[RFC1995] just as non-wildcard resource records are. - This feature has been under appreciated until discussions on - alternative approaches to wildcards appeared on mailing lists. - -2.1 Identifying a Wildcard - - To provide a more accurate description of wildcards, the - definition has to start with a discussion of the domain names - that appear as owners. Two new terms are needed, "Asterisk - Label" and "Wild Card Domain Name." - -2.1.1 Wild Card Domain Name and Asterisk Label - - A "wild card domain name" is defined by having its initial - (i.e., left-most or least significant) label be, in binary format: - - 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) - - The first octet is the normal label type and length for a 1 octet - long label, the second octet is the ASCII representation [RFC20] - for the '*' character. - - A descriptive name of a label equaling that value is an "asterisk - label." - - RFC 1034's definition of wildcard would be "a resource record - owned by a wild card domain name." - -2.1.2 Asterisks and Other Characters - - No label values other than that in section 2.1.1 are asterisk - labels, hence names beginning with other labels are never wild - card domain names. Labels such as 'the*' and '**' are not - asterisk labels so these labels do not start wild card domain - names. - -2.1.3 Non-terminal Wild Card Domain Names - - In section 4.3.3, the following is stated: - -# .......................... The owner name of the wildcard RRs is of -# the form "*.", where is any domain name. -# should not contain other * labels...................... - -DNSEXT Working Group Expires July 9, 2006 [Page 6] - -Internet-Draft dnsext-wcard January 9, 2006 - - The restriction is now removed. The original documentation of it - is incomplete and the restriction does not serve any purpose - given years of operational experience. - - There are three possible reasons for putting the restriction in - place, but none of the three has held up over time. One is - that the restriction meant that there would never be subdomains - of wild card domain names, but the restriciton as stated still - permits "example.*.example." for instance. Another is that - wild card domain names are not intended to be empty non-terminals, - but this situation does not disrupt the algorithm in 4.3.2. - Finally, "nested" wild card domain names are not ambiguous once - the concept of the closest encloser had been documented. - - A wild card domain name can have subdomains. There is no need - to inspect the subdomains to see if there is another asterisk - label in any subdomain. - - A wild card domain name can be an empty non-terminal. (See the - upcoming sections on empty non-terminals.) In this case, any - lookup encountering it will terminate as would any empty - non-terminal match. - -2.2 Existence Rules - - The notion that a domain name 'exists' is mentioned in the - definition of wildcards. In section 4.3.3 of RFC 1034: - -# Wildcard RRs do not apply: -# -... -# - When the query name or a name between the wildcard domain and -# the query name is know[n] to exist. For example, if a wildcard - - "Existence" is therefore an important concept in the understanding - of wildcards. Unfortunately, the definition of what exists, in RFC - 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is - taken at the definition of existence. - -2.2.1 An Example - - To illustrate what is meant by existence consider this complete - zone: - - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 7] - -Internet-Draft dnsext-wcard January 9, 2006 - - $ORIGIN example. - example. 3600 IN SOA - example. 3600 NS ns.example.com. - example. 3600 NS ns.example.net. - *.example. 3600 TXT "this is a wild card" - *.example. 3600 MX 10 host1.example. - sub.*.example. 3600 TXT "this is not a wild card" - host1.example. 3600 A 192.0.4.1 - _ssh._tcp.host1.example. 3600 SRV - _ssh._tcp.host2.example. 3600 SRV - subdel.example. 3600 NS ns.example.com. - subdel.example. 3600 NS ns.example.net. - - A look at the domain names in a tree structure is helpful: - - | - -------------example------------ - / / \ \ - / / \ \ - / / \ \ - * host1 host2 subdel - | | | - | | | - sub _tcp _tcp - | | - | | - _ssh _ssh - - The following responses would be synthesized from one of the - wildcards in the zone: - - QNAME=host3.example. QTYPE=MX, QCLASS=IN - the answer will be a "host3.example. IN MX ..." - - QNAME=host3.example. QTYPE=A, QCLASS=IN - the answer will reflect "no error, but no data" - because there is no A RR set at '*.example.' - - QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN - the answer will be "foo.bar.example. IN TXT ..." - because bar.example. does not exist, but the wildcard - does. - - The following responses would not be synthesized from any of the - wildcards in the zone: - - QNAME=host1.example., QTYPE=MX, QCLASS=IN - because host1.example. exists - - QNAME=sub.*.example., QTYPE=MX, QCLASS=IN - because sub.*.example. exists - -DNSEXT Working Group Expires July 9, 2006 [Page 8] - -Internet-Draft dnsext-wcard January 9, 2006 - - QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN - because _tcp.host1.example. exists (without data) - - QNAME=host.subdel.example., QTYPE=A, QCLASS=IN - because subdel.example. exists (and is a zone cut) - - QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN - because *.example. exists - - The final example highlights one common misconception about - wildcards. A wildcard "blocks itself" in the sense that a - wildcard does not match its own subdomains. I.e. "*.example." - does not match all names in the "example." zone, it fails to - match the names below "*.example." To cover names under - "*.example.", another wild card domain name is needed - - "*.*.example." - which covers all but it's own subdomains. - -2.2.2 Empty Non-terminals - - Empty non-terminals [RFC2136, Section 7.16] are domain names - that own no resource records but have subdomains that do. In - section 2.2.1, "_tcp.host1.example." is an example of a empty - non-terminal name. Empty non-terminals are introduced by this - text in section 3.1 of RFC 1034: - -# The domain name space is a tree structure. Each node and leaf on -# the tree corresponds to a resource set (which may be empty). The -# domain system makes no distinctions between the uses of the -# interior nodes and leaves, and this memo uses the term "node" to -# refer to both. - - The parenthesized "which may be empty" specifies that empty non- - terminals are explicitly recognized, and that empty non-terminals - "exist." - - Pedantically reading the above paragraph can lead to an - interpretation that all possible domains exist - up to the - suggested limit of 255 octets for a domain name [RFC1035]. - For example, www.example. may have an A RR, and as far as is - practically concerned, is a leaf of the domain tree. But the - definition can be taken to mean that sub.www.example. also - exists, albeit with no data. By extension, all possible domains - exist, from the root on down. - - As RFC 1034 also defines "an authoritative name error indicating - that the name does not exist" in section 4.3.1, so this apparently - is not the intent of the original definition, justifying the - need for an updated definition in the next section. - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 9] - -Internet-Draft dnsext-wcard January 9, 2006 - -2.2.3 Yet Another Definition of Existence - - RFC1034's wording is fixed by the following paragraph: - - The domain name space is a tree structure. Nodes in the tree - either own at least one RRSet and/or have descendants that - collectively own at least one RRSet. A node may exist with no - RRSets only if it has descendents that do, this node is an empty - non-terminal. - - A node with no descendants is a leaf node. Empty leaf nodes do - not exist. - - Note that at a zone boundary, the domain name owns data, - including the NS RR set. In the delegating zone, the NS RR - set is not authoritative, but that is of no consequence here. - The domain name owns data, therefore, it exists. - -2.3 When is a Wild Card Domain Name Not Special - - When a wild card domain name appears in a message's query section, - no special processing occurs. An asterisk label in a query name - only matches a single, corresponding asterisk label in the - existing zone tree when the 4.3.2 algorithm is being followed. - - When a wild card domain name appears in the resource data of a - record, no special processing occurs. An asterisk label in that - context literally means just an asterisk. - -3. Impact of a Wild Card Domain Name On a Response - - RFC 1034's description of how wildcards impact response - generation is in its section 4.3.2. That passage contains the - algorithm followed by a server in constructing a response. - Within that algorithm, step 3, part 'c' defines the behavior of - the wildcard. - - The algorithm in section 4.3.2. is not intended to be pseudo-code, - i.e., its steps are not intended to be followed in strict order. - The "algorithm" is a suggested means of implementing the - requirements. As such, in step 3, parts a, b, and c, do not have - to be implemented in that order, provided that the result of the - implemented code is compliant with the protocol's specification. - -3.1 Step 2 - - Step 2 of section 4.3.2 reads: - -# 2. Search the available zones for the zone which is the nearest -# ancestor to QNAME. If such a zone is found, go to step 3, -# otherwise step 4. - -DNSEXT Working Group Expires July 9, 2006 [Page 10] - -Internet-Draft dnsext-wcard January 9, 2006 - - In this step, the most appropriate zone for the response is - chosen. The significance of this step is that it means all of - step 3 is being performed within one zone. This has significance - when considering whether or not an SOA RR can be ever be used for - synthesis. - -3.2 Step 3 - - Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. - But the beginning of the step is important and needs explanation. - -# 3. Start matching down, label by label, in the zone. The -# matching process can terminate several ways: - - The word 'matching' refers to label matching. The concept - is based in the view of the zone as the tree of existing names. - The query name is considered to be an ordered sequence of - labels - as if the name were a path from the root to the owner - of the desired data. (Which it is - 3rd paragraph of RFC 1034, - section 3.1.) - - The process of label matching a query name ends in exactly one of - three choices, the parts 'a', 'b', and 'c'. Either the name is - found, the name is below a cut point, or the name is not found. - - Once one of the parts is chosen, the other parts are not - considered. (E.g., do not execute part 'c' and then change - the execution path to finish in part 'b'.) The process of label - matching is also done independent of the query type (QTYPE). - - Parts 'a' and 'b' are not an issue for this clarification as they - do not relate to record synthesis. Part 'a' is an exact match - that results in an answer, part 'b' is a referral. - -3.3 Part 'c' - - The context of part 'c' is that the process of label matching the - labels of the query name has resulted in a situation in which - there is no corresponding label in the tree. It is as if the - lookup has "fallen off the tree." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if [...] -# the "*" label exists. - - To help describe the process of looking 'to see if [...] the "*" - label exists' a term has been coined to describe the last domain - (node) matched. The term is "closest encloser." - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 11] - -Internet-Draft dnsext-wcard January 9, 2006 - -3.3.1 Closest Encloser and the Source of Synthesis - - The closest encloser is the node in the zone's tree of existing - domain names that has the most labels matching the query name - (consecutively, counting from the root label downward). Each match - is a "label match" and the order of the labels is the same. - - The closest encloser is, by definition, an existing name in the - zone. The closest encloser might be an empty non-terminal or even - be a wild card domain name itself. In no circumstances is the - closest encloser to be used to synthesize records for the current - query. - - The source of synthesis is defined in the context of a query - process as that wild card domain name immediately descending - from the closest encloser, provided that this wild card domain - name exists. "Immediately descending" means that the source - of synthesis has a name of the form: - .. - A source of synthesis does not guarantee having a RRSet to use - for synthesis. The source of synthesis could be an empty - non-terminal. - - If the source of synthesis does not exist (not on the domain - tree), there will be no wildcard synthesis. There is no search - for an alternate. - - The important concept is that for any given lookup process, there - is at most one place at which wildcard synthetic records can be - obtained. If the source of synthesis does not exist, the lookup - terminates, the lookup does not look for other wildcard records. - -3.3.2 Closest Encloser and Source of Synthesis Examples - - To illustrate, using the example zone in section 2.2.1 of this - document, the following chart shows QNAMEs and the closest - enclosers. - - QNAME Closest Encloser Source of Synthesis - host3.example. example. *.example. - _telnet._tcp.host1.example. _tcp.host1.example. no source - _telnet._tcp.host2.example. host2.example. no source - _telnet._tcp.host3.example. example. *.example. - _chat._udp.host3.example. example. *.example. - foobar.*.example. *.example. no source - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 12] - -Internet-Draft dnsext-wcard January 9, 2006 - -3.3.3 Type Matching - - RFC 1034 concludes part 'c' with this: - -# If the "*" label does not exist, check whether the name -# we are looking for is the original QNAME in the query -# or a name we have followed due to a CNAME. If the name -# is original, set an authoritative name error in the -# response and exit. Otherwise just exit. -# -# If the "*" label does exist, match RRs at that node -# against QTYPE. If any match, copy them into the answer -# section, but set the owner of the RR to be QNAME, and -# not the node with the "*" label. Go to step 6. - - The final paragraph covers the role of the QTYPE in the lookup - process. - - Based on implementation feedback and similarities between step - 'a' and step 'c' a change to this passage has been made. - - The change is to add the following text to step 'c' prior to the - instructions to "go to step 6": - - If the data at the source of synthesis is a CNAME, and - QTYPE doesn't match CNAME, copy the CNAME RR into the - answer section of the response changing the owner name - to the QNAME, change QNAME to the canonical name in the - CNAME RR, and go back to step 1. - - This is essentially the same text in step a covering the - processing of CNAME RRSets. - -4. Considerations with Special Types - - Sections 2 and 3 of this document discuss wildcard synthesis - with respect to names in the domain tree and ignore the impact - of types. In this section, the implication of wildcards of - specific types are discussed. The types covered are those - that have proven to be the most difficult to understand. The - types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and - "none," i.e., empty non-terminal wild card domain names. - -4.1 SOA RRSet at a Wild Card Domain Name - - A wild card domain name owning an SOA RRSet means that the - domain is at the root of the zone (apex). The domain can not - be a source of synthesis because that is, by definition, a - descendent node (of the closest encloser) and a zone apex is - at the top of the zone. - - -DNSEXT Working Group Expires July 9, 2006 [Page 13] - -Internet-Draft dnsext-wcard January 9, 2006 - - Although a wild card domain name owning an SOA RRSet can never - be a source of synthesis, there is no reason to forbid the - ownership of an SOA RRSet. - - E.g., given this zone: - $ORIGIN *.example. - @ 3600 IN SOA - 3600 NS ns1.example.com. - 3600 NS ns1.example.net. - www 3600 TXT "the www txt record" - - A query for www.*.example.'s TXT record would still find the - "the www txt record" answer. The asterisk label only becomes - significant when section 4.3.2, step 3 part 'c' is in effect. - - Of course, there would need to be a delegation in the parent - zone, "example." for this to work too. This is covered in the - next section. - -4.2 NS RRSet at a Wild Card Domain Name - - With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now - in place, the semantics of a wild card domain name owning an - NS RRSet has come to be poorly defined. The dilemma relates to - a conflict between the rules for synthesis in part 'c' and the - fact that the resulting synthesis generates a record for which - the zone is not authoritative. In a DNSSEC signed zone, the - mechanics of signature management (generation and inclusion - in a message) have become unclear. - - Salient points of the working group discussion on this topic is - summarized in section 4.2.1. - - As a result of these discussion, there is no definition given for - wild card domain names owning an NS RRSet. The semantics are - left undefined until there is a clear need to have a set defined, - and until there is a clear direction to proceed. Operationally, - inclusion of wild card NS RRSets in a zone is discouraged, but - not barred. - -4.2.1 Discarded Notions - - Prior to DNSSEC, a wild card domain name owning a NS RRSet - appeared to be workable, and there are some instances in which - it is found in deployments using implementations that support - this. Continuing to allow this in the specification is not - tenable with DNSSEC. The reason is that the synthesis of the - NS RRSet is being done in a zone that has delegated away the - responsibility for the name. This "unauthorized" synthesis is - not a problem for the base DNS protocol, but DNSSEC, in affirming - the authorization model for DNS exposes the problem. - -DNSEXT Working Group Expires July 9, 2006 [Page 14] - -Internet-Draft dnsext-wcard January 9, 2006 - - Outright banning of wildcards of type NS is also untenable as - the DNS protocol does not define how to handle "illegal" data. - Implementations may choose not to load a zone, but there is no - protocol definition. The lack of the definition is complicated - by having to cover dynamic update [RFC 2136], zone transfers, - as well as loading at the master server. The case of a client - (resolver, caching server) getting a wildcard of type NS in - a reply would also have to be considered. - - Given the daunting challenge of a complete definition of how to - ban such records, dealing with existing implementations that - permit the records today is a further complication. There are - uses of wild card domain name owning NS RRSets. - - One compromise proposed would have redefined wildcards of type - NS to not be used in synthesis, this compromise fell apart - because it would have required significant edits to the DNSSEC - signing and validation work. (Again, DNSSEC catches - unauthorized data.) - - With no clear consensus forming on the solution to this dilemma, - and the realization that wildcards of type NS are a rarity in - operations, the best course of action is to leave this open-ended - until "it matters." - -4.3 CNAME RRSet at a Wild Card Domain Name - - The issue of a CNAME RRSet owned by a wild card domain name has - prompted a suggested change to the last paragraph of step 3c of - the algorithm in 4.3.2. The changed text appears in section - 3.3.3 of this document. - -4.4 DNAME RRSet at a Wild Card Domain Name - - Ownership of a DNAME [RFC2672] RRSet by a wild card domain name - represents a threat to the coherency of the DNS and is to be - avoided or outright rejected. Such a DNAME RRSet represents - non-deterministic synthesis of rules fed to different caches. - As caches are fed the different rules (in an unpredictable - manner) the caches will cease to be coherent. ("As caches - are fed" refers to the storage in a cache of records obtained - in responses by recursive or iterative servers.) - - For example, assume one cache, responding to a recursive - request, obtains the record: - "a.b.example. DNAME foo.bar.example.net." - and another cache obtains: - "b.example. DNAME foo.bar.example.net." - both generated from the record: - "*.example. DNAME foo.bar.example.net." - by an authoritative server. - -DNSEXT Working Group Expires July 9, 2006 [Page 15] - -Internet-Draft dnsext-wcard January 9, 2006 - - The DNAME specification is not clear on whether DNAME records - in a cache are used to rewrite queries. In some interpretations, - the rewrite occurs, in some, it is not. Allowing for the - occurrence of rewriting, queries for "sub.a.b.example. A" may - be rewritten as "sub.foo.bar.tld. A" by the former caching - server and may be rewritten as "sub.a.foo.bar.tld. A" by the - latter. Coherency is lost, an operational nightmare ensues. - - Another justification for banning or avoiding wildcard DNAME - records is the observation that such a record could synthesize - a DNAME owned by "sub.foo.bar.example." and "foo.bar.example." - There is a restriction in the DNAME definition that no domain - exist below a DNAME-owning domain, hence, the wildcard DNAME - is not to be permitted. - -4.5 SRV RRSet at a Wild Card Domain Name - - The definition of the SRV RRset is RFC 2782 [RFC2782]. In the - definition of the record, there is some confusion over the term - "Name." The definition reads as follows: - -# The format of the SRV RR -... -# _Service._Proto.Name TTL Class SRV Priority Weight Port Target -... -# Name -# The domain this RR refers to. The SRV RR is unique in that the -# name one searches for is not this name; the example near the end -# shows this clearly. - - Do not confuse the definition "Name" with the owner name. I.e., - once removing the _Service and _Proto labels from the owner name - of the SRV RRSet, what remains could be a wild card domain name - but this is immaterial to the SRV RRSet. - - E.g., If an SRV record is: - _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. - - *.example is a wild card domain name and although it is the Name - of the SRV RR, it is not the owner (domain name). The owner - domain name is "_foo._udp.*.example." which is not a wild card - domain name. - - The confusion is likely based on the mixture of the specification - of the SRV RR and the description of a "use case." - -4.6 DS RRSet at a Wild Card Domain Name - - A DS RRSet owned by a wild card domain name is meaningless and - harmless. This statement is made in the context that an NS RRSet - at a wild card domain name is undefined. At a non-delegation - -DNSEXT Working Group Expires July 9, 2006 [Page 16] - -Internet-Draft dnsext-wcard January 9, 2006 - - point, a DS RRSet has no value (no corresponding DNSKEY RRSet - will be used in DNSSEC validation). If there is a synthesized - DS RRSet, it alone will not be very useful as it exists in the - context of a delegation point. - -4.7 NSEC RRSet at a Wild Card Domain Name - - Wild card domain names in DNSSEC signed zones will have an NSEC - RRSet. Synthesis of these records will only occur when the - query exactly matches the record. Synthesized NSEC RR's will not - be harmful as they will never be used in negative caching or to - generate a negative response. [RFC2308] - -4.8 RRSIG at a Wild Card Domain Name - - RRSIG records will be present at a wild card domain name in a - signed zone, and will be synthesized along with data sought in a - query. The fact that the owner name is synthesized is not a - problem as the label count in the RRSIG will instruct the - verifying code to ignore it. - -4.9 Empty Non-terminal Wild Card Domain Name - - If a source of synthesis is an empty non-terminal, then the - response will be one of no error in the return code and no RRSet - in the answer section. - -5. Security Considerations - - This document is refining the specifications to make it more - likely that security can be added to DNS. No functional - additions are being made, just refining what is considered - proper to allow the DNS, security of the DNS, and extending - the DNS to be more predictable. - -6. IANA Considerations - - None. - -7. References - - Normative References - - [RFC20] ASCII Format for Network Interchange, V.G. Cerf, - Oct-16-1969 - - [RFC1034] Domain Names - Concepts and Facilities, - P.V. Mockapetris, Nov-01-1987 - - [RFC1035] Domain Names - Implementation and Specification, P.V - Mockapetris, Nov-01-1987 - -DNSEXT Working Group Expires July 9, 2006 [Page 17] - -Internet-Draft dnsext-wcard January 9, 2006 - - [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996 - - [RFC2119] Key Words for Use in RFCs to Indicate Requirement - Levels, S Bradner, March 1997 - - [RFC2308] Negative Caching of DNS Queries (DNS NCACHE), - M. Andrews, March 1998 - - [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, - August 1999. - - [RFC2782] A DNS RR for specifying the location of services (DNS - SRV), A. Gulbrandsen, et.al., February 2000 - - [RFC4033] DNS Security Introduction and Requirements, R. Arends, - et.al., March 2005 - - [RFC4034] Resource Records for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - [RFC4035] Protocol Modifications for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - Informative References - - [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, - April 1997 - -8. Editor - - Name: Edward Lewis - Affiliation: NeuStar - Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US - Phone: +1-571-434-5468 - Email: ed.lewis@neustar.biz - - Comments on this document can be sent to the editor or the mailing - list for the DNSEXT WG, namedroppers@ops.ietf.org. - -9. Others Contributing to the Document - - This document represents the work of a large working group. The - editor merely recorded the collective wisdom of the working group. - - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 17] - -Internet-Draft dnsext-wcard January 9, 2006 - -10. Trailing Boilerplate - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided - on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION - HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET - SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL - WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO - ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT - INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of - any Intellectual Property Rights or other rights that might - be claimed to pertain to the implementation or use of the - technology described in this document or the extent to which - any license under such rights might or might not be available; - nor does it represent that it has made any independent effort - to identify any such rights. Information on the procedures - with respect to rights in RFC documents can be found in BCP 78 - and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the - use of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR - repository at http://www.ietf.org/ipr. The IETF invites any - interested party to bring to its attention any copyrights, - patents or patent applications, or other proprietary rights - that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - -Expiration - - This document expires on or about July 9, 2006. - - - -DNSEXT Working Group Expires July 9, 2006 [Page 19] diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt deleted file mode 100644 index bf2afcdfb3..0000000000 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt +++ /dev/null @@ -1,1848 +0,0 @@ - - - -DNS Operations WG J. Jeong, Ed. -Internet-Draft ETRI/University of Minnesota -Expires: November 6, 2005 May 5, 2005 - - - IPv6 Host Configuration of DNS Server Information Approaches - draft-ietf-dnsop-ipv6-dns-configuration-06.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 6, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document describes three approaches for IPv6 recursive DNS - server address configuration. It details the operational attributes - of three solutions: RA option, DHCPv6 option, and Well-known anycast - addresses for recursive DNS servers. Additionally, it suggests the - deployment scenarios in four kinds of networks, such as ISP, - Enterprise, 3GPP, and Unmanaged networks, considering multi-solution - resolution. Therefore, this document will give the audience a - - - -Jeong Expires November 6, 2005 [Page 1] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - guideline for IPv6 host DNS configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 2] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3. IPv6 DNS Configuration Approaches . . . . . . . . . . . . . . 7 - 3.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 8 - 3.1.3 Observations . . . . . . . . . . . . . . . . . . . . . 9 - 3.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 9 - 3.2.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 11 - 3.2.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 12 - 3.2.3 Observations . . . . . . . . . . . . . . . . . . . . . 12 - 3.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 12 - 3.3.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 13 - 3.3.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 14 - 3.3.3 Observations . . . . . . . . . . . . . . . . . . . . . 14 - 4. Interworking among IPv6 DNS Configuration Approaches . . . . . 15 - 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16 - 5.1 ISP Network . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.1.1 RA Option Approach . . . . . . . . . . . . . . . . . . 16 - 5.1.2 DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17 - 5.1.3 Well-known Anycast Addresses Approach . . . . . . . . 17 - 5.2 Enterprise Network . . . . . . . . . . . . . . . . . . . . 17 - 5.3 3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.3.1 Currently Available Mechanisms and Recommendations . . 19 - 5.3.2 RA Extension . . . . . . . . . . . . . . . . . . . . . 19 - 5.3.3 Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20 - 5.3.4 Well-known Addresses . . . . . . . . . . . . . . . . . 21 - 5.3.5 Recommendations . . . . . . . . . . . . . . . . . . . 21 - 5.4 Unmanaged Network . . . . . . . . . . . . . . . . . . . . 22 - 5.4.1 Case A: Gateway does not provide IPv6 at all . . . . . 22 - 5.4.2 Case B: A dual-stack gateway connected to a - dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22 - 5.4.3 Case C: A dual-stack gateway connected to an - IPv4-only ISP . . . . . . . . . . . . . . . . . . . . 22 - 5.4.4 Case D: A gateway connected to an IPv6-only ISP . . . 23 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 6.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 25 - 6.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 25 - 6.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 25 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . 29 - 9.2 Informative References . . . . . . . . . . . . . . . . . . 29 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31 - A. Link-layer Multicast Acknowledgements for RA Option . . . . . 32 - - - -Jeong Expires November 6, 2005 [Page 3] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - Intellectual Property and Copyright Statements . . . . . . . . 33 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 4] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -1. Introduction - - Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address - Autoconfiguration provide the ways to configure either fixed or - mobile nodes with one or more IPv6 addresses, default routes and some - other parameters [3][4]. To support the access to additional - services in the Internet that are identified by a DNS name, such as a - web server, the configuration of at least one recursive DNS server is - also needed for DNS name resolution. - - This document describes three approaches of recursive DNS server - address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 - option [5]-[7], and (c) Well-known anycast addresses for recursive - DNS servers [9]. Also, it suggests the applicable scenarios for four - kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP - network, and (d) Unmanaged network. - - This document is just an analysis of each possible approach, and does - not make any recommendation on a particular one or on a combination - of particular ones. Some approaches may even not be adopted at all - as a result of further discussion. - - Therefore, the objective of this document is to help the audience - select the approaches suitable for IPv6 host configuration of - recursive DNS servers. - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 5] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -2. Terminology - - This document uses the terminology described in [3]-[9]. In - addition, a new term is defined below: - - o Recursive DNS Server (RDNSS): A Recursive DNS Server is a name - server that offers the recursive service of DNS name resolution. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 6] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -3. IPv6 DNS Configuration Approaches - - In this section, the operational attributes of the three solutions - are described in detail. - -3.1 RA Option - - The RA approach is to define a new ND option called the RDNSS option - that contains a recursive DNS server address. Existing ND transport - mechanisms (i.e., advertisements and solicitations) are used. This - works in the same way that nodes learn about routers and prefixes. - An IPv6 host can configure the IPv6 addresses of one or more RDNSSes - via RA message periodically sent by a router or solicited by a Router - Solicitation (RS) [8]. - - This approach needs RDNSS information to be configured in the routers - doing the advertisements. The configuration of RDNSS addresses can - be performed manually by an operator or other ways, such as automatic - configuration through a DHCPv6 client running on the router. When - advertising more than one RDNSS option, an RA message includes as - many RDNSS options as RDNSSes. - - Through the ND protocol and RDNSS option along with a prefix - information option, an IPv6 host can perform its network - configuration of its IPv6 address and RDNSS simultaneously [3][4]. - The RA option for RDNSS can be used on any network that supports the - use of ND. - - However, it is worth noting that some link layers, such as Wireless - LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast, - which means that they cannot guarantee the timely delivery of RA - messages [25]-[28]. This is discussed in Appendix A. - - The RA approach is useful in some mobile environments where the - addresses of the RDNSSes are changing because the RA option includes - a lifetime field that allows client to use RDNSSes nearer to the - client. This can be configured to a value that will require the - client to time out the entry and switch over to another RDNSS address - [8]. However, from the viewpoint of implementation, the lifetime - field would seem to make matters a bit more complex. Instead of just - writing to a DNS configuration file, such as resolv.conf for the list - of RDNSS addresses, we have to have a daemon around (or a program - that is called at the defined intervals) that keeps monitoring the - lifetime of RDNSSes all the time. - - The preference value of RDNSS, included in the RDNSS option, allows - IPv6 hosts to select primary RDNSS among several RDNSSes; this can be - used for the load balancing of RDNSSes [8]. - - - -Jeong Expires November 6, 2005 [Page 7] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -3.1.1 Advantages - - The RA option for RDNSS has a number of advantages. These include: - - 1. The RA option is an extension of existing ND/Autoconfig - mechanisms [3][4], and does not require a change in the base ND - protocol. - - 2. This approach, like ND, works well on a variety of link types - including point-to-point links, point-to-multipoint, and - multipoint-to-multipoint (i.e., Ethernet LANs), etc. RFC 2461 - [3] states, however, that there may be some link types on which - ND is not feasible; on such links, some other mechanisms will be - needed for DNS configuration. - - 3. All of the information a host needs to run the basic Internet - applications such as the email, web, ftp, etc., can be obtained - with the addition of this option to ND and address - autoconfiguration. The use of a single mechanism is more - reliable and easier to provide than when the RDNSS information is - learned via another protocol mechanism. Debugging problems when - multiple protocol mechanisms are being used is harder and much - more complex. - - 4. This mechanism works over a broad range of scenarios and - leverages IPv6 ND. This works well on links that support - broadcast reliably (e.g., Ethernet LANs) but not necessarily on - other links (e.g., Wireless LANs): Refer to Appendix A. Also, - this works well on links that are high performance (e.g., - Ethernet LANs) and low performance (e.g., Cellular networks). In - the latter case, by combining the RDNSS information with the - other information in the RA, the host can learn all of the - information needed to use most Internet applications, such as the - web in a single packet. This not only saves bandwidth where this - is an issue, but also minimizes the delay needed to learn the - RDNSS information. - - 5. The RA approach could be used as a model for other similar types - of configuration information. New RA options for other server - addresses, such as NTP server address, that are common to all - clients on a subnet would be easy to define. - - -3.1.2 Disadvantages - - 1. ND is mostly implemented in the kernel of operating system. - Therefore, if ND supports the configuration of some additional - services, such as DNS servers, ND should be extended in the - - - -Jeong Expires November 6, 2005 [Page 8] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - kernel, and complemented by a user-land process. DHCPv6, - however, has more flexibility for the extension of service - discovery because it is an application layer protocol. - - 2. The current ND framework should be modified to facilitate the - synchronization between another ND cache for RDNSSes in the - kernel space and the DNS configuration file in the user space. - Because it is unacceptable to write and rewrite to the DNS - configuration file (e.g., resolv.conf) from the kernel, another - approach is needed. One simple approach to solve this is to have - a daemon listening to what the kernel conveys, and to have the - daemon do these steps, but such a daemon is not needed with the - current ND framework. - - 3. It is necessary to configure RDNSS addresses at least at one - router on every link where this information needs to be - configured via the RA option. - - -3.1.3 Observations - - The proposed RDNSS RA option along with the IPv6 ND and - Autoconfiguration allows a host to obtain all of the information it - needs to access the basic Internet services like the web, email, ftp, - etc. This is preferable in the environments where hosts use RAs to - autoconfigure their addresses and all the hosts on the subnet share - the same router and server addresses. If the configuration - information can be obtained from a single mechanism, it is preferable - because it does not add additional delay, and it uses a minimum of - bandwidth. The environments like this include the homes, public - cellular networks, and enterprise environments where no per host - configuration is needed, but exclude public WLAN hot spots. - - DHCPv6 is preferable where it is being used for address configuration - and if there is a need for host specific configuration [5]-[7]. The - environments like this are most likely to be the enterprise - environments where the local administration chooses to have per host - configuration control. - -Note - - The observation section is based on what the proponents of each - approach think makes a good overall solution. - -3.2 DHCPv6 Option - - DHCPv6 [5] includes the "DNS Recursive Name Server" option, through - which a host can obtain a list of IP addresses of recursive DNS - - - -Jeong Expires November 6, 2005 [Page 9] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - servers [7]. The DNS Recursive Name Server option carries a list of - IPv6 addresses of RDNSSes to which the host may send DNS queries. - The DNS servers are listed in the order of preference for use by the - DNS resolver on the host. - - The DNS Recursive Name Server option can be carried in any DHCPv6 - Reply message, in response to either a Request or an Information - request message. Thus, the DNS Recursive Name Server option can be - used either when DHCPv6 is used for address assignment, or when - DHCPv6 is used only for other configuration information as stateless - DHCPv6 [6]. - - Stateless DHCPv6 can be deployed either using DHCPv6 servers running - on general-purpose computers, or on router hardware. Several router - vendors currently implement stateless DHCPv6 servers. Deploying - stateless DHCPv6 in routers has the advantage that no special - hardware is required, and should work well for networks where DHCPv6 - is needed for very straightforward configuration of network devices. - - However, routers can also act as DHCPv6 relay agents. In this case, - the DHCPv6 server need not be on the router - it can be on a general - purpose computer. This has the potential to give the operator of the - DHCPv6 server more flexibility in how the DHCPv6 server responds to - individual clients - clients can easily be given different - configuration information based on their identity, or for any other - reason. Nothing precludes adding this flexibility to a router, but - generally in current practice, DHCP servers running on general- - purpose hosts tend to have more configuration options than those that - are embedded in routers. - - DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 - clients that use a stateful configuration assignment. To do this, - the DHCPv6 server sends a Reconfigure message to the client. The - client validates the Reconfigure message, and then contacts the - DHCPv6 server to obtain updated configuration information. Using - this mechanism, it is currently possible to propagate new - configuration information to DHCPv6 clients as this information - changes. - - The DHC Working Group is currently studying an additional mechanism - through which configuration information, including the list of - RDNSSes, can be updated. The lifetime option for DHCPv6 [10] assigns - a lifetime to configuration information obtained through DHCPv6. At - the expiration of the lifetime, the host contacts the DHCPv6 server - to obtain updated configuration information, including the list of - RDNSSes. This lifetime gives the network administrator another - mechanism to configure hosts with new RDNSSes by controlling the time - at which the host refreshes the list. - - - -Jeong Expires November 6, 2005 [Page 10] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - The DHC Working Group has also discussed the possibility of defining - an extension to DHCPv6 that would allow the use of multicast to - provide configuration information to multiple hosts with a single - DHCPv6 message. Because of the lack of deployment experience, the WG - has deferred consideration of multicast DHCPv6 configuration at this - time. Experience with DHCPv4 has not identified a requirement for - multicast message delivery, even in large service provider networks - with tens of thousands of hosts that may initiate a DHCPv4 message - exchange simultaneously. - -3.2.1 Advantages - - The DHCPv6 option for RDNSS has a number of advantages. These - include: - - 1. DHCPv6 currently provides a general mechanism for conveying - network configuration information to clients. So configuring - DHCPv6 servers allows the network administrator to configure - RDNSSes along with the addresses of other network services, as - well as location-specific information like time zones. - - 2. As a consequence, when the network administrator goes to - configure DHCPv6, all the configuration information can be - managed through a single service, typically with a single user - interface and a single configuration database. - - 3. DHCPv6 allows for the configuration of a host with information - specific to that host, so that hosts on the same link can be - configured with different RDNSSes as well as with other - configuration information. This capability is important in some - network deployments such as service provider networks or WiFi hot - spots. - - 4. A mechanism exists for extending DHCPv6 to support the - transmission of additional configuration that has not yet been - anticipated. - - 5. Hosts that require other configuration information such as the - addresses of SIP servers and NTP servers are likely to need - DHCPv6 for other configuration information. - - 6. The specification for configuration of RDNSSes through DHCPv6 is - available as an RFC. No new protocol extensions such as new - options are necessary. - - 7. Interoperability among independent implementations has been - demonstrated. - - - - -Jeong Expires November 6, 2005 [Page 11] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -3.2.2 Disadvantages - - The DHCPv6 option for RDNSS has a few disadvantages. These include: - - 1. Update currently requires message from server (however, see - [10]). - - 2. Because DNS information is not contained in RA messages, the host - must receive two messages from the router, and must transmit at - least one message to the router. On networks where bandwidth is - at a premium, this is a disadvantage, although on most networks - it is not a practical concern. - - 3. Increased latency for initial configuration - in addition to - waiting for an RA message, the client must now exchange packets - with a DHCPv6 server; even if it is locally installed on a - router, this will slightly extend the time required to configure - the client. For clients that are moving rapidly from one network - to another, this will be a disadvantage. - - -3.2.3 Observations - - In the general case, on general-purpose networks, stateless DHCPv6 - provides significant advantages and no significant disadvantages. - Even in the case where bandwidth is at a premium and low latency is - desired, if hosts require other configuration information in addition - to a list of RDNSSes or if hosts must be configured selectively, - those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive - name server option will be advantageous. - - However, we are aware of some applications where it would be - preferable to put the RDNSS information into an RA packet; for - example, on a cell phone network, where bandwidth is at a premium and - extremely low latency is desired. The final DNS configuration draft - should be written so as to allow these special applications to be - handled using DNS information in the RA packet. - -3.3 Well-known Anycast Addresses - - Anycast uses the same routing system as unicast [11]. However, - administrative entities are local ones. The local entities may - accept unicast routes (including default routes) to anycast servers - from adjacent entities. The administrative entities should not - advertise their peers routes to their internal anycast servers, if - they want to prohibit external access from some peers to the servers. - If some advertisement is inevitable (such as the case with default - routes), the packets to the servers should be blocked at the boundary - - - -Jeong Expires November 6, 2005 [Page 12] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - of the entities. Thus, for this anycast, not only unicast routing - but also unicast ND protocols can be used as is. - - First of all, the well-known anycast addresses approach is much - different from that discussed at IPv6 Working Group in the past [9]. - It should be noted that "anycast" in this memo is simpler than that - of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be - prohibited to have multiple servers on a single link sharing an - anycast address. That is, on a link, an anycast address is assumed - to be unique. DNS clients today already have redundancy by having - multiple well-known anycast addresses configured as RDNSS addresses. - There is no point in having multiple RDNSSes sharing an anycast - address on a single link. - - The approach with well-known anycast addresses is to set multiple - well-known anycast addresses in clients' resolver configuration files - from the beginning, say, as factory default. Thus, there is no - transport mechanism and no packet format [9]. - - An anycast address is an address shared by multiple servers (in this - case, the servers are RDNSSes). A request from a client to the - anycast address is routed to a server selected by the routing system. - However, it is a bad idea to mandate "site" boundary on anycast - addresses, because most users just do not have their own servers and - want to access their ISPs' across their site boundaries. Larger - sites may also depend on their ISPs or may have their own RDNSSes - within "site" boundaries. - -3.3.1 Advantages - - The basic advantage of the well-known addresses approach is that it - uses no transport mechanism. Thus, - - 1. There is no delay to get the response and no further delay by - packet losses. - - 2. The approach can be combined with any other configuration - mechanisms, such as the RA-based approach and DHCP based - approach, as well as the factory default configuration. - - 3. The approach works over any environment where DNS works. - - Another advantage is that the approach needs to configure DNS servers - as a router, but nothing else. Considering that DNS servers do need - configuration, the amount of overall configuration effort is - proportional to the number of the DNS servers and scales linearly. - It should be noted that, in the simplest case where a subscriber to - an ISP does not have any DNS server, the subscriber naturally - - - -Jeong Expires November 6, 2005 [Page 13] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - accesses DNS servers of the ISP even though the subscriber and the - ISP do nothing and there is no protocol to exchange DNS server - information between the subscriber and the ISP. - -3.3.2 Disadvantages - - Well-known anycast addresses approach requires that DNS servers (or - routers near it as a proxy) act as routers to advertise their anycast - addresses to the routing system, which requires some configuration - (see the last paragraph of the previous section on the scalability of - the effort). - -3.3.3 Observations - - If other approaches are used in addition, the well-known anycast - addresses should also be set in RA or DHCP configuration files to - reduce the configuration effort of users. - - The redundancy by multiple RDNSSes is better provided by multiple - servers having different anycast addresses than multiple servers - sharing the same anycast address because the former approach allows - stale servers to still generate routes to their anycast addresses. - Thus, in a routing domain (or domains sharing DNS servers), there - will be only one server having an anycast address unless the domain - is so large that load distribution is necessary. - - Small ISPs will operate one RDNSS at each anycast address which is - shared by all the subscribers. Large ISPs may operate multiple - RDNSSes at each anycast address to distribute and reduce load, where - the boundary between RDNSSes may be fixed (redundancy is still - provided by multiple addresses) or change dynamically. DNS packets - with the well-known anycast addresses are not expected (though not - prohibited) to cross ISP boundaries, as ISPs are expected to be able - to take care of themselves. - - Because "anycast" in this memo is simpler than that of RFC 1546 [11] - and RFC 3513 [12] where it is assumed to be administratively - prohibited to have multiple servers on a single link sharing an - anycast address, anycast in this memo should be implemented as - UNICAST of RFC 2461 [3] and RFC 3513 [12]. As a result, ND-related - instability disappears. Thus, anycast in well-known anycast - addresses approach can and should use the anycast address as a source - unicast (according to RFC 3513 [12]) address of packets of UDP and - TCP responses. With TCP, if a route flips and packets to an anycast - address are routed to a new server, it is expected that the flip is - detected by ICMP or sequence number inconsistency and the TCP - connection is reset and retried. - - - - -Jeong Expires November 6, 2005 [Page 14] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -4. Interworking among IPv6 DNS Configuration Approaches - - Three approaches can work together for IPv6 host configuration of - RDNSS. This section shows a consideration on how these approaches - can interwork each other. - - For ordering between RA and DHCP approaches, the O (Other stateful - configuration) flag in RA message can be used [8][32]. If no RDNSS - option is included, an IPv6 host may perform DNS configuration - through DHCPv6 [5]-[7] regardless of whether the O flag is set or - not. - - The well-known anycast addresses approach fully interworks with the - other approaches. That is, the other approaches can remove the - configuration effort on servers by using the well-known addresses as - the default configuration. Moreover, the clients preconfigured with - the well-known anycast addresses can be further configured to use - other approaches to override the well-known addresses, if the - configuration information from other approaches is available. - Otherwise, all the clients need to have the well-known anycast - addresses preconfigured. In order to use the anycast approach along - with two other approaches, there are three choices as follows: - - 1. The first choice is that well-known addresses are used as last - resort, when an IPv6 host cannot get RDNSS information through RA - and DHCP. The well-known anycast addresses have to be - preconfigured in all of IPv6 hosts' resolver configuration files. - - 2. The second is that an IPv6 host can configure well-known - addresses as the most preferable in its configuration file even - though either an RA option or DHCP option is available. - - 3. The last is that the well-known anycast addresses can be set in - RA or DHCP configuration to reduce the configuration effort of - users. According to either the RA or DHCP mechanism, the well- - known addresses can be obtained by an IPv6 host. Because this - approach is the most convenient for users, the last option is - recommended. - - -Note - - This section does not necessarily mean this document suggests - adopting all these three approaches and making them interwork in the - way described here. In fact, some approaches may even not be adopted - at all as a result of further discussion. - - - - - -Jeong Expires November 6, 2005 [Page 15] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -5. Deployment Scenarios - - Regarding the DNS configuration on the IPv6 host, several mechanisms - are being considered at the DNSOP Working Group such as RA option, - DHCPv6 option and well-known preconfigured anycast addresses as of - today, and this document is a final result from the long thread. In - this section, we suggest four applicable scenarios of three - approaches for IPv6 DNS configuration. - -Note - - In the applicable scenarios, authors do not implicitly push any - specific approaches into the restricted environments. No enforcement - is in each scenario and all mentioned scenarios are probable. The - main objective of this work is to provide a useful guideline for IPv6 - DNS configuration. - -5.1 ISP Network - - A characteristic of ISP network is that multiple Customer Premises - Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) - routers and each PE connects multiple CPE devices to the backbone - network infrastructure [13]. The CPEs may be hosts or routers. - - In the case where the CPE is a router, there is a customer network - that is connected to the ISP backbone through the CPE. Typically, - each customer network gets a different IPv6 prefix from an IPv6 PE - router, but the same RDNSS configuration will be distributed. - - This section discusses how the different approaches to distributing - DNS information are compared in an ISP network. - -5.1.1 RA Option Approach - - When the CPE is a host, the RA option for RDNSS can be used to allow - the CPE to get RDNSS information as well as /64 prefix information - for stateless address autoconfiguration at the same time when the - host is attached to a new subnet [8]. Because an IPv6 host must - receive at least one RA message for stateless address - autoconfiguration and router configuration, the host could receive - RDNSS configuration information in that RA without the overhead of an - additional message exchange. - - When the CPE is a router, the CPE may accept the RDNSS information - from the RA on the interface connected to the ISP, and copy that - information into the RAs advertised in the customer network. - - This approach is more valuable in the mobile host scenario, in which - - - -Jeong Expires November 6, 2005 [Page 16] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - the host must receive at least an RA message for detecting a new - network, than in other scenarios generally although administrator - should configure RDNSS information on the routers. Secure ND [14] - can provide extended security when using RA messages. - -5.1.2 DHCPv6 Option Approach - - DHCPv6 can be used for RDNSS configuration through the use of the DNS - option, and can provide other configuration information in the same - message with RDNSS configuration [5]-[7]. The DHCPv6 DNS option is - already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or - stateless DHCP [6] is nowhere as complex as a full DHCPv6 - implementation. DHCP is a client-server model protocol, so ISPs can - handle user identification on its network intentionally, and also - authenticated DHCP [15] can be used for secure message exchange. - - The expected model for deployment of IPv6 service by ISPs is to - assign a prefix to each customer, which will be used by the customer - gateway to assign a /64 prefix to each network in the customer's - network. Prefix delegation with DHCP (DHCPv6 PD) has already been - adopted by ISPs for automating the assignment of the customer prefix - to the customer gateway [17]. DNS configuration can be carried in - the same DHCPv6 message exchange used for DHCPv6 to efficiently - provide that information, along with any other configuration - information needed by the customer gateway or customer network. This - service model can be useful to Home or SOHO subscribers. The Home or - SOHO gateway, which is a customer gateway for ISP, can then pass that - RDNSS configuration information to the hosts in the customer network - through DHCP. - -5.1.3 Well-known Anycast Addresses Approach - - The well-known anycast addresses approach is also a feasible and - simple mechanism for ISP [9]. The use of well-known anycast - addresses avoids some of the security risks in rogue messages sent - through an external protocol like RA or DHCPv6. The configuration of - hosts for the use of well-known anycast addresses requires no - protocol or manual configuration, but the configuration of routing - for the anycast addresses requires intervention on the part of the - network administrator. Also, the number of special addresses would - be equal to the number of RDNSSes that could be made available to - subscribers. - -5.2 Enterprise Network - - Enterprise network is defined as a network that has multiple internal - links, one or more router connections, to one or more Providers and - is actively managed by a network operations entity [16]. An - - - -Jeong Expires November 6, 2005 [Page 17] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - enterprise network can get network prefixes from an ISP by either - manual configuration or prefix delegation [17]. In most cases, - because an enterprise network manages its own DNS domains, it - operates its own DNS servers for the domains. These DNS servers - within enterprise network process recursive DNS name resolution - requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the - enterprise network can be performed like in Section 4, in which three - approaches can be used together as follows: - - 1. An IPv6 host can decide which approach is or may be used in its - subnet with the O flag in RA message [8][32]. As the first - choice in Section 4, well-known anycast addresses can be used as - a last resort when RDNSS information cannot be obtained through - either an RA option or DHCP option. This case needs IPv6 hosts - to preconfigure the well-known anycast addresses in their DNS - configuration files. - - 2. When the enterprise prefers the well-known anycast approach to - others, IPv6 hosts should preconfigure the well-known anycast - addresses like in the first choice. - - 3. The last choice, a more convenient and transparent way, does not - need IPv6 hosts to preconfigure the well-known anycast addresses - because the addresses are delivered to IPv6 hosts via either the - RA option or DHCPv6 option as if they were unicast addresses. - This way is most recommended for the sake of user's convenience. - - -5.3 3GPP Network - - The IPv6 DNS configuration is a missing part of IPv6 - autoconfiguration and an important part of the basic IPv6 - functionality in the 3GPP User Equipment (UE). The higher level - description of the 3GPP architecture can be found in [18], and - transition to IPv6 in 3GPP networks is analyzed in [19] and [20]. - - In the 3GPP architecture, there is a dedicated link between the UE - and the GGSN called the Packet Data Protocol (PDP) Context. This - link is created through the PDP Context activation procedure [21]. - There is a separate PDP context type for IPv4 and IPv6 traffic. If a - 3GPP UE user is communicating using IPv6 (having an active IPv6 PDP - context), it cannot be assumed that (s)he has simultaneously an - active IPv4 PDP context, and DNS queries could be done using IPv4. A - 3GPP UE can thus be an IPv6 node, and it needs to somehow discover - the address of the RDNSS. Before IP-based services (e.g., web - browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses - need to be discovered in the 3GPP UE. - - - - -Jeong Expires November 6, 2005 [Page 18] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - Section 5.3.1 briefly summarizes currently available mechanisms in - 3GPP networks and recommendations. 5.3.2 analyzes the Router - Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 - mechanism, and 5.3.4 analyzes the Well-known addresses approach. - Section 5.3.5 finally summarizes the recommendations. - -5.3.1 Currently Available Mechanisms and Recommendations - - 3GPP has defined a mechanism, in which RDNSS addresses can be - received in the PDP context activation (a control plane mechanism). - That is called the Protocol Configuration Options Information Element - (PCO-IE) mechanism [22]. The RDNSS addresses can also be received - over the air (using text messages), or typed in manually in the UE. - Note that the two last mechanisms are not very well scalable. The UE - user most probably does not want to type IPv6 RDNSS addresses - manually in his/her UE. The use of well-known addresses is briefly - discussed in section 5.3.4. - - It is seen that the mechanisms above most probably are not sufficient - for the 3GPP environment. IPv6 is intended to operate in a zero- - configuration manner, no matter what the underlying network - infrastructure is. Typically, the RDNSS address is needed to make an - IPv6 node operational - and the DNS configuration should be as simple - as the address autoconfiguration mechanism. It must also be noted - that there will be additional IP interfaces in some near future 3GPP - UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such - as PCO-IE [22]) do not work for those IP interfaces. In other words, - a good IPv6 DNS configuration mechanism should also work in a multi- - access network environment. - - From a 3GPP point of view, the best IPv6 DNS configuration solution - is feasible for a very large number of IPv6-capable UEs (can be even - hundreds of millions in one operator's network), is automatic and - thus requires no user action. It is suggested to standardize a - lightweight, stateless mechanism that works in all network - environments. The solution could then be used for 3GPP, 3GPP2, WLAN - and other access network technologies. A light, stateless IPv6 DNS - configuration mechanism is thus not only needed in 3GPP networks, but - also 3GPP networks and UEs would certainly benefit from the new - mechanism. - -5.3.2 RA Extension - - Router Advertisement extension [8] is a lightweight IPv6 DNS - configuration mechanism that requires minor changes in the 3GPP UE - IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in - the 3GPP architecture) IPv6 stack. This solution can be specified in - the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs - - - -Jeong Expires November 6, 2005 [Page 19] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - and GGSNs - - In this solution, an IPv6-capable UE configures DNS information via - RA message sent by its default router (GGSN), i.e., RDNSS option for - recursive DNS server is included in the RA message. This solution is - easily scalable for a very large number of UEs. The operator can - configure the RDNSS addresses in the GGSN as a part of normal GGSN - configuration. The IPv6 RDNSS address is received in the Router - Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS - addresses can be avoided. - - If thinking about the cons, this mechanism still requires - standardization effort in the IETF, and the end nodes and routers - need to support this mechanism. The equipment software update - should, however, be pretty straightforward, and new IPv6 equipment - could support RA extension already from the beginning. - -5.3.3 Stateless DHCPv6 - - DHCPv6-based solution needs the implementation of Stateless DHCP [6] - and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the - operator's network. A possible configuration is such that the GGSN - works as a DHCP relay. - - Pros for Stateless DHCPv6-based solution are - - 1. Stateless DHCPv6 is a standardized mechanism. - - 2. DHCPv6 can be used for receiving other configuration information - than RDNSS addresses, e.g., SIP server addresses. - - 3. DHCPv6 works in different network environments. - - 4. When DHCPv6 service is deployed through a single, centralized - server, the RDNSS configuration information can be updated by the - network administrator at a single source. - - Some issues with DHCPv6 in 3GPP networks are listed below: - - 1. DHCPv6 requires an additional server in the network unless the - (Stateless) DHCPv6 functionality is integrated into a router - already existing, and that means one box more to be maintained. - - 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing - (3GPP Stateless Address Autoconfiguration is typically used), and - not automatically implemented in 3GPP IPv6 UEs. - - - - - -Jeong Expires November 6, 2005 [Page 20] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - 3. Scalability and reliability of DHCPv6 in very large 3GPP networks - (with tens or hundreds of millions of UEs) may be an issue, at - least the redundancy needs to be taken care of. However, if the - DHCPv6 service is integrated into the network elements, such as a - router operating system, scalability and reliability is - comparable with other DNS configuration approaches. - - 4. It is sub-optimal to utilize the radio resources in 3GPP networks - for DHCPv6 messages if there is a simpler alternative available. - - * The use of Stateless DHCPv6 adds one round trip delay to the - case in which the UE can start transmitting data right after - the Router Advertisement. - - 5. If the DNS information (suddenly) changes, Stateless DHCPv6 can - not automatically update the UE, see [23]. - - -5.3.4 Well-known Addresses - - Using well-known addresses is also a feasible and a light mechanism - for 3GPP UEs. Those well-known addresses can be preconfigured in the - UE software and the operator makes the corresponding configuration on - the network side. So this is a very easy mechanism for the UE, but - requires some configuration work in the network. When using well- - known addresses, UE forwards queries to any of the preconfigured - addresses. In the current proposal [9], IPv6 anycast addresses are - suggested. - -Note - - The IPv6 DNS configuration proposal based on the use of well-known - site-local addresses developed at the IPv6 Working Group was seen as - a feasible mechanism for 3GPP UEs, but opposition by some people in - the IETF and finally deprecating IPv6 site-local addresses made it - impossible to standardize it. Note that this mechanism is - implemented in some existing operating systems today (also in some - 3GPP UEs) as a last resort of IPv6 DNS configuration. - -5.3.5 Recommendations - - It is suggested that a lightweight, stateless DNS configuration - mechanism is specified as soon as possible. From a 3GPP UE and - network point of view, the Router Advertisement based mechanism looks - most promising. The sooner a light, stateless mechanism is - specified, the sooner we can get rid of using well-known site-local - addresses for IPv6 DNS configuration. - - - - -Jeong Expires November 6, 2005 [Page 21] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -5.4 Unmanaged Network - - There are 4 deployment scenarios of interest in unmanaged networks - [24]: - - 1. A gateway which does not provide IPv6 at all; - - 2. A dual-stack gateway connected to a dual-stack ISP; - - 3. A dual-stack gateway connected to an IPv4-only ISP; and - - 4. A gateway connected to an IPv6-only ISP. - - -5.4.1 Case A: Gateway does not provide IPv6 at all - - In this case, the gateway does not provide IPv6; the ISP may or may - not provide IPv6. Automatic or Configured tunnels are the - recommended transition mechanisms for this scenario. - - The case where dual-stack hosts behind an NAT, that need access to an - IPv6 RDNSS, cannot be entirely ruled out. The DNS configuration - mechanism has to work over the tunnel, and the underlying tunneling - mechanism could be implementing NAT traversal. The tunnel server - assumes the role of a relay (both for DHCP and Well-known anycast - addresses approaches). - - RA-based mechanism is relatively straightforward in its operation, - assuming the tunnel server is also the IPv6 router emitting RAs. - Well-known anycast addresses approach seems also simple in operation - across the tunnel, but the deployment model using Well-known anycast - addresses in a tunneled environment is unclear or not well - understood. - -5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP - - This is similar to a typical IPv4 home user scenario, where DNS - configuration parameters are obtained using DHCP. Except that - Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the - DHCP server is stateful (maintains the state for clients). - -5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP - - This is similar to Case B. If a gateway provides IPv6 connectivity by - managing tunnels, then it is also supposed to provide access to an - RDNSS. Like this, the tunnel for IPv6 connectivity originates from - the dual-stack gateway instead of the host. - - - - -Jeong Expires November 6, 2005 [Page 22] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -5.4.4 Case D: A gateway connected to an IPv6-only ISP - - This is similar to Case B. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 23] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -6. Security Considerations - - As security requirements depend solely on applications and are - different application by application, there can be no generic - requirement defined at IP or application layer for DNS. - - However, it should be noted that cryptographic security requires - configured secret information that full autoconfiguration and - cryptographic security are mutually exclusive. People insisting on - secure full autoconfiguration will get false security, false - autoconfiguration or both. - - In some deployment scenarios [19], where cryptographic security is - required for applications, the secret information for the - cryptographic security is preconfigured through which application - specific configuration data, including those for DNS, can be securely - configured. It should be noted that if applications requiring - cryptographic security depend on DNS, the applications also require - cryptographic security to DNS. Therefore, the full autoconfiguration - of DNS is not acceptable. - - However, with full autoconfiguration, weaker but still reasonable - security is being widely accepted and will continue to be acceptable. - That is, with full autoconfiguration, which means there is no - cryptographic security for the autoconfiguration, it is already - assumed that the local environment is secure enough that the - information from the local autoconfiguration server has acceptable - security even without cryptographic security. Thus, the - communication between the local DNS client and local DNS server has - acceptable security. - - In autoconfiguring recursive servers, DNSSEC may be overkill, because - DNSSEC [29] needs the configuration and reconfiguration of clients at - root key roll-over [30][31]. Even if additional keys for secure key - roll-over are added at the initial configuration, they are as - vulnerable as the original keys to some forms of attacks, such as - social hacking. Another problem of using DNSSEC and - autoconfiguration together is that DNSSEC requires secure time, which - means secure communication with autoconfigured time servers, which - requires configured secret information. Therefore, in order that the - autoconfiguration may be secure, it requires configured secret - information. - - If DNSSEC [29] is used and the signatures are verified on the client - host, the misconfiguration of a DNS server may be simply denial of - service. Also, if local routing environment is not reliable, clients - may be directed to a false resolver with the same IP address as the - true one. - - - -Jeong Expires November 6, 2005 [Page 24] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -6.1 RA Option - - The security of RA option for RDNSS is the same as the ND protocol - security [3][8]. The RA option does not add any new vulnerability. - - It should be noted that the vulnerability of ND is not worse and is a - subset of the attacks that any node attached to a LAN can do - independently of ND. A malicious node on a LAN can promiscuously - receive packets for any router's MAC address and send packets with - the router's MAC address as the source MAC address in the L2 header. - As a result, the L2 switches send packets addressed to the router to - the malicious node. Also, this attack can send redirects that tell - the hosts to send their traffic somewhere else. The malicious node - can send unsolicited RA or NA replies, answer RS or NS requests, etc. - All of this can be done independently of implementing ND. Therefore, - the RA option for RDNSS does not add to the vulnerability. - - Security issues regarding the ND protocol were discussed at IETF SEND - (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND - security has been published [14]. - -6.2 DHCPv6 Option - - The DNS Recursive Name Server option may be used by an intruder DHCP - server to cause DHCP clients to send DNS queries to an intruder DNS - recursive name server [7]. The results of these misdirected DNS - queries may be used to spoof DNS names. - - To avoid attacks through the DNS Recursive Name Server option, the - DHCP client SHOULD require DHCP authentication (see section - "Authentication of DHCP messages" in RFC 3315 [5]) before installing - a list of DNS recursive name servers obtained through authenticated - DHCP. - -6.3 Well-known Anycast Addresses - - Well-known anycast addresses does not require configuration security - since there is no protocol [9]. - - The DNS server with the preconfigured addresses are still reasonably - reliable, if local environment is reasonably secure, that is, there - is no active attackers receiving queries to the anycast addresses of - the servers and reply to them. - - - - - - - - -Jeong Expires November 6, 2005 [Page 25] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -7. Contributors - - Ralph Droms - Cisco Systems, Inc. - 1414 Massachusetts Ave. - Boxboro, MA 01719 - US - - Phone: +1 978 936 1674 - Email: rdroms@cisco.com - - - Robert M. Hinden - Nokia - 313 Fairchild Drive - Mountain View, CA 94043 - US - - Phone: +1 650 625 2004 - Email: bob.hinden@nokia.com - - - Ted Lemon - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94043 - US - - Email: Ted.Lemon@nominum.com - - - Masataka Ohta - Tokyo Institute of Technology - 2-12-1, O-okayama, Meguro-ku - Tokyo 152-8552 - Japan - - Phone: +81 3 5734 3299 - Fax: +81 3 5734 3299 - Email: mohta@necom830.hpcl.titech.ac.jp - - - Soohong Daniel Park - Mobile Platform Laboratory, SAMSUNG Electronics - 416 Maetan-3dong, Yeongtong-Gu - Suwon, Gyeonggi-Do 443-742 - Korea - - - - -Jeong Expires November 6, 2005 [Page 26] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - Phone: +82 31 200 4508 - Email: soohong.park@samsung.com - - - Suresh Satapati - Cisco Systems, Inc. - San Jose, CA 95134 - US - - Email: satapati@cisco.com - - - Juha Wiljakka - Nokia - Visiokatu 3 - FIN-33720, TAMPERE - Finland - - Phone: +358 7180 48372 - Email: juha.wiljakka@nokia.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 27] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -8. Acknowledgements - - This draft has greatly benefited from inputs by David Meyer, Rob - Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, - Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. - Also, Tony Bonanno proofread this draft. The authors appreciate - their contribution. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 28] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -9. References - -9.1 Normative References - - [1] Bradner, S., "IETF Rights in Contributions", RFC 3667, - February 2004. - - [2] Bradner, S., "Intellectual Property Rights in IETF Technology", - RFC 3668, February 2004. - - [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery - for IP Version 6 (IPv6)", RFC 2461, December 1998. - - [4] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [5] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - [6] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) - Service for IPv6", RFC 3736, April 2004. - - [7] Droms, R., Ed., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, - December 2003. - -9.2 Informative References - - [8] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS - Discovery based on Router Advertisement", - draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress), - February 2005. - - [9] Ohta, M., "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-01.txt (Work in Progress), - February 2004. - - [10] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time - Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in - Progress), January 2005. - - [11] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - [12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) - Addressing Architecture", RFC 3513, April 2003. - - [13] Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6 - - - -Jeong Expires November 6, 2005 [Page 29] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - into ISP Networks", RFC 4029, March 2005. - - [14] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, - March 2005. - - [15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", - RFC 3118, June 2001. - - [16] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", - draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress), - July 2004. - - [17] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host - Configuration Protocol (DHCP) version 6", RFC 3633, - December 2003. - - [18] Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP - Standards", RFC 3314, September 2002. - - [19] Soininen, J., Ed., "Transition Scenarios for 3GPP Networks", - RFC 3574, August 2003. - - [20] Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in - Progress), October 2004. - - [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); - Service description; Stage 2 (Release 5)", December 2002. - - [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 - specification; Core network protocols; Stage 3 (Release 5)", - June 2003. - - [23] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering - Requirements for Stateless DHCPv6", - draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in - Progress), October 2004. - - [24] Huitema, C., Ed., "Unmanaged Networks IPv6 Transition - Scenarios", RFC 3750, April 2004. - - [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access - Control (MAC) and Physical Layer (PHY) Specifications", - March 1999. - - [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control - (MAC) and Physical Layer (PHY) specifications: High-speed - Physical Layer in the 5 GHZ Band", September 1999. - - - -Jeong Expires November 6, 2005 [Page 30] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control - (MAC) and Physical Layer (PHY) specifications: Higher-Speed - Physical Layer Extension in the 2.4 GHz Band", September 1999. - - [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access - Control (MAC) and Physical Layer (PHY) specifications: Further - Higher Data Rate Extension in the 2.4 GHz Band", April 2003. - - [29] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [30] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in - Progress), December 2004. - - [31] Guette, G. and O. Courtay, "Requirements for Automated Key - Rollover in DNSSEC", - draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in - Progress), January 2005. - - [32] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M - and O Flags of IPv6 Router Advertisement", - draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress), - March 2005. - - -Author's Address - - Jaehoon Paul Jeong (editor) - ETRI/Department of Computer Science and Engineering - University of Minnesota - 117 Pleasant Street SE - Minneapolis, MN 55455 - US - - Phone: +1 651 587 7774 - Fax: +1 612 625 2002 - Email: jjeong@cs.umn.edu - URI: http://www.cs.umn.edu/~jjeong/ - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 31] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -Appendix A. Link-layer Multicast Acknowledgements for RA Option - - One benefit of an RA option [8] is to be able to multicast the - advertisements, reducing the need for duplicated unicast - communications. - - However, some link-layers may not support this as well as others. - Consider, for example, WLAN networks where multicast is unreliable. - The unreliability problem is caused by lack of ACK for multicast, - especially on the path from the Access Point (AP) to the Station - (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11 - a/b/g [25]-[28]. That is, a multicast packet is unacknowledged on - the path from the AP to the STA, but acknowledged in the reverse - direction from the STA to the AP [25]. For example, when a router is - placed at wired network connected to an AP, a host may sometimes not - receive RA message advertised through the AP. Therefore, the RA - option solution might not work well on a congested medium that uses - unreliable multicast for RA. - - The fact that this problem has not been addressed in Neighbor - Discovery [3] indicates that the extra link-layer acknowledgements - have not been considered a serious problem till now. - - A possible mitigation technique could be to map all-nodes link- local - multicast address to the link-layer broadcast address, and to rely on - the ND retransmissions for message delivery in order to achieve more - reliability. - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 32] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Jeong Expires November 6, 2005 [Page 33] - diff --git a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt deleted file mode 100644 index b2e2341be9..0000000000 --- a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt +++ /dev/null @@ -1,300 +0,0 @@ -Internet Engineering Task Force A.Durand -INTERNET-DRAFT SUN Microsystems,inc. -November, 24, 2003 J. Ihren -Expires May 25, 2004 Autonomica - - - DNS IPv6 transport operational guidelines - - - - -Status of this Memo - - This memo provides information to the Internet community. It does not - specify an Internet standard of any kind. This memo is in full - conformance with all provisions of Section 10 of RFC2026 - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet- Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - -Abstract - - This memo provides guidelines and Best Current Practice to operate - DNS in a world where queries and responses are carried in a mixed - environment of IPv4 and IPv6 networks. - - -Acknowledgment - - This document is the result of many conversations that happened in - the DNS community at IETF and elsewhere since 2001. During that - period of time, a number of Internet drafts have been published to - clarify various aspects of the issues at stake. This document focuses - on the conclusion of those discussions. - - The authors would like to acknowledge the role of Pekka Savola in his - thorough review of the document. - - -1. Terminology - - The phrase "IPv4 name server" indicates a name server available over - IPv4 transport. It does not imply anything about what DNS data is - served. Likewise, "IPv6 name server" indicates a name server - available over IPv6 transport. The phrase "dual-stack DNS server" - indicates a DNS server that is actually configured to run both - protocols, IPv4 and IPv6, and not merely a server running on a system - capable of running both but actually configured to run only one. - - 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 [2119]. - - -2. Introduction to the Problem of Name Space Fragmentation: - following the referral chain - - The caching resolver that tries to look up a name starts out at the - root, and follows referrals until it is referred to a nameserver that - is authoritative for the name. If somewhere down the chain of - referrals it is referred to a nameserver that is only accessible over - an unavailable type of transport, a traditional nameserver is unable - to finish the task. - - When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is - only a matter of time until this starts to happen. The complete DNS - hierarchy then starts to fragment into a graph where authoritative - nameservers for certain nodes are only accessible over a certain - transport. What is feared is that a node using only a particular - version of IP, querying information about another node using the same - version of IP can not do it because, somewhere in the chain of - servers accessed during the resolution process, one or more of them - will only be accessible with the other version of IP. - - With all DNS data only available over IPv4 transport everything is - simple. IPv4 resolvers can use the intended mechanism of following - referrals from the root and down while IPv6 resolvers have to work - through a "translator", i.e. they have to use a second name server on - a so-called "dual stack" host as a "forwarder" since they cannot - access the DNS data directly. - - With all DNS data only available over IPv6 transport everything would - be equally simple, with the exception of old legacy IPv4 name servers - having to switch to a forwarding configuration. - - However, the second situation will not arise in a foreseeable time. - Instead, it is expected that the transition will be from IPv4 only to - a mixture of IPv4 and IPv6, with DNS data of theoretically three - categories depending on whether it is available only over IPv4 - transport, only over IPv6 or both. - - Having DNS data available on both transports is the best situation. - The major question is how to ensure that it as quickly as possible - becomes the norm. However, while it is obvious that some DNS data - will only be available over v4 transport for a long time it is also - obvious that it is important to avoid fragmenting the name space - available to IPv4 only hosts. I.e. during transition it is not - acceptable to break the name space that we presently have available - for IPv4-only hosts. - - -3. Policy Based Avoidance of Name Space Fragmentation - - Today there are only a few DNS "zones" on the public Internet that - are available over IPv6 transport, and most of them can be regarded - as "experimental". However, as soon as the root and top level domains - are available over IPv6 transport, it is reasonable to expect that it - will become more common to have zones served by IPv6 servers. - - Having those zones served only by IPv6-only name server would not be - a good development, since this will fragment the previously - unfragmented IPv4 name space and there are strong reasons to find a - mechanism to avoid it. - - The RECOMMENDED approach to maintain name space continuity is to use - administrative policies, as described in the next section. - - -4. DNS IPv6 Transport RECOMMENDED Guidelines - - In order to preserve name space continuity, the following administrative - policies are RECOMMENDED: - - every recursive DNS server SHOULD be either IPv4-only or dual - stack, - - every single DNS zone SHOULD be served by at least one IPv4 - reachable DNS server. - - This rules out IPv6-only DNS servers performing full recursion and - DNS zones served only by IPv6-only DNS servers. However, one could - very well design a configuration where a chain of IPv6 only DNS - servers forward queries to a set of dual stack DNS servers actually - performing those recursive queries. This approach could be revisited - if/when translation techniques between IPv4 and IPv6 were to be - widely deployed. - - In order to help enforcing the second point, the optional operational - zone validation processes SHOULD ensure that there is at least one - IPv4 address record available for the name servers of any child - delegations within the zone. - - -5. Security Considerations - - Being a critical piece of the Internet infrastructure, the DNS is a - potential value target and thus should be protected. Great care - should be taken not to weaken the security of DNS while introducing - IPv6 operation. - - Keeping the DNS name space from fragmenting is a critical thing for - the availability and the operation of the Internet; this memo - addresses this issue by clear and simple operational guidelines. - - The RECOMMENDED guidelines are compatible with the operation of - DNSSEC and do not introduce any new security issues. - - -6. Author Addresses - - Alain Durand - SUN Microsystems, Inc - 17 Network circle UMPK17-202 - Menlo Park, CA, 94025 - USA - Mail: Alain.Durand@sun.com - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm, Sweden - Mail: johani@autonomica.se - - -7. Normative References - - [2119] Bradner, S., "Key Words for Use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - -8. Full Copyright Statement - - "Copyright (C) The Internet Society (2003). 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt deleted file mode 100644 index 6bece56182..0000000000 --- a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt +++ /dev/null @@ -1,389 +0,0 @@ - -DNSOP G. Guette -Internet-Draft IRISA / INRIA -Expires: July 19, 2005 O. Courtay - Thomson R&D - January 18, 2005 - - Requirements for Automated Key Rollover in DNSSEC - draft-ietf-dnsop-key-rollover-requirements-02.txt - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - 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 July 19, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). All Rights Reserved. - -Abstract - - This document describes problems that appear during an automated - rollover and gives the requirements for the design of communication - between parent zone and child zone during an automated rollover - process. This document is essentially about in-band key rollover. - - - - -Guette & Courtay Expires July 19, 2005 [Page 1] -Internet-Draft Automated Rollover Requirements January 2005 - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 - 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Messages authentication and information exchanged . . . . . . 5 - 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Security consideration . . . . . . . . . . . . . . . . . . . . 6 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 - A. Documents details and changes . . . . . . . . . . . . . . . . 7 - Intellectual Property and Copyright Statements . . . . . . . . 8 - - - - - - - - - - - - - - - - - - - -Guette & Courtay Expires July 19, 2005 [Page 2] -Internet-Draft Automated Rollover Requirements January 2005 - -1. Introduction - - The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key - cryptography and digital signatures. It stores the public part of - keys in DNSKEY Resource Records (RRs). Because old keys and - frequently used keys are vulnerable, they must be renewed - periodically. In DNSSEC, this is the case for Zone Signing Keys - (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key - exchanges between parents and children is necessary for large zones - because there are too many changes to handle. - - Let us consider for example a zone with 100000 secure delegations. - If the child zones change their keys once a year on average, that - implies 300 changes per day for the parent zone. This amount of - changes is hard to manage manually. - - Automated rollover is optional and resulting from an agreement - between the administrator of the parent zone and the administrator of - the child zone. Of course, key rollover can also be done manually by - administrators. - - This document describes the requirements for a protocol to perform - the automated key rollover process and focusses on interaction - between parent and child zone. - -2. The Key Rollover Process - - Key rollover consists of renewing the DNSSEC keys used to sign - resource records in a given DNS zone file. There are two types of - rollover, ZSK rollovers and KSK rollovers. - - During a ZSK rollover, all changes are local to the zone that renews - its key: there is no need to contact other zones administrators to - propagate the performed changes because a ZSK has no associated DS - record in the parent zone. - - During a KSK rollover, new DS RR(s) must be created and stored in the - parent zone. In consequence, data must be exchanged between child - and parent zones. - - The key rollover is built from two parts of different nature: - o An algorithm that generates new keys and signs the zone file. It - can be local to the zone, - o the interaction between parent and child zones. - - One example of manual key rollover [3] is: - o The child zone creates a new KSK, - - -Guette & Courtay Expires July 19, 2005 [Page 3] -Internet-Draft Automated Rollover Requirements January 2005 - - o the child zone waits for the creation of the DS RR in its parent - zone, - o the child zone deletes the old key, - o the parent zone deletes the old DS RR. - - This document concentrates on defining interactions between entities - present in key rollover process. - -3. Basic Requirements - - This section provides the requirements for automated key rollover in - case of normal use. Exceptional case like emergency rollover is - specifically described later in this document. - - The main condition during a key rollover is that the chain of trust - must be preserved to every validating DNS client. No matter if this - client retrieves some of the RRs from recursive caching name server - or from the authoritative servers for the zone involved in the - rollover. - - Automated key rollover solution may be interrupted by a manual - intervention. This manual intervention should not compromise the - security state of the chain of trust. If the chain is safe before - the manual intervention, the chain of trust must remain safe during - and after the manual intervention - - Two entities act during a KSK rollover: the child zone and its parent - zone. These zones are generally managed by different administrators. - These administrators should agree on some parameters like - availability of automated rollover, the maximum delay between - notification of changes in the child zone and the resigning of the - parent zone. The child zone needs to know this delay to schedule its - changes and/or to verify that the changes had been taken into account - in the parent zone. Hence, the child zone can also avoid some - critical cases where all child key are changed prior to the DS RR - creation. - - By keeping some resource records during a given time, the recursive - cache servers can act on the automated rollover. The existence of - recursive cache servers must be taken into account by automated - rollover solution. - - Indeed, during an automated key rollover a name server could have to - retrieve some DNSSEC data. An automated key rollover solution must - ensure that these data are not old DNSSEC material retrieved from a - recursive name server. - - - -Guette & Courtay Expires July 19, 2005 [Page 4] -Internet-Draft Automated Rollover Requirements January 2005 - -4. Messages authentication and information exchanged - - This section addresses in-band rollover, security of out-of-band - mechanisms is out of scope of this document. - - The security provided by DNSSEC must not be compromised by the key - rollover, thus every exchanged message must be authenticated to avoid - fake rollover messages from malicious parties. - - Once the changes related to a KSK are made in a child zone, there are - two ways for the parent zone to take this changes into account: - o the child zone notify directly or not directly its parent zone in - order to create the new DS RR and store this DS RR in parent zone - file, - o or the parent zone poll the child zone. - - In both cases, the parent zone must receive all the child keys that - need the creation of associated DS RRs in the parent zone. - - Because errors could occur during the transmission of keys between - child and parent, the key exchange protocol must be fault tolerant. - Should an error occured during the automated key rollover, an - automated key rollover solution must be able to keep the zone files - in a consistent state. - -5. Emergency Rollover - - Emergency key rollover is a special case of rollover decided by the - zone administrator generally for security reasons. In consequence, - emergency key rollover can break some of the requirement described - above. - - A zone key might be compromised and an attacker can use the - compromised key to create and sign fake records. To avoid this, the - zone administrator may change the compromised key or all its keys as - soon as possible, without waiting for the creation of new DS RRs in - its parent zone. - - Fast changes may break the chain of trust. The part of DNS tree - having this zone as apex can become unverifiable, but the break of - the chain of trust is necessary if the administrator wants to prevent - the compromised key from being used (to spoof DNS data). - - Parent and child zones sharing an automated rollover mechanism, - should have an out-of-band way to re-establish a consistent state at - the delegation point (DS and DNSKEY RRs). This allows to avoid that - a malicious party uses the compromised key to roll the zone keys. - - -Guette & Courtay Expires July 19, 2005 [Page 5] -Internet-Draft Automated Rollover Requirements January 2005 - -6. Security consideration - - The automated key rollover process in DNSSEC allows automated renewal - of any kind of DNS key (ZSK or KSK). It is essential that parent - side and child side can do mutual authentication. Moreover, - integrity of the material exchanged between the parent and child zone - must be provided to ensure the right DS are created. - - As in any application using public key cryptography, in DNSSEC a key - may be compromised. What to do in such a case can be describe in the - zone local policy and can violate some requirements described in this - draft. The emergency rollover can break the chain of trust in order - to protect the zone against the use of the compromised key. - -7. Acknowledgments - - The authors want to thank members of IDsA project for their - contribution to this document. - -8 Normative References - - [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", - RFC 3658, December 2003. - - [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY - (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", - RFC 3757, May 2004. - - [3] Kolkman, O., "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practice-01 (work in - progress), May 2004. - - [4] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-11 (work in progress), October - 2004. - - [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-13 (work in progress), October - 2004. - - [7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October - - -Guette & Courtay Expires July 19, 2005 [Page 6] -Internet-Draft Automated Rollover Requirements January 2005 - - 2004. - -Authors' Addresses - - Gilles Guette - IRISA / INRIA - Campus de Beaulieu - 35042 Rennes CEDEX - FR - - EMail: gilles.guette@irisa.fr - URI: http://www.irisa.fr - - Olivier Courtay - Thomson R&D - 1, avenue Belle Fontaine - 35510 Cesson S?vign? CEDEX - FR - - EMail: olivier.courtay@thomson.net - -Appendix A. Documents details and changes - - This section is to be removed by the RFC editor if and when the - document is published. - - Section about NS RR rollover has been removed - - Remarks from Samuel Weiler and Rip Loomis added - - Clarification about in-band rollover and in emergency section - - Section 3, details about recursive cache servers added - - - - - - - - -Guette & Courtay Expires July 19, 2005 [Page 7] -Internet-Draft Automated Rollover Requirements January 2005 - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described - in this document or the extent to which any license under such - rights might or might not be available; neither does it represent - that it has made any effort to identify any such rights. - Information on the IETF's procedures with respect to rights in - IETF Documents can be found in BCP 78 and 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use - of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository - at http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention - any copyrights, patents or patent applications, or other - proprietary rights which may cover technology that may be required - to implement this standard. Please address the information to the - IETF at ietf-ipr.org. - - - Full Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - -Guette & Courtay Expires July 19, 2005 [Page 8] diff --git a/doc/draft/draft-ietf-dnsop-serverid-06.txt b/doc/draft/draft-ietf-dnsop-serverid-06.txt deleted file mode 100644 index c6ec7e42a5..0000000000 --- a/doc/draft/draft-ietf-dnsop-serverid-06.txt +++ /dev/null @@ -1,618 +0,0 @@ - - - - -Network Working Group S. Woolf -Internet-Draft Internet Systems Consortium, Inc. -Expires: September 6, 2006 D. Conrad - Nominum, Inc. - March 5, 2006 - - - Requirements for a Mechanism Identifying a Name Server Instance - draft-ietf-dnsop-serverid-06 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 6, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - query would be useful, particularly as a diagnostic aid for - administrators. Existing ad hoc mechanisms for addressing this need - - - -Woolf & Conrad Expires September 6, 2006 [Page 1] - -Internet-Draft Serverid March 2006 - - - have some shortcomings, not the least of which is the lack of prior - analysis of exactly how such a mechanism should be designed and - deployed. This document describes the existing convention used in - some widely deployed implementations of the DNS protocol, including - advantages and disadvantages, and discusses some attributes of an - improved mechanism. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 2] - -Internet-Draft Serverid March 2006 - - -1. Introduction and Rationale - - Identifying which name server is responding to queries is often - useful, particularly in attempting to diagnose name server - difficulties. This is most obviously useful for authoritative - nameservers in the attempt to diagnose the source or prevalence of - inaccurate data, but can also conceivably be useful for caching - resolvers in similar and other situations. Furthermore, the ability - to identify which server is responding to a query has become more - useful as DNS has become more critical to more Internet users, and as - network and server deployment topologies have become more complex. - - The traditional means for determining which of several possible - servers is answering a query has traditionally been based on the use - of the server's IP address as a unique identifier. However, the - modern Internet has seen the deployment of various load balancing, - fault-tolerance, or attack-resistance schemes such as shared use of - unicast IP addresses as documented in [RFC3258]. An unfortunate side - effect of these schemes has been to make the use of IP addresses as - identifiers somewhat problematic. Specifically, a dedicated DNS - query may not go to the same server as answered a previous query, - even though sent to the same IP address. Non-DNS methods such as - ICMP ping, TCP connections, or non-DNS UDP packets (such as those - generated by tools like "traceroute"), etc., may well be even less - certain to reach the same server as the one which receives the DNS - queries. - - There is a well-known and frequently-used technique for determining - an identity for a nameserver more specific than the possibly-non- - unique "server that answered the query I sent to IP address XXX". - The widespread use of the existing convention suggests a need for a - documented, interoperable means of querying the identity of a - nameserver that may be part of an anycast or load-balancing cluster. - At the same time, however, it also has some drawbacks that argue - against standardizing it as it's been practiced so far. - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 3] - -Internet-Draft Serverid March 2006 - - -2. Existing Conventions - - For some time, the commonly deployed Berkeley Internet Name Domain - implementation of the DNS protocol suite from the Internet Systems - Consortium [BIND] has supported a way of identifying a particular - server via the use of a standards-compliant, if somewhat unusual, DNS - query. Specifically, a query to a recent BIND server for a TXT - resource record in class 3 (CHAOS) for the domain name - "HOSTNAME.BIND." will return a string that can be configured by the - name server administrator to provide a unique identifier for the - responding server. (The value defaults to the result of a - gethostname() call). This mechanism, which is an extension of the - BIND convention of using CHAOS class TXT RR queries to sub-domains of - the "BIND." domain for version information, has been copied by - several name server vendors. - - A refinement to the BIND-based mechanism, which dropped the - implementation-specific string, replaces ".BIND" with ".SERVER". - Thus the query string to learn the unique name of a server may be - queried as "ID.SERVER". - - (For reference, the other well-known name used by recent versions of - BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A - query for a CHAOS TXT RR for this name will return an - administratively defined string which defaults to the version of the - server responding. This is, however, not generally implemented by - other vendors.) - -2.1. Advantages - - There are several valuable attributes to this mechanism, which - account for its usefulness. - - 1. The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is - within the DNS protocol itself. An identification mechanism that - relies on the DNS protocol is more likely to be successful - (although not guaranteed) in going to the same system as a - "normal" DNS query. - - 2. Since the identity information is requested and returned within - the DNS protocol, it doesn't require allowing any other query - mechanism to the server, such as holes in firewalls for - otherwise-unallowed ICMP Echo requests. Thus it is likely to - reach the same server over a path subject to the same routing, - resource, and security policy as the query, without any special - exceptions to site security policy. - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 4] - -Internet-Draft Serverid March 2006 - - - 3. It is simple to configure. An administrator can easily turn on - this feature and control the results of the relevant query. - - 4. It allows the administrator complete control of what information - is given out in the response, minimizing passive leakage of - implementation or configuration details. Such details are often - considered sensitive by infrastructure operators. - - 5. Hypothetically, since it's an ordinary DNS record and the - relevant DNSSEC RRs are class independent, the id.server response - RR could be signed, which has the advantages described in - [RFC4033]. - -2.2. Disadvantages - - At the same time, there are some serious drawbacks to the CHAOS/TXT - query mechanism that argue against standardizing it as it currently - operates. - - 1. It requires an additional query to correlate between the answer - to a DNS query under normal conditions and the supposed identity - of the server receiving the query. There are a number of - situations in which this simply isn't reliable. - - 2. It reserves an entire class in the DNS (CHAOS) for what amounts - to one zone. While CHAOS class is defined in [RFC1034] and - [RFC1035], it's not clear that supporting it solely for this - purpose is a good use of the namespace or of implementation - effort. - - 3. The initial and still common form, using .BIND, is implementation - specific. BIND is one DNS implementation. At the time of this - writing, it is probably the most prevalent for authoritative - servers. This does not justify standardizing on its ad hoc - solution to a problem shared across many operators and - implementors. Meanwhile, the proposed refinement changes the - string but preserves the ad hoc CHAOS/TXT mechanism. - - 4. There is no convention or shared understanding of what - information an answer to such a query for a server identity could - or should include, including a possible encoding or - authentication mechanism. - - The first of the listed disadvantages may be technically the most - serious. It argues for an attempt to design a good answer to the - problem that "I need to know what nameserver is answering my - queries", not simply a convenient one. - - - - -Woolf & Conrad Expires September 6, 2006 [Page 5] - -Internet-Draft Serverid March 2006 - - -2.3. Characteristics of an Implementation Neutral Convention - - The discussion above of advantages and disadvantages to the - HOSTNAME.BIND mechanism suggest some requirements for a better - solution to the server identification problem. These are summarized - here as guidelines for any effort to provide appropriate protocol - extensions: - - 1. The mechanism adopted must be in-band for the DNS protocol. That - is, it needs to allow the query for the server's identifying - information to be part of a normal, operational query. It should - also permit a separate, dedicated query for the server's - identifying information. But it should preserve the ability of - the CHAOS/TXT query-based mechanism to work through firewalls and - in other situations where only DNS can be relied upon to reach - the server of interest. - - 2. The new mechanism should not require dedicated namespaces or - other reserved values outside of the existing protocol mechanisms - for these, i.e. the OPT pseudo-RR. In particular, it should not - propagate the existing drawback of requiring support for a CLASS - and top level domain in the authoritative server (or the querying - tool) to be useful. - - 3. Support for the identification functionality should be easy to - implement and easy to enable. It must be easy to disable and - should lend itself to access controls on who can query for it. - - 4. It should be possible to return a unique identifier for a server - without requiring the exposure of information that may be non- - public and considered sensitive by the operator, such as a - hostname or unicast IP address maintained for administrative - purposes. - - 5. It should be possible to authenticate the received data by some - mechanism analogous to those provided by DNSSEC. In this - context, the need could be met by including encryption options in - the specification of a new mechanism. - - 6. The identification mechanism should not be implementation- - specific. - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 6] - -Internet-Draft Serverid March 2006 - - -3. IANA Considerations - - This document proposes no specific IANA action. Protocol extensions, - if any, to meet the requirements described are out of scope for this - document. A proposed extension, specified and adopted by normal IETF - process, is described in [NSID], including relevant IANA action. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 7] - -Internet-Draft Serverid March 2006 - - -4. Security Considerations - - Providing identifying information as to which server is responding to - a particular query from a particular location in the Internet can be - seen as information leakage and thus a security risk. This motivates - the suggestion above that a new mechanism for server identification - allow the administrator to disable the functionality altogether or - partially restrict availability of the data. It also suggests that - the serverid data should not be readily correlated with a hostname or - unicast IP address that may be considered private to the nameserver - operator's management infrastructure. - - Propagation of protocol or service meta-data can sometimes expose the - application to denial of service or other attack. As DNS is a - critically important infrastructure service for the production - Internet, extra care needs to be taken against this risk for - designers, implementors, and operators of a new mechanism for server - identification. - - Both authentication and confidentiality of serverid data are - potentially of interest to administrators-- that is, operators may - wish to make serverid data available and reliable to themselves and - their chosen associates only. This would imply both an ability to - authenticate it to themselves and keep it private from arbitrary - other parties. This led to Characteristics 4 and 5 of an improved - solution. - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 8] - -Internet-Draft Serverid March 2006 - - -5. Acknowledgements - - The technique for host identification documented here was initially - implemented by Paul Vixie of the Internet Software Consortium in the - Berkeley Internet Name Daemon package. Comments and questions on - earlier drafts were provided by Bob Halley, Brian Wellington, Andreas - Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the - ICANN Root Server System Advisory Committee. The newest version - takes a significantly different direction from previous versions, - owing to discussion among contributors to the DNSOP working group and - others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam - Weiler, and Rob Austein. - -6. References - - [1] Mockapetris, P., "Domain Names - Concepts and Facilities", - RFC 1034, STD 0013, November 1987. - - [2] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, STD 0013, November 1987. - - [3] Hardie, T., "Distributing Authoritative Name Servers via Shared - Unicast Addresses", RFC 3258, April 2002. - - [4] ISC, "BIND 9 Configuration Reference". - - [5] Austein, S., "DNS Name Server Identifier Option (NSID)", - Internet Drafts http://www.ietf.org/internet-drafts/ - draft-ietf-dnsext-nsid-01.txt, January 2006. - - [6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 9] - -Internet-Draft Serverid March 2006 - - -Authors' Addresses - - Suzanne Woolf - Internet Systems Consortium, Inc. - 950 Charter Street - Redwood City, CA 94063 - US - - Phone: +1 650 423-1333 - Email: woolf@isc.org - URI: http://www.isc.org/ - - - David Conrad - Nominum, Inc. - 2385 Bay Road - Redwood City, CA 94063 - US - - Phone: +1 1 650 381 6003 - Email: david.conrad@nominum.com - URI: http://www.nominum.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 10] - -Internet-Draft Serverid March 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Woolf & Conrad Expires September 6, 2006 [Page 11] - - diff --git a/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt deleted file mode 100644 index 3353b3bb42..0000000000 --- a/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt +++ /dev/null @@ -1,1588 +0,0 @@ - - Mark Foster -Internet Draft Tom McGarry -Document: James Yu - NeuStar, Inc. -Category: Informational June 24, 2002 - - - Number Portability in the GSTN: An Overview - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [RFC]. - - 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. - - - Copyright Notice - - Copyright (C) The Internet Society (2002). All rights reserved. - - - Abstract - - This document provides an overview of E.164 telephone number - portability (NP) in the Global Switched Telephone Network (GSTN). - NP is a regulatory imperative seeking to liberalize local telephony - service competition, by enabling end-users to retain telephone - numbers while changing service providers. NP changes the - fundamental nature of a dialed E.164 number from a hierarchical - physical routing address to a virtual address, thereby requiring the - transparent translation of the later to the former. In addition, - there are various regulatory constraints that establish relevant - parameters for NP implementation, most of which are not network - technology specific. Consequently, the implementation of NP - behavior consistent with applicable regulatory constraints, as well - as the need for interoperation with the existing GSTN NP - implementations, are relevant topics for numerous areas of IP - telephony work-in-progress at IETF. - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 1] - -Number Portability in the GSTN: An Overview June 24, 2002 - - - Table of Contents - - 1. Introduction ............................................... 2 - 2. Abbreviations and Acronyms ................................. 4 - 3. Types of Number Portability ................................ 5 - 4. Service Provider Number Portability Schemes ................ 7 - 4.1 All Call Query (ACQ) .................................. 7 - 4.2 Query on Release (QoR) ................................ 8 - 4.3 Call Dropback ......................................... 9 - 4.4 Onward Routing (OR) ................................... 9 - 4.5 Comparisons of the Four Schemes ....................... 10 - 5. Database Queries in the NP Environment ..................... 11 - 5.1 U.S. and Canada ....................................... 12 - 5.2 Europe ................................................ 13 - 6. Call Routing in the NP Environment ......................... 14 - 6.1 U.S. and Canada ....................................... 14 - 6.2 Europe ................................................ 15 - 7. NP Implementations for Geographic E.164 Numbers ............ 17 - 8. Number Conservation Method Enabled By NP ................... 20 - 8.1 Block Pooling ......................................... 20 - 8.2 ITN Pooling ........................................... 21 - 9. Potential Implications ..................................... 21 - 10. Security Considerations .................................... 24 - 11. IANA Considerations ........................................ 24 - 12. Normative References ....................................... 24 - 13. Informative References ..................................... 25 - 14. Acknowledgement ............................................ 25 - 15. AuthorsË Addresses ......................................... 25 - - - -1. Introduction - - This document provides an overview of E.164 telephone number - portability in the Global Switched Telephone Network (GSTN). There - are considered to be three types of number portability (NP): service - provider portability (SPNP), location portability (not to be - confused with terminal mobility), and service portability. - - Service provider portability (SPNP), the focus of the present draft, - is a regulatory imperative in many countries seeking to liberalize - telephony service competition, especially local service. - Historically, local telephony service (as compared to long distance - or international service) has been regulated as a utility-like form - of service. While a number of countries had begun liberalization - (e.g. privatization, de-regulation, or re-regulation) some years - ago, the advent of NP is relatively recent (since ~1995). - - E.164 numbers can be non-geographic and geographic numbers. Non- - geographic numbers do not reveal the locations information of those - numbers. Geographic E.164 numbers were intentionally designed as - hierarchical routing addresses which could systematically be digit- - analyzed to ascertain the country, serving network provider, serving - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 2] - -Number Portability in the GSTN: An Overview June 24, 2002 - - end-office switch, and specific line of the called party. As such, - without NP a subscriber wishing to change service providers would - incur a number change as a consequence of being served off of a - different end-office switch operated by the new service provider. - The cost and convenience impact to the subscriber of changing - numbers is seen as barrier to competition. Hence NP has become - associated with GSTN infrastructure enhancements associated with a - competitive environment driven by regulatory directives. - - Forms of SPNP have been deployed or are being deployed widely in the - GSTN in various parts of the world, including the U.S., Canada, - Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong). - Other regions, such as South America (e.g. Brazil) are actively - considering it. - - Implementation of NP within a national telephony infrastructure - entails potentially significant changes to numbering administration, - network element signaling, call routing and processing, billing, - service management, and other functions. - - NP changes the fundamental nature of a dialed E.164 number from a - hierarchical physical routing address to a virtual address. NP - implementations attempt to encapsulate the impacts to the GSTN and - make NP transparent to subscribers by incorporating a translation - function to map a dialed, potentially ported E.164 address, into a - network routing address (either a number prefix or another E.164 - address) which can be hierarchically routed. - - This is roughly analogous to the use of network address translation - on IP addresses to enable IP address portability by containing the - impact of the address change to the edge of the network and retain - the use of CIDR blocks in the core which can be route aggregated by - the network service provider to the rest of the internet. - - NP bifurcates the historical role of a subscriberËs E.164 address - into two or more data elements (a dialed or virtual address, and a - network routing address) that must be made available to network - elements through an NP translations database, carried by forward - call signaling, and recorded on call detail records. Not only is - call processing and routing affected, but also so is SS7/C7 - messaging. A number of TCAP-based SS7 messaging sets utilize an - E.164 address as an application-level network element address in the - global title address (GTA) field of the SCCP message header. - Consequently, SS7/C7 signaling transfer points (STPs) and gateways - need to be able to perform n-digit global title translation (GTT) to - translate a dialed E.164 address into its network address - counterpart via the NP database. - - In addition, there are various national regulatory constraints that - establish relevant parameters for NP implementation, most of which - are not network technology specific. Consequently, implementations - of NP behavior in IP telephony consistent with applicable regulatory - constraints, as well as the need for interoperation with the - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 3] - -Number Portability in the GSTN: An Overview June 24, 2002 - - existing GSTN NP implementations, are relevant topics for numerous - areas of IP telephony work-in-progress at IETF. - - This document describes three types of number portability and the - four schemes that have been standardized to support SPNP for - geographic E.164 numbersspecifically. Following that, specific - information regarding the call routing and database query - implementations are described for several regions (North American - and Europe) and industries (wireless vs. wireline). The Number - Portability Database (NPDB) interfaces and the call routing schemes - that are used in the North America and Europe are described to show - the variety of standards that may be implemented worldwide. A - glance of the NP implementations worldwide is provided. Number - pooling is briefly discussed to show how NP is being enhanced in the - U.S. to conserve North American area codes. The conclusion briefly - touches the potential impacts of NP on IP & Telecommunications - Interoperability. Appendix A provides some specific technical and - regulatory information on NP in North America. Appendix B describes - the number portability administration process that manages the - number portability database in North America. - - -2. Abbreviations and Acronyms - - ACQ All Call Query - AIN Advanced Intelligent Network - AMPS Advanced Mobile Phone System - ANSI American National Standards Institute - CDMA Code Division Multiple Access - CdPA Called Party Address - CdPN Called Party Number - CH Code Holder - CMIP Common Management Information Protocol - CS1 Capability Set 1 - CS2 Capability Set 2 - DN Directory Number - DNS Domain Name System - ETSI European Technical Standards Institute - FCI Forward Call Indicator - GAP Generic Address Parameter - GMSC Gateway Mobile Services Switching Center or Gateway Mobile - Switching Center - GSM Global System for Mobile Communications - GSTN Global Switched Telephone Network - GW Gateways - HLR Home Location Register - IAM Initial Address Message - IETF Internet Engineering Task Force - ILNP Interim LNP - IN Intelligent Network - INAP Intelligent Network Application Part - INP Interim NP - IP Internet Protocol - IS-41 Interim Standards Number 41 - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 4] - -Number Portability in the GSTN: An Overview June 24, 2002 - - ISDN Integrated Services Digital Network - ISUP ISDN User Part - ITN Individual Telephony Number - ITU International Telecommunication Union - ITU-TS ITU-Telecommunication Sector - LDAP Lightweight Directory Access Protocol - LEC Local Exchange Carrier - LERG Local Exchange Routing Guide - LNP Local Number Portability - LRN Location Routing Number - MAP Mobile Application Part - MNP Mobile Number Portability - MSRN Mobile Station Roaming Number - MTP Message Transfer Part - NANP North American Numbering Plan - NP Number Portability - NPDB Number Portability Database - NRN Network Routing Number - OR Onward Routing - OSS Operation Support System - PCS Personal Communication Services - PNTI Ported Number Translation Indicator - PODP Public Office Dialing Plan - PUC Public Utility Commission - QoR Query on Release - RN Routing Number - RTP Return to Pivot - SCCP Signaling Connection Control Part - SCP Service Control Point - SIP Session Initiation Protocol - SMR Special Mobile Radio - SMS Service Management System - SPNP Service Provider Number Portability - SRF Signaling Relaying Function - SRI Send Routing Information - SS7 Signaling System Number 7 - STP Signaling Transfer Point - TCAP Transaction Capabilities Application Part - TDMA Time Division Multiple Access - TN Telephone Number - TRIP Telephony Routing Information Protocol - URL Universal Resource Locator - U.S. United States - - -3. Types of Number Portability - - As there are several types of E.164 numbers (telephone numbers, or - just TN) in the GSTN, there are correspondingly several types of - E.164 NP in the GSTN. First there are so-call non-geographic E.164 - numbers, commonly used for service-specific applications such as - freephone (800 or 0800). Portability of these numbers is called - non-geographic number portability (NGNP). NGNP, for example, was - deployed in the U.S. in 1986-92. - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 5] - -Number Portability in the GSTN: An Overview June 24, 2002 - - - Geographic number portability, which includes traditional fixed or - wireline numbers as well as mobile numbers which are allocated out - of geographic number range prefixes, is called NP or GNP or in the - U.S. local number portability (LNP). - - Number portability allows the telephony subscribers in the Global - Switched Telephone Network (GSTN) to keep their phone numbers when - they change their service providers or subscribed services, or when - they move to a new location. - - The ability to change the service provider while keeping the same - phone number is called service provider portability (SPNP) also - known as "operator portability." - - The ability to change the subscriberËs fixed service location while - keeping the same phone number is called location portability. - - The ability to change the subscribed services (e.g., from the plain - old telephone service to Integrated Services Digital Network (ISDN) - services) while keeping the same phone number is called service - portability. Another aspect of service portability is to allow the - subscribers to enjoy the subscribed services in the same way when - they roam outside their home networks as is supported by the - cellular/wireless networks. - - In addition, mobile number portability (MNP) refers to specific NP - implementation in mobile networks either as part of a broader NP - implementation in the GSTN or on a stand-alone basis. Where - interoperation of LNP and MNP is supported, service portability - between fixed and mobile service types is possible. - - At present, SPNP has been the primary form of NP deployed due to its - relevance in enabling local service competition. - - Also in use in the GSTN are the terms interim NP (INP) or Interim - LNP (ILNP) and true NP. Interim NP usually refers to the use of - remote call forwarding-like measures to forward calls to ported - numbers through the donor network to the new service network. These - are considered interim relative to true NP, which seeks to remove - the donor network or old service provider from the call or signaling - path altogether. Often the distinction between interim and true NP - is a national regulatory matter relative to the - technical/operational requirements imposed on NP in that country. - - Implementations of true NP in certain countries (e.g. U.S., Canada, - Spain, Belgium, Denmark) may pose specific requirements for IP - telephony implementations as a result of regulatory and industry - requirements for providing call routing and signaling independent of - the donor network or last previous serving network. - - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 6] - -Number Portability in the GSTN: An Overview June 24, 2002 - - -4. Service Provider Number Portability Schemes - - Four schemes can be used to support service provider portability and - are briefly described below. But first, some further terms are - introduced. - - The donor network is the network that first assigned a telephone - number (e.g., TN +1-202-533-1234) to a subscriber, out of a number - range administratively (e.g., +1 202-533) assigned to it. The - current service provider (new SP) or new serving network is the - network that currently serves the ported number. The old serving - network (or old SP) is the network that previously served the ported - number before the number was ported to the new serving network. - Since a TN can port a number of times, the old SP is not necessarily - the same as the donor network, except for the first time the TN - ports away, or if the TN ports back into the donor network and away - again. While the new SP and old SP roles are transitory as a TN - ports around, the donor network is always the same for any - particular TN based on the service provider to whom the subtending - number range was administratively assigned. See the discussion - below on number pooling, as this enhancement to NP further - bifurcates the role of donor network into two (the number range or - code holder network, and the block holder network). - - To simplify the illustration, all the transit networks are ignored, - the originating or donor network is the one that performs the - database queries or call redirection, and the dialed directory - number (TN) has been ported out of the donor network before. - - It is assumed that the old serving network, the new serving network - and the donor network are different networks so as to show which - networks are involved in call handling and routing and database - queries in each of four schemes. Please note that the port of the - number (process of moving it from one network to another) happened - prior to the call setup and is not included in the call steps. - Information carried in the signaling messages to support each of the - four schemes is not discussed to simplify the explanation. - - -4.1 All Call Query (ACQ) - - Figure 1 shows the call steps for the ACQ scheme. Those call steps - are as follows: - - (1) The Originating Network receives a call from the caller and - sends a query to a centrally administered Number Portability - Database (NPDB), a copy of which is usually resident on a - network element within its network or through a third party - provider. - (2) The NPDB returns the routing number associated with the dialed - directory number. The routing number is discussed later in - Section 6. - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 7] - -Number Portability in the GSTN: An Overview June 24, 2002 - - (3) The Originating Network uses the routing number to route the - call to the new serving network. - - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | ported | Old Serv. | - | NPDB | +-------->| Network |<------------| Network | - +-------------+ | +-----------+ +-----------+ - ^ | | - | | | - 1| | 3.| - | | 2. | - | | | - | v | - +----------+ | +----------+ +----------+ - | Orig. |------+ | Donor | | Internal | - | Network | | Network | | NPDB | - +----------+ +----------+ +----------+ - - - Figure 1 - All Call Query (ACQ) Scheme. - - -4.2 Query on Release (QoR) - - Figure 2 shows the call steps for the QoR scheme. Those call steps - are as follows: - - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | ported | Old Serv. | - | NPDB | | Network |<------------| Network | - +-------------+ +-----------+ +-----------+ - ^ | ^ - | | 4. | - 3.| | 5. | - | | +----------------------+ - | | | - | v | - +----------+ 2. +----------+ +----------+ - | Orig. |<---------------| Donor | | Internal | - | Network |--------------->| Network | | NPDB | - +----------+ 1. +----------+ +----------+ - - - Figure 2 - Query on Release (QoR) Scheme. - - (1) The Originating Network receives a call from the caller and - routes the call to the donor network. - (2) The donor network releases the call and indicates that the - dialed directory number has been ported out of that switch. - (3) The Originating Network sends a query to its copy of the - centrally administered NPDB. - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 8] - -Number Portability in the GSTN: An Overview June 24, 2002 - - (4) The NPDB returns the routing number associated with the dialed - directory number. - (5) The Originating Network uses the routing number to route the - call to the new serving network. - - -4.3 Call Dropback - - Figure 3 shows the call steps for the Dropback scheme. This scheme - is also known as "Return to Pivot (RTP)." Those call steps are as - follows: - - (1) The Originating Network receives a call from the caller and - routes the call to the donor network. - (2) The donor network detects that the dialed directory number has - been ported out of the donor switch and checks with an internal - network-specific NPDB. - (3) The internal NPDB returns the routing number associated with the - dialed directory number. - (4) The donor network releases the call by providing the routing - number. - (5) The Originating Network uses the routing number to route the - call to the new serving network. - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | porting | Old Serv. | - | NPDB | | Network |<------------| Network | - +-------------+ +-----------+ +-----------+ - /\ - | - 5. | - +------------------------+ - | - | - +----------+ 4. +----------+ 3. +----------+ - | Orig. |<---------------| Donor |<----------| Internal | - | Network |--------------->| Network |---------->| NPDB | - +----------+ 1. +----------+ 2. +----------+ - - - Figure 3 - Dropback Scheme. - - -4.4 Onward Routing (OR) - - Figure 4 shows the call steps for the OR scheme. Those call steps - are as follows: - - (1) The Originating Network receives a call from the caller and - routes the call to the donor network. - (2) The donor network detects that the dialed directory number has - been ported out of the donor switch and checks with an internal - network-specific NPDB. - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 9] - -Number Portability in the GSTN: An Overview June 24, 2002 - - (3) The internal NPDB returns the routing number associated with the - dialed directory number. - (4) The donor network uses the routing number to route the call to - the new serving network. - - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | porting | Old Serv. | - | NPDB | | Network |<------------| Network | - +-------------+ +-----------+ +-----------+ - /\ - | - 4.| - | - +----------+ +----------+ 3. +----------+ - | Orig. | | Donor |<----------| Internal | - | Network |--------------->| Network |---------->| NPDB | - +----------+ 1. +----------+ 2. +----------+ - - - Figure 4 - Onward Routing (OR) Scheme. - -4.5 Comparisons of the Four Schemes - - Only the ACQ scheme does not involve the donor network when routing - the call to the new serving network of the dialed ported number. - The other three schemes involve call setup to or signaling with the - donor network. - - Only the OR scheme requires the setup of two physical call segments, - one from the Originating Network to the donor network and the other - from the donor network to the new serving network. The OR scheme is - the least efficient in terms of using the network transmission - facilities. The QoR and Dropback schemes set up calls to the donor - network first but release the call back to the Originating Network - that then initiates a new call to the Current Serving Network. For - the QoR and Dropback schemes, circuits are still reserved one by one - between the Originating Network and the donor network when the - Originating Network sets up the call towards the donor network. - Those circuits are released one by one when the call is released - from the donor network back to the Originating Network. The ACQ - scheme is the most efficient in terms of using the switching and - transmission facilities for the call. - - Both the ACQ and QoR schemes involve Centralized NPDBs for the - Originating Network to retrieve the routing information. - Centralized NPDB means that the NPDB contains ported number - information from multiple networks. This is in contrast to the - internal network-specific NPDB that is used for the Dropback and OR - schemes. The internal NPDB only contains information about the - numbers that were ported out of the donor network. The internal - NPDB can be a stand-alone database that contains information about - all or some ported-out numbers from the donor network. It can also - reside on the donor switch and only contains information about those - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 10] - -Number Portability in the GSTN: An Overview June 24, 2002 - - numbers ported out of the donor switch. In that case, no query to a - stand-alone internal NPDB is required. The donor switch for a - particular phone number is the switch to which the number range is - assigned from which that phone number was originally assigned. - - For example, number ranges in the North American Numbering Plan - (NANP) are usually assigned in the form of central office codes (CO - codes) comprising a six-digit prefix formatted as a NPA+NXX. Thus a - switch serving +1-202-533 would typically serve +1-202-533-0000 - through +1-202-533-9999. In major cities, switches usually host - several CO codes. NPA stands for Numbering Plan Area that is also - known as the area code. It is three-digit long and has the format - of NXX where N is any digit from 2 to 9 and X is any digit from 0 to - 9. NXX in the NPA+NXX format is known as the office code that has - the same format as the NPA. When a NPA+NXX code is set as - Ÿportable÷ in the Local Exchange Routing Guide (LERG), it becomes a - "portable NPA+NXX" code. - - Similarly, in other national E.164 numbering plans, number ranges - cover a contiguous range of numbers within that range. Once a - number within that range has ported away from the donor network, all - numbers in that range are considered potentially ported and should - be queried in the NPDB. - - The ACQ scheme has two versions. One version is for the Originating - Network to always query the NPDB when a call is received from the - caller regardless whether the dialed directory number belongs to any - number range that is portable or has at least one number ported out. - The other version is to check whether the dialed directory number - belongs to any number range that is portable or has at least one - number ported out. If yes, an NPDB query is sent. If not, no NPDB - query is sent. The former performs better when there are many - portable number ranges. The latter performs better when there are - not too many portable number ranges at the expense of checking every - call to see whether NPDB query is needed. The latter ACQ scheme is - similar to the QoR scheme except that the QoR scheme uses call setup - and relies on the donor network to indicate "number ported out" - before launching the NPDB query. - - -5. Database Queries in the NP Environment - - As indicated earlier, the ACQ and QoR schemes require that a switch - query the NPDB for routing information. Various standards have been - defined for the switch-to-NPDB interface. Those interfaces with - their protocol stacks are briefly described below. The term "NPDB" - is used for a stand-alone database that may support just one or some - or all of the interfaces mentioned below. The NPDB query contains - the dialed directory number and the NPDB response contains the - routing number. There are certainly other information that is sent - in the query and response. The primary interest is to get the - routing number from the NPDB to the switch for call routing. - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 11] - -Number Portability in the GSTN: An Overview June 24, 2002 - -5.1 U.S. and Canada - - One of the following five NPDB interfaces can be used to query an - NPDB: - - (a) Advanced Intelligent Network (AIN) using the American National - Standards Institute (ANSI) version of the Intelligent Network - Application Part (INAP) [ANSI SS] [ANSI DB]. The INAP is - carried on top of the protocol stack that includes the (ANSI) - Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling - Connection Control Part (SCCP), and ANSI Transaction - Capabilities Application Part (TCAP). This interface can be - used by the wireline or wireless switches, is specific to the NP - implementation in North America, and is modeled on the Public - Office Dialing Plan (PODP) trigger defined in the Advanced - Intelligent Network (AIN) 0.1 call model. - - (b) Intelligent Network (IN), which is similar to the one used for - querying the 800 databases. The IN protocol is carried on top - of the protocol stack that includes the ANSI MTP Levels 1 - through 3, ANSI SCCP, and ANSI TCAP. This interface can be used - by the wireline or wireless switches. - - (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the - protocol stack that includes the ANSI MTP Levels 1 through 3, - ANSI SCCP, and ANSI TCAP. This interface can be used by the IS- - 41 based cellular/Personal Communication Services (PCS) wireless - switches (e.g., AMPS, TDMA and CDMA). Cellular systems use - spectrum at 800 MHz range and PCS systems use spectrum at 1900 - MHz range. - - (d) Global System for Mobile Communication Mobile Application Part - (GSM MAP) [GSM], which is carried on top of the protocol stack - that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and - International Telecommunication Union - Telecommunication Sector - (ITU-TS) TCAP. It can be used by the PCS1900 wireless switches - that are based on the GSM technologies. GSM is a series of - wireless standards defined by the European Telecommunications - Standards Institute (ETSI). - - (e) ISUP triggerless translation. NP translations are performed - transparently to the switching network by the signaling network - (e.g. Signaling Transfer Points (STPs) or signaling gateways). - ISUP IAM messages are examined to determine if the CdPN field - has already been translated, and if not, an NPDB query is - performed, and the appropriate parameters in the IAM message - modified to reflect the results of the translation. The - modified IAM message is forwarded by the signaling node on to - the designated DPC in a transparent manner to continue call - setup. The NPDB can be integrated with the signaling node or be - accessed via an API locally or by a query to a remote NPDB using - a proprietary protocol or the schemes described above. - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 12] - -Number Portability in the GSTN: An Overview June 24, 2002 - - Wireline switches have the choice of using either (a), (b), or (e). - IS-41 based wireless switches have the choice of using (a), (b), - (c), or (e). PCS1900 wireless switches have the choice of using - (a), (b), (d), or (e). In the United States, service provider - portability will be supported by both the wireline and wireless - systems, not only within the wireline or wireless domain but also - across the wireline/wireless boundary. However, this is not true in - Europe where service provider portability is usually supported only - within the wireline or wireless domain, not across the - wireline/wireless boundary due to explicit use of service-specific - number range prefixes. The reason is to avoid caller confusion - about the call charge. GSM systems in Europe are assigned - distinctive destination network codes, and the caller pays a higher - charge when calling a GSM directory number. - - -5.2 Europe - - One of the following two interfaces can be used to query an NPDB: - - (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is - carried on top of the protocol stack that includes the ITU-TS - MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP. - - (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is - carried on top of the protocol stack that includes the ITU-TS - MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP, - and ITU-TS TCAP. - - Wireline switches have the choice of using either (a) or (b); - however, all the implementations in Europe so far are based on CS1. - As indicated earlier that number portability in Europe does not go - across the wireline/wireless boundary. The wireless switches can - also use (a) or (b) to query the NPDBs if those NPDBs contains - ported wireless directory numbers. The term "Mobile Number - Portability (MNP)" is used for the support of service provider - portability by the GSM networks in Europe. - - In most, if not all, cases in Europe, the calls to the wireless - directory numbers are routed to the wireless donor network first. - Over there, an internal NPDB is queried to determine whether the - dialed wireless directory number has been ported out or not. In - this case, the interface to the internal NPDB is not subject to - standardization. - - MNP in Europe can also be supported via MNP Signaling Relay Function - (MNP-SRF). Again, an internal NPDB or a database integrated at the - MNP-SRF is used to modify the SCCP Called Party Address parameter in - the GSM MAP messages so that they can be re-directed to the wireless - serving network. Call routing involving MNP will be explained in - Section 6.2. - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 13] - -Number Portability in the GSTN: An Overview June 24, 2002 - -6. Call Routing in the NP Environment - - This section discusses the call routing after the routing - information has been retrieved either through an NPDB query or an - internal database lookup at the donor switch, or from the Integrated - Services Digital Network User Part (ISUP) signaling message (e.g., - for the Dropback scheme). For the ACQ, QoR and Dropback schemes, it - is the Originating Network that has the routing information and is - ready to route the call. For the OR scheme, it is the donor network - that has the routing information and is ready to route the call. - - A number of triggering schemes may be employed that determine where - in the call path the NPDB query is performed. In the U.S. an ŸN-1÷ - policy is used, which essentially says that for domestic calls, the - originating local carriers performs the query, otherwise, the long - distance carrier is expected to. To ensure independence of the - actual trigger policy employed in any one carrier, forward call - signaling is used to flag that an NPDB query has already been - performed and to therefore suppress any subsequent NP triggers that - may be encountered in downstream switches, in downstream networks. - This allows the earliest able network in the call path to perform - the query without introducing additional costs and call setup delays - were redundant queries performed downstream. - - -6.1 U.S. and Canada - - In the U.S. and Canada, a ten-digit North American Numbering Plan - (NANP) number called Location Routing Number (LRN) is assigned to - every switch involved in NP. In the NANP, a switch is not reachable - unless it has a unique number range (CO code) assigned to it. - Consequently, the LRN for a switch is always assigned out of a CO - code that is assigned to that switch. - - The LRN assigned to a switch currently serving a particular ported - telephone number is returned as the network routing address in the - NPDB response. The service portability scheme that was adopted in - the North America is very often referred to as the LRN scheme or - method. - - LRN serves as a network address for terminating calls served off - that switch using ported numbers. The LRN is assigned by the switch - operator using any of the unique CO codes (NPA+NXX) assigned to that - switch. The LRN is considered a non-dialable address, as the same - 10-digit number value may be assigned to a line on that switch. A - switch may have more than one LRN. - - During call routing/processing, a switch performs an NPDB query to - obtain the LRN associated with the dialed directory number. NPDB - queries are performed for all the dialed directory numbers whose - NPA+NXX codes are marked as portable NPA+NXX at that switch. When - formulating the ISUP Initial Address Message (IAM) to be sent to the - next switch, the switch puts the ten-digit LRN in the ISUP Called - Party Number (CdPN) parameter and the originally dialed directory - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 14] - -Number Portability in the GSTN: An Overview June 24, 2002 - - number in the ISUP Generic Address parameter (GAP). A new code in - the GAP was defined to indicate that the address information in the - GAP is the dialed directory number. A new bit in the ISUP Forward - Call Indicator (FCI) parameter, the Ported Number Translation - Indicator (PNTI) bit, is set to imply that NPDB query has already - been performed. All the switches in the downstream will not perform - the NPDB query if the PNTI bit is set. - - When the terminating switch receives the IAM and sees the PNTI bit - in the FCI parameter set and its own LRN in the CdPN parameter, it - retrieves the originally dialed directory number from the GAP and - uses the dialed directory number to terminate the call. - - A dialed directory number with a portable NPA+NXX does not imply - that directory number has been ported. The NPDBs currently do not - store records for non-ported directory numbers. In that case, the - NPDB will return the same dialed directory number instead of the - LRN. The switch will then set the PNTI bit but keep the dialed - directory number in the CdPN parameter. - - In the real world environment, the Originating Network is not always - the one that performs the NPDB query. For example, it is usually - the long distance carriers that query the NPDBs for long distance - calls. In that case, the Originating Network operated by the local - exchange carrier (LEC) simply routes the call to the long distance - carrier that is to handle that call. A wireless network acting as - the Originating Network can also route the call to the - interconnected local exchange carrier network if it does not want to - support the NPDB interface at its mobile switches. - - -6.2 Europe - - In some European countries, a routing number is prefixed to the - dialed directory number. The ISUP CdPN parameter in the IAM will - contain the routing prefix and the dialed directory number. For - example, United Kingdom uses routing prefixes with the format of - 5XXXXX and Italy uses C600XXXXX as the routing prefix. The networks - use the information in the ISUP CdPN parameter to route the call to - the New/Current Serving Network. - - The routing prefix can identify the Current Serving Network or the - Current Serving Switch of a ported number. For the former case, - another query to the "internal" NPDB at the Current Serving Network - is required to identify the Current Serving Switch before routing - the call to that switch. This shields the Current Serving Switch - information for a ported number from the other networks at the - expense of an additional NPDB query. Another routing number, may be - meaningful within the Current Serving Network, will replace the - previously prefixed routing number in the ISUP CdPN parameter. For - the latter case, the call is routed to the Current Serving Switch - without an additional NPDB query. - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 15] - -Number Portability in the GSTN: An Overview June 24, 2002 - - When the terminating switch receives the IAM and sees its own - routing prefix in the CdPN parameter, it retrieves the originally - dialed directory number after the routing prefix, and uses the - dialed directory number to terminate the call. - - The call routing example described above shows one of the three - methods that can be used to transport the Directory Number (DN) and - the Routing Number (RN) in the ISUP IAM message. In addition, some - other information may be added/modified as is listed in the ETSI 302 - 097 document [ETSIISUP], which is based on the ITU-T Recommendation - Q.769.1 [ITUISUP]. The three methods and the enhancements in the - ISUP to support number portability are briefly described below - - (a) Two separate parameters with the CdPN parameter containing the - RN and a new Called Directory Number (CdDN) parameter containing - the DN. A new value for the Nature of Address (NOA) indicator in - the CdPN parameter is defined to indicate that the RN is in the - CdPN parameter. The switches use the CdPN parameter to route the - call as is done today. - - (b) Two separate parameters with the CdPN parameter containing the - DN and a new Network Routing Number (NRN) parameter containing - the RN. This method requires that the switches use the NRN - parameter to route the call. - - (c) Concatenated parameter with the CdPN parameter containing the RN - plus the DN. A new Nature of Address (NOA) indicator in the CdPN - parameter is defined to indicate that the RN is concatenated with - the DN in the CdPN parameter. Some countries may not use new NOA - value because the routing prefix does not overlap with the dialed - directory numbers. But if the routing prefix overlaps with the - dialed directory numbers, a new NOA value must be assigned. For - example, Spain uses "XXXXXX" as the routing prefix to identify - the new serving network and uses a new NOA value of 126. - - There is also a network option to add a new ISUP parameter called - Number Portability Forwarding Information parameter. This parameter - has a four-bit Number Portability Status Indicator field that can - provide an indication whether number portability query is done for - the called directory number and whether the called directory number - is ported or not if the number portability query is done. - - Please note that all those NP enhancements for a ported number can - only be used in the country that defined them. This is because - number portability is supported within a nation. Within each - nation, the telecommunications industry or the regulatory bodies can - decide which method or methods to use. Number portability related - parameters and coding are usually not passed across the national - boundaries unless the interconnection agreements allow that. For - example, a UK routing prefix can only be used in UK, and would cause - routing problem if it appears outside UK. - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 16] - -Number Portability in the GSTN: An Overview June 24, 2002 - - As indicated earlier, an originating wireless network can query the - NPDB and concatenate the RN with DN in the CdPN parameter and route - the call directly to the Current Serving Network. - - If NPDBs do not contain information about the wireless directory - numbers, the call, originated from either a wireline or a wireless - network, will be routed to the Wireless donor network. Over there, - an internal NPDB is queried to retrieve the RN that then is - concatenated with the DN in the CdPN parameter. - - There are several ways of realizing MNP. When MNP-SRF is supported, - the Gateway Mobile Services Switching Center (GMSC) at the wireless - donor network, when receiving a call from the wireline network, can - send the GSM MAP Send Routing Information (SRI) message to the MNP- - SRF. The MNP-SRF interrogates an internal or integrated NPDB for - the RN of the MNP-SRF of the wireless Current Serving Network and - prefixes the RN to the dialed wireless directory number in the - global title address information in the SCCP Called Party Address - (CdPA) parameter. This SRI message will be routed to the MNP-SRF of - the wireless Current Serving Network, which then responds with an - acknowledgement by providing the RN plus the dialed wireless - directory number as the Mobile Station Roaming Number (MSRN). The - GMSC of the wireless donor network formulates the ISUP IAM with the - RN plus the dialed wireless directory number in the CdPN parameter - and routes the call to the wireless Current Serving Network. A GMSC - of the wireless Current Serving Network receives the call and sends - an SRI message to the associated MNP-SRF where the global title - address information of the SCCP CdPA parameter contains only the - dialed wireless directory number. The MNP-SRF then replaces the - global title address information in the SCCP CdPA parameter with the - address information associated with a Home Location Register (HLR) - that hosts the dialed wireless directory number and forwards the - message to that HLR after verifying that the dialed wireless - directory number is a ported-in number. The HLR then returns an - acknowledgement by providing an MSRN for the GMSC to route the call - to the MSC that currently serves the mobile station that is - associated with the dialed wireless directory number. Please see - [MNP] for details and additional scenarios. - - -7. NP Implementations for Geographic E.164 Numbers - - This section shows the known SPNP implementations worldwide. - - +-------------+----------------------------------------------------+ - + Country + SPNP Implementation + - +-------------+----------------------------------------------------+ - + Argentina + Analyzing operative viability now. Will determine + - + + whether portability should be made obligatory + - + + after a technical solution has been determined. + - +-------------+----------------------------------------------------+ - + Australia + NP supported by wireline operators since 11/30/99. + - + + NP among wireless operators in March/April 2000, + - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 17] - -Number Portability in the GSTN: An Overview June 24, 2002 - - + + but may be delayed to 1Q01. The access provider + - + + or long distance provider has the obligation to + - + + route the call to the correct destination. The + - + + donor network is obligated to maintain and make + - + + available a register of numbers ported away from + - + + its network. Telstra uses onward routing via an + - + + on-switch solution. + - +-------------+----------------------------------------------------+ - + Austria + Uses onward routing at the donor network. Routing + - + + prefix is "86xx" where "xx" identifies the + - + + recipient network. + - +-------------+----------------------------------------------------+ - + Belgium + ACQ selected by the industry. Routing prefix is + - + + "Cxxxx" where "xxxx" identifies the recipient + - + + switch. Another routing prefix is "C00xx" with "xx"+ - + + identifying the recipient network. Plan to use NOA+ - + + to identify concatenated numbers and abandon the + - + + hexadecimal routing prefix. + - +-------------+----------------------------------------------------+ - + Brazil + Considering NP for wireless users. + - +-------------+----------------------------------------------------+ - + Chile + There has been discussions lately on NP. + - +-------------+----------------------------------------------------+ - + Colombia + There was an Article 3.1 on NP to support NP prior + - + + to December 31, 1999 when NP became technically + - + + possible. Regulator has not yet issued regulations + - + + concerning this matter. + - +-------------+----------------------------------------------------+ - + Denmark + Uses ACQ. Routing number not passed between + - + + operators; however, NOA is set to "112" to + - + + indicate "ported number." QoR can be used based + - + + on bilateral agreements. + - +-------------+----------------------------------------------------+ - + Finland + Uses ACQ. Routing prefix is "1Dxxy" where "xxy" + - + + identifies the recipient network and service type. + - +-------------+----------------------------------------------------+ - + France + Uses onward routing. Routing prefix is "Z0xxx" + - + + where "xxx" identifies the recipient switch. + - +-------------+----------------------------------------------------+ - + Germany + The originating network needs to do necessary + - + + rerouting. Operators decide their own solution(s).+ - + + Deutsche Telekom uses ACQ. Routing prefix is + - + + "Dxxx" where "xxx" identifies the recipient + - + + network. + - +-------------+----------------------------------------------------+ - + Hong Kong + Recipient network informs other networks about + - + + ported-in numbers. Routing prefix is "14x" where + - + + "14x" identifies the recipient network, or a + - + + routing number of "4x" plus 7 or 8 digits is used + - + + where "4x" identifies the recipient network and + - + + the rest of digits identify the called party. + - +-------------+----------------------------------------------------+ - + Ireland + Operators choose their own solution but use onward + - + + routing now. Routing prefix is "1750" as the intra-+ - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 18] - -Number Portability in the GSTN: An Overview June 24, 2002 - - + + network routing code (network-specific) and + - + + "1752xxx" to "1759xxx" for GNP where "xxx" + - + + identifies the recipient switch. + - +-------------+----------------------------------------------------+ - + Italy + Uses onward routing. Routing prefix is "C600xxxxx" + - + + where "xxxxx" identifies the recipient switch. + - + + Telecom Italia uses IN solution and other operators+ - + + use on-switch solution. + - +-------------+----------------------------------------------------+ - + Japan + Uses onward routing. Donor switch uses IN to get + - + + routing number. + - +-------------+----------------------------------------------------+ - + Mexico + NP is considered in the Telecom law; however, the + - + + regulator (Cofetel) or the new local entrants have + - + + started no initiatives on this process. + - +-------------+----------------------------------------------------+ - + Netherlands + Operators decide NP scheme to use. Operators have + - + + chosen ACQ or QoR. KPN implemented IN solution + - + + similar to U.S. solution. Routing prefix is not + - + + passed between operators. + - +-------------+----------------------------------------------------+ - + Norway + OR for short-term and ACQ for long-term. QoR is + - + + optional. Routing prefix can be "xxx" with NOA=8, + - + + or "142xx" with NOA=3 where "xxx" or "xx" + - + + identifies the recipient network. + - +------------ +----------------------------------------------------+ - + Peru + Wireline NP may be supported in 2001. + - +-------------+----------------------------------------------------+ - + Portugal + No NP today. + - +-------------+----------------------------------------------------+ - + Spain + Uses ACQ. Telefonica uses QoR within its network. + - + + Routing prefix is "xxyyzz" where "xxyyzz" + - + + identifies the recipient network. NOA is set to + - + + 126. + - +-------------+----------------------------------------------------+ - + Sweden + Standardized the ACQ but OR for operators without + - + + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" + - + + with NOA=3 where "xxx" identifies the recipient + - + + network. But operators decide NP scheme to use. + - + + Telia uses onward routing between operators. + - +-------------+----------------------------------------------------+ - + Switzerland + Uses OR now and QoR in 2001. Routing prefix is + - + + "980xxx" where "xxx" identifies the recipient + - + + network. + - +-------------+----------------------------------------------------+ - + UK + Uses onward routing. Routing prefix is "5xxxxx" + - + + where "xxxxx" identifies the recipient switch. NOA + - + + is 126. BT uses the dropback scheme in some parts + - + + of its network. + - +-------------+----------------------------------------------------+ - + US + Uses ACQ. "Location Routing Number (LRN)" is used + - + + in the Called Party Number parameter. Called party+ - + + number is carried in the Generic Address Parameter + - + + Use a PNTI indicator in the Forward Call Indicator + - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 19] - -Number Portability in the GSTN: An Overview June 24, 2002 - - + + parameter to indicate that NPDB dip has been + - + + performed. + - +-------------+----------------------------------------------------+ - - -8. Number Conservation Methods Enabled by NP - - In addition to porting numbers NP provides the ability for number - administrators to assign numbering resources to operators in smaller - increments. Today it is common for numbering resources to be - assigned to telephone operators in a large block of consecutive - telephone numbers (TNs). For example, in North America each of - these blocks contains 10,000 TNs and is of the format NXX+0000 to - NXX+9999. Operators are assigned a specific NXX, or block. That - operator is referred to as the block holder. In that block there - are 10,000 TNs with line numbers ranging from 0000 to 9999. - - Instead of assigning an entire block to the operator NP allows the - administrator to assign a sub-block or even an individual telephone - number. This is referred to as block pooling and individual - telephone number (ITN) pooling, respectively. - - -8.1 Block Pooling - - Block Pooling refers to the process whereby the number administrator - assigns a range of numbers defined by a logical sub-block of the - existing block. Using North America as an example, block pooling - would allow the administrator to assign sub-blocks of 1,000 TNs to - multiple operators. That is, NXX+0000 to NXX+0999 can be assigned - to operator A, NXX+1000 to NXX+1999 can be assigned to operator B, - NXX-2000 to 2999 can be assigned to operator C, etc. In this - example block pooling divides one block of 10,000 TNs into ten - blocks of 1,000 TNs. - - Porting the sub-blocks from the block holder enables block pooling. - Using the example above operator A is the block holder, as well as, - the holder of the first sub-block, NXX+0000 to NXX+0999. The second - sub-block, NXX+1000 to NXX+1999, is ported from operator A to - operator B. The third sub-block, NXX+2000 to NXX+2999, is ported - from operator A to operator C, and so on. NP administrative - processes and call processing will enable proper and efficient - routing. - - From a number administration and NP administration perspective block - pooling introduces a new concept, that of the sub-block holder. - Block pooling requires coordination between the number - administrator, the NP administrator, the block holder, and the sub- - block holder. Block pooling must be implemented in a manner that - allows for NP within the sub-blocks. Each TN can have a different - serving operator, sub-block holder, and block holder. - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 20] - -Number Portability in the GSTN: An Overview June 24, 2002 - -8.2 ITN Pooling - - ITN pooling refers to the process whereby the number administrator - assigns individual telephone numbers to operators. Using the North - American example, one block of 10,000 TNs can be divided into 10,000 - ITNs. ITN is more commonly deployed in freephone services. - - In ITN the block is not assigned to an operator but to a central - administrator. The administrator then assigns ITNs to operators. - NP administrative processes and call processing will enable proper - and efficient routing. - - -9. Potential Implications - - There are three general areas of impact to IP telephony work-in- - progress at IETF: - - - Interoperation between NP in GSTN and IP telephony - - NP implementation or emulation in IP telephony - - Interconnection to NP administrative environment - - A good understanding of how number portability is supported in the - GSTN is important when addressing the interworking issues between - IP-based networks and the GSTN. This is especially important when - the IP-based network needs to route the calls to the GSTN. As shown - in Section 5, there are a variety of standards with various protocol - stacks for the switch-to-NPDB interface. Not only that, the - national variations of the protocol standards make it very - complicated to deal with in a global environment. If an entity in - the IP-based network needs to query those existing NPDBs for routing - number information to terminate the calls to the destination GSTN, - it would be impractical, if not an impossible, job for that entity - to support all those interface standards to access the NPDBs in many - countries. - - Several alternatives may address this particular problem. One - alternative is to use certain entities in the IP-based networks for - dealing with NP query, similar to the International Switches that - are used in the GSTN to interwork different national ISUP - variations. This will force signaling information associated with - the calls to certain NP-capable networks in the terminating GSTN to - be routed to those IP entities that support the NP functions. Those - IP entities then query the NPDBs in the terminating country. This - will limit the number of NPDB interfaces that certain IP entities - need to support. Another alternative can be to define a "common" - interface to be supported by all the NPDBs so that all the IP - entities use that standardized protocol to query them. The - existing NPDBs can support this additional interface, or new NPDBs - can be deployed that contain the same information but support the - common IP interface. The candidates for such a common interface - include Lightweight Directory Access Protocol (LDAP) and SIP - [SIP](e.g., using the SIP redirection capability). Certainly - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 21] - -Number Portability in the GSTN: An Overview June 24, 2002 - - another possibility is to use interworking function to convert from - one protocol to another. - - IP-based networks can handle the domestic calls between two GSTNs. - If the originating GSTN has performed NPDB query, SIP will need to - transport and make use of some of the ISUP signaling information - even if ISUP signaling may be encapsulated in SIP. Also, IP-based - networks may perform the NPDB queries, as the N-1 carrier. In that - case, SIP also needs to transport the NP related information while - the call is being routed to the destination GSTN. There are three - pieces of NP related information that SIP needs to transport. They - are 1) the called directory number, 2) a routing number, and 3) a - NPDB dip indicator. The NPDB dip indicator is needed so that the - terminating GSTN will not perform another NPDB dip. The routing - number is needed so that it is used to route the call to the - destination network or switch in the destination GSTN. The called - directory number is needed so that the terminating GSTN switch can - terminate the call. When the routing number is present, the NPDB - dip indicator may not be present because there are cases where - routing number is added for routing the call even if NP is not - involved. One issue is how to transport the NP related information - via SIP. The SIP Universal Resource Locator (URL) is one mechanism. - Another better choice may be to add an extension to the "tel" URL - [TEL] that is also supported by SIP. Please see [TELNP] for the - proposed extensions to the "tel" URL to support NP and freephone - service. Those extensions to the "tel" URL will be automatically - supported by SIP because they can be carried as the optional - parameters in the user portion of the "sip" URL. - - For a called directory number that belongs to a country that - supports NP, and if the IP-based network is to perform the NPDB - query, the logical step is to perform the NPDB dip first to retrieve - the routing number and use that routing number to select the correct - IP telephony gateways that can reach the serving switch that serves - the called directory number. Therefore, if the "rn" parameter is - present in the "tel" URL or sip URL in the SIP INVITE message, it - instead of the called directory number should be used for making - routing decisions assuming that no other higher priority routing- - related parameters such as the Ÿcic÷ are present. If "rn" is not - present, then the dialed directory number can be used as the routing - number for making routing decisions. - - Telephony Routing Information Protocol (TRIP) [TRIP] is a policy - driven inter-administrative domain protocol for advertising the - reachability of telephony destinations between location servers, and - for advertising attributes of the routes to those destinations. - With the NP in mind, it is very important to know that it is the - routing number, if present, not the called directory number that - should be used to check against the TRIP tables for making the - routing decisions. - - Overlap signaling exists in the GSTN today. For a call routing from - the originating GSTN to the IP-based network that involves overlap - signaling, NP will impact the call processing within the IP-based - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 22] - -Number Portability in the GSTN: An Overview June 24, 2002 - - networks if they must deal with the overlap signaling. The entities - in the IP-based networks that are to retrieve the NP information - (e.g., the routing number) must collect a complete called directory - number information before retrieving the NP information for a ported - number. Otherwise, the information retrieval won't be successful. - This is an issue for the IP-based networks if the originating GSTN - does not handle the overlap signaling by collecting the complete - called directory number. - - The IETF enum working group is defining the use of Domain Name - System (DNS) for identifying available services associated with a - particular E.164 number [ENUM]. [ENUMPO] outlines the principles - for the operation of a telephone number service that resolves - telephone numbers into Internet domain name addresses and service- - specific directory discovery. [ENUMPO] implements a three-level - approach where the first level is the mapping of the telephone - number delegation tree to the authority to which the number has been - delegated, the second level is the provision of the requested DNS - resource records from a service registrar, and the third level is - the provision of service specific data from the service provider - itself. NP certainly must be considered at the first level because - the telephony service providers do not "own" or control the - telephone numbers under the NP environment; therefore, they may not - be the proper entities to have the authority for a given E.164 - number. Not only that, there is a regulatory requirement on NP in - some countries that the donor network should not be relied on to - reach the delegated authority during the DNS process . The - delegated authority for a given E.164 number is likely to be an - entity designated by the end user that owns/controls a specific - telephone number or one that is designated by the service registrar. - - Since the telephony service providers may have the need to use ENUM - for their network-related services (e.g., map an E.164 number to a - HLR Identifier in the wireless networks), their ENUM records must be - collocated with those of the telephony subscribers. If that is the - case, NP will impact ENUM when a telephony subscriber who has ENUM - service changes the telephony service provider. This is because - that the ENUM records from the new telephony service provider must - replace those from the old telephony service provider. To avoid the - NP impact on ENUM, it is recommended that the telephony service - providers use a different domain tree for their network-related - service. For example, if e164.arpa is chosen for Ÿend user÷ ENUM, a - domain tree different from e164.arpa should be used for Ÿcarrier÷ - ENUM. - - The IP-based networks also may need to support some forms of number - portability in the future if E.164 numbers [E164] are assigned to - the IP-based end users. One method is to assign a GSTN routing - number for each IP-based network domain or entity in a NP-capable - country. This may increase the number of digits in the routing - number to incorporate the IP entities and impact the existing - routing in the GSTN. Another method is to associate each IP entity - with a particular GSTN gateway. At that particular GSTN gateway, - the called directory number then is used to locate the IP-entity - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 23] - -Number Portability in the GSTN: An Overview June 24, 2002 - - that serves that dialed directory number. Yet, another method can - be to assign a special routing number so that the call to an end - user currently served by an IP entity is routed to the nearest GSTN - gateway. The called directory number then is used to locate the IP- - entity that serves that dialed directory number. A mechanism can be - developed or used for the IP-based network to locate the IP entity - that serves a particular dialed directory number. Many other types - of networks use E.164 numbers to identify the end users or terminals - in those networks. Number portability among GSTN, IP-based network - and those various types of networks may also need to be supported in - the future. - - -10. Security Considerations - - This document does not raise any security issues. - - -11. IANA Considerations - - This document introduces no new values for IANA registration. - - -12. Normative References - - [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability - - Operator Services Switching Systems," April 1999. - - [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability - - Switching Systems," April 1999. - - [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability - Database and Global Title Translation," April 1999. - - [CS1] ITU-T Q-series Recommendations - Supplement 4, "Number - portability Capability set 1 requirements for service provider - portability (All call query and onward routing)," May 1998. - - [CS2] ITU-T Q-series Recommendations - Supplement 5, "Number - portability -Capability set 2 requirements for service provider - portability (Query on release and Dropback)," March 1999. - - [E164] ITU-T Recommendation E.164, "The International Public - Telecommunications Numbering Plan," 1997. - - [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. - - [ETSIISUP] ETSI EN 302 097 V.1.2.2, ŸIntegrated Services Digital - Network (ISDN); Signalling System No.7 (SS7); ISDN User Part - (ISUP); Enhancement for support of Number Portability (NP) - [ITU-T Recommendation Q.769.1 (2000), modified] - - [GSM] GSM 09.02: "Digital cellular telecommunications system (Phase - 2+); Mobile Application Part (MAP) specification". - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 24] - -Number Portability in the GSTN: An Overview March 1, 2002 - - - - [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for - Wireless Number Portability Phase II (December 1998)"Number - Portability Network Support," April 1998. - - [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 - - ISDN User Part Enhancements for the Support of Number - Portability," December 1999. - - [MNP] ETSI EN 301 716 (2000-10) European Standard - (Telecommunications series) Digital cellular telecommunications - system (Phase 2+); Support of Mobile Number Portability (MNP); - Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 - Release 1998). - - [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- - Revision 3," October 1996. - - -13. Informative References - - [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific - Provisioning: Principles of Operations," draft-ietf-enum- - operation-02.txt, February 23, 2001. - - [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP: - Session Initiation Protocol," February 27, 2002. - - [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis- - 04.txt, "URIs for Telephone Calls," May 24, 2002. - - [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL - to support Number Portability and Freephone Service," June 14, - 2002. - - [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony - Routing Information Protocol (TRIP)," January 2002. - - -14. Acknowledgment - - The authors would like to thank Monika Muench for providing - information on ISUP and MNP. - - -15. Authors' Addresses - - Mark D. Foster - NeuStar, Inc. - 1120 Vermont Avenue, NW, - Suite 400 - Washington, D.C. 20005 - United States - -Foster,McGarry,Yu Expired on August 31, 2002 [Page 25] - -Number Portability in the GSTN: An Overview March 1, 2002 - - - - Phone: +1-202-533-2800 - Fax: +1-202-533-2987 - Email: mark.foster@neustar.biz - - Tom McGarry - NeuStar, Inc. - 1120 Vermont Avenue, NW, - Suite 400 - Washington, D.C. 20005 - United States - - Phone: +1-202-533-2810 - Fax: +1-202-533-2987 - Email: tom.mcgarry@neustar.biz - - James Yu - NeuStar, Inc. - 1120 Vermont Avenue, NW, - Suite 400 - Washington, D.C. 20005 - United States - - Phone: +1-202-533-2814 - Fax: +1-202-533-2987 - Email: james.yu@neustar.biz - - - -Full Copyright Statement - - "Copyright (C) The Internet Society (2002). 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. - - - -Foster,McGarry,Yu Expired on August 31, 2002 [Page 26] - -Number Portability in the GSTN: An Overview March 1, 2002 - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Foster,McGarry,Yu Expired on August 31, 2002 [Page 27] - \ No newline at end of file diff --git a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt deleted file mode 100644 index 2d5c87eb3c..0000000000 --- a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt +++ /dev/null @@ -1,1200 +0,0 @@ - - - - - - -IPv6 Working Group John Loughney (ed) -Internet-Draft Nokia - January 14, 2004 - -Expires: July 14, 2004 - - - - IPv6 Node Requirements - draft-ietf-ipv6-node-requirements-08.txt - - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document defines requirements for IPv6 nodes. It is expected - that IPv6 will be deployed in a wide range of devices and situations. - Specifying the requirements for IPv6 nodes allows IPv6 to function - well and interoperate in a large number of situations and - deployments. - - - - - -Loughney (editor) February 16, 2004 [Page 1] - - - - - -Internet-Draft - - -Table of Contents - - 1. Introduction - 1.1 Requirement Language - 1.2 Scope of this Document - 1.3 Description of IPv6 Nodes - 2. Abbreviations Used in This Document - 3. Sub-IP Layer - 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 - 3.2 IP version 6 over PPP - RFC2472 - 3.3 IPv6 over ATM Networks - RFC2492 - 4. IP Layer - 4.1 Internet Protocol Version 6 - RFC2460 - 4.2 Neighbor Discovery for IPv6 - RFC2461 - 4.3 Path MTU Discovery & Packet Size - 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 - 4.5 Addressing - 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 - 5. Transport and DNS - 5.1 Transport Layer - 5.2 DNS - 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - 6. IPv4 Support and Transition - 6.1 Transition Mechanisms - 7. Mobility - 8. Security - 8.1 Basic Architecture - 8.2 Security Protocols - 8.3 Transforms and Algorithms - 8.4 Key Management Methods - 9. Router Functionality - 9.1 General - 10. Network Management - 10.1 MIBs - 11. Security Considerations - 12. References - 12.1 Normative - 12.2 Non-Normative - 13. Authors and Acknowledgements - 14. Editor's Address - Notices - - - - - - - - - - -Loughney (editor) February 16, 2004 [Page 2] - - - - - -Internet-Draft - - -1. Introduction - - The goal of this document is to define the common functionality - required from both IPv6 hosts and routers. Many IPv6 nodes will - implement optional or additional features, but all IPv6 nodes can be - expected to implement the mandatory requirements listed in this - document. - - This document tries to avoid discussion of protocol details, and - references RFCs for this purpose. In case of any conflicting text, - this document takes less precedence than the normative RFCs, unless - additional clarifying text is included in this document. - - Although the document points to different specifications, it should - be noted that in most cases, the granularity of requirements are - smaller than a single specification, as many specifications define - multiple, independent pieces, some of which may not be mandatory. - - As it is not always possible for an implementer to know the exact - usage of IPv6 in a node, an overriding requirement for IPv6 nodes is - that they should adhere to Jon Postel's Robustness Principle: - - Be conservative in what you do, be liberal in what you accept from - others [RFC-793]. - -1.1 Requirement Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC-2119]. - -1.2 Scope of this Document - - IPv6 covers many specifications. It is intended that IPv6 will be - deployed in many different situations and environments. Therefore, - it is important to develop the requirements for IPv6 nodes, in order - to ensure interoperability. - - This document assumes that all IPv6 nodes meet the minimum - requirements specified here. - -1.3 Description of IPv6 Nodes - - From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we - have the following definitions: - - Description of an IPv6 Node - - - - -Loughney (editor) February 16, 2004 [Page 3] - - - - - -Internet-Draft - - - - a device that implements IPv6 - - Description of an IPv6 router - - - a node that forwards IPv6 packets not explicitly addressed to - itself. - - Description of an IPv6 Host - - - any node that is not a router. - -2. Abbreviations Used in This Document - - ATM Asynchronous Transfer Mode - - AH Authentication Header - - DAD Duplicate Address Detection - - ESP Encapsulating Security Payload - - ICMP Internet Control Message Protocol - - IKE Internet Key Exchange - - MIB Management Information Base - - MLD Multicast Listener Discovery - - MTU Maximum Transfer Unit - - NA Neighbor Advertisement - - NBMA Non-Broadcast Multiple Access - - ND Neighbor Discovery - - NS Neighbor Solicitation - - NUD Neighbor Unreachability Detection - - PPP Point-to-Point Protocol - - PVC Permanent Virtual Circuit - - SVC Switched Virtual Circuit - -3. Sub-IP Layer - - - -Loughney (editor) February 16, 2004 [Page 4] - - - - - -Internet-Draft - - - An IPv6 node must include support for one or more IPv6 link-layer - specifications. Which link-layer specifications are included will - depend upon what link-layers are supported by the hardware available - on the system. It is possible for a conformant IPv6 node to support - IPv6 on some of its interfaces and not on others. - - As IPv6 is run over new layer 2 technologies, it is expected that new - specifications will be issued. This section highlights some major - layer 2 technologies and is not intended to be complete. - -3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 - - Nodes supporting IPv6 over Ethernet interfaces MUST implement - Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. - -3.2 IP version 6 over PPP - RFC2472 - - Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC- - 2472]. - -3.3 IPv6 over ATM Networks - RFC2492 - - Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM - Networks [RFC-2492]. Additionally, RFC 2492 states: - - A minimally conforming IPv6/ATM driver SHALL support the PVC mode - of operation. An IPv6/ATM driver that supports the full SVC mode - SHALL also support PVC mode of operation. - -4. IP Layer - -4.1 Internet Protocol Version 6 - RFC2460 - - The Internet Protocol Version 6 is specified in [RFC-2460]. This - specification MUST be supported. - - Unrecognized options in Hop-by-Hop Options or Destination Options - extensions MUST be processed as described in RFC 2460. - - The node MUST follow the packet transmission rules in RFC 2460. - - Nodes MUST always be able to send, receive and process fragment - headers. All conformant IPv6 implementations MUST be capable of - sending and receving IPv6 packets; forwarding functionality MAY be - supported - - RFC 2460 specifies extension headers and the processing for these - headers. - - - -Loughney (editor) February 16, 2004 [Page 5] - - - - - -Internet-Draft - - - A full implementation of IPv6 includes implementation of the - following extension headers: Hop-by-Hop Options, Routing (Type 0), - Fragment, Destination Options, Authentication and Encapsulating - Security Payload. [RFC-2460] - - An IPv6 node MUST be able to process these headers. It should be - noted that there is some discussion about the use of Routing Headers - and possible security threats [IPv6-RH] caused by them. - -4.2 Neighbor Discovery for IPv6 - RFC2461 - - Neighbor Discovery SHOULD be supported. RFC 2461 states: - - "Unless specified otherwise (in a document that covers operating - IP over a particular link type) this document applies to all link - types. However, because ND uses link-layer multicast for some of - its services, it is possible that on some link types (e.g., NBMA - links) alternative protocols or mechanisms to implement those - services will be specified (in the appropriate document covering - the operation of IP over a particular link type). The services - described in this document that are not directly dependent on - multicast, such as Redirects, Next-hop determination, Neighbor - Unreachability Detection, etc., are expected to be provided as - specified in this document. The details of how one uses ND on - NBMA links is an area for further study." - - Some detailed analysis of Neighbor Discovery follows: - - Router Discovery is how hosts locate routers that reside on an - attached link. Router Discovery MUST be supported for - implementations. - - Prefix Discovery is how hosts discover the set of address prefixes - that define which destinations are on-link for an attached link. - Prefix discovery MUST be supported for implementations. Neighbor - Unreachability Detection (NUD) MUST be supported for all paths - between hosts and neighboring nodes. It is not required for paths - between routers. However, when a node receives a unicast Neighbor - Solicitation (NS) message (that may be a NUD's NS), the node MUST - respond to it (i.e. send a unicast Neighbor Advertisement). - - Duplicate Address Detection MUST be supported on all links supporting - link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take - place on all unicast addresses). - - A host implementation MUST support sending Router Solicitations. - - Receiving and processing Router Advertisements MUST be supported for - - - -Loughney (editor) February 16, 2004 [Page 6] - - - - - -Internet-Draft - - - host implementations. The ability to understand specific Router - Advertisement options is dependent on supporting the specification - where the RA is specified. - - Sending and Receiving Neighbor Solicitation (NS) and Neighbor - Advertisement (NA) MUST be supported. NS and NA messages are required - for Duplicate Address Detection (DAD). - - Redirect functionality SHOULD be supported. If the node is a router, - Redirect functionality MUST be supported. - -4.3 Path MTU Discovery & Packet Size - -4.3.1 Path MTU Discovery - RFC1981 - - Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal - implementations MAY choose to not support it and avoid large packets. - The rules in RFC 2460 MUST be followed for packet fragmentation and - reassembly. - -4.3.2 IPv6 Jumbograms - RFC2675 - - IPv6 Jumbograms [RFC-2675] MAY be supported. - -4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 - - ICMPv6 [RFC-2463] MUST be supported. - -4.5 Addressing - -4.5.1 IP Version 6 Addressing Architecture - RFC3513 - - The IPv6 Addressing Architecture [RFC-3513] MUST be supported. - -4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 - - IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. - This specification MUST be supported for nodes that are hosts. - - Nodes that are routers MUST be able to generate link local addresses - as described in RFC 2462 [RFC-2462]. - - From 2462: - - The autoconfiguration process specified in this document applies - only to hosts and not routers. Since host autoconfiguration uses - information advertised by routers, routers will need to be - configured by some other means. However, it is expected that - - - -Loughney (editor) February 16, 2004 [Page 7] - - - - - -Internet-Draft - - - routers will generate link-local addresses using the mechanism - described in this document. In addition, routers are expected to - successfully pass the Duplicate Address Detection procedure - described in this document on all addresses prior to assigning - them to an interface. - - Duplicate Address Detection (DAD) MUST be supported. - -4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 - - Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] - SHOULD be supported. It is recommended that this behavior be - configurable on a connection basis within each application when - available. It is noted that a number of applications do not work - with addresses generated with this method, while other applications - work quite well with them. - -4.5.4 Default Address Selection for IPv6 - RFC3484 - - The rules specified in the Default Address Selection for IPv6 [RFC- - 3484] document MUST be implemented. It is expected that IPv6 nodes - will need to deal with multiple addresses. - -4.5.5 Stateful Address Autoconfiguration - - Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- - 3315] is the standard stateful address configuration protocol; see - section 5.3 for DHCPv6 support. - - Nodes which do not support Stateful Address Autoconfiguration may be - unable to obtain any IPv6 addresses aside from link-local addresses - when it receives a router advertisement with the 'M' flag (Managed - address configuration) set and which contains no prefixes advertised - for Stateless Address Autoconfiguration (see section 4.5.2). - Additionally, such nodes will be unable to obtain other configuration - information such as the addresses of DNS servers when it is connected - to a link over which the node receives a router advertisement in - which the 'O' flag ("Other stateful configuration") is set. - -4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 - - Nodes that need to join multicast groups SHOULD implement MLDv2 - [MLDv2]. However, if the node has applications, which only need - support for Any- Source Multicast [RFC3569], the node MAY implement - MLDv1 [MLDv1] instead. If the node has applications, which need - support for Source- Specific Multicast [RFC3569, SSMARCH], the node - MUST support MLDv2 [MLDv2]. - - - - -Loughney (editor) February 16, 2004 [Page 8] - - - - - -Internet-Draft - - - When MLD is used, the rules in "Source Address Selection for the - Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be - followed. - -5. Transport Layer and DNS - -5.1 Transport Layer - -5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 - - This specification MUST be supported if jumbograms are implemented - [RFC- 2675]. - -5.2 DNS - - DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] - and [RFC-3596] MAY be supported. Not all nodes will need to resolve - names. All nodes that need to resolve names SHOULD implement stub- - resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with - support for: - - - AAAA type Resource Records [RFC-3596]; - - reverse addressing in ip6.arpa using PTR records [RFC-3152]; - - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 - octets. - - Those nodes are RECOMMENDED to support DNS security extentions - [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT]. - - Those nodes are NOT RECOMMENDED to support the experimental A6 and - DNAME Resource Records [RFC-3363]. - -5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 - - RFC 2732 MUST be supported if applications on the node use URL's. - -5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 - -5.3.1 Managed Address Configuration - - Those IPv6 Nodes that use DHCP for address assignment initiate DHCP - to obtain IPv6 addresses and other configuration information upon - receipt of a Router Advertisement with the 'M' flag set, as described - in section 5.5.3 of RFC 2462. In addition, in the absence of a - router, those IPv6 Nodes that use DHCP for address assignment MUST - initiate DHCP to obtain IPv6 addresses and other configuration - information, as described in section 5.5.2 of RFC 2462. Those IPv6 - nodes that do not use DHCP for address assignment can ignore the 'M' - - - -Loughney (editor) February 16, 2004 [Page 9] - - - - - -Internet-Draft - - - flag in Router Advertisements. - -5.3.2 Other Configuration Information - - Those IPv6 Nodes that use DHCP to obtain other configuration - information initiate DHCP for other configuration information upon - receipt of a Router Advertisement with the 'O' flag set, as described - in section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP - for other configuration information can ignore the 'O' flag in Router - Advertisements. - - An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to - obtain other configuration information. - -6. IPv4 Support and Transition - - IPv6 nodes MAY support IPv4. - -6.1 Transition Mechanisms - -6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 - - If an IPv6 node implements dual stack and tunneling, then RFC2893 - MUST be supported. - - RFC 2893 is currently being updated. - -7. Mobile IP - - The Mobile IPv6 [MIPv6] specification defines requirements for the - following types of nodes: - - - mobile nodes - - correspondent nodes with support for route optimization - - home agents - - all IPv6 routers - - Hosts MAY support mobile node functionality described in Section 8.5 - of [MIPv6], including support of generic packet tunneling [RFC-2473] - and secure home agent communications [MIPv6-HASEC]. - - Hosts SHOULD support route optimization requirements for - correspondent nodes described in Section 8.2 of [MIPv6]. - - Routers SHOULD support the generic mobility-related requirements for - all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY - support the home agent functionality described in Section 8.4 of - [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC]. - - - -Loughney (editor) February 16, 2004 [Page 10] - - - - - -Internet-Draft - - -8. Security - - This section describes the specification of IPsec for the IPv6 node. - -8.1 Basic Architecture - - Security Architecture for the Internet Protocol [RFC-2401] MUST be - supported. RFC-2401 is being updated by the IPsec Working Group. - -8.2 Security Protocols - - ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. - RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group. - - -8.3 Transforms and Algorithms - - Current IPsec RFCs specify the support of certain transforms and - algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. - The requirements for these are discussed first, and then additional - algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed. - - NULL encryption algorithm [RFC-2410] MUST be supported for providing - integrity service and also for debugging use. - - The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD - NOT be supported. Security issues related to the use of DES are - discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as - required by the existing IPsec RFCs, but as it is currently viewed as - an inherently weak algorithm, and no longer fulfills its intended - role. - - The NULL authentication algorithm [RFC-2406] MUST be supported within - ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC- - 2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP, - described in [RFC-2403] MUST be supported. An implementer MUST refer - to Keyed- Hashing for Message Authentication [RFC-2104]. - - 3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC - and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES- - CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected - to be a widely available, secure algorithm that is required for - interoperability. It is not required by the current IPsec RFCs, but - is expected to become required in the future. - - In addition to the above requirements, "Cryptographic Algorithm - Implementation Requirements For ESP And AH" [CRYPTREQ] contains the - current set of mandatory to implement algorithms for ESP and AH as - - - -Loughney (editor) February 16, 2004 [Page 11] - - - - - -Internet-Draft - - - well as specifying algorithms that should be implemented because they - may be promoted to mandatory at some future time. It is RECOMMENDED - that IPv6 nodes conform to the requirements in this document. - -8.4 Key Management Methods - - Manual keying MUST be supported. - - IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast - traffic. Where key refresh, anti-replay features of AH and ESP, or - on- demand creation of Security Associations (SAs) is required, - automated keying MUST be supported. Note that the IPsec WG is working - on the successor to IKE [IKE2]. Key management methods for multicast - traffic are also being worked on by the MSEC WG. - - "Cryptographic Algorithms for use in the Internet Key Exchange - Version 2" [IKEv2ALGO] defines the current set of mandatory to - implement algorithms for use of IKEv2 as well as specifying - algorithms that should be implemented because they made be promoted - to mandatory at some future time. It is RECOMMENDED that IPv6 nodes - implementing IKEv2 conform to the requirements in this - document. - -9. Router-Specific Functionality - - This section defines general host considerations for IPv6 nodes that - act as routers. Currently, this section does not discuss routing- - specific requirements. - -9.1 General - -9.1.1 IPv6 Router Alert Option - RFC2711 - - - The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- - Hop Header that is used in conjunction with some protocols (e.g., - RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will - need to be implemented whenever protocols that mandate its usage are - implemented. See Section 4.6. - -9.1.2 Neighbor Discovery for IPv6 - RFC2461 - - Sending Router Advertisements and processing Router Solicitation MUST - be supported. - -10. Network Management - - Network Management MAY be supported by IPv6 nodes. However, for IPv6 - - - -Loughney (editor) February 16, 2004 [Page 12] - - - - - -Internet-Draft - - - nodes that are embedded devices, network management may be the only - possibility to control these nodes. - -10.1 Management Information Base Modules (MIBs) - - The following two MIBs SHOULD be supported by nodes that support an - SNMP agent. - -10.1.1 IP Forwarding Table MIB - - IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes - that support an SNMP agent. - -10.1.2 Management Information Base for the Internet Protocol (IP) - - IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an - SNMP agent. - -11. Security Considerations - - This draft does not affect the security of the Internet, but - implementations of IPv6 are expected to support a minimum set of - security features to ensure security on the Internet. "IP Security - Document Roadmap" [RFC-2411] is important for everyone to read. - - The security considerations in RFC2460 describe the following: - - The security features of IPv6 are described in the Security - Architecture for the Internet Protocol [RFC-2401]. - -12. References - -12.1 Normative - - [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa- - tion Requirements For ESP And AH", draft-ietf-ipsec- - esp-ah-algorithms-01.txt, January 2004. - - [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the - Internet Key Exchange Version 2", draft-ietf-ipsec- - ikev2-algorithms-04.txt, Work in Progress. - - [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6 - Service", draft- ietf-dhc-dhcpv6-stateless-00.txt, - Work in Progress. - - [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Support - in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in - - - -Loughney (editor) February 16, 2004 [Page 13] - - - - - -Internet-Draft - - - progress. - - [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec - to Protect Mobile IPv6 Signaling between Mobile Nodes - and Home Agents", draft-ietf- mobileip-mipv6-ha- - ipsec-06.txt, Work in Progress. - - [MLDv2] Vida, R. et al., "Multicast Listener Discovery Version - 2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in - Progress. - - [RFC-1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU - Discovery for IP version 6", RFC 1981, August 1996. - - [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table - MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in - Progress. - - [RFC-2011BIS] Routhier, S (ed), "Management Information Base for the - Internet Protocol (IP)", draft-ietf-ipv6-rfc2011- - update-07.txt, Work in progress. - - [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: - Keyed-Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for - the Internet Protocol", RFC 2401, November 1998. - - [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication - Header", RFC 2402, November 1998. - - [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 within - ESP and AH", RFC 2403, November 1998. - - [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 - within ESP and AH", RFC 2404, November 1998. - - [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher - Algorithm With Explicit IV", RFC 2405, November 1998. - - [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security - - - -Loughney (editor) February 16, 2004 [Page 14] - - - - - -Internet-Draft - - - Protocol (ESP)", RFC 2406, November 1998. - - [RFC-2407] Piper, D., "The Internet IP Security Domain of - Interpretation for ISAKMP", RFC 2407, November 1998. - - [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and Turner, - J., "Internet Security Association and Key Management - Protocol (ISAKMP)", RFC 2408, November 1998. - - [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key - Exchange (IKE)", RFC 2409, November 1998. - - [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm - and Its Use With IPsec", RFC 2410, November 1998. - - [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher - Algorithms", RFC 2451, November 1998. - - [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver- - sion 6 (IPv6) Specification", RFC 2460, December 1998. - - [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor - Discovery for IP Version 6 (IPv6)", RFC 2461, December - 1998. - - [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address - Autoconfiguration", RFC 2462. - - [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet Pro- - tocol Version 6 (IPv6)", RFC 2463, December 1998. - - [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC - 2472, December 1998. - - [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling - in IPv6 Specification", RFC 2473, December 1998. Xxx - add - - [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast - Listener Discovery (MLD) for IPv6", RFC 2710, October - 1999. - - [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert - Option", RFC 2711, October 1999. - - - - -Loughney (editor) February 16, 2004 [Page 15] - - - - - -Internet-Draft - - - [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC - 3041, January 2001. - - [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August - 2001. - - [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Protocol - for IPv6 (DHCPv6)", RFC 3315, July 2003. - - [RFC-3363] Bush, R., et al., "Representing Internet Protocol ver- - sion 6 (IPv6) Addresses in the Domain Name System - (DNS)", RFC 3363, August 2002. - - [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC - 3484, February 2003. - - [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing - Architecture", RFC 3513, April 2003. - - [RFC-3590] Haberman, B., "Source Address Selection for the Multi- - cast Listener Discovery (MLD) Protocol", RFC 3590, - September 2003. - - [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP - version 6", RFC 3596, October 2003. - - [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use - with IPsec", RFC 3602, September 2003. - -12.2 Non-Normative - - [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast", - draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in - Progress. - - [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of - DES-like cryptosystems", Journal of Cryptology Vol 4, Jan - 1991. - - [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000. - - [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without - Strong Integrity", Proceedings of the 32nd IETF, Danvers, - MA, April 1995. - - [DHCPv6-SL] Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser- - vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in - - - -Loughney (editor) February 16, 2004 [Page 16] - - - - - -Internet-Draft - - - Progress. - - [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, - S., "DNS Security Introduction and Requirements" draft- - ietf-dnsext-dnssec-intro- 06.txt, Work in Progress. - - [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, - S., "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro- - gress. - - [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, - S., "Protocol Modifications for the DNS Security Exten- - sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work - in Progress. - - [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto- - col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress. - - [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home - Address Options", draft-savola-ipv6-rh-ha-security- - 03.txt, Work in Progress, March 2002. - - [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu- - rity Threats and Counter-Measures; In Proceedings "Sympo- - sium on Network and Distributed System Security", Febru- - ary 1995, pp.2-16. - - [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793, - August 1980. - - [RFC-1034] Mockapetris, P., "Domain names - concepts and facili- - ties", RFC 1034, November 1987. - - [RFC-2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, - May 1997. - - [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and - S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC - 2205, September 1997. - - [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet - Networks", RFC 2462, December 1998. - - [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over - ATM Networks", RFC 2492, January 1999. - - [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6 - - - -Loughney (editor) February 16, 2004 [Page 17] - - - - - -Internet-Draft - - - Jumbograms", RFC 2675, August 1999. - - [RFC-2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal - IPv6 Addresses in URL's", RFC 2732, December 1999. - - [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder, - "Textual Conventions for Internet Network Addresses", RFC - 2851, June 2000. - - [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms for - IPv6 Hosts and Routers", RFC 2893, August 2000. - - [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific - Multicast (SSM)", RFC 3569, July 2003. - - [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", - draft-ietf- ssm-arch-03.txt, Work in Progress. - -13. Authors and Acknowledgements - - This document was written by the IPv6 Node Requirements design team: - - Jari Arkko - [jari.arkko@ericsson.com] - - Marc Blanchet - [marc.blanchet@viagenie.qc.ca] - - Samita Chakrabarti - [samita.chakrabarti@eng.sun.com] - - Alain Durand - [alain.durand@sun.com] - - Gerard Gastaud - [gerard.gastaud@alcatel.fr] - - Jun-ichiro itojun Hagino - [itojun@iijlab.net] - - Atsushi Inoue - [inoue@isl.rdc.toshiba.co.jp] - - Masahiro Ishiyama - [masahiro@isl.rdc.toshiba.co.jp] - - John Loughney - [john.loughney@nokia.com] - - - -Loughney (editor) February 16, 2004 [Page 18] - - - - - -Internet-Draft - - - Rajiv Raghunarayan - [raraghun@cisco.com] - - Shoichi Sakane - [shouichi.sakane@jp.yokogawa.com] - - Dave Thaler - [dthaler@windows.microsoft.com] - - Juha Wiljakka - [juha.wiljakka@Nokia.com] - - The authors would like to thank Ran Atkinson, Jim Bound, Brian Car- - penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, - Juha Ollila and Pekka Savola for their comments. - -14. Editor's Contact Information - - Comments or questions regarding this document should be sent to the - IPv6 Working Group mailing list (ipv6@ietf.org) or to: - - John Loughney - Nokia Research Center - Itamerenkatu 11-13 - 00180 Helsinki - Finland - - Phone: +358 50 483 6242 - Email: John.Loughney@Nokia.com - -Notices - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to per- - tain to the implementation or use of the technology described in this - document or the extent to which any license under such rights might - or might not be available; neither does it represent that it has made - any effort to identify any such rights. Information on the IETF's - procedures with respect to rights in standards-track and standards- - related documentation can be found in BCP-11. Copies of claims of - rights made available for publication and any assurances of licenses - to be made available, or the result of an attempt made to obtain a - general license or permission for the use of such proprietary rights - by implementors or users of this specification can be obtained from - the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - - - -Loughney (editor) February 16, 2004 [Page 19] - - - - - -Internet-Draft - - - rights, which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Loughney (editor) February 16, 2004 [Page 20] - - diff --git a/doc/draft/draft-ietf-secsh-dns-05.txt b/doc/draft/draft-ietf-secsh-dns-05.txt deleted file mode 100644 index a272d81b0a..0000000000 --- a/doc/draft/draft-ietf-secsh-dns-05.txt +++ /dev/null @@ -1,614 +0,0 @@ -Secure Shell Working Group J. Schlyter -Internet-Draft OpenSSH -Expires: March 5, 2004 W. Griffin - SPARTA - September 5, 2003 - - - Using DNS to Securely Publish SSH Key Fingerprints - draft-ietf-secsh-dns-05.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on March 5, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document describes a method to verify SSH host keys using - DNSSEC. The document defines a new DNS resource record that contains - a standard SSH key fingerprint. - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 1] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 - 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 - 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 - 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 - 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 5 - 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5 - 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 - 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6 - 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 - Normative References . . . . . . . . . . . . . . . . . . . . 8 - Informational References . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 - A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - Intellectual Property and Copyright Statements . . . . . . . 10 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 2] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -1. Introduction - - The SSH [6] protocol provides secure remote login and other secure - network services over an insecure network. The security of the - connection relies on the server authenticating itself to the client - as well as the user authenticating itself to the server. - - If a connection is established to a server whose public key is not - already known to the client, a fingerprint of the key is presented to - the user for verification. If the user decides that the fingerprint - is correct and accepts the key, the key is saved locally and used for - verification for all following connections. While some - security-conscious users verify the fingerprint out-of-band before - accepting the key, many users blindly accept the presented key. - - The method described here can provide out-of-band verification by - looking up a fingerprint of the server public key in the DNS [1][2] - and using DNSSEC [5] to verify the lookup. - - In order to distribute the fingerprint using DNS, this document - defines a new DNS resource record, "SSHFP", to carry the fingerprint. - - Basic understanding of the DNS system [1][2] and the DNS security - extensions [5] is assumed by 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 [3]. - -2. SSH Host Key Verification - -2.1 Method - - Upon connection to a SSH server, the SSH client MAY look up the SSHFP - resource record(s) for the host it is connecting to. If the - algorithm and fingerprint of the key received from the SSH server - match the algorithm and fingerprint of one of the SSHFP resource - record(s) returned from DNS, the client MAY accept the identity of - the server. - -2.2 Implementation Notes - - Client implementors SHOULD provide a configurable policy used to - select the order of methods used to verify a host key. This document - defines one method: Fingerprint storage in DNS. Another method - defined in the SSH Architecture [6] uses local files to store keys - for comparison. Other methods that could be defined in the future - might include storing fingerprints in LDAP or other databases. A - - - -Schlyter & Griffin Expires March 5, 2004 [Page 3] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - configurable policy will allow administrators to determine which - methods they want to use and in what order the methods should be - prioritized. This will allow administrators to determine how much - trust they want to place in the different methods. - - One specific scenario for having a configurable policy is where - clients do not use fully qualified host names to connect to servers. - In this scenario, the implementation SHOULD verify the host key - against a local database before verifying the key via the fingerprint - returned from DNS. This would help prevent an attacker from injecting - a DNS search path into the local resolver and forcing the client to - connect to a different host. - -2.3 Fingerprint Matching - - The public key and the SSHFP resource record are matched together by - comparing algorithm number and fingerprint. - - The public key algorithm and the SSHFP algorithm number MUST - match. - - A message digest of the public key, using the message digest - algorithm specified in the SSHFP fingerprint type, MUST match the - SSHFP fingerprint. - - -2.4 Authentication - - A public key verified using this method MUST NOT be trusted if the - SSHFP resource record (RR) used for verification was not - authenticated by a trusted SIG RR. - - Clients that do validate the DNSSEC signatures themselves SHOULD use - standard DNSSEC validation procedures. - - Clients that do not validate the DNSSEC signatures themselves MUST - use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8], - between themselves and the entity performing the signature - validation. - -3. The SSHFP Resource Record - - The SSHFP resource record (RR) is used to store a fingerprint of a - SSH public host key that is associated with a Domain Name System - (DNS) name. - - The RR type code for the SSHFP RR is TBA. - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 4] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -3.1 The SSHFP RDATA Format - - The RDATA for a SSHFP RR consists of an algorithm number, fingerprint - type and the fingerprint of the public host key. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | algorithm | fp type | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / - / / - / fingerprint / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -3.1.1 Algorithm Number Specification - - This algorithm number octet describes the algorithm of the public - key. The following values are assigned: - - Value Algorithm name - ----- -------------- - 0 reserved - 1 RSA - 2 DSS - - Reserving other types requires IETF consensus [4]. - -3.1.2 Fingerprint Type Specification - - The fingerprint type octet describes the message-digest algorithm - used to calculate the fingerprint of the public key. The following - values are assigned: - - Value Fingerprint type - ----- ---------------- - 0 reserved - 1 SHA-1 - - Reserving other types requires IETF consensus [4]. - - For interoperability reasons, as few fingerprint types as possible - should be reserved. The only reason to reserve additional types is - to increase security. - -3.1.3 Fingerprint - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 5] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - The fingerprint is calculated over the public key blob as described - in [7]. - - The message-digest algorithm is presumed to produce an opaque octet - string output which is placed as-is in the RDATA fingerprint field. - -3.2 Presentation Format of the SSHFP RR - - The RDATA of the presentation format of the SSHFP resource record - consists of two numbers (algorithm and fingerprint type) followed by - the fingerprint itself presented in hex, e.g: - - host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 - - The use of mnemonics instead of numbers is not allowed. - -4. Security Considerations - - Currently, the amount of trust a user can realistically place in a - server key is proportional to the amount of attention paid to - verifying that the public key presented actually corresponds to the - private key of the server. If a user accepts a key without verifying - the fingerprint with something learned through a secured channel, the - connection is vulnerable to a man-in-the-middle attack. - - The overall security of using SSHFP for SSH host key verification is - dependent on the security policies of the SSH host administrator and - DNS zone administrator (in transferring the fingerprint), detailed - aspects of how verification is done in the SSH implementation, and in - the client's diligence in accessing the DNS in a secure manner. - - One such aspect is in which order fingerprints are looked up (e.g. - first checking local file and then SSHFP). We note that in addition - to protecting the first-time transfer of host keys, SSHFP can - optionally be used for stronger host key protection. - - If SSHFP is checked first, new SSH host keys may be distributed by - replacing the corresponding SSHFP in DNS. - - If SSH host key verification can be configured to require SSHFP, - SSH host key revocation can be implemented by removing the - corresponding SSHFP from DNS. - - As stated in Section 2.2, we recommend that SSH implementors provide - a policy mechanism to control the order of methods used for host key - verification. One specific scenario for having a configurable policy - is where clients use unqualified host names to connect to servers. In - this case, we recommend that SSH implementations check the host key - - - -Schlyter & Griffin Expires March 5, 2004 [Page 6] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - against a local database before verifying the key via the fingerprint - returned from DNS. This would help prevent an attacker from injecting - a DNS search path into the local resolver and forcing the client to - connect to a different host. - - A different approach to solve the DNS search path issue would be for - clients to use a trusted DNS search path, i.e., one not acquired - through DHCP or other autoconfiguration mechanisms. Since there is no - way with current DNS lookup APIs to tell whether a search path is - from a trusted source, the entire client system would need to be - configured with this trusted DNS search path. - - Another dependency is on the implementation of DNSSEC itself. As - stated in Section 2.4, we mandate the use of secure methods for - lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This - is especially important if SSHFP is to be used as a basis for host - key rollover and/or revocation, as described above. - - Since DNSSEC only protects the integrity of the host key fingerprint - after it is signed by the DNS zone administrator, the fingerprint - must be transferred securely from the SSH host administrator to the - DNS zone administrator. This could be done manually between the - administrators or automatically using secure DNS dynamic update [11] - between the SSH server and the nameserver. We note that this is no - different from other key enrollment situations, e.g. a client sending - a certificate request to a certificate authority for signing. - -5. IANA Considerations - - IANA needs to allocate a RR type code for SSHFP from the standard RR - type space (type 44 requested). - - IANA needs to open a new registry for the SSHFP RR type for public - key algorithms. Defined types are: - - 0 is reserved - 1 is RSA - 2 is DSA - - Adding new reservations requires IETF consensus [4]. - - IANA needs to open a new registry for the SSHFP RR type for - fingerprint types. Defined types are: - - 0 is reserved - 1 is SHA-1 - - Adding new reservations requires IETF consensus [4]. - - - -Schlyter & Griffin Expires March 5, 2004 [Page 7] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Normative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [5] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. - Lehtinen, "SSH Protocol Architecture", - draft-ietf-secsh-architecture-14 (work in progress), July 2003. - - [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. - Lehtinen, "SSH Transport Layer Protocol", - draft-ietf-secsh-transport-16 (work in progress), July 2003. - -Informational References - - [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document - Roadmap", RFC 2411, November 1998. - - [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - [10] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 8] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Authors' Addresses - - Jakob Schlyter - OpenSSH - 812 23rd Avenue SE - Calgary, Alberta T2G 1N8 - Canada - - EMail: jakob@openssh.com - URI: http://www.openssh.com/ - - - Wesley Griffin - SPARTA - 7075 Samuel Morse Drive - Columbia, MD 21046 - USA - - EMail: wgriffin@sparta.com - URI: http://www.sparta.com/ - -Appendix A. Acknowledgements - - The authors gratefully acknowledge, in no particular order, the - contributions of the following persons: - - Martin Fredriksson - - Olafur Gudmundsson - - Edward Lewis - - Bill Sommerfeld - - - - - - - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 9] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). 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 assignees. - - 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 - - - -Schlyter & Griffin Expires March 5, 2004 [Page 10] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 11] - diff --git a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt deleted file mode 100644 index 3578d2a15e..0000000000 --- a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt +++ /dev/null @@ -1,519 +0,0 @@ - -Internet Draft Johan Ihren -draft-ihren-dnsext-threshold-validation-00.txt Autonomica -February 2003 -Expires in six months - - - Threshold Validation: - - A Mechanism for Improved Trust and Redundancy for DNSSEC Keys - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - -Abstract - - This memo documents a proposal for a different method of validation - for DNSSEC aware resolvers. The key change is that by changing from - a model of one Key Signing Key, KSK, at a time to multiple KSKs it - will be possible to increase the aggregated trust in the signed - keys by leveraging from the trust associated with the different - signees. - - By having multiple keys to chose from validating resolvers get the - opportunity to use local policy to reflect actual trust in - different keys. For instance, it is possible to trust a single, - particular key ultimately, while requiring multiple valid - signatures by less trusted keys for validation to succeed. - Furthermore, with multiple KSKs there are additional redundancy - benefits available since it is possible to roll over different KSKs - at different times which may make rollover scenarios easier to - manage. - -Contents - - 1. Terminology - 2. Introduction and Background - - 3. Trust in DNSSEC Keys - 3.1. Key Management, Split Keys and Trust Models - 3.2. Trust Expansion: Authentication versus Authorization - - 4. Proposed Semantics for Signing the KEY Resource Record - Set - 4.1. Packet Size Considerations - - 5. Proposed Use of Multiple "Trusted Keys" in a Validating - Resolver - 5.1. Not All Possible KSKs Need to Be Trusted - 5.2. Possible to do Threshold Validation - 5.3. Not All Trusted Keys Will Be Available - - 6. Additional Benefits from Having Multiple KSKs - 6.1. More Robust Key Rollovers - 6.2. Evaluation of Multiple Key Distribution Mechanisms - - 7. Security Considerations - 8. IANA Considerations. - 9. References - 9.1. Normative. - 9.2. Informative. - 10. Acknowledgments. - 11. Authors' Address - - -1. Terminology - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", - and "MAY" in this document are to be interpreted as described in - RFC 2119. - - The term "zone" refers to the unit of administrative control in the - Domain Name System. "Name server" denotes a DNS name server that is - authoritative (i.e. knows all there is to know) for a DNS zone, - typically the root zone. A "resolver", is a DNS "client", i.e. an - entity that sends DNS queries to authoritative nameservers and - interpret the results. A "validating resolver" is a resolver that - attempts to perform DNSSEC validation on data it retrieves by doing - DNS lookups. - - -2. Introduction and Background - - From a protocol perspective there is no real difference between - different keys in DNSSEC. They are all just keys. However, in - actual use there is lots of difference. First and foremost, most - DNSSEC keys have in-band verification. I.e. the keys are signed by - some other key, and this other key is in its turn also signed by - yet another key. This way a "chain of trust" is created. Such - chains have to end in what is referred to as a "trusted key" for - validation of DNS lookups to be possible. - - A "trusted key" is a the public part of a key that the resolver - acquired by some other means than by looking it up in DNS. The - trusted key has to be explicitly configured. - - A node in the DNS hierarchy that issues such out-of-band "trusted - keys" is called a "security apex" and the trusted key for that apex - is the ultimate source of trust for all DNS lookups within that - entire subtree. - - DNSSEC is designed to be able to work with more than on security - apex. These apexes will all share the problem of how to distribute - their "trusted keys" in a way that provides validating resolvers - confidence in the distributed keys. - - Maximizing that confidence is crucial to the usefulness of DNSSEC - and this document tries to address this issue. - - -3. Trust in DNSSEC Keys - - In the end the trust that a validating resolver will be able to put - in a key that it cannot validate within DNSSEC will have to be a - function of - - * trust in the key issuer, aka the KSK holder - - * trust in the distribution method - - * trust in extra, out-of-band verification - - The KSK holder needs to be trusted not to accidentally lose private - keys in public places. Furthermore it needs to be trusted to - perform correct identification of the ZSK holders in case they are - separate from the KSK holder itself. - - The distribution mechanism can be more or less tamper-proof. If the - key holder publishes the public key, or perhaps just a secure - fingerprint of the key in a major newspaper it may be rather - difficult to tamper with. A key acquired that way may be easier to - trust than if it had just been downloaded from a web page. - - Out-of-band verification can for instance be the key being signed - by a certificate issued by a known Certificate Authority that the - resolver has reason to trust. - -3.1. Simplicity vs Trust - - The fewer keys that are in use the simpler the key management - becomes. Therefore increasing the number of keys should only be - considered when the complexity is not the major concern. A perfect - example of this is the distinction between so called Key Signing - Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds - overall complexity but simplifies real life operations and was an - overall gain since operational simplification was considered to be - a more crucial issue than the added complexity. - - In the case of a security apex there are additional issues to - consider, among them - - * maximizing trust in the KSK received out-of-band - - * authenticating the legitimacy of the ZSKs used - - In some cases this will be easy, since the same entity will manage - both ZSKs and KSKs (i.e. it will authenticate itself, somewhat - similar to a self-signed certificate). In some environments it will - be possible to get the trusted key installed in the resolver end by - decree (this would seem to be a likely method within corporate and - government environments). - - In other cases, however, this will possibly not be sufficient. In - the case of the root zone this is obvious, but there may well be - other cases. - -3.2. Expanding the "Trust Base" - - For a security apex where the ZSKs and KSK are not held by the same - entity the KSK will effectively authenticate the identity of - whoever does real operational zone signing. The amount of trust - that the data signed by a ZSK will get is directly dependent on - whether the end resolver trusts the KSK or not, since the resolver - has no OOB access to the public part of the ZSKs (for practical - reasons). - - Since the KSK holder is distinct from the ZSK holder the obvious - question is whether it would then be possible to further improve - the situation by using multiple KSK holders and thereby expanding - the trust base to the union of that available to each individual - KSK holder. "Trust base" is an invented term intended to signify - the aggregate of Internet resolvers that will eventually choose to - trust a key issued by a particular KSK holder. - - A crucial issue when considering trust expansion through addition - of multiple KSK holders is that the KSK holders are only used to - authenticate the ZSKs used for signing the zone. I.e. the function - performed by the KSK is basically: - - "This is indeed the official ZSK holder for this zone, - I've verified this fact to the best of my abilitites." - - Which can be thought of as similar to the service of a public - notary. I.e. the point with adding more KSK holders is to improve - the public trust in data signed by the ZSK holders by improving the - strength of available authentication. - - Therefore adding more KSK holders, each with their own trust base, - is by definition a good thing. More authentication is not - controversial. On the contrary, when it comes to authentication, - the more the merrier. - - -4. Proposed Semantics for Signing the KEY Resource Record Set - - In DNSSEC according to RFC2535 all KEY Resource Records are used to - sign all authoritative data in the zone, including the KEY RRset - itself, since RFC2535 makes no distinction between Key Signing - Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS] - it is possible to change this to the KEY RRset being signed with - all KSKs and ZSKs but the rest of the zone only being signed by the - ZSKs. - - This proposal changes this one step further, by recommending that - the KEY RRset is only signed by the Key Signing Keys, KSK, and - explicitly not by the Zone Signing Keys, ZSK. The reason for this - is to maximize the amount of space in the DNS response packet that - is available for additional KSKs and signatures thereof. The rest - of the authoritative zone contents are as previously signed by only - the ZSKs. - -4.1. Packet Size Considerations - - The reason for the change is to keep down the size of the aggregate - of KEY RRset plus SIG(KEY) that resolvers will need to acquire to - perform validation of data below a security apex. For DNSSEC data - to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be - set, and therefore the allowed packet size can be assumed to be at - least the EDNS0 minimum of 4000 bytes. - - When querying for KEY + SIG(KEY) for "." (the case that is assumed - to be most crucial) the size of the response packet after the - change to only sign the KEY RR with the KSKs break down into a - rather large space of possibilities. Here are a few examples for - the possible alternatives for different numbers of KSKs and ZSKs - for some different key lengths (all RSA keys, with a public - exponent that is < 254). This is all based upon the size of the - response for the particular example of querying for - - ". KEY IN" - - with a response of entire KEY + SIG(KEY) with the authority and - additional sections empty: - - ZSK/768 and KSK/1024 (real small) - Max 12 KSK + 3 ZSK at 3975 - 10 KSK + 8 ZSK at 3934 - 8 KSK + 13 ZSK at 3893 - - ZSK/768 + KSK/1280 - MAX 10 KSK + 2 ZSK at 3913 - 8 KSK + 9 ZSK at 3970 - 6 KSK + 15 ZSK at 3914 - - ZSK/768 + KSK/1536 - MAX 8 KSK + 4 ZSK at 3917 - 7 KSK + 8 ZSK at 3938 - 6 KSK + 12 ZSK at 3959 - - ZSK/768 + KSK/2048 - MAX 6 KSK + 5 ZSK at 3936 - 5 KSK + 10 ZSK at 3942 - - ZSK/1024 + KSK/1024 - MAX 12 KSK + 2 ZSK at 3943 - 11 KSK + 4 ZSK at 3930 - 10 KSK + 6 ZSK at 3917 - 8 KSK + 10 ZSK at 3891 - - ZSK/1024 + KSK/1536 - MAX 8 KSK + 3 ZSK at 3900 - 7 KSK + 6 ZSK at 3904 - 6 KSK + 9 ZSK at 3908 - - ZSK/1024 + KSK/2048 - MAX 6 KSK + 4 ZSK at 3951 - 5 KSK + 8 ZSK at 3972 - 4 KSK + 12 ZSK at 3993 - - Note that these are just examples and this document is not making - any recommendations on suitable choices of either key lengths nor - number of different keys employed at a security apex. - - This document does however, based upon the above figures, make the - recommendation that at a security apex that expects to distribute - "trusted keys" the KEY RRset should only be signed with the KSKs - and not with the ZSKs to keep the size of the response packets - down. - - -5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver - - In DNSSEC according to RFC2535[RFC2535] validation is the process - of tracing a chain of signatures (and keys) upwards through the DNS - hierarchy until a "trusted key" is reached. If there is a known - trusted key present at a security apex above the starting point - validation becomes an exercise with a binary outcome: either the - validation succeeds or it fails. No intermediate states are - possible. - - With multiple "trusted keys" (i.e. the KEY RRset for the security - apex signed by multiple KSKs) this changes into a more complicated - space of alternatives. From the perspective of complexity that may - be regarded as a change for the worse. However, from a perspective - of maximizing available trust the multiple KSKs add value to the - system. - -5.1. Possible to do Threshold Validation - - With multiple KSKs a new option that opens for the security - concious resolver is to not trust a key individually. Instead the - resolver may decide to require the validated signatures to exceed a - threshold. For instance, given M trusted keys it is possible for - the resolver to require N-of-M signatures to treat the data as - validated. - - I.e. with the following pseudo-configuration in a validating - resolver - - security-apex "." IN { - keys { ksk-1 .... ; - ksk-2 .... ; - ksk-3 .... ; - ksk-4 .... ; - ksk-5 .... ; - }; - validation { - # Note that ksk-4 is not present below - keys { ksk-1; ksk-2; ksk-3; ksk-5; }; - # 3 signatures needed with 4 possible keys, aka 75% - needed-signatures 3; - }; - }; - - we configure five trusted keys for the root zone, but require two - valid signatures for the top-most KEY for validation to - succeed. I.e. threshold validation does not force multiple - signatures on the entire signature chain, only on the top-most - signature, closest to the security apex for which the resolver has - trusted keys. - -5.2. Not All Trusted Keys Will Be Available - - With multiple KSKs held and managed by separate entities the end - resolvers will not always manage to get access to all possible - trusted keys. In the case of just a single KSK this would be fatal - to validation and necessary to avoid at whatever cost. But with - several fully trusted keys available the resolver can decide to - trust several of them individually. An example based upon more - pseudo-configuration: - - security-apex "." IN { - keys { ksk-1 .... ; - ksk-2 .... ; - ksk-3 .... ; - ksk-4 .... ; - ksk-5 .... ; - }; - validation { - # Only these two keys are trusted independently - keys { ksk-1; ksk-4; }; - # With these keys a single signature is sufficient - needed-signatures 1; - }; - }; - - Here we have the same five keys and instruct the validating - resolver to fully trust data that ends up with just one signature - from by a fully trusted key. - - The typical case where this will be useful is for the case where - there is a risk of the resolver not catching a rollover event by - one of the KSKs. By doing rollovers of different KSKs with - different schedules it is possible for a resolver to "survive" - missing a rollover without validation breaking. This improves - overall robustness from a management point of view. - -5.3. Not All Possible KSKs Need to Be Trusted - - With just one key available it simply has to be trusted, since that - is the only option available. With multiple KSKs the validating - resolver immediately get the option of implementing a local policy - of only trusting some of the possible keys. - - This local policy can be implemented either by simply not - configuring keys that are not trusted or, possibly, configure them - but specify to the resolver that certain keys are not to be - ultimately trusted alone. - - -6. Additional Benefits from Having Multiple KSKs - -6.1. More Robust Key Rollovers - - With only one KSK the rollover operation will be a delicate - operation since the new trusted key needs to reach every validating - resolver before the old key is retired. For this reason it is - expected that long periods of overlap will be needed. - - With multiple KSKs this changes into a system where different - "series" of KSKs can have different rollover schedules, thereby - changing from one "big" rollover to several "smaller" rollovers. - - If the resolver trusts several of the available keys individually - then even a failure to track a certain rollover operation within - the overlap period will not be fatal to validation since the other - available trusted keys will be sufficient. - -6.2. Evaluation of Multiple Key Distribution Mechanisms - - Distribution of the trusted keys for the DNS root zone is - recognized to be a difficult problem that ... - - With only one trusted key, from one single "source" to distribute - it will be difficult to evaluate what distribution mechanism works - best. With multiple KSKs, held by separate entitites it will be - possible to measure how large fraction of the resolver population - that is trusting what subsets of KSKs. - - -7. Security Considerations - - From a systems perspective the simplest design is arguably the - best, i.e. one single holder of both KSK and ZSKs. However, if that - is not possible in all cases a more complex scheme is needed where - additional trust is injected by using multiple KSK holders, each - contributing trust, then there are only two alternatives - available. The first is so called "split keys", where a single key - is split up among KSK holders, each contributing trust. The second - is the multiple KSK design outlined in this proposal. - - Both these alternatives provide for threshold mechanisms. However - split keys makes the threshold integral to the key generating - mechanism (i.e. it will be a property of the keys how many - signatures are needed). In the case of multiple KSKs the threshold - validation is not a property of the keys but rather local policy in - the validating resolver. A benefit from this is that it is possible - for different resolvers to use different trust policies. Some may - configure threshold validation requiring multiple signatures and - specific keys (optimizing for security) while others may choose to - accept a single signature from a larger set of keys (optimizing for - redundancy). Since the security requirements are different it would - seem to be a good idea to make this choice local policy rather than - global policy. - - Furthermore, a clear issue for validating resolvers will be how to - ensure that they track all rollover events for keys they - trust. Even with operlap during the rollover (which is clearly - needed) there is still a need to be exceedingly careful not to miss - any rollovers (or fail to acquire a new key) since without this - single key validation will fail. With multiple KSKs this operation - becomes more robust, since different KSKs may roll at different - times according to different rollover schedules and losing one key, - for whatever reason, will not be crucial unless the resolver - intentionally chooses to be completely dependent on that exact key. - -8. IANA Considerations. - - NONE. - - -9. References - -9.1. Normative. - - [RFC2535] Domain Name System Security Extensions. D. Eastlake. - March 1999. - - [RFC3090] DNS Security Extension Clarification on Zone Status. - E. Lewis. March 2001. - - -9.2. Informative. - - [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System - (DNS). D. Eastlake 3rd. May 2001. - - [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. - December 2001. - - [DS] Delegation Signer Resource Record. - O. Gudmundsson. October 2002. Work In Progress. - -10. Acknowledgments. - - Bill Manning came up with the original idea of moving complexity - from the signing side down to the resolver in the form of threshold - validation. I've also had much appreciated help from (in no - particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and - Olaf Kolkman. - - -11. Authors' Address -Johan Ihren -Autonomica AB -Bellmansgatan 30 -SE-118 47 Stockholm, Sweden -johani@autonomica.se diff --git a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt deleted file mode 100644 index f9eaf26819..0000000000 --- a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt +++ /dev/null @@ -1,1830 +0,0 @@ - - - - INTERNET-DRAFT S. Daniel Park - Expires: October 2003 Syam Madanapalli - File: SAMSUNG Electronics - draft-park-ipv6-extensions-dns-pnp-00.txt April 2003 - - - - - IPv6 Extensions for DNS Plug and Play - - - - Status of This Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - - Abstract - - This document proposes automatic configuration of domain name (FQDN) - for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as - a part of IPv6 plug and play feature. 6DNAC allows the automatic - registration of domain name and corresponding IPv6 Addresses with - the DNS server. In order to provide 6DNAC function, Neighbor Discovery - Protocol [2461] will be used. Moreover, 6DNAC does not require any - changes to the existing DNS system. - - - Table of Contents - - 1. Introduction ............................................. 3 - 2. Terminology .............................................. 3 - 3. 6DNAC Design Principles .................................. 4 - 4. 6DNAC Overview ........................................... 4 - 5. 6DNAC Requirements ....................................... 5 - 5.1. 6DANR Client Requirements ................................ 5 - 5.2. 6DNAC Server Requirements ................................ 6 - -Park & Madanapalli Expires October 2003 [Page 1] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 6. 6DNAC Messages and Option Formats ........................ 6 - 6.1. Router Advertisement (RA) Message Format ................. 6 - 6.2. Neighbor Solicitation (NS) Message Format ................ 7 - 6.3. Neighbor Advertisement (NA) Message Format ............... 8 - 6.4. Option Formats ........................................... 8 - 6.4.1. DNS Zone Suffix Information Option Format ................ 8 - 6.4.2. Domain Name (FQDN) Option Format ......................... 9 - 6.4.3. Router Alert Option for 6DNAC ............................ 10 - 7. 6DNAC Operation .......................................... 10 - 7.1. 6DNAC Network Topology ................................... 11 - 7.2. 6DNAC Operational Scenarios .............................. 12 - 7.2.1. Domain Name Registration-Success Case .................... 12 - 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2.... 14 - 7.2.3. Domain Name Registration-Defend Case ..................... 16 - 7.2.4. Domain Name Registration in Retry Mode ................... 19 - 7.2.5. Domain Name Registration when DAD Fails .................. 20 - 7.3. DNS Zone Suffix Discovery and FQDN Construction .......... 22 - 7.3.1. Sending Router Advertisement Messages .................... 22 - 7.3.2. Processing Router Advertisement Messages ................. 22 - 7.3.3. FQDN Lifetime expiry ..................................... 23 - 7.3.4. Host Naming Algorithm .................................... 23 - 7.4. Duplicate Domain Name Detection .......................... 23 - 7.4.1. DAD with All Nodes Multicast Address ..................... 24 - 7.4.1.1. Sending Neighbor Solicitation Messages ................... 24 - 7.4.1.2. Processing Neighbor Solicitation Messages ................ 24 - 7.4.1.3. Sending Neighbor Advertisement Messages .................. 25 - 7.4.1.4. Processing Neighbor Advertisement Messages ............... 25 - 7.4.1.5. Pros and Cons ............................................ 25 - 7.4.2. DAD with Router Alert Option for 6DNAC ................... 25 - 7.4.2.1. Sending Neighbor Solicitation Messages ................... 25 - 7.4.2.2. Processing Neighbor Solicitation Messages ................ 26 - 7.4.2.3. Sending Neighbor Advertisement Messages .................. 26 - 7.4.2.4. Processing Neighbor Advertisement Messages ............... 26 - 7.4.2.5. Pros and Cons ............................................ 26 - 7.4.3. Explicit Detection of Duplicate Domain Name .............. 26 - 7.4.3.1. Sending Neighbor Solicitation Messages ................... 26 - 7.4.3.2. Processing Neighbor Solicitation Messages ................ 26 - 7.4.3.3. Sending Neighbor Advertisement Messages .................. 27 - 7.4.3.4. Processing Neighbor Advertisement Messages ............... 27 - 7.4.3.5. Pros and Cons ............................................ 27 - 7.4.4. Retry Mode for Re-registering Domain Name ................ 27 - 7.5. Domain Name Registration ................................. 27 - 8. Security Consideration ................................... 27 - 9. IANA Consideration ....................................... 28 - 10. Acknowledgement .......................................... 28 - 11. Intellectual Property .................................... 28 - 12. Copyright ................................................ 28 - 13. References ............................................... 29 - 14. Author's Addresses ....................................... 30 - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 2] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 1. Introduction - - Today, most networks use DNS[1034][1035] for convenience. In case of - IPv6, DNS is more important element because of IPv6 long addresses - which are difficult to remember. In addition, small networks like home - networks using IPv6, should be able to make network easily without - manual configuration. Also, these small networks may not have DHCP - Server, DNS Server etc. that are used to configure the network. This - document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure - for generating and registering the Domain Name and IPv6 addresses with - the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are - required to implement lightweight functions specified in this document. - 6DNAC can be applied to all defined IPv6 unicast addresses except Link - local IPv6 addresses, viz: Site-local and Global addresses. - - 6DNAC uses Neighbor Discovery Protocol [2461] with new additions - (defined in section 6) and DAD procedures for generating and - registering the Domain Name with the DNS server automatically. - - - 2. Terminology - - 6DNAC - IPv6 Domain Name Auto Configuration. It can provide - IPv6 hosts with Domain Name Generation and - Registration automatically. - - 6DNAC Client - An IPv6 node that can generate its own unique Domain - Name. Section 3 identifies the new requirements that - 6DNAC places on an IPv6 node to be a 6DNAC node. - - 6DNAC Server - An IPv6 node that can collect and registrate Domain - Name and IPv6 addresses automatically. 6DNAC server - uses the information from the DAD operation messages - with newly defined options for the registration of the - Domain Name and IPv6 Addresses. Section 3 identifies - the new requirements that 6DNAC places on an IPv6 - node to be a 6DNAC server. Also 6DNAC server can have - various other functions depending on network - environment and the network operator. For instance - 6DNAC Server can acts as a Gateway as well Home Server - in Home Networks. - - DAD - Duplicate Address Detection (is defined [2461]) - - DFQDND - Duplicate Domain Name Detection - - FQDN - Fully Qualified Domain Name - FQDN and Domain Name are - used interchangeably in this document. - - NA - Neighbor Advertisement message (is defined [2461]) - - NS - Neighbor Solicitation message (is defined [2461]) - - RA - Router Advertisement message (is defined [2461]) - - SLAAC - Stateless Address Autoconfiguration [2462]. - -Park & Madanapalli Expires October 2003 [Page 3] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 3. 6DNAC Design Principles - - This section discusses the design principles of 6DNAC mechanism. - - 1. The new procedures for plug and play DNS should not cause changes - to existing DNS system. 6DNAC requires lightweight functions to be - implemented only at the client side of the DNS system, and uses the - existing DDNS UPDATE [2136] to communicate with DNS Servers. - - 2. Introducing a new protocol will always introduce new problems. - 6DNAC uses the existing protocols NDP [2461] with minor extensions - for generating and registering the domain name automatically - without defining a new protocol - - 3. Reusing proven and well understood design principles/patterns - will always yield a robust system. 6DNAC is based on IPv6 Address - Auotoconfiguration principle, where routers advertise the prefix - and host adds the interface ID to the prefix and forms the IPv6 - address. Domain Name (FQDN) also contains two parts: host name - and DNS zone suffix. Routers can advertise the DNS zone suffix - on a particular link in Router Advertisements (RA Messages) and - hosts can prefix their preferred host name to the DNS zone suffix - and form the fully qualified domain name. Also the detection of - duplicate domain name is similar to Duplicate Address Detection - (DAD) and can be part of DAD operation itself. - - - 4. 6DNAC Overview - - 6DNAC proposes minor extensions to NDP [2461] for automatic generation - and registration of domain name with the DNS server. It introduces two - new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone - Suffix option is carried in Router Advertisement (RA) messages for - notifying IPv6 nodes about the valid DNS Zone Suffix on the link and - FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement - (NA) messages to detect duplicate domain name. 6DNAC consists of two - components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the - domain name based on DNS Zone Suffix using Host Naming Algorithm (see - section 7.3.1) and 6DNAC Server collects and registers the DNS - information with the DNS Server on behalf of 6DNAC Clients. - - The automatic configuration of domain name using 6DNAC consists of - three parts. - - - DNS Zone Suffix Discovery and FQDN Construction: - - IPv6 Nodes collect DNS Zone Suffix information from Router - Advertisements and constructs FQDN by prefixing host name to the - DNS Zone Suffix. The IPv6 Nodes are required to implement Host - Naming Algorithm for generating host part of the FQDN in the - absence of administrator. - - Generation of node's FQDN within the node itself has advantages. Nodes - can provide forward and reverse name lookups independent of the DNS - System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain - Name is some thing that is owned by the node. - -Park & Madanapalli Expires October 2003 [Page 4] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - Duplicate Domain Name Detection - - All nodes are expected to go for DAD for all new IPv6 unicast - addresses, regardless of whether they are obtained through - stateful, stateless or manual configuration. 6DNAC uses the DAD - messages with new option for carrying the Domain Name along with - the new IPv6 Address. 6DNAC Server captures this information and - updates DNS Server provided that the IPv6 Address and its domain - name are not duplicate. If the domain name is already in use, - the 6DNAC server replies to the sender with FQDN Option in NA - message indicating that the domain name is duplicate. Then the - node is expected to generate another domain name using host - naming algorithm and go for DAD. This time the DAD is only for - duplicate domain name detection (DFQDND). In order to avoid - confusion with the normal NDP processing, the target address - field of the NS message must carry the unspecified address - in retry mode. This can be repeated depending on number of - retries defined by the administrator in the host naming algorithm. - - - - Domain Name Registration - - 6DNAC Server detects the DNS information (IPv6 Address and - corresponding FQDN) from DAD/DFQDND messages and updates DNS - Server using existing protocol DDNS UPDATE [2136] provided that - the IPv6 Address and its domain name are not duplicate. - - If an IPv6 Address is duplicate, the IPv6 node cannot perform - stateless address autoconfiguration repeatedly. Unlike IPv6 stateless - address autoconfiguration, 6DNAC allows the automatic configuration of - domain name repeatedly if the domain name is duplicate depending on - number of retries defined by the administrator in the host naming - algorithm. - - - 5. 6DNAC Requirements - - Depending on the 6DNAC functionality, the IPv6 nodes implement, they - are called either 6DNAC Clients or 6DNAC Servers. The following - sections lists the requirements that the 6DNAC Client and 6DNAC server - must support. - - - 5.1. 6DANC Client Requirements - - - 6DNAC Client must recognize and process the following NDP - extensions - - - DNS Zone Suffix option in RA messages for generating its - domain name (FQDN). - - - Domain Name option in NS and NA messages for detecting - the duplicate domain name - - - - -Park & Madanapalli Expires October 2003 [Page 5] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - It must generate its domain name (FQDN) based on the DNS - suffix that it got from the router advertisement. And it must - have a host naming algorithm for generating the host part of - the FQDN. - - - If NA message is received with unspecified target address and - FQDN option, then the node must treat that the domain is - duplicate. - - - 5.2. 6DNAC Server Requirements - - - 6DNAC Server must recognize and process the following NDP - extensions - - - If the 6DNAC Server is a router on the link, then it - must advertise DNS Zone Suffix option in RA messages - for hosts to generate their domain name (FQDN). - - - FQDN option in NS messages for detecting new DNS - information for of nodes on the link for which it - must update the AAAA RR and PTR RR in DNS Server. - - - FQDN option in NA messages for notifying duplicate - domain name with unspecified target address. - - - 6DNAC server must update the DNS Server (both AAAA RR and - PTR RR) dynamically using DDNS UPDATE [2136]. - - - 6DNAC server must cache this (newly detected) FQDN, Link - Layer Address, and IPv6 Address information, so that it can - decide whether it really needs to update DNS Server or not, - to avoid redundant updates. This information will also be - used for notifying the duplicate domain name. - - - 6. 6DNAC Messages and Option Formats - - In order to achieve the plug and play DNS, 6DNAC proposes new - extensions to the NDP [2461]. This section specifies the new - additions to NDP messages and formats of new options. - - - 6.1. Router Advertisement (RA) Message Format - - Routers send out Router Advertisement (RA) message periodically, or - in response to a Router Solicitation. 6DNAC does not modify the format - of the RA message, but proposes new option (DNS Zone Suffix Information) - to be carried in RA messages. - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 6] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Code | Checksum | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Cur Hop Limit |M|O| Reserved | Router Lifetime | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reachable Time | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Retrans Timer | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Options ... | - / / - | DNS Zone Suffix Information | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - 6.2. Neighbor Solicitation (NS) Message Format - - 6DNAC does not modify the format of the Neighbor Solicitation (NS) - message, but proposes new option (FQDN Option) to be carried in NS - messages. When a node is going for DAD, the node must include FQDN - option in NS message to participate in plug and play DNS. If the - node is going for Explicit Detection of Duplicate Domain Name, the - node must use FQDN option in NS message and unspecified address in - the target address field. - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Code | Checksum | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Target Address + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Options ... | - / / - | Domain Name | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - -Park & Madanapalli Expires October 2003 [Page 7] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 6.3. Neighbor Advertisement (NA) Message Format - - 6DNAC does not modify the format of the Neighbor Advertisement (NA) - message, but proposes new option (FQDN Option) to be carried in NA - messages. 6DNAC Server sends NA message with FQDN option to 6DNAC - Client that is performing duplicate domain name detection in case - the domain name found to be duplicate. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Code | Checksum | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |R|S|O| Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Target Address + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Options ... | - / / - | FQDN Option | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - 6.4 Option Formats - - 6.4.1. DNS Zone Suffix Information Option Format - - IPv6 nodes require DNS Zone Suffix for constructing their FQDN. - 6DNAC introduces new option for routers to advertise the DNS Zone - Suffix Information for IPv6 nodes on the link. The suffix information - should be configured into routers manually. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Valid Lifetime | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - / DNS Zone Suffix / - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - -Park & Madanapalli Expires October 2003 [Page 8] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - Type [TBD] - - Length 8-bit unsigned integer. The length of the option - (including the type and length fields) in units of - 8 octets. - - Reserved This field is unused. It must be initialized to zero - by the sender and must be ignored by the receiver. - - Valid Life Time 32-bit signed integer. The maximum time, in - seconds, over which this suffix is valid. Nodes - should treat this as the life time for their domain - name. Nodes should contact the source of this - information before expiry of this time interval. - A value of all one bits (0xFFFFFFFF) represents - infinity. - - DNS Zone Suffix The suffix part of the FQDN. The data in the DNS - Zone Suffix field should be encoded according to - DNS encoding rules specified in [1035]. - - - - 6.4.2. Domain Name (FQDN) Option Format - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Valid Lifetime | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + FQDN Target Address + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - / Domain Name / - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - Type [TBD] - - Length 8-bit unsigned integer. The length of the option - (including the type and length fields) in units - of 8 octets. It must be greater than 3. - - - -Park & Madanapalli Expires October 2003 [Page 9] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - Reserved This field is unused. It must be initialized to - zero by the sender and must be ignored by the - receiver. - - Valid Life Time 32-bit signed integer. The maximum time, in - seconds, over which this domain name is valid - 6DNAC should deregister this domain name at - the expiry of this interval. 6DNAC clients - should send updates by the expiry of this - interval. A value of all one bits (0xFFFFFFFF) - represents infinity. - - FQDN Target Address The Address for which the FQDN maps to. It - should be same as Target Address field of the - NS message in case of DAD & duplicate FQDN are - running in parallel. - - Domain Name The domain name (FQDN) of the node. The data in - the domain name should be encoded according to - DNS encoding rules specified in [1035]. - - - 6.4.3. Router Alert Option for 6DNAC - - Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop - Header for using in NDP messages. The presence of this option in NS - message informs the router that this NS message is carrying Domain - Name information and must be processed by the 6DNAC Server on the router. - 6DNAC Clients can use this option for sending DAD packets instead - of addressing the DAD packets to the all-nodes multicast address - when 6DNAC Server is implemented on router. - - The Router Alert option has the following format: - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Length = 2 - - Values are registered and maintained by the IANA. For 6DNAC, the - value has to be assigned by IANA. - - Further information about this option can be obtained from - IPv6 Router Alert Option [2711]. - - - 7. 6DNAC Operation - - 6DNAC provides mechanisms for automatic generation of domain name - and registering it with the DNS Server for IPv6 nodes. 6DNAC consists - of two components: 6DNAC Client and 6DNAC Server. All nodes that want - to participate in plug and play DNS are required to implement 6DNAC - Client functionality, and one of the IPv6 nodes is required to - implement 6DNAC Server functionality. The IPv6 node that implements - the 6DNAC Server functionality must know the location of the DNS - Server and must be a trusted node to send DDNS UPDATE [2136] messages. - -Park & Madanapalli Expires October 2003 [Page 10] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 7.1. 6DNAC Network Topology - - This section identifies the possible locations for the 6DNAC Server. - Note that, all nodes are required to implement 6DNAC Client - functionality for constructing the domain name from the DNS Zone - Suffix Information advertised by the router. Figure 6 illustrates - IPv6 host (H4) implementing 6DNAC Server functionality. In this case - H4 can serve only one link (that it belongs to) for automatic - registration of domain name. H4 must observe the DAD packets on the - link to detect the DNS information, this requires all nodes on the - link must belong to same solicited node multicast address. In general, - this may not be the case. So the node that is going for DAD must use - all nodes multicast address for DAD packets, so that the 6DNAC Server - (H4) can observe the DAD packets, detects IPv6 address and - corresponding domain name, checks if this domain name is duplicate - and finally registers the domain name with the DNS Server. - - - 6DNAC Server - +---+ +---+ +----------+ - | H1| | H4|<--- DDNS UPDATE --->|DNS Server| - +-+-+ +-+-+ +----+-----+ - | | +----+ +---/ - | | | | / - ---+-----+-----------+-----+-----------+ R1 +-----+ - | | | | - | | +----+ - +-+-+ +-+-+ - | H2| | H3| - +---+ +---+ - - - H1, H2, H3 - 6DNAC Clients - H4 - 6DNAC Server - R1 - Router - - - - - - Figure 7 shows the 6DNAC Server implemented on a router R1. In this - case a single 6DNAC server can serve multiple links for automatic - configuration of the domain name. This topology also has flexibility - of using DAD packets with Router Alert option instead of sending DAD - packets to all nodes multicast address. The routers are required to - process all the packets with Router Alert option as per [2711]. - - In case of Home Networks, R1 is will acts as a Home Gateway (CPE) - connected to ISP. R1 delegates the prefix from the ISP edge router. - After delegating the prefix the CPE can advertise the DNS Zone suffix - along with the prefix information to the nodes on the links to which - the router is connected to. Note that the R1 must be configured with - the DNS Zone suffix Information manually. - - - - -Park & Madanapalli Expires October 2003 [Page 11] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---+ +---+ - | H3+ | H4| - +-+-+ +-+-+ - | | - | LINK2 | - +---+ ---+--------+--+-- +----------+ - | H1| | |DNS Server| - +-+-+ | +----+-----+ - | +--+-+ -------/ - | LINK 1 | | / - ---+-----+------------------+ R1 +---------+ - | | | DDNS UPDATE - | +----+ - +-+-+ 6DNAC Server - | H2| - +---+ - - - H1, H2 - 6DNAC Clients on Link1 - H3, H4 - 6DNAC Clients on Link2 - R1 - Router with 6DNAC Server, serving both Link1 and Link2 - - - - - - 7.2. 6DNAC Operational Scenarios - - This section provides message sequence charts for various 6DNAC - operational scenarios assuming that the 6DNAC Server is implemented - on a router. All the scenarios assume that the normal boot up time - stateless address autoconfiguration of Link Local address derived - from the Interface Identifier has been completed successfully. And - it is also assumed that the router is already configured with the - DNS Zone Suffix Information. - - - Legend: - - 6DNAC-A, B, C : 6DNAC Clients - 6DNAC-S : 6DNAC Server/Router - DAD : Duplicate Address Detection - DFQDND : Duplicate Domain Name Detection - DNS-S : DNS Server - - - 7.2.1. Domain Name Registration-Successful Case - - This scenario starts when a 6DNAC Client receives RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and wants configure its IPv6 address (Global - or Site Local) and domain name. It is Assumed that the - DupAddrDetectTransmits is set to 1. - - - - -Park & Madanapalli Expires October 2003 [Page 12] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---------+ +---------+ +---------+ - | 6DNAC-C | | 6DNAC-S | | DNS-S | - +----+----+ +----+----+ +----+----+ - | | | - | RA with | | - | DNS Suffix Opt | | - |<---------------| | - | #1 | | - |---+ | | - Construct |#2 | | - FQDN | | | - |<--+ | | -DAD/DFQDND Starts | | - | | | - | | | - | NS With | | - | FQDN Opt | | - |--------------->| | - | #3 | | - | | | - | |------+ | - | Create FQDN | #4 | - | | | - | |<-----+ | - | | | - | | Register FQDN | - | |--------------->| - | | #5 | - | #6 | | - |--------+ | | - No Response | | | - DFQDND-Success | | | - |<-------+ | | - | | | - | | | - v V v - - - - - - #1. 6DNAC Server (Router) sends out router advertisement with DNS - Suffix information along with other parameters as specified in - NDP [2461]. - - #2. 6DNAC Client processes the router advertisement and constructs - the FQDN by prefixing hostname to the DNS Zone Suffix. It also - constructs IPv6 address from the autoconfiguration prefix - information option. - - #3. 6DNAC Client starts duplicate address & FQDN detection for the - IPv6 address & FQDN constructed and sends out a Neighbor - Solicitation message with FQDN option. - - Note that the DAD packets must be addressed to all nodes multicast - address if Router Alert option is not used. - -Park & Madanapalli Expires October 2003 [Page 13] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #4. 6DNAC Server processes the Neighbor Solicitation message sent by - 6DNAC Client as part of duplicate FQDN detection procedure and - creates a FQDN entry in its FQDN Cache (assuming that there is no - entry ), where C is Link Layer Address of the 6DNAC Client. - - #5. 6DNAC Server then registers FQDN and corresponding IPv6 address - through the existing protocol DDNS UPDATE. - - #6. 6DNAC Client times out and observes that there is no response to - defend its duplicate FQDN detection procedure and the node is - successful in configuring its domain name. - - Note that, Stateless Address Autoconfiguration DAD procedure is not - depicted in the following message sequence chart, which simultaneously - happens along with duplicate FQDN detection. - - - 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2 - - This scenario starts when a 6DNAC Client receives RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and wants configure its IPv6 address (Global - or Site Local) and domain name. The node is configured with - DupAddrDetectTransmits = 2 for reliability in delivering DAD messages. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 14] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---------+ +---------+ +---------+ - | 6DNAC-C | | 6DNAC-S | | DNS-S | - +----+----+ +----+----+ +----+----+ - | | | - | RA with | | - | DNS Suffix Opt | | - |<---------------| | - | #1 | | - |---+ | | - Construct |#2 | | - FQDN | | | - |<--+ | | -DAD/DFQDND Starts | | - | | | - | | | - | NS With | | - | FQDN Opt | | - |--------------->| | - | #3 | | - | | | - | |------+ | - | Create FQDN | #4 | - | | | - | |<-----+ | - | | | - | | Register FQDN | - | |--------------->| - | | #5 | - | NS With | | - | FQDN Opt | | - |--------------->| | - | #6 | | - | | | - | Lookup FQDN | - | Entry exists | - | |------+ | - | Ignore | #7 | - | |<-----+ | - | #8 | | - |--------+ | | - No Response | | | - DFQDND-Success | | | - |<-------+ | | - | | | - | | | - v V v - - - - - - - Steps from #1 to #5 are same as that of scenario.7.2.1. - - #6. 6DNAC Client sends out second Neighbor Solicitation message with - FQDN option as part of duplicate FQDN detection. - -Park & Madanapalli Expires October 2003 [Page 15] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #7. 6DNAC Server receives and observes that the FQDN Cache exactly - matches with that of the NS information and ignores the NS message. - - #8. 6DNAC Client times out and observes that there is no response to - defend its duplicate FQDN detection procedure and the node is - successful in configuring its domain name.. - - - 7.2.3. Domain Name Registration-Defend Case - - This scenario starts when two 6DNAC Client receive RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and both the nodes want configure their IPv6 - address (Global or Site Local) and domain name. In this scenario both - the nodes want to have same domain name. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 16] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - - +---------+ +---------+ +---------+ +---------+ - | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | - +----+----+ +----+----+ +----+----+ +----+----+ - | | | | - | RA with | RA with | | - | DNS Suffix Opt | DNS Suffix Opt | | - |<---------------|--------------->| | - | #1 | #1 | | - |---+ | |---+ | - Construct | #2 | Construct | #2 | - FQDN | | FQDN | | - |<--+ | |<--+ | - DAD/DFQDND Starts | DAD/DFQDND Starts | - | | | - | | | | - | NS with | | | - | FQDN Opt | | | - |--------------->| | | - | #3 | | | - | No Entry | | - | |------+ | | - | Create FQDN | #4 | | - | | | | - | |<-----+ | | - | | | | - | | Register FQDN #5 | - | |-------------------------------->| - | | | | - | | NS with | | - | | FQDN Opt | | - | |<---------------| | - | | #6 | | - | |------+ | | - | FQDN is in use| | | - | Defend DFQDND| #7 | | - | |<-----+ | | - | | | | - | | NA with | | - | | D-flag Set | | - | |--------------->| | - | | #8 | | - |------+ | |---+ | - No Response | #9 | Enter | #10 | - DFQDND Success| | Retry Mode| | - |<-----+ | |<--+ | - | | | | - v v v v - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 17] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #1. 6DNAC Server (Router) sends out router advertisement with DNS - Suffix information. - - #2. 6DNAC Clients A&B process the router advertisement and construct - their FQDN by prefixing hostname to the DNS Zone Suffix. They - also construct IPv6 address from the autoconfiguration prefix - information option. - - When each host is trying to go for DAD, all hosts must have - random delay to avoid the traffic congestion according to [2461]. - So here it is assumed that 6DNAC Client-A starts DAD first and - 6DNAC Client-B starts DAD later. - - #3. 6DNAC Client-A starts duplicate address & FQDN detection for the - IPv6 address & FQDN constructed and sends out a Neighbor - Solicitation message with FQDN option. - - #4. 6DNAC Server processes the Neighbor Solicitation message sent by - 6DNAC Client-A as part of duplicate FQDN detection procedure and - creates a FQDN entry in its FQDN Cache (assuming that there is no - entry ), where A is Link Layer Address of the 6DNAC Client-A. - - #5. 6DNAC Server then registers FQDN and corresponding IPv6 address - through the existing protocol DDNS UPDATE. - - #6. 6DNAC Client-B starts duplicate address & FQDN detection for the - IPv6 address & FQDN constructed and sends out a Neighbor Solicitation - message with FQDN option. - - #7. 6DNAC Server processes the Neighbor Solicitation message sent by - 6DNAC Client-B as part of duplicate FQDN detection procedure and - finds that the domain name is already in use by the 6DNAC Client-A. - Hence, concludes to defend the duplicate FQDN detection of 6DNAC - Client-B. - - #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN - option to 6DNAC Client-B to defend its duplicate FQDN detection. - - #9. 6DNAC Client-A times out and observes that there is no response to - defend its duplicate FQDN detection procedure and the node is - successful in configuring its domain name. - - #10. 6DNAC Client-B observes that there is a NA with FQDN option - indicating that the domain name is duplicate and enters Retry - Mode. In retry mode, 6DNAC Client constructs another FQDN based - on Host Naming Algorithm. The number of retries is defined by the - administrator and must be a configurable value. - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 18] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 7.2.4. Domain Name Registration in Retry Mode - - Pre-Conditions: - - 1. Duplicate Address Detection has succeeded - 2. Duplicate FQDN Detection FAILED - 3. FQDN is the first FQDN one constructed and FAILED - 4. FQDN2 is the second FQDN to be constructed - 5. The Neighbor Solicitation in the 'Retry Mode' - carries unspecified address in its target field (NS*). - - +---------+ +---------+ +---------+ - | 6DNAC-C | | 6DNAC-S | | DNS-S | - +----+----+ +----+----+ +----+----+ - | | | - |--------+ | | - Construct | #1 | | - new FQDN2 | | | - |<-------+ | | - | | | - DFQDND Restarts | | - | | | - | | | - | NS* With | | - | FQDN Opt | | - |--------------->| | - | #2 | | - | | | - | No Entry | - | |------+ | - | Create FQDN | #3 | - | | | - | |<-----+ | - | | | - | | Register FQDN2 | - | |--------------->| - | | #4 | - | | | - |--------+ | | - No Response | #5 | | - DFQDND-Success | | | - |<-------+ | | - | | | - v V v - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 19] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm, - the DNS Zone Suffix, and it is FQDN2. - #2. It then starts Duplicate Detection only for Domain Name. 6DNAC - Client sends out NS with FQDN option and unspecified target - address. - - #3. 6DNAC Server processes the Retry Mode NS message and finds that - the FQDN2 is not in use and creates Cache entry as . - - #4. It then starts registration procedures with the DNS Server. - - #5. Meanwhile, 6DNAC Client timesout and observes that there is no - defending NA for its DFQDND NS sent out and successfully - configures its domain name. - - - 7.2.5. Domain Name Registration when DAD Fails - - Duplicate domain name detection and subsequent registration starts - if and only if the DAD for IPv6 address succeeds. If the DAD for - IPv6 address fails then no actions are taken for domain name. When - DAD fails for stateless address autoconfiguration, then the domain - configuration starts only when the address has been configured using - Stateful Address Configuration methods and the node is going on DAD - for this address. - - This scenario starts when a 6DNAC Client receives RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and wants configure its IPv6 address (Global - or Site Local) and domain name. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 20] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---------+ +---------+ +---------+ +---------+ - | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | - +----+----+ +----+----+ +----+----+ +----+----+ - | | | | - | | | | - | RA with | | | - | DNS Suffix Opt | | | - |<---------------| | | - | #1 | | | - |-----+ | | | - Construct | | | | - FQDN& | #2 | | | - IPv6 Addr | | | | - |<----+ | | | - DAD/DFQDND Starts | | | - | | | | - | | | | - | NS with | | | - | FQDN Opt | | | - |--------------->+--------------->| | - | #3 | #3 | | - | No Entry | | - | |------+ | | - | Create FQDN | | | - | | #4 | | - | |<-----+ | | - | | | | - | | |------+ | - | | My IPv6 Addr| #5 | - | | |<-----+ | - | | Defend DAD | | - | | with NA | | - |<---------------+<---------------| | - | #6 | #6 | | - | Entry | | - | |------+ | | - | Delete FQDN | #7 | | - | |<-----+ | | - | | | | - |----+ | | | - DAD Failed | #8 | | | - Stop DFQDND | | | | - |<---+ | | | - | | | | - v v v v - - - - #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A. - - #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and - FQDN as per Host Naming Algorithm. - - #3. It then starts Duplicate address & FQDN Detection, for the newly - constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS - with FQDN option. - -Park & Madanapalli Expires October 2003 [Page 21] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #4. 6DNAC Server processes the DAD/DFQDND NS message and finds - that there is no entry for the FQDN in its cache. And, - creates Cache entry as and starts a Registration - timer with RegistrationWaitTime seconds. - - #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is - in its unicast address list. - - #6. It then starts defending DAD by sending NA to all-nodes multicast. - - #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A. - And, deletes its FQDN Cache entry . - - #8. 6DNAC Client gets defending DAD-NA and desists from DAD. - And also, stops Duplicate FQDN Detection as well. - At this point the address must be configured using stateful - methods and the domain name registration starts with the DAD - for the newly constructed IPv6 address. - - 7.3. DNS Zone Suffix Discovery and FQDN Construction - - 7.3.1. Sending Router Advertisement Messages - - Routers send out Router Advertisement message periodically, - or in response to a Router Solicitation. Router should include - the DNS Zone Suffix Option in their advertisements. If the DNS - Zone Suffix changes (similar to Site Renumbering), then it should - advertise the Old Zone Suffix with zero Valid Lifetime and New - Zone Suffix with proper non-zero Valid Lifetime. In any other - case, a router should not send this option twice in a single - router advertisement. - - 7.3.2. Processing Router Advertisement Messages - - For each DNS Zone Suffix Option in Router Advertisement, - - a. 6DNAC node stores the Zone Suffix information in its local - database. Also, constructs FQDN as per Host Naming Algorithm. - - b. If the node has not configured FQDN yet, - - 1. If the node is going to perform DAD for either Site local or - Global Address, then it should include FQDN option to perform - Duplicate FQDN Detection in parallel with DAD. - - 2. If the node has already got either Site local or Global - address, then it should send out NS with FQDN option and - unspecified target address to perform Duplicate FQDN - Detection. - - c. If the node has already configured FQDN, and if the - advertisement carries two DNS Zone Suffix Options, - First DNS Zone Suffix should match with the configured FQDN - Suffix and its Valid Lifetime must be zero. Second DNS Zone - - - -Park & Madanapalli Expires October 2003 [Page 22] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - Suffix should have non-zero Valid Lifetime. In this case, the - node constructs new FQDN based on the new DNS Zone Suffix (from - second DNS Zone Suffix option), and perform Duplicate FQDN - Detection with unspecified target address. Also, it should - overwrite the old FQDN with the newly constructed FQDN. - - - 7.3.3. FQDN Lifetime expiry - - 6DNAC Server: - It should delete the FQDN cache entry and should de-register from - the DNS Server. - - 6DNAC Client: - It should send update to 6DNAC Server by restarting the Duplicate - FQDN Detection. - - 7.3.4. Host Naming Algorithm - - A node constructs FQDN by combining DNS Zone Suffix and the hostname - as depicted in the following diagram. - - +------------------+----------------------------------+ - | Host Name | Advertised Suffix | - +------------------+----------------------------------+ - -
- - A node can choose Host Name using any of the following methods: - - a. String form of random number generated from the Interface - Identifier. - - b. List of configured Host Names provided by the administrator. - - - The number of retries must be specified in this algorithm in - case of domain name duplication. - - - 7.4. Duplicate Domain Name Detection - - The procedure for detecting duplicated FQDNs uses Neighbor - Solicitation and Advertisement messages as described below. - - If a duplicate FQDN is detected during the procedure, the - FQDN cannot be assigned to the node. - - An FQDN on which the DFQDND Procedure is applied is said - to be tentative until the procedure has completed successfully. - A tentative FQDN is not considered "assigned to the node" in the - traditional sense. That is, the node must accept Neighbor - Advertisement message containing the tentative FQDN in the FQDN - Option. - - -Park & Madanapalli Expires October 2003 [Page 23] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - It should also be noted that DFQDN must be performed prior to - registering with DNS Server to prevent multiple nodes from using - the same FQDN simultaneously. All the Duplicate Address Detection - Neighbor Solicitation messages must carry Source Link Layer Address - Option as specified in NDP [2461]. - - The detection of duplicate FQDN can be achieved through one of the - following three types of procedures. - - 1. DAD with All Nodes Multicast Address - 2. DAD with Router Alert Option for 6DNAC. - 3. Explicit Detection of Duplicate Domain Name - - Even though three solutions are listed, authors prefer only one - procedure to be followed in future based on further analysis and - comments received from others. - - 7.4.1. DAD with All Nodes Multicast Address - - 7.4.1.1. Sending Neighbor Solicitation Messages - - 6DNAC Client sends Neighbor Solicitation Messages as part - of Duplicate Address Detection SLAAC [2462] with the following - extra information and modifications: - - a. Include FQDN Option in the DAD Neighbor Solicitation Message - b. Destination Address is set to All Nodes Multicast Address - - There may be a case where DAD has succeeded but DFQDND is in Retry - Mode. In such case, the Neighbor Solicitation must carry unspecified - address in the ICMP target address field and new domain name in FQDN - option to re-try the registration of the domain name. - - 7.4.1.2. Processing Neighbor Solicitation Messages - - 6DNAC Clients must ignore the FQDN option found in any of the - neighbor solicitation messages. - - 6DNAC Server processes FQDN Option found in the Duplicate Address - Detection Neighbor Solicitation Messages as described below: - - Lookup FQDN Cache for the domain name in FQDN Option. - - If the entry exists and - i. Link Layer Address matches with SLLA option, this is the case, - where node has changed its IPv6 address or updating the valid - life time. 6DNAC Server updates its cache and also updates DNS - Server using DDNS-UPDATE. If there is no change in IPv6 address - or life time then no updates are sent to the DNS server. - - ii. Link Layer Address differs with SLLA option, defend the duplicate - FQDN Detection by sending Neighbor Advertisement Message as - described in $7.4.1.3$. - - - -Park & Madanapalli Expires October 2003 [Page 24] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - else, - Lookup FQDN Cache for the Link Layer Address in SLLA Option. - - If the entry exists, update the FQDN Cache and update DNS Server - using DDNS-UPDATE. This is the case, where node has changed its - domain name (similar to Site Re-numbering). - - If then entry does not exists, then it means that this is the new - registration. It must create a cache entry and start Registration - - timer with RegistrationWaitTime. At the expiry of the Registration - timer, it should update DNS Server with DDNS-UPDATE. - - 7.4.1.3. Sending Neighbor Advertisement Messages - - 6DNAC Server sends Neighbor Advertisement Messages as part - of Duplicate Address Detection SLAAC [2462] with the FQDN Option - in Neighbor Advertisement message to defend duplicate FQDN - detection. - - There may be the case where defending of duplicate address detection - is not required but defending of FQDN is required. In such instance, - the defending Neighbor Advertisement must carry FQDN and unspecified - address in the ICMP target address field. - - 7.4.1.4. Processing Neighbor Advertisement Messages - - 6DNAC Server must ignore the any FQDN option found any of - the neighbor advertisement messages. If the Neighbor Advertisement - is a DAD defending, then it must delete its FQDN Cache entry created - on the reception of DAD Neighbor Solicitation message. - - When 6DNAC Clients gets the duplicate address detection neighbor - advertisement messages with FQDN option set it means that its - duplicate FQDN detection failed and enters Retry Mode. - - 7.4.1.5. Pros and Cons - - The advantage of this procedure is that it does not need any - extension header options to be included. The disadvantage of this - procedure is that, it needs change in the existing DAD procedure. - The change is only that the DAD neighbor solicitations are to be - addressed to all nodes multicast address instead of solicited - node multicast address. The another disadvantage is that, it needs - the existence of Duplicate Address Detection Procedure to - perform duplicate FQDN detection. - - 7.4.2. DAD with Router Alert Option for 6DNAC - - 7.4.2.1. Sending Neighbor Solicitation Messages - - 6DNAC Client sends Neighbor Solicitation Messages as part - of Duplicate Address Detection SLAAC [2462] with the following - extra information: - - -Park & Madanapalli Expires October 2003 [Page 25] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - a. Include Hop-by-Hop extension Header with Router Alert Option - for 6DNAC as described in IPv6 Router Alert Option[2711]. - - b. Include FQDN Option in the DAD Neighbor Solicitation Message - - 7.4.2.2. Processing Neighbor Solicitation Messages - - This is same as described in $7.4.1.2$. - - 7.4.2.3. Sending Neighbor Advertisement Messages - - This is same as described in $7.4.1.3$. - - 7.4.2.4. Processing Neighbor Advertisement Messages - - This is same as described in $7.4.1.4$. - - 7.4.2.5. Pros and Cons - - The advantage of this procedure is that it does not disturb - the existing implementation and their way of processing the - packets. The disadvantage is that, it needs the existence - of Duplicate Address Detection Procedure to perform duplicate - FQDN detection. Another disadvantage is that this procedure - requires 6DNAC Server functionality to be implemented on Router. - However, in this case 6DNAC Server can serve multiple links. - - 7.4.3. Explicit Detection of Duplicate Domain Name - - In this procedure Duplicate FQDN Detection starts after completion - of successful Site local or Global Address configuration. - - 7.4.3.1. Sending Neighbor Solicitation Messages - - 6DNAC Client sends Neighbor Solicitation Messages as part - of Duplicate FQDN Detection with the following information: - - a. Include FQDN Option in the Neighbor Solicitation Message - - b. Destination Address is set to All Nodes Multicast Address - or uses Router Alert Option for 6DNAC, when 6DNAC Server is - implemented on router. - - c. Target Address is set to Unspecified Address - - d. Other fields are set as per DAD SLAAC [2462]. - - 7.4.3.2. Processing Neighbor Solicitation Messages - - This is same as described in $7.4.1.2$. - - - - - - -Park & Madanapalli Expires October 2003 [Page 26] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - 7.4.3.3. Sending Neighbor Advertisement Messages - - This is same as described in $7.4.1.3$. - - 7.4.3.4. Processing Neighbor Advertisement Messages - - This is same as described in $7.4.1.4$. - - 7.4.3.5. Pros and Cons - - The advantage of this procedure is that it does not need the - existing duplicate address detection procedure. This is introduced - as the DAD procedure is found to be redundant in when IPv6 addresses - are constructed from the interface ID [DIID]. - - Note that, if 6DNAC Clients know the address of 6DNAC Server then - they can directly send DFQDND-NS to 6DNAC Server. - - 7.4.4. Retry Mode for Re-registering Domain Name - - In retry mode, nodes construct new FQDN as per Host Naming Algorithm. - Then they restart Duplicate FQDN Detection as described in $7.4.3$. - - - 7.5. Domain Name Registration - - 6DNAC Server must be an authenticated to update the DNS Server. - 6DNAC Server must also be configured with the DNS Server - information. - - 6DNAC Server detects the DNS information (IPv6 Address and - corresponding FQDN) from DAD/DFQDND messages and caches the - information. It also have an associated Registration Timer with - RegistrationWaitTime to wait for the successful completion of - DFQDND and update DNS Server using existing protocol DDNS UPDATE - [2136]. - - - 8. Security Consideration - - If someone wants to hijack correct Domain Name registration, they - could send a NS message with incorrect or same Domain Name to the - 6DNAC server repeatedly and server would start the Domain Name - registration through above mechanism, which is a security hole. - As described in [2461], a host can check validity of NDP messages. - If the NDP message include an IP Authentication Header, the message - authenticates correctly. For DNS UPDATE processing, secure DNS - Dynamic Update is described in [3007]. - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 27] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - 9. IANA Consideration - - Values in the Router Alert Option are registered and maintained by - IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is - required to assign the Type values for DNS Zone Suffix Information - option and FADN option. - - - 10. Acknowledgement - - Special thanks are due to Badrinarayana N.S. and Christian Huitema for - many helpful suggestions and revisions. - - - 11. Intellectual Property - - The following notice is copied from RFC 2026 [Bradner, 1996], - Section 10.4, and describes the position of the IETF concerning - intellectual property claims made against this document. - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use other technology described in - - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances - of licenses to be made available, or the result of an attempt made - to obtain a general license or permission for the use of such - proprietary rights by implementers or users of this specification - can be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - 12. Copyright - - The following copyright notice is copied from RFC 2026 [Bradner, - 1996], Section 10.4, and describes the applicable copyright for this - document. - - Copyright (C) The Internet Society July 12, 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 - -Park & Madanapalli Expires October 2003 [Page 28] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - 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 assignees. - - 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. - - - 13. References - - [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - - [2460] Deering, S. abd R. Hinden, "Internet Protocol, - Version 6 (IPv6) Specification", RFC 2460, - December 1998. - - [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor - Discovery for IP version 6(IPv6)", RFC 2461, December - 1998. - - [2462] S. Thomson and Narten T, "IPv6 Stateless Address Auto- - Configuration", RFC 2462, December 1998. - - [2711] C. Patridge and A.Jackson, "IPv6 Router Alert Option", - RFC 2711, October 1999. - - [1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND - FACILITIES", RFC 1034, November 1987. - - [1035] P. Mockapetris, "Domain Names - Implementation and - Specification" RFC 1035, November 1987. - - [2136] P. Vixie et al., "Dynamic Updates in the Domain Name - System (DNS UPDATE)", RFC2136, April 1997. - - [3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - - -Park & Madanapalli Expires October 2003 [Page 29] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - [DIID] yokohama-dad-vs-diid.pdf - at http://playground.sun.com/ipng/presentations/July2002/ - - [DNSISSUES] Durand, A., "IPv6 DNS transition issues", draft-ietf- - dnsop-ipv6-dns-issues-00.txt, work in progress. - - [PREFIX] S. Miyakawa, R. Droms, "Requirements for IPv6 prefix - delegation", draft-ietf-ipv6-prefix-delegation- - requirement-01.txt, work in progress. - - [Autoreg] H. Kitamura, "Domain Name Auto-Registration for - Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name- - auto-reg-00.txt, work in progress. - - [NIQ] Matt Crawford, "IPv6 Node Information Queries", , work in progress. - - - 14. Author's Addresses - - Soohong Daniel Park - Mobile Platform Laboratory, SAMSUNG Electronics, KOREA - Phone: +82-31-200-3728 - Email:soohong.park@samsung.com - - Syam Madanapalli - Network Systems Division, SAMSUNG India Software Operations, INDIA - Phone: +91-80-5550555 - Email:syam@samsung.com - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 30] diff --git a/doc/rfc/index b/doc/rfc/index index 2858658729..5d48ee4e6e 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -106,6 +106,8 @@ 4159: Deprecation of "ip6.int" 4193: Unique Local IPv6 Unicast Addresses 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints +4294: IPv6 Node Requirements +4339: IPv6 Host Configuration of DNS Server Information Approaches 4343: Domain Name System (DNS) Case Insensitivity Clarification 4367: What's in a Name: False Assumptions about DNS Names 4398: Storing Certificates in the Domain Name System (DNS) @@ -114,11 +116,13 @@ in E-Mail, Version 1 4470: Minimally Covering NSEC Records and DNSSEC On-line Signing 4471: Derivation of DNS Name Predecessor and Successor +4472: Operational Considerations and Issues with IPv6 DNS 4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) 4634: US Secure Hash Algorithms (SHA and HMAC-SHA) 4635: HMAC SHA TSIG Algorithm Identifiers 4641: DNSSEC Operational Practices 4648: The Base16, Base32, and Base64 Data Encodings +4697: Observed DNS Resolution Misbehavior 4701: A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) 4892: Requirements for a Mechanism Identifying a Name Server Instance diff --git a/doc/rfc/rfc4294.txt b/doc/rfc/rfc4294.txt new file mode 100644 index 0000000000..8fea5c311b --- /dev/null +++ b/doc/rfc/rfc4294.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group J. Loughney, Ed. +Request for Comments: 4294 Nokia +Category: Informational April 2006 + + + IPv6 Node Requirements + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document defines requirements for IPv6 nodes. It is expected + that IPv6 will be deployed in a wide range of devices and situations. + Specifying the requirements for IPv6 nodes allows IPv6 to function + well and interoperate in a large number of situations and + deployments. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Requirement Language .......................................3 + 1.2. Scope of This Document .....................................3 + 1.3. Description of IPv6 Nodes ..................................3 + 2. Abbreviations Used in This Document .............................3 + 3. Sub-IP Layer ....................................................4 + 3.1. Transmission of IPv6 Packets over Ethernet Networks + - RFC 2464 .................................................4 + 3.2. IP version 6 over PPP - RFC 2472 ...........................4 + 3.3. IPv6 over ATM Networks - RFC 2492 ..........................4 + 4. IP Layer ........................................................5 + 4.1. Internet Protocol Version 6 - RFC 2460 .....................5 + 4.2. Neighbor Discovery for IPv6 - RFC 2461 .....................5 + 4.3. Path MTU Discovery and Packet Size .........................6 + 4.4. ICMP for the Internet Protocol Version 6 (IPv6) - + RFC 2463 ...................................................7 + 4.5. Addressing .................................................7 + 4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 .....8 + 5. DNS and DHCP ....................................................8 + 5.1. DNS ........................................................8 + + + + +Loughney Informational [Page 1] + +RFC 4294 IPv6 Node Requirements April 2006 + + + 5.2. Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) - RFC 3315 ........................................9 + 6. IPv4 Support and Transition ....................................10 + 6.1. Transition Mechanisms .....................................10 + 7. Mobile IP ......................................................10 + 8. Security .......................................................10 + 8.1. Basic Architecture ........................................10 + 8.2. Security Protocols ........................................11 + 8.3. Transforms and Algorithms .................................11 + 8.4. Key Management Methods ....................................12 + 9. Router-Specific Functionality ..................................12 + 9.1. General ...................................................12 + 10. Network Management ............................................12 + 10.1. Management Information Base Modules (MIBs) ...............12 + 11. Security Considerations .......................................13 + 12. References ....................................................13 + 12.1. Normative References .....................................13 + 12.2. Informative References ...................................16 + 13. Authors and Acknowledgements ..................................18 + +1. Introduction + + The goal of this document is to define the common functionality + required from both IPv6 hosts and routers. Many IPv6 nodes will + implement optional or additional features, but this document + summarizes requirements from other published Standards Track + documents in one place. + + This document tries to avoid discussion of protocol details, and + references RFCs for this purpose. This document is informational in + nature and does not update Standards Track RFCs. + + Although the document points to different specifications, it should + be noted that in most cases, the granularity of requirements are + smaller than a single specification, as many specifications define + multiple, independent pieces, some of which may not be mandatory. + + As it is not always possible for an implementer to know the exact + usage of IPv6 in a node, an overriding requirement for IPv6 nodes is + that they should adhere to Jon Postel's Robustness Principle: + + Be conservative in what you do, be liberal in what you accept from + others [RFC-793]. + + + + + + + + +Loughney Informational [Page 2] + +RFC 4294 IPv6 Node Requirements April 2006 + + +1.1. Requirement Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC-2119]. + +1.2. Scope of This Document + + IPv6 covers many specifications. It is intended that IPv6 will be + deployed in many different situations and environments. Therefore, + it is important to develop the requirements for IPv6 nodes to ensure + interoperability. + + This document assumes that all IPv6 nodes meet the minimum + requirements specified here. + +1.3. Description of IPv6 Nodes + + From the Internet Protocol, Version 6 (IPv6) Specification + [RFC-2460], we have the following definitions: + + Description of an IPv6 Node + + - a device that implements IPv6. + + Description of an IPv6 router + + - a node that forwards IPv6 packets not explicitly addressed + to itself. + + Description of an IPv6 Host + + - any node that is not a router. + +2. Abbreviations Used in This Document + + ATM Asynchronous Transfer Mode + + AH Authentication Header + + DAD Duplicate Address Detection + + ESP Encapsulating Security Payload + + ICMP Internet Control Message Protocol + + IKE Internet Key Exchange + + + + +Loughney Informational [Page 3] + +RFC 4294 IPv6 Node Requirements April 2006 + + + MIB Management Information Base + + MLD Multicast Listener Discovery + + MTU Maximum Transfer Unit + + NA Neighbor Advertisement + + NBMA Non-Broadcast Multiple Access + + ND Neighbor Discovery + + NS Neighbor Solicitation + + NUD Neighbor Unreachability Detection + + PPP Point-to-Point Protocol + + PVC Permanent Virtual Circuit + + SVC Switched Virtual Circuit + +3. Sub-IP Layer + + An IPv6 node must include support for one or more IPv6 link-layer + specifications. Which link-layer specifications are included will + depend upon what link-layers are supported by the hardware available + on the system. It is possible for a conformant IPv6 node to support + IPv6 on some of its interfaces and not on others. + + As IPv6 is run over new layer 2 technologies, it is expected that new + specifications will be issued. This section highlights some major + layer 2 technologies and is not intended to be complete. + +3.1. Transmission of IPv6 Packets over Ethernet Networks - RFC 2464 + + Nodes supporting IPv6 over Ethernet interfaces MUST implement + Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. + +3.2. IP version 6 over PPP - RFC 2472 + + Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP + [RFC-2472]. + +3.3. IPv6 over ATM Networks - RFC 2492 + + Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM + Networks [RFC-2492]. Additionally, RFC 2492 states: + + + +Loughney Informational [Page 4] + +RFC 4294 IPv6 Node Requirements April 2006 + + + A minimally conforming IPv6/ATM driver SHALL support the PVC mode + of operation. An IPv6/ATM driver that supports the full SVC mode + SHALL also support PVC mode of operation. + +4. IP Layer + +4.1. Internet Protocol Version 6 - RFC 2460 + + The Internet Protocol Version 6 is specified in [RFC-2460]. This + specification MUST be supported. + + Unrecognized options in Hop-by-Hop Options or Destination Options + extensions MUST be processed as described in RFC 2460. + + The node MUST follow the packet transmission rules in RFC 2460. + + Nodes MUST always be able to send, receive, and process fragment + headers. All conformant IPv6 implementations MUST be capable of + sending and receiving IPv6 packets; the forwarding functionality MAY + be supported. + + RFC 2460 specifies extension headers and the processing for these + headers. + + A full implementation of IPv6 includes implementation of the + following extension headers: Hop-by-Hop Options, Routing (Type 0), + Fragment, Destination Options, Authentication and Encapsulating + Security Payload [RFC-2460]. + + An IPv6 node MUST be able to process these headers. It should be + noted that there is some discussion about the use of Routing Headers + and possible security threats [IPv6-RH] that they cause. + +4.2. Neighbor Discovery for IPv6 - RFC 2461 + + Neighbor Discovery SHOULD be supported. [RFC-2461] states: + + "Unless specified otherwise (in a document that covers operating + IP over a particular link type) this document applies to all link + types. However, because ND uses link-layer multicast for some of + its services, it is possible that on some link types (e.g., NBMA + links) alternative protocols or mechanisms to implement those + services will be specified (in the appropriate document covering + the operation of IP over a particular link type). The services + described in this document that are not directly dependent on + multicast, such as Redirects, Next-hop determination, Neighbor + Unreachability Detection, etc., are expected to be provided as + + + + +Loughney Informational [Page 5] + +RFC 4294 IPv6 Node Requirements April 2006 + + + specified in this document. The details of how one uses ND on + NBMA links is an area for further study." + + Some detailed analysis of Neighbor Discovery follows: + + Router Discovery is how hosts locate routers that reside on an + attached link. Router Discovery MUST be supported for + implementations. + + Prefix Discovery is how hosts discover the set of address prefixes + that define which destinations are on-link for an attached link. + Prefix discovery MUST be supported for implementations. Neighbor + Unreachability Detection (NUD) MUST be supported for all paths + between hosts and neighboring nodes. It is not required for paths + between routers. However, when a node receives a unicast Neighbor + Solicitation (NS) message (that may be a NUD's NS), the node MUST + respond to it (i.e., send a unicast Neighbor Advertisement). + + Duplicate Address Detection MUST be supported on all links supporting + link-layer multicast (RFC 2462, Section 5.4, specifies DAD MUST take + place on all unicast addresses). + + A host implementation MUST support sending Router Solicitations. + + Receiving and processing Router Advertisements MUST be supported for + host implementations. The ability to understand specific Router + Advertisement options is dependent on supporting the specification + where the RA is specified. + + Sending and Receiving Neighbor Solicitation (NS) and Neighbor + Advertisement (NA) MUST be supported. NS and NA messages are + required for Duplicate Address Detection (DAD). + + Redirect functionality SHOULD be supported. If the node is a router, + Redirect functionality MUST be supported. + +4.3. Path MTU Discovery and Packet Size + +4.3.1. Path MTU Discovery - RFC 1981 + + Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal + implementations MAY choose to not support it and avoid large packets. + The rules in RFC 2460 MUST be followed for packet fragmentation and + reassembly. + +4.3.2. IPv6 Jumbograms - RFC 2675 + + IPv6 Jumbograms [RFC-2675] MAY be supported. + + + +Loughney Informational [Page 6] + +RFC 4294 IPv6 Node Requirements April 2006 + + +4.4. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463 + + ICMPv6 [RFC-2463] MUST be supported. + +4.5. Addressing + +4.5.1. IP Version 6 Addressing Architecture - RFC 3513 + + The IPv6 Addressing Architecture [RFC-3513] MUST be supported as + updated by [RFC-3879]. + +4.5.2. IPv6 Stateless Address Autoconfiguration - RFC 2462 + + IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. + This specification MUST be supported for nodes that are hosts. + Static address can be supported as well. + + Nodes that are routers MUST be able to generate link local addresses + as described in RFC 2462 [RFC-2462]. + + From 2462: + + The autoconfiguration process specified in this document applies + only to hosts and not routers. Since host autoconfiguration uses + information advertised by routers, routers will need to be + configured by some other means. However, it is expected that + routers will generate link-local addresses using the mechanism + described in this document. In addition, routers are expected to + successfully pass the Duplicate Address Detection procedure + described in this document on all addresses prior to assigning + them to an interface. + + Duplicate Address Detection (DAD) MUST be supported. + +4.5.3. Privacy Extensions for Address Configuration in IPv6 - RFC 3041 + + Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] + SHOULD be supported. It is recommended that this behavior be + configurable on a connection basis within each application when + available. It is noted that a number of applications do not work + with addresses generated with this method, while other applications + work quite well with them. + +4.5.4. Default Address Selection for IPv6 - RFC 3484 + + The rules specified in the Default Address Selection for IPv6 + [RFC-3484] document MUST be implemented. It is expected that IPv6 + nodes will need to deal with multiple addresses. + + + +Loughney Informational [Page 7] + +RFC 4294 IPv6 Node Requirements April 2006 + + +4.5.5. Stateful Address Autoconfiguration + + Stateful Address Autoconfiguration MAY be supported. DHCPv6 + [RFC-3315] is the standard stateful address configuration protocol; + see Section 5.3 for DHCPv6 support. + + Nodes which do not support Stateful Address Autoconfiguration may be + unable to obtain any IPv6 addresses, aside from link-local addresses, + when it receives a router advertisement with the 'M' flag (Managed + address configuration) set and that contains no prefixes advertised + for Stateless Address Autoconfiguration (see Section 4.5.2). + Additionally, such nodes will be unable to obtain other configuration + information, such as the addresses of DNS servers when it is + connected to a link over which the node receives a router + advertisement in which the 'O' flag ("Other stateful configuration") + is set. + +4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 + + Nodes that need to join multicast groups SHOULD implement MLDv2 + [RFC-3810]. However, if the node has applications that only need + support for Any-Source Multicast [RFC-3569], the node MAY implement + MLDv1 [RFC-2710] instead. If the node has applications that need + support for Source-Specific Multicast [RFC-3569, SSM-ARCH], the node + MUST support MLDv2 [RFC-3810]. + + When MLD is used, the rules in the "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be + followed. + +5. DNS and DHCP + +5.1. DNS + + DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363], + and [RFC-3596]. Not all nodes will need to resolve names; those that + will never need to resolve DNS names do not need to implement + resolver functionality. However, the ability to resolve names is a + basic infrastructure capability that applications rely on and + generally needs to be supported. All nodes that need to resolve + names SHOULD implement stub-resolver [RFC-1034] functionality, as in + RFC 1034, Section 5.3.1, with support for: + + - AAAA type Resource Records [RFC-3596]; + + - reverse addressing in ip6.arpa using PTR records [RFC-3152]; + + + + + +Loughney Informational [Page 8] + +RFC 4294 IPv6 Node Requirements April 2006 + + + - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 + octets. + + Those nodes are RECOMMENDED to support DNS security extensions + [RFC-4033], [RFC-4034], and [RFC-4035]. + + Those nodes are NOT RECOMMENDED to support the experimental A6 and + DNAME Resource Records [RFC-3363]. + +5.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315 + +5.2.1. Managed Address Configuration + + The method by which IPv6 nodes that use DHCP for address assignment + can obtain IPv6 addresses and other configuration information upon + receipt of a Router Advertisement with the 'M' flag set is described + in Section 5.5.3 of RFC 2462. + + In addition, in the absence of a router, those IPv6 nodes that use + DHCP for address assignment MUST initiate DHCP to obtain IPv6 + addresses and other configuration information, as described in + Section 5.5.2 of RFC 2462. Those IPv6 nodes that do not use DHCP for + address assignment can ignore the 'M' flag in Router Advertisements. + +5.2.2. Other Configuration Information + + The method by which IPv6 nodes that use DHCP to obtain other + configuration information can obtain other configuration information + upon receipt of a Router Advertisement with the 'O' flag set is + described in Section 5.5.3 of RFC 2462. + + Those IPv6 nodes that use DHCP to obtain other configuration + information initiate DHCP for other configuration information upon + receipt of a Router Advertisement with the 'O' flag set, as described + in Section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP + for other configuration information can ignore the 'O' flag in Router + Advertisements. + + An IPv6 node can use the subset of DHCP (described in [RFC-3736]) to + obtain other configuration information. + +5.3.3. Use of Router Advertisements in Managed Environments + + Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + are expected to determine their default router information and on- + link prefix information from received Router Advertisements. + + + + + +Loughney Informational [Page 9] + +RFC 4294 IPv6 Node Requirements April 2006 + + +6. IPv4 Support and Transition + + IPv6 nodes MAY support IPv4. + +6.1. Transition Mechanisms + +6.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893 + + If an IPv6 node implements dual stack and tunneling, then [RFC-4213] + MUST be supported. + +7. Mobile IP + + The Mobile IPv6 [RFC-3775] specification defines requirements for the + following types of nodes: + + - mobile nodes + + - correspondent nodes with support for route optimization + + - home agents + + - all IPv6 routers + + Hosts MAY support mobile node functionality described in Section 8.5 + of [RFC-3775], including support of generic packet tunneling [RFC- + 2473] and secure home agent communications [RFC-3776]. + + Hosts SHOULD support route optimization requirements for + correspondent nodes described in Section 8.2 of [RFC-3775]. + + Routers SHOULD support the generic mobility-related requirements for + all IPv6 routers described in Section 8.3 of [RFC-3775]. Routers MAY + support the home agent functionality described in Section 8.4 of + [RFC-3775], including support of [RFC-2473] and [RFC-3776]. + +8. Security + + This section describes the specification of IPsec for the IPv6 node. + +8.1. Basic Architecture + + Security Architecture for the Internet Protocol [RFC-4301] MUST be + supported. + + + + + + + +Loughney Informational [Page 10] + +RFC 4294 IPv6 Node Requirements April 2006 + + +8.2. Security Protocols + + ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported. + +8.3. Transforms and Algorithms + + Current IPsec RFCs specify the support of transforms and algorithms + for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and + HMAC-MD5-96. However, "Cryptographic Algorithm Implementation + Requirements For ESP And AH" [RFC-4305] contains the current set of + mandatory to implement algorithms for ESP and AH. It also specifies + algorithms that should be implemented because they are likely to be + promoted to mandatory at some future time. IPv6 nodes SHOULD conform + to the requirements in [RFC-4305], as well as the requirements + specified below. + + Since ESP encryption and authentication are both optional, support + for the NULL encryption algorithm [RFC-2410] and the NULL + authentication algorithm [RFC-4303] MUST be provided to maintain + consistency with the way these services are negotiated. However, + while authentication and encryption can each be NULL, they MUST NOT + both be NULL. The NULL encryption algorithm is also useful for + debugging. + + The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported + within ESP. Security issues related to the use of DES are discussed + in [DESDIFF], [DESINT], and [DESCRACK]. DES-CBC is still listed as + required by the existing IPsec RFCs, but updates to these RFCs will + be published in the near future. DES provides 56 bits of protection, + which is no longer considered sufficient. + + The use of the HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP + MUST be supported. The use of the HMAC-MD5-96 algorithm [RFC-2403] + within AH and ESP MAY also be supported. + + The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the + same security issues as DES-CBC, and the 3DES-CBC algorithm within + ESP MUST be supported to ensure interoperability. + + The AES-128-CBC algorithm [RFC-3602] MUST also be supported within + ESP. AES-128 is expected to be a widely available, secure, and + efficient algorithm. While AES-128-CBC is not required by the + current IPsec RFCs, it is expected to become required in the future. + + + + + + + + +Loughney Informational [Page 11] + +RFC 4294 IPv6 Node Requirements April 2006 + + +8.4. Key Management Methods + + An implementation MUST support the manual configuration of the + security key and SPI. The SPI configuration is needed in order to + delineate between multiple keys. + + Key management SHOULD be supported. Examples of key management + systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include + key management functions. + + Where key refresh, anti-replay features of AH and ESP, or on-demand + creation of Security Associations (SAs) is required, automated keying + MUST be supported. + + Key management methods for multicast traffic are also being worked on + by the MSEC WG. + +9. Router-Specific Functionality + + This section defines general host considerations for IPv6 nodes that + act as routers. Currently, this section does not discuss routing- + specific requirements. + +9.1. General + +9.1.1. IPv6 Router Alert Option - RFC 2711 + + The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- + Hop Header that is used in conjunction with some protocols (e.g., + RSVP [RFC-2205] or MLD [RFC-2710]). The Router Alert option will + need to be implemented whenever protocols that mandate its usage are + implemented. See Section 4.6. + +9.1.2. Neighbor Discovery for IPv6 - RFC 2461 + + Sending Router Advertisements and processing Router Solicitation MUST + be supported. + +10. Network Management + + Network Management MAY be supported by IPv6 nodes. However, for IPv6 + nodes that are embedded devices, network management may be the only + possible way of controlling these nodes. + +10.1. Management Information Base Modules (MIBs) + + The following two MIBs SHOULD be supported by nodes that support an + SNMP agent. + + + +Loughney Informational [Page 12] + +RFC 4294 IPv6 Node Requirements April 2006 + + +10.1.1. IP Forwarding Table MIB + + IP Forwarding Table MIB [RFC-4292] SHOULD be supported by nodes that + support an SNMP agent. + +10.1.2. Management Information Base for the Internet Protocol (IP) + + IP MIB [RFC-4293] SHOULD be supported by nodes that support an SNMP + agent. + +11. Security Considerations + + This document does not affect the security of the Internet, but + implementations of IPv6 are expected to support a minimum set of + security features to ensure security on the Internet. "IP Security + Document Roadmap" [RFC-2411] is important for everyone to read. + + The security considerations in RFC 2460 state the following: + + The security features of IPv6 are described in the Security + Architecture for the Internet Protocol [RFC-2401]. + + RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for + the security features of IPv6. + +12. References + +12.1. Normative References + + [RFC-1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC-1981] McCann, J., Deering, S., and J. Mogul, "Path MTU + Discovery for IP version 6", RFC 1981, August 1996. + + [RFC-2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 + within ESP and AH", RFC 2403, November 1998. + + [RFC-2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 + within ESP and AH", RFC 2404, November 1998. + + + + +Loughney Informational [Page 13] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher + Algorithm With Explicit IV", RFC 2405, November 1998. + + [RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm + and Its Use With IPsec", RFC 2410, November 1998. + + [RFC-2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security + Document Roadmap", RFC 2411, November 1998. + + [RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher + Algorithms", RFC 2451, November 1998. + + [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version + 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC-2463] Conta, A. and S. Deering, "Internet Control Message + Protocol (ICMPv6) for the Internet Protocol Version 6 + (IPv6) Specification", RFC 2463, December 1998. + + [RFC-2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC + 2472, December 1998. + + [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in + IPv6 Specification", RFC 2473, December 1998. + + [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC-2710] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + + [RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert + Option", RFC 2711, October 1999. + + [RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC + 3041, January 2001. + + [RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + + +Loughney Informational [Page 14] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC-3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and + T. Hain, "Representing Internet Protocol version 6 + (IPv6) Addresses in the Domain Name System (DNS)", RFC + 3363, August 2002. + + [RFC-3484] Frye, R., Levi, D., Routhier, S., and B. Wijnen, + "Coexistence between Version 1, Version 2, and Version + 3 of the Internet-standard Network Management + Framework", BCP 74, RFC 3584, August 2003. + + [RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version + 6 (IPv6) Addressing Architecture", RFC 3513, April + 2003. + + [RFC-3590] Haberman, B., "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol", RFC + 3590, September 2003. + + [RFC-3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. + + [RFC-3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC + Cipher Algorithm and Its Use with IPsec", RFC 3602, + September 2003. + + [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility + Support in IPv6", RFC 3775, June 2004. + + [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using + IPsec to Protect Mobile IPv6 Signaling Between Mobile + Nodes and Home Agents", RFC 3776, June 2004. + + [RFC-3810] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + [RFC-3879] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. + + [RFC-4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, + April 2006. + + [RFC-4293] Routhier, S., Ed., "Management Information Base for + the Internet Protocol (IP)", RFC 4293, April 2006. + + + +Loughney Informational [Page 15] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-4301] Kent, S. and R. Atkinson, "Security Architecture for + the Internet Protocol", RFC 4301, December 2005. + + [RFC-4302] Kent, S., "IP Authentication Header", RFC 4302, + December 2005. + + [RFC-4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + + [RFC-4305] Eastlake 3rd, D., "Cryptographic Algorithm + Implementation Requirements for Encapsulating Security + Payload (ESP) and Authentication Header (AH)", RFC + 4305, December 2005. + +12.2. Informative References + + [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of + DES-like cryptosystems", Journal of Cryptology Vol 4, + Jan 1991. + + [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA + 2000. + + [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without + Strong Integrity", Proceedings of the 32nd IETF, + Danvers, MA, April 1995. + + [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home + Address Options", Work in Progress. + + [RFC-793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC-1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- + Version 1 Functional Specification", RFC 2205, + September 1997. + + [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over + Ethernet Networks", RFC 2464, December 1998. + + [RFC-2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over + ATM Networks", RFC 2492, January 1999. + + + + + +Loughney Informational [Page 16] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-2675] Borman, D., Deering, S., and R. Hinden, "IPv6 + Jumbograms", RFC 2675, August 1999. + + [RFC-4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. + + [RFC-3569] Bhattacharyya, S., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, July 2003. + + [RFC-3736] Droms, R., "Stateless Dynamic Host Configuration + Protocol (DHCP) Service for IPv6", RFC 3736, April + 2004. + + [RFC-4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet + Network Addresses", RFC 4001, February 2005. + + [RFC-4033] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC-4034] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Resource Records for the DNS Security + Extensions", RFC 4034, March 2005. + + [RFC-4035] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC-4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) + Protocol", RFC 4306, December 2005. + + [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for + IP", Work in Progress. + + + + + + + + + + + + + + + + +Loughney Informational [Page 17] + +RFC 4294 IPv6 Node Requirements April 2006 + + +13. Authors and Acknowledgements + + This document was written by the IPv6 Node Requirements design team: + + Jari Arkko + [jari.arkko@ericsson.com] + + Marc Blanchet + [marc.blanchet@viagenie.qc.ca] + + Samita Chakrabarti + [samita.chakrabarti@eng.sun.com] + + Alain Durand + [alain.durand@sun.com] + + Gerard Gastaud + [gerard.gastaud@alcatel.fr] + + Jun-ichiro itojun Hagino + [itojun@iijlab.net] + + Atsushi Inoue + [inoue@isl.rdc.toshiba.co.jp] + + Masahiro Ishiyama + [masahiro@isl.rdc.toshiba.co.jp] + + John Loughney + [john.loughney@nokia.com] + + Rajiv Raghunarayan + [raraghun@cisco.com] + + Shoichi Sakane + [shouichi.sakane@jp.yokogawa.com] + + Dave Thaler + [dthaler@windows.microsoft.com] + + Juha Wiljakka + [juha.wiljakka@Nokia.com] + + The authors would like to thank Ran Atkinson, Jim Bound, Brian + Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas + Narten, Juha Ollila, and Pekka Savola for their comments. + + + + + +Loughney Informational [Page 18] + +RFC 4294 IPv6 Node Requirements April 2006 + + +Editor's Contact Information + + Comments or questions regarding this document should be sent to the + IPv6 Working Group mailing list (ipv6@ietf.org) or to: + + John Loughney + Nokia Research Center + Itamerenkatu 11-13 + 00180 Helsinki + Finland + + Phone: +358 50 483 6242 + EMail: John.Loughney@Nokia.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Loughney Informational [Page 19] + +RFC 4294 IPv6 Node Requirements April 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Loughney Informational [Page 20] + diff --git a/doc/rfc/rfc4339.txt b/doc/rfc/rfc4339.txt new file mode 100644 index 0000000000..a6f29d9f43 --- /dev/null +++ b/doc/rfc/rfc4339.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group J. Jeong, Ed. +Request for Comments: 4339 ETRI/University of Minnesota +Category: Informational February 2006 + + + IPv6 Host Configuration of DNS Server Information Approaches + + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +IESG Note + + This document describes three different approaches for the + configuration of DNS name resolution server information in IPv6 + hosts. + + There is not an IETF consensus on which approach is preferred. The + analysis in this document was developed by the proponents for each + approach and does not represent an IETF consensus. + + The 'RA option' and 'Well-known anycast' approaches described in this + document are not standardized. Consequently the analysis for these + approaches might not be completely applicable to any specific + proposal that might be proposed in the future. + +Abstract + + This document describes three approaches for IPv6 recursive DNS + server address configuration. It details the operational attributes + of three solutions: RA option, DHCPv6 option, and well-known anycast + addresses for recursive DNS servers. Additionally, it suggests the + deployment scenarios in four kinds of networks (ISP, enterprise, + 3GPP, and unmanaged networks) considering multi-solution resolution. + + + + + + + + + + +Jeong Informational [Page 1] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................3 + 3. IPv6 DNS Configuration Approaches ...............................3 + 3.1. RA Option ..................................................3 + 3.1.1. Advantages ..........................................4 + 3.1.2. Disadvantages .......................................5 + 3.1.3. Observations ........................................5 + 3.2. DHCPv6 Option ..............................................6 + 3.2.1. Advantages ..........................................7 + 3.2.2. Disadvantages .......................................8 + 3.2.3. Observations ........................................9 + 3.3. Well-known Anycast Addresses ...............................9 + 3.3.1. Advantages .........................................10 + 3.3.2. Disadvantages ......................................10 + 3.3.3. Observations .......................................10 + 4. Interworking among IPv6 DNS Configuration Approaches ...........11 + 5. Deployment Scenarios ...........................................12 + 5.1. ISP Network ...............................................12 + 5.1.1. RA Option Approach .................................13 + 5.1.2. DHCPv6 Option Approach .............................13 + 5.1.3. Well-known Anycast Addresses Approach ..............14 + 5.2. Enterprise Network ........................................14 + 5.3. 3GPP Network ..............................................15 + 5.3.1. Currently Available Mechanisms and + Recommendations ....................................15 + 5.3.2. RA Extension .......................................16 + 5.3.3. Stateless DHCPv6 ...................................16 + 5.3.4. Well-known Addresses ...............................17 + 5.3.5. Recommendations ....................................18 + 5.4. Unmanaged Network .........................................18 + 5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18 + 5.4.2. Case B: A Dual-stack Gateway Connected to a + Dual-stack ISP .....................................19 + 5.4.3. Case C: A Dual-stack Gateway Connected to + an IPv4-only ISP ...................................19 + 5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19 + 6. Security Considerations ........................................19 + 6.1. RA Option .................................................20 + 6.2. DHCPv6 Option .............................................21 + 6.3. Well-known Anycast Addresses ..............................21 + 7. Contributors ...................................................21 + 8. Acknowledgements ...............................................23 + 9. References .....................................................23 + 9.1. Normative References ......................................23 + 9.2. Informative References ....................................23 + + + + +Jeong Informational [Page 2] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +1. Introduction + + Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address + Autoconfiguration provide ways to configure either fixed or mobile + nodes with one or more IPv6 addresses, default routes, and some other + parameters [1][2]. To support the access to additional services in + the Internet that are identified by a DNS name, such as a web server, + the configuration of at least one recursive DNS server is also needed + for DNS name resolution. + + This document describes three approaches of recursive DNS server + address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6 + option [3]-[5], and (c) well-known anycast addresses for recursive + DNS servers [7]. Also, it suggests the applicable scenarios for four + kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP + network, and (d) unmanaged network. + + This document is just an analysis of each possible approach, and it + does not recommend a particular approach or combination of + approaches. Some approaches may even not be adopted at all as a + result of further discussion. + + Therefore, the objective of this document is to help the audience + select the approaches suitable for IPv6 host configuration of + recursive DNS servers. + +2. Terminology + + This document uses the terminology described in [1]-[7]. In + addition, a new term is defined below: + + o Recursive DNS Server (RDNSS): Server which provides a recursive + DNS resolution service. + +3. IPv6 DNS Configuration Approaches + + In this section, the operational attributes of the three solutions + are described in detail. + +3.1. RA Option + + The RA approach defines a new ND option, called the RDNSS option, + that contains a recursive DNS server address [6]. Existing ND + transport mechanisms (i.e., advertisements and solicitations) are + used. This works in the same way that nodes learn about routers and + prefixes. An IPv6 host can configure the IPv6 addresses of one or + more RDNSSes via RA message periodically sent by a router or + solicited by a Router Solicitation (RS). + + + +Jeong Informational [Page 3] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + This approach needs RDNSS information to be configured in the routers + doing the advertisements. The configuration of RDNSS addresses can + be performed manually by an operator or in other ways, such as + automatic configuration through a DHCPv6 client running on the + router. An RA message with one RDNSS option can include as many + RDNSS addresses as needed [6]. + + Through the ND protocol and RDNSS option, along with a prefix + information option, an IPv6 host can perform network configuration of + its IPv6 address and RDNSS simultaneously [1][2]. The RA option for + RDNSS can be used on any network that supports the use of ND. + + The RA approach is useful in some mobile environments where the + addresses of the RDNSSes are changing because the RA option includes + a lifetime field that allows client to use RDNSSes nearer to the + client. This can be configured to a value that will require the + client to time out the entry and switch over to another RDNSS address + [6]. However, from the viewpoint of implementation, the lifetime + field would seem to make matters a bit more complex. Instead of just + writing to a DNS configuration file, such as resolv.conf for the list + of RDNSS addresses, we have to have a daemon around (or a program + that is called at the defined intervals) that keeps monitoring the + lifetime of RDNSSes all the time. + + The preference value of RDNSS, included in the RDNSS option, allows + IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this + can be used for the load balancing of RDNSSes. + +3.1.1. Advantages + + The RA option for RDNSS has a number of advantages. These include: + + 1. The RA option is an extension of existing ND/Autoconfig + mechanisms [1][2] and does not require a change in the base ND + protocol. + + 2. This approach, like ND, works well on a variety of link types, + including point-to-point links, point-to-multipoint, and + multipoint-to-multipoint (i.e., Ethernet LANs). RFC 2461 [1] + states, however, that there may be some link types on which ND is + not feasible; on such links, some other mechanisms will be needed + for DNS configuration. + + 3. All the information a host needs to run the basic Internet + applications (such as the email, web, ftp, etc.) can be obtained + with the addition of this option to ND and address + autoconfiguration. The use of a single mechanism is more + reliable and easier to provide than when the RDNSS information is + + + +Jeong Informational [Page 4] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + learned via another protocol mechanism. Debugging problems when + multiple protocol mechanisms are being used is harder and much + more complex. + + 4. This mechanism works over a broad range of scenarios and + leverages IPv6 ND. This works well on links that are high + performance (e.g., Ethernet LANs) and low performance (e.g., + cellular networks). In the latter case, by combining the RDNSS + information with the other information in the RA, the host can + learn all the information needed to use most Internet + applications, such as the web, in a single packet. This not only + saves bandwidth, but also minimizes the delay needed to learn the + RDNSS information. + + 5. The RA approach could be used as a model for similar types of + configuration information. New RA options for other server + addresses, such as NTP server address, that are common to all + clients on a subnet would be easy to define. + +3.1.2. Disadvantages + + 1. ND is mostly implemented in the kernel of the operating system. + Therefore, if ND supports the configuration of some additional + services, such as DNS servers, ND should be extended in the + kernel and complemented by a user-land process. DHCPv6, however, + has more flexibility for the extension of service discovery + because it is an application layer protocol. + + 2. The current ND framework should be modified to facilitate the + synchronization between another ND cache for RDNSSes in the + kernel space and the DNS configuration file in the user space. + Because it is unacceptable to write and rewrite to the DNS + configuration file (e.g., resolv.conf) from the kernel, another + approach is needed. One simple approach to solve this is to have + a daemon listening to what the kernel conveys, and to have the + daemon do these steps, but such a daemon is not needed with the + current ND framework. + + 3. It is necessary to configure RDNSS addresses at least at one + router on every link where this information needs to be + configured via the RA option. + +3.1.3. Observations + + The proposed RDNSS RA option, along with the IPv6 ND and + Autoconfiguration, allows a host to obtain all of the information it + needs to access basic Internet services like the web, email, ftp, + etc. This is preferable in the environments where hosts use RAs to + + + +Jeong Informational [Page 5] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + autoconfigure their addresses and all the hosts on the subnet share + the same router and server addresses. If the configuration + information can be obtained from a single mechanism, it is preferable + because it does not add additional delay, and because it uses a + minimum of bandwidth. Environments like this include homes, public + cellular networks, and enterprise environments where no per host + configuration is needed. + + DHCPv6 is preferable where it is being used for address configuration + and if there is a need for host specific configuration [3]-[5]. + Environments like this are most likely to be the enterprise + environments where the local administration chooses to have per host + configuration control. + +3.2. DHCPv6 Option + + DHCPv6 [3] includes the "DNS Recursive Name Server" option, through + which a host can obtain a list of IP addresses of recursive DNS + servers [5]. The DNS Recursive Name Server option carries a list of + IPv6 addresses of RDNSSes to which the host may send DNS queries. + The DNS servers are listed in the order of preference for use by the + DNS resolver on the host. + + The DNS Recursive Name Server option can be carried in any DHCPv6 + Reply message, in response to either a Request or an Information + request message. Thus, the DNS Recursive Name Server option can be + used either when DHCPv6 is used for address assignment, or when + DHCPv6 is used only for other configuration information as stateless + DHCPv6 [4]. + + Stateless DHCPv6 can be deployed either by using DHCPv6 servers + running on general-purpose computers, or on router hardware. Several + router vendors currently implement stateless DHCPv6 servers. + Deploying stateless DHCPv6 in routers has the advantage that no + special hardware is required, and it should work well for networks + where DHCPv6 is needed for very straightforward configuration of + network devices. + + However, routers can also act as DHCPv6 relay agents. In this case, + the DHCPv6 server need not be on the router; it can be on a general + purpose computer. This has the potential to give the operator of the + DHCPv6 server more flexibility in how the DHCPv6 server responds to + individual clients that can easily be given different configuration + information based on their identity, or for any other reason. + Nothing precludes adding this flexibility to a router, but generally, + in current practice, DHCP servers running on general-purpose hosts + tend to have more configuration options than those that are embedded + in routers. + + + +Jeong Informational [Page 6] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 + clients that use a stateful configuration assignment. To do this, + the DHCPv6 server sends a Reconfigure message to the client. The + client validates the Reconfigure message, and then contacts the + DHCPv6 server to obtain updated configuration information. By using + this mechanism, it is currently possible to propagate new + configuration information to DHCPv6 clients as this information + changes. + + The DHC Working Group has standardized an additional mechanism + through which configuration information, including the list of + RDNSSes, can be updated. The lifetime option for DHCPv6 [8] assigns + a lifetime to configuration information obtained through DHCPv6. At + the expiration of the lifetime, the host contacts the DHCPv6 server + to obtain updated configuration information, including the list of + RDNSSes. This lifetime gives the network administrator another + mechanism to configure hosts with new RDNSSes by controlling the time + at which the host refreshes the list. + + The DHC Working Group has also discussed the possibility of defining + an extension to DHCPv6 that would allow the use of multicast to + provide configuration information to multiple hosts with a single + DHCPv6 message. Because of the lack of deployment experience, the WG + has deferred consideration of multicast DHCPv6 configuration at this + time. Experience with DHCPv4 has not identified a requirement for + multicast message delivery, even in large service provider networks + with tens of thousands of hosts that may initiate a DHCPv4 message + exchange simultaneously. + +3.2.1. Advantages + + The DHCPv6 option for RDNSS has a number of advantages. These + include: + + 1. DHCPv6 currently provides a general mechanism for conveying + network configuration information to clients. Configuring DHCPv6 + servers in this way allows the network administrator to configure + RDNSSes, the addresses of other network services, and location- + specific information, such as time zones. + + 2. As a consequence, when the network administrator goes to + configure DHCPv6, all the configuration information can be + managed through a single service, typically with a single user + interface and a single configuration database. + + + + + + + +Jeong Informational [Page 7] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + 3. DHCPv6 allows for the configuration of a host with information + specific to that host, so that hosts on the same link can be + configured with different RDNSSes and with other configuration + information. + + 4. A mechanism exists for extending DHCPv6 to support the + transmission of additional configuration that has not yet been + anticipated. + + 5. Hosts that require other configuration information, such as the + addresses of SIP servers and NTP servers, are likely to need + DHCPv6 for other configuration information. + + 6. The specification for configuration of RDNSSes through DHCPv6 is + available as an RFC. No new protocol extensions (such as new + options) are necessary. + + 7. Interoperability among independent implementations has been + demonstrated. + +3.2.2. Disadvantages + + The DHCPv6 option for RDNSS has a few disadvantages. These include: + + 1. Update currently requires a message from server (however, see + [8]). + + 2. Because DNS information is not contained in RA messages, the host + must receive two messages from the router and must transmit at + least one message to the router. On networks where bandwidth is + at a premium, this is a disadvantage, although on most networks + it is not a practical concern. + + 3. There is an increased latency for initial configuration. In + addition to waiting for an RA message, the client must now + exchange packets with a DHCPv6 server. Even if it is locally + installed on a router, this will slightly extend the time + required to configure the client. For clients that are moving + rapidly from one network to another, this will be a disadvantage. + + + + + + + + + + + + +Jeong Informational [Page 8] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +3.2.3. Observations + + In the general case, on general-purpose networks, stateless DHCPv6 + provides significant advantages and no significant disadvantages. + Even in the case where bandwidth is at a premium and low latency is + desired, if hosts require other configuration information in addition + to a list of RDNSSes or if hosts must be configured selectively, + those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive + name server option will be advantageous. + + However, we are aware of some applications where it would be + preferable to put the RDNSS information into an RA packet; for + example, in a mobile phone network, where bandwidth is at a premium + and extremely low latency is desired. The DNS configuration based on + RA should be standardized so as to allow these special applications + to be handled using DNS information in the RA packet. + +3.3. Well-known Anycast Addresses + + Anycast uses the same routing system as unicast [9]. However, + administrative entities are local ones. The local entities may + accept unicast routes (including default routes) to anycast servers + from adjacent entities. The administrative entities should not + advertise their peer routes to their internal anycast servers, if + they want to prohibit external access from some peers to the servers. + If some advertisement is inevitable (such as the case with default + routes), the packets to the servers should be blocked at the boundary + of the entities. Thus, for this anycast, not only unicast routing + but also unicast ND protocols can be used as is. + + First of all, the well-known anycast addresses approach is much + different from that discussed by the IPv6 Working Group in the past + [7]. Note that "anycast" in this memo is simpler than that of RFC + 1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to + have multiple servers on a single link sharing an anycast address. + That is, on a link, an anycast address is assumed to be unique. DNS + clients today already have redundancy by having multiple well-known + anycast addresses configured as RDNSS addresses. There is no point + in having multiple RDNSSes sharing an anycast address on a single + link. + + The approach with well-known anycast addresses is to set multiple + well-known anycast addresses in clients' resolver configuration files + from the beginning as, say, factory default. Thus, there is no + transport mechanism and no packet format [7]. + + An anycast address is an address shared by multiple servers (in this + case, the servers are RDNSSes). A request from a client to the + + + +Jeong Informational [Page 9] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + anycast address is routed to a server selected by the routing system. + However, it is a bad idea to mandate "site" boundary on anycast + addresses, because most users do not have their own servers and want + to access their ISPs across their site boundaries. Larger sites may + also depend on their ISPs or may have their own RDNSSes within "site" + boundaries. + +3.3.1. Advantages + + The basic advantage of the well-known addresses approach is that it + uses no transport mechanism. Thus, the following apply: + + 1. There is no delay to get the response and no further delay by + packet losses. + + 2. The approach can be combined with any other configuration + mechanisms, such as the RA-based approach and DHCP-based + approach, as well as the factory default configuration. + + 3. The approach works over any environment where DNS works. + + Another advantage is that this approach only needs configuration of + the DNS servers as a router (or configuration of a proxy router). + Considering that DNS servers do need configuration, the amount of + overall configuration effort is proportional to the number of DNS + servers and it scales linearly. Note that, in the simplest case, + where a subscriber to an ISP does not have a DNS server, the + subscriber naturally accesses DNS servers of the ISP, even though the + subscriber and the ISP do nothing and there is no protocol to + exchange DNS server information between the subscriber and the ISP. + +3.3.2. Disadvantages + + The well-known anycast addresses approach requires that DNS servers + (or routers near to them as a proxy) act as routers to advertise + their anycast addresses to the routing system, which requires some + configuration (see the last paragraph of the previous section on the + scalability of the effort). In addition, routers at the boundary of + the "site" might need the configuration of route filters to prevent + providing DNS services for parties outside the "site" and the + possibility of denial of service attacks on the internal DNS + infrastructure. + +3.3.3. Observations + + If other approaches are used in addition, the well-known anycast + addresses should also be set in RA or DHCP configuration files to + reduce the configuration effort of users. + + + +Jeong Informational [Page 10] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + The redundancy by multiple RDNSSes is better provided by multiple + servers with different anycast addresses than by multiple servers + sharing the same anycast address, because the former approach allows + stale servers to generate routes to their anycast addresses. Thus, + in a routing domain (or domains sharing DNS servers), there will be + only one server with an anycast address unless the domain is so large + that load distribution is necessary. + + Small ISPs will operate one RDNSS at each anycast address that is + shared by all the subscribers. Large ISPs may operate multiple + RDNSSes at each anycast address to distribute and reduce load, where + the boundary between RDNSSes may be fixed (redundancy is still + provided by multiple addresses) or change dynamically. DNS packets + with the well-known anycast addresses are not expected (though not + prohibited) to cross ISP boundaries, as ISPs are expected to be able + to take care of themselves. + + Because "anycast" in this memo is simpler than that of RFC 1546 [9] + and RFC 3513 [10], where it is assumed to be administratively + prohibited to have multiple servers on a single link sharing an + anycast address, anycast in this memo should be implemented as + UNICAST of RFC 2461 [1] and RFC 3513 [10]. As a result, ND-related + instability disappears. Thus, in the well-known anycast addresses + approach, anycast can and should use the anycast address as a source + unicast (according to RFC 3513 [10]) address of packets of UDP and + TCP responses. With TCP, if a route flips and packets to an anycast + address are routed to a new server, it is expected that the flip is + detected by ICMP or sequence number inconsistency, and that the TCP + connection is reset and retried. + +4. Interworking among IPv6 DNS Configuration Approaches + + Three approaches can work together for IPv6 host configuration of + RDNSS. This section shows a consideration on how these approaches + can interwork. + + For ordering between RA and DHCP approaches, the O (Other stateful + configuration) flag in the RA message can be used [6][28]. If no + RDNSS option is included, an IPv6 host may perform DNS configuration + through DHCPv6 [3]-[5] regardless of whether the O flag is set or + not. + + The well-known anycast addresses approach fully interworks with the + other approaches. That is, the other approaches can remove the + configuration effort on servers by using the well-known addresses as + the default configuration. Moreover, the clients preconfigured with + the well-known anycast addresses can be further configured to use + other approaches to override the well-known addresses, if the + + + +Jeong Informational [Page 11] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + configuration information from other approaches is available. + Otherwise, all the clients need to have the well-known anycast + addresses preconfigured. In order to use the anycast approach along + with two other approaches, there are three choices as follows: + + 1. The first choice is that well-known addresses are used as last + resort, when an IPv6 host cannot get RDNSS information through RA + and DHCP. The well-known anycast addresses have to be + preconfigured in all of IPv6 hosts' resolver configuration files. + + 2. The second is that an IPv6 host can configure well-known + addresses as the most preferable in its configuration file even + though either an RA option or DHCP option is available. + + 3. The last is that the well-known anycast addresses can be set in + RA or DHCP configuration to reduce the configuration effort of + users. According to either the RA or DHCP mechanism, the well- + known addresses can be obtained by an IPv6 host. Because this + approach is the most convenient for users, the last option is + recommended. + + Note: This section does not necessarily mean that this document + suggests adopting all of these three approaches and making them + interwork in the way described here. In fact, as a result of further + discussion some approaches may not even be adopted at all. + +5. Deployment Scenarios + + Regarding the DNS configuration on the IPv6 host, several mechanisms + are being considered by the DNSOP Working Group, such as RA option, + DHCPv6 option, and well-known preconfigured anycast addresses as of + today, and this document is a final result from the long thread. In + this section, we suggest four applicable scenarios of three + approaches for IPv6 DNS configuration. + + Note: In the applicable scenarios, authors do not implicitly push any + specific approaches into the restricted environments. No enforcement + is in each scenario, and all mentioned scenarios are probable. The + main objective of this work is to provide a useful guideline for IPv6 + DNS configuration. + +5.1. ISP Network + + A characteristic of an ISP network is that multiple Customer Premises + Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) + routers and that each PE connects multiple CPE devices to the + backbone network infrastructure [11]. The CPEs may be hosts or + routers. + + + +Jeong Informational [Page 12] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + If the CPE is a router, there is a customer network that is connected + to the ISP backbone through the CPE. Typically, each customer + network gets a different IPv6 prefix from an IPv6 PE router, but the + same RDNSS configuration will be distributed. + + This section discusses how the different approaches to distributing + DNS information are compared in an ISP network. + +5.1.1. RA Option Approach + + When the CPE is a host, the RA option for RDNSS can be used to allow + the CPE to get RDNSS information and /64 prefix information for + stateless address autoconfiguration at the same time when the host is + attached to a new subnet [6]. Because an IPv6 host must receive at + least one RA message for stateless address autoconfiguration and + router configuration, the host could receive RDNSS configuration + information in the RA without the overhead of an additional message + exchange. + + When the CPE is a router, the CPE may accept the RDNSS information + from the RA on the interface connected to the ISP and copy that + information into the RAs advertised in the customer network. + + This approach is more valuable in the mobile host scenario, in which + the host must receive at least an RA message for detecting a new + network, than in other scenarios generally, although the + administrator should configure RDNSS information on the routers. + Secure ND [12] can provide extended security when RA messages are + used. + +5.1.2. DHCPv6 Option Approach + + DHCPv6 can be used for RDNSS configuration through the use of the DNS + option, and can provide other configuration information in the same + message with RDNSS configuration [3]-[5]. The DHCPv6 DNS option is + already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or + stateless DHCP [4] is not nearly as complex as a full DHCPv6 + implementation. DHCP is a client-server model protocol, so ISPs can + handle user identification on its network intentionally; also, + authenticated DHCP [13] can be used for secure message exchange. + + The expected model for deployment of IPv6 service by ISPs is to + assign a prefix to each customer, which will be used by the customer + gateway to assign a /64 prefix to each network in the customer's + network. Prefix delegation with DHCP (DHCPv6 PD) has already been + adopted by ISPs for automating the assignment of the customer prefix + to the customer gateway [15]. DNS configuration can be carried in + the same DHCPv6 message exchange used for DHCPv6 to provide that + + + +Jeong Informational [Page 13] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + information efficiently, along with any other configuration + information needed by the customer gateway or customer network. This + service model can be useful to Home or SOHO subscribers. The Home or + SOHO gateway, which is a customer gateway for ISP, can then pass that + RDNSS configuration information to the hosts in the customer network + through DHCP. + +5.1.3. Well-known Anycast Addresses Approach + + The well-known anycast addresses approach is also a feasible and + simple mechanism for ISP [7]. The use of well-known anycast + addresses avoids some of the security risks in rogue messages sent + through an external protocol such as RA or DHCPv6. The configuration + of hosts for the use of well-known anycast addresses requires no + protocol or manual configuration, but the configuration of routing + for the anycast addresses requires intervention on the part of the + network administrator. Also, the number of special addresses would + be equal to the number of RDNSSes that could be made available to + subscribers. + +5.2. Enterprise Network + + An enterprise network is defined as a network that has multiple + internal links, one or more router connections to one or more + providers, and is actively managed by a network operations entity + [14]. An enterprise network can get network prefixes from an ISP by + either manual configuration or prefix delegation [15]. In most + cases, because an enterprise network manages its own DNS domains, it + operates its own DNS servers for the domains. These DNS servers + within enterprise networks process recursive DNS name resolution + requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the + enterprise network can be performed as it is in Section 4, in which + three approaches can be used together as follows: + + 1. An IPv6 host can decide which approach is or may be used in its + subnet with the O flag in RA message [6][28]. As the first + choice in Section 4, well-known anycast addresses can be used as + a last resort when RDNSS information cannot be obtained through + either an RA option or a DHCP option. This case needs IPv6 hosts + to preconfigure the well-known anycast addresses in their DNS + configuration files. + + 2. When the enterprise prefers the well-known anycast approach to + others, IPv6 hosts should preconfigure the well-known anycast + addresses as it is in the first choice. + + 3. The last choice, a more convenient and transparent way, does not + need IPv6 hosts to preconfigure the well-known anycast addresses + + + +Jeong Informational [Page 14] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + because the addresses are delivered to IPv6 hosts via either the + RA option or DHCPv6 option as if they were unicast addresses. + This way is most recommended for the sake of the user's + convenience. + +5.3. 3GPP Network + + The IPv6 DNS configuration is a missing part of IPv6 + autoconfiguration and an important part of the basic IPv6 + functionality in the 3GPP User Equipment (UE). The higher-level + description of the 3GPP architecture can be found in [16], and + transition to IPv6 in 3GPP networks is analyzed in [17] and [18]. + + In the 3GPP architecture, there is a dedicated link between the UE + and the GGSN called the Packet Data Protocol (PDP) Context. This + link is created through the PDP Context activation procedure [19]. + There is a separate PDP context type for IPv4 and IPv6 traffic. If a + 3GPP UE user is communicating by using IPv6 (i.e., by having an + active IPv6 PDP context), it cannot be assumed that the user + simultaneously has an active IPv4 PDP context, and DNS queries could + be done using IPv4. A 3GPP UE can thus be an IPv6 node, and somehow + it needs to discover the address of the RDNSS. Before IP-based + services (e.g., web browsing or e-mail) can be used, the IPv6 (and + IPv4) RDNSS addresses need to be discovered in the 3GPP UE. + + Section 5.3.1 briefly summarizes currently available mechanisms in + 3GPP networks and recommendations. 5.3.2 analyzes the Router + Advertisement-based solution, 5.3.3 analyzes the Stateless DHCPv6 + mechanism, and 5.3.4 analyzes the well-known addresses approach. + Section 5.3.5 summarizes the recommendations. + +5.3.1. Currently Available Mechanisms and Recommendations + + 3GPP has defined a mechanism in which RDNSS addresses can be received + in the PDP context activation (a control plane mechanism). That is + called the Protocol Configuration Options Information Element (PCO- + IE) mechanism [20]. The RDNSS addresses can also be received over + the air (using text messages) or typed in manually in the UE. Note + that the two last mechanisms are not very well scalable. The UE user + most probably does not want to type IPv6 RDNSS addresses manually in + the user's UE. The use of well-known addresses is briefly discussed + in section 5.3.4. + + It is seen that the mechanisms above most probably are not sufficient + for the 3GPP environment. IPv6 is intended to operate in a zero- + configuration manner, no matter what the underlying network + infrastructure is. Typically, the RDNSS address is needed to make an + IPv6 node operational, and the DNS configuration should be as simple + + + +Jeong Informational [Page 15] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + as the address autoconfiguration mechanism. Note that there will be + additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP- + specific DNS configuration mechanisms (such as PCO-IE [20]) do not + work for those IP interfaces. In other words, a good IPv6 DNS + configuration mechanism should also work in a multi-access network + environment. + + From a 3GPP point of view, the best IPv6 DNS configuration solution + is feasible for a very large number of IPv6-capable UEs (even + hundreds of millions in one operator's network), is automatic, and + thus requires no user action. It is suggested that a lightweight, + stateless mechanism be standardized for use in all network + environments. The solution could then be used for 3GPP, 3GPP2, and + other access network technologies. Thus, not only is a light, + stateless IPv6 DNS configuration mechanism needed in 3GPP networks, + but also 3GPP networks and UEs would certainly benefit from the new + mechanism. + +5.3.2. RA Extension + + Router Advertisement extension [6] is a lightweight IPv6 DNS + configuration mechanism that requires minor changes in the 3GPP UE + IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in + the 3GPP architecture) IPv6 stack. This solution can be specified in + the IETF (no action is needed in the 3GPP) and taken in use in 3GPP + UEs and GGSNs. + + In this solution, an IPv6-capable UE configures DNS information via + an RA message sent by its default router (GGSN); i.e., the RDNSS + option for a recursive DNS server is included in the RA message. + This solution is easily scalable for a very large number of UEs. The + operator can configure the RDNSS addresses in the GGSN as a part of + normal GGSN configuration. The IPv6 RDNSS address is received in the + Router Advertisement, and an extra Round Trip Time (RTT) for asking + RDNSS addresses can be avoided. + + When one considers the cons, this mechanism still requires + standardization effort in the IETF, and the end nodes and routers + need to support this mechanism. The equipment software update + should, however, be pretty straightforward, and new IPv6 equipment + could support RA extension already from the beginning. + +5.3.3. Stateless DHCPv6 + + A DHCPv6-based solution needs the implementation of Stateless DHCP + [4] and DHCPv6 DNS options [5] in the UE, and a DHCPv6 server in the + operator's network. A possible configuration is such that the GGSN + works as a DHCP relay. + + + +Jeong Informational [Page 16] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + The pros of a stateless DHCPv6-based solution are: + + 1. Stateless DHCPv6 is a standardized mechanism. + + 2. DHCPv6 can be used for receiving configuration information other + than RDNSS addresses; e.g., SIP server addresses. + + 3. DHCPv6 works in different network environments. + + 4. When DHCPv6 service is deployed through a single, centralized + server, the RDNSS configuration information can be updated by the + network administrator at a single source. + + Some issues with DHCPv6 in 3GPP networks are listed below: + + 1. DHCPv6 requires an additional server in the network unless the + (Stateless) DHCPv6 functionality is integrated into an existing + router. This means that there might be one additional server to + be maintained. + + 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing + (3GPP Stateless Address Autoconfiguration is typically used) and + is not automatically implemented in 3GPP IPv6 UEs. + + 3. Scalability and reliability of DHCPv6 in very large 3GPP networks + (with tens or hundreds of millions of UEs) may be an issue; at + least the redundancy needs to be taken care of. However, if the + DHCPv6 service is integrated into the network elements, such as a + router operating system, scalability and reliability is + comparable with other DNS configuration approaches. + + 4. It is sub-optimal to utilize the radio resources in 3GPP networks + for DHCPv6 messages if there is a simpler alternative is + available. + + * The use of stateless DHCPv6 adds one round-trip delay to the + case in which the UE can start transmitting data right after + the Router Advertisement. + + 5. If the DNS information (suddenly) changes, Stateless DHCPv6 + cannot automatically update the UE; see [21]. + +5.3.4. Well-known Addresses + + Using well-known addresses is also a feasible and light mechanism for + 3GPP UEs. Those well-known addresses can be preconfigured in the UE + software and the operator can make the corresponding configuration on + the network side. Thus, this is a very easy mechanism for the UE, + + + +Jeong Informational [Page 17] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + but it requires some configuration work in the network. When using + well-known addresses, UE forwards queries to any of the preconfigured + addresses. In the current proposal [7], IPv6 anycast addresses are + suggested. + + Note: An IPv6 DNS configuration proposal, based on the use of well- + known site-local addresses, was developed by the IPv6 Working Group; + it was seen as a feasible mechanism for 3GPP UEs, although no IETF + consensus was reached on this proposal. In the end, the deprecation + of IPv6 site-local addresses made it impossible to standardize a + mechanism that uses site-local addresses as well-known addresses. + However, as of this writing, this mechanism is implemented in some + operating systems and 3GPP UEs as a last resort of IPv6 DNS + configuration. + +5.3.5. Recommendations + + It is suggested that a lightweight, stateless DNS configuration + mechanism be specified as soon as possible. From a 3GPP UE and + network point of view, the Router Advertisement-based mechanism looks + most promising. The sooner a light, stateless mechanism is + specified, the sooner we can stop using well-known site-local + addresses for IPv6 DNS configuration. + +5.4. Unmanaged Network + + There are four deployment scenarios of interest in unmanaged networks + [22]: + + 1. A gateway that does not provide IPv6 at all, + + 2. A dual-stack gateway connected to a dual-stack ISP, + + 3. A dual-stack gateway connected to an IPv4-only ISP, and + + 4. A gateway connected to an IPv6-only ISP. + +5.4.1. Case A: Gateway Does Not Provide IPv6 at All + + In this case, the gateway does not provide IPv6; the ISP may or may + not provide IPv6. Automatic or Configured tunnels are the + recommended transition mechanisms for this scenario. + + The case where dual-stack hosts behind an NAT need access to an IPv6 + RDNSS cannot be entirely ruled out. The DNS configuration mechanism + has to work over the tunnel, and the underlying tunneling mechanism + could implement NAT traversal. The tunnel server assumes the role of + a relay (for both DHCP and well-known anycast addresses approaches). + + + +Jeong Informational [Page 18] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + The RA-based mechanism is relatively straightforward in its + operation, assuming the tunnel server is also the IPv6 router + emitting RAs. The well-known anycast addresses approach also seems + simple in operation across the tunnel, but the deployment model using + well-known anycast addresses in a tunneled environment is unclear or + not well understood. + +5.4.2. Case B: A Dual-stack Gateway Connected to a Dual-stack ISP + + This is similar to a typical IPv4 home user scenario, where DNS + configuration parameters are obtained using DHCP. The exception is + that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where + the DHCP server is stateful (it maintains the state for clients). + +5.4.3. Case C: A Dual-stack Gateway Connected to an IPv4-only ISP + + This is similar to Case B. If a gateway provides IPv6 connectivity + by managing tunnels, then it is also supposed to provide access to an + RDNSS. Like this, the tunnel for IPv6 connectivity originates from + the dual-stack gateway instead of from the host. + +5.4.4. Case D: A Gateway Connected to an IPv6-only ISP + + This is similar to Case B. + +6. Security Considerations + + As security requirements depend solely on applications and differ + from application to application, there can be no generic requirement + defined at the IP or application layer for DNS. + + However, note that cryptographic security requires configured secret + information and that full autoconfiguration and cryptographic + security are mutually exclusive. People insisting on secure, full + autoconfiguration will get false security, false autoconfiguration, + or both. + + In some deployment scenarios [17], where cryptographic security is + required for applications, the secret information for the + cryptographic security is preconfigured, through which application- + specific configuration data, including those for DNS, can be securely + configured. Note that if applications requiring cryptographic + security depend on DNS, the applications also require cryptographic + security to DNS. Therefore, the full autoconfiguration of DNS is not + acceptable. + + However, with full autoconfiguration, weaker but still reasonable + security is being widely accepted and will continue to be acceptable. + + + +Jeong Informational [Page 19] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + That is, with full autoconfiguration, which means there is no + cryptographic security for the autoconfiguration, it is already + assumed that the local environment is secure enough that the + information from the local autoconfiguration server has acceptable + security even without cryptographic security. Thus, the + communication between the local DNS client and local DNS server has + acceptable security. + + In autoconfiguring recursive servers, DNSSEC may be overkill, because + DNSSEC [23]-[25] needs the configuration and reconfiguration of + clients at root key roll-over [26][27]. Even if additional keys for + secure key roll-over are added at the initial configuration, they are + as vulnerable as the original keys to some forms of attack, such as + social hacking. Another problem of using DNSSEC and + autoconfiguration together is that DNSSEC requires secure time, which + means secure communication with autoconfigured time servers, which + requires configured secret information. Therefore, in order that the + autoconfiguration may be secure, configured secret information is + required. + + If DNSSEC [23]-[25] is used and the signatures are verified on the + client host, the misconfiguration of a DNS server may simply be + denial of service. Also, if local routing environment is not + reliable, clients may be directed to a false resolver with the same + IP address as the true one. + +6.1. RA Option + + The security of RA option for RDNSS is the same as the ND protocol + security [1][6]. The RA option does not add any new vulnerability. + + Note that the vulnerability of ND is not worse and is a subset of the + attacks that any node attached to a LAN can do independently of ND. + A malicious node on a LAN can promiscuously receive packets for any + router's MAC address and send packets with the router's MAC address + as the source MAC address in the L2 header. As a result, the L2 + switches send packets addressed to the router to the malicious node. + Also, this attack can send redirects that tell the hosts to send + their traffic somewhere else. The malicious node can send + unsolicited RA or NA replies, answer RS or NS requests, etc. All of + this can be done independently of implementing ND. Therefore, the RA + option for RDNSS does not add to the vulnerability. + + Security issues regarding the ND protocol were discussed by the IETF + SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for + the ND security has been published [12]. + + + + + +Jeong Informational [Page 20] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +6.2. DHCPv6 Option + + The DNS Recursive Name Server option may be used by an intruder DHCP + server to cause DHCP clients to send DNS queries to an intruder DNS + recursive name server [5]. The results of these misdirected DNS + queries may be used to spoof DNS names. + + To avoid attacks through the DNS Recursive Name Server option, the + DHCP client SHOULD require DHCP authentication (see "Authentication + of DHCP messages" in RFC 3315 [3][13]) before installing a list of + DNS recursive name servers obtained through authenticated DHCP. + +6.3. Well-known Anycast Addresses + + The well-known anycast addresses approach is not a protocol, thus + there is no need to secure the protocol itself. + + However, denial of service attacks on the DNS resolver system might + be easier to achieve as the anycast addresses used are by definition + well known. + +7. Contributors + + Ralph Droms + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxboro, MA 01719 + US + + Phone: +1 978 936 1674 + EMail: rdroms@cisco.com + + + Robert M. Hinden + Nokia + 313 Fairchild Drive + Mountain View, CA 94043 + US + + Phone: +1 650 625 2004 + EMail: bob.hinden@nokia.com + + + + + + + + + + +Jeong Informational [Page 21] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + Ted Lemon + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94043 + US + + EMail: Ted.Lemon@nominum.com + + Masataka Ohta + Tokyo Institute of Technology + 2-12-1, O-okayama, Meguro-ku + Tokyo 152-8552 + Japan + + Phone: +81 3 5734 3299 + Fax: +81 3 5734 3299 + EMail: mohta@necom830.hpcl.titech.ac.jp + + + Soohong Daniel Park + Mobile Platform Laboratory, SAMSUNG Electronics + 416 Maetan-3dong, Yeongtong-Gu + Suwon, Gyeonggi-Do 443-742 + Korea + + Phone: +82 31 200 4508 + EMail: soohong.park@samsung.com + + + Suresh Satapati + Cisco Systems, Inc. + San Jose, CA 95134 + US + + EMail: satapati@cisco.com + + + Juha Wiljakka + Nokia + Visiokatu 3 + FIN-33720, TAMPERE + Finland + + Phone: +358 7180 48372 + EMail: juha.wiljakka@nokia.com + + + + + + +Jeong Informational [Page 22] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +8. Acknowledgements + + This document has greatly benefited from inputs by David Meyer, Rob + Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, + Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. + Also, Tony Bonanno proofread this document. The authors appreciate + their contribution. + +9. References + +9.1. Normative References + + [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)", RFC 2461, December 1998. + + [2] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. + Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 3315, July 2003. + + [4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) + Service for IPv6", RFC 3736, April 2004. + + [5] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December + 2003. + +9.2. Informative References + + [6] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 + Router Advertisement Option for DNS Configuration", Work in + Progress, September 2005. + + [7] Ohta, M., "Preconfigured DNS Server Addresses", Work in + Progress, February 2004. + + [8] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time + Option for Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 4242, November 2005. + + [9] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting + Service", RFC 1546, November 1993. + + [10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + + + +Jeong Informational [Page 23] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + [11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, + "Scenarios and Analysis for Introducing IPv6 into ISP Networks", + RFC 4029, March 2005. + + [12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", + RFC 3118, June 2001. + + [14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June + 2005. + + [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host + Configuration Protocol (DHCP) version 6", RFC 3633, December + 2003. + + [16] Wasserman, M., "Recommendations for IPv6 in Third Generation + Partnership Project (3GPP) Standards", RFC 3314, September 2002. + + [17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC + 3574, August 2003. + + [18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation + Partnership Project (3GPP) Networks", RFC 4215, October 2005. + + [19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); + Service description; Stage 2 (Release 5)", December 2002. + + [20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 + specification; Core network protocols; Stage 3 (Release 5)", + June 2003. + + [21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering + Requirements for Stateless Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 4076, May 2005. + + [22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, + "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April + 2004. + + [23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + +Jeong Informational [Page 24] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + [25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work + in Progress, October 2005. + + [27] Guette, G. and O. Courtay, "Requirements for Automated Key + Rollover in DNSSEC", Work in Progress, January 2005. + + [28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M + and O Flags of IPv6 Router Advertisement", Work in Progress, + March 2005. + +Author's Address + + Jaehoon Paul Jeong (editor) + ETRI/Department of Computer Science and Engineering + University of Minnesota + 117 Pleasant Street SE + Minneapolis, MN 55455 + US + + Phone: +1 651 587 7774 + Fax: +1 612 625 2002 + EMail: jjeong@cs.umn.edu + URI: http://www.cs.umn.edu/~jjeong/ + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Informational [Page 25] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Jeong Informational [Page 26] + diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/doc/rfc/rfc4472.txt similarity index 54% rename from doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt rename to doc/rfc/rfc4472.txt index 1276f9f91d..b396e9a11a 100644 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt +++ b/doc/rfc/rfc4472.txt @@ -2,62 +2,36 @@ -DNS Operations WG A. Durand -Internet-Draft SUN Microsystems, Inc. -Expires: January 17, 2006 J. Ihren + + +Network Working Group A. Durand +Request for Comments: 4472 Comcast +Category: Informational J. Ihren Autonomica P. Savola CSC/FUNET - July 16, 2005 + April 2006 Operational Considerations and Issues with IPv6 DNS - draft-ietf-dnsop-ipv6-dns-issues-11.txt -Status of this Memo +Status of This Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 17, 2006. + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). Abstract This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 - addresses, documentation of known DNS implementation misbehaviour, + addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, - - - -Durand, et al. Expires January 17, 2006 [Page 1] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who @@ -65,63 +39,62 @@ Internet-Draft Considerations with IPv6 DNS July 2005 Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 - 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 - 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 - 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 - 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 - 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 - 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 - 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 - 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 - 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 - 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 - 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 - 4. Recommendations for Service Provisioning using DNS . . . . . . 7 - 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 - 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 - 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 - 4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10 - 4.4.1 TTL With Courtesy Additional Data . . . . . . . . . . 10 - 4.4.2 TTL With Critical Additional Data . . . . . . . . . . 10 - 4.5 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11 - 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11 - 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11 - 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 13 - 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13 - 6. Considerations about Forward DNS Updating . . . . . . . . . . 13 - 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14 - 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. Considerations about Reverse DNS Updating . . . . . . . . . . 15 - 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 15 - 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 - 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 16 - 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18 - 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18 - 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19 - 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19 - 8.2 Renumbering Procedures and Applications' Use of DNS . . . 19 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 20 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . 20 + 1. Introduction ....................................................3 + 1.1. Representing IPv6 Addresses in DNS Records .................3 + 1.2. Independence of DNS Transport and DNS Records ..............4 + 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4 + 1.4. Query Type '*' and A/AAAA Records ..........................4 + 2. DNS Considerations about Special IPv6 Addresses .................5 + 2.1. Limited-Scope Addresses ....................................5 + 2.2. Temporary Addresses ........................................5 + 2.3. 6to4 Addresses .............................................5 + 2.4. Other Transition Mechanisms ................................5 + 3. Observed DNS Implementation Misbehavior .........................6 + 3.1. Misbehavior of DNS Servers and Load-balancers ..............6 + 3.2. Misbehavior of DNS Resolvers ...............................6 -Durand, et al. Expires January 17, 2006 [Page 2] +Durand, et al. Informational [Page 1] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - 11.2 Informative References . . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 - A. Unique Local Addressing Considerations for DNS . . . . . . . . 25 - B. Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25 - B.1 Description of Additional Data Scenarios . . . . . . . . . 26 - B.2 Which Additional Data to Keep, If Any? . . . . . . . . . . 27 - B.3 Discussion of the Potential Problems . . . . . . . . . . . 28 - Intellectual Property and Copyright Statements . . . . . . . . 30 + 4. Recommendations for Service Provisioning Using DNS ..............7 + 4.1. Use of Service Names instead of Node Names .................7 + 4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8 + 4.3. Adding the Records Only When Fully IPv6-enabled ............8 + 4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9 + 4.4.1. TTL with Courtesy Additional Data ...................9 + 4.4.2. TTL with Critical Additional Data ..................10 + 4.5. IPv6 Transport Guidelines for DNS Servers .................10 + 5. Recommendations for DNS Resolver IPv6 Support ..................10 + 5.1. DNS Lookups May Query IPv6 Records Prematurely ............10 + 5.2. Obtaining a List of DNS Recursive Resolvers ...............12 + 5.3. IPv6 Transport Guidelines for Resolvers ...................12 + 6. Considerations about Forward DNS Updating ......................13 + 6.1. Manual or Custom DNS Updates ..............................13 + 6.2. Dynamic DNS ...............................................13 + 7. Considerations about Reverse DNS Updating ......................14 + 7.1. Applicability of Reverse DNS ..............................14 + 7.2. Manual or Custom DNS Updates ..............................15 + 7.3. DDNS with Stateless Address Autoconfiguration .............16 + 7.4. DDNS with DHCP ............................................17 + 7.5. DDNS with Dynamic Prefix Delegation .......................17 + 8. Miscellaneous DNS Considerations ...............................18 + 8.1. NAT-PT with DNS-ALG .......................................18 + 8.2. Renumbering Procedures and Applications' Use of DNS .......18 + 9. Acknowledgements ...............................................19 + 10. Security Considerations .......................................19 + 11. References ....................................................20 + 11.1. Normative References .....................................20 + 11.2. Informative References ...................................22 + Appendix A. Unique Local Addressing Considerations for DNS ........24 + Appendix B. Behavior of Additional Data in IPv4/IPv6 + Environments ..........................................24 + B.1. Description of Additional Data Scenarios ..................24 + B.2. Which Additional Data to Keep, If Any? ....................26 + B.3. Discussion of the Potential Problems ......................27 @@ -138,36 +111,9 @@ Internet-Draft Considerations with IPv6 DNS July 2005 - - - - - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires January 17, 2006 [Page 3] +Durand, et al. Informational [Page 2] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 1. Introduction @@ -189,18 +135,18 @@ Internet-Draft Considerations with IPv6 DNS July 2005 The second section summarizes the special IPv6 address types and how they relate to DNS. The third section describes observed DNS - implementation misbehaviours which have a varying effect on the use - of IPv6 records with DNS. The fourth section lists recommendations - and considerations for provisioning services with DNS. The fifth - section in turn looks at recommendations and considerations about - providing IPv6 support in the resolvers. The sixth and seventh - sections describe considerations with forward and reverse DNS - updates, respectively. The eighth section introduces several - miscellaneous IPv6 issues relating to DNS for which no better place - has been found in this memo. Appendix A looks briefly at the - requirements for unique local addressing. + implementation misbehaviors that have a varying effect on the use of + IPv6 records with DNS. The fourth section lists recommendations and + considerations for provisioning services with DNS. The fifth section + in turn looks at recommendations and considerations about providing + IPv6 support in the resolvers. The sixth and seventh sections + describe considerations with forward and reverse DNS updates, + respectively. The eighth section introduces several miscellaneous + IPv6 issues relating to DNS for which no better place has been found + in this memo. Appendix A looks briefly at the requirements for + unique local addressing. Appendix B discusses additional data. -1.1 Representing IPv6 Addresses in DNS Records +1.1. Representing IPv6 Addresses in DNS Records In the forward zones, IPv6 addresses are represented using AAAA records. In the reverse zones, IPv6 address are represented using @@ -208,24 +154,28 @@ Internet-Draft Considerations with IPv6 DNS July 2005 [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] for background information. - In particular one should note that the use of A6 records in the + In particular, one should note that the use of A6 records in the forward tree or Bitlabels in the reverse tree is not recommended [RFC3363]. Using DNAME records is not recommended in the reverse tree in conjunction with A6 records; the document did not mean to take a stance on any other use of DNAME records [RFC3364]. -1.2 Independence of DNS Transport and DNS Records + + + + + + + +Durand, et al. Informational [Page 3] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +1.2. Independence of DNS Transport and DNS Records DNS has been designed to present a single, globally unique name space [RFC2826]. This property should be maintained, as described here and - - - -Durand, et al. Expires January 17, 2006 [Page 4] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - in Section 1.3. The IP version used to transport the DNS queries and responses is @@ -249,8 +199,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 independent of the protocol version of the resource records; e.g., IPv4 transport can be used to query IPv6 records and vice versa. - -1.3 Avoiding IPv4/IPv6 Name Space Fragmentation +1.3. Avoiding IPv4/IPv6 Name Space Fragmentation To avoid the DNS name space from fragmenting into parts where some parts of DNS are only visible using IPv4 (or IPv6) transport, the @@ -258,7 +207,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 IPv4-enabled, and to ensure that recursive DNS servers support IPv4. See DNS IPv6 transport guidelines [RFC3901] for more information. -1.4 Query Type '*' and A/AAAA Records +1.4. Query Type '*' and A/AAAA Records QTYPE=* is typically only used for debugging or management purposes; it is worth keeping in mind that QTYPE=* ("ANY" queries) only return @@ -267,35 +216,37 @@ Internet-Draft Considerations with IPv6 DNS July 2005 they have all the RRsets. Therefore, to get both A and AAAA records reliably, two separate queries must be made. + + + + + + + +Durand, et al. Informational [Page 4] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + 2. DNS Considerations about Special IPv6 Addresses - There are a couple of IPv6 address types which are somewhat special; + There are a couple of IPv6 address types that are somewhat special; these are considered here. +2.1. Limited-Scope Addresses - - - - -Durand, et al. Expires January 17, 2006 [Page 5] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - -2.1 Limited-scope Addresses - - The IPv6 addressing architecture [RFC3513] includes two kinds of + The IPv6 addressing architecture [RFC4291] includes two kinds of local-use addresses: link-local (fe80::/10) and site-local (fec0::/10). The site-local addresses have been deprecated [RFC3879] but are discussed with unique local addresses in Appendix A. Link-local addresses should never be published in DNS (whether in forward or reverse tree), because they have only local (to the - connected link) significance [I-D.durand-dnsop-dont-publish]. + connected link) significance [WIP-DC2005]. -2.2 Temporary Addresses +2.2. Temporary Addresses - Temporary addresses defined in RFC3041 [RFC3041] (sometimes called + Temporary addresses defined in RFC 3041 [RFC3041] (sometimes called "privacy addresses") use a random number as the interface identifier. Having DNS AAAA records that are updated to always contain the current value of a node's temporary address would defeat the purpose @@ -303,55 +254,54 @@ Internet-Draft Considerations with IPv6 DNS July 2005 possible to return a non-identifiable name (e.g., the IPv6 address in hexadecimal format), as described in [RFC3041]. -2.3 6to4 Addresses +2.3. 6to4 Addresses - 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps - a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. + 6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a + public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. If the reverse DNS population would be desirable (see Section 7.1 for applicability), there are a number of possible ways to do so. - The main proposal [I-D.huston-6to4-reverse-dns] aims to design an - autonomous reverse-delegation system that anyone being capable of - communicating using a specific 6to4 address would be able to set up a - reverse delegation to the corresponding 6to4 prefix. This could be - deployed by e.g., Regional Internet Registries (RIRs). This is a - practical solution, but may have some scalability concerns. + [WIP-H2005] aims to design an autonomous reverse-delegation system + that anyone being capable of communicating using a specific 6to4 + address would be able to set up a reverse delegation to the + corresponding 6to4 prefix. This could be deployed by, e.g., Regional + Internet Registries (RIRs). This is a practical solution, but may + have some scalability concerns. -2.4 Other Transition Mechanisms +2.4. Other Transition Mechanisms 6to4 is mentioned as a case of an IPv6 transition mechanism requiring - special considerations. In general, mechanisms which include a - special prefix may need a custom solution; otherwise, for example + special considerations. In general, mechanisms that include a + special prefix may need a custom solution; otherwise, for example, when IPv4 address is embedded as the suffix or not embedded at all, special solutions are likely not needed. - Note that it does not seem feasible to provide reverse DNS with - another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops- - teredo]; this is because the IPv6 address is based on the IPv4 - address and UDP port of the current NAT mapping which is likely to be - -Durand, et al. Expires January 17, 2006 [Page 6] +Durand, et al. Informational [Page 5] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - relatively short-lived. + Note that it does not seem feasible to provide reverse DNS with + another automatic tunneling mechanism, Teredo [RFC4380]; this is + because the IPv6 address is based on the IPv4 address and UDP port of + the current Network Address Translation (NAT) mapping, which is + likely to be relatively short-lived. -3. Observed DNS Implementation Misbehaviour +3. Observed DNS Implementation Misbehavior - Several classes of misbehaviour in DNS servers, load-balancers and + Several classes of misbehavior in DNS servers, load-balancers, and resolvers have been observed. Most of these are rather generic, not only applicable to IPv6 -- but in some cases, the consequences of - this misbehaviour are extremely severe in IPv6 environments and + this misbehavior are extremely severe in IPv6 environments and deserve to be mentioned. -3.1 Misbehaviour of DNS Servers and Load-balancers +3.1. Misbehavior of DNS Servers and Load-balancers - There are several classes of misbehaviour in certain DNS servers and - load-balancers which have been noticed and documented [RFC4074]: some + There are several classes of misbehavior in certain DNS servers and + load-balancers that have been noticed and documented [RFC4074]: some implementations silently drop queries for unimplemented DNS records types, or provide wrong answers to such queries (instead of a proper negative reply). While typically these issues are not limited to @@ -363,7 +313,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 to query the AAAA records of the name, and after receiving a response, query the A records. This is done in a serial fashion -- if the first query is never responded to (instead of properly - returning a negative answer), significant timeouts will occur. + returning a negative answer), significant time-outs will occur. In consequence, this is an enormous problem for IPv6 deployments, and in some cases, IPv6 support in the software has even been disabled @@ -372,32 +322,31 @@ Internet-Draft Considerations with IPv6 DNS July 2005 The solution is to fix or retire those misbehaving implementations, but that is likely not going to be effective. There are some possible ways to mitigate the problem, e.g., by performing the - lookups somewhat in parallel and reducing the timeout as long as at - least one answer has been received; but such methods remain to be + lookups somewhat in parallel and reducing the time-out as long as at + least one answer has been received, but such methods remain to be investigated; slightly more on this is included in Section 5. -3.2 Misbehaviour of DNS Resolvers +3.2. Misbehavior of DNS Resolvers - Several classes of misbehaviour have also been noticed in DNS - resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem - to directly impair IPv6 use, and are only referred to for - completeness. + Several classes of misbehavior have also been noticed in DNS + resolvers [WIP-LB2005]. However, these do not seem to directly + impair IPv6 use, and are only referred to for completeness. -4. Recommendations for Service Provisioning using DNS + + + +Durand, et al. Informational [Page 6] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +4. Recommendations for Service Provisioning Using DNS When names are added in the DNS to facilitate a service, there are - - - -Durand, et al. Expires January 17, 2006 [Page 7] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - several general guidelines to consider to be able to do it as smoothly as possible. -4.1 Use of Service Names instead of Node Names +4.1. Use of Service Names instead of Node Names It makes sense to keep information about separate services logically separate in the DNS by using a different DNS hostname for each @@ -406,17 +355,17 @@ Internet-Draft Considerations with IPv6 DNS July 2005 o It allows more flexibility and ease for migration of (only a part of) services from one node to another, - o It allows configuring different properties (e.g., TTL) for each - service, and + o It allows configuring different properties (e.g., Time to Live + (TTL)) for each service, and - o It allows deciding separately for each service whether to publish - the IPv6 addresses or not (in cases where some services are more + o It allows deciding separately for each service whether or not to + publish the IPv6 addresses (in cases where some services are more IPv6-ready than others). Using SRV records [RFC2782] would avoid these problems. Unfortunately, those are not sufficiently widely used to be applicable in most cases. Hence an operation technique is to use - service names instead of node names (or, "hostnames"). This + service names instead of node names (or "hostnames"). This operational technique is not specific to IPv6, but required to understand the considerations described in Section 4.2 and Section 4.3. @@ -424,32 +373,37 @@ Internet-Draft Considerations with IPv6 DNS July 2005 For example, assume a node named "pobox.example.com" provides both SMTP and IMAP service. Instead of configuring the MX records to point at "pobox.example.com", and configuring the mail clients to - look up the mail via IMAP from "pobox.example.com", one could use + look up the mail via IMAP from "pobox.example.com", one could use, e.g., "smtp.example.com" for SMTP (for both message submission and mail relaying between SMTP servers) and "imap.example.com" for IMAP. Note that in the specific case of SMTP relaying, the server itself must typically also be configured to know all its names to ensure - loops do not occur. DNS can provide a layer of indirection between - service names and where the service actually is, and using which - addresses. (Obviously, when wanting to reach a specific node, one - should use the hostname rather than a service name.) + that loops do not occur. DNS can provide a layer of indirection + between service names and where the service actually is, and using + which addresses. (Obviously, when wanting to reach a specific node, + one should use the hostname rather than a service name.) -4.2 Separate vs the Same Service Names for IPv4 and IPv6 + + + + + + + + +Durand, et al. Informational [Page 7] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +4.2. Separate vs. the Same Service Names for IPv4 and IPv6 The service naming can be achieved in basically two ways: when a service is named "service.example.com" for IPv4, the IPv6-enabled - service could either be added to "service.example.com", or added - separately under a different name, e.g., in a sub-domain, like, + service could either be added to "service.example.com" or added + separately under a different name, e.g., in a sub-domain like "service.ipv6.example.com". - - - -Durand, et al. Expires January 17, 2006 [Page 8] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - These two methods have different characteristics. Using a different name allows for easier service piloting, minimizing the disturbance to the "regular" users of IPv4 service; however, the service would @@ -469,7 +423,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 confident enough that the service level will not degrade for the users unaware of IPv6. -4.3 Adding the Records Only when Fully IPv6-enabled +4.3. Adding the Records Only When Fully IPv6-enabled The recommendation is that AAAA records for a service should not be added to the DNS until all of following are true: @@ -478,7 +432,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 2. The address is configured on the interface. - 3. The interface is on a link which is connected to the IPv6 + 3. The interface is on a link that is connected to the IPv6 infrastructure. In addition, if the AAAA record is added for the node, instead of @@ -489,32 +443,33 @@ Internet-Draft Considerations with IPv6 DNS July 2005 (e.g., it is not connected to IPv6 Internet) constraint #3 would mean that it should not have an address in the DNS. - Consider the case of two dual-stack nodes, which both have IPv6 + + + + +Durand, et al. Informational [Page 8] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + Consider the case of two dual-stack nodes, which both are IPv6- enabled, but the server does not have (global) IPv6 connectivity. As the client looks up the server's name, only A records are returned (if the recommendations above are followed), and no IPv6 communication, which would have been unsuccessful, is even attempted. - The issues are not always so black-and-white. Usually it's important - that the service offered using both protocols is of roughly equal - quality, using the appropriate metrics for the service (e.g., - - - -Durand, et al. Expires January 17, 2006 [Page 9] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - latency, throughput, low packet loss, general reliability, etc.) -- - this is typically very important especially for interactive or real- + The issues are not always so black-and-white. Usually, it's + important that the service offered using both protocols is of roughly + equal quality, using the appropriate metrics for the service (e.g., + latency, throughput, low packet loss, general reliability, etc.). + This is typically very important especially for interactive or real- time services. In many cases, the quality of IPv6 connectivity may - not yet be equal to that of IPv4, at least globally -- this has to be + not yet be equal to that of IPv4, at least globally; this has to be taken into consideration when enabling services. -4.4 The Use of TTL for IPv4 and IPv6 RRs +4.4. The Use of TTL for IPv4 and IPv6 RRs - The behaviour of DNS caching when different TTL values are used for + The behavior of DNS caching when different TTL values are used for different RRsets of the same name calls for explicit discussion. For example, let's consider two unrelated zone fragments: @@ -532,7 +487,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 latter, we have "critical" additional data. See more extensive background discussion of additional data handling in Appendix B. -4.4.1 TTL With Courtesy Additional Data +4.4.1. TTL with Courtesy Additional Data When a caching resolver asks for the MX record of example.com, it gets back "foo.example.com". It may also get back either one or both @@ -545,32 +500,33 @@ Internet-Draft Considerations with IPv6 DNS July 2005 this case, for the AAAA record) expires; this would avoid the situation where there would be a window of 200 seconds when incomplete information is returned from the cache. Further argument + + + +Durand, et al. Informational [Page 9] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + for discarding is that in the normal operation, the TTL values are so high that very likely the incurred additional queries would not be noticeable, compared to the obtained performance optimization. The - behaviour in this scenario is unspecified. + behavior in this scenario is unspecified. -4.4.2 TTL With Critical Additional Data +4.4.2. TTL with Critical Additional Data The difference to courtesy additional data is that the A/AAAA records - served by the parent zone cannot be queried explicitly. Therefore - - - -Durand, et al. Expires January 17, 2006 [Page 10] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - + served by the parent zone cannot be queried explicitly. Therefore, after 100 seconds the AAAA record is removed from the cache(s), but the A record remains. Queries for the remaining 200 seconds - (provided that there are no further queries from the parent which + (provided that there are no further queries from the parent that could refresh the caches) only return the A record, leading to a - potential opererational situation with unreachable servers. + potential operational situation with unreachable servers. - Similar cache flushing strategies apply in this scenario; the record. + Similar cache flushing strategies apply in this scenario; the + behavior is likewise unspecified. -4.5 IPv6 Transport Guidelines for DNS Servers +4.5. IPv6 Transport Guidelines for DNS Servers As described in Section 1.3 and [RFC3901], there should continue to be at least one authoritative IPv4 DNS server for every zone, even if @@ -583,16 +539,16 @@ Internet-Draft Considerations with IPv6 DNS July 2005 When IPv6 is enabled on a node, there are several things to consider to ensure that the process is as smooth as possible. -5.1 DNS Lookups May Query IPv6 Records Prematurely +5.1. DNS Lookups May Query IPv6 Records Prematurely The system library that implements the getaddrinfo() function for looking up names is a critical piece when considering the robustness - of enabling IPv6; it may come in basically three flavours: + of enabling IPv6; it may come in basically three flavors: 1. The system library does not know whether IPv6 has been enabled in the kernel of the operating system: it may start looking up AAAA records with getaddrinfo() and AF_UNSPEC hint when the system is - upgraded to a system library version which supports IPv6. + upgraded to a system library version that supports IPv6. 2. The system library might start to perform IPv6 queries with getaddrinfo() only when IPv6 has been enabled in the kernel. @@ -600,43 +556,42 @@ Internet-Draft Considerations with IPv6 DNS July 2005 IPv6 connectivity (e.g., the node could be isolated from the other IPv6 networks, only having link-local addresses). - 3. The system library might implement a toggle which would apply - some heuristics to the "IPv6-readiness" of the node before - starting to perform queries; for example, it could check whether - only link-local IPv6 address(es) exists, or if at least one - global IPv6 address exists. + + + +Durand, et al. Informational [Page 10] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + 3. The system library might implement a toggle that would apply some + heuristics to the "IPv6-readiness" of the node before starting to + perform queries; for example, it could check whether only link- + local IPv6 address(es) exists, or if at least one global IPv6 + address exists. First, let us consider generic implications of unnecessary queries for AAAA records: when looking up all the records in the DNS, AAAA records are typically tried first, and then A records. These are done in serial, and the A query is not performed until a response is - - - -Durand, et al. Expires January 17, 2006 [Page 11] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - received to the AAAA query. Considering the misbehaviour of DNS - servers and load-balancers, as described in Section 3.1, the look-up + received to the AAAA query. Considering the misbehavior of DNS + servers and load-balancers, as described in Section 3.1, the lookup delay for AAAA may incur additional unnecessary latency, and introduce a component of unreliability. One option here could be to do the queries partially in parallel; for example, if the final response to the AAAA query is not received in 0.5 seconds, start performing the A query while waiting for the - result (immediate parallelism might be unoptimal, at least without - information sharing between the look-up threads, as that would - probably lead to duplicate non-cached delegation chain lookups). + result. (Immediate parallelism might not be optimal, at least + without information-sharing between the lookup threads, as that would + probably lead to duplicate non-cached delegation chain lookups.) An additional concern is the address selection, which may, in some circumstances, prefer AAAA records over A records even when the node - does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. - In some cases, the implementation may attempt to connect or send a - datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], - incurring very long protocol timeouts, instead of quickly failing - back to IPv4. + does not have any IPv6 connectivity [WIP-RDP2004]. In some cases, + the implementation may attempt to connect or send a datagram on a + physical link [WIP-R2006], incurring very long protocol time-outs, + instead of quickly falling back to IPv4. Now, we can consider the issues specific to each of the three possibilities: @@ -653,66 +608,74 @@ Internet-Draft Considerations with IPv6 DNS July 2005 The second case is similar to the first, except it happens to a smaller set of nodes when IPv6 has been enabled but connectivity has - not been provided yet; similar considerations apply, with the + not been provided yet. Similar considerations apply, with the exception that IPv6 records, when returned, will be actually tried - first which may typically lead to long timeouts. + first, which may typically lead to long time-outs. + + + + +Durand, et al. Informational [Page 11] + +RFC 4472 Considerations with IPv6 DNS April 2006 + The third case is a bit more complex: optimizing away the DNS lookups with only link-locals is probably safe (but may be desirable with - different lookup services which getaddrinfo() may support), as the + different lookup services that getaddrinfo() may support), as the link-locals are typically automatically generated when IPv6 is enabled, and do not indicate any form of IPv6 connectivity. That is, performing DNS lookups only when a non-link-local address has been configured on any interface could be beneficial -- this would be an - indication that either the address has been configured either from a - router advertisement, DHCPv6 [RFC3315], or manually. Each would - - - -Durand, et al. Expires January 17, 2006 [Page 12] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - indicate at least some form of IPv6 connectivity, even though there - would not be guarantees of it. + indication that the address has been configured either from a router + advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + [RFC3315], or manually. Each would indicate at least some form of + IPv6 connectivity, even though there would not be guarantees of it. These issues should be analyzed at more depth, and the fixes found consensus on, perhaps in a separate document. -5.2 Obtaining a List of DNS Recursive Resolvers +5.2. Obtaining a List of DNS Recursive Resolvers In scenarios where DHCPv6 is available, a host can discover a list of - DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" - option [RFC3646]. This option can be passed to a host through a - subset of DHCPv6 [RFC3736]. + DNS recursive resolvers through the DHCPv6 "DNS Recursive Name + Server" option [RFC3646]. This option can be passed to a host + through a subset of DHCPv6 [RFC3736]. The IETF is considering the development of alternative mechanisms for obtaining the list of DNS recursive name servers when DHCPv6 is unavailable or inappropriate. No decision about taking on this - development work has been reached as of this writing (Aug 2004) - [I-D.ietf-dnsop-ipv6-dns-configuration]. + development work has been reached as of this writing [RFC4339]. In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms - under consideration for development include the use of well-known - addresses [I-D.ohta-preconfigured-dns] and the use of Router - Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns- - discovery]. + under consideration for development include the use of [WIP-O2004] + and the use of Router Advertisements to convey the information + [WIP-J2006]. Note that even though IPv6 DNS resolver discovery is a recommended procedure, it is not required for dual-stack nodes in dual-stack networks as IPv6 DNS records can be queried over IPv4 as well as - IPv6. Obviously, nodes which are meant to function without manual + IPv6. Obviously, nodes that are meant to function without manual configuration in IPv6-only networks must implement the DNS resolver discovery function. -5.3 IPv6 Transport Guidelines for Resolvers +5.3. IPv6 Transport Guidelines for Resolvers As described in Section 1.3 and [RFC3901], the recursive resolvers should be IPv4-only or dual-stack to be able to reach any IPv4-only DNS server. Note that this requirement is also fulfilled by an IPv6- only stub resolver pointing to a dual-stack recursive DNS resolver. + + + + + +Durand, et al. Informational [Page 12] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + 6. Considerations about Forward DNS Updating While the topic of how to enable updating the forward DNS, i.e., the @@ -720,47 +683,39 @@ Internet-Draft Considerations with IPv6 DNS July 2005 IPv6, it should be considered especially due to the advent of Stateless Address Autoconfiguration [RFC2462]. - Typically forward DNS updates are more manageable than doing them in + Typically, forward DNS updates are more manageable than doing them in the reverse DNS, because the updater can often be assumed to "own" a - - - -Durand, et al. Expires January 17, 2006 [Page 13] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - certain DNS name -- and we can create a form of security relationship - with the DNS name and the node which is allowed to update it to point + with the DNS name and the node that is allowed to update it to point to a new address. A more complex form of DNS updates -- adding a whole new name into a DNS zone, instead of updating an existing name -- is considered out of scope for this memo as it could require zone-wide authentication. - Adding a new name in the forward zone is a problem which is still + Adding a new name in the forward zone is a problem that is still being explored with IPv4, and IPv6 does not seem to add much new in that area. -6.1 Manual or Custom DNS Updates +6.1. Manual or Custom DNS Updates The DNS mappings can also be maintained by hand, in a semi-automatic fashion or by running non-standardized protocols. These are not considered at more length in this memo. -6.2 Dynamic DNS +6.2. Dynamic DNS Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized mechanism for dynamically updating the DNS. It works equally well - with stateless address autoconfiguration (SLAAC), DHCPv6 or manual + with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual address configuration. It is important to consider how each of these behave if IP address-based authentication, instead of stronger mechanisms [RFC3007], was used in the updates. - 1. manual addresses are static and can be configured + 1. Manual addresses are static and can be configured. 2. DHCPv6 addresses could be reasonably static or dynamic, depending on the deployment, and could or could not be configured on the - DNS server for the long term + DNS server for the long term. 3. SLAAC addresses are typically stable for a long time, but could require work to be configured and maintained. @@ -770,6 +725,13 @@ Internet-Draft Considerations with IPv6 DNS July 2005 requires that the authorization keying will be explicitly configured using unspecified operational methods. + + +Durand, et al. Informational [Page 13] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + Note that with DHCP it is also possible that the DHCP server updates the DNS, not the host. The host might only indicate in the DHCP exchange which hostname it would prefer, and the DHCP server would @@ -778,18 +740,9 @@ Internet-Draft Considerations with IPv6 DNS July 2005 does not help much with "content" security, i.e., whether the hostname was acceptable -- if the DNS server does not include policies, they must be included in the DHCP server (e.g., a regular - - - -Durand, et al. Expires January 17, 2006 [Page 14] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - host should not be able to state that its name is "www.example.com"). DHCP-initiated DDNS updates have been extensively described in - [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and - [I-D.ietf-dnsext-dhcid-rr]. + [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b]. The nodes must somehow be configured with the information about the servers where they will attempt to update their addresses, sufficient @@ -806,14 +759,13 @@ Internet-Draft Considerations with IPv6 DNS July 2005 that if the node is renumbered in a managed fashion, the amount of stale DNS information is kept to the minimum. That is, if the preferred lifetime of an address expires, the TTL of the record needs - be modified unless it was already done before the expiration. For + to be modified unless it was already done before the expiration. For better flexibility, the DNS TTL should be much shorter (e.g., a half or a third) than the lifetime of an address; that way, the node can start lowering the DNS TTL if it seems like the address has not been renewed/refreshed in a while. Some discussion on how an - administrator could manage the DNS TTL is included in [I-D.ietf- - v6ops-renumbering-procedure]; this could be applied to (smart) hosts - as well. + administrator could manage the DNS TTL is included in [RFC4192]; this + could be applied to (smart) hosts as well. 7. Considerations about Reverse DNS Updating @@ -821,27 +773,28 @@ Internet-Draft Considerations with IPv6 DNS July 2005 authority over an address. However, first we have to consider the applicability of reverse DNS in the first place. -7.1 Applicability of Reverse DNS +7.1. Applicability of Reverse DNS - Today, some applications use reverse DNS to either look up some hints - about the topological information associated with an address (e.g. - resolving web server access logs), or as a weak form of a security - check, to get a feel whether the user's network administrator has - "authorized" the use of the address (on the premises that adding a + Today, some applications use reverse DNS either to look up some hints + about the topological information associated with an address (e.g., + resolving web server access logs) or (as a weak form of a security + check) to get a feel whether the user's network administrator has + + + + +Durand, et al. Informational [Page 14] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + "authorized" the use of the address (on the premise that adding a reverse record for an address would signal some form of authorization). One additional, maybe slightly more useful usage is ensuring that the reverse and forward DNS contents match (by looking up the pointer to the name by the IP address from the reverse tree, and ensuring that a - - - -Durand, et al. Expires January 17, 2006 [Page 15] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - record under the name in the forward tree points to the IP address) and correspond to a configured name or domain. As a security check, it is typically accompanied by other mechanisms, such as a user/ @@ -858,14 +811,13 @@ Internet-Draft Considerations with IPv6 DNS July 2005 reverse DNS records be updated. In many cases, it would just make more sense to use proper mechanisms for security (or topological information lookup) in the first place. At minimum, the applications - which use it as a generic authorization (in the sense that a record + that use it as a generic authorization (in the sense that a record exists at all) should be modified as soon as possible to avoid such lookups completely. - The applicability is discussed at more length in [I-D.ietf-dnsop- - inaddr-required]. + The applicability is discussed at more length in [WIP-S2005c]. -7.2 Manual or Custom DNS Updates +7.2. Manual or Custom DNS Updates Reverse DNS can of course be updated using manual or custom methods. These are not further described here, except for one special case. @@ -874,30 +826,32 @@ Internet-Draft Considerations with IPv6 DNS July 2005 example, by configuring one name for a subnet (/64) or a site (/48). As a concrete example, a site (or the site's ISP) could configure the reverses of the prefix 2001:db8:f00::/48 to point to one name using a - wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR - site.example.com." Naturally, such a name could not be verified from - the forward DNS, but would at least provide some form of "topological - information" or "weak authorization" if that is really considered to - be useful. Note that this is not actually updating the DNS as such, - as the whole point is to avoid DNS updates completely by manually - configuring a generic name. + wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR + site.example.com.". Naturally, such a name could not be verified + from the forward DNS, but would at least provide some form of + "topological information" or "weak authorization" if that is really + considered to be useful. Note that this is not actually updating the + DNS as such, as the whole point is to avoid DNS updates completely by + manually configuring a generic name. -7.3 DDNS with Stateless Address Autoconfiguration + + + + + +Durand, et al. Informational [Page 15] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +7.3. DDNS with Stateless Address Autoconfiguration Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in some regard, while being more difficult in another, as described below. - The address space administrator decides whether the hosts are trusted - to update their reverse DNS records or not. If they are trusted and - - - -Durand, et al. Expires January 17, 2006 [Page 16] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - + The address space administrator decides whether or not the hosts are + trusted to update their reverse DNS records. If they are trusted and deployed at the same site (e.g., not across the Internet), a simple address-based authorization is typically sufficient (i.e., check that the DNS update is done from the same IP address as the record being @@ -912,21 +866,21 @@ Internet-Draft Considerations with IPv6 DNS July 2005 DNS. However, when a stronger form of security is used, forward DNS updates are simpler to manage because the host can be assumed to have an association with the domain. Note that the user may roam to - different networks, and does not necessarily have any association - with the owner of that address space -- so, assuming stronger form of + different networks and does not necessarily have any association with + the owner of that address space. So, assuming a stronger form of authorization for reverse DNS updates than an address association is generally infeasible. Moreover, the reverse zones must be cleaned up by an unspecified janitorial process: the node does not typically know a priori that it - will be disconnected, and cannot send a DNS update using the correct - source address to remove a record. + will be disconnected, and it cannot send a DNS update using the + correct source address to remove a record. A problem with defining the clean-up process is that it is difficult to ensure that a specific IP address and the corresponding record are no longer being used. Considering the huge address space, and the unlikelihood of collision within 64 bits of the interface - identifiers, a process which would remove the record after no traffic + identifiers, a process that would remove the record after no traffic has been seen from a node in a long period of time (e.g., a month or year) might be one possible approach. @@ -938,28 +892,29 @@ Internet-Draft Considerations with IPv6 DNS July 2005 authorization is trusted) must also be established by some other means. - One should note that Cryptographically Generated Addresses [RFC3972] - (CGAs) may require a slightly different kind of treatment. CGAs are - addresses where the interface identifier is calculated from a public - key, a modifier (used as a nonce), the subnet prefix, and other data. - Depending on the usage profile, CGAs might or might not be changed - periodically due to e.g., privacy reasons. As the CGA address is not - predicatable, a reverse record can only reasonably be inserted in the - DNS by the node which generates the address. -Durand, et al. Expires January 17, 2006 [Page 17] +Durand, et al. Informational [Page 16] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 -7.4 DDNS with DHCP + One should note that Cryptographically Generated Addresses (CGAs) + [RFC3972] may require a slightly different kind of treatment. CGAs + are addresses where the interface identifier is calculated from a + public key, a modifier (used as a nonce), the subnet prefix, and + other data. Depending on the usage profile, CGAs might or might not + be changed periodically due to, e.g., privacy reasons. As the CGA + address is not predictable, a reverse record can only reasonably be + inserted in the DNS by the node that generates the address. + +7.4. DDNS with DHCP With DHCPv4, the reverse DNS name is typically already inserted to - the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One + the DNS that reflects the name (e.g., "dhcp-67.example.com"). One can assume similar practice may become commonplace with DHCPv6 as - well; all such mappings would be pre-configured, and would require no + well; all such mappings would be pre-configured and would require no updating. If a more explicit control is required, similar considerations as @@ -981,7 +936,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 similar properties except that the janitorial process could be integrated with DHCP address assignment. -7.5 DDNS with Dynamic Prefix Delegation +7.5. DDNS with Dynamic Prefix Delegation In cases where a prefix, instead of an address, is being used and updated, one should consider what is the location of the server where @@ -993,25 +948,25 @@ Internet-Draft Considerations with IPv6 DNS July 2005 the authority of the DNS reverse zone corresponding to the delegated prefix is also delegated to the site. + + + +Durand, et al. Informational [Page 17] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + 3. Elsewhere; this implies a relationship between the site and where - DNS server is located, and such a relationship should be rather - straightforward to secure as well. Like in the previous case, - the authority of the DNS reverse zone is also delegated. + the DNS server is located, and such a relationship should be + rather straightforward to secure as well. Like in the previous + case, the authority of the DNS reverse zone is also delegated. In the first case, managing the reverse DNS (delegation) is simpler as the DNS server and the prefix delegator are in the same administrative domain (as there is no need to delegate anything at all); alternatively, the prefix delegator might forgo DDNS reverse - - - -Durand, et al. Expires January 17, 2006 [Page 18] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - capability altogether, and use e.g., wildcard records (as described - in Section 7.2). In the other cases, it can be slighly more + capability altogether, and use, e.g., wildcard records (as described + in Section 7.2). In the other cases, it can be slightly more difficult, particularly as the site will have to configure the DNS server to be authoritative for the delegated reverse zone, implying automatic configuration of the DNS server -- as the prefix may be @@ -1030,56 +985,56 @@ Internet-Draft Considerations with IPv6 DNS July 2005 8. Miscellaneous DNS Considerations - This section describes miscellaneous considerations about DNS which + This section describes miscellaneous considerations about DNS that seem related to IPv6, for which no better place has been found in this document. -8.1 NAT-PT with DNS-ALG +8.1. NAT-PT with DNS-ALG - The DNS-ALG component of NAT-PT mangles A records to look like AAAA - records to the IPv6-only nodes. Numerous problems have been - identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl]. This is - a strong reason not to use NAT-PT in the first place. + The DNS-ALG component of NAT-PT [RFC2766] mangles A records to look + like AAAA records to the IPv6-only nodes. Numerous problems have + been identified with [WIP-AD2005]. This is a strong reason not to + use NAT-PT in the first place. -8.2 Renumbering Procedures and Applications' Use of DNS +8.2. Renumbering Procedures and Applications' Use of DNS One of the most difficult problems of systematic IP address - renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that - an application which looks up a DNS name disregards information such - as TTL, and uses the result obtained from DNS as long as it happens - to be stored in the memory of the application. For applications - which run for a long time, this could be days, weeks or even months; - some applications may be clever enough to organize the data - structures and functions in such a manner that look-ups get refreshed - now and then. + renumbering procedures [RFC4192] is that an application that looks up + a DNS name disregards information such as TTL, and uses the result + obtained from DNS as long as it happens to be stored in the memory of + the application. For applications that run for a long time, this + + + + +Durand, et al. Informational [Page 18] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + could be days, weeks, or even months. Some applications may be + clever enough to organize the data structures and functions in such a + manner that lookups get refreshed now and then. While the issue appears to have a clear solution, "fix the - applications", practically this is not reasonable immediate advice; - the TTL information is not typically available in the APIs and - libraries (so, the advice becomes "fix the applications, APIs and + applications", practically, this is not reasonable immediate advice. + The TTL information is not typically available in the APIs and + libraries (so, the advice becomes "fix the applications, APIs, and libraries"), and a lot more analysis is needed on how to practically - - - -Durand, et al. Expires January 17, 2006 [Page 19] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - go about to achieve the ultimate goal of avoiding using the names longer than expected. 9. Acknowledgements Some recommendations (Section 4.3, Section 5.1) about IPv6 service - provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik - Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided - useful feedback and improvements. Scott Rose, Rob Austein, Masataka - Ohta, and Mark Andrews helped in clarifying the issues regarding - additional data and the use of TTL. Jefsey Morfin, Ralph Droms, - Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and - Rob Austein provided useful feedback during the WG last call. Thomas - Narten provided extensive feedback during the IESG evaluation. + provisioning were moved here from [RFC4213] by Erik Nordmark and Bob + Gilligan. Havard Eidnes and Michael Patton provided useful feedback + and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark + Andrews helped in clarifying the issues regarding additional data and + the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei + Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided + useful feedback during the WG last call. Thomas Narten provided + extensive feedback during the IESG evaluation. 10. Security Considerations @@ -1087,7 +1042,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 operations and does not have security considerations in itself. However, it is worth noting that in particular with Dynamic DNS - Updates, security models based on the source address validation are + updates, security models based on the source address validation are very weak and cannot be recommended -- they could only be considered in the environments where ingress filtering [RFC3704] has been deployed. On the other hand, it should be noted that setting up an @@ -1100,274 +1055,249 @@ Internet-Draft Considerations with IPv6 DNS July 2005 (questionable) security-related use for them may be in conjunction with other mechanisms when authenticating a user. + + + + + + + + +Durand, et al. Informational [Page 19] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + 11. References -11.1 Normative References +11.1. Normative References - [I-D.ietf-dnsop-ipv6-dns-configuration] - Jeong, J., "IPv6 Host Configuration of DNS Server - Information Approaches", - draft-ietf-dnsop-ipv6-dns-configuration-06 (work in - progress), May 2005. + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. - [I-D.ietf-ipv6-unique-local-addr] - Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in - progress), January 2005. + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS + UPDATE)", RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, + "Selection and Operation of Secondary DNS Servers", + BCP 16, RFC 2182, July 1997. + + [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) + Dynamic Update", RFC 3007, November 2000. + + [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC 3041, + January 2001. + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. + + [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. -Durand, et al. Expires January 17, 2006 [Page 20] +Durand, et al. Informational [Page 20] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - [I-D.ietf-v6ops-renumbering-procedure] - Baker, F., "Procedures for Renumbering an IPv6 Network - without a Flag Day", - draft-ietf-v6ops-renumbering-procedure-05 (work in - progress), March 2005. + [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) + Support for Internet Protocol version 6 (IPv6)", + RFC 3364, August 2002. - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. + [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration + Protocol (DHCP) Service for IPv6", RFC 3736, + April 2004. - [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection - and Operation of Secondary DNS Servers", BCP 16, RFC 2182, - July 1997. + [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. - [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. + [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport + Operational Guidelines", BCP 91, RFC 3901, + September 2004. - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. + [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. + Castro, "Application Aspects of IPv6 Transition", + RFC 4038, March 2005. - [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, - April 2001. + [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior + Against DNS Queries for IPv6 Addresses", RFC 4074, + May 2005. - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. + [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for + Renumbering an IPv6 Network without a Flag Day", + RFC 4192, September 2005. - [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC 3041, - January 2001. + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. - [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains - via IPv4 Clouds", RFC 3056, February 2001. + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. - [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, - August 2001. - - [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., - and M. Carney, "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - - [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. - Hain, "Representing Internet Protocol version 6 (IPv6) + [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server + Information Approaches", RFC 4339, February 2006. -Durand, et al. Expires January 17, 2006 [Page 21] + + + + + +Durand, et al. Informational [Page 21] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - Addresses in the Domain Name System (DNS)", RFC 3363, - August 2002. +11.2. Informative References - [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) - Support for Internet Protocol version 6 (IPv6)", RFC 3364, - August 2002. + [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address + Translation - Protocol Translation (NAT-PT)", RFC 2766, + February 2000. - [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 3513, April 2003. + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR + for specifying the location of services (DNS SRV)", + RFC 2782, February 2000. - [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, - "DNS Extensions to Support IP Version 6", RFC 3596, - October 2003. + [RFC2826] Internet Architecture Board, "IAB Technical Comment on + the Unique DNS Root", RFC 2826, May 2000. - [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, - December 2003. + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for + Multihomed Networks", BCP 84, RFC 3704, March 2004. - [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, April 2004. + [RFC3972] Aura, T., "Cryptographically Generated Addresses + (CGA)", RFC 3972, March 2005. - [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", RFC 3879, September 2004. + [RFC4025] Richardson, M., "A Method for Storing IPsec Keying + Material in DNS", RFC 4025, March 2005. - [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational - Guidelines", BCP 91, RFC 3901, September 2004. + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. - [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. - Castro, "Application Aspects of IPv6 Transition", - RFC 4038, March 2005. + [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third + Generation Partnership Project (3GPP) Networks", + RFC 4215, October 2005. - [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against - DNS Queries for IPv6 Addresses", RFC 4074, May 2005. + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, + February 2006. -11.2 Informative References + [TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit + handling and additional data" on DNSEXT mailing list, + Message- + Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August + 1, 2005, . - [I-D.durand-dnsop-dont-publish] - Durand, A. and T. Chown, "To publish, or not to publish, - that is the question.", draft-durand-dnsop-dont-publish-00 - (work in progress), February 2005. + [WIP-AD2005] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to + Experimental", Work in Progress, October 2005. - [I-D.huitema-v6ops-teredo] - Huitema, C., "Teredo: Tunneling IPv6 over UDP through - NATs", draft-huitema-v6ops-teredo-05 (work in progress), - April 2005. - - [I-D.huston-6to4-reverse-dns] - Huston, G., "6to4 Reverse DNS Delegation", + [WIP-DC2005] Durand, A. and T. Chown, "To publish, or not to + publish, that is the question", Work in Progress, + October 2005. -Durand, et al. Expires January 17, 2006 [Page 22] + +Durand, et al. Informational [Page 22] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - draft-huston-6to4-reverse-dns-03 (work in progress), - October 2004. + [WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation + Specification", Work in Progress, November 2005. - [I-D.ietf-dhc-ddns-resolution] - Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among - DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in - progress), June 2005. + [WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS + Configuration", Work in Progress, January 2006. - [I-D.ietf-dhc-fqdn-option] - Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", - draft-ietf-dhc-fqdn-option-10 (work in progress), - February 2005. + [WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution + Misbehavior", Work in Progress, February 2006. - [I-D.ietf-dnsext-dhcid-rr] - Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for - encoding DHCP information (DHCID RR)", - draft-ietf-dnsext-dhcid-rr-09 (work in progress), - February 2005. + [WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in + Progress, February 2004. - [I-D.ietf-dnsop-bad-dns-res] - Larson, M. and P. Barber, "Observed DNS Resolution - Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in - progress), October 2004. + [WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption + Considered Harmful", Work in Progress, January 2006. - [I-D.ietf-dnsop-inaddr-required] - Senie, D., "Encouraging the use of DNS IN-ADDR Mapping", - draft-ietf-dnsop-inaddr-required-06 (work in progress), - February 2005. + [WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual + Stack IPv6 on by Default", Work in Progress, July 2004. - [I-D.ietf-v6ops-3gpp-analysis] - Wiljakka, J., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in - progress), October 2004. + [WIP-S2005a] Stapp, M., "The DHCP Client FQDN Option", Work in + Progress, March 2006. - [I-D.ietf-v6ops-mech-v2] - Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms - for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 - (work in progress), March 2005. + [WIP-S2005b] Stapp, M., "A DNS RR for Encoding DHCP Information + (DHCID RR)", Work in Progress, March 2006. - [I-D.ietf-v6ops-natpt-to-exprmntl] - Aoun, C. and E. Davies, "Reasons to Move NAT-PT to - Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work - in progress), July 2005. + [WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR + Mapping", Work in Progress, August 2005. - [I-D.ietf-v6ops-onlinkassumption] - Roy, S., "IPv6 Neighbor Discovery On-Link Assumption - Considered Harmful", draft-ietf-v6ops-onlinkassumption-03 - (work in progress), May 2005. + [WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts + among DHCP Clients", Work in Progress, March 2006. -Durand, et al. Expires January 17, 2006 [Page 23] + + + + + + + + + + + + + + + + + + + +Durand, et al. Informational [Page 23] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - [I-D.ietf-v6ops-v6onbydefault] - Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack - IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 - (work in progress), July 2004. - - [I-D.jeong-dnsop-ipv6-dns-discovery] - Jeong, J., "IPv6 DNS Configuration based on Router - Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04 - (work in progress), February 2005. - - [I-D.ohta-preconfigured-dns] - Ohta, M., "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-01 (work in progress), - February 2004. - - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - [RFC2826] Internet Architecture Board, "IAB Technical Comment on the - Unique DNS Root", RFC 2826, May 2000. - - [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed - Networks", BCP 84, RFC 3704, March 2004. - - [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", - RFC 3972, March 2005. - - [RFC4025] Richardson, M., "A Method for Storing IPsec Keying - Material in DNS", RFC 4025, March 2005. - - -Authors' Addresses - - Alain Durand - SUN Microsystems, Inc. - 17 Network circle UMPL17-202 - Menlo Park, CA 94025 - USA - - Email: Alain.Durand@sun.com - - - - - - -Durand, et al. Expires January 17, 2006 [Page 24] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm - Sweden - - Email: johani@autonomica.se - - - Pekka Savola - CSC/FUNET - Espoo - Finland - - Email: psavola@funet.fi - Appendix A. Unique Local Addressing Considerations for DNS - Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have - replaced the now-deprecated site-local addresses [RFC3879]. From the - perspective of the DNS, the locally generated unique local addresses - (LUL) and site-local addresses have similar properties. + Unique local addresses [RFC4193] have replaced the now-deprecated + site-local addresses [RFC3879]. From the perspective of the DNS, the + locally generated unique local addresses (LUL) and site-local + addresses have similar properties. The interactions with DNS come in two flavors: forward and reverse DNS. @@ -1378,31 +1308,21 @@ Appendix A. Unique Local Addressing Considerations for DNS procedures to achieve this are not elaborated here. The implication is that local addresses must not be published in the public DNS. - To faciliate reverse DNS (if desired) with local addresses, the stub + To facilitate reverse DNS (if desired) with local addresses, the stub resolvers must look for DNS information from the local DNS servers, - not e.g. starting from the root servers, so that the local + not, e.g., starting from the root servers, so that the local information may be provided locally. Note that the experience of private addresses in IPv4 has shown that the root servers get loaded for requests for private address lookups in any case. This - requirement is discussed in [I-D.ietf-ipv6-unique-local-addr]. + requirement is discussed in [RFC4193]. -Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments +Appendix B. Behavior of Additional Data in IPv4/IPv6 Environments DNS responses do not always fit in a single UDP packet. We'll - examine the cases which happen when this is due to too much data in - the Additional Section. + examine the cases that happen when this is due to too much data in + the Additional section. - - - - - -Durand, et al. Expires January 17, 2006 [Page 25] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - -B.1 Description of Additional Data Scenarios +B.1. Description of Additional Data Scenarios There are two kinds of additional data: @@ -1418,12 +1338,19 @@ B.1 Description of Additional Data Scenarios Only those additional data records (even if sometimes carelessly termed "glue") are considered "critical" or real "glue" if and only - if they meet the abovementioned condition, as specified in Section + if they meet the above-mentioned condition, as specified in Section 4.2.1 of [RFC1034]. + + +Durand, et al. Informational [Page 24] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + Remember that resource record sets (RRsets) are never "broken up", so if a name has 4 A records and 5 AAAA records, you can either return - all 9, all 4 A records, all 5 AAAA records or nothing. In + all 9, all 4 A records, all 5 AAAA records, or nothing. In particular, notice that for the "critical" additional data getting all the RRsets can be critical. @@ -1433,14 +1360,14 @@ B.1 Description of Additional Data Scenarios the TC bit, and the recipient should discard the whole response and retry using mechanism allowing larger responses such as TCP. - b. "courtesy" additional data should not cause the setting of TC + b. "courtesy" additional data should not cause the setting of the TC bit, but instead all the non-fitting additional data RRsets should be removed. An example of the "courtesy" additional data is A/AAAA records in conjunction with MX records as shown in Section 4.4; an example of the "critical" additional data is shown below (where getting both the - A and AAAA RRsets is critical w.r.t. to the NS RR): + A and AAAA RRsets is critical with respect to the NS RR): child.example.com. IN NS ns.child.example.com. ns.child.example.com. IN A 192.0.2.1 @@ -1451,25 +1378,38 @@ B.1 Description of Additional Data Scenarios additional data is not critical, even all of it could be safely removed. - - -Durand, et al. Expires January 17, 2006 [Page 26] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - When there is too much "critical" additional data, TC bit will have to be set, and the recipient should ignore the response and retry using TCP; if some data were to be left in the UDP response, the issue is which data could be retained. - Failing to discard the response with TC bit or omitting critical - information but not setting TC bit lead to an unrecoverable problem. - Omitting only some of the RRsets if all would not fit (but not - setting TC bit) leads to a performance problem. These are discussed - in the next two subsections. + However, the practice may differ from the specification. Testing and + code analysis of three recent implementations [TC-TEST] confirm this. + None of the tested implementations have a strict separation of + critical and courtesy additional data, while some forms of additional + data may be treated preferably. All the implementations remove some + (critical or courtesy) additional data RRsets without setting the TC + bit if the response would not otherwise fit. -B.2 Which Additional Data to Keep, If Any? + Failing to discard the response with the TC bit or omitting critical + information but not setting the TC bit lead to an unrecoverable + problem. Omitting only some of the RRsets if all would not fit (but + not setting the TC bit) leads to a performance problem. These are + discussed in the next two subsections. + + + +Durand, et al. Informational [Page 25] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +B.2. Which Additional Data to Keep, If Any? + + NOTE: omitting some critical additional data instead of setting the + TC bit violates a 'should' in Section 9 of RFC2181. However, as many + implementations still do that [TC-TEST], operators need to understand + its implications, and we describe that behavior as well. If the implementation decides to keep as much data (whether "critical" or "courtesy") as possible in the UDP responses, it might @@ -1501,24 +1441,26 @@ B.2 Which Additional Data to Keep, If Any? than a random process would seem justifiable. That is, leaving in some intelligently selected critical additional - data is a tradeoff between creating an optimization for those - resolvers which ignore the "should discard" recommendation, and - causing a protocol problem by propagating inconsistent information - about "critical" records in the caches. - - - - -Durand, et al. Expires January 17, 2006 [Page 27] - -Internet-Draft Considerations with IPv6 DNS July 2005 - + data is a trade-off between creating an optimization for those + resolvers that ignore the "should discard" recommendation and causing + a protocol problem by propagating inconsistent information about + "critical" records in the caches. Similarly, leaving in the complete courtesy additional data RRsets - instead of removing all the RRsets is a performance tradeoff as + instead of removing all the RRsets is a performance trade-off as described in the next section. -B.3 Discussion of the Potential Problems + + + + + +Durand, et al. Informational [Page 26] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +B.3. Discussion of the Potential Problems As noted above, the temptation for omitting only some of the additional data could be problematic. This is discussed more below. @@ -1537,42 +1479,69 @@ B.3 Discussion of the Potential Problems requestor (e.g., a recursive server in the middle) uses makes no difference to the ultimate user of the records, whose transport capabilities might differ from those of the requestor. This might - result in e.g., inappropriately returning A records to an IPv6-only + result in, e.g., inappropriately returning A records to an IPv6-only node, going through a translation, or opening up another IP-level - session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]). + session (e.g., a Packet Data Protocol (PDP) context [RFC4215]). Therefore, at least in many scenarios, it would be very useful if the information returned would be consistent and complete -- or if that - is not feasible, return no misleading information but rather leave it - to the client to query again. + is not feasible, leave it to the client to query again. The problem of too much additional data seems to be an operational - one: the zone administrator entering too many records which will be - returned either truncated (or missing some RRsets, depending on + one: the zone administrator entering too many records that will be + returned truncated (or missing some RRsets, depending on implementations) to the users. A protocol fix for this is using - EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes, - pushing up the relevant threshold. Further, DNS server - implementations should rather omit courtesy additional data - completely rather than including only some RRsets [RFC2181]. An + Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity + for larger UDP packet sizes, pushing up the relevant threshold. + Further, DNS server implementations should omit courtesy additional + data completely rather than including only some RRsets [RFC2181]. An operational fix for this is having the DNS server implementations - return a warning when the administrators create zones which would + return a warning when the administrators create zones that would result in too much additional data being returned. Further, DNS server implementations should warn of or disallow such zone - configurations which are recursive or otherwise difficult to manage - by the protocol. - - Additionally, to avoid the case where an application would not get an - address at all due to some of courtesy additional data being omitted, + configurations that are recursive or otherwise difficult to manage by + the protocol. -Durand, et al. Expires January 17, 2006 [Page 28] + + + + + + + + +Durand, et al. Informational [Page 27] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - the resolvers should be able to query the specific records of the - desired protocol, not just rely on getting all the required RRsets in - the additional section. +Authors' Addresses + + Alain Durand + Comcast + 1500 Market St. + Philadelphia, PA 19102 + USA + + EMail: Alain_Durand@cable.comcast.com + + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm + Sweden + + EMail: johani@autonomica.se + + + Pekka Savola + CSC/FUNET + Espoo + Finland + + EMail: psavola@funet.fi @@ -1598,35 +1567,28 @@ Internet-Draft Considerations with IPv6 DNS July 2005 - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires January 17, 2006 [Page 29] +Durand, et al. Informational [Page 28] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to @@ -1650,33 +1612,16 @@ Intellectual Property Statement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. +Acknowledgement -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). -Durand, et al. Expires January 17, 2006 [Page 30] + + + +Durand, et al. Informational [Page 29] - diff --git a/doc/rfc/rfc4697.txt b/doc/rfc/rfc4697.txt new file mode 100644 index 0000000000..773507ca69 --- /dev/null +++ b/doc/rfc/rfc4697.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group M. Larson +Request for Comments: 4697 P. Barber +BCP: 123 VeriSign, Inc. +Category: Best Current Practice October 2006 + + + Observed DNS Resolution Misbehavior + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This memo describes DNS iterative resolver behavior that results in a + significant query volume sent to the root and top-level domain (TLD) + name servers. We offer implementation advice to iterative resolver + developers to alleviate these unnecessary queries. The + recommendations made in this document are a direct byproduct of + observation and analysis of abnormal query traffic patterns seen at + two of the thirteen root name servers and all thirteen com/net TLD + name servers. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. A Note about Terminology in this Memo ......................3 + 1.2. Key Words ..................................................3 + 2. Observed Iterative Resolver Misbehavior .........................3 + 2.1. Aggressive Requerying for Delegation Information ...........3 + 2.1.1. Recommendation ......................................5 + 2.2. Repeated Queries to Lame Servers ...........................6 + 2.2.1. Recommendation ......................................6 + 2.3. Inability to Follow Multiple Levels of Indirection .........7 + 2.3.1. Recommendation ......................................7 + 2.4. Aggressive Retransmission when Fetching Glue ...............8 + 2.4.1. Recommendation ......................................9 + 2.5. Aggressive Retransmission behind Firewalls .................9 + 2.5.1. Recommendation .....................................10 + 2.6. Misconfigured NS Records ..................................10 + 2.6.1. Recommendation .....................................11 + + + + +Larson & Barber Best Current Practice [Page 1] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + 2.7. Name Server Records with Zero TTL .........................11 + 2.7.1. Recommendation .....................................12 + 2.8. Unnecessary Dynamic Update Messages .......................12 + 2.8.1. Recommendation .....................................13 + 2.9. Queries for Domain Names Resembling IPv4 Addresses ........13 + 2.9.1. Recommendation .....................................14 + 2.10. Misdirected Recursive Queries ............................14 + 2.10.1. Recommendation ....................................14 + 2.11. Suboptimal Name Server Selection Algorithm ...............15 + 2.11.1. Recommendation ....................................15 + 3. Security Considerations ........................................16 + 4. Acknowledgements ...............................................16 + 5. Internationalization Considerations ............................16 + 6. References .....................................................16 + 6.1. Normative References ......................................16 + 6.2. Informative References ....................................16 + +1. Introduction + + Observation of query traffic received by two root name servers and + the thirteen com/net Top-Level Domain (TLD) name servers has revealed + that a large proportion of the total traffic often consists of + "requeries". A requery is the same question () + asked repeatedly at an unexpectedly high rate. We have observed + requeries from both a single IP address and multiple IP addresses + (i.e., the same query received simultaneously from multiple IP + addresses). + + By analyzing requery events, we have found that the cause of the + duplicate traffic is almost always a deficient iterative resolver, + stub resolver, or application implementation combined with an + operational anomaly. The implementation deficiencies we have + identified to date include well-intentioned recovery attempts gone + awry, insufficient caching of failures, early abort when multiple + levels of indirection must be followed, and aggressive retry by stub + resolvers or applications. Anomalies that we have seen trigger + requery events include lame delegations, unusual glue records, and + anything that makes all authoritative name servers for a zone + unreachable (Denial of Service (DoS) attacks, crashes, maintenance, + routing failures, congestion, etc.). + + In the following sections, we provide a detailed explanation of the + observed behavior and recommend changes that will reduce the requery + rate. None of the changes recommended affects the core DNS protocol + specification; instead, this document consists of guidelines to + implementors of iterative resolvers. + + + + + +Larson & Barber Best Current Practice [Page 2] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +1.1. A Note about Terminology in This Memo + + To recast an old saying about standards, the nice thing about DNS + terms is that there are so many of them to choose from. Writing or + talking about DNS can be difficult and can cause confusion resulting + from a lack of agreed-upon terms for its various components. Further + complicating matters are implementations that combine multiple roles + into one piece of software, which makes naming the result + problematic. An example is the entity that accepts recursive + queries, issues iterative queries as necessary to resolve the initial + recursive query, caches responses it receives, and which is also able + to answer questions about certain zones authoritatively. This entity + is an iterative resolver combined with an authoritative name server + and is often called a "recursive name server" or a "caching name + server". + + This memo is concerned principally with the behavior of iterative + resolvers, which are typically found as part of a recursive name + server. This memo uses the more precise term "iterative resolver", + because the focus is usually on that component. In instances where + the name server role of this entity requires mentioning, this memo + uses the term "recursive name server". As an example of the + difference, the name server component of a recursive name server + receives DNS queries and the iterative resolver component sends + queries. + + The advent of IPv6 requires mentioning AAAA records as well as A + records when discussing glue. To avoid continuous repetition and + qualification, this memo uses the general term "address record" to + encompass both A and AAAA records when a particular situation is + relevant to both types. + +1.2. Key Words + + 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. Observed Iterative Resolver Misbehavior + +2.1. Aggressive Requerying for Delegation Information + + There can be times when every name server in a zone's NS RRSet is + unreachable (e.g., during a network outage), unavailable (e.g., the + name server process is not running on the server host), or + misconfigured (e.g., the name server is not authoritative for the + given zone, also known as "lame"). Consider an iterative resolver + that attempts to resolve a query for a domain name in such a zone and + + + +Larson & Barber Best Current Practice [Page 3] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + discovers that none of the zone's name servers can provide an answer. + We have observed a recursive name server implementation whose + iterative resolver then verifies the zone's NS RRSet in its cache by + querying for the zone's delegation information: it sends a query for + the zone's NS RRSet to one of the parent zone's name servers. (Note + that queries with QTYPE=NS are not required by the standard + resolution algorithm described in Section 4.3.2 of RFC 1034 [2]. + These NS queries represent this implementation's addition to that + algorithm.) + + For example, suppose that "example.com" has the following NS RRSet: + + example.com. IN NS ns1.example.com. + example.com. IN NS ns2.example.com. + + Upon receipt of a query for "www.example.com" and assuming that + neither "ns1.example.com" nor "ns2.example.com" can provide an + answer, this iterative resolver implementation immediately queries a + "com" zone name server for the "example.com" NS RRSet to verify that + it has the proper delegation information. This implementation + performs this query to a zone's parent zone for each recursive query + it receives that fails because of a completely unresponsive set of + name servers for the target zone. Consider the effect when a popular + zone experiences a catastrophic failure of all its name servers: now + every recursive query for domain names in that zone sent to this + recursive name server implementation results in a query to the failed + zone's parent name servers. On one occasion when several dozen + popular zones became unreachable, the query load on the com/net name + servers increased by 50%. + + We believe this verification query is not reasonable. Consider the + circumstances: when an iterative resolver is resolving a query for a + domain name in a zone it has not previously searched, it uses the + list of name servers in the referral from the target zone's parent. + If on its first attempt to search the target zone, none of the name + servers in the referral is reachable, a verification query to the + parent would be pointless: this query to the parent would come so + quickly on the heels of the referral that it would be almost certain + to contain the same list of name servers. The chance of discovering + any new information is slim. + + The other possibility is that the iterative resolver successfully + contacts one of the target zone's name servers and then caches the NS + RRSet from the authority section of a response, the proper behavior + according to Section 5.4.1 of RFC 2181 [3], because the NS RRSet from + the target zone is more trustworthy than delegation information from + the parent zone. If, while processing a subsequent recursive query, + the iterative resolver discovers that none of the name servers + + + +Larson & Barber Best Current Practice [Page 4] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + specified in the cached NS RRSet is available or authoritative, + querying the parent would be wrong. An NS RRSet from the parent zone + would now be less trustworthy than data already in the cache. + + For this query of the parent zone to be useful, the target zone's + entire set of name servers would have to change AND the former set of + name servers would have to be deconfigured or decommissioned AND the + delegation information in the parent zone would have to be updated + with the new set of name servers, all within the Time to Live (TTL) + of the target zone's NS RRSet. We believe this scenario is uncommon: + administrative best practices dictate that changes to a zone's set of + name servers happen gradually when at all possible, with servers + removed from the NS RRSet left authoritative for the zone as long as + possible. The scenarios that we can envision that would benefit from + the parent requery behavior do not outweigh its damaging effects. + + This section should not be understood to claim that all queries to a + zone's parent are bad. In some cases, such queries are not only + reasonable but required. Consider the situation when required + information, such as the address of a name server (i.e., the address + record corresponding to the RDATA of an NS record), has timed out of + an iterative resolver's cache before the corresponding NS record. If + the name of the name server is below the apex of the zone, then the + name server's address record is only available as glue in the parent + zone. For example, consider this NS record: + + example.com. IN NS ns.example.com. + + If a cache has this NS record but not the address record for + "ns.example.com", it is unable to contact the "example.com" zone + directly and must query the "com" zone to obtain the address record. + Note, however, that such a query would not have QTYPE=NS according to + the standard resolution algorithm. + +2.1.1. Recommendation + + An iterative resolver MUST NOT send a query for the NS RRSet of a + non-responsive zone to any of the name servers for that zone's parent + zone. For the purposes of this injunction, a non-responsive zone is + defined as a zone for which every name server listed in the zone's NS + RRSet: + + 1. is not authoritative for the zone (i.e., lame), or + + 2. returns a server failure response (RCODE=2), or + + 3. is dead or unreachable according to Section 7.2 of RFC 2308 [4]. + + + + +Larson & Barber Best Current Practice [Page 5] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.2. Repeated Queries to Lame Servers + + Section 2.1 describes a catastrophic failure: when every name server + for a zone is unable to provide an answer for one reason or another. + A more common occurrence is when a subset of a zone's name servers is + unavailable or misconfigured. Different failure modes have different + expected durations. Some symptoms indicate problems that are + potentially transient, for example, various types of ICMP unreachable + messages because a name server process is not running or a host or + network is unreachable, or a complete lack of a response to a query. + Such responses could be the result of a host rebooting or temporary + outages; these events do not necessarily require any human + intervention and can be reasonably expected to be temporary. + + Other symptoms clearly indicate a condition requiring human + intervention, such as lame server: if a name server is misconfigured + and not authoritative for a zone delegated to it, it is reasonable to + assume that this condition has potential to last longer than + unreachability or unresponsiveness. Consequently, repeated queries + to known lame servers are not useful. In this case of a condition + with potential to persist for a long time, a better practice would be + to maintain a list of known lame servers and avoid querying them + repeatedly in a short interval. + + It should also be noted, however, that some authoritative name server + implementations appear to be lame only for queries of certain types + as described in RFC 4074 [5]. In this case, it makes sense to retry + the "lame" servers for other types of queries, particularly when all + known authoritative name servers appear to be "lame". + +2.2.1. Recommendation + + Iterative resolvers SHOULD cache name servers that they discover are + not authoritative for zones delegated to them (i.e., lame servers). + If this caching is performed, lame servers MUST be cached against the + specific query tuple . Zone + name can be derived from the owner name of the NS record that was + referenced to query the name server that was discovered to be lame. + + Implementations that perform lame server caching MUST refrain from + sending queries to known lame servers for a configurable time + interval after the server is discovered to be lame. A minimum + interval of thirty minutes is RECOMMENDED. + + + + + + + + +Larson & Barber Best Current Practice [Page 6] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + An exception to this recommendation occurs if all name servers for a + zone are marked lame. In that case, the iterative resolver SHOULD + temporarily ignore the servers' lameness status and query one or more + servers. This behavior is a workaround for the type-specific + lameness issue described in the previous section. + + Implementors should take care not to make lame server avoidance logic + overly broad: note that a name server could be lame for a parent zone + but not a child zone, e.g., lame for "example.com" but properly + authoritative for "sub.example.com". Therefore, a name server should + not be automatically considered lame for subzones. In the case + above, even if a name server is known to be lame for "example.com", + it should be queried for QNAMEs at or below "sub.example.com" if an + NS record indicates that it should be authoritative for that zone. + +2.3. Inability to Follow Multiple Levels of Indirection + + Some iterative resolver implementations are unable to follow + sufficient levels of indirection. For example, consider the + following delegations: + + foo.example. IN NS ns1.example.com. + foo.example. IN NS ns2.example.com. + + example.com. IN NS ns1.test.example.net. + example.com. IN NS ns2.test.example.net. + + test.example.net. IN NS ns1.test.example.net. + test.example.net. IN NS ns2.test.example.net. + + An iterative resolver resolving the name "www.foo.example" must + follow two levels of indirection, first obtaining address records for + "ns1.test.example.net" or "ns2.test.example.net" in order to obtain + address records for "ns1.example.com" or "ns2.example.com" in order + to query those name servers for the address records of + "www.foo.example". Although this situation may appear contrived, we + have seen multiple similar occurrences and expect more as new generic + top-level domains (gTLDs) become active. We anticipate many zones in + new gTLDs will use name servers in existing gTLDs, increasing the + number of delegations using out-of-zone name servers. + +2.3.1. Recommendation + + Clearly constructing a delegation that relies on multiple levels of + indirection is not a good administrative practice. However, the + practice is widespread enough to require that iterative resolvers be + able to cope with it. Iterative resolvers SHOULD be able to handle + arbitrary levels of indirection resulting from out-of-zone name + + + +Larson & Barber Best Current Practice [Page 7] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + servers. Iterative resolvers SHOULD implement a level-of-effort + counter to avoid loops or otherwise performing too much work in + resolving pathological cases. + + A best practice that avoids this entire issue of indirection is to + name one or more of a zone's name servers in the zone itself. For + example, if the zone is named "example.com", consider naming some of + the name servers "ns{1,2,...}.example.com" (or similar). + +2.4. Aggressive Retransmission when Fetching Glue + + When an authoritative name server responds with a referral, it + includes NS records in the authority section of the response. + According to the algorithm in Section 4.3.2 of RFC 1034 [2], the name + server should also "put whatever addresses are available into the + additional section, using glue RRs if the addresses are not available + from authoritative data or the cache." Some name server + implementations take this address inclusion a step further with a + feature called "glue fetching". A name server that implements glue + fetching attempts to include address records for every NS record in + the authority section. If necessary, the name server issues multiple + queries of its own to obtain any missing address records. + + Problems with glue fetching can arise in the context of + "authoritative-only" name servers, which only serve authoritative + data and ignore requests for recursion. Such an entity will not + normally generate any queries of its own. Instead it answers non- + recursive queries from iterative resolvers looking for information in + zones it serves. With glue fetching enabled, however, an + authoritative server invokes an iterative resolver to look up an + unknown address record to complete the additional section of a + response. + + We have observed situations where the iterative resolver of a glue- + fetching name server can send queries that reach other name servers, + but is apparently prevented from receiving the responses. For + example, perhaps the name server is authoritative-only and therefore + its administrators expect it to receive only queries and not + responses. Perhaps unaware of glue fetching and presuming that the + name server's iterative resolver will generate no queries, its + administrators place the name server behind a network device that + prevents it from receiving responses. If this is the case, all + glue-fetching queries will go unanswered. + + We have observed name server implementations whose iterative + resolvers retry excessively when glue-fetching queries are + unanswered. A single com/net name server has received hundreds of + queries per second from a single such source. Judging from the + + + +Larson & Barber Best Current Practice [Page 8] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + specific queries received and based on additional analysis, we + believe these queries result from overly aggressive glue fetching. + +2.4.1. Recommendation + + Implementers whose name servers support glue fetching SHOULD take + care to avoid sending queries at excessive rates. Implementations + SHOULD support throttling logic to detect when queries are sent but + no responses are received. + +2.5. Aggressive Retransmission behind Firewalls + + A common occurrence and one of the largest sources of repeated + queries at the com/net and root name servers appears to result from + resolvers behind misconfigured firewalls. In this situation, an + iterative resolver is apparently allowed to send queries through a + firewall to other name servers, but not receive the responses. The + result is more queries than necessary because of retransmission, all + of which are useless because the responses are never received. Just + as with the glue-fetching scenario described in Section 2.4, the + queries are sometimes sent at excessive rates. To make matters + worse, sometimes the responses, sent in reply to legitimate queries, + trigger an alarm on the originator's intrusion detection system. We + are frequently contacted by administrators responding to such alarms + who believe our name servers are attacking their systems. + + Not only do some resolvers in this situation retransmit queries at an + excessive rate, but they continue to do so for days or even weeks. + This scenario could result from an organization with multiple + recursive name servers, only a subset of whose iterative resolvers' + traffic is improperly filtered in this manner. Stub resolvers in the + organization could be configured to query multiple recursive name + servers. Consider the case where a stub resolver queries a filtered + recursive name server first. The iterative resolver of this + recursive name server sends one or more queries whose replies are + filtered, so it cannot respond to the stub resolver, which times out. + Then the stub resolver retransmits to a recursive name server that is + able to provide an answer. Since resolution ultimately succeeds the + underlying problem might not be recognized or corrected. A popular + stub resolver implementation has a very aggressive retransmission + schedule, including simultaneous queries to multiple recursive name + servers, which could explain how such a situation could persist + without being detected. + + + + + + + + +Larson & Barber Best Current Practice [Page 9] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.5.1. Recommendation + + The most obvious recommendation is that administrators SHOULD take + care not to place iterative resolvers behind a firewall that allows + queries, but not the resulting replies, to pass through. + + Iterative resolvers SHOULD take care to avoid sending queries at + excessive rates. Implementations SHOULD support throttling logic to + detect when queries are sent but no responses are received. + +2.6. Misconfigured NS Records + + Sometimes a zone administrator forgets to add the trailing dot on the + domain names in the RDATA of a zone's NS records. Consider this + fragment of the zone file for "example.com": + + $ORIGIN example.com. + example.com. 3600 IN NS ns1.example.com ; Note missing + example.com. 3600 IN NS ns2.example.com ; trailing dots + + The zone's authoritative servers will parse the NS RDATA as + "ns1.example.com.example.com" and "ns2.example.com.example.com" and + return NS records with this incorrect RDATA in responses, including + typically the authority section of every response containing records + from the "example.com" zone. + + Now consider a typical sequence of queries. An iterative resolver + attempting to resolve address records for "www.example.com" with no + cached information for this zone will query a "com" authoritative + server. The "com" server responds with a referral to the + "example.com" zone, consisting of NS records with valid RDATA and + associated glue records. (This example assumes that the + "example.com" zone delegation information is correct in the "com" + zone.) The iterative resolver caches the NS RRSet from the "com" + server and follows the referral by querying one of the "example.com" + authoritative servers. This server responds with the + "www.example.com" address record in the answer section and, + typically, the "example.com" NS records in the authority section and, + if space in the message remains, glue address records in the + additional section. According to Section 5.4.1 of RFC 2181 [3], NS + records in the authority section of an authoritative answer are more + trustworthy than NS records from the authority section of a non- + authoritative answer. Thus, the "example.com" NS RRSet just received + from the "example.com" authoritative server overrides the + "example.com" NS RRSet received moments ago from the "com" + authoritative server. + + + + + +Larson & Barber Best Current Practice [Page 10] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + But the "example.com" zone contains the erroneous NS RRSet as shown + in the example above. Subsequent queries for names in "example.com" + will cause the iterative resolver to attempt to use the incorrect NS + records and so it will try to resolve the nonexistent names + "ns1.example.com.example.com" and "ns2.example.com.example.com". In + this example, since all of the zone's name servers are named in the + zone itself (i.e., "ns1.example.com.example.com" and + "ns2.example.com.example.com" both end in "example.com") and all are + bogus, the iterative resolver cannot reach any "example.com" name + servers. Therefore, attempts to resolve these names result in + address record queries to the "com" authoritative servers. Queries + for such obviously bogus glue address records occur frequently at the + com/net name servers. + +2.6.1. Recommendation + + An authoritative server can detect this situation. A trailing dot + missing from an NS record's RDATA always results by definition in a + name server name that exists somewhere under the apex of the zone + that the NS record appears in. Note that further levels of + delegation are possible, so a missing trailing dot could + inadvertently create a name server name that actually exists in a + subzone. + + An authoritative name server SHOULD issue a warning when one of a + zone's NS records references a name server below the zone's apex when + a corresponding address record does not exist in the zone AND there + are no delegated subzones where the address record could exist. + +2.7. Name Server Records with Zero TTL + + Sometimes a popular com/net subdomain's zone is configured with a TTL + of zero on the zone's NS records, which prohibits these records from + being cached and will result in a higher query volume to the zone's + authoritative servers. The zone's administrator should understand + the consequences of such a configuration and provision resources + accordingly. A zero TTL on the zone's NS RRSet, however, carries + additional consequences beyond the zone itself: if an iterative + resolver cannot cache a zone's NS records because of a zero TTL, it + will be forced to query that zone's parent's name servers each time + it resolves a name in the zone. The com/net authoritative servers do + see an increased query load when a popular com/net subdomain's zone + is configured with a TTL of zero on the zone's NS records. + + A zero TTL on an RRSet expected to change frequently is extreme but + permissible. A zone's NS RRSet is a special case, however, because + changes to it must be coordinated with the zone's parent. In most + zone parent/child relationships that we are aware of, there is + + + +Larson & Barber Best Current Practice [Page 11] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + typically some delay involved in effecting changes. Furthermore, + changes to the set of a zone's authoritative name servers (and + therefore to the zone's NS RRSet) are typically relatively rare: + providing reliable authoritative service requires a reasonably stable + set of servers. Therefore, an extremely low or zero TTL on a zone's + NS RRSet rarely makes sense, except in anticipation of an upcoming + change. In this case, when the zone's administrator has planned a + change and does not want iterative resolvers throughout the Internet + to cache the NS RRSet for a long period of time, a low TTL is + reasonable. + +2.7.1. Recommendation + + Because of the additional load placed on a zone's parent's + authoritative servers resulting from a zero TTL on a zone's NS RRSet, + under such circumstances authoritative name servers SHOULD issue a + warning when loading a zone. + +2.8. Unnecessary Dynamic Update Messages + + The UPDATE message specified in RFC 2136 [6] allows an authorized + agent to update a zone's data on an authoritative name server using a + DNS message sent over the network. Consider the case of an agent + desiring to add a particular resource record. Because of zone cuts, + the agent does not necessarily know the proper zone to which the + record should be added. The dynamic update process requires that the + agent determine the appropriate zone so the UPDATE message can be + sent to one of the zone's authoritative servers (typically the + primary master as specified in the zone's Start of Authority (SOA) + record's MNAME field). + + The appropriate zone to update is the closest enclosing zone, which + cannot be determined only by inspecting the domain name of the record + to be updated, since zone cuts can occur anywhere. One way to + determine the closest enclosing zone entails walking up the name + space tree by sending repeated UPDATE messages until successful. For + example, consider an agent attempting to add an address record with + the name "foo.bar.example.com". The agent could first attempt to + update the "foo.bar.example.com" zone. If the attempt failed, the + update could be directed to the "bar.example.com" zone, then the + "example.com" zone, then the "com" zone, and finally the root zone. + + A popular dynamic agent follows this algorithm. The result is many + UPDATE messages received by the root name servers, the com/net + authoritative servers, and presumably other TLD authoritative + servers. A valid question is why the algorithm proceeds to send + updates all the way to TLD and root name servers. This behavior is + not entirely unreasonable: in enterprise DNS architectures with an + + + +Larson & Barber Best Current Practice [Page 12] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + "internal root" design, there could conceivably be private, non- + public TLD or root zones that would be the appropriate targets for a + dynamic update. + + A significant deficiency with this algorithm is that knowledge of a + given UPDATE message's failure is not helpful in directing future + UPDATE messages to the appropriate servers. A better algorithm would + be to find the closest enclosing zone by walking up the name space + with queries for SOA or NS rather than "probing" with UPDATE + messages. Once the appropriate zone is found, an UPDATE message can + be sent. In addition, the results of these queries can be cached to + aid in determining the closest enclosing zones for future updates. + Once the closest enclosing zone is determined with this method, the + update will either succeed or fail and there is no need to send + further updates to higher-level zones. The important point is that + walking up the tree with queries yields cacheable information, + whereas walking up the tree by sending UPDATE messages does not. + +2.8.1. Recommendation + + Dynamic update agents SHOULD send SOA or NS queries to progressively + higher-level names to find the closest enclosing zone for a given + name to update. Only after the appropriate zone is found should the + client send an UPDATE message to one of the zone's authoritative + servers. Update clients SHOULD NOT "probe" using UPDATE messages by + walking up the tree to progressively higher-level zones. + +2.9. Queries for Domain Names Resembling IPv4 Addresses + + The root name servers receive a significant number of A record + queries where the QNAME looks like an IPv4 address. The source of + these queries is unknown. It could be attributed to situations where + a user believes that an application will accept either a domain name + or an IP address in a given configuration option. The user enters an + IP address, but the application assumes that any input is a domain + name and attempts to resolve it, resulting in an A record lookup. + There could also be applications that produce such queries in a + misguided attempt to reverse map IP addresses. + + These queries result in Name Error (RCODE=3) responses. An iterative + resolver can negatively cache such responses, but each response + requires a separate cache entry; i.e., a negative cache entry for the + domain name "192.0.2.1" does not prevent a subsequent query for the + domain name "192.0.2.2". + + + + + + + +Larson & Barber Best Current Practice [Page 13] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.9.1. Recommendation + + It would be desirable for the root name servers not to have to answer + these queries: they unnecessarily consume CPU resources and network + bandwidth. A possible solution is to delegate these numeric TLDs + from the root zone to a separate set of servers to absorb the + traffic. The "black hole servers" used by the AS 112 Project + (http://www.as112.net), which are currently delegated the + in-addr.arpa zones corresponding to RFC 1918 [7] private use address + space, would be a possible choice to receive these delegations. Of + course, the proper and usual root zone change procedures would have + to be followed to make such a change to the root zone. + +2.10. Misdirected Recursive Queries + + The root name servers receive a significant number of recursive + queries (i.e., queries with the Recursion Desired (RD) bit set in the + header). Since none of the root servers offers recursion, the + servers' response in such a situation ignores the request for + recursion and the response probably does not contain the data the + querier anticipated. Some of these queries result from users + configuring stub resolvers to query a root server. (This situation + is not hypothetical: we have received complaints from users when this + configuration does not work as hoped.) Of course, users should not + direct stub resolvers to use name servers that do not offer + recursion, but we are not aware of any stub resolver implementation + that offers any feedback to the user when so configured, aside from + simply "not working". + +2.10.1. Recommendation + + When the IP address of a name server that supposedly offers recursion + is configured in a stub resolver using an interactive user interface, + the resolver could send a test query to verify that the server indeed + supports recursion (i.e., verify that the response has the RA bit set + in the header). The user could be notified immediately if the server + is non-recursive. + + The stub resolver could also report an error, either through a user + interface or in a log file, if the queried server does not support + recursion. Error reporting SHOULD be throttled to avoid a + notification or log message for every response from a non-recursive + server. + + + + + + + + +Larson & Barber Best Current Practice [Page 14] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.11. Suboptimal Name Server Selection Algorithm + + An entire document could be devoted to the topic of problems with + different implementations of the recursive resolution algorithm. The + entire process of recursion is woefully under-specified, requiring + each implementor to design an algorithm. Sometimes implementors make + poor design choices that could be avoided if a suggested algorithm + and best practices were documented, but that is a topic for another + document. + + Some deficiencies cause significant operational impact and are + therefore worth mentioning here. One of these is name server + selection by an iterative resolver. When an iterative resolver wants + to contact one of a zone's authoritative name servers, how does it + choose from the NS records listed in the zone's NS RRSet? If the + selection mechanism is suboptimal, queries are not spread evenly + among a zone's authoritative servers. The details of the selection + mechanism are up to the implementor, but we offer some suggestions. + +2.11.1. Recommendation + + This list is not conclusive, but reflects the changes that would + produce the most impact in terms of reducing disproportionate query + load among a zone's authoritative servers. That is, these changes + would help spread the query load evenly. + + o Do not make assumptions based on NS RRSet order: all NS RRs SHOULD + be treated equally. (In the case of the "com" zone, for example, + most of the root servers return the NS record for + "a.gtld-servers.net" first in the authority section of referrals. + Apparently as a result, this server receives disproportionately + more traffic than the other twelve authoritative servers for + "com".) + + o Use all NS records in an RRSet. (For example, we are aware of + implementations that hard-coded information for a subset of the + root servers.) + + o Maintain state and favor the best-performing of a zone's + authoritative servers. A good definition of performance is + response time. Non-responsive servers can be penalized with an + extremely high response time. + + o Do not lock onto the best-performing of a zone's name servers. An + iterative resolver SHOULD periodically check the performance of + all of a zone's name servers to adjust its determination of the + best-performing one. + + + + +Larson & Barber Best Current Practice [Page 15] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +3. Security Considerations + + The iterative resolver misbehavior discussed in this document exposes + the root and TLD name servers to increased risk of both intentional + and unintentional Denial of Service attacks. + + We believe that implementation of the recommendations offered in this + document will reduce the amount of unnecessary traffic seen at root + and TLD name servers, thus reducing the opportunity for an attacker + to use such queries to his or her advantage. + +4. Acknowledgements + + The authors would like to thank the following people for their + comments that improved this document: Andras Salamon, Dave Meyer, + Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy, + Olafur Gudmundsson, Pekka Savola, Peter Koch, and Rob Austein. We + apologize if we have omitted anyone; any oversight was unintentional. + +5. Internationalization Considerations + + There are no new internationalization considerations introduced by + this memo. + +6. References + +6.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + +6.2. Informative References + + [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + + [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS + Queries for IPv6 Addresses", RFC 4074, May 2005. + + [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April + 1997. + + + +Larson & Barber Best Current Practice [Page 16] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + [7] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. + Lear, "Address Allocation for Private Internets", BCP 5, RFC + 1918, February 1996. + +Authors' Addresses + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Piet Barber + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: pbarber@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Best Current Practice [Page 17] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Larson & Barber Best Current Practice [Page 18] +