[GTER] Banda infinita para a rede:
Cristine Hoepers
cristine at cert.br
Fri Apr 1 10:37:19 -03 2011
Falando nisso... :-)
============
Independent Submission B. Carpenter
Request for Comments: 6214 Univ. of Auckland
Category: Informational R. Hinden
ISSN: 2070-1721 Check Point Software
1 April 2011
Adaptation of RFC 1149 for IPv6
Abstract
This document specifies a method for transmission of IPv6 datagrams
over the same medium as specified for IPv4 datagrams in RFC 1149.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6214.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Carpenter & Hinden Informational [Page 1]
RFC 6214 IPv6 and RFC 1149 1 April 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 2
3. Detailed Specification . . . . . . . . . . . . . . . . . . . . 2
3.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . . 2
3.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Address Configuration . . . . . . . . . . . . . . . . . . . 3
3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Quality-of-Service Considerations . . . . . . . . . . . . . . . 4
5. Routing and Tunneling Considerations . . . . . . . . . . . . . 4
6. Multihoming Considerations . . . . . . . . . . . . . . . . . . 5
7. Internationalization Considerations . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction
As shown by [RFC6036], many service providers are actively planning
to deploy IPv6 to alleviate the imminent shortage of IPv4 addresses.
This will affect all service providers who have implemented
[RFC1149]. It is therefore necessary, indeed urgent, to specify a
method of transmitting IPv6 datagrams [RFC2460] over the RFC 1149
medium, rather than obliging those service providers to migrate to a
different medium. This document offers such a specification.
2. Normative Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Detailed Specification
Unless otherwise stated, the provisions of [RFC1149] and [RFC2460]
apply throughout.
3.1. Maximum Transmission Unit
As noted in RFC 1149, the MTU is variable, and generally increases
with increased carrier age. Since the minimum link MTU allowed by
RFC 2460 is 1280 octets, this means that older carriers MUST be used
for IPv6. RFC 1149 does not provide exact conversion factors between
age and milligrams, or between milligrams and octets. These
Carpenter & Hinden Informational [Page 2]
RFC 6214 IPv6 and RFC 1149 1 April 2011
conversion factors are implementation dependent, but as an
illustrative example, we assume that the 256 milligram MTU suggested
in RFC 1149 corresponds to an MTU of 576 octets. In that case, the
typical MTU for the present specification will be at least
256*1280/576, which is approximately 569 milligrams. Again as an
illustrative example, this is likely to require a carrier age of at
least 365 days.
Furthermore, the MTU issues are non-linear with carrier age. That
is, a young carrier can only carry small payloads, an adult carrier
can carry jumbograms [RFC2675], and an elderly carrier can again
carry only smaller payloads. There is also an effect on transit time
depending on carrier age, affecting bandwidth-delay product and hence
the performance of TCP.
3.2. Frame Format
RFC 1149 does not specify the use of any link layer tag such as an
Ethertype or, worse, an OSI Link Layer or SNAP header [RFC1042].
Indeed, header snaps are known to worsen the quality of service
provided by RFC 1149 carriers. In the interests of efficiency and to
avoid excessive energy consumption while packets are in flight
through the network, no such link layer tag is required for IPv6
packets either. The frame format is therefore a pure IPv6 packet as
defined in [RFC2460], encoded and decoded as defined in [RFC1149].
One important consequence of this is that in a dual-stack deployment
[RFC4213], the receiver MUST inspect the IP protocol version number
in the first four bits of every packet, as the only means to
demultiplex a mixture of IPv4 and IPv6 packets.
3.3. Address Configuration
The lack of any form of link layer protocol means that link-local
addresses cannot be formed, as there is no way to address anything
except the other end of the link.
Similarly, there is no method to map an IPv6 unicast address to a
link layer address, since there is no link layer address in the first
place. IPv6 Neighbor Discovery [RFC4861] is therefore impossible.
Implementations SHOULD NOT even try to use stateless address auto-
configuration [RFC4862]. This recommendation is because this
mechanism requires a stable interface identifier formed in a way
compatible with [RFC4291]. Unfortunately the transmission elements
specified by RFC 1149 are not generally stable enough for this and
may become highly unstable in the presence of a cross-wind.
Carpenter & Hinden Informational [Page 3]
RFC 6214 IPv6 and RFC 1149 1 April 2011
In most deployments, either the end points of the link remain
unnumbered, or a /127 prefix and static addresses MAY be assigned.
See [IPv6-PREFIXLEN] for further discussion.
3.4. Multicast
RFC 1149 does not specify a multicast address mapping. It has been
reported that attempts to implement IPv4 multicast delivery have
resulted in excessive noise in transmission elements, with subsequent
drops of packet digests. At the present time, an IPv6 multicast
mapping has not been specified, to avoid such problems.
4. Quality-of-Service Considerations
[RFC2549] is also applicable in the IPv6 case. However, the author
of RFC 2549 did not take account of the availability of the
Differentiated Services model [RFC2474]. IPv6 packets carrying a
non-default Differentiated Services Code Point (DSCP) value in their
Traffic Class field [RFC2460] MUST be specially encoded using green
or blue ink such that the DSCP is externally visible. Note that red
ink MUST NOT be used to avoid confusion with the usage of red paint
specified in RFC 2549.
RFC 2549 did not consider the impact on quality of service of
different types of carriers. There is a broad range. Some are very
fast but can only carry small payloads and transit short distances,
others are slower but carry large payloads and transit very large
distances. It may be appropriate to select the individual carrier
for a packet on the basis of its DSCP value. Indeed, different
carriers will implement different per-hop behaviors according to RFC
2474.
5. Routing and Tunneling Considerations
Routing carriers through the territory of similar carriers, without
peering agreements, will sometimes cause abrupt route changes,
looping packets, and out-of-order delivery. Similarly, routing
carriers through the territory of predatory carriers may potentially
cause severe packet loss. It is strongly recommended that these
factors be considered in the routing algorithm used to create carrier
routing tables. Implementers should consider policy-based routing to
ensure reliable packet delivery by routing around areas where
territorial and predatory carriers are prevalent.
There is evidence that some carriers have a propensity to eat other
carriers and then carry the eaten payloads. Perhaps this provides a
new way to tunnel an IPv4 packet in an IPv6 payload, or vice versa.
Carpenter & Hinden Informational [Page 4]
RFC 6214 IPv6 and RFC 1149 1 April 2011
However, the decapsulation mechanism is unclear at the time of this
writing.
6. Multihoming Considerations
Some types of carriers are notoriously good at homing. Surprisingly,
this property is not mentioned in RFC 1149. Unfortunately, they
prove to have no talent for multihoming, and in fact enter a routing
loop whenever multihoming is attempted. This appears to be a
fundamental restriction on the topologies in which both RFC 1149 and
the present specification can be deployed.
7. Internationalization Considerations
In some locations, such as New Zealand, a significant proportion of
carriers are only able to execute short hops, and only at times when
the background level of photon emission is extremely low. This will
impact the availability and throughput of the solution in such
locations.
8. Security Considerations
The security considerations of [RFC1149] apply. In addition, recent
experience suggests that the transmission elements are exposed to
many different forms of denial-of-service attacks, especially when
perching. Also, the absence of link layer identifiers referred to
above, combined with the lack of checksums in the IPv6 header,
basically means that any transmission element could be mistaken for
any other, with no means of detecting the substitution at the network
layer. The use of an upper-layer security mechanism of some kind
seems like a really good idea.
There is a known risk of infection by the so-called H5N1 virus.
Appropriate detection and quarantine measures MUST be available.
9. IANA Considerations
This document requests no action by IANA. However, registry clean-up
may be necessary after interoperability testing, especially if
multicast has been attempted.
10. Acknowledgements
Steve Deering was kind enough to review this document for conformance
with IPv6 requirements. We acknowledge in advance the many errata in
this document that will be reported by Alfred Hoenes.
This document was produced using the xml2rfc tool [RFC2629].
Carpenter & Hinden Informational [Page 5]
RFC 6214 IPv6 and RFC 1149 1 April 2011
11. References
11.1. Normative References
[RFC1149] Waitzman, D., "Standard for the transmission of IP
datagrams on avian carriers", RFC 1149, April 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460,
December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6
Jumbograms", RFC 2675, August 1999.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
11.2. Informative References
[IPv6-PREFIXLEN] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y.,
Colitti, L., and T. Narten, "Using 127-bit IPv6
Prefixes on Inter-Router Links", Work in Progress,
October 2010.
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
transmission of IP datagrams over IEEE 802
networks", STD 43, RFC 1042, February 1988.
[RFC2549] Waitzman, D., "IP over Avian Carriers with Quality
of Service", RFC 2549, April 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML",
RFC 2629, June 1999.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Carpenter & Hinden Informational [Page 6]
RFC 6214 IPv6 and RFC 1149 1 April 2011
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H.
Soliman, "Neighbor Discovery for IP version 6
(IPv6)", RFC 4861, September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Stateless Address Autoconfiguration", RFC 4862,
September 2007.
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service
Provider Scenarios for IPv6 Deployment", RFC 6036,
October 2010.
Authors' Addresses
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
EMail: brian.e.carpenter at gmail.com
Robert M. Hinden
Check Point Software Technologies, Inc.
800 Bridge Parkway
Redwood City, CA 94065
US
Phone: +1.650.387.6118
EMail: bob.hinden at gmail.com
Carpenter & Hinden Informational [Page 7]
On Fri, Apr 01, 2011 at 10:11:23AM -0300, Demi Getschko wrote:
> (cuidado com a data do RFC...)
>
> :-)
>
>
> =====
> Independent Submission K-M. Moller
> Request for Comments: 5984 1 April 2011
> Category: Experimental
> ISSN: 2070-1721
>
>
> Increasing Throughput in IP Networks with ESP-Based Forwarding:
> ESPBasedForwarding
>
> Abstract
>
> This document proposes an experimental way of reaching infinite
> bandwidth in IP networks by the use of ESP-based forwarding.
>
> Status of This Memo
>
> This document is not an Internet Standards Track specification; it is
> published for examination, experimental implementation, and
> evaluation.
>
> This document defines an Experimental Protocol for the Internet
> community. 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 5741.
>
> Information about the current status of this document, any errata,
> and how to provide feedback on it may be obtained at
> http://www.rfc-editor.org/info/rfc5984.
>
> Copyright Notice
>
> Copyright (c) 2011 IETF Trust and the persons identified as the
> document authors. All rights reserved.
>
> This document is subject to BCP 78 and the IETF Trust's Legal
> Provisions Relating to IETF Documents
> (http://trustee.ietf.org/license-info) in effect on the date of
> publication of this document. Please review these documents
> carefully, as they describe your rights and restrictions with respect
> to this document.
>
>
>
>
>
>
>
>
> Moller Experimental [Page 1]
>
> RFC 5984 ESP-Based Forwarding 1 April 2011
>
>
> Table of Contents
>
> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
> 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 2
> 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
> 2.1. Experiments with Black Fiber . . . . . . . . . . . . . . . 3
> 2.2. Schrodinger's Cat Experiment . . . . . . . . . . . . . . . 3
> 3. ESP-Based Forwarding . . . . . . . . . . . . . . . . . . . . . 4
> 3.1. Principle of Operation . . . . . . . . . . . . . . . . . . 4
> 3.2. Architectural Components . . . . . . . . . . . . . . . . . 4
> 3.2.1. DPAUI . . . . . . . . . . . . . . . . . . . . . . . . . 5
> 3.2.2. PPG . . . . . . . . . . . . . . . . . . . . . . . . . . 5
> 3.2.3. IID . . . . . . . . . . . . . . . . . . . . . . . . . . 5
> 3.2.4. CFE . . . . . . . . . . . . . . . . . . . . . . . . . . 6
> 3.2.5. PPS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
> 3.2.6. ND . . . . . . . . . . . . . . . . . . . . . . . . . . 6
> 4. End User Considerations . . . . . . . . . . . . . . . . . . . . 7
> 5. TCP Slow-Start Considerations . . . . . . . . . . . . . . . . . 7
> 6. Market Considerations . . . . . . . . . . . . . . . . . . . . . 7
> 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
> 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
> 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
>
> 1. Introduction
>
> Mechanisms for efficient packet forwarding has evolved over the past
> years. The demand for bandwidth is always increasing. Instead of
> optimizing forwarding performance and link capacity in an incremental
> fashion, we propose a brand new concept in packet forwarding that
> will provide unsurpassed end user performance regardless of link
> capacity, distance, and number of hops.
>
> 1.1. Requirements Language
>
> 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 [RFC2119].
>
> 2. Background
>
> During the past years, there have been a lot of improvements made in
> the domain of packet forwarding. Both software and hardware
> optimizations combined with increased link capacities have cut down
> round-trip times. Despite these improvements, many users find
> themselves frustrated since their demand for bandwidth has increased
> faster than the supply.
>
>
>
>
> Moller Experimental [Page 2]
>
> RFC 5984 ESP-Based Forwarding 1 April 2011
>
>
> The current incremental approach to lower latency and increase
> capacity will soon reach the end of the road. The reason for this
> has been known for some time and is stated in RFC 1925 [RFC1925]
> clause 2:
>
> "(2) No matter how hard you push and no matter what the priority, you
> can't increase the speed of light."
>
> Our research has finally been able to circumvent this boundary by the
> development of zero-latency network paths.
>
> Inspired by RFC 1072 [RFC1072], where a network containing a long,
> fat pipe is called LFN (pronounced "elephan(t)"), we will refer to an
> internet path with zero-latency as "infinitely fat", and a network
> containing this path as "IFN" (pronounced "infan(t)").
>
> Before the invention of this new forwarding principle, several
> experimental methods were tried. We have chosen to share our failed
> attempts in order help others avoid the same mistakes that we
> encountered. The following two methods have been dismissed:
>
> o Black Fiber
> o Schrodinger's cat experiment
>
> 2.1. Experiments with Black Fiber
>
> Attempting to push the speed-of-light limitation by means of using
> black fiber looked promising at first. Shortly after initiating the
> experiment, lack of light was detected in the black fiber. This was
> interpreted as proof of successful data transmission faster than the
> speed of light. After popping the champagne, the following problems
> were detected:
>
> 1. No data reached the receiver.
> 2. The fiber was not connected at the transmitting side.
>
> This clearly spoiled the mood of the party.
>
> 2.2. Schrodinger's Cat Experiment
>
> The Schrodinger's netcat experiment was based on an attempt to
> implement the method described by E. Schrodinger [Schrodinger35].
> The original procedure includes locking up cats in boxes with
> radioactive materials and poisonous gas. Data communication
> capabilities were added to the experiment, by using netcat. The
> research team was dumbfounded by the notion that the cat experiment
> seemed to work and not work at the same time. This was also
> confirmed by a friend of Wigner's [Wigner].
>
>
>
> Moller Experimental [Page 3]
>
> RFC 5984 ESP-Based Forwarding 1 April 2011
>
>
> A detailed analysis of the experiment indicated that the probability
> vectors collapsed whenever traffic was sent to the box. The
> conclusion was that this approach would only work without traffic,
> thus eliminating all practical applications.
>
> 3. ESP-Based Forwarding
>
> Experiments with ESP-based (Extra Sensory Perception) forwarding has
> proved to successfully remove the limitation in RFC 1925 [RFC1925].
>
> The foundation for the ESP-based forwarding scheme is to reduce
> latency by means of precognitive datagram detection and generation.
> By applying this technology, latency will not only reach zero, but
> might even become negative.
>
> Experiments performed by Benjamin Libet [Libet85] regarding the
> readiness potential (Bereitschaftspotential) concludes that the end
> user latency from impulse to the conscious mind is approximately 350
> - 400 ms. In order to reach the highest possible data transport
> without confusing the end user, it is important to take this latency
> into consideration.
>
> 3.1. Principle of Operation
>
> Traffic between the end user and the server reaches the ESP-enabled
> router. Inside the ESP-based router, the data stream is first
> analyzed by the DPAUI (Deep Packet And User Inspection). The DPAUI
> sends a signal to the PPG (Deep Packet And User Inspection), which
> generates uplink IP datagrams supported by the IID (Infinite
> Improbability Drive). The generated IP datagram is sent to the CFE
> (Clairvoyant Forwarding Engine) that forwards the datagram. Finally,
> the "real" uplink, the end user datagram is received and forwarded to
> the ND (Null Device).
>
> 3.2. Architectural Components
>
> The current ESP-based forwarding architecture includes the following
> components:
>
> o DPAUI
> o PPG
> o IID
> o CFE
> o PPS
> o ND
>
>
>
>
>
>
> Moller Experimental [Page 4]
>
> RFC 5984 ESP-Based Forwarding 1 April 2011
>
>
> 3.2.1. DPAUI
>
> The DPAUI (Deep Packet And User Inspection) monitors the data streams
> for all individual users. The DPAUI is implemented by means of
> implementing a learning agent that analyzes each individual user.
> The output from the DPAUI is a signal that indicates that an IP
> datagram will be sent by the end user within a couple of seconds.
>
> 3.2.2. PPG
>
> The purpose of the PPG (Precognitive Packet Generator) is to generate
> the IP datagram that the end user will trigger to be sent. In order
> to craft such a datagram, the PPG will perform a lookup based on the
> offset and length parameters generated by the IID. The PPG will
> generate the future packet by means of the function:
>
> struct mbuf * CopyDatagramFromPi(
> insane long offset,
> unsigned int len);
>
> The CopyDatagramFromPi() function will return a pointer to an mbuf
> containing the IP datagram. The offset value and len matches a
> corresponding offset and length in the decimal set for pi that
> contains the bit pattern for the future datagram. This method of
> operation will reduce the complex matter of precognitive packet
> generation to a simple lookup.
>
> Concerns have been raised that the full decimal set of pi requires an
> infinite amount of memory. This might have a negative effect on the
> manufacturing cost of the router. These concerns were successfully
> managed by using a perfectly circular buffer. This reduced the
> previous stated memory requirements at least by half.
>
> 3.2.3. IID
>
> The purpose of the IID (Infinite Improbability Drive) is to assist
> the PPG and PPS with improbable probabilities (and the other way
> around). The IID was originally invented by Douglas Adams [Adams79].
> The original implementation was based on hooking up the logic
> circuits of a Bambleweeny 57 sub-meson Brain to an atomic vector
> plotter suspended in a strong Brownian motion producer (i.e., a nice
> hot cup of tea).
>
> The research team struggled with the implementation of the strong
> Brownian motion producer. As a matter of fact, the majority of the
> research budget was wasted before it was fully conceived that a warm
> cup of tea and router equipment rarely mix.
>
>
>
>
> Moller Experimental [Page 5]
>
> RFC 5984 ESP-Based Forwarding 1 April 2011
>
>
> Aided by the gastronomical department (working on Bistromathic
> Drive), the research team managed to attach a brownie on top of a
> radio controlled hovercraft full of eels. This not only caused a lot
> of noise and disarray, but also a sufficient amount of Brownian
> motion. The research team is still working on an entirely software-
> based solution. Hopefully, the eel-filled hovercraft will soon be
> replaced with a different type of python script.
>
> 3.2.4. CFE
>
> After the IP datagram has been produced by the PPG, the CFE
> (Clairvoyant Forwarding Engine) will attempt to find the right route.
> Since the route might not exist yet, direct access to a routing table
> might result in routing errors.
>
> The implementation of the CFE is very straightforward: any off-the-
> shelf routing stack with a routing table and a routing daemon can be
> used. A standard Ouija board is simply put on top of the routing
> table. For each datagram, the CFE initiates an Ouija board session
> that will establish a connection with the routing deamons. The CFE
> will seek guidance for the future of the IP datagram and then send it
> along for a low cost, to meet a tall, dark server rack.
>
> 3.2.5. PPS
>
> The PPS (Pre-Preemptive Scheduler) is synchronized by means of an NTP
> connection to the IID based NTP server. This ensures that the ESP
> process will execute ten seconds ahead of local time (layman's term:
> "into the future"). This value should ensure operation even with
> very long Round Trip Times and should also include the readiness
> potential of the end user.
>
> The pre-preemptive scheduler not only provides a separate user space,
> but a separate dimension for the code to execute in. The dimension
> alignment is based on string theory and has been implemented in the
> language C, simply by including the library string.h and then using
> strcpy to copy the PPS function pointer into an eleven-dimensional
> array.
>
> 3.2.6. ND
>
> After a little time, less than the 'end user to server' Round-trip
> time (RTT), the real end user datagram will reach the ingress side of
> the ESP-based router, since the datagram has already been sent,
> routed and returned. The datagram is directly routed to the ND (Null
> Device) and the ingress packet counter is decremented.
>
>
>
>
>
> Moller Experimental [Page 6]
>
> RFC 5984 ESP-Based Forwarding 1 April 2011
>
>
> Experimentation showed that the ND is a perfect source of entropy and
> is able to store all digits of pi. The research team had great hopes
> of reducing the memory footprint for the PPG even further, but ran
> into problems with read access times.
>
> The ND is readily available in most operating systems.
>
> 4. End User Considerations
>
> End user considerations and differentiated traffic classes:
>
> 1. In order to facilitate a pleasant end user gaming experience,
> packets destined for the spinal cord (i.e., force feedback
> information, etc.) must be delayed by 350 ms in order to
> synchronize with the traffic that is routed by the end user to
> the cerebrum and cortex.
>
> 2. RFC 1216 [RFC1216], Section 3.3 states that "bad news travels
> fast". This means that additional delay must be introduced when
> the end user is browsing on news sites. Negative latency might
> make the end user suspect that the news is even worse than
> indicated by the news sites.
>
> 3. Machine-to-Machine (M2M) communication might experience reduced
> performance due to difficulties for the DPAUI to work correctly.
> When the concept starts working for M2M communication, this can
> be used as an indication that a technological singularity might
> be near.
>
> 5. TCP Slow-Start Considerations
>
> The lack of RTT of IFNs might cause some problems with TCP slow-
> start. More precisely, it will most likely not be slow at all. This
> might be handled by implementing a congestion avoidance mechanism,
> but will need further study.
>
> 6. Market Considerations
>
> Unfortunately, we foresee that this product will never be ready for
> the market. This is especially true for the Pre-preemptive
> Scheduler, which by nature, will always be slightly ahead of its
> time.
>
> 7. Security Considerations
>
> o Introducing an end user RTT delay of zero might cause crashes in
> badly implemented TCP/IP stacks. This is because division by zero
> might occur when calculating bandwidth-delay product.
>
>
>
> Moller Experimental [Page 7]
>
> RFC 5984 ESP-Based Forwarding 1 April 2011
>
>
> o ESP forwarding of traffic generated by psychics might lead to
> problems with recursiveness.
>
> o Lawful Intercept of the Deep User and Intention Inspection might
> violate personal integrity.
>
> o Terrorist organizations might exploit the "bad news travels fast"
> loophole in RFC 1216 [RFC1216].
>
> 8. References
>
> 8.1. Normative References
>
> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> Requirement Levels", BCP 14, RFC 2119, March 1997.
>
> 8.2. Informative References
>
> [Adams79] Adams, D., "Hitchhiker's guide to the galaxy.",
> 1979.
>
> [Libet85] Libet, B., "Unconscious cerebral initiative and the
> role of conscious will in voluntary action.", 1985.
>
> [RFC1072] Jacobson, V. and R. Braden, "TCP extensions for
> long-delay paths", RFC 1072, October 1988.
>
> [RFC1216] Richard, P. and Kynikos, "Gigabit network economics
> and paradigm shifts", RFC 1216, April 1991.
>
> [RFC1925] Callon, R., "The Twelve Networking Truths",
> RFC 1925, April 1996.
>
> [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas,
> D., and L. Jones, "SOCKS Protocol Version 5",
> RFC 1928, March 1996.
>
> [Schrodinger35] Schrodinger, E., "The Present Situation In Quantum
> Mechanics", 1935,
> <http://www.tu-harburg.de/rzt/rzt/it/QM/cat.html>.
>
> [Wigner] Wikipedia, "Wikipedia: Wigner's friend.",
> <http://en.wikipedia.org/wiki/Wigner's_friend>.
>
>
>
>
>
>
>
>
> Moller Experimental [Page 8]
>
> RFC 5984 ESP-Based Forwarding 1 April 2011
>
>
> Author's Address
>
> Karl-Magnus Moller
> Tankesaft
>
> EMail: kalle at tankesaft.se
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list