One document matched: draft-hain-6to4-scaling-00.txt
NGtrans T. Hain
Internet Draft Microsoft
Document: draft-hain-6to4-scaling-00.txt July 2000
Category:
6to4-relay discovery and scaling
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The mechanism for 6to4-router scaling described in the 6to4 draft
[2][6to4] raises concerns when the matrix of IPv4 connected systems,
communicating across to the native IPv6 connected systems, are on
the order of tens to hundreds of millions. This document will
address those concerns, offer additional mechanisms for resolving
them, and identify the scenario for link-local addressing postulated
in section 3.1.
Hain Expires December 2000 1
6to4 router discovery and scaling July 2000
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................2
Terms..............................................................2
Overview and assumptions...........................................3
Scenarios..........................................................5
Fig. 1...........................................................5
Sequence Scenario 1:.............................................6
Sequence Scenario 2:.............................................7
NS syntax..........................................................9
NA syntax..........................................................9
Redirect syntax...................................................10
Protection from random redirects:...............................11
Additional Requirements...........................................11
Additional Thoughts...............................................12
Security Considerations...........................................12
References........................................................12
Acknowledgments...................................................13
Author's Addresses................................................13
Conventions used in this document
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 RFC-2119 [3].
Terms
(expanding slightly on the definitions in [6to4])
6to4-router: an IPv6 router supporting a 6to4 pseudo-interface. It
is normally the border router between an IPv6 site and a wide-area
IPv4 network. When not acting as a relay, it advertises
[2002:IPv4::/48] as an attached prefix on IPv6 enabled interfaces.
Relay router: a 6to4-router configured to support transit routing
between 6to4 addresses and native IPv6 addresses. Advertises the
[2002::/16] as an attached prefix on native IPv6 enabled interfaces.
(referred to as 6to4-relay in this document)
6to4 normal host: an IPv6 host, which happens to have at least one
6to4 address learned from a 6to4-router. In all other respects it is
a standard IPv6 host.
6to4 integrated host: an IPv6 host that generates at least one 6to4
address and supporting 6to4 pseudo-interface from an IPv4 address.
It interacts directly with relays, but in all other respects it is a
standard IPv6 host.
Hain Expires December 2000 2
6to4 router discovery and scaling July 2000
Overview and assumptions
The intent of this approach is to use the mechanism defined in
[6to4] as a simplifier for providing IPv6 services to any node with
a public IPv4 address. (While IPv4-compatible IPv6 addresses would
be another option, there have been questions raised related to their
use and the scaling impact on the IPv6 routing tables.) The
technical aspects of creating the appropriate addresses are not an
issue, but there is an area of concern related to discovery of the
path from 6to4 nodes to native-IPv6 nodes. Several schemes have been
proposed, and the approach described here does not preclude any of
them. What it does is provide an alternative that automates the
process on a massive scale, without requiring the 6to4 routers to
participate directly in a global routing process.
One way to look at this approach is an automated tunnel broker that
is tied to the current routing infrastructure. Existing tunnel
broker models expect manual interaction and basically set up a
default route to the entire native IPv6 infrastructure. If the
native IPv6 network partitions, the communications will fail even
though the IPv4 network is intact. The approach presented here would
theoretically allow for islands of native IPv6 to exist around the
edge of the IPv4 cloud, as long as the regional relays know the
current prefix to IPv4 mapping for the relays.
Another way to look at this approach is a default route that only
handles one packet per prefix, and then redirects each node directly
attached to the IPv4 network to the appropriate native-IPv6-ISP
6to4-relay for subsequent packets.
The default route approach works because from the perspective of the
6to4-router (or integrated host), the entire IPv4 Internet appears
to be a single-subnet link-layer. While section 3.1 of [6to4]
discusses the formation of addresses in a link-local context, it
questions the utility of such addresses. The mechanism described
here answers the question by taking advantage of the format for
communicating with a well-known relay, as well as in the redirect
messages sent by relays. A final point to make is that in addition
to appearing as a single link-layer, the IPv4 Internet does not
provide multicast to all points, so it should be considered an NBMA
network. Since the IPv4 Internet appears to be a single link to 6to4
nodes, all rules in section 8 of [4][ND] apply to redirects
described here, EXCEPT the one at the end of 8.2 that prohibits
routers from updating routes based on redirects. It should also be
noted that part of a previously reserved field is now defined.
A basic assumption is that a 6to4 based IPv6 deployment will not
rely on ANY support from IPv4 only ISP's. If a 6to4-relay (willing
to take the traffic) exists, a site 6to4-router may be configured to
use that path as the default route to the native IPv6 infrastructure
through a tunnel broker, or other means. If there is no configured
relay, the default behavior of 6to4-routers SHOULD be to use a well-
Hain Expires December 2000 3
6to4 router discovery and scaling July 2000
known starting point to find a 6to4-relay that will get it to the
native IPv6 endpoint.
Another assumption is that each ISP providing native IPv6 services
will be motivated to provide a relay service for their customers to
communicate with 6to4 sites. At the same time, these ISPs will
generally not want to be the 'default' route between 6to4 & native
IPv6 infrastructures. They will also not be excited about managing a
massive manually configured tunnel array (no matter which end the
manual effort is applied to). Once a 6to4-router (integrated host)
acquires a prefix to relay mapping, it SHOULD send NS messages to
maintain the mapping until idle for 2 lifetimes. To aid with
scaling, there is no need for the relay to maintain a mapping to the
6to4-router (integrated host) as the required information is in the
destination address of each packet header.
Consumer systems (ie:dial-up) will be completely automated 6to4
integrated hosts. To make this automation work, a well-known relay
service needs to exist and be capable of handling greater than 10M
clients. This results in scaling issues that are comparable to the
DNS root.
Maintaining a static database with full IPv6 addresses of the
current ISP relays is operationally complex. As only the IPv4
address are required when using link-local [FE80::IPv4] format
addresses, this has better scaling properties for database
maintenance. (The Anycast address [2002:IPv4::0] would be a
comparable alternative, but redirect messages require use of a link-
local address).
The regional access relays described below are currently assumed to
be geographical, but the native-IPv6-ISP ones they redirect to are
assumed to be topologically near the native IPv6 end.
Hain Expires December 2000 4
6to4 router discovery and scaling July 2000
Scenarios
1. A Consumer system dials into their preferred ISP and only
receives IPv4 service. Using the 6to4 mechanisms as defined, the
system creates IPv6 addresses for its interface. Later an
application attempts to connect to a system that is connected to a
native IPv6 network (non-2002::). The consumer system forwards the
first packet to the well-known relay 6to4-relay.ipv6.org, and
verifies the redirect it receives for the destination prefix.
Further communications are directed to the native-IPv6-ISP 6to4-
relay. NS messages SHOULD be sent to the native-IPv6-ISP 6to4-relay
to maintain this Prefix / IPv4 address / Lifetime mapping until idle
for at least two lifetimes.
2. An IPv6 only system initiates a connection to a 6to4 web site.
The native-IPv6-ISP 6to4-relay extracts the IPv4 address from the
destination IPv6 address, and tunnels per the 6to4 specification.
The 6to4-router will use the response from the web site to establish
the mapping between the native-IPv6 prefix, and its 6to4-relay via
the well-known 6to4-relay. NS messages SHOULD be sent to the native-
IPv6-ISP 6to4-relay to maintain this Prefix / IPv4 address /
Lifetime mapping information until idle for at least two lifetimes.
----- ------------
| | | 6to4-relay.|
| DNS | |AR.ipv6.org |
----- ------------
| |
------------- ------------ ----------- ----------
| Native IPv6 | | 6to4-relay | | IPv4 only | | Consumer |
| system |-/-| IPv6 ISP |---| Internet |-/-| system |
------------- ------------ ----------- ----------
|
------------- -----
| 6to4-router | | Web |
| |---| site|
------------- -----
-----
Fig. 1
Hain Expires December 2000 5
6to4 router discovery and scaling July 2000
Sequence Scenario 1:
1) The 6to4 process in a consumer system automatically looks up
the IPv4 address of the well-known relay 6to4-relay.ipv6.org
for any non-2002:: destination that does not match a prefix
in the routing cache, using IPv4.
2) DNS returns a Cname based on the RIR of the requestors IPv4.
3) The 6to4 process then automatically looks up 6to4-
relay.RIR.ipv6.org
4) DNS returns a traditional IPv4 round-robin for relays per
region.
5) The 6to4 process uses 6to4 rules for link-local and tunnels
the initial packet to the regional relay.
6) Regional Registries have collected IPv4 addresses of ISP
6to4-relays as each IPv6 prefix is allocated.
7) Regional access and ISP relays participate in the global BGP
mesh.
8) Regional access relay sends IPv6 prefix-based redirect to the
Consumer system, pointing it to the native-IPv6-ISP 6to4-
relay having the longest match. It then forwards the original
packet to the identified native-IPv6-ISP 6to4-relay.
9) The 6to4 process builds a routing table cache from the
redirect messages. It first verifies the redirect through the
new 'Tunnel Ident' field (IPv4 Identifier in original tunnel
packet). Subsequent tunneling is based on longest match on
prefix. Once it knows the neighbor, the 6to4-router, or
integrated host, SHOULD send NS to the ISP relay it was
redirected to for maintenance of the mapping.
10) The 6to4 process resends first packet, now tunneled to the
native-IPv6-ISP 6to4-relay topologically closest to the
native IPv6 end of this traffic flow.
11) Destination ISP relay forwards within the IPv6 network. (It
SHOULD already be advertising the return route to 2002::/16.)
12) The Native-IPv6 system sends an Ack for first packet via the
nearest relay advertising 2002::/16.
13) The Native-IPv6-ISP 6to4-relay extracts the IPv4 from
destination in packet header and tunnels the packet across
the IPv4 logical link.
------
Hain Expires December 2000 6
6to4 router discovery and scaling July 2000
Sequence Scenario 2:
1. The Native-IPv6 system looks up the name 6to4-web-site.
2. DNS MAY return a 2002:: record in a traditional round-robin
for the web site.
3. The native-IPv6 system sends its first packet via the nearest
relay advertising 2002::/16.
4. The native-IPv6-ISP 6to4-relay extracts the IPv4 from
destination in packet header and tunnels the packet across
the IPv4 logical link.
5. The 6to4-router for the web site forwards the packet to the
destination web site.
6. The Web site sends an ACK via its 6to4-router.
7. The 6to4 process in the 6to4-router looks up the IPv4 address
of the well-known relay 6to4-relay.ipv6.org for any non-
2002:: destination that does not match a prefix in the
routing cache, using IPv4.
8. DNS returns a Cname based on the RIR of the requestors IPv4.
9. The 6to4 process then automatically looks up 6to4-
relay.RIR.ipv6.org
10. DNS returns a traditional IPv4 round-robin for relays per
region.
11. The 6to4 process uses 6to4 rules for link-local and tunnels
the packet to the regional relay.
12. Regional Registries have collected IPv4 addresses of ISP
6to4-relays as each IPv6 prefix is allocated.
13. Regional access and ISP relays participate in the global BGP
mesh.
14. Regional access relay sends IPv6 prefix-based redirect to the
6to4 router, pointing it to the native-IPv6-ISP 6to4-relay
having the longest match.
15. The 6to4-router builds a routing table cache from the
redirect messages. It first verifies the redirect through the
new 'Tunnel Ident' field (IPv4 Identifier in original tunnel
packet). Subsequent tunneling is based on longest match on
prefix. Once it knows the neighbor, the 6to4-router, or
integrated host, SHOULD send NS to the ISP relay it was
redirected to for maintenance of the mapping.
Hain Expires December 2000 7
6to4 router discovery and scaling July 2000
*** This creates a perceived problem : -router responding to
redirect- Actually RFC 1812 [5][routerreq] 5.2.7.2 states
'MAY consider redirect when not running a routing protocol',
which is the case at hand; at least with other parties
involved with this logical link.
16. 6to4-router forwards to native-IPv6-ISP 6to4-relay based on
the longest match.
17. Native-IPv6-ISP 6to4-relay forwards to Native-IPv6 system.
-------
Hain Expires December 2000 8
6to4 router discovery and scaling July 2000
NS syntax
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (135) | Code (0) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target Address (FE80::IPv4) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) | Length (1) | MUST be 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Layer Address (IPv4 of 6to4-router) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NA syntax
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (136) | Code (1) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target Address (FE80::IPv4) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) | Length (1) | MUST be 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Layer Address (IPv4 of 6to4-relay) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) | Length (4) | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Prefix (from table for this target) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code is set to 1 to identify new message with prefix information
R-bit is set as the 6to4-relay is logically a router
S-bit is set in response to solicitation
O-bit is cleared to prevent thrashing
Hain Expires December 2000 9
6to4 router discovery and scaling July 2000
Redirect syntax
(Expands scope for redirect from host to prefix)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (137) | Code (0) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target Address (FE80::IPv4) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Destination Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) | Length (1) | MUST be 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Layer Address (IPv4 of 6to4-relay) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) | Length (4) | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Prefix (from table for this target) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (4) | Length | Tunnel Ident |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IP header + data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP header + data is the original packet truncated to ensure that the
size of the redirect message does not exceed 1280 octets.
Valid lifetime and Preferred lifetime are set to the time remaining
until next scheduled BGP update
'Tunnel Ident' is used for spoof protection, and is filled in from
the Identity field from the IPv4 header of the 6to4 packet.
Hain Expires December 2000 10
6to4 router discovery and scaling July 2000
Protection from random redirects:
For simple spoof protection, the upper 16 bits of the 'Tunnel Ident'
field (previously reserved) in the Redirected Header option are used
to reflect the Identifier field from the outer IPv4 header of the
original packet sent to the Regional Relay. This combined with the
original packet contents mitigate guessing or flooding attacks, and
virtually require access to the packet path to generate a valid
spoof.
Additional Requirements
Regional relays are run as ipv6.org named service by the Regional
Internet Registries (RIRs).
Registration of native-IPv6-ISP relays is handled through RIRs,
because a trust model exists and it appears to be an easy addition
to the allocation process.
Regional relays SHOULD address scaling to support the number of
directly attached IPv4 systems in their area, and forward any
packets received to the same ISP relay it identified in the prefix-
based redirect defined above. Severe rate limiting MAY be imposed to
discourage 6to4-routers and integrated hosts from ignoring these
redirect messages.
6to4 integrated hosts, routers, and relays MUST recognize and
respond to ICMP messages targeted for [FE80::IPv4] that are received
on the 6to4 interface.
6to4-routers SHOULD establish NUD (as defined in section 3.8 of
[6][mech]) with 6to4-relays they are redirected to, and avoid
thrashing if multiple relays exist for a given prefix. The ISP
relays MAY establish NUD with the routers if desired, though this
will create scaling concerns with the only marginal benefit being
the rapid removal of access to nodes behind the an individual IPv4
address.
6to4-routers MAY choose to time out this prefix entry if there is no
traffic for two valid lifetimes.
6to4-relays SHOULD address scaling for both traffic handling and NUD
exchanges.
6to4-relays MAY send prefix based redirects to provide load
balancing among relays not directly identified via BGP.
Neighbor solicitation (type 135) is sent when the lifetime expires.
The 6to4-relay SHOULD answer if it is still willing to forward with
a Neighbor Advertisement (type 136) including the options defined
for redirect.
Hain Expires December 2000 11
6to4 router discovery and scaling July 2000
Additional Thoughts
Separate regional relays are not required if native-IPv6-ISPs are
willing to have their relays act as the first packet top-level
redirectors for non-customers. The only requirements are
establishing who manages the round-robin DNS entries for each
regions relay name; and that all systems in that list be
participants in the global BGP mesh, as well as willing and capable
of generating the prefix based redirects.
Security Considerations
This document does not introduce any new security concerns, and
attempts to add some level of protection from spoofed redirects
received over the 6to4 interface. Basic protection from spoofed
redirects is provided unless the routing path infrastructure is
penetrated. Additional protection of the redirect is possible using
IPsec. This approach is not used by default, as the case where it is
necessary is rare, and the cost is relatively high.
Denial-of-Service attacks are possible against the common
infrastructure in the Regional Relays. If such an attack is detected
the targeted relay MAY choose to stop forwarding packets and only
issue redirects. This will impact application responsiveness as
packets are discarded, but not as dramatically as loosing all
ability to find the native IPv6 relays should the regional relays
become inundated.
Denial-of-service attacks against other components described here
are beyond the scope of this document, as those components are not
common infrastructure and their defense is a local matter.
References
1 [RFC-2026], Bradner, S., " The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
2 [6to4], Carpenter, B., "Connection of IPv6 Domains via IPv4
Clouds without Explicit Tunnels", draft-ietf-ngtrans-6to4-06.txt,
June 2000
3 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
4 [ND], Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery
for IP Version 6", RFC 2461, December 1998
5 [routerreq] Baker, F., "Requirements for IP Version 4 Routers",
RFC-1812, June 1995
Hain Expires December 2000 12
6to4 router discovery and scaling July 2000
6 [mech], Nordmark, E., Gilligan, R. E., "Transition Mechanisms for
IPv6 Hosts and Routers", April 14, 2000
Acknowledgments
Thanks for critique of this document provided by Christian Huitema,
David Thaler, Fred Baker and Brian Carpenter.
Author's Addresses
Tony Hain
Microsoft
One Microsoft Way
Redmond, Wa. USA 98052
Email: tonyhain@microsoft.com
Hain Expires December 2000 13 | PAFTECH AB 2003-2026 | 2026-04-23 06:15:30 |