Teklibre

2104 W First Street Apt 2002 FT Myers FL 33901 USA d@taht.net http://www.teklibre.com/

ISC

950 Charter Street Redwood City CA 94063 USA each@isc.org http://www.isc.org/

Dnsmasq

22 St Peters Street Duxford Cambridge CB22 4RP GB +44.07810386191 simon@thekelleys.org.uk http://www.dnsmasq.org/

General Homenet Working Group RFC Request for Comments I-D Internet-Draft XML Pandoc Extensible Markup Language This memo presents a technique for using the hostname acquired from a DHCPv4 client request to publish AAAA records on that domain name for public IPv6 addresses acquired by the same dual-stack host using SLAAC. On dual-stack networks, there is a need to automatically publish entries in the DNS for the public IPv6 addresses of an IPv6 host when it does not use DHCPv6. IPv6 hosts can acquire IPv6 addresses using SLAAC, but there is no mechanism allowing them to register a name in the DNS database other than a DNS update, which would create a very difficult key management problem. By combining the DHCPv4 hostname or client FQDN option with information acquired using ICMPv6, a lightweight DHCPv4 server on a home gateway or SOHO gateway can automatically publish AAAA records for such hosts.

This memo presents a technique for using the hostname acquired for a DHCPv4 client request to publish AAAA records on that domain name for public IPv6 addresses acquired by the same dual-stack host using SLAAC . On dual-stack networks, there is a need to automatically publish entries in the DNS for the public IPv6 addresses of an IPv6 host when it does not use DHCPv6. IPv6 hosts can acquire IPv6 addresses using SLAAC, but there is no mechanism allowing them to register a name in the DNS database other than a DNS update, which creates a very difficult key management problem. By combining the DHCPv4 hostname or client FQDN option, the client MAC address or DHCPPv4 client-ID and information acquired using ICMPv6, a DHCPv4 server on a home gateway or SOHO gateway can automatically publish AAAA records for such hosts using the same route by which it publishes A records.

A DHCPv4 server which supports the hostname or FQDN options can easily determine the tuple (link-layer address, hostname, broadcast domain) for each DHCPv4 client which has completed a DHCPv4 lease. The MAC address or client-id can be used to determine the host-identifier which is likely to be used by the client if it configures itself for IPv6 using SLAAC. If the server has access to the mapping between broadcast domains and IPv6 prefixes, it can construct a list of possible SLAAC-configured IPv6 addresses which the client may be using. If some or all of these addresses can be confirmed as in-use, then the server can infer a connection between the active IPv6 addresses and the hostname, and install that naming information into the DNS using the same mechanisms it uses to public IPv4 naming information.

For each DHCPv4 lease which is in BOUND state and has a known name, the DHCPv4 server attempts to determines the broadcast domain in which the assigned IPv4 address exists and the IPv6 prefix(es) associated with that broadcast domain. If the server has an interface in the broadcast domain, then the server MAY use the configuration of the interface in the form of IPv4 addresses and netmasks, and IPv6 prefixes and prefix lengths to make this determination. The implementation MAY also make it possible to provide this information as part of the server's configuration. This is likely to be a requirement when a DHCPv4 relay agent is in use and the server does not have an interface in the broadcast domain. The server MUST discard any IPv6 prefixes whose length is not 64, since hosts cannot assign addresses in these prefixes using SLAAC. The server MUST discard link-local prefixes. It MAY be configured to discard site-local prefixes. This would be appropriate of the host records were being inserted into the global DNS, but not if they were being inserted into a local DNS view only available within the site. Having determined the set of possible IPv6 prefixes (as above) the implementation then determines a possible interface identifier. It uses the client's link-layer address contained in the CHADDR field of the DHCPv4 packet, or encoded in the client-id as in FIREWIRE and applies the procedure given in para 2.5.1 to calculate the SLAAC interface identifier. The set of prefixes are combined with the interface identifier to generate a set of putative IPv6 addresses for the client. This set of addresses is then tested to determine if the client is actually using them. To do this the server sends an ICMPv6 [](#RFC4443] echo request to each putative address and awaits a reply. To avoid problems with packet loss, the ICMP echo requests MUST be retransmitted and the time between retransmissions MUST be subject to a suitable backoff strategy to avoid flooding the network. When an ICMPv6 echo reply is recieved from a putative address, that address is marked as confirmed, and the (name, IPv6-address) pair SHOULD be installed in the DNS. The server SHOULD cease sending IMCPv6 echo requests to an address once it has been confirmed. It MAY cease sending ICMPv6 echo requests is no answers are recieved after an extended period, or it MAY implement a backoff strategy which reduces the rate to sending echo requests to close to zero after an extended period. One of these options MUST be implemented.

The exact mechanism by which a name is associated with a host, and the name, address pair are installed in the DNS are beyond the scope of this document. It is assumed that the mechanism which is used to determine the name which is stored in the A record is re-used to the AAAA record, and the mechanism by which the A record is inserted into the DNS is re-used for the AAAA record. The lifetime and TTL of the AAAA record should be the same as that for the A record. The same strategy for removing DNS records on the expiry of a DHCPv4 lease is used for AAAA records. The server MUST NOT insert AAAA records into the DNS unless they have been confirmed by the receipt of an ICMPv6 echo reply.

The server MAY store the set of confirmed IPv6 addresses in the persistent lease database so that they are preserved over a server restart. Alternatively, after a server restart, the server MAY repeat the generation and confirmation of the set of putative IPv6 addresses associated with each DHCPv4 lease. The server MUST NOT assume that IPv6 addresses for existing leases are confirmed after a server restart and MUST repeat the confirmation process unless the status of the addresses is stored in the persistent database.

When an new IPv6 prefix is added to a broadcast domain, the server SHOULD add the corresponding IPv6 addresses to the set of putative addressess for each existing DHCPv4 lease which is in BOUND state and attempt to confirm its existence by sending ICMP6 echp requests and listening for replies. When confirmed, the relevant AAAA records should be added the relevant RRset. When an IPv6 prefix is removed or becomes deprecated, the associated AAAA records should be removed from the DNS.

The implementation MAY arrange for unsolicited Router Advertisements to be sent at short intervals, in the same way as after an interface becomes an advertising interface, when a new DHCPv4 lease enters the BOUND state from another state. This increases tha probability that a new host appearing on the network will be assigned an address by SLAAC promptly and be detected by the system.

This technique will only install SLAAC addresses into the DNS. It does not detect privacy addresses. It is unlikely to be useful to insert privacy addresses into the DNS. A host which is required to accept incoming connections should have a SLAAC address. It may make outgoing connections from privacy addresses. IPv6 addresses of Windows nodes (which do not generate IIDs according to traditional SLAAC), and any nodes using CGAs, are also missed. Nodes using stateful DHCPv6 do not need this technique as naming is handled by DHCPv6. This technique makes traditional DNS naming work on IPv6 for existing deployed systems. It works, for instance, with hundreds of millions of existing Android phones and tablets, most SLAAC enabled hosts that supply a hostname with their DHCPv4 requests, and many printers.

This document describes a simple and operational scheme for tying DHCPv4 name requests to SLAAC generated addresses. Privacy addresses remain private. Exposure to the DNS is limited to SLAAC addresses. Automatic DNS registry of these has privacy implications that may be undesirable in some cases; user interfaces should provide appropriate mechanisms for controlling which hosts' addresses are registered in the public DNS, and which are not.

This document has no actions for IANA.

This document outlines a simple method for co-joining the DHCPv4 and SLAAC assigned DNS namespace. It is lightweight, and robust. It has been deployed as part of DNSMASQ since version 2.61, released 29-Apr-2012, and continually improved. Scripts have been available for doing the equivalent with BIND9 and ISC-dhcp since 15-May-2011.

Dnsmasq is configured using simple option=value pairs. For each interface you care about, the "ra-names" option will enable attempts to leverage DHCPv4 information for naming SLAAC-derived addresses.

Use the DHCPv4 lease to derive the name, network segment and MAC address and assume that the host will also have an IPv6 address calculated using the SLAAC alogrithm. dhcp-range=1234::, ra-names

dhcp-range=1234::, ra-stateless, ra-names For more details on configuration see the dnsmasq examples at http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example.

For more details on isc-dhcp configuration see the examples at https://github.com/dtaht/bufferbloat-rfcs/tree/master/dhcpv4_to_slaac/isc-dhcp/

Harvard University

1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu

GeneralkeywordIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their 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. Note that the force of these words is modified by the requirement level of the document in which they are used. This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.</t><t> The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.</t><t> This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. This memo provides information for the Internet community. Computer Science Department

323 Dana EngineeringBucknell UniversityLewisburgPA 17837(717) 524-1145droms@bucknell.edu

InternetDHCPconfigurationdynamic host configuration protocolhostThe Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP) , adding the capability of automatic allocation of reusable network addresses and additional configuration options . DHCP captures the behavior of BOOTP relay agents [7, 21], and DHCP participants can interoperate with BOOTP participants . This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t><t> This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.</t><t> This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus. This memo defines an Experimental Protocol for the Internet community. This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. [STANDARDS-TRACK] This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK] The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). This mechanism is intended for delegating a long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK] This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]