Internet DRAFT - draft-kitamura-ipv6-auto-name
draft-kitamura-ipv6-auto-name
Network Working Group H. Kitamura
Internet-Draft NEC Corporation
Intended status: Informational S. Ata
Expires: April 2013 Osaka City University
October 16, 2012
Corresponding Auto Names for IPv6 Addresses
<draft-kitamura-ipv6-auto-name-03.txt>
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 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 provide annotated
meaningful information to IPv6 addresses, mechanisms called
Corresponding Auto Names for IPv6 addresses is introduced. They
will become human friendly information. By applying a simple naming
rule to the Auto Names (e.g., use the same Auto Name Suffix 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 and provide meaningful
information.
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."
H. Kitamura Expires April 2013 [Page 1]
Internet Draft Auto Names for IPv6 Addresses
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 2013.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Goals (What can be achieved) . . . . . . . . . . . . . . . . . 4
2.1. Assumed typical IPv6 communication environment: . . . . . . 4
2.2. Auto Names examples . . . . . . . . . . . . . . . . . . . . 4
2.3. Auto Name Suffix for Grouped Addresses . . . . . . . . . . . 5
2.4. Contribution in Regular Resolving (Name -> Address) . . . . 6
2.5. Contribution in Reverse Resolving (Address -> Name) . . . . 6
3. Deployed Notions and Functions that are used in Auto Names . . 8
3.1. Stateless Name . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Scoped Name . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Target IPv6 Addresses . . . . . . . . . . . . . . . . . . . 10
4. Design of Auto Names . . . . . . . . . . . . . . . . . . . . . 11
4.1. Conceptual Design on Naming Rules . . . . . . . . . . . . . 11
4.1.1. <P> Value: . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. <I> Value: . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. <NGI> Value: . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Address Type Distinction . . . . . . . . . . . . . . . . . . 13
4.2.1. EUI64-based Address Identification . . . . . . . . . . . 13
4.2.2. "Zero Contain Rate" and Manual or Automatic Distinction . 13
5. Name Services . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15
H. Kitamura Expires April 2013 [Page 2]
Internet Draft Auto Names for IPv6 Addresses
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
A. IPv6 Address Appearance Detection and Auto Name Registration . 16
A.1. IPv6 Address Appearance Detection mechanism . . . . . . . . 16
A.2. Auto Names Generation and Registration mechanism . . . . . 16
A.3. Placement of Detector and Registrar . . . . . . . . . . . . 17
A.4. Detection and Registration Procedures . . . . . . . . . . . 18
Appendix B. Implementation . . . . . . . . . . . . . . . . . . . . 19
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses .. . . . . . . . . . . . . . . . . . . . . . . 20
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. For human
being, values of EUI64-based or temporary addresses should be felt
that they are random number series. So, it is very nuisance 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.
Moreover, when more than two literal IPv6 addresses are shown to
human beings, it is almost impossible to distinguish them whether
they are same or not at a glance.
So, there are strong desires to use Name information (that is human
friendly) instead of literal IPv6 Address information and to use
meaningful and distinguishable 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.
H. Kitamura Expires April 2013 [Page 3]
Internet Draft Auto Names for IPv6 Addresses
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;
One Link-Local scoped Address
Two Unique Local Addresses (SLLAC and manual set address)
Two Global scoped Addresses (SLLAC and manual set address)
They communicate each other.
2.2. Auto Names examples
For all addresses, respective Corresponding Auto Names are prepared
and registered to a some name resolving service DB (typically the
DNS is used for this) automatically by the mechanism that detects
these addresses (that is explained after in this document).
Prepared Auto Names are shown below.
H. Kitamura Expires April 2013 [Page 4]
Internet Draft Auto Names for IPv6 Addresses
Node A: Literal Address Auto Name
---------------------------------- ---------
MAC Address: 00:0d:5e:b8:80:7b
----------------------------------
LL-Address: fe80::20d:5eff:feb8:807b%fxp0 -> L0-7bz%fxp0
ULA: fd01:2345:6789::20d:5eff:feb8:807b -> U0-7bz
fd01:2345:6789::1234 -> U1-7bz
Global Addr: 2001:DB8::20d:5eff:feb8:807b -> G0-7bz
2001:DB8::1234 -> G1-7bz
Node B: Literal Address Auto Name
---------------------------------- ---------
MAC Address: 00:0c:76:d9:14:e3
----------------------------------
LL-Address: fe80::20c:76ff:fed9:14e3%em0 -> L0-3ez%em0
ULA: fd01:2345:6789::20c:76ff:fed9:14e3 -> U0-3ez
fd01:2345:6789::5678 -> U1-3ez
Global Addr: 2001:DB8::20c:76ff:fed9:14e3 -> G0-3ez
2001:DB8::5678 -> G1-3ez
2.3. Auto Name Suffix for Grouped Addresses
In order to make Auto Names meaningful, IPv6 addresses are grouped
and Auto Name Suffix is used to show grouped addresses.
For IPv6 addresses that are set to the same interface (node), the
same Auto Name Suffix that stands for the Group ID is used for
their Auto Names.
As shown above:
'-7bz' is used for Auto Name Suffix (Group ID) for Node A.
'-3ez' is used for Auto Name Suffix (Group ID) for Node B.
In order to make easier to identify and remember the Auto Name
Suffixes, their naming rule is based on inheriting the last octet
of the node's MAC address in this example.
H. Kitamura Expires April 2013 [Page 5]
Internet Draft Auto Names for IPv6 Addresses
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 L0-3ez%fxp0
>telnet U0-3ez
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 2013 [Page 6]
Internet Draft Auto Names for IPv6 Addresses
'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)
L0-7bz.8722 L0-e3z.23 ESTABLISH
U0-7bz.16258 U0-e3z.23 TIME_WAIT
'ndp -a' (on Node A) shows neighbor cache status as followed:
Neighbor Linklayer Addr. Netif Expire S
L0-7bz%fxp0 0:0d:5e:b8:80:7b fxp0 permanent R
U0-7bz 0:0d:5e:b8:80:7b fxp0 permanent R
U1-7bz 0:0d:5e:b8:80:7b fxp0 permanent R
G0-7bz 0:0d:5e:b8:80:7b fxp0 permanent R
G1-7bz 0:0d:5e:b8:80:7b fxp0 permanent R
L0-ffz%fxp0 0:21:85:a7:82:ff fxp0 23h50m51s S
L0-3ez%fxp0 0:0c:76:d9:14:e3 fxp0 23h51m56s S
U0-3ez 0:0c:76:d9:14:e3 fxp0 23h52m50s S
U1-3ez 0:0c:76:d9:14:e3 fxp0 23h53m51s S
G0-3ez 0:0c:76:d9:14:e3 fxp0 23h54m53s S
G1-3ez 0:0c:76:d9:14:e3 fxp0 23h55m54s S
H. Kitamura Expires April 2013 [Page 7]
Internet Draft Auto Names for IPv6 Addresses
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 and distinguishable 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.
Table 1 Stateless Name
+-------+---------------------+--------------------+
| | Stateful | Stateless |
+=======+=====================+====================+
|Address| DHCPv6 | SLAAC |
+-------+---------------------+--------------------+
| Nmae |existing Domain Names| Auto Names |
+-------+---------------------+--------------------+
H. Kitamura Expires April 2013 [Page 8]
Internet Draft Auto Names for IPv6 Addresses
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 now. It is generally assumed that all names are
global information and "scope" notion does not exist.
The Corresponding Auto Name is achieved by introducing Scoped Name
obviously.
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.
Table 1 Scoped Name
+-------+-------------+-------------------+----------+----------+
| | Global | Site-Local(ULA) |Link-Local|Node-Local|
+=======+=============+===================+==========+==========+
|Address|2001:db8::/64|fd01:2345:6789::/64|fe80::/64 | |
+-------+-------------+-------------------+----------+----------+
| Nmae |Domain Names | Domain Names | | |
| | | / Auto Names |Auto Names|Auto Names|
+-------+-------------+-------------------+----------+----------+
At some special situation (that it is enough that Auto Name
information is shared within a node), Node-Local scoped Auto Name
is possible. At such a situation, we can use /etc/hosts file as a
name service.
Deployment of Scoped Name:
Scoped Name notion can be easily achieved with current
technologies.
As shown above, at a special case when we adopt /etc/hosts file as
a name service for Auto Names, scope of Auto Names naturally
becomes Node-Local.
At general cases when we adopt the DNS as a name service for Auto
Names, scope of Auto Names is easily managed by the DNS query
access permission control on DNS servers.
H. Kitamura Expires April 2013 [Page 9]
Internet Draft Auto Names for IPv6 Addresses
3.3. Target IPv6 Addresses
One of the goals of the Auto Name technique is to provide and set
Names to all IPv6 addresses (include Link-local addresses).
All IPv6 Addresses are targets of Auto Names.
Some IPv6 Addresses have their own names (let's call them Proper
Names) that are assigned manually and are registered into name
resolving services (such as the DNS). It may be thought that it is
not necessary to assign Auto Name to such IPv6 addresses which have
Proper Names. However, we strongly recommend assigning Auto Names
to them, too.
In order to provide meaningful information to IPv6 addresses,
uniformed Name information for all IPv6 addresses is necessary.
This is very natural behavior for 'Stateless' type technology.
Since one-to-multiple mapping is allowed in name resolving
services, it will not cause problems to assign both Proper Name and
Auto Name for one IPv6 address.
We may need some function that controls name display priority
(which name is first Proper Name or Auto Name). This function also
achieved easily by using existing current technologies.
If Auto Name and Proper Name are implemented as different name
resolving services (e.g., one is /etc/hosts, the other is the DNS),
name display priority is can be easily controlled by nsswitch.conf
function.
If Auto Name and Proper Name are implemented as same name resolving
service, name display priority is can be controlled by their
registration order to the name resolving service DB.
H. Kitamura Expires April 2013 [Page 10]
Internet Draft Auto Names for IPv6 Addresses
4. Design of Auto Names
4.1. Conceptual Design on Naming Rules
Auto Names are composed of "<P><I>-<NGI>" format:
<P>: stands for Prefix of Address
1 character: (e.g., 'L', 'U', 'G')
<I>: stands for Interface ID of Address
1 character: (e.g., '0', '1')
<NGI>: stands for Node (Interface) Group ID
3 characters:
(e.g., '7bz', '3ez')
Above discussed Auto Name examples satisfy <P><I>-<NGI> format.
on Node A: L0-7bz, U0-7bz, U1-7bz, G0-7bz, G1-7bz
on Node B: L0-3ez, U0-3ez, U1-3ez, G0-3ez, G1-3ez
4.1.1. <P> Value:
<P> value stands for Prefix (Scope) (upper 64 bit) of Address as 1
character format.
Auto Names of IPv6 addresses whose prefixes are same use the same
<P> value.
Typically, following characters are used for <P> value:
"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.
"Prefix - <P> value" mapping table:
If the scope of Auto Name is wider than link-local and Auto Name
information is shared with other nodes, a mapping table (called
"Prefix - <P> value" mapping table) is used to avoid collision and
manage mappings of them.
H. Kitamura Expires April 2013 [Page 11]
Internet Draft Auto Names for IPv6 Addresses
4.1.2. <I> Value:
<I> value stands for Interface ID (lower 64 bit) of Address as 1
character format.
Following characters are used for <I> value:
<I> value assignment is based on three address type
categorization.
"0": used for EUI64-based address
"1",,"9": used for manually set addresses
(stateful addresses will be categorized here)
"a",,"z": used for automatically generated and set addresses
except EUI64-based
(Temporary addresses are categorized here)
4.1.3. <NGI> Value:
<NGI> value is also called Auto Name-Suffix.
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.
<NGI> value is shown as 'XYZ' format:
'XY': (1st, 2nd chars) are inherited from
the last octet (2 charters) of the node's MAC address
'Z' : (3rd 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 19 nodes (interfaces) exist on
the same link, collision is happened with 50% probability.
Collision check procedure of the last octet of MAC addresses is
necessary.
"MAC address - <NGI> value" mapping table:
If the scope of Auto Name is wider than link-local and Auto Name
information is shared with other nodes, a mapping table (called
"MAC address - <NGI> value" mapping table) is needed to avoid
collision and manage mappings of them.
H. Kitamura Expires April 2013 [Page 12]
Internet Draft Auto Names for IPv6 Addresses
Detailed methods how to distinguish and categorize IPv6 addresses
are described at the following section.
We can found one remarkable thing with the naming rules:
"L0-XYz" is a special and very standard Auto Name. "L0-XYz" is an
Auto Name that assigned for Link-local scoped EUI64-based address.
Since Almost all the IPv6 nodes have Link-local scoped EUI64-based
address, with "L0-XYz" name information we can reach or communicate
the node whose last octet MAC address is known as "XY".
4.2. Address Type Distinction
If we can obtain address type information from Auto Name,
convenient environment will be provided. So, there are strong
desires to understand type of detected IPv6 addresses. In this
section, methods how to distinguish and categorize IPv6 addresses
are described.
4.2.1. EUI64-based Address Identification
Only with IPv6 address information, it is impossible to identify
that the detected IPv6 address is EUI64-based address or not.
In proposed IPv6 address detection method which is described in the
following section, IPv6 address and MAC address that are set to the
same node (interface) is detected simultaneously.
So, with this detection method, it is very easy to identify that
the detected IPv6 address is EUI64-based address or not.
4.2.2. "Zero Contain Rate" and Manual or Automatic Distinction
It is generally difficult to distinguish whether the detected IPv6
address is manually or automatically set address.
In order to distinguish IPv6 address types, "Zero Contain Rate"
technique is introduced.
For a human being, "Zero" is a special value. When a human being
omits a part of information, "Zero" is used for the omitted part of
information implicitly.
For a machine "Zero" is NOT a special value. "Zero" is treated as
almost equal to other values.
We can reach a fact that manually set IPv6 address contains many
"Zero", because it is assigned by a human being. 64bit is long for
H. Kitamura Expires April 2013 [Page 13]
Internet Draft Auto Names for IPv6 Addresses
a human being and there must be too many omitted part filled with
"Zero". Especially, a human being is apt to omit and fill with
"Zero" upper part of 64bit Interface ID.
In other words, we can see human relation bias from "Zero Contain
Rate" of IPv6 address.
Bias Check by using Mathematical Technique:
By using mathematical probability technique, we can distinguish
whether value of 64bit Interface ID is biased (manual) or non-
biased (automatic).
When we see 64bit value in 8bit (1 octet) unit, it follows the
binomial distribution (n=8 and p=1/256).
Under this distribution, the probability to meet "Zero" octet two
times is 0.042%. It means that to meet "Zero" octet two times is
too rare case if the value is non-biased.
So, we can adopt the following method:
If the value of 64bit Interface ID contains two and above "Zero"
octets,
the value is bias and
the IPv6 address is identified as a manually set address.
Of cause, this method is not perfect because this is based on
mathematical probability technique and heuristic human behavior,
but this is very effective.
Even if wrong identification is done, no big problems are found.
H. Kitamura Expires April 2013 [Page 14]
Internet Draft Auto Names for IPv6 Addresses
5. Name Services
It is not clearly defined which Name Services is utilized to
achieve Auto Names specifications. In other words, any types of
Name Services can be utilized. Which Name Services is utilized is
tightly dependent on which Scoped Name is adopted for the Auto
Names.
If wide Scoped Name is adopted, it is very natural to utilize wide
Name Servce (i.e. the DNS) as the Name Services for Auto Names. If
narrow scope (e.g., node-local scoped name) is adopted for Auto
Names, it becomes possible to utilize node-local scoped Name
Service (e.g., /etc/hosts) for Auto Name.
6. Security Considerations
Auto Names are generated and registered to the name service in this
document. In order to register correct Auto Names information,
communication 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.
7. IANA Considerations
This document does not require any resource assignments to IANA.
H. Kitamura Expires April 2013 [Page 15]
Internet Draft Auto Names for IPv6 Addresses
Appendix A. 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.
A.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.
A.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
H. Kitamura Expires April 2013 [Page 16]
Internet Draft Auto Names for IPv6 Addresses
is not duplicated.
Finally, Registrar registers both Regular and Reverse resolving
entries for the address and prepared Auto Name are registered to the
name server.
A.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 |
+===========+ +===========+
H. Kitamura Expires April 2013 [Page 17]
Internet Draft Auto Names for IPv6 Addresses
Fig. 2 Multiple-Link Case Example
A.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 2013 [Page 18]
Internet Draft Auto Names for IPv6 Addresses
Appendix B. Implementation
Auto Name functions have been implemented at the following environ-
ments. It has been verified that designed functions work well.
Used functions:
Packet capture on Detector: libpcap
Name Server: DNS (BIND9)
Name Registration: nsupdate (BIND9 bundled)
OS:
FreeBSD 6.2R
(Since FreeBSD OS specific funtions are not used to implement,
codes will run on UNIX type OS that has libpcap (such as Linux).)
Acknowledgment
A part of this work is supported by the program: SCOPE (Strategic
Information and Communications R&D Promotion Programme) operated by
Ministry of Internal Affairs and Communications of JAPAN.
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
H. Kitamura Expires April 2013 [Page 19]
Internet Draft Auto Names for IPv6 Addresses
[RFC4795] B. Aboba, D. Thaler, and L. Esibov, "Link-Local Multicast
Name Resolution (LLMNR)," RFC4795, January 2007
Informative References
[RFC4620] M. Crawford and B. Haberman, "IPv6 Node Information
Queries," RFC4620, August 2006
[mDNS] S. Cheshire and M. Krochmal, "Multicast DNS" <draft-cheshire-
dnsext-multicastdns-14.txt> 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
Knowledge Discovery 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 2013 [Page 20]
