Independent Submission                                           F. Gont
Request for Comments: 7943                        SI6 Networks / UTN-FRH
Category: Informational                                           W. Liu
ISSN: 2070-1721                                      Huawei Technologies
                                                          September 2016

A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)




This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration.

このドキュメントでは、一時的でないIPv6アドレスをDHCPv6クライアントにリースするときに、IPv6の動的ホスト構成プロトコル(DHCPv6)サーバーで使用できるIPv6インターフェイス識別子を選択する方法について説明します。この方法は、既存のDHCPv6仕様を更新する必要のないDHCPv6サーバー側アルゴリズムです。前述の方法により、複数のDHCPv6サーバーまたはDHCPv6サーバーの再インストールがある場合でも、各サブネット内で安定したアドレスが得られます。これは、IPv6ステートレスアドレス自動構成用にRFC 7217で指定された方法のDHCPv6バリアントです。



A predecessor to this document was earlier a working group document in the DHC WG. The WG decided to stop further work in this area because such work was not considered useful.

この文書の前身は、以前はDHC WGのワーキンググループ文書でした。 WGは、このような作業が有用であるとは考えられなかったため、この分野でのさらなる作業を停止することを決定しました。

The proposal described in this document has an unaddressed failure case that makes it unsuitable for use as the mechanism to provide the claimed failover features for DHCPv6 servers. Specifically, when a DHCPv6 client DECLINEs a provided address there is no recovery mechanism described that will result in the DHCPv6 client obtaining a working IPv6 address.


Status of This Memo


This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Applicability and Design Goals  . . . . . . . . . . . . . . .   3
   3.  Method Specification  . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10
1. Introduction
1. はじめに

The benefits of stable IPv6 addresses are discussed in [RFC7721]. Providing address stability across server reinstallations or when a database of previous DHCPv6 address leases is unavailable is of use not only when a DHCPv6 server must be reinstalled or the address-lease database becomes corrupted, but is also of use when implementation constraints (e.g., a DHCPv6 server implementation on an embedded device) make it impossible for a DHCPv6 server implementation to maintain a database of previous DHCPv6 address leases. Additionally, [RFC7031] describes scenarios where multiple DHCPv6 servers are required to run in such a way as to provide increased availability in case of server failures.


This document describes a method for selecting IPv6 Interface Identifiers that can be employed by DHCPv6 servers when leasing non-temporary IPv6 addresses to DHCPv6 clients (i.e., to be employed with IA_NA options). This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method has the following properties:


o The resulting IPv6 addresses remain stable within each subnet for the same network interface of the same client, even when different DHCPv6 servers (implementing this specification) are employed.

o 結果のIPv6アドレスは、異なるDHCPv6サーバー(この仕様を実装)が使用されている場合でも、同じクライアントの同じネットワークインターフェイスの各サブネット内で安定したままです。

o Predicting the IPv6 addresses that will be generated by the method specified in this document, even with knowledge of the IPv6 addresses generated for other nodes within the same network, becomes very difficult.

o このドキュメントで指定された方法で生成されるIPv6アドレスを予測することは、同じネットワーク内の他のノードに対して生成されたIPv6アドレスの知識があっても、非常に困難になります。

The method specified in this document achieves the aforementioned properties by means of a calculated technique as opposed to, e.g., state sharing among DHCPv6 servers. This approach has already been suggested in [RFC7031]. We note that the method described in this document is essentially a DHCPv6 version of the "Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217].


2. Applicability and Design Goals
2. 適用性と設計目標

This document simply describes one possible approach for selecting IPv6 Interface Identifiers to be employed by DHCPv6 servers when leasing non-temporary IPv6 addresses to DHCPv6 clients, with the following properties:


o The resulting IPv6 addresses remain stable within each subnet for the same network interface of the same client.

o 結果のIPv6アドレスは、同じクライアントの同じネットワークインターフェイスの各サブネット内で安定したままです。

o The resulting IPv6 addresses cannot be predicted by an attacker without knowledge of a secret key.

o 結果のIPv6アドレスは、秘密鍵を知らない限り、攻撃者が予測することはできません。

o The resulting IPv6 addresses remain stable across DHCPv6 server reinstallations, or even if a database of previous DHCPv6 address leases is not available.

o 結果のIPv6アドレスは、DHCPv6サーバーの再インストール後、または以前のDHCPv6アドレスリースのデータベースが利用できない場合でも安定したままです。

o The resulting IPv6 addresses remain stable when different DHCPv6 servers (implementing this specification) are employed on the same network.

o 異なるDHCPv6サーバー(この仕様を実装)が同じネットワークで使用されている場合、結果のIPv6アドレスは安定したままです。

We note that the algorithm specified in this document employs a (lightweight) calculated technique (as opposed to, e.g., state sharing among DHCPv6 servers) to achieve address stability in scenarios where multiple DHCPv6 servers are required to run in such a way as to provide increased availability, without the need of an additional protocol to synchronize the lease databases of DHCPv6 servers.


Finally, we note that the algorithm in this document is only meant to mitigate IPv6 address-based location tracking, device-specific vulnerability exploitation, and host scanning (please see [RFC7721]). There are a number of ways in which DHCPv6 affects user privacy, which the algorithm specified in this document does not mitigate (and does not intend to). Please see [RFC7844] for a comprehensive discussion of how DHCPv6 may affect user privacy.

最後に、このドキュメントのアルゴリズムは、IPv6アドレスベースのロケーショントラッキング、デバイス固有の脆弱性の悪用、およびホストスキャン([RFC7721]を参照)を軽減することのみを目的としていることに注意してください。 DHCPv6がユーザーのプライバシーに影響を与える方法はいくつかありますが、このドキュメントで指定されているアルゴリズムでは軽減されません(意図されていません)。 DHCPv6がユーザーのプライバシーに与える影響の包括的な説明については、[RFC7844]を参照してください。

3. Method Specification
3. メソッド仕様

Implementations should provide the means for a system administrator to enable or disable the use of this algorithm for generating IPv6 addresses.


A DHCPv6 server implementing this specification must select the IPv6 addresses to be leased with the following algorithm:


1. Compute a random (but stable) identifier with the expression:

1. 次の式でランダムな(ただし安定した)識別子を計算します。

RID = F(Prefix | Client_DUID | IAID | Counter | secret_key)

RID = F(プレフィックス| Client_DUID | IAID |カウンター| secret_key)



RID: Random (but stable) Identifier


F(): A Pseudorandom Function (PRF) that must not be computable from the outside (without knowledge of the secret key). F() must also be difficult to reverse, such that it resists attempts to obtain the secret key, even when given samples of the output of F() and knowledge or control of the other input parameters. F() should produce an output of at least 64 bits. F() could be implemented as a cryptographic hash of the concatenation of each of the function parameters. The default algorithm to be employed for F() should be SHA-256 [FIPS-SHS]. An implementation may provide the means for selecting other algorithms. Note: Message Digest 5 (MD5) [RFC1321] is considered unacceptable for F() [RFC6151].

F():(秘密鍵の知識なしで)外部から計算可能であってはならない擬似ランダム関数(PRF)。 F()は、F()の出力のサンプルと他の入力パラメーターの知識または制御が与えられた場合でも、秘密鍵を取得しようとする試みに抵抗するように、逆にするのが困難でなければなりません。 F()は、少なくとも64ビットの出力を生成する必要があります。 F()は、各関数パラメーターの連結の暗号化ハッシュとして実装できます。 F()に使用されるデフォルトのアルゴリズムはSHA-256 [FIPS-SHS]である必要があります。実装は、他のアルゴリズムを選択する手段を提供します。注:メッセージダイジェスト5(MD5)[RFC1321]は、F()[RFC6151]では受け入れられないと見なされます。

Prefix: The prefix employed for the local subnet, as a 128-bit unsigned integer in network byte order (with the unused bits set to 0). If multiple servers operate on the same network to provide increased availability, all such DHCPv6 servers must be configured with the same Prefix. It is the administrator's responsibility that the aforementioned requirement is met.


|: An operator representing "concatenation".


Client_DUID: The DHCPv6 Unique Identifier (DUID) value contained in the Client Identifier option received in the DHCPv6 client message. The DUID can be treated as an array of 8-bit unsigned integers.

Client_DUID:DHCPv6クライアントメッセージで受信したクライアント識別子オプションに含まれるDHCPv6一意識別子(DUID)値。 DUIDは、8ビットの符号なし整数の配列として扱うことができます。

IAID: The Identity Association Identifier (IAID) value contained in the IA_NA option received in the client message. It must be interpreted as a 32-bit unsigned integer in network byte order.


secret_key: A secret key configured by the DHCPv6 server administrator, which must not be known by the attacker. It must be encoded as an array of 8-bit unsigned integers. An implementation of this specification must provide an interface for viewing and changing the secret key. All DHCPv6 servers leasing addresses from the same address range must employ the same secret key.

secret_key:DHCPv6サーバー管理者が設定した秘密キー。攻撃者に知られてはいけません。 8ビットの符号なし整数の配列としてエンコードする必要があります。この仕様の実装は、秘密鍵を表示および変更するためのインターフェースを提供する必要があります。同じアドレス範囲からアドレスをリースするすべてのDHCPv6サーバーは、同じ秘密鍵を使用する必要があります。

Counter: A 32-bit unsigned integer in network byte order that is employed to resolve address conflicts. It must be initialized to 0.

カウンター:アドレスの競合を解決するために使用されるネットワークバイトオーダーの32ビット符号なし整数。 0に初期化する必要があります。

2. A candidate IPv6 address (IPV6_ADDR) to be leased is obtained by concatenating as many bits as necessary from the RID value computed in the previous step (starting from the least significant bit) to the Prefix employed in the equation above, as follows:

2. リースされるIPv6アドレス(IPV6_ADDR)の候補は、前の手順で計算されたRID値から(最下位ビットから開始して)必要な数のビットを上記の式で使用されるプレフィックスに次のように連結することによって取得されます。

        IPV6_ADDR = IPV6_ADDR_LOW +
                    RID % (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1)



IPV6_ADDR: The candidate IPv6 address to be leased.


IPV6_ADDR_HI: An IPv6 address specifying the upper boundary of the IPv6 address pool from which the DHCPv6 server leases IPv6 addresses. If an address range is not explicitly selected, IPV6_ADDR_HI must be set to the IPv6 address from the Prefix (see the expression above) that has all of the bits of the Interface Identifier set to 1.


IPV6_ADDR_LOW: An IPv6 address specifying the lower boundary of the IPv6 address pool from which the DHCPv6 server leases IPv6 addresses. If an address range is not explicitly selected, IPV6_ADDR_LOW must be set to the IPv6 address from the Prefix (see the expression above) that has all of the bits of the Interface Identifier set to 0.


3. The Interface Identifier of the selected IPv6 address must be compared against the reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]. In the event that an unacceptable identifier has been generated, the Counter variable should be incremented by 1, and a new IPv6 address should be computed with the updated Counter value.

3. 選択したIPv6アドレスのインターフェース識別子は、予約済みのIPv6インターフェース識別子[RFC5453] [IANA-RESERVED-IID]と比較する必要があります。許容できない識別子が生成された場合、Counter変数を1増やし、新しいIPv6アドレスを更新されたCounter値で計算する必要があります。

4. If the resulting address is not available (e.g., there is a conflicting binding), the DHCPv6 server should increment the Counter variable, and a new Interface Identifier and IPv6 address should be computed with the updated Counter value.

4. 結果のアドレスが使用できない場合(たとえば、バインディングが競合している場合)、DHCPv6サーバーはCounter変数をインクリメントし、新しいインターフェイス識別子とIPv6アドレスを更新されたCounter値で計算する必要があります。

This document requires that SHA-256 be the default function to be used for F(), such that (all other configuration parameters being the same) different implementations of this specification result in the same IPv6 addresses.


Including the Prefix in the PRF computation causes the Interface Identifier to be different for each address from a different prefix leased to the same client. This mitigates the correlation of activities of multihomed nodes (since each of the corresponding addresses will employ a different Interface Identifier), host tracking (since the network prefix, and therefore the resulting Interface Identifier, will change as the node moves from one network to another), and any other attacks that benefit from predictable Interface Identifiers [RFC7721].

PRF計算にプレフィックスを含めると、同じクライアントにリースされる異なるプレフィックスからのアドレスごとにインターフェイス識別子が異なります。これにより、マルチホームノードのアクティビティの相関が緩和されます(対応するアドレスごとに異なるインターフェイス識別子が使用されるため)、ホストトラッキング(ネットワークプレフィックス、したがって結果のインターフェイス識別子がノードがネットワーク間を移動するにつれて変化するため) )、および予測可能なインターフェース識別子[RFC7721]の恩恵を受けるその他の攻撃。

As required by [RFC3315], an IAID is associated with each of the client's network interfaces and is consistent across restarts of the DHCPv6 client.


The Counter parameter provides the means to intentionally cause this algorithm to produce different IPv6 addresses (all other parameters being the same). This can be of use to resolve address conflicts (e.g., the resulting address having a conflicting binding).


Note that the result of F() in the algorithm above is no more secure than the secret key. If an attacker is aware of the PRF that is being used by the DHCPv6 server (which we should expect), and the attacker can obtain enough material (i.e., addresses generated by the DHCPv6 server), the attacker may simply search the entire secret-key space to find matches. To protect against this, the secret key should be of at least 128 bits. Key lengths of at least 128 bits should be adequate.


Providing a mechanism to display and change the secret_key is crucial for having different DHCPv6 servers produce the same IPv6 addresses and for causing a replacement system to generate the same IPv6 addresses as the system being replaced. We note that since the privacy of the scheme specified in this document relies on the secrecy of the secret_key parameter, implementations should constrain access to the secret_key parameter to the extent practicable (e.g., require superuser privileges to access it). Furthermore, in order to prevent leakages of the secret_key parameter, it should not be used for any other purposes than being a parameter to the scheme specified in this document.


We note that all of the bits in the resulting Interface Identifiers are treated as "opaque" bits [RFC7136]. For example, the universal/ local bit of Modified EUI-64 format identifiers is treated as any other bit of such identifier.

結果として得られるインターフェイス識別子のすべてのビットは、「不透明な」ビットとして扱われることに注意してください[RFC7136]。たとえば、Modified EUI-64形式の識別子のユニバーサル/ローカルビットは、そのような識別子の他のビットとして扱われます。

4. Security Considerations
4. セキュリティに関する考慮事項

The method specified in this document results in IPv6 Interface Identifiers (and hence IPv6 addresses) that do not follow any specific pattern. Thus, attacks that rely on predictable Interface Identifiers (such as [RFC7707]) are mitigated.


The method specified in this document neither mitigates nor exacerbates the security considerations for DHCPv6 discussed in [RFC3315] and does not mitigate a range of other privacy implications associated with DHCPv6. Please read [RFC7844] for a comprehensive assessment of the privacy implications of DHCPv6.

このドキュメントで指定されている方法は、[RFC3315]で説明されているDHCPv6のセキュリティに関する考慮事項を緩和または悪化させることはなく、DHCPv6に関連するその他のプライバシーへの影響を軽減することもありません。 DHCPv6のプライバシーへの影響の包括的な評価については、[RFC7844]を読んでください。

Finally, we note that an attacker that is able to attach to each of the links to which the victim attaches would still be able to correlate the activities of the victim across networks.


5. References
5. 参考文献
5.1. Normative References
5.1. 引用文献

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

[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6(DHCPv6)"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<>。

[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, DOI 10.17487/RFC5453, February 2009, <>.

[RFC5453] Krishnan、S。、「Reserved IPv6 Interface Identifiers」、RFC 5453、DOI 10.17487 / RFC5453、2009年2月、<>。

[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <>.

[RFC7136] Carpenter、B。およびS. Jiang、「Significance of IPv6 Interface Identifiers」、RFC 7136、DOI 10.17487 / RFC7136、2014年2月、<>。

5.2. Informative References
5.2. 参考引用

[FIPS-SHS] Federal Information Processing Standards (FIPS), "Secure Hash Standard (SHS)", FIPS 180-4, August 2015, < fips-180-4.pdf>.

[FIPS-SHS]連邦情報処理標準(FIPS)、「Secure Hash Standard(SHS)」、FIPS 180-4、2015年8月、< fips -180-4.pdf>。

[IANA-RESERVED-IID] IANA, "Reserved IPv6 Interface Identifiers", <>.

[IANA-RESERVED-IID] IANA、「予約済みIPv6インターフェース識別子」、<>。

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <>.

[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<>。

[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <>.

[RFC6151]ターナーS.およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、DOI 10.17487 / RFC6151、2011年3月、<http://www.rfc->。

[RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Requirements", RFC 7031, DOI 10.17487/RFC7031, September 2013, <>.

[RFC7031] Mrugalski、T。およびK. Kinnear、「DHCPv6フェイルオーバー要件」、RFC 7031、DOI 10.17487 / RFC7031、2013年9月、<>。

[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <>.

[RFC7217] Gont、F。、「IPv6ステートレスアドレス自動構成(SLAAC)を使用してセマンティックに不透明なインターフェース識別子を生成する方法」、RFC 7217、DOI 10.17487 / RFC7217、2014年4月、< / info / rfc7217>。

[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, <>.

[RFC7707] Gont、F。およびT. Chown、「IPv6ネットワークでのネットワーク偵察」、RFC 7707、DOI 10.17487 / RFC7707、2016年3月、<>。

[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <>.

[RFC7721]クーパー、A。、ゴント、F。、およびD.ターラー、「IPv6アドレス生成メカニズムのセキュリティとプライバシーに関する考慮事項」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<http://www.rfc->。

[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <>.

[RFC7844] Huitema、C.、Mrugalski、T。、およびS. Krishnan、「DHCPクライアントの匿名プロファイル」、RFC 7844、DOI 10.17487 / RFC7844、2016年5月、< info / rfc7844>。



This document is based on [RFC7217], authored by Fernando Gont.

このドキュメントは、Fernando Gontによって作成された[RFC7217]に基づいています。

The authors would like to thank Marc Blanchet, Stephane Bortzmeyer, Tatuya Jinmei, Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jim Schaad, Jean-Francois Tremblay, Tina Tsou, and Bernie Volz for providing valuable comments on earlier draft versions of this documents.

このドキュメントの以前のドラフトバージョンに貴重なコメントを提供してくれたMarc Blanchet、Stephane Bortzmeyer、Tatuya Jinmei、Andre Kostur、Tomek Mrugalski、Hosnieh Rafiee、Jim Schaad、Jean-Francois Tremblay、Tina Tsou、およびBernie Volzに感謝します。

The authors would like to thank Ted Lemon, who kindly answered some DHCPv6-related questions, and Nevil Brownlee for his guidance while pursuing this document.

著者は、DHCPv6関連のいくつかの質問に親切に回答してくれたTed Lemonと、このドキュメントを追求している間のガイダンスを提供してくれたNevil Brownleeに感謝します。

Fernando Gont would like to thank Nelida Garcia and Guillermo Gont for their love and support, and Diego Armando Maradona for his magic and inspiration.


Authors' Addresses


Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina

フェルナンドゴンSI6ネットワーク/ UTN-FRHエヴァリストキャリーゴ2644ブエノスアイレス州ハエド1706アルゼンチン

   Phone: +54 11 4650 8472

Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 China

will(Shu成)l IU hu Aはテクノロジー禁止の日であり、長いだけの地区は非常に現実的です518129中国