INTERNET-DRAFT Alain DURAND Expires 26/08/1999 IMAG Generic Address Mapping draft-durand-ipv6-address-mapping-00.txt This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract: --------- The goal of this proposal is to provide a generic mechanism to perform various kind of IPv6 address resolution. It is designed to work in a serverless environment. Introduction: ------------- This proposal is largely inspired by draft-ietf-ipngwg-linkname-01.txt By Dan Harrington and various discussion with Peter Curran. Within sites, nodes may use different addresses from various scopes. It is sometimes necessary to perform address mapping in between them. A similar problem is to perform address to name and name to address mapping in serverless (no DNS running) environment. The proposed mechanism is inspired by the ARP model of IPv4 and ND of IPv6. It should be noted that this mechanism is voluntarily limited to site local scope and should not be used on the global Internet. Mechanism: ---------- A node willing to perform such a resolution send a multicast query to a (to be defined) site local group. A node in this multicast group whose IP address or name is requested SHOULD send back to the source a unicast packet containing the requested information. Node receiving replies may cache those data for a limited time not exceeding the TTL value. The periodic "advertisement" mechanism of the original proposal has been abandoned. Packet format: -------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Direction | T Y P E | L E N G T H | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S e q u e n c e N u m b e r | T T L | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | D A T A . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version : 1 Direction : 0 : Request 1 : Reply TYPE : 0x01 : Name to Link Local Address 0x02 : Name to Site Local Address 0x03 : Name to Global Address 0x04 : Name to Preferred Scope Address 0x10 : Link Local Address to Name 0x12 : Link Local Address to Site Local Address 0x13 : Link Local Address to Global Address 0x14 : Link Local Address to Preferred Scope Address 0x20 : Site Local Address to Name 0x21 : Site Local Address to Link Local Address 0x23 : Site Local Address to Global Address 0x24 : Site Local Address to Preferred Scope Address 0x30 : Global Address to Name 0x31 : Global Address to Link Local Address 0x32 : Global Address to site Local Address 0x34 : Global Address to Preferred Scope Address 0x40 : Preferred Address to Name 0x41 : Preferred Address to Name 0x42 : Preferred Address to Site Local Address 0x43 : Preferred Address to Global Address LENGTH : packet length in 64 bit words Sequence Number : Random ID. The reply MUST match the query sequence number. TTL : In query packets: MBZ In reply packets: The time the provided information may be cached, in second. 0x0000 means don't cache 0xFFFF means infinity DATA : This field is initialized according to the TYPE field. If the DATA field length in bits is not a multiple of 64, padding with 0 must occurred. Security Consideration: ----------------------- This mechanism is neither more nor less secure than the ICMP one. Limiting the scope of this mechanism to site may somehow lower the risks, However is should be used with caution in high security environment. This mechanism is just a part of a more global picture including plug & play and auto-configuration. Y2K Consideration: ------------------ None Author address: --------------- Alain Durand IMAG BP 53 38041 GRENOBLE CEDEX 9 Tel: +33 4 76 63 57 03 Fax: +33 4 76 51 Mail: Alain.Durand@imag.fr Expires: 26/08/1999