Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
51
Добавлен:
11.04.2015
Размер:
22.9 Mб
Скачать

334 Understanding IPv6, Second Edition

To determine whether a destination Teredo address corresponds to a Teredo client on the same link, a Teredo client checks its multicast bubble cache. Each Teredo client sends

out multicast bubble packets on its IPv4 link to indicate its presence on the link. Each Teredo client receives the multicast bubble packets of other Teredo clients and adds their Teredo addresses and IPv4 addresses to the multicast bubble cache. Therefore, if the destination Teredo address is in the multicast bubble cache, the destination is an on-link neighbor.

Intersite Teredo Client Destinations

For packets destined for another Teredo client in a different site, the Teredo tunneling interface uses bubble packets as the substitute for the address resolution process of Neighbor Discovery when both Teredo clients are across restricted NATs. The exchange of bubble packets creates address and port-specific mappings in both restricted NATs so that the two Teredo clients can send packets directly to each other. For more information, see the “Initial Communication Between Teredo Clients in Different Sites” section later in this chapter.

IPv6 Internet Destinations

For packets destined for the IPv6 Internet, the Teredo tunneling interface uses ICMPv6 Echo Request and Echo Reply messages as substitutes for the address resolution process of Neighbor Discovery. An ICMPv6 Echo Request message is sent to the destination. The ICMP Echo Reply message that is returned contains the IPv4 address of the Teredo relay closest to the IPv6 host on the IPv6 Internet. For more information, see the “Initial Communication from a Teredo Client to a Teredo Host-Specific Relay” and “Initial Communication from a Teredo Client to an IPv6-Only Host” sections later in this chapter.

Teredo Processes

This section provides details on the set of Teredo packets exchanged to perform the following:

Initial configuration for Teredo clients

Maintaining the NAT mapping

Initial communication between Teredo clients on the same link

Initial communication between Teredo clients in different sites

Initial communication from a Teredo client to a Teredo host-specific relay

Initial communication from a Teredo host-specific relay to a Teredo client

Initial communication from a Teredo client to an IPv6-only host

Initial communication from an IPv6-only host to a Teredo client

All of these processes are supported by the Teredo client in Windows Server 2008, Windows Vista, Windows XP with SP2, Windows XP with SP1 with the Advanced Networking Pack for

Chapter 14 Teredo

335

Windows XP, and Windows Server 2003 with Service Pack 1 and are performed automatically, without requiring configuration or intervention from the user.

Initial Configuration for Teredo Clients

Initial configuration for Teredo clients is accomplished by sending a series of Router Solicitation messages to Teredo servers to determine a Teredo address and whether the client is behind a cone, restricted, or symmetric NAT. Figure 14-11 shows the initial configuration process defined in RFC 4380.

Teredo Server 2

Teredo Server 1

1.Router Solicitation

2.Router Advertisement (with Different IPv4 Source to Detect Cone NAT)

3.Router Solicitation

4.Router Advertisement (with Same IPv4 Source to Detect Restricted NAT)

5.Router Solicitation

6.Router Advertisement (Used to Detect Symmetric NAT)

Teredo

Client

4 2

6

IPv4 Internet

5

3

1

NAT

Figure 14-11 Initial configuration for Teredo clients

This initial configuration for Teredo clients consists of the following process:

1.The Teredo client sends a Router Solicitation message to a preferred Teredo server (Teredo Server 1). The Teredo client sends the router solicitation from a link-local address for which the Cone flag is set.

2.Teredo Server 1 responds with a Router Advertisement message. Because the router solicitation had the Cone flag set, Teredo Server 1 sends the router advertisement from an alternate IPv4 address. If the Teredo client receives the router advertisement, it determines that it is behind a cone NAT.

3.If a router advertisement is not received, the Teredo client sends another router solicitation from a link-local address for which the Cone flag is not set.

4.Teredo Server 1 responds with a router advertisement. Because the router solicitation did not have the Cone flag set, Teredo Server 1 sends the router advertisement from the source IPv4 address corresponding to the destination IPv4 address of the router

336 Understanding IPv6, Second Edition

solicitation. If the Teredo client receives the router advertisement, it determines that it is behind a restricted NAT.

5.To determine whether the Teredo client is behind a symmetric NAT, it sends another router advertisement to a secondary Teredo server (Teredo Server 2).

6.Teredo Server 2 responds with a router advertisement. The Teredo client compares the mapped addresses and UDP ports in the Origin indicators of the router advertisements received by both Teredo servers. If they are different, the NAT is mapping the same internal address and port number to different external addresses and port numbers. The Teredo client determines that the NAT is a symmetric NAT.

Based on the received router advertisement (step 2 or 4 in the previous process), the Teredo client constructs its Teredo address from the following:

The first 64 bits are set to the value included in the Prefix Information option of the received router advertisement. The 64-bit prefix advertised by the Teredo server consists of the Teredo prefix (32 bits) and the IPv4 address of the Teredo server (32 bits).

The next 16 bits are the Flags field.

The next 16 bits are set to the obscured external UDP port number from the Origin indicator in the router advertisement.

The last 32 bits are set to the obscured external IPv4 address from the Origin indicator in the router advertisement.

Teredo clients running Windows Server 2008 or Windows Vista skip the detection for cone NATs and attempt to detect a symmetric NAT by sending router solicitations to both its primary and secondary Teredo server and comparing the Origin indicators from the received router advertisements.

The Teredo client in Windows Server 2008, Windows Vista, Windows XP with SP2, Windows XP with SP1 with the Advanced Networking Pack for Windows XP, and Windows Server 2003 with Service Pack 1 automatically attempts to determine the IPv4 addresses of Teredo servers by resolving the name teredo.ipv6.microsoft.com. You can use the netsh interface teredo set state servername=NameOrAddress command to configure the DNS name or IPv4 address of a Teredo server.

Network Monitor Capture

Here is an example of a Teredo-encapsulated router advertisement from a Teredo client on the IPv4 Internet to a Teredo server as displayed by Network Monitor 3.1 (frame 1 of capture 14_01 in the \NetworkMonitorCaptures folder on the companion CD-ROM):

Frame:

+ Ethernet: Etype = Internet IP (IPv4)

-Ipv4: Next Protocol = UDP, Packet ID = 1967, Total IP Length = 105

+Versions: IPv4, Internet Protocol; Header Length = 20

+DifferentiatedServicesField: DSCP: 0, ECN: 0

Chapter 14 Teredo

337

TotalLength: 105 (0x69)

Identification: 1967 (0x7AF)

+FragmentFlags: 0 (0x0) TimeToLive: 128 (0x80) NextProtocol: UDP, 17(0x11) Checksum: 42382 (0xA58E) SourceAddress: 71.112.33.18 DestinationAddress: 65.54.227.142

-Udp: SrcPort = 1151, DstPort = Teredo Servers(3544), Length = 85 SourcePort: 1151, 1151(0x47f)

DestinationPort: Teredo Servers(3544), 3544(0xdd8) TotalLength: 85 (0x55)

Checksum: 39434 (0x9A0A)

-Teredo: Tunneling IPv6 over UDP through NATs, No Authentication - AuthenticationHeader:

AuthenticationIndicator: 1 (0x1) IDLen: 0 (0x0)

AULen: 0 (0x0) NonceValue: 0x0

Confirmation: The client's key is still valid, 0(0x0)

-TunnelingIpv6: Next Protocol = ICMPv6, Payload Length = 24

+Versions: IPv6, Internet Protocol, DSCP 0 PayloadLength: 24 (0x18)

NextProtocol: ICMPv6, 58(0x3a) HopLimit: 255 (0xFF)

SourceAddress: FE80:0:0:0:8000:FFFF:FFFF:FFFD DestinationAddress: FF02:0:0:0:0:0:0:2

-Icmpv6: Router Solicitation

MessageType: Router Solicitation, 133(0x85)

+RouterSolicitation:

+SourceLinkLayerAddress:

In the IPv4 header, the packet is addressed from 71.112.33.18, the public IPv4 address of the Teredo client, to 65.54.227.142, the public IPv4 address of a Teredo server. The packet contains the Authentication indicator with no authentication information present. In the IPv6 header, the packet is addressed from a link-local address assigned to the Teredo tunneling interface to the link-local scope, all-routers multicast address.

The following is the corresponding Teredo-encapsulated router advertisement message from the Teredo server as displayed by Network Monitor 3.1 (frame 2 of capture 14_01):

Frame:

+ Ethernet: Etype = Internet IP (IPv4)

-Ipv4: Next Protocol = UDP, Packet ID = 40784, Total IP Length = 137

+Versions: IPv4, Internet Protocol; Header Length = 20

+DifferentiatedServicesField: DSCP: 0, ECN: 0 TotalLength: 137 (0x89)

Identification: 40784 (0x9F50)

+FragmentFlags: 0 (0x0) TimeToLive: 118 (0x76) NextProtocol: UDP, 17(0x11) Checksum: 6092 (0x17CC) SourceAddress: 65.54.227.143 DestinationAddress: 71.112.33.18

338Understanding IPv6, Second Edition

-Udp: SrcPort = Teredo Servers(3544), DstPort = 1151, Length = 117 SourcePort: Teredo Servers(3544), 3544(0xdd8)

DestinationPort: 1151, 1151(0x47f) TotalLength: 117 (0x75)

Checksum: 39734 (0x9B36)

-Teredo: Tunneling IPv6 over UDP through NATs, No Authentication,

OriginAddress = 71.112.33.18, OriginPort = 1151

-AuthenticationHeader: AuthenticationIndicator: 1 (0x1) IDLen: 0 (0x0)

AULen: 0 (0x0) NonceValue: 0x0

Confirmation: The client's key is still valid, 0(0x0)

-OriginHeader:

OriginIndicator: 0 (0x0)

OriginPort: 1151 (0x047F)

OriginIPv4Address: 71.112.33.18

-TunnelingIpv6: Next Protocol = ICMPv6, Payload Length = 48

+Versions: IPv6, Internet Protocol, DSCP 0 PayloadLength: 48 (0x30)

NextProtocol: ICMPv6, 58(0x3a) HopLimit: 255 (0xFF)

SourceAddress: FE80:0:0:0:8000:F227:BEC9:1C71 DestinationAddress: FE80:0:0:0:8000:FFFF:FFFF:FFFD

-Icmpv6: Router Advertisement

MessageType: Router Advertisement, 134(0x86) + RouterAdvertisement:

- PrefixInformation:

Type: Prefix Information, 3(0x3) Length: 4, in unit of 8 octets PrefixLength: 64 (0x40)

-Flags: 64 (0x40)

L:(0.......) Not on-Link specification

A:(.1......) Autonomous address-configuration

R:(..0.....) Not router Address

S:(...0....) Not a site prefix

P: (....0...) Not a router prefix

Rsv: (.....000)

ValidLifetime: 4294967295 (0xFFFFFFFF)

PreferredLifetime: 4294967295 (0xFFFFFFFF)

Reserved: 0 (0x0)

Prefix: 2001:0:4136:E38E:0:0:0:0

This packet contains the Authentication indicator and the Origin indicator. Because this Teredo client was not behind a NAT, the public IPv4 address and UDP port number in the Origin indicator is the same as the destination IPv4 address and UDP port of the packet. In the IPv6 header, the packet is addressed from a link-local address of the Teredo server to the link-local address of the Teredo client. The router advertisement contains a Prefix Information option for the prefix formed from the Teredo prefix and the colon hexadecimal representation of the Teredo server’s public IPv4 address (65.54.227.143 is 4136:E38E).

Соседние файлы в папке Lecture 2_10