[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 6784

INTERNET-DRAFT                                                 S. Sakane
Intended Status: Informational                   Yokogawa Electric Corp.
Expires: April 3, 2009                                       M. Ishiyama
                                                           Toshiba Corp.
                                                      September 30, 2008

                       Kerberos Option for DHCPv6

                          Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft expires in April 3, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   This document defines a new DHCPv6 option to carry a set of
   configuration information related to the Kerberos protocol [RFC4120].

Sakane & Ishiyama                                               [Page 1]

Internet-Draft                                            September 2008

   This document also defines three sub-options to be used in this new
   option, which specify a realm name of the Kerberos, a list of IP
   addresses of the Key Distribution Center of that realm and a client
   principal name to distinguish a Kerberos client by the DHCPv6 server.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   It is assumed that the readers are familiar with the terms and
   concepts described in the DHCPv6 [RFC3315].

Sakane & Ishiyama                                               [Page 2]

Internet-Draft                                            September 2008

Table of Contents

    1. Introduction .................................................  4
    2. Kerberos Option ..............................................  4
       2.1. Realm Name Sub-Option ...................................  5
       2.2. KDC Sub-Option ..........................................  6
       2.3. Client Principal Name Sub-Option ........................  6
    3. Client Operation .............................................  7
       3.1. A recommendation of KDC discovery for a client ..........  8
    4. Server Operation .............................................  9
    5. Appearance of this option .................................... 10
    6. Specification Issue Consideration ............................ 10
       6.1. Providing a Service Type ................................ 10
       6.2. Other configuration values to be provided ............... 11
       6.3. Providing IPv4 Address .................................. 12
       6.4. Behavior when there is no information ................... 12
    7. IANA Considerations .......................................... 12
    8. Security Considerations ...................................... 13
    9. Acknowledgments .............................................. 13
   10. References ................................................... 13
       10.1. Normative References ................................... 14
   Appendix A. Why DNS is not acceptable in some environment ........ 14
   Authors' Addresses ............................................... 18
   Full Copyright Statement ......................................... 18
   Intellectual Property Statement .................................. 18

Sakane & Ishiyama                                               [Page 3]

Internet-Draft                                            September 2008

1.  Introduction

   The Kerberos Version 5 [RFC4120] is an authentication system which is
   based on the trusted third-party authentication protocol.  Each
   organization wishing to use the Kerberos protocol establishes its own
   "realm", and each client is assigned to the realm.  At least more
   than one Key Distribution Center (KDC) is required for the Kerberos
   operation of the realm.

   When the client wants to begin communication with the peer and to be
   authenticated by the peer, the client needs to take a credential from
   the KDC.  In this process, the client required to indicate a realm
   name to which the client itself belongs.  After the client gets the
   credential, the client presents it to the peer.  The peer can
   authenticate the access from the client with the credential.  Hence,
   the client needs to know its realm name, and at least more than one
   IP address of KDC from which the client can get the credential,
   before the client begins the communication with the peer.

   Furthermore, a public workstation for an unspecified several number
   of people does not have any initial configuration for the Kerberos.
   Any mechanism is required to provide a default realm to such

   For providing a set of IP addresses of the KDC, the Kerberos V5
   specification [RFC4120] defines a KDC discovery by utilizing DNS SRV
   records [RFC2782].  Providing a set of IPv4 addresses of the KDC to
   the devices deployed into the PacketCable Architecture [PCARCH], the
   KDC Server Address sub-option for the DHCPv4 CableLabs Client
   Configuration option is defined in RFC 3634 [RFC3634].

   For providing a realm name, and for a certain special environment
   where using DNS is not appropriate (The detail is described in the
   APPENDIX), the Kerberos option for DHCPv6 defined by this document
   allows to provide a realm name and/or a list of IP addresses of the
   KDC.  The Kerberos option does not replace and deny of the previous
   methods, and this option does not interfere with those methods.

2.  Kerberos Option

   The Kerberos option provides a realm name and/or a set of IP
   addresses of the KDC.  The option contains more than one sub-option
   defined in this document.  This document defines the Realm Name sub-
   option, the KDC sub-option and the Client Principal Name sub-option.
   Any other sub-option may be defined in other documents.

Sakane & Ishiyama                                               [Page 4]

Internet-Draft                                            September 2008

   The format of the Kerberos option is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |            OPTION_KRB         |           option-len          |
       :                                                               :
       :                 Kerberos sub-options (variable)               :
       :                                                               :

   o  option-code: OPTION_KRB (TBD by IANA)

   o  option-len: length of the Kerberos sub-options in octets.

   o  Kerberos sub-options (variable): each sub-option is listed in the
      Kerberos sub-options field sequentially.  The order of the sub-
      options is discussed in section of the server behavior of this
      document.  Currently, the following options are defined.  Any
      other sub-options my be defined in the future.

           Realm Name sub-option
           KDC sub-option
           Client Principal Name sub-option

2.1.  Realm Name Sub-Option

   The Realm Name sub-option provides a realm name.  The encoding of the
   realm-name field MUST be conformed to "KerberosString" defined in
   section 5.2.1 of RFC 4120.  The naming constraints MUST be conformed
   to section 6.1 of RFC 4120.

   The format of the realm name sub-option is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |     SUB_OPTION_REALM_NAME     |          sub-opt-len          |
       :                                                               :
       :                       realm-name (variable)                   :
       :                                                               :

Sakane & Ishiyama                                               [Page 5]

Internet-Draft                                            September 2008

   o  sub-option-code: SUB_OPTION_REALM_NAME (TBD by IANA)

   o  sub-opt-len: length of the realm-name field in octets.

   o  realm-name (variable): a realm-name.

2.2.  KDC Sub-Option

   The KDC sub-option provides an address of the KDC, a weight and a
   port number.  See section of the Specification Issue Consideration
   for discussion of providing a service type of the Kerberos protocol.

   The format of the KDC sub-option is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |         SUB_OPTION_KDC        |          sub-opt-len          |
       |            Weight             |          Port Number          |
       :                                                               :
       :                    KDC address (variable)                     :
       :                                                               :

   o  sub-option-code: SUB_OPTION_KDC (TBD by IANA)

   o  sub-opt-len: 4 + length of the KDC address field in octets.

   o  Weight: a value for a server selection mechanism.  It specifies a
      hint for a kind of server selection mechanism of a client.  An
      implementer could refer to the DNS SRV specification [RFC2782] for
      this usage.

   o  Port Number: a port number listened to by the KDC

   o  KDC address (variable): an IP address of the KDC

2.3.  Client Principal Name Sub-Option

   The Kerberos protocol uses a "principal name" as the client
   identifier.  It is desirable to use the principal name in order that
   the server determines a specific Kerberos information for the client.
   This sub-option specifies the client principal name.  The contents of

Sakane & Ishiyama                                               [Page 6]

Internet-Draft                                            September 2008

   the name-string field is only "name-string" defined in section 5.2.2
   of RFC 4120, and its encoding MUST be conformed to "KerberosString"
   defined in section 5.2.1 of RFC 4120.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |     SUB_OPTION_CLIENT_NAME    |          sub-opt-len          |
       |                           name-type                           |
       :                                                               :
       :                     name-string (variable)                    :
       :                                                               :

   o  sub-option-code: SUB_OPTION_CLIENT_NAME (TBD by IANA)

   o  sub-opt-len: 4 + length of the name-string field.

   o  name-type: an unsigned integer value in network byte order.  It is
      specified a name-type of the principal name.  The value is defined
      in section 6.2 of RFC 4120.

   o  name-string (variable): it specified a name-string of the
      principal name.

3.  Client Operation

   When a client needs to know information of the Kerberos, the client
   may send an Information-request Message which includes the DHCPv6
   option number of the Kerberos option in the Option Request Option
   defined in section 22.7 of RFC 3315 [RFC3315].  The client MAY
   include any other options with data values as hints to the server as
   it is described in section 18.1.5 of RFC 3315 [RFC3315].  When the
   client needs to know a specific information of a certain realm, the
   client MAY specify the realm name.  If the client wants to get a
   specific information related to its own client principal name, the
   client MUST put own principal name into the Client Principal Name
   sub-option of the Kerberos option.

   Multiple KDC address sub-options MAY be listed in a Kerberos Option
   of the Reply Message from the server.  If a client receives a set of
   addresses of the KDC, the client MUST contact to the addresses in the
   order of the list.

   An implementor should also refer to the Stateless Dynamic Host
   Configuration Protocol (DHCP) Service for IPv6 [RFC3736].

Sakane & Ishiyama                                               [Page 7]

Internet-Draft                                            September 2008

3.1.  A recommendation of KDC discovery for a client

   When a client has a capability of both the DNS method defined by RFC
   4120 and the DHCP method defined this document, which methods the
   client should use to get the kerberos information depends on the
   policy of the environment.  The administrator of the realm MUST
   define the method to the client before the client is installed into
   the environment.

   When there is no criteria in the environment, and the client could
   get the Kerberos information from both the DNS server and the DHCP
   server, then the information from DNS is recommended.  The following
   is a recommendation of the behavior of the client in such environment
   where there is no criteria.
                               No Ans. or
               +------------+  DNS Info.  +-----------+ No Ans.
     Start --> | Ask DHCP(1)| ----------> | Ask DNS(3)| ------> Abort(4)
               +------------+             +-----------+
                /          \                       \
      Only KRB /            \ DNS and               \ KRB Info.
        Info. /              \ KRB Info.             \
             /                \                       \
            |                  |                       |
            |                  V                       |
            V     No Ans.  +-----------+  KRB Info.    V
     Adopt Info. <-------- | Ask DNS(6)| ---------> Adopt Info.
     from DHCP             +-----------+            from DNS
      (2), (7)                                      (5), (8)

          Ans.: Answer
          Info.: Information
          KRB: Kerberos

   1) At the first, the client asks both DNS and KRB information to the
      DHCP server.

   2) If the client gets only a response with KRB information from the
      DHCP server, the client adopts the information from the DHCP

   3) As the result of (1), if the client gets either no answer or only
      a response with DNS information from the DHCP server, the client
      then asks KRB information to the DNS server.

   4) If the client gets no answer from the DNS server, then the client
      will abort.

Sakane & Ishiyama                                               [Page 8]

Internet-Draft                                            September 2008

   5) If the client gets KRB information from the DNS server, then the
      client adopts the information from the DNS server.

   6) As the result of (1), if the client gets both DNS and KRB
      information from the DHCP server, then the client asks KRB
      information to the DNS server.

   7) If the client gets no answer from the DNS server, the client
      adopts the KRB information from the DHCP server.

   8) As the result of (6), if the client gets KRB information from the
      DNS server, the client adopts the information instead of another
      from the DHCP server.

4.  Server Operation

   After the DHCPv6 server receives a message which is contained an
   Option Request Option, what information the server will provide
   depends on the policy of the server in the end.  If there is no
   criteria on the server, the following operation is recommended.

   The server should send a Reply Message back to the client when the
   option number of the Kerberos option is specified in the Option
   Request option by the client.

   When the message did not include any information which can be used to
   determine data for a specific client, the server should reply at
   least a realm name sub-option as a default realm for example.  The
   Kerberos option is followed by a realm name sub-option.  The form of
   the Kerberos option in this case is:

       (Kerberos option) | (Realm Name sub-option)

             '|' means concatenation.

   When the server determines to reply a set of addresses of the KDC by
   its configuration or by information specified in the message, the
   server SHOULD reply the KDC options in the order of preference by
   which the server wants the client to connect with each KDC.  The
   Kerberos option is followed by a Realm Name option followed by a set
   of the KDC options.  The form of the Kerberos option in this case is:

Sakane & Ishiyama                                               [Page 9]

Internet-Draft                                            September 2008

      (Kerberos option | (Realm Name sub-option) |
         (KDC sub-option) [| (KDC sub-option) [|...]]

         '|' means concatenation.
         '[|...]' means other sub-options might be optionally

   If there is no information related to the Kerberos option in the
   server's DHCPv6 configuration database, See the section of "the
   behavior when there is no information" in this document.

5.  Appearance of this option

   The Kerberos option MUST NOT appear in any other than the following
   messages: Solicit, Advertise, Request, Renew, Rebind, Information-
   request and Reply.  The option MAY also appear in the DHCP-relay-
   message field of both Relay-forward or Relay-reply message.  If this
   option appears in messages other than those specified above, the
   receiver MUST ignore it.

   The number of the Kerberos option MAY appear in the Option Request
   Option in the DHCPv6 message types Solicit, Request, Renew, Rebind,
   Information-request and Reconfigure.  The number MAY also appear in
   the DHCP-relay-message field of both Relay-forward or Relay-reply

   The sub-option of the Kerberos option MUST appear only in the
   Kerberos option.

6.  Specification Issue Consideration

   This section discusses what we should have to further consider for
   specifying the Kerberos option.  We are expecting any input from
   experts to solve below issues.  This section will be removed in near
   future after the specification is clear or the issues are solved.

6.1.  Providing a Service Type

   The Service Type specifies the transport medium of the Kerberos
   communication.  The Kerberos specification [RFC4120] defines to use
   UDP and TCP for communication between clients and servers.  Other
   transports are not defined in RFC 4120.  However, SCTP might be used
   in the future.  In addition, the Heimdal implementation can use HTTP
   as a transport type for that purpose.

Sakane & Ishiyama                                              [Page 10]

Internet-Draft                                            September 2008

   The Service Type should be put into each KDC sub-option if required.
   To put it into the KDC sub-option, the "Weight" field could be
   shortened to 8-bit from 16-bit.  And the Service Type could put the
   place immediately after the Weight field.

   If the Service Type is required and above proposals are accepted, the
   form of the KDC sub-option becomes like the following:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       |         SUB_OPTION_KDC        |          sub-opt-len          |
       |     Weight    |  Service Type |          Port Number          |
       :                                                               :
       :                          KDC address                          :
       :                                                               :

   o  Service Type: the value of the type is defined in below.

         Reserved 0
         UDP      1 (default)
         TCP      2
         SCTP     3
         HTTP     4
         Reserved 5-15

6.2.  Other configuration values to be provided

   CableLabs Configuration Option [RFC3495] is the option using in the
   PacketLabs Architecture [PCARCH].  This option can provide a timer
   and a counter to a client.  These are used to determine how long time
   the client keeps trying to contact to the KDC for the Kerberos
   processing until the KDC will respond, and how many times the client
   needs to contact to the KDC for retrying.  This option can also
   provide a flag to determine whether or not the client needs to use
   the special credential(ticket-granting ticket) to get a new
   credential(application ticket) from the KDC.  There is another
   special sub-option can provide a FQDN of the KDC in the CableLabs

   The Kerberos option defined in this document can be added these
   feature as its sub-option if these are needed.  However, these
   feature is out of scope of this document, and might be defined in
   another document in the future.

Sakane & Ishiyama                                              [Page 11]

Internet-Draft                                            September 2008

6.3.  Providing IPv4 Address

   Basically, one of the purpose of this document is to configure an
   IPv6 client by using the DHCPv6 server.  However, the address family
   of the communication of any Kerberos service does not depend on the
   address family of the DCHPv6 service.  Essentially, the DHCPv6 server
   could provide a set of IPv4 addresses of the KDC by using the KDC
   sub-option.  As one solution to enable this, the sub-opt-len of the
   KDC sub-option could be used to determine whether the KDC-address
   contained in the sub-option is an IPv6 address or an IPv4 address.
   If the length is 8 (fixed field length + IPv4 address length), it
   means that the type of the address is IPv4.  Another solution is to
   add a field identifying the address family into the KDC sub-option.
   It requires further 2 octets of the sub-option.  This value [ADDRFAM]
   is maintained by the IANA.

6.4.  Behavior when there is no information

   This problem is not only issue for the Kerberos option.  Actually, no
   server's behavior is not defined in RFC 3315 when there is no
   information in the server's configuration database related to an
   option which is specified at an Option Request option from a client.
   One solution in this case is that the server could just ignore the
   message.  On the other hand, there is another solution in section
   18.2.5 of RFC 3315,

      If the Information-request message received from the client
      did not include a Client Identifier option, the server SHOULD
      respond with a Reply message containing any configuration
      parameters that are not determined by the client's identity.
      If the server chooses not to respond, the client may continue
      to retransmit the Information-request message indefinitely.

   For the latter case, we need to define a new status code which means
   "there is no information of the option in the ORO".  And the server
   sends it back to the client.

7.  IANA Considerations

   When this document is published, the IANA is requested to assign an
   option code from the option-code space defined in "DHCPv6 Options"
   section of [RFC3315] for the Kerberos option named OPTION_KRB.

   The IANA is also requested to create a new name space "DHCPv6
   Kerberos Sub-option Codes", and these sub-options should be placed
   under the same registry.

Sakane & Ishiyama                                              [Page 12]

Internet-Draft                                            September 2008

          o Reserved                                 0
          o SUB_OPTION_REALM_NAME                    1
          o SUB_OPTION_KDC                           2
          o SUB_OPTION_CLIENT_NAME                   3
          o Reserved                                 4 - 65535

8.  Security Considerations

   The security considerations in RFC 3315 fully apply.  The message of
   DHCPv6 could be altered undesirably.  If an adversary modifies the
   response from a DHCPv6 server or inserts its own response, a client
   could be led to contact a rogue KDC or a server which does not know
   the client access.  Both cases are categorized into a kind of the
   denial of service attack.  However, such incorrect KDC does not know
   the shared key between the client and a valid KDC.  The incorrect KDC
   is not be able to proceed any further state of the client.  Even when
   the client receives a response from such KDC, the client can know the
   fact that it has received an inappropriate message after it verifies
   the response with the shared key.  In order to minimize potential
   vulnerabilities, a client SHOULD require to use the DHCPv6
   authentication defined in section 21 of RFC 3315, or any other
   authentication mechanism.

   Sometimes, the Kerberos information is manually configured into the
   client before the DHCPv6 process starts.  Generally, the manual
   configuration to the device should be preferred to the configuration
   by the DHCP server.  Overwriting the manual configuration should be
   considered in anytime.

9.  Acknowledgments

   The authors are very grateful to Nobuo Okabe and Shigeya Suzuki.
   They contributed the summary explaining why DNS is not appropriate to
   the Industry networks, which is put as the appendix of this document.
   Ken'ichi Kamada and Yukiyo Akisada contributed for the initial work
   of making this document.  The authors also thank Jeffrey Hutzelman,
   Kazunori Miyazawa, Kensuke Hosoya, Nicolas Williams, Nobumichi Ozoe,
   and Sam Hartman.  They gave us valuable comments and suggestions for
   this document.

10.  References

Sakane & Ishiyama                                              [Page 13]

Internet-Draft                                            September 2008

10.1.  Normative References

   [ADDRFAM]   Internet Assigned Numbers Authority, "Protocol
               Registries: Address Family Numbers",

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2782]   A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for
               specifying the location of services (DNS SRV)", RFC 2782,
               February 2000.

   [RFC3315]   R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins,
               M. Carney.  "Dynamic Host Configuration Protocol for IPv6
               (DHCPv6)", RFC 3315, July 2003.

   [RFC3495]   B. Beser, P. Duffy, Ed., "Dynamic Host Configuration
               Protocol (DHCP) Option for CableLabs Client
               Configuration", RFC 3495, March 2003.

   [RFC3634]   K. Luehrs, R. Woundy, J. Bevilacqua, N. Davoust, "Key
               Distribution Center (KDC) Server Address Sub-option for
               the Dynamic Host Configuration Protocol (DHCP) CableLabs
               Client Configuration (CCC) Option", RFC 3634, December

   [RFC3736]   R. Droms, "Stateless Dynamic Host Configuration Protocol
               (DHCP) Service for IPv6", RFC 3736, April 2004.

   [RFC4120]   Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
               Kerberos Network Authentication Service (V5)", RFC 4120,
               July 2005.

   [PCARCH]    "PacketCable 1.0 Architecture Framework Technical
               Report", PKT-TR-ARCH-V01-991201,

Appendix A. Why DNS is not acceptable in some environment

Sakane & Ishiyama                                              [Page 14]

Internet-Draft                                            September 2008

   1. Summary

      - This appendix describes reasons why DHCP-based KDC discovery
        is more suitable than DNS-based KDC discovery described
        in RFC4120 (= the RFC4120-way) for the industrial systems.

      - The main reason is that some industrial systems don't use DNS
        because they have already had their own name spaces and
        naming systems rather than FQDN and DNS.

      - Less servers benefits the industrial systems:
        1) Less messages simplifying the systems.
        2) Less servers contributing reliability,
           and reducing management cost.

      - We understand that RFC4120 does not require DHCP for KDC
        discovery.  However, we will have to solve DNS discovery
        when considering the RFC4120-way.
        And it is natural way to use DHCP for the purpose.

      - DHCP-based KDC discovery is more efficient under those
        systems (=expecting not to use DNS).

   2. Background (what's industrial systems?)

      Industrial systems are a kind of sensor systems.
      The systems have a large number of devices, i.e. sensors and
      actuators, usually called field devices
      by which the systems control plants, factories, buildings, etc.

      The field devices have the following features:
      1) Their resources, e.g. processing capability, memory size,
         footprint, power consumption and user i/f, are limited
         even though they are physically large.
      2) The field device is controlled as an I/O by a administrative
         device, usually called controller, with a legacy communication
      3) Security of the field devices have not been cared
         because they are regarded as being on I/O buses, not networks.

   3. High-level goal and some requirements

   3.1. IP and security can enhance the industrial systems.

      Our goal is to introduce latest IP-based network technology
      into field devices for enhancing the entire system.
      1) Network architecture (=IP technology) can enhance
         the systems including the field devices.

Sakane & Ishiyama                                              [Page 15]

Internet-Draft                                            September 2008

      2) The field devices will require security if network architecture
         is introduced. The field devices will not be I/O devices

   3.2. Auto-configuration benefits the industrial systems.

      Auto-configuration will also be important for large systems
      like the industrial systems if introducing new technology or

      1) Reducing engineering cost when installing/configuring
         large number of field devices over spread area.
         The following are existing large systems.
         The size of a plant, the size of an industrial system and
         the number of field devices are growing.

         - An example of single large PA system:
           About 20000 field devices over 2km*2km area

              - http://www.process-worldwide.com/fachartikel/pw_facha

         - An example of distributed PA systems:
           About 30000 field devices for 26 distributed sites
           over 30km*30km area.

              - http://www.mikrocentrum.nl/FilesPage/3462/Presentatie
              - http://www.nam.nl/home/Framework?siteId=nam-en&FC2=/n

         - An example of single large BA system:
           170000 control points of 16500 field devices in
           729,000 sq. meters (7.8 million sq. ft.) building complex.

              - http://www.echelon.com/company/press/2003/echelon_mor

      2) Reducing the chance of human error.

      3) Making disaster-recovery easier.

   3.3. Security mechanism suited to resource-limited devices are

Sakane & Ishiyama                                              [Page 16]

Internet-Draft                                            September 2008

      Kerberos-based security can be suited resource-limited devices,
      i.e. the field devices, because of not requiring
      public key cryptography (of course, when not using PKINIT).

   4. Some industrial systems don't use DNS.

      For field devices, there have been multiple technologies (see
      Section 6) which don't use DNS because of having already had
      their own name spaces and naming systems even though introducing
      IP (partially at this moment).

      For example, TAG is the common logical identifier for PA systems
      and Device ID is the common logical identifier for BA systems.
      (You may think those names are not so abstracted, though....)

   5. KDC discovery with DHCP is more suitable than the one with DNS.

      If Kerberos is introduced into the field devices,
      auto-configuration will be achieved with the following steps:
      1) Learning DNS address(es) by DHCP
      2) Learning KDC address(es) by DNS based on RFC4120-way.
      However, DNS will be used by kerberos-related part only.
      Most application will not use DNS as described above.

      If DHCP can advertise KDC-related information instead of DNS,
      there are the following advantages.
      1) It can reduce messages handled by the field devices.
         Consequently, it can reduce footprint of the field devices.
      2) It can reduce the number of servers.
         Consequently, it contribute to management cost of the systems.

   6. References

      There have been multiple technologies for field devices.
      - FOUNDATION Fieldbus (http://www.fieldbus.org/)
      - PROFIBUS (http://www.profibus.com/)
      - BACnet (http://www.bacnet.org/)
      - LonWorks (http://www.echelon.co.jp/products/lonworks.html)
      - Modbus (http://www.modbus.org/)

      You can learn about communication technology of field devices
      with wikipedia:
      - http://en.wikipedia.org/wiki/Fieldbus
      - http://en.wikipedia.org/wiki/BACnet
      - http://en.wikipedia.org/wiki/LonWorks

Sakane & Ishiyama                                              [Page 17]

Internet-Draft                                            September 2008

Authors' Addresses

   Shoichi Sakane
   Yokogawa Electric Corporation
   2-9-32 Nakacho, Musashino-shi,
   Tokyo  180-8750 Japan
   E-mail: Shouichi.Sakane@jp.yokogawa.com

    Masahiro Ishiyama
    Toshiba Corporation
    1, komukai-toshiba-cho, Saiwai-ku,
    Kawasaki  212-8582 Japan
    E-mail: masahiro@isl.rdc.toshiba.co.jp

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

Sakane & Ishiyama                                              [Page 18]

Internet-Draft                                            September 2008


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-

Sakane & Ishiyama                                              [Page 19]

Html markup produced by rfcmarkup 1.114, available from https://tools.ietf.org/tools/rfcmarkup/