Internet Draft H. Kitamura NEC Corporation S. Ata Osaka City University Expires April 2012 October 24, 2011 Corresponding Auto Names for IPv6 Addresses Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. H. Kitamura Expires April 2012 [Page 1] Internet Draft Corresponding Auto Names for IPv6 Abstract This document discusses notion and actual mechanisms of "Corresponding Auto Names" for IPv6 Addresses. With this mechanism, all IPv6 addresses (even if they are link-local scoped addresses) can obtain their own Names, and it will be able to use Names anywhere instead of IPv6 Addresses. IPv6 address is too long and complicated to remember, and it is very nuisance thing to type a literal IPv6 address manually as an argument of applications. Also, it is very difficult for human beings to tell which IPv6 address is set to which actual IPv6 node. In this sense, literal IPv6 address information can be called meaningless information for human beings. In order to solve above problems and to make the information meaningful, mechanisms called Corresponding Auto Names for IPv6 addresses is introduced. They will become gentle information for human beings. By applying a simple naming rule to the Auto Names (e.g., use the same name-prefix for IPv6 addresses that are set to the same interface (node)), this will contribute to help people to understand which IPv6 address / Name indicates which actual IPv6 node. 1. Introduction This document discusses notion and actual mechanisms of "Corresponding Auto Names" for IPv6 Addresses. IPv6 address is too long and complicated to remember, and it is very nuisance thing to type a literal IPv6 address manually as an argument of applications. Furthermore, it is very normal and popular cases to set multiple IPv6 addresses to one node. One IPv6 node owns more than two IPv6 addresses (typically: one is link-local scoped address. the other is global scoped address) at least. Some IPv6 addresses (such as link-local scoped stateless auto-configuration addresses and temporary addresses) may become users' conscious-less address, because they are automatically set to the IPv6 node. It is too difficult for human beings to tell which IPv6 address is set to which IPv6 node. In other words, when an IPv6 address is shown to a person, he almost can not tell that the shown IPv6 address indicates which IPv6 node. In this sense, literal IPv6 address information can be called useless or meaningless information for human beings. H. Kitamura Expires April 2012 [Page 2] Internet Draft Corresponding Auto Names for IPv6 So, there are strong desires to use Name information (that is gentle for human beings) instead of literal IPv6 Address information and to use meaningful information that can easily show which IPv6 address / name indicates which actual IPv6 node. The Corresponding Auto Names for IPv6 Addresses is introduced to solve above problems and to satisfy the above desires. 2. Goals (What can be achieved) In this section, goals of the mechanisms of the Corresponding Auto Names for IPv6 Addresses and what can be achieved are shown by using examples. 2.1 Assumed typical IPv6 communication environment: Two IPv6 nodes (Node A and Node B) are located on the same link. Their IPv6 Addresses are shown below. Node A: Literal Address ---------------------------------- MAC Address: 00:0d:5e:b8:80:7b ---------------------------------- LL-Address: fe80::20d:5eff:feb8:807b%fxp0 ULA: fd01:2345:6789::20d:5eff:feb8:807b fd01:2345:6789::1234 Global Addr: 2001:DB8::20d:5eff:feb8:807b 2001:DB8::1234 Node B: Literal Address ---------------------------------- MAC Address: 00:0c:76:d9:14:e3 ---------------------------------- LL-Address: fe80::20c:76ff:fed9:14e3%em0 ULA: fd01:2345:6789::20c:76ff:fed9:14e3 fd01:2345:6789::5678 Global Addr: 2001:DB8::20c:76ff:fed9:14e3 2001:DB8::5678 They own altogether 5 IPv6 addresses respectively; 1 Link-Local scoped Address 2 Unique Local Addresses (SLLAC address and manual set address) 2 Global scoped Addresses (SLLAC address and manual set address) They communicate each other. H. Kitamura Expires April 2012 [Page 3] Internet Draft Corresponding Auto Names for IPv6 2.2 Auto Names examples For all addresses, respective Corresponding Auto Names are prepared and registered to a name resolving DB and its service (such as the DNS) automatically by the mechanism that detects these addresses (that is explained after in this document). Prepared Auto Names are shown below. Node A: Literal Address Auto Name ---------------------------------- --------- MAC Address: 00:0d:5e:b8:80:7b ---------------------------------- LL-Address: fe80::20d:5eff:feb8:807b%fxp0 -> n7bz-l1%fxp0 ULA: fd01:2345:6789::20d:5eff:feb8:807b -> n7bz-u1 fd01:2345:6789::1234 -> n7bz-u2 Global Addr: 2001:DB8::20d:5eff:feb8:807b -> n7bz-g1 2001:DB8::1234 -> n7bz-g2 Node B: Literal Address Auto Name ---------------------------------- --------- MAC Address: 00:0c:76:d9:14:e3 ---------------------------------- LL-Address: fe80::20c:76ff:fed9:14e3%em0 -> n3ez-l1%em0 ULA: fd01:2345:6789::20c:76ff:fed9:14e3 -> n3ez-u1 fd01:2345:6789::5678 -> n3ez-u2 Global Addr: 2001:DB8::20c:76ff:fed9:14e3 -> n3ez-g1 2001:DB8::5678 -> n3ez-g2 2.3 Auto Name Prefix for Grouped Addresses In order to make Auto Names meaningful, IPv6 addresses are grouped and Auto Name Prefix is used to show grouped addresses. For IPv6 addresses that are set to the same interface (node), the same Auto Name-Prefix that stands for the Group ID is used for their Auto Names. As shown above: 'n7bz-' is used for Auto Name Prefix (Group ID) for Node A and 'n3ez-' is used for Auto Name Prefix (Group ID) for Node B. In order to make easier to identify and remember the Auto Name Prefixes, their naming rule is based on inheriting the last octet of the node's MAC address in this example. H. Kitamura Expires April 2012 [Page 4] Internet Draft Corresponding Auto Names for IPv6 2.4 Contribution in Regular Resolving (Name -> Address) In order to communicate with the specific IPv6 address of the destination node, the following procedure to type literal IPv6 address is required in the current environment. They are very stressful and nuisance procedures for human beings. When 'ping6' or 'telnet' to the specific IPv6 address of Node B from Node A is executed, the following commands are typed. >ping6 fe80::20c:76ff:fed9:14e3%fxp0 >telnet fd01:2345:6789::20c:76ff:fed9:14e3 Especially for link-local scoped addresses or temporary addresses, there are no way to type Names instead of literal IPv6 addresses, because they are generally not registered to name resolving services. By introducing the Corresponding Auto Names, above typed commands are changed and replaced with the following easy and rememberalbe name typing procedures. >ping6 n3ez-l1%fxp0 >telnet n3ez-u1 2.5 Contribution in Reverse Resolving (Address -> Name) Communication related status information is shown to human beings in literal IPv6 address format in the current environment. 'netstat -a' (on Node A) shows connection status as followed: Local Address Foreign Address (state) fe80::20d:5eff:feb8:807b.8722 fe80:3::20c:76ff:fed9:14e3.23 ESTABLISH fd01:2345:6789::1234.16258 fd01:2345:6789::5678.23 TIME_WAIT H. Kitamura Expires April 2012 [Page 5] Internet Draft Corresponding Auto Names for IPv6 'ndp -a' (on Node A) shows neighbor cache status as followed: Neighbor Linklayer Addr. Netif Expire S fe80::20d:5eff:feb8:807b%fxp0 0:0d:5e:b8:80:7b fxp0 permanent R fd01:2345:6789::20d:5eff:feb8:807b 0:0d:5e:b8:80:7b fxp0 permanent R fd01:2345:6789::1234 0:0d:5e:b8:80:7b fxp0 permanent R 2001:DB8::20d:5eff:feb8:807b 0:0d:5e:b8:80:7b fxp0 permanent R 2001:DB8::1234 0:0d:5e:b8:80:7b fxp0 permanent R fe80::221:85ff:fea7:82ff%fxp0 0:21:85:a7:82:ff fxp0 23h50m51s S fe80::20c:76ff:fed9:14e3%fxp0 0:0c:76:d9:14:e3 fxp0 23h51m56s S fd01:2345:6789::20c:76ff:fed9:14e3 0:0c:76:d9:14:e3 fxp0 23h52m50s S fd01:2345:6789::5678 0:0c:76:d9:14:e3 fxp0 23h53m51s S 2001:DB8::20c:76ff:fed9:14e3 0:0c:76:d9:14:e3 fxp0 23h54m53s S 2001:DB8::5678 0:0c:76:d9:14:e3 fxp0 23h55m54s S People almost can not tell which shown literal IPv6 address indicates which IPv6 node. In this sense, shown information is meaningless and useless. By introducing the Corresponding Auto Names, above complicated information is converted into simple and meaningful information and shown as followed. 'netstat -a' (on Node A) shows connection status as followed: Local Address Foreign Address (state) n7bz-l1.8722 ne3z-l1.23 ESTABLISH n7bz-u1.16258 ne3z-u1..23 TIME_WAIT 'ndp -a' (on Node A) shows neighbor cache status as followed: Neighbor Linklayer Addr. Netif Expire S n7bz-l1%fxp0 0:0d:5e:b8:80:7b fxp0 permanent R n7bz-u1 0:0d:5e:b8:80:7b fxp0 permanent R n7bz-u2 0:0d:5e:b8:80:7b fxp0 permanent R n7bz-g1 0:0d:5e:b8:80:7b fxp0 permanent R n7bz-g2 0:0d:5e:b8:80:7b fxp0 permanent R nffz-l1%fxp0 0:21:85:a7:82:ff fxp0 23h50m51s S n3ez-l1%fxp0 0:0c:76:d9:14:e3 fxp0 23h51m56s S n3ez-l1 0:0c:76:d9:14:e3 fxp0 23h52m50s S n3ez-l2 0:0c:76:d9:14:e3 fxp0 23h53m51s S n3ez-g1 0:0c:76:d9:14:e3 fxp0 23h54m53s S n3ez-g2 0:0c:76:d9:14:e3 fxp0 23h55m54s S H. Kitamura Expires April 2012 [Page 6] Internet Draft Corresponding Auto Names for IPv6 Other examples where the Auto Name technique can contributes: In log files of a server application, accesses from clients are recoded into them in literal IPv6 address format. It is almost impossible to read and understand the log files effectively without this Auto Name technique. Also, in packet dumping applications, address information is shown in literal IPv6 address format. This Auto Name technique can significantly help for human beings to analyze and understand dumped packets. Shown communication related status information in Auto Name format is simple and easy enough for human beings to understand. As shown above, troublesome IPv6 literal Address information can be converted into meaningful information by using the Corresponding Auto Names technique, and we can achieve our goals. 3 Deployed Notions and Functions that are used in Auto Names 3.1. Stateless Name We know that we can categorize Addresses into two types. One is "stateful" address type, and the other is 'stateless' address type. On the other, we have not been applied the same categorization to domain Names or host Names clearly. It has been assumed that existing all Names are categorized into stateful type and there is no stateless name type. Authors think that it is a time to change this preconception. We can grasp that the introduced Corresponding Auto Name is realization of "stateless" name type, and we have deployed a notion Stateless Name clearly here. 3.2 Scoped Name We also know that a notion called "scope" (such as link-local scope, global-scope) is introduced when we deal with addresses. Every address has its own scope. In domain Names or host Names cases, the "scope" notion have not clearly introduced. It is assumed that all names are global information and "scope" notion does not exist. The Corresponding Auto Name is achieved by introducing Scoped Name obviously. H. Kitamura Expires April 2012 [Page 7] Internet Draft Corresponding Auto Names for IPv6 Scope of Auto Name for IPv6 address is the same to the scope of its IPv6 address. For example, scope of the Auto Name for the link- local IPv6 address is link-local. They are only effective within the link-local scope. 3.3 Target IPv6 Addresses One of the goals of the Auto Name technique is to provide and set Names to all IPv6 addresses. If an address has its own name and it is registered into name resolving services (such as the DNS) already, it is basically not necessary to provide Auto Name to such addresses. We can assume that IPv6 addresses whose names are registered into the name resolving services are well managed. So, they will not become targets of the Auto Name technique. However, we can provide Auto Names to such addresses, because one-to-multiple mapping is allowed in name resolving services. 4. Design of Auto Names 4.1 Conceptual Design on Naming Rules Auto Names are composed of "-

" format: : stands for Node (Interface) Group ID 4 characters (starting from 'n') (e.g., 'n7bz', 'n3ez')

: stands for Prefix of Address 1 character: (e.g., 'l', 'u', 'g') : stands for Interface ID of Address 1 character: (e.g., '1', '2') Above discussed Auto Name examples satisfy -

format. on Node A: n7bz-l1, n7bz-u1, n7bz-u2, n7bz-g1, n7bz-g2 on Node B: n3ez-l1, n3ez-u1, n3ez-u2, n3ez-g1, n3ez-g2 H. Kitamura Expires April 2012 [Page 8] Internet Draft Corresponding Auto Names for IPv6 4.1.1 Value: value is also called Auto Name-Prefix. In order to make IPv6 addresses meaningful, IPv6 addresses are grouped. It is very natural to group IPv6 addresses by which node (interface) they are set. So, IPv6 addresses that are set to the same node (interface) are grouped into the same group. value is shown as 'nXYZ' format: 'n' : (1st char) fixed and not changed 'XY': (2nd, 3rd chars) are inherited from the last octet (2 charters) of the node's MAC address 'Z' : (4th char) suffix char to avoid a collision of 'XY' starting from "z" if 'XY' is collided, 'Z' is changed into "y", "x" ,,, By using the birthday paradox theorem, collision probability of 256 states (1 octet) is calculated. If there are 19 nodes (interfaces), collision is happened with 50% probability. Collision check procedure of the last octet of MAC addresses is necessary. 4.1.2

Value:

value stands for Prefix (Scope) of Address as 1 character format. Auto Names of IPv6 addresses whose prefixes are same use the same

value. Typically, following characters are used: "l": used for link-local scoped addresses. "u": used for ULA "g": used for global scoped address If multiple prefixes for the same scope are used, other character (such as "h", "i",,,) can be used depending on the circumstances. 4.1.3 Value: value stands for Interface ID of Address as 1 character format. value is starting from "1". If multiple IPv6 addresses whose and

values are same are found, other value (such as "2", "3",,,) is used. H. Kitamura Expires April 2012 [Page 9] Internet Draft Corresponding Auto Names for IPv6 4.2 IPv6 Address Appearance Detection and Auto Name Registration In order to generate and register Auto Names automatically, two types of mechanisms are needed. One is a mechanism that detects IPv6 address appearance. The other is a mechanism that checks the detected addresses and generates Auto Names and registers them to name service. Two functions ("Detector" and "Registrar") are introduced. Detector" function takes in charge of the former mechanism, and "Registrar" takes in charge the latter mechanism. 4.2.1 IPv6 Address Appearance Detection mechanism In order to detect newly appeared IPv6 address, DAD message (NS for DAD) is effectively used. DAD message has the following good capabilities: - issued only when node would like to set new IPv6 address - issued for All types (link-local, global, temporary,,,) - L2 broadcast and easy to capture (without using mirror port) - distinguishable from other NS messages, because source address of the message is unspecified ("::") and different from others - Captured DAD message includes all necessary information (such as, IPv6 address and MAC address) Detector captures DAD messages and detects newly appeared IPv6 addresses. Detected information is sent to Registrar. 4.2.2 Auto Names Generation and Registration mechanism At first, Registrar checks the Detected address information that is sent from Detector(s). By using the reverse resolving (Address -> Name), it is checked whether the Detected address information is first appearance or not. If an entry for the address does NOT exist, it is confirmed that the address is first appearance and it should be registered to the name server. After Name for the address is prepared, duplication of the Name can be checked by using the regular resolving (Name -> Address). If an entry for the Name exist, it is confirmed that Name is duplicated (collided). Another Name is prepared and checked again until the Name is not duplicated. H. Kitamura Expires April 2012 [Page 10] Internet Draft Corresponding Auto Names for IPv6 Finally, Registrar registers both Regular and Reverse resolving entries for the address and prepared Auto Name are registered to the name server. 4.2.3 Placement of Detector and Registrar Placement of Detector and Registrar is designed to make the mecha- nisms flexible and to make it to be applied to various environments (office networks, home networks, etc.) Figure 1 and 2 show typical examples that indicate locations where Detector and Registrar functions are placed on the IPv6 network. Figure 1 shows a case for a single link, and Figure 2 shows a case for multiple links. | +------------+ | | Name Server| +-+-+ %%%%%%%%%%%% ############# +------+-----+ | R | % Detector % # Registrar # / +-+-+ %%%%%%%%%%%% ############# +---+ | | | / ----+---------+-------+------+---------------+----- | +===========+ | IPv6 Node | +===========+ Fig. 1 Single-Link Case Example +------------+ | Name Server| ############# +------+-----+ # Registrar # / ############# +---+ | / ----+-----------+------------+-------+------ | | +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%% | R1| % Detector1 % | R2| % Detector2 % +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%% | | | | ----+-----+-----+----- ----+-----+-----+----- | | +===========+ +===========+ | IPv6 Node | | IPv6 Node | +===========+ +===========+ Fig. 2 Multiple-Link Case Example H. Kitamura Expires April 2012 [Page 11] Internet Draft Corresponding Auto Names for IPv6 4.2.4 Detection and Registration Procedures Figure 3 shows an example of typical detection and registration pro- cedures at IPv6 links where DAD packets are issued. DAD message pack- ets are used for the appearance detection. IPv6 Node Router Detector Registrar Name Server | link local | | | | (a)|---DAD NS--->--------->| | | (b)| no NA | |(detect) | | (c)| | |=========>| | (d)| | | |----------->|(Reverse Check) (e)| | | |<-----------| | | | | | (f)| | | |----------->|(Regular Check) (g)| | | |<-----------| | | | | | (h)| | | |===========>|(Reg. Register) (i)| | | |<-----------| (j)| | | |===========>|(Rev. Register) (k)| | | |<-----------| | global | | | | (l)|(----RS--->)| | | | (m)|<----RA-----| | | | (n)|---DAD NS--->--------->| | | (o)| no NA | |(detect) | | (p)| | |=========>| | | | | | | (q)| | | |----------->|(Reverse Check) (r)| | | |<-----------| | | | | | (s)| | | |----------->|(Regular Check) (t)| | | |<-----------| | | | | | (u)| | | |===========>|(Reg. Register) (v)| | | |<-----------| (w)| | | |===========>|(Rev. Register) (x)| | | |<-----------| | | | | | H. Kitamura Expires April 2012 [Page 12] Internet Draft Corresponding Auto Names for IPv6 5. Security Considerations Auto Names are generated and registered to the name service in this document. In order to register correct Auto Names information, commu- nication between Detector and Registrar and communication between Registrar and Name Server should be protected and be secured. In general usage, scope of Auto Names will be local (not global). Auto Names are usually local scoped names. So, we do not have to be too sensitive on the correctness of Auto Names. 6. IANA Considerations This document does not require any resource assignments to IANA. References Normative References [RFC4291] R. Hinden and S. Deering, "IP Version 6 Addressing Archi- tecture", RFC 4291, February 2006 [RFC4861] T. Narten, E. Nordmark, W. Simpson and H. Soliman, "Neigh- bor Discovery for IP Version 6 (IPv6)," RFC 4861, Septem- ber 2007 [RFC4862] S. Thomson, T. Narten and T. Jinmei "IPv6 Stateless Address Autoconfiguration," RFC4862, September 2007 [RFC4941] T. Narten, R. Draves and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6," RFC4941, September 2007 [RFC1034] P. Mockapetris, "Domain names - concepts and facilities ", RFC 1034, November 1987 [RFC1035] P. Mockapetris, "Domain names - implementation and specifi- cation", RFC 1035, November 1987 [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic Updates in the Domain Name System," RFC 2136, April 1997 [RFC4795] B. Aboba, D. Thaler, and L. Esibov, "Link-Local Multicast Name Resolution (LLMNR)," RFC4795, January 2007 Informative References H. Kitamura Expires April 2012 [Page 13] Internet Draft Corresponding Auto Names for IPv6 [RFC4620] M. Crawford and B. Haberman, "IPv6 Node Information Queries," RFC4620, August 2006 [mDNS] S. Cheshire and M. Krochmal, "Multicast DNS" work in progress, February 2011 [RFC3849] G. Huston, A. Lord and P. Smith, "IPv6 Address Prefix Reserved for Documentation," RFC3849, July 2004 Authors' Addresses Hiroshi Kitamura Service Platform Research Laboratories, NEC Corporation (SC building 12F)1753, Shimonumabe, Nakahara-Ku, Kawasaki, Kanagawa 211-8666, JAPAN Graduate School of Information Systems, University of Electro-Communications 5-1 Chofugaoka 1-Chome, Chofu-shi, Tokyo 182-8585, JAPAN Phone: +81 44 431 7686 Fax: +81 44 431 7680 Email: kitamura@da.jp.nec.com Shingo Ata Graduate School of Engineering, Osaka City University 3-3-138, Sugimoto, Sumiyoshi-Ku, Osaka 558-8585, JAPAN Phone: +81 6 6605 2191 Fax: +81 6 6605 2191 Email: ata@info.eng.osaka-cu.ac.jp H. Kitamura Expires April 2012 [Page 14]