Internet Engineering Task Force (IETF) R. Seggelmann
Request for Comments: 6520 M. Tuexen
Category: Standards Track Muenster Univ. of Appl. Sciences
ISSN: 2070-1721 M. Williams
GWhiz Arts & Sciences
February 2012
Internet Engineering Task Force (IETF) R. Seggelmann
Request for Comments: 6520 M. Tuexen
Category: Standards Track Muenster Univ. of Appl. Sciences
ISSN: 2070-1721 M. Williams
GWhiz Arts & Sciences
February 2012
Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension
传输层安全性（TLS）和数据报传输层安全性（DTLS）心跳扩展
Abstract
摘要
This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.
本文档描述了传输层安全性（TLS）和数据报传输层安全性（DTLS）协议的心跳扩展。
The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS.
Heartbeat扩展为TLS/DTL提供了一个新的协议，允许在不执行重新协商的情况下使用保持活动功能，并为DTL的路径MTU（PMTU）发现提供了基础。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6520.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6520.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Heartbeat Hello Extension . . . . . . . . . . . . . . . . . . . 3
3. Heartbeat Protocol . . . . . . . . . . . . . . . . . . . . . . 4
4. Heartbeat Request and Response Messages . . . . . . . . . . . . 5
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Heartbeat Hello Extension . . . . . . . . . . . . . . . . . . . 3
3. Heartbeat Protocol . . . . . . . . . . . . . . . . . . . . . . 4
4. Heartbeat Request and Response Messages . . . . . . . . . . . . 5
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols, as defined in [RFC5246] and [RFC6347] and their adaptations to specific transport protocols described in [RFC3436], [RFC5238], and [RFC6083].
本文档描述了[RFC5246]和[RFC6347]中定义的传输层安全性（TLS）和数据报传输层安全性（DTLS）协议的心跳扩展及其对[RFC3436]、[RFC5238]和[RFC6083]中描述的特定传输协议的适应性。
DTLS is designed to secure traffic running on top of unreliable transport protocols. Usually, such protocols have no session management. The only mechanism available at the DTLS layer to figure out if a peer is still alive is a costly renegotiation, particularly when the application uses unidirectional traffic. Furthermore, DTLS needs to perform path MTU (PMTU) discovery but has no specific message type to realize it without affecting the transfer of user messages.
DTLS旨在保护运行在不可靠传输协议之上的流量。通常，这样的协议没有会话管理。DTLS层唯一可用的机制是昂贵的重新协商，特别是当应用程序使用单向流量时。此外，DTL需要执行路径MTU（PMTU）发现，但没有特定的消息类型来实现它，而不影响用户消息的传输。
TLS is based on reliable protocols, but there is not necessarily a feature available to keep the connection alive without continuous data transfer.
TLS基于可靠的协议，但不一定有一种功能可以在不进行连续数据传输的情况下保持连接的活动性。
The Heartbeat Extension as described in this document overcomes these limitations. The user can use the new HeartbeatRequest message, which has to be answered by the peer with a HeartbeartResponse immediately. To perform PMTU discovery, HeartbeatRequest messages containing padding can be used as probe packets, as described in [RFC4821].
本文档中描述的Heartbeat扩展克服了这些限制。用户可以使用新的HeartbeatRequest消息，该消息必须由具有HeartbeartResponse的对等方立即响应。要执行PMTU发现，可以将包含填充的HeartbeatRequest消息用作探测数据包，如[RFC4821]中所述。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The support of Heartbeats is indicated with Hello Extensions. A peer cannot only indicate that its implementation supports Heartbeats, it can also choose whether it is willing to receive HeartbeatRequest messages and respond with HeartbeatResponse messages or only willing to send HeartbeatRequest messages. The former is indicated by using peer_allowed_to_send as the HeartbeatMode; the latter is indicated by using peer_not_allowed_to_send as the Heartbeat mode. This decision can be changed with every renegotiation. HeartbeatRequest messages MUST NOT be sent to a peer indicating peer_not_allowed_to_send. If an endpoint that has indicated peer_not_allowed_to_send receives a HeartbeatRequest message, the endpoint SHOULD drop the message silently and MAY send an unexpected_message Alert message.
Heartbeats的支持由Hello扩展表示。对等方不仅可以表示其实现支持心跳，还可以选择是愿意接收心跳请求消息并使用心跳响应消息进行响应，还是只愿意发送心跳请求消息。前者通过使用允许发送的对等方作为HeartbeatMode来表示；后者通过使用peer_not_allowed_to_send作为心跳模式来表示。每次重新谈判都会改变这一决定。HeartbeatRequest消息不得发送到表示不允许发送的对等方。如果已指示peer_not_allowed_发送的终结点接收到HeartbeatRequest消息，则该终结点应无声地删除该消息，并可能发送意外的_消息警报消息。
The format of the Heartbeat Hello Extension is defined by:
Heartbeat Hello扩展的格式由以下内容定义：
enum {
peer_allowed_to_send(1),
peer_not_allowed_to_send(2),
(255)
} HeartbeatMode;
enum {
peer_allowed_to_send(1),
peer_not_allowed_to_send(2),
(255)
} HeartbeatMode;
struct {
HeartbeatMode mode;
} HeartbeatExtension;
struct {
HeartbeatMode mode;
} HeartbeatExtension;
Upon reception of an unknown mode, an error Alert message using illegal_parameter as its AlertDescription MUST be sent in response.
在接收到未知模式时，必须发送一条错误警报消息作为响应，该消息使用非法_参数作为其警报描述。
The Heartbeat protocol is a new protocol running on top of the Record Layer. The protocol itself consists of two message types: HeartbeatRequest and HeartbeatResponse.
心跳协议是运行在记录层之上的新协议。协议本身由两种消息类型组成：HeartbeatRequest和HeartbeatResponse。
enum {
heartbeat_request(1),
heartbeat_response(2),
(255)
} HeartbeatMessageType;
enum {
heartbeat_request(1),
heartbeat_response(2),
(255)
} HeartbeatMessageType;
A HeartbeatRequest message can arrive almost at any time during the lifetime of a connection. Whenever a HeartbeatRequest message is received, it SHOULD be answered with a corresponding HeartbeatResponse message.
HeartbeatRequest消息几乎可以在连接生命周期内的任何时间到达。无论何时收到HeartbeatRequest消息，都应使用相应的HeartbeatResponse消息进行应答。
However, a HeartbeatRequest message SHOULD NOT be sent during handshakes. If a handshake is initiated while a HeartbeatRequest is still in flight, the sending peer MUST stop the DTLS retransmission timer for it. The receiving peer SHOULD discard the message silently, if it arrives during the handshake. In case of DTLS, HeartbeatRequest messages from older epochs SHOULD be discarded.
但是，握手时不应发送HeartbeatRequest消息。如果在HeartBeat请求仍在运行时启动握手，则发送对等方必须停止该请求的DTLS重传计时器。如果消息在握手过程中到达，则接收对等方应无声地丢弃该消息。对于DTL，应该丢弃来自旧时代的HeartbeatRequest消息。
There MUST NOT be more than one HeartbeatRequest message in flight at a time. A HeartbeatRequest message is considered to be in flight until the corresponding HeartbeatResponse message is received, or until the retransmit timer expires.
一次传输的HeartbeatRequest消息不得超过一条。在收到相应的HeartbeatResponse消息或重传计时器过期之前，HeartbeatRequest消息被视为处于飞行状态。
When using an unreliable transport protocol like the Datagram Congestion Control Protocol (DCCP) or UDP, HeartbeatRequest messages MUST be retransmitted using the simple timeout and retransmission scheme DTLS uses for flights as described in Section 4.2.4 of [RFC6347]. In particular, after a number of retransmissions without receiving a corresponding HeartbeatResponse message having the expected payload, the DTLS connection SHOULD be terminated. The threshold used for this SHOULD be the same as for DTLS handshake messages. Please note that after the timer supervising a HeartbeatRequest messages expires, this message is no longer considered in flight. Therefore, the HeartbeatRequest message is eligible for retransmission. The retransmission scheme, in combination with the restriction that only one HeartbeatRequest is allowed to be in flight, ensures that congestion control is handled appropriately in case of the transport protocol not providing one, like in the case of DTLS over UDP.
当使用数据报拥塞控制协议（DCCP）或UDP等不可靠传输协议时，必须使用DTLS用于航班的简单超时和重传方案（如[RFC6347]第4.2.4节所述）重传HeartbeatRequest消息。特别地，在多次重传之后，在没有接收到具有预期有效载荷的相应HeartbeatResponse消息的情况下，应该终止DTLS连接。用于此操作的阈值应与DTLS握手消息的阈值相同。请注意，监控HeartbeatRequest消息的计时器过期后，此消息将不再在飞行中考虑。因此，HeartbeatRequest消息有资格重新传输。重传方案与仅允许一个HeartBeat请求飞行的限制相结合，确保在传输协议不提供拥塞控制的情况下（如UDP上的DTLS的情况）适当地处理拥塞控制。
When using a reliable transport protocol like the Stream Control Transmission Protocol (SCTP) or TCP, HeartbeatRequest messages only need to be sent once. The transport layer will handle retransmissions. If no corresponding HeartbeatResponse message has been received after some amount of time, the DTLS/TLS connection MAY be terminated by the application that initiated the sending of the HeartbeatRequest message.
当使用流控制传输协议（SCTP）或TCP等可靠传输协议时，HeartbeatRequest消息只需发送一次。传输层将处理重传。如果在一段时间后没有收到相应的HeartbeatResponse消息，则发起发送HeartbeatRequest消息的应用程序可能会终止DTLS/TLS连接。
The Heartbeat protocol messages consist of their type and an arbitrary payload and padding.
心跳协议消息由其类型、任意负载和填充组成。
struct {
HeartbeatMessageType type;
uint16 payload_length;
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;
struct {
HeartbeatMessageType type;
uint16 payload_length;
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;
The total length of a HeartbeatMessage MUST NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066].
当按照[RFC6066]中的定义协商时，HeartbeatMessage的总长度不得超过2^14或最大片段长度。
type: The message type, either heartbeat_request or heartbeat_response.
类型：消息类型，心跳\u请求或心跳\u响应。
payload_length: The length of the payload.
有效载荷长度：有效载荷的长度。
payload: The payload consists of arbitrary content.
有效负载：有效负载由任意内容组成。
padding: The padding is random content that MUST be ignored by the receiver. The length of a HeartbeatMessage is TLSPlaintext.length for TLS and DTLSPlaintext.length for DTLS. Furthermore, the length of the type field is 1 byte, and the length of the payload_length is 2. Therefore, the padding_length is TLSPlaintext.length - payload_length - 3 for TLS and DTLSPlaintext.length - payload_length - 3 for DTLS. The padding_length MUST be at least 16.
填充：填充是接收器必须忽略的随机内容。HeartbeatMessage的长度为TLS的TLSPlaintext.length和DTLS的DTLSPlaintext.length。此外，类型字段的长度为1字节，有效负载长度为2字节。因此，对于TLS，padding_长度为TLSPlaintext.length-payload_length-3，对于DTL，padding_长度为DTLSPlaintext.length-payload_length-3。填充长度必须至少为16。
The sender of a HeartbeatMessage MUST use a random padding of at least 16 bytes. The padding of a received HeartbeatMessage message MUST be ignored.
HeartbeatMessage的发件人必须使用至少16字节的随机填充。必须忽略接收到的HeartbeatMessage的填充。
If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently.
如果收到的HeartbeatMessage的有效负载长度太大，则必须无声地丢弃收到的HeartbeatMessage。
When a HeartbeatRequest message is received and sending a HeartbeatResponse is not prohibited as described elsewhere in this document, the receiver MUST send a corresponding HeartbeatResponse message carrying an exact copy of the payload of the received HeartbeatRequest.
当接收到HeartbeatRequest消息且发送HeartbeatResponse未被禁止（如本文档其他部分所述）时，接收方必须发送相应的HeartbeatResponse消息，其中包含所接收HeartbeatRequest有效负载的准确副本。
If a received HeartbeatResponse message does not contain the expected payload, the message MUST be discarded silently. If it does contain the expected payload, the retransmission timer MUST be stopped.
如果收到的HeartbeatResponse消息不包含预期的有效负载，则必须以静默方式丢弃该消息。如果它确实包含预期的有效负载，则必须停止重传计时器。
Each endpoint sends HeartbeatRequest messages at a rate and with the padding required for the particular use case. The endpoint should not expect its peer to send HeartbeatRequests. The directions are independent.
每个端点以特定用例所需的速率和填充发送HeartbeatRequest消息。端点不应期望其对等方发送请求。方向是独立的。
DTLS performs path MTU discovery as described in Section 4.1.1.1 of [RFC6347]. A detailed description of how to perform path MTU discovery is given in [RFC4821]. The necessary probe packets are the HeartbeatRequest messages.
DTLS按照[RFC6347]第4.1.1.1节所述执行路径MTU发现。[RFC4821]中详细描述了如何执行路径MTU发现。必要的探测数据包是HeartbeatRequest消息。
This method of using HeartbeatRequest messages for DTLS is similar to the one for the Stream Control Transmission Protocol (SCTP) using the padding chunk (PAD-chunk) defined in [RFC4820].
这种为DTL使用HeartbeatRequest消息的方法类似于使用[RFC4820]中定义的填充块（PAD chunk）的流控制传输协议（SCTP）的方法。
Sending HeartbeatRequest messages allows the sender to make sure that it can reach the peer and the peer is alive. Even in the case of TLS/TCP, this allows a check at a much higher rate than the TCP keep-alive feature would allow.
发送HeartbeatRequest消息允许发送方确保它可以到达对等方并且对等方处于活动状态。即使在TLS/TCP的情况下，这也允许以比TCP保持活动特性更高的速率进行检查。
Besides making sure that the peer is still reachable, sending HeartbeatRequest messages refreshes the NAT state of all involved NATs.
除了确保对等方仍然可以访问之外，发送HeartbeatRequest消息还会刷新所有相关NAT的NAT状态。
HeartbeatRequest messages SHOULD only be sent after an idle period that is at least multiple round-trip times long. This idle period SHOULD be configurable up to a period of multiple minutes and down to a period of one second. A default value for the idle period SHOULD be configurable, but it SHOULD also be tunable on a per-peer basis.
HeartbeatRequest消息只应在至少多个往返时间的空闲期之后发送。此空闲时间应可配置为最多几分钟，最多一秒。空闲时间的默认值应该是可配置的，但它也应该可以在每个对等机的基础上进行调整。
IANA has assigned the heartbeat content type (24) from the "TLS ContentType Registry" as specified in [RFC5246]. The reference is to RFC 6520.
IANA已根据[RFC5246]中的规定，从“TLS ContentType注册表”分配心跳信号内容类型（24）。参考RFC 6520。
IANA has created and now maintains a new registry for Heartbeat Message Types. The message types are numbers in the range from 0 to 255 (decimal). IANA has assigned the heartbeat_request (1) and the heartbeat_response (2) message types. The values 0 and 255 should be reserved. This registry uses the Expert Review policy as described in [RFC5226]. The reference is to RFC 6520.
IANA已经创建并维护了心跳消息类型的新注册表。消息类型是0到255（十进制）范围内的数字。IANA已分配心跳\u请求（1）和心跳\u响应（2）消息类型。应保留值0和255。该注册中心使用[RFC5226]中所述的专家评审政策。参考RFC 6520。
IANA has assigned the heartbeat extension type (15) from the TLS "ExtensionType Values" registry as specified in [RFC5246]. The reference is to RFC 6520.
IANA已根据[RFC5246]中的规定，从TLS“ExtensionType Values”注册表中分配心跳扩展类型（15）。参考RFC 6520。
IANA has created and now maintains a new registry for Heartbeat Modes. The modes are numbers in the range from 0 to 255 (decimal). IANA has assigned the peer_allowed_to_send (1) and the peer_not_allowed_to_send (2) modes. The values 0 and 255 should be reserved. This registry uses the Expert Review policy as described in [RFC5226]. The reference is to RFC 6520.
IANA已经创建并维护了心跳模式的新注册表。模式是0到255（十进制）范围内的数字。IANA已将对等方允许的模式分配给发送（1）和对等方不允许的模式分配给发送（2）。应保留值0和255。该注册中心使用[RFC5226]中所述的专家评审政策。参考RFC 6520。
The security considerations of [RFC5246] and [RFC6347] apply to this document. This document does not introduce any new security considerations.
[RFC5246]和[RFC6347]的安全注意事项适用于本文件。本文档没有引入任何新的安全注意事项。
The authors wish to thank Pasi Eronen, Adrian Farrel, Stephen Farrell, Adam Langley, Nikos Mavrogiannopoulos, Tom Petch, Eric Rescorla, Peter Saint-Andre, and Juho Vaehae-Herttua for their invaluable comments.
作者希望感谢帕西·艾罗宁、阿德里安·法雷尔、斯蒂芬·法雷尔、亚当·兰利、尼科斯·马夫罗吉安诺普洛斯、汤姆·佩奇、埃里克·雷斯科拉、彼得·圣安德烈和朱霍·瓦哈·赫图亚的宝贵评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436]Jungmaier，A.，Rescorla，E.，和M.Tuexen，“流控制传输协议上的传输层安全”，RFC 3436，2002年12月。
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007.
[RFC4820]Tuexen，M.，Stewart，R.，和P.Lei，“流控制传输协议（SCTP）的填充块和参数”，RFC 4820，2007年3月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008.
[RFC5238]Phelan，T.，“数据报拥塞控制协议（DCCP）上的数据报传输层安全性（DTLS）”，RFC 5238，2008年5月。
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.
[RFC6083]Tuexen，M.，Seggelmann，R.，和E.Rescorla，“流控制传输协议（SCTP）的数据报传输层安全性（DTLS）”，RFC 6083，2011年1月。
Authors' Addresses
作者地址
Robin Seggelmann Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE
罗宾.塞格曼明斯特应用科学大学斯坦福德德39 48565
EMail: seggelmann@fh-muenster.de
EMail: seggelmann@fh-muenster.de
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE
米迦勒TuxEN明斯特应用科学大学StigalddSTR。斯坦福德德39 48565
EMail: tuexen@fh-muenster.de
EMail: tuexen@fh-muenster.de
Michael Glenn Williams GWhiz Arts & Sciences 2885 Denise Court Newbury Park, CA, 91320 USA
迈克尔·格伦·威廉姆斯·格希兹艺术与科学2885美国加利福尼亚州纽伯里公园丹尼斯宫，邮编：91320
EMail: michael.glenn.williams@gmail.com
EMail: michael.glenn.williams@gmail.com