rfc4389.Neighbor Discovery Proxies (ND Proxy)

rfc4389.Neighbor Discovery Proxies (ND Proxy)
rfc4389.Neighbor Discovery Proxies (ND Proxy)

Network Working Group D. Thaler Request for Comments: 4389 M. Talwar Category: Experimental Microsoft C. Patel All Play, No Work April 2006 Neighbor Discovery Proxies (ND Proxy)

Status of This Memo

This memo defines an Experimental Protocol for the Internet

community. It does not specify an Internet standard of any kind.

Discussion and suggestions for improvement are requested.

Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2006).

Abstract

Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the

different networks, simplifying management. Bridging some types of

media requires network-layer support, however. This document

describes these cases and specifies the IP-layer support that enables bridging under these circumstances.

Thaler, et al. Experimental [Page 1]

Table of Contents

1. Introduction (3)

1.1. SCENARIO 1: Wireless Upstream (3)

1.2. SCENARIO 2: PPP Upstream (4)

1.3. Inapplicable Scenarios (5)

2. Terminology (5)

3. Requirements (5)

3.1. Non-requirements (6)

4. Proxy Behavior (7)

4.1. Forwarding Packets (7)

4.1.1. Sending Packet Too Big Messages (8)

4.1.2. Proxying Packets with Link-Layer Addresses (8)

4.1.3. IPv6 ND Proxying (9)

4.1.3.1. ICMPv6 Neighbor Solicitations (9)

4.1.3.2. ICMPv6 Neighbor Advertisements (9)

4.1.3.3. ICMPv6 Router Advertisements (9)

4.1.3.4. ICMPv6 Redirects (10)

4.2. Originating Packets (10)

5. Example (11)

6. Loop Prevention (12)

7. Guidelines to Proxy Developers (12)

8. IANA Considerations (13)

9. Security Considerations (13)

10. Acknowledgements (14)

11. Normative References (14)

12. Informative References (15)

Appendix A: Comparison with Naive RA Proxy (16)

Thaler, et al. Experimental [Page 2]

1. Introduction

In the IPv4 Internet today, it is common for Network Address

Translators (NATs) [NAT] to be used to easily connect one or more

leaf links to an existing network without requiring any coordination with the network service provider. Since NATs modify IP addresses in packets, they are problematic for many IP applications. As a result, it is desirable to address the problem (for both IPv4 and IPv6)

without the need for NATs, while still maintaining the property that no explicit cooperation from the router is needed.

One common solution is IEEE 802 bridging, as specified in [BRIDGE].

It is expected that whenever possible links will be bridged at the

link layer using classic bridge technology [BRIDGE] as opposed to

using the mechanisms herein. However, classic bridging at the data- link layer has the following limitations (among others):

o It requires the ports to support promiscuous mode.

o It requires all ports to support the same type of link-layer

addressing (in particular, IEEE 802 addressing).

As a result, two common scenarios, described below, are not solved,

and it is these two scenarios we specifically target in this

document. While the mechanism described herein may apply to other

scenarios as well, we will concentrate our discussion on these two

scenarios.

1.1. SCENARIO 1: Wireless Upstream

The following figure illustrates a likely example:

| +-------+ +--------+

local |Ethernet | | Wireless | Access |

+---------+ A +-))) (((-+ +--> rest of network hosts | | | link | Point |

| +-------+ +--------+

In this scenario, the access point has assigned an IPv6 subnet prefix to the wireless link, and uses link-layer encryption so that wireless clients may not see each other’s data.

Classic bridging requires the bridge (node A in the above diagram) to be in promiscuous mode. In this wireless scenario, A cannot put its wireless interface into promiscuous mode, since one wireless node

cannot see traffic to/from other wireless nodes.

Thaler, et al. Experimental [Page 3]

IPv4 Address Resolution Protocol (ARP) proxying has been used for

some years to solve this problem without involving NAT or requiring

any change to the access point or router. In this document, we

describe equivalent functionality for IPv6 to remove this incentive

to deploy NATs in IPv6.

We also note that Prefix Delegation [PD] could also be used to solve this scenario. There are, however, two disadvantages to this.

First, if an implementation already supports IPv4 ARP proxying (which is indeed the case in a number of implementations today), then IPv6

Prefix Delegation would result in separate IPv6 subnets on either

side of the device, while a single IPv4 subnet would span both

segments. This topological discrepancy can complicate applications

and protocols that use the concept of a local subnet. Second, the

extent to which Prefix Delegation is supported for any particular

subscriber class is up to the service provider. Hence, there is no

guarantee that Prefix Delegation will work without explicit

configuration or additional charge. Bridging, on the other hand,

allows the device to work with zero configuration, regardless of the service provider’s policies, just as a NAT does. Hence bridging

avoids the incentive to NAT IPv6 just to avoid paying for, or

requiring configuration to get, another prefix.

1.2. SCENARIO 2: PPP Upstream

The following figure illustrates another likely example:

| +-------+ +--------+

local |Ethernet | | PPP link | |

+---------+ A +-----------+ Router +--> rest of network hosts | | | | |

| +-------+ +--------+

In this scenario, the router has assigned a /64 to the PPP link and

advertises it in an IPv6 Router Advertisement.

Classic bridging does not support non-802 media. The PPP Bridging

Control Protocol [BCP] defines a mechanism for supporting bridging

over PPP, but it requires both ends to be configured to support it.

Hence IPv4 connectivity is often solved by making the proxy (node A

in the above diagram) be a NAT or an IPv4 ARP proxy. This document

specifies a solution for IPv6 that does not involve NAT or require

any change to the router.

Thaler, et al. Experimental [Page 4]

1.3. Inapplicable Scenarios

This document is not applicable to scenarios with loops in the

physical topology, or where routers exist on multiple segments.

These cases are detected and proxying is disabled (see Section 6).

In addition, this document is not appropriate for scenarios where

classic bridging can be applied, or when configuration of the router can be done.

2. Terminology

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 BCP 14, RFC 2119

[KEYWORDS].

The term "proxy interface" will be used to refer to an interface

(which could itself be a bridge interface) over which network-layer

proxying is done as defined herein.

In this document, we make no distinction between a "link" (in the

classic IPv6 sense) and a "subnet". We use the term "segment" to

apply to a bridged component of the link.

Finally, while it is possible that functionality equivalent to that

described herein may be achieved by nodes that do not fulfill all the requirements in [NODEREQ], in the remainder of this document we will describe behavior in terms of an IPv6 node as defined in that

document.

3. Requirements

Proxy behavior is designed with the following requirements in mind:

o Support connecting multiple segments with a single subnet

prefix.

o Support media that cannot be bridged at the link layer.

o Do not require any changes to existing routers. That is,

routers on the subnet may be unaware that the subnet is being

bridged.

Thaler, et al. Experimental [Page 5]

o Provide full connectivity between all nodes in the subnet.

For example, if there are existing nodes (such as any routers

on the subnet) that have addresses in the subnet prefix,

adding a proxy must allow bridged nodes to have full

connectivity with existing nodes on the subnet.

o Prevent loops.

o Also work in the absence of any routers.

o Support nodes moving between segments. For example, a node

should be able to keep its address without seeing its address

as a duplicate due to any cache maintained at the proxy.

o Allow dynamic addition of a proxy without adversely

disrupting the network.

o The proxy behavior should not break any existing classic

bridges in use on a network segment.

3.1. Non-requirements

The following items are not considered requirements, as they are not met by classic bridges:

o Show up as a hop in a traceroute.

o Use the shortest path between two nodes on different

segments.

o Be able to use all available interfaces simultaneously.

Instead, bridging technology relies on disabling redundant

interfaces to prevent loops.

o Support connecting media on which Neighbor Discovery is not

possible. For example, some technologies such as [6TO4] use

an algorithmic mapping from IPv6 address to the underlying

link-layer (IPv4 in this case) address, and hence cannot

support bridging arbitrary IP addresses.

The following additional items are not considered requirements for

this document:

o Support network-layer protocols other than IPv6. We do not

preclude such support, but it is not specified in this

document.

Thaler, et al. Experimental [Page 6]

o Support Redirects for off-subnet destinations that point to a

router on a different segment from the redirected host.

While this scenario may be desirable, no solution is

currently known that does not have undesirable side effects

outside the subnet. As a result, this scenario is outside

the scope of this document.

4. Proxy Behavior

Network-layer support for proxying between multiple interfaces SHOULD be used only when classic bridging is not possible.

When a proxy interface comes up, the node puts it in "all-multicast" mode so that it will receive all multicast packets. It is common for interfaces not to support full promiscuous mode (e.g., on a wireless client), but all-multicast mode is generally still supported.

As with all other interfaces, IPv6 maintains a neighbor cache for

each proxy interface, which will be used as described below.

4.1. Forwarding Packets

When a packet from any IPv6 source address other than the unspecified address is received on a proxy interface, the neighbor cache of that interface SHOULD be consulted to find an entry for the source IPv6

address. If no entry exists, one is created in the STALE state.

When any IPv6 packet is received on a proxy interface, it must be

parsed to see whether it is known to be of a type that negotiates

link-layer addresses. This document covers the following types:

Neighbor Solicitations, Neighbor Advertisements, Router

Advertisements, and Redirects. These packets are ones that can carry link-layer addresses, and hence must be proxied (as described below) so that packets between nodes on different segments can be received

by the proxy and have the correct link-layer address type on each

segment.

When any other IPv6 multicast packet is received on a proxy

interface, in addition to any normal IPv6 behavior such as being

delivered locally, it is forwarded unchanged (other than using a new link-layer header) out all other proxy interfaces on the same link.

(As specified in [BRIDGE], the proxy may instead support multicast

learning and filtering, but this is OPTIONAL.) In particular, the

IPv6 Hop Limit is not updated, and no ICMP errors (except as noted in Section 4.1.1 below) are sent as a result of attempting this

forwarding.

Thaler, et al. Experimental [Page 7]

When any other IPv6 unicast packet is received on a proxy interface, if it is not locally destined then it is forwarded unchanged (other

than using a new link-layer header) to the proxy interface for which the next hop address appears in the neighbor cache. Again the IPv6

Hop Limit is not updated, and no ICMP errors (except as noted in

Section 4.1.1 below) are sent as a result of attempting this

forwarding. To choose a proxy interface to forward to, the neighbor cache is consulted, and the interface with the neighbor entry in the "best" state is used. In order of least to most preferred, the

states (per [ND]) are INCOMPLETE, STALE, DELAY, PROBE, REACHABLE. A packet is never forwarded back out the same interface on which it

arrived; such a packet is instead silently dropped.

If no cache entry exists (as may happen if the proxy has previously

evicted the cache entry or if the proxy is restarted), the proxy

SHOULD queue the packet and initiate Neighbor Discovery as if the

packet were being locally generated. The proxy MAY instead silently drop the packet. In this case, the entry will eventually be re-

created when the sender re-attempts Neighbor Discovery.

The link-layer header and the link-layer address within the payload

for each forwarded packet will be modified as follows:

1) The source address will be the address of the outgoing

interface.

2) The destination address will be the address in the neighbor

entry corresponding to the destination IPv6 address.

3) The link-layer address within the payload is substituted with

the address of the outgoing interface.

4.1.1. Sending Packet Too Big Messages

Whenever any IPv6 packet is to be forwarded out an interface whose

MTU is smaller than the size of the packet, the ND proxy drops the

packet and sends a Packet Too Big message back to the source, as

described in [ICMPv6].

4.1.2. Proxying Packets with Link-Layer Addresses

Once it is determined that the packet is either multicast or else is not locally destined (if unicast), the special types enumerated above (ARP, etc.) that carry link-layer addresses are handled by generating a proxy packet that contains the proxy’s link-layer address on the

outgoing interface instead. Such link-layer addresses occur in the Thaler, et al. Experimental [Page 8]

link-layer header itself, as well as in the payloads of some

protocols. As with all forwarded packets, the link-layer header is

new.

Section 4.1.3 enumerates the currently known cases where link-layer

addresses must be changed in payloads. For guidance on handling

future protocols, Section 7, "Guidelines to Proxy Developers",

describes the scenarios in which the link-layer address substitution in the payload should be performed. Note that any change to the

length of a proxied packet, such as when the link-layer address

length changes, will require a corresponding change to the IPv6

Payload Length field.

4.1.3. IPv6 ND Proxying

When any IPv6 packet is received on a proxy interface, it must be

parsed to see whether it is known to be one of the following types:

Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, or Redirect.

4.1.3.1. ICMPv6 Neighbor Solicitations

If the received packet is an ICMPv6 Neighbor Solicitation (NS), the

NS is processed locally as described in Section 7.2.3 of [ND] but no NA is generated immediately. Instead the NS is proxied as described above and the NA will be proxied when it is received. This ensures

that the proxy does not interfere with hosts moving from one segment to another since it never responds to an NS based on its own cache. 4.1.3.2. ICMPv6 Neighbor Advertisements

If the received packet is an ICMPv6 Neighbor Advertisement (NA), the neighbor cache on the receiving interface is first updated as if the NA were locally destined, and then the NA is proxied as described in 4.1.2 above.

4.1.3.3. ICMPv6 Router Advertisements

The following special processing is done for IPv6 Router

Advertisements (RAs).

A new "Proxy" bit is defined in the existing Router Advertisement

flags field as follows:

+-+-+-+-+-+-+-+-+

|M|O|H|Prf|P|Rsv|

+-+-+-+-+-+-+-+-+

Thaler, et al. Experimental [Page 9]

where "P" indicates the location of the Proxy bit, and "Rsv"

indicates the remaining reserved bits.

The proxy determines an "upstream" proxy interface, typically through a (zero-configuration) physical choice dictated by the scenario (see Scenarios 1 and 2 above), or through manual configuration.

When an RA with the P bit clear arrives on the upstream interface,

the P bit is set when the RA is proxied out all other ("downstream") proxy interfaces (see Section 6).

If an RA with the P bit set has arrived on a given interface

(including the upstream interface) within the last 60 minutes, that

interface MUST NOT be used as a proxy interface; i.e., proxy

functionality is disabled on that interface.

Furthermore, if any RA (regardless of the value of the P bit) has

arrived on a "downstream" proxy interface within the last 60 minutes, that interface MUST NOT be used as a proxy interface.

The RA is processed locally as well as proxied as described in

Section 4.1.2, unless such proxying is disabled as noted above.

4.1.3.4. ICMPv6 Redirects

If the received packet is an ICMPv6 Redirect message, then the

proxied packet should be modified as follows. If the proxy has a

valid (i.e., not INCOMPLETE) neighbor entry for the target address on the same interface as the redirected host, then the Target Link-Layer Address (TLLA) option in the proxied Redirect simply contains the

link-layer address of the target as found in the proxy’s neighbor

entry, since the redirected host may reach the target address

directly. Otherwise, if the proxy has a valid neighbor entry for the target address on some other interface, then the TLLA option in the

proxied packet contains the link-layer address of the proxy on the

sending interface, since the redirected host must reach the target

address through the proxy. Otherwise, the proxy has no valid

neighbor entry for the target address, and the proxied packet

contains no TLLA option, which will cause the redirected host to

perform Neighbor Discovery for the target address.

4.2. Originating Packets

Locally originated packets that are sent on a proxy interface also

follow the same rules as packets received on a proxy interface. If

no neighbor entry exists when a unicast packet is to be locally

originated, an interface can be chosen in any implementation-specific fashion. Once the neighbor is resolved, the actual interface will be Thaler, et al. Experimental [Page 10]

discovered and the packet will be sent on that interface. When a

multicast packet is to be locally originated, an interface can be

chosen in any implementation-specific fashion, and the packet will

then be forwarded out other proxy interfaces on the same link as

described in Section 4.1 above.

5. Example

Consider the following topology, where A and B are nodes on separate segments which are connected by a proxy P:

A---|---P---|---B

a p1 p2 b

A and

B have link-layer addresses a and b, respectively. P has

link-layer addresses p1 and p2 on the two segments. We now walk

through the actions that happen when A attempts to send an initial

IPv6 packet to B.

A first does a route lookup on the destination address B. This

matches the on-link subnet prefix, and a destination cache entry is

created as well as a neighbor cache entry in the INCOMPLETE state.

Before the packet can be sent, A needs to resolve B’s link-layer

address and sends a Neighbor Solicitation (NS) to the solicited-node multicast address for B. The Source Link-Layer Address (SLLA) option in the solicitation contains A’s link-layer address.

P receives the solicitation (since it is receiving all link-layer

multicast packets) and processes it as it would any multicast packet by forwarding it out to other segments on the link. However, before actually sending the packet, it determines if the packet being sent

is one that requires proxying. Since it is an NS, it creates a

neighbor entry for A on interface 1 and records its link-layer

address. It also creates a neighbor entry for B (on an arbitrary

proxy interface) in the INCOMPLETE state. Since the packet is

multicast, P then needs to proxy the NS out all other proxy

interfaces on the subnet. Before sending the packet out interface 2, it replaces the link-layer address in the SLLA option with its own

link-layer address, p2.

B receives this NS, processing it as usual. Hence it creates a

neighbor entry for A mapping it to the link-layer address p2. It

responds with a Neighbor Advertisement (NA) sent to A containing B’s link-layer address b. The NA is sent using A’s neighbor entry, i.e., to the link-layer address p2.

Thaler, et al. Experimental [Page 11]

The NA is received by P, which then processes it as it would any

unicast packet; i.e., it forwards this out interface 1, based on the neighbor cache. However, before actually sending the packet out, it inspects it to determine if the packet being sent is one that

requires proxying. Since it is an NA, it updates its neighbor entry for B to be REACHABLE and records the link-layer address b. P then

replaces the link-layer address in the TLLA option with its own

link-layer address on the outgoing interface, p1. The packet is then sent out interface 1.

A receives this NA, processing it as usual. Hence it creates a

neighbor entry for B on interface 2 in the REACHABLE state and

records the link-layer address p1.

6. Loop Prevention

An implementation MUST ensure that loops are prevented by using the P bit in RAs as follows. The proxy determines an "upstream" proxy

interface, typically through a (zero-configuration) physical choice

dictated by the scenario (see Scenarios 1 and 2 above), or through

manual configuration. As described in Section 4.1.3.3, only the

upstream interface is allowed to receive RAs, and never from other

proxies. Proxy functionality is disabled on an interface otherwise. Finally, a proxy MUST wait until it has sent two P bit RAs on a given "downstream" interface before it enables forwarding on that

interface.

7. Guidelines to Proxy Developers

Proxy developers will have to accommodate protocols or protocol

options (for example, new ICMP messages) that are developed in the

future, or protocols that are not mentioned in this document (for

example, proprietary protocols). This section prescribes guidelines that can be used by proxy developers to accommodate protocols that

are not mentioned herein.

1) If a link-layer address carried in the payload of the

protocol can be used in the link-layer header of future

messages, then the proxy should substitute it with its own

address. For example, the link-layer address in NA messages is used in the link-layer header for future messages, and,

hence, the proxy substitutes it with its own address.

For multicast packets, the link-layer address substituted

within the payload will be different for each outgoing

interface.

Thaler, et al. Experimental [Page 12]

2) If the link-layer address in the payload of the protocol will

never be used in any link-layer header, then the proxy should

not substitute it with its own address. No special actions

are required for supporting these protocols. For example,

[DHCPv6] is in this category.

8. IANA Considerations

This document defines a new bit in the RA flags (the P bit). There

is currently no registration procedure for such bits, so IANA should not take any action.

9. Security Considerations

Unsecured Neighbor Discovery has a number of security issues, which

are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines security mechanisms that can protect Neighbor Discovery.

Proxies are susceptible to the same kind of security issues that

plague hosts using unsecured Neighbor Discovery. These issues

include hijacking traffic and denial-of-service within the subnet.

Malicious nodes within the subnet can take advantage of this

property, and hijack traffic. In addition, a Neighbor Discovery

proxy is essentially a legitimate man-in-the-middle, which implies

that there is a need to distinguish proxies from unwanted man-in-

the-middle attackers.

This document does not introduce any new mechanisms for the

protection of proxy Neighbor Discovery. That is, it does not provide a mechanism from authorizing certain devices to act as proxies, and

it does not provide extensions to SEND to make it possible to use

both SEND and proxies at the same time. We note that RFC 2461 [ND]

already defines the ability to proxy Neighbor Advertisements, and

extensions to SEND are already needed to cover that case, independent of this document.

Note also that the use of proxy Neighbor Discovery may render it

impossible to use SEND both on the leaf subnet and on the external

subnet. This is because the modifications performed by the proxy

will invalidate the RSA Signature Option in a secured Neighbor

Discovery message, and cause SEND-capable nodes to either discard the messages or treat them as unsecured. The latter is the desired

operation when SEND is used together with this specification, and it ensures that SEND nodes within this environment can selectively

downgrade themselves to unsecure Neighbor Discovery when proxies are present.

Thaler, et al. Experimental [Page 13]

In the following, we outline some potential paths to follow when

defining a secure proxy mechanism.

It is reasonable for nodes on the leaf subnet to have a secure

relationship with the proxy and to accept ND packets either from the owner of a specific address (normal SEND) or from a trusted proxy

that it can verify (see below).

For nodes on the external subnet, there is a trade-off between

security (where all nodes have a secure relationship with the proxy) and privacy (where no nodes are aware that the proxy is a proxy). In the case of a point-to-point external link (Scenario 2), however,

SEND may not be a requirement on that link.

Verifying that ND packets come from a trusted proxy requires an

extension to the SEND protocol and is left for future work [SPND],

but is similar to the problem of securing Router Advertisements that is supported today. For example, a rogue node can send a Router

Advertisement to cause a proxy to disable its proxy behavior, and

hence cause denial-of-service to other nodes; this threat is covered in Section 4.2.1 of [PSREQ].

Alternative designs might involve schemes where the right for

representing a particular host is delegated to the proxy, or where

multiple nodes can make statements on behalf of one address

[RINGSIG].

10. Acknowledgements

The authors wish to thank Jari Arkko for contributing portions of the Security Considerations text.

11. Normative References

[BRIDGE] T. Jeffree, editor, "Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D, 2004, https://www.360docs.net/doc/932879241.html,/

getieee802/download/802.1D-2004.pdf.

[ICMPv6] Conta, A. and S. Deering, "Internet Control Message

Protocol (ICMPv6) for the Internet Protocol Version 6

(IPv6) Specification", RFC 2463, December 1998.

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC 2119, March 1997.

[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor

Discovery for IP Version 6 (IPv6)", RFC 2461, December

1998.

Thaler, et al. Experimental [Page 14]

[NODEREQ] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294,

April 2006.

12. Informative References

[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains

via IPv4 Clouds", RFC 3056, February 2001.

[BCP] Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)", RFC

3518, April 2003.

[DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol

for IPv6 (DHCPv6)", RFC 3315, July 2003.

[NAT] Srisuresh, P. and K. Egevang, "Traditional IP Network

Address Translator (Traditional NAT)", RFC 3022, January 2001.

[PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.

[PSREQ] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May

2004.

[RINGSIG] Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying

using Multi-Key Cryptographically Generated Addresses

(MCGAs)", Work in Progress, August 2005.

[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,

"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [SPND] Daley, G., "Securing Proxy Neighbour Discovery Problem

Statement", Work in Progress, February 2005.

Thaler, et al. Experimental [Page 15]

Appendix A: Comparison with Naive RA Proxy

It has been suggested that a simple Router Advertisement (RA) proxy

would be sufficient, where the subnet prefix in an RA is "stolen" by the proxy and applied to a downstream link instead of an upstream

link. Other ND messages are not proxied.

There are many problems with this approach. First, it requires

cooperation from all nodes on the upstream link. No node (including the router sending the RA) can have an address in the subnet or it

will not have connectivity with nodes on the downstream link. This

is because when a node on a downstream link tries to do Neighbor

Discovery, and the proxy does not send the NS on the upstream link,

it will never discover the neighbor on the upstream link. Similarly, if messages are not proxied during Duplicate Address Detection (DAD), conflicts can occur.

Second, if the proxy assumes that no nodes on the upstream link have addresses in the prefix, such a proxy could not be safely deployed

without cooperation from the network administrator since it

introduces a requirement that the router itself not have an address

in the prefix. This rules out use in situations where bridges and

Network Address Translators (NATs) are used today, which is the

problem this document is directly addressing. Instead, where a

prefix is desired for use on one or more downstream links in

cooperation with the network administrator, Prefix Delegation [PD]

should be used instead.

Thaler, et al. Experimental [Page 16]

Authors’ Addresses

Dave Thaler

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052-6399

Phone: +1 425 703 8835

EMail: dthaler@https://www.360docs.net/doc/932879241.html,

Mohit Talwar

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052-6399

Phone: +1 425 705 3131

EMail: mohitt@https://www.360docs.net/doc/932879241.html,

Chirayu Patel

All Play, No Work

Bangalore, Karnataka 560038

Phone: +91-98452-88078

EMail: chirayu@https://www.360docs.net/doc/932879241.html,

Thaler, et al. Experimental [Page 17]

Full Copyright Statement

Copyright (C) The Internet Society (2006).

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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET

ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,

INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE

INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property

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 https://www.360docs.net/doc/932879241.html,/ipr.

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-ipr@https://www.360docs.net/doc/932879241.html,.

Acknowledgement

Funding for the RFC Editor function is provided by the IETF

Administrative Support Activity (IASA).

Thaler, et al. Experimental [Page 18]

探索2014

探索2014 2014-01-01期《探索》:河中巨怪——锯鳐 2014-01-02期《探索》:野地七霸 2014-01-03期《探索》:树屋大师隐居灵屋 2014-01-04期《探索》:荒野求生俄勒冈地狱谷 2014-01-05期《探索》:贝尔·格里尔斯极限重生山区 2014-01-06期《探索》:凡尔赛宫的兴衰革命倒计时 2014-01-07期《探索》:飞机回购达人 2014-01-08期《探索》:北美大地生机勃发 2014-01-09期《探索》:河中巨怪巨骨舌鱼 2014-01-10期《探索》:树屋大师空中水疗 2014-01-11期《探索》:宝物鉴价大师 2014-01-12期《探索》:贝尔·格里尔斯极限重生——终极求生学校2014-01-13期《探索》:谍对谍 2014-01-14期《探索》:我爱树懒 2014-01-15期《探索》:牛鲨大军 2014-01-16期《探索》:驯狮达人非洲之旅 2014-01-17期《探索》:草根科学大发现落难英雄 2014-01-18期《探索》:荒野求生德克萨斯 2014-01-19期《探索》:宝物鉴赏大师 2014-01-20期《探索》:掠食战场 2014-01-21期《探索》:鲨口逃生 2014-01-22期《探索》:野兽大追踪缅甸蟒的攻击 2014-01-23期《探索》:河中巨怪年度河怪集锦 2014-01-24期《探索》:雪豹在伦敦(一) 2014-01-25期《探索》:雪豹在伦敦(二) 2014-01-26期《探索》:雪豹在伦敦(三) 2014-01-27期《探索》:草根科学大发现自然之子 2014-01-28期《探索》:草根科学大发现人体实验迷 2014-01-29期《探索》:草根科学大发现热门集萃 2014-01-30期《探索》:草根科学大发现宇宙大师 2014-01-31期《探索》:全球我最萌(第一集) 2014-02-01期《探索》:全球我最萌(第二集) 2014-02-03期《探索》:全球我最萌(第三集)——极致毛球 2014-02-04期《探索》:全球我最萌(第四集) 2014-02-05期《探索》:全球我最萌(五)——狗狗暖人心 2014-02-06期《探索》:最萌宠物汇 2014-02-07期《探索》:宠物淘气包 2014-02-08期《探索》:巨齿鲨大复活(上集) 2014-02-09期《探索》:巨齿鲨大复活(下集) 2014-02-10期《探索》:贝尔·格里尔斯——极限重生(第一集) 2014-02-11期《探索》:贝尔·格里尔斯极限重生——丛林

中国电视纪录片发展现状研究

中国电视纪录片发展现状研究 本文的目的在于研究中国电视纪录片发展现状。新中国成立以来电视纪录片的的发展经历了四个阶段新闻纪录、专题纪录、创新纪录、媒 介融合。从研究历史出发通过对当下纪录片生态环境、市场化问题、 话语权三大问题的现状分析归纳出体制内外纪录片发展中共同面临 的问题。世纪在新的传播环境和传播语境下中国当下的电视纪录片依 托传播学的理念从自身改造突破问题寻找出路。关键词电视纪录片市场化问题话语权传播过程引言引言研究缘起在年第届奥斯卡金像奖 提名名单中华人女导演杨紫烨凭借执导的环保题材纪录短片《仇岗卫士》成功入围最佳纪录短片提名。杨紫烨接受采访时说“现在是中国纪录片最好的时代。与“最好时代”不相称的是纪录片现状的尴尬局面翻阅电视报几乎找不到它的身影即使找到了也被安排在午夜等非黄 金时段相亲节目选秀节目竟猜节目……充斥于荧屏成为了老百姓茶 余饭后的谈资。与二十世纪九十年代的辉煌相比电视纪录片节目渐渐 冷清甚至已淡出人们的视线。纪录片遇到了怎样的困境把电视台的资源拱手让于其他节目电视纪录片在中国为何会有此境遇它的出路又 在哪里这就是笔者写作的缘起也是重点研究的问题。纪录得益于电 影。年月日法国卢米埃尔兄弟开创了电影的先河,工厂大门》、火车到站》、《婴儿进餐》等影片的公开收费放映使得电影真正走入了人类世 界展示出独有的光影魅力。这些影片就像一幅幅活动的相片带有很大程度的纪实性质。而就在年电影很快登陆中国。上海、北京、香港、

台湾陆续出现电影但放映的都是外国人的影片。直到年北京丰泰照相馆的老板任庆泰以著名京剧艺术家谭鑫培作为拍摄对象拍下了他表 演定军山》的几个片断观众反响热烈。这预示了中国纪录片的萌芽。 而国际上公认的第一部纪录电影是罗伯特?弗拉哈迪在年拍摄的北方的纳努克》这也是他的第一部电影。直到今天这部电影仍然充满着无穷的魔力被热爱纪录片的专家学者作为研究欣赏图本。原因就在于他开创了纪录片的拍摄手法。纪录片依托电影发展壮大在电影和电视界闯下了一番天地被全世界人民所认同。从年电视发明以后人们就可以足不出户了解世界新闻、博览社会百态。影视合流成了趋势。电视 纪录片应电视技术的成熟、媒体力量的聚合诞生了。美国国家地理频道、探索频道依托纪录片而崛起、发展英国的日本的在世界上在纪录片的专属领域中享有美誉。中国的电视杨紫烨现在是中国纪录片最好时代新浪网? 引言纪录片发从年起步至今已走过了五十三年的历史 现状又是如何呢研究的目的和意义选择中国电视纪录片的现状作为 论文的研究对象其目的和意义在于第一新千年已进入第十一个年头 科学技术日新月异中国电视纪录片自身在承载内容和外在形式上都 表现出个性化、丰富化的特点通过回顾半个世纪的电视纪录史分析出每个时期电视纪录片的共性站在历史的肩头才能更好的审视现在展 望未来。第二电视生态环境与纪录片发展息息相关在市场经济时代纪 录片面临着哪些问题又该如何把握自己的话语权这些问题的探讨是 纪录片现状生存必须面对的课题。第三电视纪录片是一个复杂动态的

Discovery纽约时代广场探索博物馆EB-5项目

Discovery纽约时代广场探索博物馆EB-5项目 项目概况 探索频道(Discovery Channel)于1985年在美国创立,探索频道目前覆盖全球 超过160个国家、4亿5千万个家庭,探索公司同时也是美国的上市公司,是美国最大的主流媒体之一。 Discovery博物馆(mDiscovery Times Square)成立于2009年,是探索频道(Discovery)的官方合作伙伴,为纽约市的前五大的博物馆。地处于时代广场核心的44街与第七第八大道中间,过去成功展出:泰坦尼克号、哈利波特、法老王和兵马俑等世界知名展览,已接待超过数百万人次的游客。继成功推出纽约时代广场第一期娱乐项目“百老汇4D剧院”项目(进展顺利,投资者均取得I-526移民申请通过)后,曼哈顿区域中心(MRC)又重磅推出位于纽约时代广场的第二期娱乐项目Discovery博物馆——探索纽约项目,该项目与第一期4D剧院项目仅隔一街距离。

项目特点 独一无二的地理优势 纽约时代广场在2013年迎接了5340万次游客,游客总消费超过了400亿美金,旅游消费预计将会在未来4年每年以8.5%的速度增长。 良好的发展前景——纽约市的旅游统计表

足够的就业机会创造 依照Michael Evans所做出的就业人数计算(即RIMS Ⅱ计算方式,该计算方法为美国移民局比较推荐的就业机会计算方式),该项目预计产生593个新的就业机会。远远超过EB-5所需的240个就业机会空间高达60%。 银行专户还款 Discovery博物馆参观门票预计价格为22美元,娱乐产业一直以来都是现金流十分可观的产业,依照与其他时代广场相似项目比较并且保守评估推算,每年项目净利润预计高达一千万美元以上,项目承诺在营运方面将保留60%的现金存放至还款账户中,专款专户作为未来贷款五年还款准备。 资金结构

教你DIY中文增强版Geexbox

教你DIY中文增强版Geexbox Geexbox是一款可以从光盘上直接启动的Linux多媒体操作系统【当然也可以从硬盘和USB闪存上启动】,它是基于Linux和MPlayer进行开发应用的,它可以让你不用进windows 就可以欣赏大片。它几乎支持大部分主流媒体格式,包括AVI、RM、RMVB、MPEG-4、MP3及外挂中文字幕,可以让旧电脑变成强悍的媒体中心。可惜官方提供的只有英文的ISO 镜像,因此网上也出现了不少网友定制的中文版。他们是怎么做的呢?其实很简单。利用官方提供的GeeXboX ISO Generator,你也可以轻松DIY属于自己的Geexbox中文增强版。还犹豫什么呢?下面就和笔者一起来体会DIY的乐趣。 一、GeeXboX ISO Generator初上手 “工欲善其事,必先利其器”,首先,请你到Geexbox的官方网站 (https://www.360docs.net/doc/932879241.html,/en/downloads.html)下载最新的GeeXboX ISO Generator。然后将下载到的geexbox-generator-1.0.i386.tar.gz用Winrar解压到硬盘中(本文以“D:\geexbox”为例进行说明)。进入解压目录,双击generator.exe运行软件(这个镜像生成器还包括在Linux和Macosx下使用的程序)。进入程序界面,你可以看到八个标签页,它们分别是:界面设置(Interface)、音频设置(Audio)、视频设置(Video)、遥控设置(Remote control)、网络设置(Network)、服务设置(Services)、液晶显示设置(Lcd display)、套件设置(Packages)。 接下来,请你单击“Packages“,进入套件设置项。这里列出的都是一些非常有用却没有包含在压缩包中的解码器(Codecs)、固件(Filmwares)、字体(Fonts)和主题(Themes)。建议你选中所有的解码器、固件、主题以及字体——“Chinese Simplified-GB2312”,然后点击”DownlOad”按钮下载。好啦,沏杯热茶慢慢等,Generator自己会通过网络把相应的文件下载到本地硬盘中。(如图1)心急的朋友如果受不了牛速,你也可以直接进入官方ftp下载所需资源: ⑴.解码器:https://www.360docs.net/doc/932879241.html,/codecs/ 将下得的压缩包解压至 D:\geexbox\iso\GEEXBOX\codec\即可。 ⑵.固件:https://www.360docs.net/doc/932879241.html,/firmwares/ 将下得的压缩包解压至 D:\geexbox\iso\GEEXBOX\firmwares\即可。 ⑶.字体:https://www.360docs.net/doc/932879241.html,/fonts/ 将下得的压缩包解压至 D:\geexbox\i18n\fonts\即可。

纪录片制作机构

探索频道(Discovery Channel)是由探索传播公司(Discovery Communications, Inc./DCI;NASDAQ:DISCA,旗下拥有197多家全球性电视网,包括Discovery探索频道、动物星球频道、Discovery科学频道和Discovery高清视界频道等)于1985年创立的,总部位于美国马里兰州蒙哥马利县银泉市。探索频道主要播放流行科学、科技、历史、考古及自然纪录片。 探索频道自1985年在美国启播后、现今已成为世界上发展最迅速的有线电视网络之一、覆盖面遍及全国百分之九十九的有线电视订户、在全球145个国家和地区有超过14400万个家庭订户。探索频道是全球最大的纪录片制作及买家、它吸引全球最优秀的纪录片制作人、所以探索频道的节目均被认为是世界上最优秀的纪实娱乐节目。也是世界上发行最广的电视品牌,目前到达全球160多个国家和地区的30600多万家庭,以35种不同语言播出节目。 探索频道在世界主要国家地区均有落地,但探索频道会因应不同地区设立不同版本,加上字幕或配音。美国版本主要播放写实电视节目,如著名的流言终结者系列。亚洲探索频道除着重播放写实节目之外,也播放文化节目,如介绍中国、日本文化的一系列节目。 亚洲探索频道于1994年成立,总部在新加坡,为美国Discovery传播公司(DCI)的全资附属机构,提供二十四小时精彩的纪实娱乐节目。据2005年泛亚媒体调查(PAX)的结果显示,探索频道在富裕成人中连续9年被公认为亚洲地区收视人口最多的有线及卫星电视频道。在新加坡举办的2004年“亚洲电视大奖”评选中,探索频道还荣膺“年度最佳有线及卫星电视频道”。 中国国际电视总公司(中央电视台全额投资的大型国有独资公司,成立于1984年,是中国内地规模最大、赢利能力最强的传媒公司)境外卫星代理部接收探索频道信号,通过亚太6号卫星(东经134度)发射KU波段信号。该服务一般只提供给三星级或以上的涉外宾馆酒店,外国人居住区,领事馆及大使馆。中国大陆各省市的地方电视台会转播或播放探索频道制作的节目。同时,还与浙江华数集团成立合资公司,向由杭州电视台开办的四个面向全国播出的高清付费电视频道(求索纪录、求索生活、求索科学、求索动物)提供绝大多数的节目内容。

SuperScan 使用教程

扫描工具SuperScan使用教程(如何使用SuperScan) SuperScan 是由Foundstone开发的一款免费的,但功能十分强大的工具,与许多同类工具比较,它既是一款黑客工具,又是一款网络安全工具。一名黑客可以利用它的拒绝服务攻击(DoS,denial of service)来收集远程网络主机信息。而做为安全工具,SuperScan能够帮助你发现你网络中的弱点。下面我将为你介绍从哪里得到这款软件并告诉你如何使用它。 如何获得SuperScan SuperScan4.0是免费的,并且你可以在如下地址下载: https://www.360docs.net/doc/932879241.html,:81/up/soft3_2010/SuperScan.rar 因为SuperScan有可能引起网络包溢出,所以Foundstone站点声明某些杀毒软件可能识别SuperScan是一款拒绝服务攻击(Dos)的代理。 SuperScan4.0只能在Windows XP或者Windows 2000上运行。对一些老版本的操作系统,你必须下载SuperScan3.0版。 SuperScan的使用 给SuperScan解压后,双击SuperScan4.exe,开始使用。打开主界面,默认为扫描(Scan)菜单,允许你输入一个或多个主机名或IP范围。你也可以选文件下的输入地址列表。输入主机名或IP范围后开始扫描,点Play button,SuperScan开始扫描地址,如下图A。

图A:SuperScan允许你输入要扫描的IP范围。 扫描进程结束后,SuperScan将提供一个主机列表,关于每台扫描过的主机被发现的开放端口信息。SuperScan还有选择以HTML格式显示信息的功能。如图B。

美国探索教育视频资源服务平台

1、美国探索教育视频资源服务平台 平台内容及意义 大众文化的流行,娱乐学习一体化的浪潮席卷全球。同时随着社会发展,多学科交叉融合,使得社会对大学生综合能力要求颇高。在某一个方面出类拔萃的复合型人才,越来越受到企业社会的青睐。综合性人才在当今社会炙手可热,因此学校在重视专业课的同时,加强对课外知识的普及符合当今教育时代的发展需求。 美国探索教育视频资源服务平台坚持以“科教兴国”为总方略,以提高在校师生综合素质、开拓师生眼界为宗旨;以教育、科学、文化、历史、探险等为题材的多学科交叉融合的教育视频资源服务平台。平台始终坚持科学研究与教学理论相统一,历史知识和文化教育相结合,以求达到师生即使足不出户,亦能知大千世界之神奇、能知世界各地前沿性科学技术,能解世间万物之疑惑。此平台已经成为西安数图网络科技有限公司一个独具特色的教育资源服务平台。 平台特色 美国探索教育视频资源服务平台,结合高校科学教育及科普知识所需,精选整合美国探索频道(Discovery)和美国国家地理频道(National Geography)两大世界知名频道近年来的最新节目,精心制作而成。 1、美国探索频道(Discovery) 1985年开播 使用客户在全球达到160多个国家,3亿零6百多万家庭。 通过15颗卫星用36种语言、24小时播放来源于全球不同地方摄制的精彩高品质纪实节目 2、美国国家地理频道(National Geography) 遍布全球达171个国家及地区 通过48种语言收看 荣获1次奥斯卡金像奖和2次金像奖提名,129座艾美奖 平台分类 自然科学,历史人文,科学发现,生命科学,旅游风光,体育探索,军事侦探,交通机械,工程建筑

discovery教程

第一章:前言 (1) 第二章:微机油藏描述系统集成 (3) 一、Landmark公司微机油藏描述系统发展历程 (3) 二、微机油藏描述系统各模块集成 (4) (一)工区、数据管理系统 (二)GESXplorer地质分析与制图系统 (三)SeisVision 2D/3D二维三维地震解释系统 (四)PRIZM 测井多井解释系统 (五)ZoneManager层管理与预测 (六)GMAPlus正演建模 三、Discovery微机油藏描述系统软件特色 (12) 第三章:微机三维地震解释系统软件应用方案研究 (13) 一、工区建立 (13) (一)工区目录建立 (二)一般工区建立 (三)工区管理 二、数据输入 (20) (一)地质数据输入 1 井头数据输入 2 井斜数据输入 3 分层数据输入 4 试油数据输入 5 生产数据加载 6 速度数据输入 (二)测井数据输入 1 ASCII格式测井数据输入 2 LAS格式测井数据输入 (三)地震数据输入 1 SEG-Y三维地震数据输入 2 层位数据输入 3 断层数据输入

三、微机地质应用 (31) (一)微机地质应用工作流程工作流程 1 地质分析工作流程 2 沉积相分析工作流程 (二)微机地质应用 1 井位图建立 2 等值线图(isomap)建立 3 各种剖面图(Xsection)建立 4 生产现状图制作 5 沉积相图制作 四、微机三维地震解释综合应用 (48) (一)微机三维地震解释工作流程 1 合成记录及层位工作流程 2 地震解释工作流程 3 速度分析工作流程 (二)微机三维地震解释综合应用 1 地震迭后处理-相干体 2 合成记录制作及层位标定 3 层位和断层建立、解释 4 三维可视化 5 速度分析与时深转换 6 构造成图 7 地震测网图建立 8 地震属性提取 五、微机单井测井解释及多井评价 (104) (一)微机单井测井解释及多井评价工作流程 1 测井曲线环境校正与标准化工作流程 2 测井分析流程 (二)微机单井测井解释及多井评价 1 打开测井曲线 2 测井曲线显示模板制作 3.测井曲线显示、编辑与预处理 4.交会图制作与分析 5 测井解释模型建立与解释 6 测井解释成果报告

BBC一百多部记录片

BBC一百多部记录片 BBC.生物记录片.细胞 https://www.360docs.net/doc/932879241.html,/cszGSiqUkU9cr(访问密码:e215)自然风光喜马拉雅山脉 https://www.360docs.net/doc/932879241.html,/cs4iYcAeiHKIn 提取码:28c1自然风光巴厘岛 https://www.360docs.net/doc/932879241.html,/csizn3trNnCGv 提取码:e5edBBC纪录片《野性水域终极挑战》[MKV] https://www.360docs.net/doc/932879241.html,/Qi24t6zR3TyCK (提取码:bbcb)[历史地理] 詹姆斯·卡梅隆的深海挑战. https://www.360docs.net/doc/932879241.html,/lk/cJxR8pIvfSvR8 访问密码4076远方的家-边疆行全100集 https://www.360docs.net/doc/932879241.html,/cszGATNBFhjjw(访问密码:52c6)美丽中国湿地行50集

https://www.360docs.net/doc/932879241.html,/cszX2JZKa6UVy 访问密码2f2f李小龙:勇士的旅程》(Bruce Lee A Warriors Journey) https://www.360docs.net/doc/932879241.html,/csFPTqFZr8GTz 提取码6c71CHC高清纪录片:星球奥秘之地球雪球期MKV 720P 1.4G 英语中字 https://www.360docs.net/doc/932879241.html,/QGEpqiPbfGfsG (访问密码:cdb2)探索频道:狂野亚洲:四季森林 https://www.360docs.net/doc/932879241.html,/cJxPJZXa8wGzA 访问密码1034BBC 纪录片《美国的未来》[MKV/4集全] https://www.360docs.net/doc/932879241.html,/QivxnUNbqLEau (提取码:27fe)生命的奇迹.全5集 https://www.360docs.net/doc/932879241.html,/cJXTIkq5jLBY5 访问密码7d2f《华尔街》高清收藏版[HDTV/720p/MKV/全10集] https://www.360docs.net/doc/932879241.html,/cy5PrZeud43Rk 提取码8497远方的家-沿海行(高清全112集) https://www.360docs.net/doc/932879241.html,/cszX4jUKD29ay 访问密码a52aBBC

全球最好的电视台

全球著名电视台 掌门人:霍珂灵 标签:文化国家 电视台(TV station /television station )指的是制作电视节目并通过电视或网络播放的媒体机构。它由国家或商业机构创办的媒体运作组织,传播视频和音频同步的资讯信息,这些资讯信息可通过有线或无线方式为公众提供付费或免费的视频节目。其播出时间固定,节目内容一部分为其自己制作,也有相当部分为外购。比较有名的电视台:CNN,BBC,TVB,CCTV等。 美国有线电视新闻网(CNN ) CNN由特德·特纳于1980年创办,1995年被时代—华纳公司兼并。总部设在美国佐治亚州首府亚特兰大市,在美国本土以外设有28个分部,在世界各地的雇员达4000人。CNN使用英语和西班牙语广播,它的资金来源于用户付费和广告收入。CNN因独家报道1991年海湾战争而成为家喻户晓的有线新闻广播公司,目前已覆盖全球210个国家和地区。 ? 什么叫CNN? ?CNN是什么? ?CNN什么意思啊好像最近很流行还有什么流行词啊? ?美国的CNN公司是什么东西请消息说明一下 ?CNN 是美国的还是法国的 ?CNN歪曲报道原文 英国广播公司(BBC) 这一新闻频道由英国广播公司于1991年成立。它在海外拥有250名记者和58个分部,资金来源于用户付费和广告收入。该频道声称在全球拥有2.7亿个家庭用户。英国广播公司今年宣布,计划于2007年新开播一个阿拉伯语的新闻频道。 ? BBC是什么? ?BBC什么意思 ?BBC是什么啊 ?BBC是哪个国家的媒体哦? ?bbc的经典语录(games[TV]的BBC) ?求bbc所有纪录片目录 半岛电视台(AlJazeera) 半岛电视台由卡塔尔政府于1996年成立。它在全球雇有170名记者,拥有26个分部。世界各地都能收看到半岛电视台的阿拉伯语频道。半岛电视台因不断报道伊拉克和中东其他地区的一些事件而遭到美国的指责。美国总统布什甚至曾计划轰炸它的卡塔尔总部。2006年,该电视台还将推出英语频道。 ?半岛电视台的相关资料? ?卡塔尔半岛电视台与cctv ?为什么半岛电视台收视率全球第一?cctv1呢? ?基地组织为什么要把拉登的录音送到半岛电视台? ?半岛电视台在中东哪里?据说很有名的! ?半岛电视台是哪国的 欧洲新闻电视台(Euronews) 欧洲新闻电视台建立于1993年,它的特点之一就是使用英语、法语、德语、意大利语、葡萄牙语、西班牙语和俄语7种语言播报新闻。该电视台所以能这样做是因为它主要使用各个通讯社提供的图像,而没有亮相屏幕的新闻主播。该电视台由19个欧洲公共部门电视频道共同所有,总部设在法国城市里昂,雇

纪录片是否要完全真实

纪录片不一定要完全真实 对于纪录片真实性的鉴定,就犹如不同的人看《哈姆雷特》,每个人都有自己的看法,而我的观点是:纪录片不一定要完全真实。我在这里提到的完全真实是指没有摆拍,没有编排。我认为纪录片中可以存在重现,摆拍。 有种对纪录片的定义是:一切真实记录社会和自然事物的非虚构的电影片或电视片都是纪录片。对于非虚构的电影片或电视片就可能存在编排和摆拍。 我的想法在国外和少数中国导演那里可以得到些许的认可。 在国外,纪录片是很受欢迎的,甚至纪录片的频道需要付费。就拿众所周知的美国的Discovery探索频道为例,美国的Discovery探索频道于1985年开播,是世界上发行最广的电视品牌,目前到达全球160多个国家和地区的3亿零6百多万家庭,以35种不同语言播出节目。 美国的Discovery探索频道的很多纪录片就是摆拍,重现的。Discovery有一档栏目叫重案夜现场,这个栏目并不是完全跟拍警方的破案过程,而是进行情景再现的,以摆拍,采访的方式进行重述。在这个节目里事件是真实的,专家的口述是真实的,而犯罪现场的以及犯罪证据,甚至犯罪过程的还原都是情景再现的,除了重案夜现场,历史零时差,与恐龙共舞特别篇等等都是情景再现的方式。情景再现即编排和摆拍。

黑格尔曾经说过:真实不是别的,而是缓慢的成熟过程。我觉得这句话,对于中国的纪录片仍然是很实用的。在我们国家,为什么人们不喜欢看纪录片?我想很大原因是因为我们国家的纪录片很多是不成熟的,但是有些导演的纪录片是很招人喜欢的,比如张以庆导演的影片《英和白》《幼儿园》《周周的世界》,冷冶夫的《伴》《油菜花开》等等,那么他们的影片是否是完全真实的呢? 冷冶夫在接受采访时说,他的《油菜花开》:“基本全部是摆拍,因为它是一种实验纪录片,国外翻译过来是“真实电影”,这种纪录片除了载体好以外,它的故事也好。我在主流媒体做的都是纪实风格的纪录片,很多人看不到我的另一面,所以我今天斗胆地放了这样一部片子”。当记者问到:“那您觉得摆拍还叫纪录片吗?”冷冶夫答道:“其实国际上往往把有没有这件事作为纪录片的鉴定。写剧本拍摄,那属于虚构的故事片,如果有这么件事,不管你怎么弄,它都是属于非虚构类的。国外对纪录片的分类特别粗,你也可以看到,包括国外那些Discovery节目几乎都用了情景再现的方式。” 我个人喜欢看《油菜花开》这样的纪录片,首先它的镜头很美,假如是跟拍,想必一定没有这么美的镜头;其次选材更容易,事件的结局知道,就更容易分析这件事件,就更容易找到切入点,在接下来编排摆拍时就更容易制造氛围,从而达到教育感化等效果,如果从开始就跟拍的纪录片,不一定能准确料定时间的结局,就不容易分析事件。 张以庆导演的纪录片一直以选材新颖,立意深刻著称,他肯花大

优秀自然纪录片

自然纪录片(这里面又大概分为地球、宇宙、人体三个大部分) 一、BBC地球篇 首先是BBC三大“镇馆之宝”(自封的) 《地球脉动》:几乎算是有史以来最好的生态纪录片,用接近上帝的视角,审视这个叫做地球的星球,虽然探讨的是科学,但是有着宗教式的观影体验。 《人类星球》: 一部极其特别的自然纪录片,说是讲地球,其实是在从社会学的角度讲人类,但说是讲人类的纪录片,它又是以自然生态地理环境等要素为载体来讲述。视点新颖,内容丰富,把自然和人文结合得天衣无缝。 《生命》:人类看完足以无地自容的片子,哪怕只是地穴里一只微不足道的小虫子,每天也在上演生存的史诗。为了吃饭,为了繁衍,为了活下去,无数精彩甚至悲壮的生物行为,在这个生生不息的地球上无限地演绎下去,地球也因此而不朽。 除了我心目中难以超越的三大神作之外,仍有一些不能不看的作品。 《植物之歌》:这部讲植物的算是侧重于动物的《生命》的姊妹篇,从植物的进化讲到对地球,对生态的影响,这是一次对地球的绿色,也是对生命的礼赞。 《非洲》:我认为最接近三大神作的作品,拍得极其出色。非洲大地上生命的瑰丽,壮阔,惊奇,灵动,不朽,一一呈现在镜头前。此外,大量蒙太奇,慢镜头的运用,让这部纪录片的观赏性和趣味性,也达到一个难以超越的高度。(例如,那个从沙丘底部拼命往上推粪球的屎壳郎君,一次次往上推,粪球一次次滚落,好不容易推上沙丘,一阵风吹过又把它直接吹到底部。表现得非常有趣,但笑着笑着不知不觉眼泪就出来了。。。) 《冰冻星球》:算是《地球脉动》和《生命》的一条支线,讲述两极大陆的世界与“居民”们。极地世界的镜头难能可贵,摄制组捕捉到了很多平常难以观测到的动物捕食、迁徙等活动,以及壮观的冰川与雪原,还有对全球变暖趋势的忧虑。 《蓝色星球》:这部纪录片的人气在国内不如以上几部那么高,但是其品质足以名列BBC前茅。本片深入海洋,对水下蔚蓝的世界进行深入细致的介绍。从起源到各方各面,再到反思,每一集主题鲜明,节奏得当,配乐非常动听,本片足以成为自然纪录片的教科书。 ==========题外话的分割线===========================

discovery中文教程

4.找到实例数据文件后,单击Open.。将出现General Properties(一般属性)对话框用于输入ASCII文本文件的定义。 5.在General Properties对话框中输入以下信息: z数据格式的Name(名)称为New Wells(新井)。 z在Description(描述)框中输入以下信息: 文件包括Well ID、 Operator(作业者)、Well Name(井名)、Well Number(井号)和 Status (状态)等一般井信息。每个字段用逗号分开。文本文件井头在第一行。

z Application是一种Well数据格式。这项选择决定在把ASCII数据映射到数据库中(或LandNet的层)时你的有效目标是什么。接受这个默认值。 z正常情况下,这些ASCII文本文件带有一个.txt后缀。在Default Extension(s) for ASCII Data Files(ASCII数据文件默认扩展名中)可输入txt, .txt, or *.txt. 输入该信息后,输入数据时选择ASCII数据文件会默认地查找*.txt文件。 z DefCon2 正确判断记录分隔符的末端和记录类型。一个ASCII数据文件中记录的基本格式。但Record ID选择的默认值需要改为(none), 因为数据文件的所有记录的格式相同。 z将Number of Header Records(井头记录序号)改为1用来说明包含列标题的ASCII 文本文件的第一行。 z正确的字段分隔符为逗号字段,正确的字段限定符为none(无)。 完成后的General Properties(一般属性)对话框应该像以下对话框。 6.单击OK。将出现Records Definition(记录定义)窗口。ASCII文本文件的每个字段或数据列将在这个窗口中进行定义。

Discovery Studio 讲义中文

附录:准备一个PDB文件作为同源性 建模模板 同源建模的基本原理是,你映射的一个未知的蛋白质序列一种已知蛋白质的结构。因此,如果你没有已知的蛋白质,或模板,你将无法建立模型。模板的共同来源是蛋白质在结构生物信息学研究的实验室数据银行(目标)。该网站RCSB是HTTP:/ /www.rcsb。org /。 蛋白质数据库(PDB)可能是世界上领先的公共源三维生物分子数据(1)。截至七月2006,超过37000项可在PDB。每个月都有更多的人加入。X射线衍射仪和其它固态技术占大多数的结构。然而,超过5500的核磁共振结构还可用。这些沉积的结构包括蛋白质,肽,核酸,碳水化合物,这些分子的配合物。 在发现工作室环境中工作的这些分子是一个关键的过程给你的建模工作。这个练习如何准备一个PDB文件作为一个模板同源建模项目。你将在课程中学习如何: ?加载PDB文件直接从蛋白质数据银行, ?生产和检验蛋白质报告, ?清除晶体单元电池, ?分裂分子, ?删除不需要的组件,和保存已完成的文件。 1、开始发现工作室 我们必须有发现工作室开始行使。 推出发现工作室客户端,如果它没有运行。 如果发现工作室已经在运行,从窗口菜单,选择关闭所有命令 如果提示保存任何分子或数据,请选择“不”。 2、加载PDB文件 现在,我们将直接从目标通过Discovery Studio界面加载PDB文件。注意:文件|打开网址…命令只会获得文件通过网络连接一个数据库服务器。如果连接不可能返回错误。检查你的导师或系统管理员,如果一个连接是可从您的车间位置。 从文件下拉菜单,选择命令打开网址。在对话框中,网址应该是指目标网站。更换与1t64 URL的最后四个字。 点击打开按钮。 如果一个PDB不能连接,所需的文件中的数据文件是可用的目录 1t64_original.pdb。

河南省接收卫星传送的境外电视节目许可证申领表 (2)

河南省接收卫星传送的境外电视节目许可证 申 领 表 申领单位:(盖章) 报送日期: 河南省广播电视局制 二○二〇年三月

填表说明 1、“申领单位”填写单位全称(与工商营业执照相符),并加盖公章。“单位性质”属事业单位的,填写事业单位;属企业单位的,选择民营、国有独资、国有控股、国有参股、外商独资或中外合资填写。 2、“注册地址”以工商营业执照为准,“设站地址”填写设置境外电视节目接收设施所在详细地点。 3、“接收目的”选择教学、科研、工作需要、服务中外宾客或外籍人士公寓填写。 4、“接收方式”根据本单位实际情况,从以下两种方式中选取一种,并在“□”中打“√”: (1)限定收视人数范围,不将接收设施的终端安置到超出规定及批准接收范围的场所,不在本单位的有线电视系统中传送所接收的境外电视节目; (2)接收的同时通过本单位闭路电视系统有选择播出(仅限涉外旅游宾馆、酒店)。 5、“申请接收境外电视频道名称”由省广电局参照国家广电总局批准的当年可供国内三星级以上涉外宾馆等单位申请接收的境外卫星电视频道名单,需要接收的节目请在“□”中打“√”。 6、“申领单位意见”请法定代表人签署意见,并签字、加盖单位公章。 7、“申领单位所在地广播影视行政部门意见”由当地广播电视行政管理部门负责人签署意见,并加盖单位公章。 8、申领单位报送本表时,同时需提交以下资料: (1)申请报告及《申请接收卫星传送的境外电视节目单位承诺书》;

(2)企业法人营业执照复印件或事业单位法人证书复印件; (3)安置接收设施的机房的有关设施情况、管理人员情况及管理制度; (4)三星级以上涉外宾馆请提交星级评定证明复印件; (5)原持证单位请提交原接收的境外节目名称、收视卡卡号等基本情况。 9、申领单位提交的材料,本表应提交一式三份,其余材料各一份。 10、彭博财经电视亚太频道2015年起不再发展新用户。

STM32F0-DISCOVERY用户手册

1/30 文档ID 022910第1版2012年3 月 STM32F0DISCOVERY STM32F0探索套件 UM1525 前言 STM32F0DISCOVERY 是意法半导体STM32F0系列微控制器的探索套件,用于帮助你探索STM32F0 Cortex-M0微控制器的功能,轻松开发应用设计。STM32F0探索套件基于1颗STM32F051R8T6微控制器,组件包括ST-LINK/V2嵌入式调试工具、LED 指示灯、按键和1个原型板。 图1: STM32F0 探索套件 用户手册

2/30UM1525 文档ID 022910第1版 目录目录 1. 约定....................................................................................................................................52. 快速入门 (6) 2.1 开始使用........................................................................................................ 62.2 系统要求..........................................................................................................62.3 支持STM32F0探索套件的开发工具链 .......................................................62.4 订货代码. (6) 3. 特性....................................................................................................................................74. 硬件与原理图.. (8) 4.1 STM32F051R8T6 微控制器 ..........................................................................114.2 嵌入式ST-LINK/V2编程器/调试器 . (13) 4.2.1 使用ST-LINK/V2向板载STM32F0烧录和调试代码 ............................14 4.2.2 使用ST-LINK/V2向外部STM32应用板烧录和调试代码. (15) 4.3电源和电源选择............................................ 164.4 LED 指示灯 ...................................................................................................164.5 按键................................................................................................................164.6 JP2(Idd ) ﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍﹍ 16 4.7 OSC 时钟 -----------------------------------------------------------------------------174.7.1 OSC 时钟电源 .............................................................................................174.7.2 OSC 32kHz 时钟电源 17 4.8 焊桥.................................................................................................................184.9 扩展连接器.. (19) 5. 尺寸图..............................................................................................................................266. 原理图..............................................................................................................................277. 修改历史记录 (30)

Discovery Studio 4 教程

Copyright ?2014, Neotrident Technology Ltd. All rights reserved

Discovery Studio CDOCKER教程 CDOCKER - 精准的分子对接技术 所需功能和模块:Discovery Studio Client, DS CDOCKER. 所需数据文件:1EQG.dsv, 1EQD-ibuprofen-conf.sd, 1EQG-ibuprofen.sd 所需时间:15分钟 介绍 CDOCKER是基于CHARMm力场的分子对接方法,这种方法可以产生高精度的对接结果。在本教程中,天然布洛芬配体分子对接回COX-1受体的结合位点中,得到的对接构象和X-ray衍射得到的晶体结构中的配体天然构象进行比较。本教程包括: ?准备对接体系 ?运行CDOCKER ?CDOCKER结果分析 准备对接体系 在文件浏览器(Files Explorer)中,找到并双击打开Samples | Tutorials | Receptor-Ligand Interactions| 1EQG.dsv。 在分子窗口中将打开一个带有活性位点的蛋白质三维结构(图1)。 图1蛋白质三维结构示意图 在工具浏览器(Tools Explorer)中,展开Receptor-Ligand Interactions | Define and Edit Binding Site,依次点击Show/Hide Residues Outside Sphere和Show/Hide Sphere。 展开菜单栏View|Transform,点击Fit To Screen将结合位点的氨基酸在窗口中居中显示(图2)。

美国探索频道纪录片和欧洲纪录片的传播学比较

2006年4月号下旬刊○出类拔萃 摘要:纪录片与其他大众传媒方式一样必须解决何时传播,在什么合适的地点传播,如何有效的传播,如何获得更好的传播效果,如何建立并通过优化的传播渠道进行传播等问题。本文引入传播学的分析方法,分析美国探索频道纪录片和欧洲纪录片在运作模式、制作方式和核心传播理念上的差异。 关键词:传播运作模式标准化生产核心传播理念纪实娱乐 传统的纪录片研究,在一般层次上注重的是关于纪录片内部的系统研究。其中包括纪录片语言研究,镜头研究,美学研究乃至于纪录片史的研究。但是理论界却往往把纪录片和传播切割开来。纪录片更多的被归为艺术领域进行泛文化的研究与精读,而分裂了作为传播媒介个体的属性和特点,作为传播工具的作用与方法,作为传播模式的影响和受众的接受与反馈。 “电影和纪录片首先是一门传播,其次才是一门艺术。电影和纪录片首先是一门传播的艺术,其次才是一门艺术的传播。”电影和纪录片的本体是为了解决何时传播,在什么合适的地点传播,如何有效的传播,如何获得更好的传播效果,如何建立并通过优化的传播渠道。纪录片也应和其他的大众传媒(报纸,电视)一样,在5个W中间寻找自己最有用的、最优化的传播方式和策划。 在美国,电影的生产和流通,首先是作为一种经济行为来运作的,这几乎已是人所共知的事实,美国的好莱坞更是把电影作为产业来经营的世界性代表。作为在同样的商业环境浸润中诞生的美国探索频道纪录片,在商业化运作方面几乎将好莱坞模式照搬过来,打造出纪录片领域的“美国大片”,并将传播的触角伸向世界每一个角落。 对比之下,欧洲纪录片生产和发行带有更多的政府背景和个人色彩,商品和市场的概念并没有在纪录片创作上产生过多影响,从纪录片创作的资金来源、运作模式、传播方式上都和美国探索频道纪录片有显著区别。 (一)运作模式:商业运作和社会运作 1.探索频道:利益驱动的商业运作模式 今天,好莱坞已经将电影商业化运营方式发展到登峰造极的地步,不仅拥有电影营销的系统模式,电影发行的院线制和分账制,还拥有经典的叙事系统,种类丰富的电影类型。在商业运作上,探索频道和好莱坞模式异曲同工。 探索频道1985年才正式开播,可以说是比较年轻的电 视频道。作为私营商业性公司的探索频道,从创建之初就开宗明义地把“赢利”作为自己的首要目的。探索频道探索亚洲制作总监VikramChanna曾说过,他们称观众为“消费者”,因为观众是“付费观众”,所以节目从定位、选题、制作等各个环节,都须紧紧围绕观众的需求来进行。“既然产品属性为商品,探索频道的竞争性思维一开始强调的就是遵循商业规则的价值性思维—— —即全力关注‘消费者’(观众),注意力集中在为‘消费者’(观众)提供的价值需求上,从而形成一个长期稳定的、忠诚的、不断扩延的‘客户平台’。” 商业利益驱动对纪录片创作产生的一个重要影响就是,能否赢利成为判断是否制作纪录片的唯一准则,制作的纪录片必须符合市场需要和能够带来商业利润。作为全球最大的纪实片制作商及买家,Discovery总会选择最优秀的制片人、最优秀的导演、主持人和翻译介入节目的制作;其每部制作实播片长和实拍片长的比例平均在1:15左右,最高甚至能达到1:75,其中所耗资金和所耗时间由此可想而知。Discovrey探索亚洲有限公司中国副总裁罗百鸿曾经说“Discovery要投入一个节目,一般在概念构思过程里就已经跟每一个播出地区的前线工作人员或者广告的销售人员去研究这一类节目是否有市场,是否有广告,甚至细致到各个推广地区是否会买节目版权。所以,我们的产品必须是能为Discovery主流市场接受的节目,这样投资才会有保证。” 2.欧洲纪录片:多样化的社会运作模式 欧洲国家众多,各国在广播电视节目的管理和运作的微观层面方面也存在很多复杂的差异。但总体来看,表现出一种和美国商业化模式不同的脉络,基本实行广播电视的公共管理模式。这种模式的基本特征就是通过一定的制度设计,以公共视听费,或以社会资助为主,国家财政补贴为辅,以此消除商业营利的驱动力,“在非商业主义、民主政治和中立自主的基础上,建立服务于公共利益和对社会负责的广播电视体制,从而促进言论的自由传播、文化的多元发展、信息的可选择性、教育的繁荣和高质量节目的制作。” 在欧洲,不论是机构还是个人制作纪录片,基本都不以赢利为目的。法国FIPA国际电视节秘书长让?米歇尔在接受访问时说“如果说在纪录片或者其它片子的成功中有窍门的话,如果谁知道成功的窍门这一秘密的话,所有的制作人就都成亿万富翁了,都发家致富了,但事实并非如此。制作人还并不富有,甚至是很穷,在欧洲甚至会穷死,从来不可能靠这种职业发大财。虽然他们也想赚钱,但实际上是不会有所谓的秘诀的。这是不可能存在的。现在唯一的秘诀就 美国探索频道纪录片和欧洲纪录片的传播学比较(中国传媒大学2003级纪录片研究方向硕士研究生,北京100000) 闵杰 215

相关文档
最新文档