diff --git a/doc/draft/draft-ietf-dhc-dhcp-dns-12.txt b/doc/draft/draft-ietf-dhc-dhcp-dns-12.txt deleted file mode 100644 index d2424d073e..0000000000 --- a/doc/draft/draft-ietf-dhc-dhcp-dns-12.txt +++ /dev/null @@ -1,1072 +0,0 @@ - - -DHC Working Group M. Stapp -Internet-Draft Y. Rekhter -Expires: September 2000 Cisco Systems, Inc. - March 10, 2000 - - - Interaction between DHCP and DNS - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - To view the entire list of Internet-Draft Shadow Directories, see - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 2000. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - DHCP provides a powerful mechanism for IP host configuration. - However, the configuration capability provided by DHCP does not - include updating DNS, and specifically updating the name to address - and address to name mappings maintained in the DNS. - - This document specifies how DHCP clients and servers should use the - Dynamic DNS Updates mechanism in RFC2136[5] to update the DNS name - to address and address to name mappings so that the mappings for - DHCP clients will be consistent with the IP addresses that the - clients acquire via DHCP. - - - - - - - -Stapp & Rekhter Expires September 2000 [Page 1] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - -Table of Contents - - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Models of Operation . . . . . . . . . . . . . . . . . . . . 3 - 4. Issues with DDNS in DHCP Environments . . . . . . . . . . . 4 - 4.1 Name Collisions . . . . . . . . . . . . . . . . . . . . . . 5 - 4.2 Multiple DHCP servers . . . . . . . . . . . . . . . . . . . 6 - 4.3 Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 6 - 4.3.1 Format of the DHCID RRDATA . . . . . . . . . . . . . . . . . 6 - 4.4 DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Client FQDN Option . . . . . . . . . . . . . . . . . . . . . 8 - 5.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 9 - 5.2 The RCODE Fields . . . . . . . . . . . . . . . . . . . . . . 10 - 5.3 The Domain Name Field . . . . . . . . . . . . . . . . . . . 10 - 6. DHCP Client behavior . . . . . . . . . . . . . . . . . . . . 10 - 7. DHCP Server behavior . . . . . . . . . . . . . . . . . . . . 12 - 8. Procedures for performing DNS updates . . . . . . . . . . . 14 - 8.1 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . 14 - 8.2 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . 15 - 8.3 Removing Entries from DNS . . . . . . . . . . . . . . . . . 15 - 8.4 Updating other RRs . . . . . . . . . . . . . . . . . . . . . 16 - 9. Security Considerations . . . . . . . . . . . . . . . . . . 16 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 - - - - - - - - - - - - - - - - - - - - - - - - -Stapp & Rekhter Expires September 2000 [Page 2] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - -1. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119[6]. - -2. Introduction - - DNS (RFC1034[1], RFC1035[2]) maintains (among other things) the - information about mapping between hosts' Fully Qualified Domain - Names (FQDNs) RFC1594[4] and IP addresses assigned to the hosts. The - information is maintained in two types of Resource Records (RRs): A - and PTR. The A RR contains mapping from a FQDN to an IP address; the - PTR RR contains mapping from an IP address to a FQDN. The Dynamic - DNS Updates specification (RFC2136[5]) describes a mechanism that - enables DNS information to be updated over a network. - - DHCP RFC2131[3] provides a mechanism by which a host (a DHCP client) - can acquire certain configuration information, along with its IP - address(es). However, DHCP does not provide any mechanisms to update - the DNS RRs that contain the information about mapping between the - host's FQDN and its IP address(es) (A and PTR RRs). Thus the - information maintained by DNS for a DHCP client may be incorrect - a - host (the client) could acquire its address by using DHCP, but the A - RR for the host's FQDN wouldn't reflect the address that the host - acquired, and the PTR RR for the acquired address wouldn't reflect - the host's FQDN. - - The Dynamic DNS Update protocol can be used to maintain consistency - between the information stored in the A and PTR RRs and the actual - address assignment done via DHCP. When a host with a particular FQDN - acquires its IP address via DHCP, the A RR associated with the - host's FQDN would be updated (by using the Dynamic DNS Updates - protocol) to reflect the new address. Likewise, when an IP address - is assigned to a host with a particular FQDN, the PTR RR associated - with this address would be updated (using the Dynamic DNS Updates - protocol) to reflect the new FQDN. - - Although this document refers to the A and PTR DNS record types and - to DHCP assignment of IPv4 addresses, the same procedures and - requirements apply for updates to the analogous RR types that are - used when clients are assigned IPv6 addresses via DHCPv6. - -3. Models of Operation - - When a DHCP client acquires a new address, a site's administrator - may desire that one or both of the A RR for the client's FQDN and - the PTR RR for the acquired address be updated. Therefore, two - separate Dynamic DNS Update transactions occur. Acquiring an address - - -Stapp & Rekhter Expires September 2000 [Page 3] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - via DHCP involves two entities: a DHCP client and a DHCP server. In - principle each of these entities could perform none, one, or both of - the transactions. However, in practice not all permutations make - sense. This document covers these possible design permutations: - - 1. DHCP client updates the A RR, DHCP server updates the PTR RR - 2. DHCP server updates both the A and the PTR RRs - - The only difference between these two cases is whether the FQDN to - IP address mapping is updated by a DHCP client or by a DHCP server. - The IP address to FQDN mapping is updated by a DHCP server in both - cases. - - The reason these two are important, while others are unlikely, has - to do with authority over the respective DNS domain names. A DHCP - client may be given authority over mapping its own A RRs, or that - authority may be restricted to a server to prevent the client from - listing arbitrary addresses or associating its address with - arbitrary domain names. In all cases, the only reasonable place for - the authority over the PTR RRs associated with the address is in the - DHCP server that allocates the address. - - In any case, whether a site permits all, some, or no DHCP servers - and clients to perform DNS updates into the zones which it controls - is entirely a matter of local administrative policy. This document - does not require any specific administrative policy, and does not - propose one. The range of possible policies is very broad, from - sites where only the DHCP servers have been given credentials that - the DNS servers will accept, to sites where each individual DHCP - client has been configured with credentials which allow the client - to modify its own domain name. Compliant implementations MAY support - some or all of these possibilities. Furthermore, this specification - applies only to DHCP client and server processes: it does not apply - to other processes which initiate dynamic DNS updates. - - This document describes a new DHCP option which a client can use to - convey all or part of its domain name to a DHCP server. - Site-specific policy determines whether DHCP servers use the names - that clients offer or not, and what DHCP servers may do in cases - where clients do not supply domain names. - -4. Issues with DDNS in DHCP Environments - - There are two DNS update situations that require special - consideration in DHCP environments: cases where more than one DHCP - client has been configured with the same FQDN, and cases where more - than one DHCP server has been given authority to perform DNS updates - in a zone. In these cases, it is possible for DNS records to be - modified in inconsistent ways unless the updaters have a mechanism - that allows them to detect anomolous situations. If DNS updaters can - - -Stapp & Rekhter Expires September 2000 [Page 4] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - detect these situations, site administrators can configure the - updaters' behavior so that the site's policies can be enforced. We - use the term "Name Collisions" to refer to cases where more than one - DHCP client has been associated with a single FQDN. This - specification describes a mechanism designed to allow updaters to - detect these situations, and requires that DHCP implementations use - this mechanism by default. - -4.1 Name Collisions - - How can the entity updating an A RR (either the DHCP client or DHCP - server) detect that a domain name has an A RR which is already in - use by a different DHCP client? Similarly, should a DHCP client or - server update a domain name which has an A RR that has been - configured by an administrator? In either of these cases, the - domain name in question would either have an additional A RR, or - would have its original A RR replaced by the new record. Either of - these effects may be considered undesirable by some sites. Different - authority and credential models have different levels of exposure to - name collisions. - - 1. Client updates A RR, uses Secure DNS Update with credentials - that are associated with the client's FQDN, and exclusive to the - client. Name collisions in this scenario are unlikely (though - not impossible), since the client has received credentials - specific to the name it desires to use. This implies that the - name has already been allocated (through some implementation- or - organization-specific procedure) to that client. - - 2. Client updates A RR, uses Secure DNS Update with credentials - that are valid for any name in the zone. Name collisions in this - scenario are possible, since the credentials necessary for the - client to update DNS are not necessarily name-specific. Thus, - for the client to be attempting to update a unique name requires - the existence of some administrative procedure to ensure client - configuration with unique names. - - 3. Server updates the A RR, uses a name for the client which is - known to the server. Name collisions in this scenario are likely - unless prevented by the server's name configuration procedures. - See Section 9 for security issues with this form of deployment. - - 4. Server updates the A RR, uses a name supplied by the client. - Name collisions in this scenario are highly likely, even with - administrative procedures designed to prevent them. (This - scenario is a popular one in real-world deployments in many - types of organizations.) See Section 9 for security issues with - this type of deployment. - - - Scenarios 2, 3, and 4 rely on administrative procedures to ensure - name uniqueness for DNS updates, and these procedures may break - down. Experience has shown that, in fact, these procedures will - break down at least occasionally. The question is what to do when - - -Stapp & Rekhter Expires September 2000 [Page 5] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - these procedures break down or, for example in scenario #4, may not - even exist. - - In all cases of name collisions, the desire is to offer two modes of - operation to the administrator of the combined DHCP-DNS capability: - first-update-wins (i.e., the first updating entity gets the name) or - most-recent-update-wins (i.e., the last updating entity for a name - gets the name). - -4.2 Multiple DHCP servers - - If multiple DHCP servers are able to update the same DNS zones, or - if DHCP servers are performing A RR updates on behalf of DHCP - clients, and more than one DHCP server may be able to serve - addresses to the same DHCP clients, the DHCP servers should be able - to provide reasonable and consistent DNS name update behavior for - DHCP clients. - -4.3 Use of the DHCID RR - - A solution to both of these problems is for the updating entities - (both DHCP clients and DHCP servers) to be able to detect that - another entity has been associated with a DNS name, and to offer - administrators the opportunity to configure update behavior. - - Specifically, a DHCID RR, described in DHCID RR[12] is used to - associate client identification information with a DNS name and the - A RR associated with that name. When either a client or server adds - an A RR for a client, it also adds a DHCID RR which specifies a - unique client identity (based on a "client specifier" created from - the client's client-id or MAC address). In this model, only one A - RR is associated with a given DNS name at a time. - - By associating this ownership information with each A RR, - cooperating DNS updating entities may determine whether their client - is the first or last updater of the name (and implement the - appropriately configured administrative policy), and DHCP clients - which currently have a host name may move from one DHCP server to - another without losing their DNS name. - - The specific algorithms utilizing the DHCID RR to signal client - ownership are explained below. The algorithms only work in the case - where the updating entities all cooperate -- this approach is - advisory only and is not substitute for DNS security, nor is it - replaced by DNS security. - -4.3.1 Format of the DHCID RRDATA - - The DHCID RR used to hold the DHCP client's identity is formatted as - - -Stapp & Rekhter Expires September 2000 [Page 6] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - follows: - - The name of the DHCID RR is the name of the A or PTR RR which refers - to the DHCP client. - - The RDATA section of a DHCID RR in transmission contains RDLENGTH - bytes of binary data. From the perspective of DHCP clients and - servers, the DHC resource record consists of a 16-bit identifier - type, followed by one or more bytes representing the actual - identifier. There are two possible forms for a DHCID RR - one that - is used when the client's link-layer address is being used to - identify it, and one that is used when some DHCP option that the - DHCP client has sent is being used to identify it. - - - DISCUSSION: - Implementors should note that the actual identifying data is - never placed into the DNS directly. Instead, the client-identity - data is used as the input into a one-way hash algorithm, and the - output of that hash is then used as DNS RRDATA. This has been - specified in order to avoid placing data about DHCP clients that - some sites might consider sensitive into the DNS. - - When the updater is using the client's link-layer address, the first - two bytes of the DHCID RRDATA MUST be zero. To generate the rest of - the resource record, the updater MUST compute a one-way hash using - the MD5[13] algorithm across a buffer containing the client's - network hardware type and link-layer address. Specifically, the - first byte of the buffer contains the network hardware type as it - appears in the DHCP htype field of the client's DHCPREQUEST message. - All of the significant bytes of the chaddr field in the client's - DHCPREQUEST message follow, in the same order in which the bytes - appear in the DHCPREQUEST message. The number of significant bytes - in the chaddr field is specified in the hlen field of the - DHCPREQUEST message. - - When the updater is using a DHCP option sent by the client in its - DHCPREQUEST message, the first two bytes of the DHCID RR MUST be the - option code of that option, in network byte order. For example, if - the DHCP client identifier option is being used, the first byte of - the DHCID RR should be zero, and the second byte should be 61 - decimal. The rest of the DHCID RR MUST contain the results of - computing a one-way hash across the payload of the option being - used, using the MD5 algorithm. The payload of a DHCP option consists - of the bytes of the option following the option code and length. - - In order for independent DHCP implementations to be able to use the - DHCID RR as a prerequisite in dynamic DNS updates, each updater must - be able to reliably choose the same identifier that any other would - choose. To make this possible, we specify a prioritization which - - -Stapp & Rekhter Expires September 2000 [Page 7] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - will ensure that for any given DHCP client request, any updater will - select the same client-identity data. All updaters MUST use this - order of prioritization by default, but all implementations SHOULD - be configurable to use a different prioritization if so desired by - the site administrators. Because of the possibility of future - changes in the DHCP protocol, implementors SHOULD check for updated - versions of this draft when implementing new DHCP clients and - servers which can perform DDNS updates, and also when releasing new - versions of existing clients and servers. - - DHCP clients and servers should use the following forms of client - identification, starting with the most preferable, and finishing - with the least preferable. If the client does not send any of these - forms of identification, the DHCP/DDNS interaction is not defined by - this specification. The most preferable form of identification is - the Globally Unique Identifier Option [TBD]. Next is the DHCP - Client Identifier option. Last is the client's link-layer address, - as conveyed in its DHCPREQUEST message. Implementors should note - that the link-layer address cannot be used if there are no - significant bytes in the chaddr field of the DHCP client's request, - because this does not constitute a unique identifier. - -4.4 DNS RR TTLs - - RRs associated with DHCP clients may be more volatile than - statically configured RRs. DHCP clients and servers which perform - dynamic updates should attempt to specify resource record TTLs which - reflect this volatility, in order to minimize the possibility that - there will be stale records in resolvers' caches. A reasonable basis - for RR TTLs is the lease duration itself: TTLs of 1/2 or 1/3 the - expected lease duration might be reasonable defaults. Because - configured DHCP lease times vary widely from site to site, it may - also be desirable to establish a fixed TTL ceiling. DHCP clients and - servers MAY allow administrators to configure the TTLs they will - supply, possibly as a fraction of the actual lease time, or as a - fixed value. - -5. Client FQDN Option - - To update the IP address to FQDN mapping a DHCP server needs to know - the FQDN of the client to which the server leases the address. To - allow the client to convey its FQDN to the server this document - defines a new DHCP option, called "Client FQDN". The FQDN Option - also contains Flags and RCode fields which DHCP servers can use to - convey information about DNS updates to clients. - - Clients MAY send the FQDN option, setting appropriate Flags values, - in both their DISCOVER and REQUEST messages. If a client sends the - FQDN option in its DISCOVER message, it MUST send the option in - - -Stapp & Rekhter Expires September 2000 [Page 8] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - subsequent REQUEST messages. - - The code for this option is 81. Its minimum length is 4. - - - Code Len Flags RCODE1 RCODE2 Domain Name - +------+------+------+------+------+------+-- - | 81 | n | | | | ... - +------+------+------+------+------+------+-- - - -5.1 The Flags Field - - - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+ - | MBZ |E|O|S| - +-+-+-+-+-+-+-+-+ - - - When a DHCP client sends the FQDN option in its DHCPDISCOVER and/or - DHCPREQUEST messages, it sets the right-most bit (labelled "S") to - indicate that it will not perform any Dynamic DNS updates, and that - it expects the DHCP server to perform any FQDN-to-IP (the A RR) DNS - update on its behalf. If this bit is clear, the client indicates - that it intends to maintain its own FQDN-to-IP mapping update. - - If a DHCP server intends to take responsibility for the A RR update - whether or not the client sending the FQDN option has set the "S" - bit, it sets both the "O" bit and the "S" bit, and sends the FQDN - option in its DHCPOFFER and/or DHCPACK messages. - - The data in the Domain Name field may appear in one of two formats: - ASCII, or DNS-style binary encoding (without compression, of - course), as described in RFC1035[2]. A client which sends the FQDN - option MUST set the "E" bit to indicate that the data in the Domain - Name field is DNS binary encoded. If a server receives an FQDN - option from a client, and intends to include an FQDN option in its - reply, it MUST use the same encoding that the client used. The DNS - encoding is recommended. The use of ASCII-encoded domain-names is - fragile, and the use of ASCII encoding in this option should be - considered deprecated. - - The remaining bits in the Flags field are reserved for future - assignment. DHCP clients and servers which send the FQDN option MUST - set the MBZ bits to 0, and they MUST ignore values in the part of - the field labelled "MBZ". - - - - -Stapp & Rekhter Expires September 2000 [Page 9] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - -5.2 The RCODE Fields - - The RCODE1 and RCODE2 fields are used by a DHCP server to indicate - to a DHCP client the Response Code from any A or PTR RR Dynamic DNS - Updates it has performed. The server may also use these fields to - indicate whether it has attempted such an update before sending the - DHCPACK message. Each of these fields is one byte long. - - Implementors should note that EDNS0 describes a mechanism for - extending the length of a DNS RCODE to 12 bits. EDNS0 is specified - in RFC2671[8]. Only the least-significant 8 bits of the RCODE from a - Dynamic DNS Update will be carried in the Client FQDN DHCP Option. - This provides enough number space to accomodate the RCODEs defined - in the Dynamic DNS Update specification. - -5.3 The Domain Name Field - - The Domain Name part of the option carries all or part of the FQDN - of a DHCP client. A client may be configured with a fully-qualified - domain name, or with a partial name that is not fully-qualified. If - a client knows only part of its name, it MAY send a single label, - indicating that it knows part of the name but does not necessarily - know the zone in which the name is to be embedded. The data in the - Domain Name field may appear in one of two formats: ASCII (with no - terminating NULL), or DNS encoding as specified in RFC1035[2]. If - the DHCP client wishes to use DNS encoding, it MUST set the - third-from-rightmost bit in the Flags field (the "E" bit); if it - uses ASCII encoding, it MUST clear the "E" bit. - - A DHCP client that can only send a single label using ASCII encoding - includes a series of ASCII characters in the Domain Name field, - excluding the "." (dot) character. The client SHOULD follow the - character-set recommendations of RFC1034[1] and RFC1035[2]. A client - using DNS binary encoding which wants to suggest part of its FQDN - MAY send a non-terminal sequence of labels in the Domain Name part - of the option. - -6. DHCP Client behavior - - The following describes the behavior of a DHCP client that - implements the Client FQDN option. - - If a client that owns/maintains its own FQDN wants to be responsible - for updating the FQDN to IP address mapping for the FQDN and - address(es) used by the client, then the client MUST include the - Client FQDN option in the DHCPREQUEST message originated by the - client. A DHCP client MAY choose to include the Client FQDN option - in its DISCOVER messages as well as its REQUEST messages. The - rightmost ("S") bit in the Flags field in the option MUST be set to - - -Stapp & Rekhter Expires September 2000 [Page 10] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - 0. Once the client's DHCP configuration is completed (the client - receives a DHCPACK message, and successfully completes a final check - on the parameters passed in the message), the client MAY originate - an update for the A RR (associated with the client's FQDN). The - update MUST be originated following the procedures described in - RFC2136[5] and Section 8. If the DHCP server from which the client - is requesting a lease includes the FQDN option in its ACK message, - and if the server sets both the "S" and the "O" bits (the two - rightmost bits) in the option's flags field, the DHCP client MUST - NOT initiate an update for the name in the Domain Name field. - - A client can choose to delegate the responsibility for updating the - FQDN to IP address mapping for the FQDN and address(es) used by the - client to the server. In order to inform the server of this choice, - the client SHOULD include the Client FQDN option in its DHCPREQUEST - message. The rightmost (or "S") bit in the Flags field in the option - MUST be set to 1. A client which delegates this responsibility MUST - NOT attempt to perform a Dynamic DNS update for the name in the - Domain Name field of the FQDN option. The client MAY supply an FQDN - in the Client FQDN option, or it MAY supply a single label (the - most-specific label), or it MAY leave that field empty as a signal - to the server to generate an FQDN for the client in any manner the - server chooses. - - Since there is a possibility that the DHCP server may be configured - to complete or replace a domain name that the client was configured - to send, the client might find it useful to send the FQDN option in - its DISCOVER messages. If the DHCP server returns different Domain - Name data in its OFFER message, the client could use that data in - performing its own eventual A RR update, or in forming the FQDN - option that it sends in its REQUEST message. There is no requirement - that the client send identical FQDN option data in its DISCOVER and - REQUEST messages. In particular, if a client has sent the FQDN - option to its server, and the configuration of the client changes so - that its notion of its domain name changes, it MAY send the new name - data in an FQDN option when it communicates with the server again. - This may allow the DHCP server to update the name associated with - the PTR record, and, if the server updated the A record representing - the client, to delete that record and attempt an update for the - client's current domain name. - - A client that delegates the responsibility for updating the FQDN to - IP address mapping to a server might not receive any indication - (either positive or negative) from the server whether the server was - able to perform the update. In this case the client MAY use a DNS - query to check whether the mapping is updated. - - A client MUST set the RCODE1 and RCODE2 fields in the Client FQDN - option to 0 when sending the option. - - -Stapp & Rekhter Expires September 2000 [Page 11] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - If a client releases its lease prior to the lease expiration time - and the client is responsible for updating its A RR, the client - SHOULD delete the A RR (following the procedures described in - Section 8) associated with the leased address before sending a DHCP - RELEASE message. Similarly, if a client was responsible for updating - its A RR, but is unable to renew its lease, the client SHOULD - attempt to delete the A RR before its lease expires. A DHCP client - which has not been able to delete an A RR which it added (because it - has lost the use of its DHCP IP address) should attempt to notify - its administrator. - -7. DHCP Server behavior - - When a server receives a DHCPREQUEST message from a client, if the - message contains the Client FQDN option, and the server replies to - the message with a DHCPACK message, the server may be configured to - originate an update for the PTR RR (associated with the address - leased to the client). Any such update MUST be originated following - the procedures described in Section 8. The server MAY complete the - update before the server sends the DHCPACK message to the client. In - this case the RCODE from the update MUST be carried to the client in - the RCODE1 field of the Client FQDN option in the DHCPACK message. - Alternatively, the server MAY send the DHCPACK message to the client - without waiting for the update to be completed. In this case the - RCODE1 field of the Client FQDN option in the DHCPACK message MUST - be set to 255. The choice between the two alternatives is entirely - determined by the configuration of the DHCP server. Servers SHOULD - support both configuration options. - - When a server receives a DHCPREQUEST message containing the Client - FQDN option, the server MUST ignore the values carried in the RCODE1 - and RCODE2 fields of the option. - - In addition, if the Client FQDN option carried in the DHCPREQUEST - message has the "S" bit in its Flags field set, then the server MAY - originate an update for the A RR (associated with the FQDN carried - in the option) if it is configured to do so by the site's - administrator, and if it has the necessary credentials. The server - MAY be configured to use the name supplied in the client's FQDN - option, or it MAY be configured to modify the supplied name, or - substitute a different name. - - Any such update MUST be originated following the procedures - described in Section 8. The server MAY originate the update before - the server sends the DHCPACK message to the client. In this case the - RCODE from the update [RFC2136] MUST be carried to the client in the - RCODE2 field of the Client FQDN option in the DHCPACK message. - Alternatively the server MAY send the DHCPACK message to the client - without waiting for the update to be completed. In this case the - - -Stapp & Rekhter Expires September 2000 [Page 12] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - RCODE2 field of the Client FQDN option in the DHCPACK message MUST - be set to 255. The choice between the two alternatives is entirely - up to the DHCP server. In either case, if the server intends to - perform the DNS update and the client's REQUEST message included the - FQDN option, the server SHOULD include the FQDN option in its ACK - message, and MUST set the "S" bit in the option's Flags field. - - Even if the Client FQDN option carried in the DHCPREQUEST message - has the "S" bit in its Flags field clear (indicating that the client - wants to update the A RR), the server MAY be configured by the local - administrator to update the A RR on the client's behalf. A server - which is configured to override the client's preference SHOULD - include an FQDN option in its ACK message, and MUST set both the "O" - and "S" bits in the FQDN option's Flags field. The update MUST be - originated following the procedures described in Section 8. The - server MAY originate the update before the server sends the DHCPACK - message to the client. In this case the RCODE from the update - [RFC2136] MUST be carried to the client in the RCODE2 field of the - Client FQDN option in the DHCPACK message. Alternatively, the server - MAY send the DHCPACK message to the client without waiting for the - update to be completed. In this case the RCODE2 field of the Client - FQDN option in the DHCPACK message MUST be set to 255. Whether the - DNS update occurs before or after the DHCPACK is sent is entirely up - to the DHCP server's configuration. - - When a DHCP server sends the Client FQDN option to a client in the - DHCPACK message, the DHCP server SHOULD send its notion of the - complete FQDN for the client in the Domain Name field. The server - MAY simply copy the Domain Name field from the Client FQDN option - that the client sent to the server in the DHCPREQUEST message. The - DHCP server MAY be configured to complete or modify the domain name - which a client sent, or it MAY be configured to substitute a - different name. If the server initiates a DDNS update which is not - complete until after the server has replied to the DHCP client, the - server's The server MUST use the same encoding format (ASCII or DNS - binary encoding) that the client used in the FQDN option in its - DHCPREQUEST, and MUST set the "E" bit in the option's Flags field - accordingly. - - If a client's DHCPREQUEST message doesn't carry the Client FQDN - option (e.g., the client doesn't implement the Client FQDN option), - the server MAY be configured to update either or both of the A and - PTR RRs. The updates MUST be originated following the procedures - described in Section 8. - - If a server detects that a lease on an address that the server - leases to a client has expired, the server SHOULD delete any PTR RR - which it added via dynamic update. In addition, if the server added - an A RR on the client's behalf, the server SHOULD also delete the A - - -Stapp & Rekhter Expires September 2000 [Page 13] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - RR. The deletion MUST follow the procedures described in Section 8. - - If a server terminates a lease on an address prior to the lease's - expiration time, for instance by sending a DHCPNAK to a client, the - server SHOULD delete any PTR RR which it associated with the address - via DNS Dynamic Update. In addition, if the server took - responsibility for an A RR, the server SHOULD also delete that A RR. - The deletion MUST follow the procedures described in Section 8. - -8. Procedures for performing DNS updates - -8.1 Adding A RRs to DNS - - When a DHCP client or server intends to update an A RR, it first - prepares a DNS UPDATE query which includes as a prerequisite the - assertion that the name does not exist. The update section of the - query attempts to add the new name and its IP address mapping (an A - RR), and the DHCID RR with its unique client-identity. - - If this update operation succeeds, the updater can conclude that it - has added a new name whose only RRs are the A and DHCID RR records. - The A RR update is now complete (and a client updater is finished, - while a server might proceed to perform a PTR RR update). - - If the first update operation fails with YXDOMAIN, the updater can - conclude that the intended name is in use. The updater then - attempts to confirm that the DNS name is not being used by some - other host. The updater prepares a second UPDATE query in which the - prerequisite is that the desired name has attached to it a DHCID RR - whose contents match the client identity. The update section of - this query deletes the existing A records on the name, and adds the - A record that matches the DHCP binding and the DHCID RR with the - client identity. - - If this query succeeds, the updater can conclude that the current - client was the last client associated with the domain name, and that - the name now contains the updated A RR. The A RR update is now - complete (and a client updater is finished, while a server would - then proceed to perform a PTR RR update). - - If the second query fails with NXRRSET, the updater must conclude - that the client's desired name is in use by another host. At this - juncture, the updater can decide (based on some administrative - configuration outside of the scope of this document) whether to let - the existing owner of the name keep that name, and to (possibly) - perform some name disambiguation operation on behalf of the current - client, or to replace the RRs on the name with RRs that represent - the current client. If the configured policy allows replacement of - existing records, the updater submits a query that deletes the - - -Stapp & Rekhter Expires September 2000 [Page 14] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - existing A RR and the existing DHCID RR, adding A and DHCID RRs that - represent the IP address and client-identity of the new client. - - - DISCUSSION: - The updating entity may be configured to allow the existing DNS - records on the domain name to remain unchanged, and to perform - disambiguation on the name of the current client in order to - attempt to generate a similar but unique name for the current - client. In this case, once another candidate name has been - generated, the updater should restart the process of adding an A - RR as specified in this section. - -8.2 Adding PTR RR Entries to DNS - - The DHCP server submits a DNS query which deletes all of the PTR RRs - associated with the lease IP address, and adds a PTR RR whose data - is the client's (possibly disambiguated) host name. The server also - adds a DHCID RR specified in Section 4.3. - -8.3 Removing Entries from DNS - - The most important consideration in removing DNS entries is be sure - that an entity removing a DNS entry is only removing an entry that - it added, or for which an administrator has explicitly assigned it - responsibility. - - When a lease expires or a DHCP client issues a DHCPRELEASE request, - the DHCP server SHOULD delete the PTR RR that matches the DHCP - binding, if one was successfully added. The server's update query - SHOULD assert that the name in the PTR record matches the name of - the client whose lease has expired or been released. - - The entity chosen to handle the A record for this client (either the - client or the server) SHOULD delete the A record that was added when - the lease was made to the client. - - In order to perform this delete, the updater prepares an UPDATE - query which contains two prerequisites. The first prerequisite - asserts that the DHCID RR exists whose data is the client identity - described in Section 4.3. The second prerequisite asserts that the - data in the A RR contains the IP address of the lease that has - expired or been released. - - If the query fails, the updater MUST NOT delete the DNS name. It - may be that the host whose lease on the server has expired has moved - to another network and obtained a lease from a different server, - which has caused the client's A RR to be replaced. It may also be - that some other client has been configured with a name that matches - the name of the DHCP client, and the policy was that the last client - - -Stapp & Rekhter Expires September 2000 [Page 15] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - to specify the name would get the name. In this case, the DHCID RR - will no longer match the updater's notion of the client-identity of - the host pointed to by the DNS name. - -8.4 Updating other RRs - - The procedures described in this document only cover updates to the - A and PTR RRs. Updating other types of RRs is outside the scope of - this document. - -9. Security Considerations - - Unauthenticated updates to the DNS can lead to tremendous confusion, - through malicious attack or through inadvertent misconfiguration. - Administrators should be wary of permitting unsecured DNS updates to - zones which are exposed to the global Internet. Both DHCP clients - and servers SHOULD use some form of update request origin - authentication procedure (e.g., Simple Secure DNS Update[11]) when - performing DNS updates. - - Whether a DHCP client may be responsible for updating an FQDN to IP - address mapping, or whether this is the responsibility of the DHCP - server is a site-local matter. The choice between the two - alternatives may be based on the security model that is used with - the Dynamic DNS Update protocol (e.g., only a client may have - sufficient credentials to perform updates to the FQDN to IP address - mapping for its FQDN). - - Whether a DHCP server is always responsible for updating the FQDN to - IP address mapping (in addition to updating the IP to FQDN mapping), - regardless of the wishes of an individual DHCP client, is also a - site-local matter. The choice between the two alternatives may be - based on the security model that is being used with dynamic DNS - updates. In cases where a DHCP server is performing DNS updates on - behalf of a client, the DHCP server should be sure of the DNS name - to use for the client, and of the identity of the client. - - Currently, it is difficult for DHCP servers to develop much - confidence in the identities of its clients, given the absence of - entity authentication from the DHCP protocol itself. There are many - ways for a DHCP server to develop a DNS name to use for a client, - but only in certain relatively unusual circumstances will the DHCP - server know for certain the identity of the client. If DHCP - Authentication[10] becomes widely deployed this may become more - customary. - - One example of a situation which offers some extra assurances is one - where the DHCP client is connected to a network through an MCNS - cable modem, and the CMTS (head-end) of the cable modem ensures that - - -Stapp & Rekhter Expires September 2000 [Page 16] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - MAC address spoofing simply does not occur. Another example of a - configuration that might be trusted is one where clients obtain - network access via a network access server using PPP. The NAS itself - might be obtaining IP addresses via DHCP, encoding a client - identification into the DHCP client-id option. In this case, the - network access server as well as the DHCP server might be operating - within a trusted environment, in which case the DHCP server could be - configured to trust that the user authentication and authorization - procedure of the remote access server was sufficient, and would - therefore trust the client identification encoded within the DHCP - client-id. - -10. Acknowledgements - - Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter - Ford, Edie Gunter, Andreas Gustafsson, R. Barr Hibbs, Kim Kinnear, - Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, Josh Littlefield, - Michael Patton, and Glenn Stump for their review and comments. - -References - - [1] Mockapetris, P., "Domain names - Concepts and Facilities", RFC - 1034, Nov 1987. - - [2] Mockapetris, P., "Domain names - Implementation and - Specification", RFC 1035, Nov 1987. - - [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - - [4] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and - Answers to Commonly asked ``New Internet User'' Questions", RFC - 1594, March 1994. - - [5] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System", RFC 2136, April 1997. - - [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - - [7] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG) - (draft-ietf-dnsext-tsig-*)", July 1999. - - -Stapp & Rekhter Expires September 2000 [Page 17] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - - [10] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages - (draft-ietf-dhc-authentication-*)", June 1999. - - [11] Wellington, B., "Simple Secure DNS Dynamic Updates - (draft-ietf-dnsext-simple-secure-update-*)", June 1999. - - [12] Gustafsson, A., "A DNS RR for encoding DHCP client identity - (draft-ietf-dnsext-dhcid-rr-*)", October 1999. - - [13] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, - April 1992. - -Authors' Addresses - - Mark Stapp - Cisco Systems, Inc. - 250 Apollo Dr. - Chelmsford, MA 01824 - US - - Phone: 978.244.8498 - EMail: mjs@cisco.com - - Yakov Rekhter - Cisco Systems, Inc. - 170 Tasman Dr. - San Jose, CA 95134 - US - - Phone: 914.235.2128 - EMail: yakov@cisco.com - - - - - - - - - - - - - - - - - - - - -Stapp & Rekhter Expires September 2000 [Page 18] - -Internet-Draft Interaction between DHCP and DNS March 2000 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Stapp & Rekhter Expires September 2000 [Page 19] - diff --git a/doc/draft/draft-ietf-dhc-dhcp-dns-13.txt b/doc/draft/draft-ietf-dhc-dhcp-dns-13.txt new file mode 100644 index 0000000000..c15c2cd116 --- /dev/null +++ b/doc/draft/draft-ietf-dhc-dhcp-dns-13.txt @@ -0,0 +1,20 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +Y. Rekhter: yakov@cisco.com +M. Stapp: mark@american.com + + diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-00.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-00.txt deleted file mode 100644 index b6386e275c..0000000000 --- a/doc/draft/draft-ietf-dnsext-dhcid-rr-00.txt +++ /dev/null @@ -1,336 +0,0 @@ -Network Working Group A. Gustafsson -Internet-Draft T. Lemon -Expires: January 12, 2001 Nominum, Inc. - M. Stapp - Cisco Systems, Inc. - July 14, 2000 - - - A DNS RR for encoding DHCP information - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 12, 2001. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - A situation can arise where multiple DHCP clients request the same - DNS name from their (possibly distinct) DHCP servers. To resolve - such conflicts, 'Resolution of DNS Name Conflicts'[7] proposes - storing client identifiers in the DNS to unambiguously associate - domain names with the DHCP clients "owning" them. This memo defines - a distinct RR type for use by DHCP servers, the "DHCID" RR. - - - - - - -Gustafsson, et. al. Expires January 12, 2001 [Page 1] - -Internet-Draft A DNS RR for encoding DHCP information July 2000 - - -Table of Contents - - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . . 3 - 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 - References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gustafsson, et. al. Expires January 12, 2001 [Page 2] - -Internet-Draft A DNS RR for encoding DHCP information July 2000 - - -1. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119[1]. - -2. Introduction - - A set of procedures to allow DHCP [RFC2131] clients and servers to - automatically update the DNS (RFC1034[2], RFC1035[3]) is proposed in - Resolution of DNS Name Conflicts[7]. - - A situation can arise where multiple DHCP clients wish to use the - same DNS name. To resolve such conflicts, Resolution of DNS Name - Conflicts[7] proposes storing client identifiers in the DNS to - unambiguously associate domain names with the DHCP clients using - them. In the interest of clarity, it would be preferable for this - DHCP information to use a distinct RR type. - - This memo defines a distinct RR type for this purpose for use by - DHCP clients or servers, the "DHCID" RR. - -3. The DHCID RR - - The DHCP RR is defined with mnemonic DHCID and type code [TBD]. - -4. DHCID RDATA format - - The RDATA section of a DHCID RR in transmission contains RDLENGTH - bytes of binary data. The format of this data and its - interpretation by DHCP servers and clients are described below. - - DNS software should consider the RDATA section to be opaque. In DNS - master files, the RDATA is represented as a hexadecimal string with - an optional "0x" or "0X" prefix. Periods (".") may be inserted - anywhere after the "0x" for readability. This format is identical - to that of the NSAP RR (RFC1706[4]). The number of hexadecimal - digits MUST be even. - - DHCP clients or servers use the DHCID RR to associate a DHCP - client's identity with a DNS name, so that multiple DHCP clients and - servers may safely perform dynamic DNS updates to the same zone. - From the updater's perspective, the DHCID resource record consists - of a 16-bit identifier type, followed by one or more bytes - representing the actual identifier. There are two possible forms - for a DHCID RR - one that is used when the DHCP server is using the - client's link-layer address to identify it, and one that is used - when the DHCP server is using some DHCP option that the DHCP client - sent to identify it. When the link-layer address is used as the - - -Gustafsson, et. al. Expires January 12, 2001 [Page 3] - -Internet-Draft A DNS RR for encoding DHCP information July 2000 - - - identifier, the first two bytes of the RRDATA are set to 0. When a - DHCP option is used as the identifier, the first two bytes of the - RRDATA contain the option number, in network byte order. The two - bytes 0xffff are reserved. In both cases, the remainder of the - RRDATA is the result of performing a one-way hash across the - identifier. - - The details of the method used to generate the data in the RR and - the use to which a DHCP client or server may put this association - are beyond the scope of this draft, and are discussed in the draft - that specifies the DNS update behavior, 'Resolution of DNS Name - Conflicts'[7]. This RR MUST NOT be used for any purpose other than - that detailed in the DHC document. Althought this RR contains data - that is opaque to DNS servers, the data is meaningful to DHCP - updaters. Therefore, new data formats may only be defined through - actions of the DHC Working Group. - -4.1 Example - - A DHCP server allocating the IPv4 address 10.0.0.1 to a client - "client.org.nil" might use the client's link-layer address to - identify the client: - - client.org.nil. A 10.0.0.1 - client.org.nil. DHCID -00.00.18.29.11.17.22.0a.ad.c1.88.10.a3.dd.ff.c8.d9.49 - - A DHCP server allocating the IPv4 address 10.0.12.99 to a client - "chi.org.nil" might use the DHCP client identifier option to - identify the client: - - chi.org.nil. A 10.0.12.99 - chi.org.nil. DHCID 00.61.92.71.22.da.01.88.dd.3a.11.8c.1c.a0.ff.94.9d.81 - -5. Security Considerations - - The DHCID record as such does not introduce any new security - problems into the DNS. In order to avoid exposing private - information about DHCP clients to public scrutiny, a one-way-hash is - used to obscure all client information. - -6. IANA Considerations - - The IANA is requested to allocate an RR type number for the DHCP - record type. - -References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - - -Gustafsson, et. al. Expires January 12, 2001 [Page 4] - -Internet-Draft A DNS RR for encoding DHCP information July 2000 - - - [2] Mockapetris, P., "Domain names - Concepts and Facilities", RFC - 1034, Nov 1987. - - [3] Mockapetris, P., "Domain names - Implementation and - Specification", RFC 1035, Nov 1987. - - [4] Manning, B. and R. Colella, "DNS NSAP Resource Records", RFC - 1706, Oct 1994. - - [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar - 1997. - - [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, Mar 1997. - - [7] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients - (draft-ietf-dhc-dns-resolution-*)", July 2000. - - -Authors' Addresses - - Andreas Gustafsson - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - USA - - EMail: gson@nominum.com - - - Ted Lemon - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - USA - - EMail: mellon@nominum.com - - - Mark Stapp - Cisco Systems, Inc. - 250 Apollo Dr. - Chelmsford, MA 01824 - USA - - Phone: 978.244.8498 - EMail: mjs@cisco.com - - - - -Gustafsson, et. al. Expires January 12, 2001 [Page 5] - -Internet-Draft A DNS RR for encoding DHCP information July 2000 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). 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. - - - - - - - - - - - - - - - - - - - -Gustafsson, et. al. Expires January 12, 2001 [Page 6] - - diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-01.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-01.txt new file mode 100644 index 0000000000..cba30f45d8 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-01.txt @@ -0,0 +1,448 @@ + + +Network Working Group M. Stapp +Internet-Draft Cisco Systems, Inc. +Expires: June 1, 2001 T. Lemon + A. Gustafsson + Nominum, Inc. + December 2000 + + + A DNS RR for Encoding DHCP Information + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other documents + at any time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on June 1, 2001. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + A situation can arise where multiple DHCP clients request the same + DNS name from their (possibly distinct) DHCP servers. To resolve + such conflicts, 'Resolution of DNS Name Conflicts'[5] proposes + storing client identifiers in the DNS to unambiguously associate + domain names with the DHCP clients "owning" them. This memo defines + a distinct RR type for use by DHCP servers, the "DHCID" RR. + + + + + + +Stapp, et. al. Expires June 1, 2001 [Page 1] + +Internet-Draft A DNS RR for Encoding DHCP Information December 2000 + + +Table of Contents + + 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . . 3 + 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 + 7. Appendix A: Base 64 Encoding . . . . . . . . . . . . . . . . . 4 + References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et. al. Expires June 1, 2001 [Page 2] + +Internet-Draft A DNS RR for Encoding DHCP Information December 2000 + + +1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119[1]. + +2. Introduction + + A set of procedures to allow DHCP[2] clients and servers to + automatically update the DNS (RFC1034[3], RFC1035[4]) is proposed in + "Resolution of DNS Name Conflicts"[5]. + + A situation can arise where multiple DHCP clients wish to use the + same DNS name. To resolve such conflicts, Resolution of DNS Name + Conflicts[5] proposes storing client identifiers in the DNS to + unambiguously associate domain names with the DHCP clients using + them. In the interest of clarity, it would be preferable for this + DHCP information to use a distinct RR type. + + This memo defines a distinct RR type for this purpose for use by + DHCP clients or servers, the "DHCID" RR. + +3. The DHCID RR + + The DHCID RR is defined with mnemonic DHCID and type code [TBD]. + +4. DHCID RDATA format + + The RDATA section of a DHCID RR in transmission contains RDLENGTH + bytes of binary data. The format of this data and its + interpretation by DHCP servers and clients are described below. + + DNS software should consider the RDATA section to be opaque. In DNS + master files, the RDATA is represented in base 64 (see Appendix A) + and may be divided up into any number of white space separated + substrings, down to single base 64 digits, which are concatenated to + obtain the full signature. These substrings can span lines using + the standard parenthesis. This format is identical to that used for + representing binary data in DNSSEC (RFC2535[6]). + + DHCP clients or servers use the DHCID RR to associate a DHCP + client's identity with a DNS name, so that multiple DHCP clients and + servers may safely perform dynamic DNS updates to the same zone. + From the updater's perspective, the DHCID resource record consists + of a 16-bit identifier type, followed by one or more bytes + representing the actual identifier. There are two possible forms + for a DHCID RR - one that is used when the DHCP server is using the + client's link-layer address to identify it, and one that is used + when the DHCP server is using some DHCP option that the DHCP client + + +Stapp, et. al. Expires June 1, 2001 [Page 3] + +Internet-Draft A DNS RR for Encoding DHCP Information December 2000 + + + sent to identify it. When the link-layer address is used as the + identifier, the first two bytes of the RRDATA are set to 0. When a + DHCP option is used as the identifier, the first two bytes of the + RRDATA contain the option number, in network byte order. The two + bytes 0xffff are reserved for future extensibility. In both cases, + the remainder of the RRDATA is the result of performing a one-way + hash across the identifier. + + The details of the method used to generate the data in the RR and + the use to which a DHCP client or server may put this association + are beyond the scope of this draft, and are discussed in the + specification of the DNS update behavior, 'Resolution of DNS Name + Conflicts'[5]. This RR MUST NOT be used for any purpose other than + that detailed in the DHC document. Althought this RR contains data + that is opaque to DNS servers, the data is meaningful to DHCP + updaters. Therefore, new data formats may only be defined through + actions of the DHC Working Group. + +4.1 Example + + A DHCP server allocating the IPv4 address 10.0.0.1 to a client + "client.org.nil" might use the client's link-layer address to + identify the client: + + client.org.nil. A 10.0.0.1 + client.org.nil. DHCID AAAY KREX Igqt wYgQ o93/ yNlJ + + A DHCP server allocating the IPv4 address 10.0.12.99 to a client + "chi.org.nil" might use the DHCP client identifier option to + identify the client: + + chi.org.nil. A 10.0.12.99 + chi.org.nil. DHCID AGGS cSLa AYjd OhGM HKD/ lJ2B + +5. Security Considerations + + The DHCID record as such does not introduce any new security + problems into the DNS. In order to avoid exposing private + information about DHCP clients to public scrutiny, a one-way-hash is + used to obscure all client information. + +6. IANA Considerations + + IANA is requested to allocate an RR type number for the DHCID record + type. + +7. Appendix A: Base 64 Encoding + + The following encoding technique is taken from RFC 2045[7] by N. + + +Stapp, et. al. Expires June 1, 2001 [Page 4] + +Internet-Draft A DNS RR for Encoding DHCP Information December 2000 + + + Borenstein and N. Freed. It is reproduced here in an edited form + for convenience. + + A 65-character subset of US-ASCII is used, enabling 6 bits to be + represented per printable character. (The extra 65th character, "=", + is used to signify a special processing function.) + + The encoding process represents 24-bit groups of input bits as + output strings of 4 encoded characters. Proceeding from left to + right, a 24-bit input group is formed by concatenating 3 8-bit input + groups. These 24 bits are then treated as 4 concatenated 6-bit + groups, each of which is translated into a single digit in the base + 64 alphabet. + + Each 6-bit group is used as an index into an array of 64 printable + characters. The character referenced by the index is placed in the + output string. + + The Base 64 Alphabet + + Value Encoding Value Encoding Value Encoding Value Encoding + 0 A 17 R 34 i 51 z + 1 B 18 S 35 j 52 0 + 2 C 19 T 36 k 53 1 + 3 D 20 U 37 l 54 2 + 4 E 21 V 38 m 55 3 + 5 F 22 W 39 n 56 4 + 6 G 23 X 40 o 57 5 + 7 H 24 Y 41 p 58 6 + 8 I 25 Z 42 q 59 7 + 9 J 26 a 43 r 60 8 + 10 K 27 b 44 s 61 9 + 11 L 28 c 45 t 62 + + 12 M 29 d 46 u 63 / + 13 N 30 e 47 v + 14 O 31 f 48 w (pad) = + 15 P 32 g 49 x + 16 Q 33 h 50 y + + + Special processing is performed if fewer than 24 bits are available + at the end of the data being encoded. A full encoding quantum is + always completed at the end of a quantity. When fewer than 24 input + bits are available in an input group, zero bits are added (on the + right) to form an integral number of 6-bit groups. Padding at the + end of the data is performed using the '=' character. Since all + base 64 input is an integral number of octets, only the following + cases can arise: (1) the final quantum of encoding input is an + integral multiple of 24 bits; here, the final unit of encoded output + + +Stapp, et. al. Expires June 1, 2001 [Page 5] + +Internet-Draft A DNS RR for Encoding DHCP Information December 2000 + + + will be an integral multiple of 4 characters with no "=" padding, + (2) the final quantum of encoding input is exactly 8 bits; here, the + final unit of encoded output will be two characters followed by two + "=" padding characters, or (3) the final quantum of encoding input + is exactly 16 bits; here, the final unit of encoded output will be + three characters followed by one "=" padding character. + +References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar + 1997. + + [3] Mockapetris, P., "Domain names - Concepts and Facilities", RFC + 1034, Nov 1987. + + [4] Mockapetris, P., "Domain names - Implementation and + Specification", RFC 1035, Nov 1987. + + [5] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients + (draft-ietf-dhc-dns-resolution-*)", July 2000. + + [6] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + +Authors' Addresses + + Mark Stapp + Cisco Systems, Inc. + 250 Apollo Dr. + Chelmsford, MA 01824 + USA + + Phone: 978.244.8498 + EMail: mjs@cisco.com + + + + + + + + + +Stapp, et. al. Expires June 1, 2001 [Page 6] + +Internet-Draft A DNS RR for Encoding DHCP Information December 2000 + + + Ted Lemon + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + EMail: mellon@nominum.com + + + Andreas Gustafsson + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + EMail: gson@nominum.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et. al. Expires June 1, 2001 [Page 7] + +Internet-Draft A DNS RR for Encoding DHCP Information December 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Stapp, et. al. Expires June 1, 2001 [Page 8] + diff --git a/doc/draft/draft-ietf-ipngwg-default-addr-select-01.txt b/doc/draft/draft-ietf-ipngwg-default-addr-select-01.txt deleted file mode 100644 index 2047267e91..0000000000 --- a/doc/draft/draft-ietf-ipngwg-default-addr-select-01.txt +++ /dev/null @@ -1,695 +0,0 @@ - - -IPng Working Group Richard Draves -Internet Draft Microsoft Research -Document: draft-ietf-ipngwg-default-addr-select-01.txt July 14, 2000 -Category: Standards Track - - Default Address Selection for IPv6 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026 [1]. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Abstract - - This document describes two algorithms, for source address selection - and for destination address selection. The algorithms specify - default behavior for all IPv6 implementations. They do not override - choices made by applications or upper-layer protocols, nor do they - preclude the development of more advanced mechanisms for address - selection. The two algorithms share a common framework, including an - optional mechanism for allowing administrators to provide policy - that can override the default behavior. In dual stack - implementations, the framework allows the destination address - selection algorithm to consider both IPv4 and IPv6 addresses - - depending on the available source addresses, the algorithm might - prefer IPv6 addresses over IPv4 addresses, or vice-versa. - -1. Introduction - - The IPv6 addressing architecture [2] allows multiple unicast - addresses to be assigned to interfaces. These addresses may have - different reachability scopes (link-local, site-local, or global). - These addresses may also be "preferred" or "deprecated" [3]. Privacy - considerations have introduced the concepts of "public addresses" - and "anonymous addresses" [4]. The mobility architecture introduces - "home addresses" and "care-of addresses" [5]. In addition, multi- - homing situations will result in more addresses per node. For - -Draves Standards Track - Expires January 2001 1 -Default Address Selection for IPv6 July 14, 2000 - - - example, a node may have multiple interfaces, some of them tunnels - or virtual interfaces, or a site may have multiple ISP attachments - with a global prefix per ISP. - - The end result is that IPv6 implementations will very often be faced - with multiple possible source and destination addresses when - initiating communication. It is desirable to have simple default - algorithms, common across all implementations, for selecting source - and destination addresses so that developers and administrators can - reason about and predict the behavior of their systems. - - Furthermore, dual or hybrid stack implementations, which support - both IPv6 and IPv4, will very often need to choose between IPv6 and - IPv4 when initiating communication. For example, when DNS name - resolution yields both IPv6 and IPv4 addresses and the network - protocol stack has available both IPv6 and IPv4 source addresses. In - such cases, a simple policy to always prefer IPv6 or always prefer - IPv4 can produce poor behavior. As one example, suppose a DNS name - resolves to a global IPv6 address and a global IPv4 address. If the - node has assigned a global IPv6 address and a 169.254/16 "autonet" - IPv4 address, then IPv6 is the best choice for communication. But if - the node has assigned only a link-local IPv6 address and a global - IPv4 address, then IPv4 is the best choice for communication. The - destination address selection algorithm solves this with a unified - procedure for choosing among both IPv6 and IPv4 addresses. - - This document specifies source address selection and destination - address selection separately, but using a common framework so that - together the two algorithms yield useful results. The algorithms - attempt to choose source and destination addresses of appropriate - scope and configuration status (preferred or deprecated). - Furthermore, this document suggests a preferred method, longest - matching prefix, for choosing among otherwise equivalent addresses - in the absence of better information. - - The framework also has policy hooks to allow administrative override - of the default behavior. For example, using these hooks an - administrator can specify a preferred source prefix for use with a - destination prefix, or prefer destination addresses with one prefix - over addresses with another prefix. These hooks give an - administrator flexibility in dealing with some multi-homing and - transition scenarios, but they are certainly not a panacea. - - The rules specified in this document MUST NOT be construed to - override an application or upper-layer's explicit choice of - destination or source address. - -1.1. Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in - this document are to be interpreted as described in RFC-2119 [6]. - - -Draves Standards Track - Expires May 2000 2 -Default Address Selection for IPv6 July 14, 2000 - - -2. Framework - - Our framework for address selection derives from the most common - implementation architecture, which separates the choice of - destination address from the choice of source address. Consequently, - the framework specifies two separate algorithms for these tasks. The - algorithms are designed to work well together and they share a - mechanism for administrative policy override. - - In this implementation architecture, applications use APIs [7] like - getaddrinfo() and getipnodebyname() that return a list of addresses - to the application. This list might contain both IPv6 and IPv4 - addresses (sometimes represented as IPv4-mapped addresses). The - application then passes a destination address to the network stack - with connect() or sendto(). The application might use only the first - address in the list, or it might loop over the list of addresses to - find a working address. In any case, the network layer is never in a - situation where it needs to choose a destination address from - several alternatives. The application might also specify a source - address with bind(), but often the source address is left - unspecified. Therefore the network layer does often choose a source - address from several alternatives. - - As a consequence, we intend that implementations of getaddrinfo() - and getipnodebyname() will use the destination address selection - algorithm specified here to sort the list of IPv6 and IPv4 addresses - that they return. Separately, the IPv6 network layer will use the - source address selection algorithm when an application or upper- - layer has not specified a source address. Application of this - framework to source address selection in an IPv4 network layer may - be possible but this is not explored further here. - - The algorithms use several criteria in making their decisions. The - combined effect is to prefer destination/source address pairs for - which the two addresses are of equal scope or type, prefer smaller - scopes over larger scopes for the destination address, prefer non- - deprecated source addresses of sufficient scope to reach the - destination, avoid the use of transitional addresses when native - addresses are available, and all else being equal prefer address - pairs having the longest possible common prefix. For source address - selection, an anonymous address [4] is preferred over its - corresponding public address. In mobile situations [5], home - addresses are preferred over care-of addresses. - - The framework optionally allows for the possibility of - administrative configuration of policy that can override the default - behavior of the algorithms. The policy override takes the form of a - configurable table that provides precedence values and preferred - source prefixes for destination prefixes. If an implementation is - not configurable, or if an implementation has not been configured, - then the default policy table specified in this document SHOULD be - used. - - -Draves Standards Track - Expires May 2000 3 -Default Address Selection for IPv6 July 14, 2000 - - -2.1. Scope Comparisons - - Multicast destination addresses have a 4-bit scope field that - controls the propagation of the multicast packet. The IPv6 - addressing architecture defines scope field values for node-local - (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), - and global (0xE) scopes. - - Use of the source address selection algorithm in the presence of - multicast destination addresses requires the comparison of a unicast - address scope with a multicast address scope. We map unicast link- - local to multicast link-local, unicast site-local to multicast site- - local, and unicast global scope to multicast global scope. For - example, unicast site-local is equal to multicast site-local, which - is smaller than multicast organization-local, which is smaller than - unicast global, which is equal to multicast global. - - We write Scope(A) to mean the scope of address A. For example, if A - is a link-local unicast address and B is a site-local multicast - address, then Scope(A) < Scope(B). - - This mapping implicitly conflates unicast site boundaries and - multicast site boundaries. - -2.2. IPv4-Compatible Addresses and Other Format Prefixes - - For the purposes of this document, IPv4-compatible addresses have - global scope and "preferred" configuration status. - - Similarly, NSAP addresses, IPX addresses, or addresses with as-yet- - undefined format prefixes should be treated as having global scope - and "preferred" configuration status. Later standards may supercede - this treatment. - - The loopback address should be treated as having link-local scope - and "preferred" configuration status. - -2.3. IPv4 Addresses and IPv4-Mapped Addresses - - The destination address selection algorithm operates on both IPv6 - and IPv4 addresses. For this purpose, IPv4 addresses should be - represented as IPv4-mapped addresses. For example, to lookup the - precedence or other attributes of an IPv4 address in the policy - table, lookup the corresponding IPv4-mapped IPv6 address. - -2.4. Policy Table - - The policy table is a longest-matching-prefix lookup table, much - like a routing table. Given an address A, a lookup in the policy - table produces three values: a precedence value Precedence(A), a - classification or label Label(A), and a second label - MatchSrcLabel(A). - - -Draves Standards Track - Expires May 2000 4 -Default Address Selection for IPv6 July 14, 2000 - - - The precedence value Precedence(A) is used for sorting destination - addresses. If Precedence(A) > Precedence(B), we say that address A - has higher precedence than address B, meaning that our algorithm - will prefer to sort destination address A before destination address - B. - - The labels Label(A) and MatchSrcLabel(A) allow for policies that - prefer a particular source address prefix for use with a destination - address prefix. The algorithms prefer to use a source address S with - a destination address D if Label(S) = MatchSrcLabel(D). - - IPv6 implementations SHOULD support configurable address selection - via a mechanism at least as powerful as the policy tables defined - here. If an implementation is not configurable or has not been - configured, then it SHOULD operate according to the algorithms - specified here in conjunction with the following default policy - table: - - Prefix Precedence Label MatchSrcLabel - ::1/128 100 1 1 - fe80::/10 90 2 2 - fec0::/10 80 3 3 - ::/0 70 4 4 - 2002::/16 60 5 5 - ::/96 50 6 6 - ::ffff:169.254.0.0/112 30 7 7 - ::ffff:10.0.0.0/104 20 8 8 - ::ffff:172.16.0.0/108 20 9 9 - ::ffff:192.168.0.0/112 20 10 10 - ::ffff:0:0/96 10 11 11 - - One effect of the default policy table is to prefer using native - source addresses with native destination addresses, 6to4 source - addresses with 6to4 destination addresses, and v4-compatible source - addresses with v4-compatible destination addresses. Another effect - of the default policy table is to prefer communication using IPv6 - addresses to communication using IPv4 addresses, if matching source - addresses are available. - - Policy table entries for scoped address prefixes MAY be qualified - with an optional scope-id. If so, a prefix table entry only matches - against an address during a lookup if the scope-id also matches the - address's scope-id. - -2.5. Common Prefix Length - - We define the common prefix length CommonPrefixLen(A, B) of two - addresses A and B as the length of the longest prefix (looking at - the most significant, or leftmost, bits) that the two addresses have - in common. It ranges from 0 to 128. - - - - -Draves Standards Track - Expires May 2000 5 -Default Address Selection for IPv6 July 14, 2000 - - -3. Candidate Source Addresses - - The source address selection algorithm uses the concept of a - "candidate set" of potential source addresses for a given - destination address. We write CandidateSource(A) to denote the - candidate set for the address A. - - It is RECOMMENDED that the candidate source addresses be the set of - unicast addresses assigned to the interface that will be used to - send to the destination. (The "outgoing" interface.) On routers, the - candidate set MAY include unicast addresses assigned to any - interface that could forward the destination address to the outgoing - interface. - - In some cases the destination address may be qualified with a scope- - id or other information that will constrain the candidate set. - - For multicast and link-local destination addresses, the set of - candidate source addresses MUST only include addresses assigned to - interfaces belonging to the same link as the outgoing interface. - - For site-local destination addresses, the set of candidate source - addresses MUST only include addresses assigned to interfaces - belonging to the same site as the outgoing interface. - - In any case, anycast addresses, multicast addresses, and the - unspecified address MUST NOT be included in a candidate set. - -4. Source Address Selection - - The source address selection algorithm chooses a source address for - use with a destination address D. It is specified here in terms of - the pair-wise comparison of addresses SA and SB. The pair-wise - comparison can be used to select an address from the set - CandidateSource(D). - - The pair-wise comparison consists of eight rules, which MUST be - applied in order. If a rule chooses an address, then the remaining - rules are not relevant and MUST be ignored. Subsequent rules act as - tie-breakers for earlier rules. If the eight rules fail to choose an - address, some unspecified tie-breaker must be used. - - Rule 1: Prefer same address. - If SA = D, then choose SA. Similarly, if SB = D, then choose SB. - - Rule 2: Prefer matching label. - If Label(SA) = MatchSrcLabel(D) and Label(SB) <> MatchSrcLabel(D), - then choose SA. Similarly, if Label(SB) = MatchSrcLabel(D) and - Label(SA) <> MatchSrcLabel(D), then choose SB. - - - - - -Draves Standards Track - Expires May 2000 6 -Default Address Selection for IPv6 July 14, 2000 - - - Rule 3: Prefer appropriate scope. - If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then choose SB. - Otherwise, if one of the source addresses is "preferred" and one of - them is "deprecated", then choose the "preferred" address. - Otherwise, choose SA. - Similarly, if Scope(SB) < Scope(SA). If Scope(SB) < Scope(D), then - choose SA. Otherwise, if one of the source addresses is "preferred" - and one of them is "deprecated", then choose the "preferred" - address. Otherwise, choose SB. - - Rule 4: Avoid deprecated addresses. - The addresses SA and SB have the same scope. If one of the source - addresses is "preferred" and one of them is "deprecated", an - implementation MUST choose the one that is preferred. - - Rule 5: Prefer home addresses. - If SA is a home address and SB is a care-of address, then prefer SA. - Similarly, if SB is a home address and SA is a care-of address, then - prefer SB. - An implementation MAY support a per-connection configuration - mechanism (for example, a socket option) to reverse the sense of - this preference and prefer care-of addresses over home addresses. - - Rule 6: Prefer outgoing interface. - If SA is assigned to the interface that will be used to send to D - and SB is assigned to a different interface, then prefer SA. - Similarly, if SB is assigned to the interface that will be used to - send to D and SA is assigned to a different interface, then prefer - SB. - - Rule 7: Prefer anonymous addresses. - If SA is an anonymous address and SB is its corresponding public - address, then prefer SA. Similarly, if SB is an anonymous address - and SA is its corresponding public address, then prefer SB. - An implementation MAY support a per-connection configuration - mechanism (for example, a socket option) to reverse the sense of - this preference and prefer public addresses over anonymous - addresses. - - Rule 8: Use longest matching prefix. - If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA. - Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then - choose SB. - - Rule 8 MAY be superceded if the implementation has other means of - choosing among source addresses. For example, if the implementation - somehow knows which source address will result in the "best" - communications performance. - -5. Destination Address Selection - - The destination address selection algorithm takes a list of - destination addresses and sorts the addresses to produce a new list. - -Draves Standards Track - Expires May 2000 7 -Default Address Selection for IPv6 July 14, 2000 - - - It is specified here in terms of the pair-wise comparison of - addresses DA and DB, where DA appears before DB in the original - list. - - The destination address selection algorithm uses the source address - selection algorithm as a subroutine. We write Source(D) to indicate - the selected source address for a destination D. - - The pair-wise comparison of destination addresses consists of four - rules, which MUST be applied in order. If a rule determines a - result, then the remaining rules are not relevant and MUST be - ignored. Subsequent rules act as tie-breakers for earlier rules. - - Rule 1: Prefer destinations with a matching source. - If Label(Source(DA)) = MatchSrcLabel(DA) and Label(Source(DB)) <> - MatchSrcLabel(DB), then sort DA before DB. Similarly, if - Label(Source(DB)) = MatchSrcLabel(DB) and Label(Source(DA)) <> - MatchSrcLabel(DA), then sort DB before DA. - - Rule 2: Prefer higher precedence. - If Precedence(DA) > Precedence(DB), then sort DA before DB. - Similarly, if Precedence(DB) > Precedence(DA), then sort DB before - DA. - - Rule 3: Use longest matching prefix. - Applies only if Label(Source(DA)) = MatchSrcLabel(DA) and - Label(Source(DB)) = MatchSrcLabel(DB). - If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, - Source(DB)), then sort DA before DB. Similarly, if - CommonPrefixLen(DB, Source(DB)) > CommonPrefixLen(DA, Source(DA)), - then sort DB before DA. - - Rule 4: Otherwise, leave the order unchanged. - Sort DA before DB. - - The third and fourth rules MAY be superceded if the implementation - has other means of sorting destination addresses. For example, if - the implementation somehow knows which destination addresses will - result in the "best" communications performance. - -6. Interactions with Routing - - All IPv6 nodes, including both hosts and routers, SHOULD conform to - this specification. - - This specification of source address selection assumes that routing - (more precisely, selecting an outgoing interface on a node with - multiple interfaces) is done before source address selection. - However, implementations MAY use source address considerations as a - tiebreaker when choosing among otherwise equivalent routes. - - For example, suppose a node has interfaces on two different links, - with both links having a working default router. Both of the - -Draves Standards Track - Expires May 2000 8 -Default Address Selection for IPv6 July 14, 2000 - - - interfaces have preferred global addresses. When sending to a global - destination address, if there's no routing reason to prefer one - interface over the other, then an implementation MAY preferentially - choose the outgoing interface that will allow it to use the source - address that shares a longer common prefix with the destination. - -7. Implementation Considerations - - The destination address selection algorithm needs information about - potential source addresses. One possible implementation strategy is - for getipnodebyname() and getaddrinfo() to call down to the IPv6 - network layer with a list of destination addresses, sort the list in - the network layer with full current knowledge of available source - addresses, and return the sorted list to getipnodebyname() or - getaddrinfo(). This is simple and gives the best results but it - introduces the overhead of another system call. One way to reduce - this overhead is to cache the sorted address list in the resolver, - so that subsequent calls for the same name do not need to resort the - list. - - Another implementation strategy is to call down to the network layer - to retrieve source address information and then sort the list of - addresses directly in the context of getipnodebyname() or - getaddrinfo(). To reduce overhead in this approach, the source - address information can be cached, amortizing the overhead of - retrieving it across multiple calls to getipnodebyname() and - getaddrinfo(). - - In any case, if the implementation uses cached and possibly stale - information in its implementation of destination address selection, - or if the ordering of a cached list of destination addresses is - possibly stale, then it MUST ensure that the destination address - ordering returned to the application is no more than one second out - of date. For example, an implementation might make a system call to - check if any routing table entries or source address assignments - that might affect these algorithms have changed. - -8. Security Considerations - - This document has no direct impact on Internet infrastructure - security. - -References - - 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP - 9, RFC 2026, October 1996. - - 2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", - RFC 2373, July 1998. - - 3 S. Thompson, T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462 , December 1998. - - -Draves Standards Track - Expires May 2000 9 -Default Address Selection for IPv6 July 14, 2000 - - - - 4 T. Narten, R. Draves, "Privacy Extensions for Stateless Address - Autoconfiguration in IPv6", draft-ietf-ipngwg-addrconf-privacy- - 01.txt, July 2000. - - 5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- - mobileip-ipv6-12.txt, April 2000. - - 6 S. Bradner, "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - 7 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket - Interface Extensions for IPv6", RFC 2553, March 1999. - -Acknowledgments - - The author would like to acknowledge the contributions of the IPng - Working Group. - -Author's Address - - Richard Draves - Microsoft Research - One Microsoft Way - Redmond, WA 98052 - Phone: 1-425-936-2268 - Email: richdr@microsoft.com - -Revision History - -Changes from draft-ietf-ipngwg-default-addr-select-00 - - Changed the candidate set definition so that the strong host model - is recommended but not required. Added a rule to source address - selection to prefer addresses assigned to the outgoing interface. - - Simplified the destination address selection algorithm, by having it - use source address selection as a subroutine. - - Added a rule to source address selection to handle anonymous/public - addresses. - - Added a rule to source address selection to handle home/care-of - addresses. - - Changed to allow destination address selection to sort both IPv6 and - IPv4 addresses. Added entries in the default policy table for IPv4- - mapped addresses. - - Changed default precedences, so v4-compatible addresses have lower - precedence than 6to4 addresses. - - - -Draves Standards Track - Expires May 2000 10 -Default Address Selection for IPv6 July 14, 2000 - - -Changes from draft-draves-ipngwg-simple-srcaddr-01 - - Added framework discussion. - - Added algorithm for destination address ordering. - - Added mechanism to allow the specification of administrative policy - that can override the default behavior. - - Added section on routing interactions and TBD section on mobility - interactions. - - Changed the candidate set definition for source address selection, - so that only addresses assigned to the outgoing interface are - allowed. - - Changed the loopback address treatment to link-local scope. - -Changes from draft-draves-ipngwg-simple-srcaddr-00 - - Minor wording changes because DHCPv6 also supports "preferred" and - "deprecated" addresses. - - Specified treatment of other format prefixes; now they are - considered global scope, "preferred" addresses. - - Reiterated that anycast and multicast addresses are not allowed as - source addresses. - - Recommended that source addresses be taken from the outgoing - interface. Required this for multicast destinations. Added analogous - requirements for link-local and site-local destinations. - - Specified treatment of the loopback address. - - Changed the second selection rule so that if both candidate source - addresses have scope greater or equal than the destination address - and only of them is preferred, the preferred address is chosen. - - - - - - - - - - - - - - - - -Draves Standards Track - Expires May 2000 11 -Default Address Selection for IPv6 July 14, 2000 - - - Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Draves Standards Track - Expires May 2000 12 \ No newline at end of file diff --git a/doc/draft/draft-ietf-ipngwg-default-addr-select-02.txt b/doc/draft/draft-ietf-ipngwg-default-addr-select-02.txt new file mode 100644 index 0000000000..02de64b3e4 --- /dev/null +++ b/doc/draft/draft-ietf-ipngwg-default-addr-select-02.txt @@ -0,0 +1,1101 @@ + + +IPng Working Group Richard Draves +Internet Draft Microsoft Research +Document: draft-ietf-ipngwg-default-addr-select-02.txt November 24, 2000 +Category: Standards Track + + Default Address Selection for IPv6 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026 [1]. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other documents + at any time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Abstract + + This document describes two algorithms, for source address selection + and for destination address selection. The algorithms specify + default behavior for all IPv6 implementations. They do not override + choices made by applications or upper-layer protocols, nor do they + preclude the development of more advanced mechanisms for address + selection. The two algorithms share a common framework, including an + optional mechanism for allowing administrators to provide policy + that can override the default behavior. In dual stack + implementations, the framework allows the destination address + selection algorithm to consider both IPv4 and IPv6 addresses - + depending on the available source addresses, the algorithm might + prefer IPv6 addresses over IPv4 addresses, or vice-versa. + + All IPv6 nodes, including both hosts and routers, must implement + default address selection as defined in this specification. + +1. Introduction + + The IPv6 addressing architecture [2] allows multiple unicast + addresses to be assigned to interfaces. These addresses may have + different reachability scopes (link-local, site-local, or global). + These addresses may also be "preferred" or "deprecated" [3]. Privacy + considerations have introduced the concepts of "public addresses" + +Draves Standards Track - Expires June 2001 1 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + and "temporary addresses" [4]. The mobility architecture introduces + "home addresses" and "care-of addresses" [5]. In addition, multi- + homing situations will result in more addresses per node. For + example, a node may have multiple interfaces, some of them tunnels + or virtual interfaces, or a site may have multiple ISP attachments + with a global prefix per ISP. + + The end result is that IPv6 implementations will very often be faced + with multiple possible source and destination addresses when + initiating communication. It is desirable to have default + algorithms, common across all implementations, for selecting source + and destination addresses so that developers and administrators can + reason about and predict the behavior of their systems. + + Furthermore, dual or hybrid stack implementations, which support + both IPv6 and IPv4, will very often need to choose between IPv6 and + IPv4 when initiating communication. For example, when DNS name + resolution yields both IPv6 and IPv4 addresses and the network + protocol stack has available both IPv6 and IPv4 source addresses. In + such cases, a simple policy to always prefer IPv6 or always prefer + IPv4 can produce poor behavior. As one example, suppose a DNS name + resolves to a global IPv6 address and a global IPv4 address. If the + node has assigned a global IPv6 address and a 169.254/16 auto- + configured IPv4 address [6], then IPv6 is the best choice for + communication. But if the node has assigned only a link-local IPv6 + address and a global IPv4 address, then IPv4 is the best choice for + communication. The destination address selection algorithm solves + this with a unified procedure for choosing among both IPv6 and IPv4 + addresses. + + This document specifies source address selection and destination + address selection separately, but using a common framework so that + together the two algorithms yield useful results. The algorithms + attempt to choose source and destination addresses of appropriate + scope and configuration status (preferred or deprecated). + Furthermore, this document suggests a preferred method, longest + matching prefix, for choosing among otherwise equivalent addresses + in the absence of better information. + + The framework also has policy hooks to allow administrative override + of the default behavior. For example, using these hooks an + administrator can specify a preferred source prefix for use with a + destination prefix, or prefer destination addresses with one prefix + over addresses with another prefix. These hooks give an + administrator flexibility in dealing with some multi-homing and + transition scenarios, but they are certainly not a panacea. + + The selection rules specified in this document MUST NOT be construed + to override an application or upper-layer's explicit choice of + destination or source address. + + + + +Draves Standards Track - Expires June 2001 2 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + +1.1. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC 2119 [7]. + +2. Framework + + Our framework for address selection derives from the most common + implementation architecture, which separates the choice of + destination address from the choice of source address. Consequently, + the framework specifies two separate algorithms for these tasks. The + algorithms are designed to work well together and they share a + mechanism for administrative policy override. + + In this implementation architecture, applications use APIs [8] like + getaddrinfo() and getipnodebyname() that return a list of addresses + to the application. This list might contain both IPv6 and IPv4 + addresses (sometimes represented as IPv4-mapped addresses). The + application then passes a destination address to the network stack + with connect() or sendto(). The application might use only the first + address in the list, or it might loop over the list of addresses to + find a working address. In any case, the network layer is never in a + situation where it needs to choose a destination address from + several alternatives. The application might also specify a source + address with bind(), but often the source address is left + unspecified. Therefore the network layer does often choose a source + address from several alternatives. + + As a consequence, we intend that implementations of getaddrinfo() + and getipnodebyname() will use the destination address selection + algorithm specified here to sort the list of IPv6 and IPv4 addresses + that they return. Separately, the IPv6 network layer will use the + source address selection algorithm when an application or upper- + layer has not specified a source address. Application of this + framework to source address selection in an IPv4 network layer may + be possible but this is not explored further here. + + The algorithms use several criteria in making their decisions. The + combined effect is to prefer destination/source address pairs for + which the two addresses are of equal scope or type, prefer smaller + scopes over larger scopes for the destination address, prefer non- + deprecated source addresses, avoid the use of transitional addresses + when native addresses are available, and all else being equal prefer + address pairs having the longest possible common prefix. For source + address selection, temporary addresses [4] are preferred over public + addresses. In mobile situations [5], home addresses are preferred + over care-of addresses. + + The framework optionally allows for the possibility of + administrative configuration of policy that can override the default + behavior of the algorithms. The policy override takes the form of a + configurable table that specifies precedence values and preferred + +Draves Standards Track - Expires June 2001 3 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + source prefixes for destination prefixes. If an implementation is + not configurable, or if an implementation has not been configured, + then the default policy table specified in this document SHOULD be + used. + +2.1. Scope Comparisons + + Multicast destination addresses have a 4-bit scope field that + controls the propagation of the multicast packet. The IPv6 + addressing architecture defines scope field values for node-local + (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), + and global (0xE) scopes [9]. + + Use of the source address selection algorithm in the presence of + multicast destination addresses requires the comparison of a unicast + address scope with a multicast address scope. We map unicast link- + local to multicast link-local, unicast site-local to multicast site- + local, and unicast global scope to multicast global scope. For + example, unicast site-local is equal to multicast site-local, which + is smaller than multicast organization-local, which is smaller than + unicast global, which is equal to multicast global. + + We write Scope(A) to mean the scope of address A. For example, if A + is a link-local unicast address and B is a site-local multicast + address, then Scope(A) < Scope(B). + + This mapping implicitly conflates unicast site boundaries and + multicast site boundaries [9]. + +2.2. IPv4 Addresses and IPv4-Mapped Addresses + + The destination address selection algorithm operates on both IPv6 + and IPv4 addresses. For this purpose, IPv4 addresses should be + represented as IPv4-mapped addresses [2]. For example, to lookup the + precedence or other attributes of an IPv4 address in the policy + table, lookup the corresponding IPv4-mapped IPv6 address. + + IPv4 addresses are assigned scopes as follows. IPv4 auto- + configuration addresses [6], which have the prefix 169.254/16, are + assigned link-local scope. IPv4 private addresses [10], which have + the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site- + local scope. IPv4 loopback addresses [11, section 4.2.2.11], which + have the prefix 127/8, are assigned link-local scope. Other IPv4 + addresses are assigned global scope. + + IPv4 addresses should be treated as having "preferred" configuration + status. + +2.3. IPv6 Addresses with Embedded IPv4 Addresses + + IPv4-compatible addresses [2] and 6to4 addresses [12] contain an + embedded IPv4 address. For the purposes of this document, these + addresses should be treated as having the scope of the embedded IPv4 + +Draves Standards Track - Expires June 2001 4 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + address. For example, the IPv6 address ::169.254.3.18 has link-local + scope and the address 2002:0a01:0203::1 has site-local scope. + + IPv4-compatible addresses should be treated as having "preferred" + configuration status. + +2.4. Loopback Address and Other Format Prefixes + + The loopback address should be treated as having link-local scope + and "preferred" configuration status. + + NSAP addresses, IPX addresses, and other addresses with as-yet- + undefined format prefixes should be treated as having global scope + and "preferred" configuration status. Later standards may supercede + this treatment. + +2.5. Policy Table + + The policy table is a longest-matching-prefix lookup table, much + like a routing table. Given an address A, a lookup in the policy + table produces three values: a precedence value Precedence(A), a + classification or label SrcLabel(A), and a second label DstLabel(A). + + The precedence value Precedence(A) is used for sorting destination + addresses. If Precedence(A) > Precedence(B), we say that address A + has higher precedence than address B, meaning that our algorithm + will prefer to sort destination address A before destination address + B. + + The labels SrcLabel(A) and DstLabel(A) allow for policies that + prefer a particular source address prefix for use with a destination + address prefix. The algorithms prefer to use a source address S with + a destination address D if SrcLabel(S) = DstLabel(D). + + IPv6 implementations SHOULD support configurable address selection + via a mechanism at least as powerful as the policy tables defined + here. If an implementation is not configurable or has not been + configured, then it SHOULD operate according to the algorithms + specified here in conjunction with the following default policy + table: + + Prefix Precedence SrcLabel DstLabel + ::1/128 50 0 0 + ::/0 40 1 1 + 2002::/16 30 2 2 + ::/96 20 3 3 + ::ffff:0:0/96 10 4 4 + + One effect of the default policy table is to prefer using native + source addresses with native destination addresses, 6to4 [12] source + addresses with 6to4 destination addresses, and v4-compatible [2] + source addresses with v4-compatible destination addresses. Another + + +Draves Standards Track - Expires June 2001 5 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + effect of the default policy table is to prefer communication using + IPv6 addresses to communication using IPv4 addresses, if matching + source addresses are available. + + Policy table entries for scoped address prefixes MAY be qualified + with an optional scope-id. If so, a prefix table entry only matches + against an address during a lookup if the scope-id also matches the + address's scope-id. + +2.6. Common Prefix Length + + We define the common prefix length CommonPrefixLen(A, B) of two + addresses A and B as the length of the longest prefix (looking at + the most significant, or leftmost, bits) that the two addresses have + in common. It ranges from 0 to 128. + +3. Candidate Source Addresses + + The source address selection algorithm uses the concept of a + "candidate set" of potential source addresses for a given + destination address. We write CandidateSource(A) to denote the + candidate set for the address A. + + It is RECOMMENDED that the candidate source addresses be the set of + unicast addresses assigned to the interface that will be used to + send to the destination. (The "outgoing" interface.) On routers, the + candidate set MAY include unicast addresses assigned to any + interface that could forward the destination address to the outgoing + interface. + + In some cases the destination address may be qualified with a scope- + id or other information that will constrain the candidate set. + + For multicast and link-local destination addresses, the set of + candidate source addresses MUST only include addresses assigned to + interfaces belonging to the same link as the outgoing interface. + + For site-local destination addresses, the set of candidate source + addresses MUST only include addresses assigned to interfaces + belonging to the same site as the outgoing interface. + + In any case, anycast addresses, multicast addresses, and the + unspecified address MUST NOT be included in a candidate set. + + If an application or upper-layer specifies a source address that is + not in the candidate set for the destination, then the network layer + MUST treat this is an error. If the application or upper-layer + specifies a source address that is in the candidate set for the + destination, then the network layer MUST respect that choice. If the + application or upper-layer does not specify a source address, then + the network layer uses the source address selection algorithm + specified in the next section. + + +Draves Standards Track - Expires June 2001 6 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + +4. Source Address Selection + + The source address selection algorithm chooses a source address for + use with a destination address D. It is specified here in terms of + the pair-wise comparison of addresses SA and SB. The pair-wise + comparison can be used to select an address from the set + CandidateSource(D). + + This source address selection algorithm only applies to IPv6 + destination addresses, not IPv4 addresses. + + The pair-wise comparison consists of eight rules, which should be + applied in order. If a rule chooses an address, then the remaining + rules are not relevant and should be ignored. Subsequent rules act + as tie-breakers for earlier rules. If the eight rules fail to choose + an address, some unspecified tie-breaker should be used. + + Rule 1: Prefer same address. + If SA = D, then choose SA. Similarly, if SB = D, then choose SB. + + Rule 2: Prefer appropriate scope. + If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then choose SB + and otherwise choose SA. + Similarly, if Scope(SB) < Scope(SA). If Scope(SB) < Scope(D), then + choose SA and otherwise choose SB. + + Rule 3: Avoid deprecated addresses. + The addresses SA and SB have the same scope. If one of the source + addresses is "preferred" and one of them is "deprecated", choose the + one that is preferred. + + Rule 4: Prefer home addresses. + If SA is a home address and SB is a care-of address, then prefer SA. + Similarly, if SB is a home address and SA is a care-of address, then + prefer SB. + An implementation may support a per-connection configuration + mechanism (for example, a socket option) to reverse the sense of + this preference and prefer care-of addresses over home addresses. + + Rule 5: Prefer outgoing interface. + If SA is assigned to the interface that will be used to send to D + and SB is assigned to a different interface, then prefer SA. + Similarly, if SB is assigned to the interface that will be used to + send to D and SA is assigned to a different interface, then prefer + SB. + + Rule 6: Prefer matching label. + If Label(SA) = MatchSrcLabel(D) and Label(SB) <> MatchSrcLabel(D), + then choose SA. Similarly, if Label(SB) = MatchSrcLabel(D) and + Label(SA) <> MatchSrcLabel(D), then choose SB. + + + + +Draves Standards Track - Expires June 2001 7 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + Rule 7: Prefer temporary addresses. + If SA is a temporary address and SB is a public address, then prefer + SA. Similarly, if SB is a temporary address and SA is a public + address, then prefer SB. + An implementation may support a per-connection configuration + mechanism (for example, a socket option) to reverse the sense of + this preference and prefer public addresses over temporary + addresses. + + Rule 8: Use longest matching prefix. + If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA. + Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then + choose SB. + + Rule 8 may be superceded if the implementation has other means of + choosing among source addresses. For example, if the implementation + somehow knows which source address will result in the "best" + communications performance. + + Rule 2 (prefer appropriate scope) MUST be implemented and given high + priority because it can affect interoperability. + +5. Destination Address Selection + + The destination address selection algorithm takes a list of + destination addresses and sorts the addresses to produce a new list. + It is specified here in terms of the pair-wise comparison of + addresses DA and DB, where DA appears before DB in the original + list. + + The algorithm sorts together both IPv6 and IPv4 addresses. To find + the attributes of an IPv4 address in the policy table, the IPv4 + address should be represented as an IPv4-mapped address. + + We write Source(D) to indicate the selected source address for a + destination D. For IPv6 addresses, the previous section specifies + the source address selection algorithm. Source address selection for + IPv4 addresses is not specified in this document. + + We say that Source(D) is undefined if there is no source address + available for destination D. For IPv6 addresses, this is only the + case if CandidateSource(D) is the empty set. + + The pair-wise comparison of destination addresses consists of nine + rules, which should be applied in order. If a rule determines a + result, then the remaining rules are not relevant and should be + ignored. Subsequent rules act as tie-breakers for earlier rules. + + Rule 1: Avoid unusable destinations. + If there is no route to DB or if Source(DB) is undefined, then sort + DA before DB. Similarly, if there is no route to DA or if Source(DA) + is undefined, then sort DB before DA. + + +Draves Standards Track - Expires June 2001 8 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + Rule 2: Prefer matching scope. + If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), + then sort DA before DB. Similarly, if Scope(DA) <> Scope(Source(DA)) + and Scope(DB) = Scope(Source(DB)), then sort DB before DA. + + Rule 3: Avoid deprecated addresses. + If Source(DA) is deprecated and Source(DB) is not, then sort DB + before DA. Similarly, if Source(DA) is not deprecated and Source(DB) + is deprecated, then sort DA before DB. + + Rule 4: Prefer home addresses. + If Source(DA) is a home address and Source(DB) is a care-of address, + then sort DA before DB. Similarly, if Source(DA) is a care-of + address and Source(DB) is a home address, then sort DB before DA. + + Rule 5: Prefer matching label. + If SrcLabel(Source(DA)) = DstLabel(DA) and SrcLabel(Source(DB)) <> + DstLabel(DB), then sort DA before DB. Similarly, if + SrcLabel(Source(DA)) <> DstLabel(DA) and SrcLabel(Source(DB)) = + DstLabel(DB), then sort DB before DA. + + Rule 6: Prefer higher precedence. + If Precedence(DA) > Precedence(DB), then sort DA before DB. + Similarly, if Precedence(DA) < Precedence(DB), then sort DB before + DA. + + Rule 7: Prefer smaller scope. + If Scope(DA) < Scope(DB), then sort DA before DB. Similarly, if + Scope(DA) > Scope(DB), then sort DB before DA. + + Rule 8: Use longest matching prefix. + If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, + Source(DB)), then sort DA before DB. Similarly, if + CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), + then sort DB before DA. + + Rule 9: Otherwise, leave the order unchanged. + Sort DA before DB. + + Rules 8 and 9 may be superceded if the implementation has other + means of sorting destination addresses. For example, if the + implementation somehow knows which destination addresses will result + in the "best" communications performance. + +6. Interactions with Routing + + This specification of source address selection assumes that routing + (more precisely, selecting an outgoing interface on a node with + multiple interfaces) is done before source address selection. + However, implementations may use source address considerations as a + tiebreaker when choosing among otherwise equivalent routes. + + + +Draves Standards Track - Expires June 2001 9 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + For example, suppose a node has interfaces on two different links, + with both links having a working default router. Both of the + interfaces have preferred global addresses. When sending to a global + destination address, if there's no routing reason to prefer one + interface over the other, then an implementation may preferentially + choose the outgoing interface that will allow it to use the source + address that shares a longer common prefix with the destination. + + Implementations may also use the choice of router to influence the + choice of source address. For example, suppose a host is on a link + with two routers. One router is advertising a global prefix A and + the other route is advertising global prefix B. Then when sending + via the first router, the host may prefer source addresses with + prefix A and when sending via the second router, prefer source + addresses with prefix B. + +7. Implementation Considerations + + The destination address selection algorithm needs information about + potential source addresses. One possible implementation strategy is + for getipnodebyname() and getaddrinfo() to call down to the IPv6 + network layer with a list of destination addresses, sort the list in + the network layer with full current knowledge of available source + addresses, and return the sorted list to getipnodebyname() or + getaddrinfo(). This is simple and gives the best results but it + introduces the overhead of another system call. One way to reduce + this overhead is to cache the sorted address list in the resolver, + so that subsequent calls for the same name do not need to resort the + list. + + Another implementation strategy is to call down to the network layer + to retrieve source address information and then sort the list of + addresses directly in the context of getipnodebyname() or + getaddrinfo(). To reduce overhead in this approach, the source + address information can be cached, amortizing the overhead of + retrieving it across multiple calls to getipnodebyname() and + getaddrinfo(). In this approach, the implementation may not have + knowledge of the outgoing interface for each destination, so it MAY + use a looser definition of the candidate set during destination + address ordering. + + In any case, if the implementation uses cached and possibly stale + information in its implementation of destination address selection, + or if the ordering of a cached list of destination addresses is + possibly stale, then it should ensure that the destination address + ordering returned to the application is no more than one second out + of date. For example, an implementation might make a system call to + check if any routing table entries or source address assignments + that might affect these algorithms have changed. + + + + + +Draves Standards Track - Expires June 2001 10 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + +8. Security Considerations + + This document has no direct impact on Internet infrastructure + security. + +9. Examples + + This section contains a number of examples, first of default + behavior and then demonstrating the utility of policy table + configuration. + +9.1. Default Source Address Selection + + The source address selection rules, in conjunction with the default + policy table, produce the following behavior: + + Destination: 2001::1 + Sources: 3ffe::1 vs fe80::1 + Result: 3ffe::1 (prefer appropriate scope) + + Destination: 2001::1 + Sources: fe80::1 vs fec0::1 + Result: fec0::1 (prefer appropriate scope) + + Destination: fec0::1 + Sources: fe80::1 vs 2001::1 + Result: 2001::1 (prefer appropriate scope) + + Destination: ff05::1 + Sources: fe80::1 vs fec0::1 vs 2001::1 + Result: fec0::1 (prefer appropriate scope) + + Destination: 2001::1 + Sources: 2001::1 (deprecated) vs 2002::1 + Result: 2001::1 (prefer same address) + + Destination: fec0::1 + Sources: fec0::2 (deprecated) vs 2001::1 + Result: fec0::2 (prefer appropriate scope) + + Destination: 2001::1 + Sources: 2001::2 vs 3ffe::2 + Result: 2001::2 (longest-matching-prefix) + + Destination: 2001::1 + Sources: 2001::2 (care-of address) vs 3ffe::2 (home address) + Result: 3ffe::2 (prefer home address) + + Destination: 2002:836b:2179::1 + Sources: 2002:836b:2179::2 vs 2001::d5e3:7953:13eb:22e8 (temporary) + Result: 2002:836b:2179::2 (prefer matching label) + + + +Draves Standards Track - Expires June 2001 11 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + Destination: 2001::1 + Sources: 2001::2 vs 2001::d5e3:7953:13eb:22e8 (temporary) + Result: 2001::d5e3:7953:13eb:22e8 (prefer temporary address) + +9.2. Default Destination Address Selection + + The destination address selection rules, in conjunction with the + default policy table and the source address selection rules, produce + the following behavior: + + Sources: 2001::2 or fe80::1 or 169.254.13.78 + Destinations: 2001::1 vs 131.107.65.121 + Result: 2001::1 (src 2001::2) then 131.107.65.121 (src + 169.254.13.78) (prefer matching scope) + + Sources: fe80::1 or 131.107.65.117 + Destinations: 2001::1 vs 131.107.65.121 + Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src + fe80::1) (prefer matching scope) + + Sources: 2001::2 or fe80::1 or 10.1.2.4 + Destinations: 2001::1 vs 10.1.2.3 + Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer + higher precedence) + + Sources: 2001::2 or fec0::2 or fe80::2 + Destinations: 2001::1 vs fec0::1 vs fe80::1 + Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then + 2001::1 (src 2001::2) (prefer smaller scope) + + Sources: 2001::2 (care-of address) or 3ffe::1 (home address) or + fec0::2 (care-of address) or fe80::2 (care-of address) + Destinations: 2001::1 vs fec0::1 + Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home + address) + + Sources: 2001::2 or fec0::2 (deprecated) or fe80::2 + Destinations: 2001::1 vs fec0::1 + Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid + deprecated addresses) + + Sources: 2001::2 or 3f44::2 or fe80::2 + Destinations: 2001::1 vs 3ffe::1 + Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest + matching prefix) + + Sources: 2002:836b:4179::2 or fe80::2 + Destinations: 2002:836b:4179::1 vs 2001::1 + Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src + 2002:836b:4179::2) (prefer matching label) + + Sources: 2002:836b:4179::2 or 2001::2 or fe80::2 + Destinations: 2002:836b:4179::1 vs 2001::1 + +Draves Standards Track - Expires June 2001 12 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src + 2002:836b:4179::2) (prefer higher precedence) + +9.3. Configuring Preference for IPv6 vs IPv4 + + The default policy table gives IPv6 addresses higher precedence than + IPv4 addresses. This means that applications will use IPv6 in + preference to IPv4 when the two are equally suitable. An + administrator can change the policy table to prefer IPv4 addresses + by giving the ::ffff:0.0.0.0/96 prefix a higher precedence: + + Prefix Precedence SrcLabel DstLabel + ::1/128 50 0 0 + ::/0 40 1 1 + 2002::/16 30 2 2 + ::/96 20 3 3 + ::ffff:0:0/96 100 4 4 + + This change to the default policy table produces the following + behavior: + + Sources: 2001::2 or fe80::1 or 169.254.13.78 + Destinations: 2001::1 vs 131.107.65.121 + Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src + 169.254.13.78) (prefer matching scope) + + Sources: fe80::1 or 131.107.65.117 + Destinations: 2001::1 vs 131.107.65.121 + Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 + (src fe80::1) (prefer matching scope) + + Sources: 2001::2 or fe80::1 or 10.1.2.4 + Destinations: 2001::1 vs 10.1.2.3 + New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) + (prefer higher precedence) + +9.4. Configuring Preference for Scoped Addresses + + The destination address selection rules give preference to + destinations of smaller scope. For example, a site-local destination + will be sorted before a global scope destination when the two are + otherwise equally suitable. An administrator can change the policy + table to reverse this preference and sort global destinations before + site-local destinations, and site-local destinations before link- + local destinations: + + + + + + + + + +Draves Standards Track - Expires June 2001 13 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + Prefix Precedence SrcLabel DstLabel + ::1/128 50 0 0 + ::/0 40 1 1 + fec0::/10 37 1 1 + fe80::/10 33 1 1 + 2002::/16 30 2 2 + ::/96 20 3 3 + ::ffff:0:0/96 10 4 4 + + This change to the default policy table produces the following + behavior: + + Sources: 2001::2 or fec0::2 or fe80::2 + Destinations: 2001::1 vs fec0::1 vs fe80::1 + New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then + fe80::1 (src fe80::2) (prefer higher precedence) + + Sources: 2001::2 (deprecated) or fec0::2 or fe80::2 + Destinations: 2001::1 vs fec0::1 + Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2) + (avoid deprecated addresses) + +9.5. Configuring a Multi-Homed Site + + Consider a site A that has a business-critical relationship with + another site B. To support their business needs, the two sites have + contracted for service with a special high-performance ISP. This is + in addition to the normal Internet connection that both sites have + with different ISPs. The high-performance ISP is expensive and the + two sites wish to use it only for their business-critical traffic + with each other. + + Each site has two global prefixes, one from the high-performance ISP + and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48 + from the high-performance ISP and prefix 2007:0:aaaa::/48 from its + normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high- + performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All + hosts in both sites register two addresses in the DNS. + + The routing within both sites directs most traffic to the egress to + the normal ISP, but the routing directs traffic sent to the other + site's 2001 prefix to the egress to the high-performance ISP. To + prevent unintended use of their high-performance ISP connection, the + two sites implement ingress filtering to discard traffic entering + from the high-performance ISP that is not from the other site. + + The default policy table and address selection rules produce the + following behavior: + + Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a + Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b + + + +Draves Standards Track - Expires June 2001 14 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b + (src 2001:aaaa:aaaa::a) (longest matching prefix) + + In other words, when a host in site A initiates a connection to a + host in site B, the traffic does not take advantage of their + connections to the high-performance ISP. This is not their desired + behavior. + + Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a + Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c + Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then + 2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) + + In other words, when a host in site A initiates a connection to a + host in some other site C, the reverse traffic may come back through + the high-performance ISP. Again, this is not their desired behavior. + + This situation demonstrates the limitations of the longest-matching- + prefix heuristic in multi-homed situations. + + However, the administrators of sites A and B can achieve their + desired behavior via policy table configuration. For example, they + can use the following policy table: + + Prefix Precedence SrcLabel DstLabel + ::1 50 0 0 + 2001:aaaa:aaaa::/48 45 5 5 + 2001:bbbb:bbbb::/48 45 5 5 + ::/0 40 1 1 + 2002::/16 30 2 2 + ::/96 20 3 3 + ::ffff:0:0/96 10 4 4 + + This policy table produces the following behavior: + + Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a + Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b + New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then + 2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence) + + In other words, when a host in site A initiates a connection to a + host in site B, the traffic uses the high-performance ISP as + desired. + + Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a + Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c + New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then + 2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) + + In other words, when a host in site A initiates a connection to a + host in some other site C, the traffic uses the normal ISP as + desired. + + +Draves Standards Track - Expires June 2001 15 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + +References + + 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + 2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", + RFC 2373, July 1998. + + 3 S. Thompson, T. Narten, "IPv6 Stateless Address Autoconfig- + uration", RFC 2462 , December 1998. + + 4 T. Narten, R. Draves, "Privacy Extensions for Stateless Address + Autoconfiguration in IPv6", draft-ietf-ipngwg-addrconf-privacy- + 01.txt, July 2000. + + 5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- + mobileip-ipv6-12.txt, April 2000. + + 6 R. Troll. "Automatically Choosing an IP Address in an Ad-Hoc IPv4 + Network", draft-ietf-dhc-ipv4-autoconfig-05.txt, March 2000. + + 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + 8 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket + Interface Extensions for IPv6", RFC 2553, March 1999. + + 9 S. Deering, B. Haberman, B. Zill. "IP Version 6 Scoped Address + Architecture", draft-ietf-ipngwg-scoping-arch-01.txt, March 2000. + + 10 Y. Rekhter et. al, "Address Allocation for Private Internets", + RFC 1918, February 1996. + + 11 F. Baker, Editor. "Requirements for IP Version 4 Routers", RFC + 1812, June 1995. + + 12 B. Carpenter, K. Moore. "Connection of IPv6 Domains via IPv4 + Clouds", draft-ietf-ngtrans-6to4-07.txt, September 2000. + +Acknowledgments + + The author would like to acknowledge the contributions of the IPng + Working Group, particularly Steve Deering and Ken Powell. Please let + the author know if you contributed to the development of this draft + and are not mentioned here. + +Author's Address + + Richard Draves + Microsoft Research + One Microsoft Way + Redmond, WA 98052 + + +Draves Standards Track - Expires June 2001 16 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + Phone: 1-425-936-2268 + Email: richdr@microsoft.com + +Revision History + +Changes from draft-ietf-ipngwg-default-addr-select-01 + + Added Examples section, demonstrating default behavior and some + policy table configuration scenarios. + + Removed many uses of MUST. Remaining uses concern the candidate set + of source addresses and the source address selection rule that + prefers source addresses of appropriate scope. + + Simplified the default policy table. Reordered the source address + selection rules to reduce the influence of policy labels. Added more + destination address selection rules. + + Added scoping of v4-compatible and 6to4 addresses based on the + embedded IPv4 address. + + Changed references to anonymous addresses to use the new term, + temporary addresses. + + Clarified that a user-level implementation of destination address + ordering, which does not have knowledge of the outgoing interface + for each destination, may use a looser definition of the candidate + set. + + Clarified that an implementation should prevent an application or + upper-layer from choosing a source address that is not in the + candidate set and not prevent an application or upper-layer from + choosing a source address that is in the candidate set. + + Miscellaneous editorial changes, including adding some missing + references. + +Changes from draft-ietf-ipngwg-default-addr-select-00 + + Changed the candidate set definition so that the strong host model + is recommended but not required. Added a rule to source address + selection to prefer addresses assigned to the outgoing interface. + + Simplified the destination address selection algorithm, by having it + use source address selection as a subroutine. + + Added a rule to source address selection to handle anonymous/public + addresses. + + Added a rule to source address selection to handle home/care-of + addresses. + + + +Draves Standards Track - Expires June 2001 17 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + Changed to allow destination address selection to sort both IPv6 and + IPv4 addresses. Added entries in the default policy table for IPv4- + mapped addresses. + + Changed default precedences, so v4-compatible addresses have lower + precedence than 6to4 addresses. + +Changes from draft-draves-ipngwg-simple-srcaddr-01 + + Added framework discussion. + + Added algorithm for destination address ordering. + + Added mechanism to allow the specification of administrative policy + that can override the default behavior. + + Added section on routing interactions and TBD section on mobility + interactions. + + Changed the candidate set definition for source address selection, + so that only addresses assigned to the outgoing interface are + allowed. + + Changed the loopback address treatment to link-local scope. + +Changes from draft-draves-ipngwg-simple-srcaddr-00 + + Minor wording changes because DHCPv6 also supports "preferred" and + "deprecated" addresses. + + Specified treatment of other format prefixes; now they are + considered global scope, "preferred" addresses. + + Reiterated that anycast and multicast addresses are not allowed as + source addresses. + + Recommended that source addresses be taken from the outgoing + interface. Required this for multicast destinations. Added analogous + requirements for link-local and site-local destinations. + + Specified treatment of the loopback address. + + Changed the second selection rule so that if both candidate source + addresses have scope greater or equal than the destination address + and only of them is preferred, the preferred address is chosen. + + + + + + + + + +Draves Standards Track - Expires June 2001 18 +draft-ietf-ipngwg-default-addr-select-02 November 24, 2000 + + + Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Draves Standards Track - Expires June 2001 19 \ No newline at end of file