As per Relevance of the word addresses, we have this rfc below:
Network Working Group B.
Request for Comments: 2775
Category: Informational February 2000
Internet
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document describes the current state of the Internet from
architectural viewpoint, concentrating on issues of end-to-
connectivity and transparency. It concludes with a summary of
major architectural alternatives facing the Internet network layer
This document was used as input to the IAB workshop on the future
the network layer held in July 1999. For this reason, it does
claim to be complete and definitive, and it refrains from
recommendations
Table of
1. Introduction.................................................2
2. Aspects of end-to-end connectivity...........................3
2.1 The end-to-end argument.....................................3
2.2 End-to-end performance......................................4
2.3 End-to-end address transparency.............................4
3. Multiple causes of loss of transparency......................5
3.1 The Intranet model..........................................6
3.2 Dynamic address allocation..................................6
3.2.1 SLIP and PPP..............................................6
3.2.2 DHCP......................................................6
3.3 Firewalls...................................................6
3.3.1 Basic firewalls...........................................6
3.3.2 SOCKS.....................................................7
3.4 Private addresses...........................................7
3.5 Network address translators.................................7
3.6 Application level gateways, relays, proxies, and caches.....8
3.7 Voluntary isolation and peer networks.......................8
Carpenter Informational [Page 1]
RFC 2775 Internet Transparency February 2000
3.8 Split DNS...................................................9
3.9 Various load-sharing tricks.................................9
4. Summary of current status and impact.........................9
5. Possible future directions..................................11
5.1 Successful migration to IPv6...............................11
5.2 Complete failure of IPv6...................................12
5.2.1 Re-allocating the IPv4 address space.....................12
5.2.2 Exhaustion...............................................13
5.3 Partial deployment of IPv6.................................13
6. Conclusion..................................................13
7. Security Considerations.....................................13
Acknowledgements...............................................14
References.....................................................14
Author's Address...............................................17
Full Copyright Statement.......................................18
1.
"There's a freedom about the Internet: As long as we accept
rules of sending packets around, we can send packets
anything to anywhere." [Berners-Lee
The Internet is experiencing growing pains which are often
to as "the end-to-end problem". This document attempts to
those growing pains by reviewing the current state of the
layer, especially its progressive loss of transparency. For
purposes of this document, "transparency" refers to the
Internet concept of a single universal logical addressing scheme,
the mechanisms by which packets may flow from source to
essentially unaltered
The causes of this loss of transparency are partly artefacts
parsimonious allocation of the limited address space available
IPv4, and partly the result of broader issues resulting from
widespread use of TCP/IP technology by businesses and consumers.
example, network address translation is an artefact, but
are not
Thus the way forward must recognise the fundamental changes in
usage of TCP/IP that are driving current Internet growth. In
scenario, a complete migration to IPv6 potentially allows
restoration of global address transparency, but without
firewalls and proxies from the picture. At the other extreme, a
failure of IPv6 leads to complete fragmentation of the network layer
with global connectivity depending on endless patchwork
Carpenter Informational [Page 2]
RFC 2775 Internet Transparency February 2000
This document does not discuss the routing implications of
space, nor the implications of quality of service management
router state, although both these matters interact with
to some extent. It also does not substantively discuss
issues
2. Aspects of end-to-end
The phrase "end to end", often abbreviated as "e2e", is widely
in architectural discussions of the Internet. For the purposes
this paper, we first present three distinct aspects of end-to
endness
2.1 The end-to-end
This is an argument first described in [Saltzer] and reviewed in [
1958], from which an extended quotation follows
"The basic argument is that, as a first principle,
required end-to-end functions can only be performed correctly
the end-systems themselves. A specific case is that any network
however carefully designed, will be subject to failures
transmission at some statistically determined rate. The best
to cope with this is to accept it, and give responsibility for
integrity of communication to the end systems. Another
case is end-to-end security
"To quote from [Saltzer], 'The function in question can
and correctly be implemented only with the knowledge and help
the application standing at the endpoints of the
system. Therefore, providing that questioned function as
feature of the communication system itself is not possible
(Sometimes an incomplete version of the function provided by
communication system may be useful as a performance enhancement.)'
"This principle has important consequences if we
applications to survive partial network failures. An end-to-
protocol design should not rely on the maintenance of state (i.e
information about the state of the end-to-end communication
inside the network. Such state should be maintained only in
endpoints, in such a way that the state can only be destroyed
the endpoint itself breaks (known as fate-sharing). An
consequence of this is that datagrams are better than
virtual circuits. The network's job is to transmit datagrams
efficiently and flexibly as possible. Everything else should
done at the fringes."
Carpenter Informational [Page 3]
RFC 2775 Internet Transparency February 2000
Thus this first aspect of end-to-endness limits what the network
expected to do, and clarifies what the end-system is expected to do
The end-to-end argument underlies the rest of this document
2.2 End-to-end
Another aspect, in which the behaviour of the network and that of
end-systems interact in a complex way, is performance, in
generalised sense. This is not a primary focus of the
document, but it is mentioned briefly since it is often referred
when discussing end-to-end issues
Much work has been done over many years to improve and optimise
performance of TCP. Interestingly, this has led to
minor changes to TCP itself; [STD 7] is still valid apart from
additions [RFC 1323, RFC 2581, RFC 2018]. However a great deal
knowledge about good practice in TCP implementations has built up
and the queuing and discard mechanisms in routers have been fine
tuned to improve system performance in congested conditions
Unfortunately all this experience in TCP performance does not
with transport protocols that do not exhibit TCP-like response
congestion [RFC 2309]. Also, the requirement for specified quality
service for different applications and/or customers has led to
new development, especially the Integrated Services [RFC 1633,
2210] and Differentiated Services [RFC 2475] models. At the same
new transport-related protocols have appeared [RFC 1889, RFC 2326]
are in discussion in the IETF. It should also be noted that since
speed of light is not set by an IETF standard, our current notions
end-to-end performance will be largely irrelevant to
networking
Thus, despite the fact that performance and congestion issues for
are now quite well understood, the arrival of QOS mechanisms and
new transport protocols raise new questions about end-to-
performance, but these are not further discussed here
2.3 End-to-end address
When the catenet concept (a network of networks) was first
by Cerf in 1978 [IEN 48] following an earlier suggestion by Pouzin
1974 [CATENET], a clear assumption was that a single logical
space would cover the whole catenet (or Internet as we now know it).
This applied not only to the early TCP/IP Internet, but also to
Xerox PUP design, the OSI connectionless network design, XNS,
numerous other proprietary network architectures
Carpenter Informational [Page 4]
RFC 2775 Internet Transparency February 2000
This concept had two clear consequences - packets could
essentially unaltered throughout the network, and their source
destination addresses could be used as unique labels for the
systems
The first of these consequences is not absolute. In practice
can be made to packets in transit. Some of these are reversible
the destination (such as fragmentation and compression). Others
be irreversible (such as changing type of service bits
decrementing a hop limit), but do not seriously obstruct the end-to
end principle of Section 2.1. However, any change made to a packet
transit that requires per-flow state information to be kept at
intermediate point would violate the fate-sharing aspect of the end
to-end principle
The second consequence, using addresses as unique labels, was in
sense a side-effect of the catenet concept. However, it was a side
effect that came to be highly significant. The uniqueness
durability of addresses have been exploited in many ways,
particular by incorporating them in transport identifiers. Thus
have been built into transport checksums, cryptographic signatures
Web documents, and proprietary software licence servers. [RFC 2101]
explores this topic in some detail. Its main conclusion is that IPv
addresses can no longer be assumed to be either globally unique
invariant, and any protocol or applications design that assumes
properties will fail unpredictably. Work in the IAB and the
working group [NAT-ARCH] has analysed the impact of one
cause of non-uniqueness and non-invariance, i.e., network
translators. Again the conclusion is that many applications
fail, unless they are specifically adapted to avoid the assumption
address transparency. One form of adaptation is the insertion of
form of application level gateway, and another form is for the NAT
modify payloads on the fly, but in either case the adaptation
application-specific
Non-transparency of addresses is part of a more general phenomenon
We have to recognise that the Internet has lost end-to-
transparency, and this requires further analysis
3. Multiple causes of loss of
This section describes various recent inventions that have led to
loss of end-to-end transparency in the Internet
Carpenter Informational [Page 5]
RFC 2775 Internet Transparency February 2000
3.1 The Intranet
Underlying a number of the specific developments mentioned below
the concept of an "Intranet", loosely defined as a private
network using TCP/IP technology, and connected to the Internet
large in a carefully controlled manner. The Intranet is presumed
be used by corporate employees for business purposes, and
interconnect hosts that carry sensitive or confidential information
It is also held to a higher standard of operational availability
the Internet at large. Its usage can be monitored and controlled,
its resources can be better planned and tuned than those of
public network. These arguments of security and resource
have ensured the dominance of the Intranet model in most
and campuses
The emergence of the Intranet model has had a profound effect on
notion of application transparency. Many corporate network
feel it is for them alone to determine which applications
traverse the Internet/Intranet boundary. In this world view,
transparency may seem to be an unimportant consideration
3.2 Dynamic address
3.2.1 SLIP and
It is to be noted that with the advent of vast numbers of dial-
Internet users, whose addresses are allocated at dial-up time,
whose traffic may be tunneled back to their home ISP, the actual
addresses of such users are purely transient. During their period
validity they can be relied on end-to-end, but they must be
at the end of every session. In particular they can have no
association with the domain name of the host borrowing them
3.2.2
Similarly, LAN-based users of the Internet today frequently use
to acquire a new address at system restart, so here again the
value of the address is potentially transient and must not be
between sessions
3.3
3.3.1 Basic
Intranet managers have a major concern about security:
traffic must be kept out of the Intranet at all costs. This
led directly to the firewall concept (a system that intercepts
traffic between the Internet and the Intranet, and only lets
Carpenter Informational [Page 6]
RFC 2775 Internet Transparency February 2000
selected traffic, usually belonging to a very limited set
applications). Firewalls, by their nature, fundamentally
transparency
3.3.2
A footnote to the effect of firewalls is the SOCKS mechanism [
1928] by which untrusted applications such as telnet and ftp
punch through a firewall. SOCKS requires a shim library in
Intranet client, and a server in the firewall which is essentially
application level relay. As a result, the remote server does not
the real client; it believes that the firewall is the client
3.4 Private
When the threat of IPv4 address exhaustion first arose, and in
cases user sites were known to be "pirating" addresses for
use, a set of official private addresses were hurriedly
[RFC 1597] and later more carefully defined [BCP 5]. The
existence of such an address allocation proved to very appealing,
Intranets with large numbers of non-global addresses came
existence. Unfortunately, such addresses by their nature cannot
used for communication across the public Internet; without
measures, hosts using private addresses are cut off from the world
Note that private address space is sometimes asserted to be
security feature, based on the notion that outside knowledge
internal addresses might help intruders. This is a false argument
since it is trivial to hide addresses by suitable access
lists, even if they are globally unique - indeed that is a
feature of a filtering router, the simplest form of firewall.
system with a hidden address is just as private as a system with
private address. There is of course no possible point in hiding
addresses of servers to which outside access is required
It is also worth noting that the IPv6 equivalent of
addresses, i.e. site-local addresses, have similar characteristics
BCP 5 addresses, but their use will not be forced by a lack
globally unique IPv6 addresses
3.5 Network address
Network address translators (NATs) are an almost
consequence of the existence of Intranets using private addresses
needing to communicate with the Internet at large.
architectural implications are discussed at length in [NAT-ARCH],
fundamental point being that address translation on the fly
end-to-end address transparency and breaks any middleware
Carpenter Informational [Page 7]
RFC 2775 Internet Transparency February 2000
applications that depend on it. Numerous protocols, for
H.323, carry IP addresses at application level and fail to traverse
simple NAT box correctly. If the full range of Internet
is to be used, NATs have to be coupled with application
gateways (ALGs) or proxies. Furthermore, the ALG or proxy must
updated whenever a new address-dependent application comes along.
practice, NAT functionality is built into many firewall products,
all useful NATs have associated ALGs, so it is difficult
disentangle their various impacts
3.6 Application level gateways, relays, proxies, and
It is reasonable to position application level gateways, relays
proxies, and caches at certain critical topological points
especially the Intranet/Internet boundary. For example, if
Intranet does not use SMTP as its mail protocol, an SMTP gateway
needed. Even in the normal case, an SMTP relay is common, and
perform useful mail routing functions, spam filtering, etc. (It
be observed that spam filtering is in some ways a firewall function
but the store-and-forward nature of electronic mail and
availability of MX records allow it to be a distinct and
function.)
Similarly, for a protocol such as HTTP with a well-defined
proxy mechanism, application proxies also serving as caches are
useful. Although these devices interfere with transparency, they
so in a precise way, correctly terminating network, transport
application protocols on both sides. They can however exhibit
shortfalls in ease of configuration and failover
However, there appear to be cases of "involuntary" applications
devices such as proxies that grab and modify HTTP traffic
using the appropriate mechanisms, sometimes known as "
caches", or mail relays that purport to remove undesirable words
These devices are by definition not transparent, and may have
unforeseeable side effects. (A possible conclusion is that even
non-store-and-forward protocols, a generic diversion
analogous to the MX record would be of benefit. The SRV record [
2052] is a step in this direction.)
3.7 Voluntary isolation and peer
There are communities that think of themselves as being so
that they require isolation via an explicit proxy, and even by
proprietary protocols and addressing schemes within their network.
example is the WAP Forum which targets very small phone-like
with some capabilities for Internet connectivity. However, it's
Carpenter Informational [Page 8]
RFC 2775 Internet Transparency February 2000
the Internet they're connecting directly to. They have to go
a proxy. This could potentially mean that millions of devices
never know the benefits of end-to-end connectivity to the Internet
A similar effect arises when applications such as telephony span
an IP network and a peer network layer using a different technology
Although the application may work end-to-end, there is no
of end-to-end packet transmission
3.8 Split
Another consequence of the Intranet/Internet split is "split DNS"
"two faced DNS", where a corporate network serves up partly
completely different DNS inside and outside its firewall. There
many possible variants on this; the basic point is that
correspondence between a given FQDN (fully qualified domain name)
a given IPv4 address is no longer universal and stable over
periods
3.9 Various load-sharing
IPv4 was not designed to support anycast [RFC 1546], so there is
natural approach to load-sharing when one server cannot do the job
Various tricks have been used to resolve this (multicast to find
free server, the DNS returns different addresses for the same FQDN
a round-robin, a router actually routes packets sent to the
address automatically to different servers, etc.). While these
are not particularly harmful in the overall picture, they can
implemented in such a way as to interfere with name or
transparency
4. Summary of current status and
It is impossible to estimate with any numerical reliability
widely the above inventions have been deployed. Since many of
preserve the illusion of transparency while actually interfering
it, they are extremely difficult to measure
However it is certain that all the mechanisms just described are
very widespread use; they are not a marginal phenomenon. In
networks, many of them are the norm. Some of them (firewalls, relays
proxies and caches) clearly have intrinsic value given the
concept. The others are largely artefacts and pragmatic responses
various pressures in the operational Internet, and they must
costing the industry very dearly in constant administration
complex fault diagnosis
Carpenter Informational [Page 9]
RFC 2775 Internet Transparency February 2000
In particular, the decline of transparency is having a severe
on deployment of end-to-end IP security. The Internet security
[SECMECH] calls for security at several levels (roughly, network
applications, and object levels). The current network level
model [RFC 2401] was constructed prior to the recognition that end
to-end address transparency was under severe threat.
alternative proposals have begun to emerge [HIP] the current
is that IPSEC cannot be deployed end-to-end in the general case
Tunnel-mode IPSEC can be deployed between corporate gateways
firewalls. Transport-mode IPSEC can be deployed within a
network in some cases, but it cannot span from Intranet to
and back to another Intranet if there is any chance of a NAT
the way
Indeed, NAT breaks other security mechanisms as well, such as
and Kerberos, since they rely on address values
The loss of transparency brought about by private addresses and
affects many applications protocols to a greater or lesser extent
This is explored in detail in [NAT-PROT]. A more subtle effect
that the prevalence of dynamic addresses (from DHCP, SLIP and PPP
has fed upon the trend towards client/server computing. Today it
largely true that servers have fixed addresses, clients have
addresses, and servers can in no way assume that a client's
address identifies the client. On the other hand, clients rely
servers having stable addresses since a DNS lookup is the
generally deployed mechanism by which a client can find a server
solicit service. In this environment, there is little scope for
peer-to-peer applications protocols, and no easy solution for
servers. Indeed, the very limited demand for Mobile IP might
partly attributed to the market dominance of client/
applications in which the client's address is of
significance. We also see a trend towards single points of
such as media gateways, again resulting from the difficulty
implementing peer-to-peer solutions directly between clients with
fixed address
The notion that servers can use precious globally unique
from a small pool, because there will always be fewer servers
clients, may become anachronistic when most electrical devices
network-manageable and thus become servers for a management protocol
Similarly, if every PC becomes a telephone (or the converse),
of receiving unsolicited incoming calls, the lack of stable
addresses for PCs will be an issue. Another impending paradigm
is when domestic and small-office subscribers move from dial-up
always-on Internet connectivity, at which point transient
assignment from a pool becomes much less appropriate
Carpenter Informational [Page 10]
RFC 2775 Internet Transparency February 2000
Many of the inventions described in the previous section lead to
datagram traffic between two hosts being directly or
mediated by at least one other host. For example a client may
on a DHCP server, a server may depend on a NAT, and any host
depend on a firewall. This violates the fate-sharing principle
[Saltzer] and introduces single points of failure. Worse, most
these points of failure require configuration data, yet
source of operational risk. The original notion that datagrams
find their way around failures, especially around failed routers,
been lost; indeed the overloading of border routers with
functions has turned them into critical rather than
components, even for multihomed sites
The loss of address transparency has other negative effects.
example, large scale servers may use heuristics or even
policies that assign different priorities to service for
clients, based on their addresses. As addresses lose their
meaning, this mechanism will fail. Similarly, any anti-spam or anti
spoofing techniques that rely on reverse DNS lookup of address
can be confused by translated addresses. (Uncoordinated
can have similar disadvantages.)
The above issues are not academic. They add up to complexity
applications design, complexity in network configuration,
in security mechanisms, and complexity in network management
Specifically, they make fault diagnosis much harder, and
introducing more single points of failure, they make faults
likely to occur
5. Possible future
5.1 Successful migration to IPv
In this scenario, IPv6 becomes fully implemented on all hosts
routers, including the adaptation of middleware, applications,
management systems. Since the address space then becomes big
for all conceivable needs, address transparency can be restored
Transport-mode IPSEC can in principle deploy, given adequate
policy tools and a key infrastructure. However, it is
believed that the Intranet/firewall model will certainly persist
Note that it is a basic assumption of IPv6 that no
constraints will be placed on the supply of addresses, given
there are so many of them. Current practices by which some
strongly limit the number of IPv4 addresses per client will have
reason to exist for IPv6. (However, addresses will still be
prudently, according to guidelines designed to favour
routing.)
Carpenter Informational [Page 11]
RFC 2775 Internet Transparency February 2000
Clearly this is in any case a very long term scenario, since
assumes that IPv4 has declined to the point where IPv6 is
for universal connectivity. Thus, a viable version of Scenario 5.3
a prerequisite for Scenario 5.1.
5.2 Complete failure of IPv
In this scenario, IPv6 fails to reach any significant level
operational deployment, IPv4 addressing is the only
mechanism, and address transparency cannot be restored. IPSEC
be deployed globally in its current form. In the very long term,
pool of globally unique IPv4 addresses will be nearly
allocated, and new addresses will generally not be available for
purpose
It is unclear exactly what is likely to happen if the
continues to rely exclusively on IPv4, because in that eventuality
variety of schemes are likely to promulgated, with a view
providing an acceptable evolutionary path for the network. However
we can examine two of the more simplistic sub-scenarios which
possible, while realising that the future would be unlikely to
either one exactly
5.2.1 Re-allocating the IPv4 address
Suppose that a mechanism is created to continuously recover and re
allocate IPv4 addresses. A single global address space is maintained
with all sites progressively moving to an Intranet private
model, with global addresses being assigned temporarily from a
of several billion
5.2.1.1 A sub-sub-scenario of this is generalised use of NAT and
(NAT with port number translation). This has the
that the host is unaware of the unique address being used
its traffic, being aware only of its ambiguous
address, with all the problems that this generates.
[NAT-ARCH].
5.2.1.2 Another sub-sub-scenario is the use of realm-specific
addressing implemented at the host rather than by a NAT box
See [RSIP]. In this case the host is aware of its
address, allowing for substantial restoration of the end-to
end usefulness of addresses, e.g. for TCP or
checksums
Carpenter Informational [Page 12]
RFC 2775 Internet Transparency February 2000
5.2.1.3 A final sub-sub-scenario is the "map and encapsulate"
in which address translation is replaced by
encapsulation of all packets for wide-area transport.
model has never been fully developed, although it
completely compatible with end-to-end addressing
5.2.2
Suppose that no mechanism is created to recover addresses (
perhaps black or open market trading). Sites with large
blocks keep them. All the scenarios of 5.2.1 appear but
insufficient. Eventually the global address space is no
adequate. This is a nightmare scenario - NATs appear within
"global" address space, for example at ISP-ISP boundaries. It
unclear how a global routing system and a global DNS system can
maintained; the Internet is permanently fragmented
5.3 Partial deployment of IPv
In this scenario, IPv6 is completely implemented but only deploys
certain segments of the network (e.g. in certain countries, or
certain areas of application such as mobile hand-held devices).
Instead of being transitional in nature, some of the IPv6
techniques become permanent features of the landscape.
addresses are 32 bits, sometimes they are 128 bits. DNS lookups
return either or both. In the 32 bit world, the scenarios 5.2.1
5.2.2 may occur. IPSEC can only deploy partially
6.
None of the above scenarios is clean, simple and straightforward
Although the pure IPv6 scenario is the cleanest and simplest, it
not straightforward to reach it. The various scenarios without use
IPv6 are all messy and ultimately seem to lead to dead ends of
kind or another. Partial deployment of IPv6, which is a required
on the road to full deployment, is also messy but avoids the
ends
7. Security
The loss of transparency is both a bug and a feature from
security viewpoint. To the extent that it prevents the end-to-
deployment of IPSEC, it damages security and creates vulnerabilities
For example, if a standard NAT box is in the path, then the best
can be done is to decrypt and re-encrypt IP traffic in the NAT.
traffic will therefore be momentarily in clear text and
vulnerable. Furthermore, the NAT will possess many keys and will be
prime target of attack. In environments where this is unacceptable
Carpenter Informational [Page 13]
RFC 2775 Internet Transparency February 2000
encryption must be applied above the network layer instead, of
with no usage whatever of IP addresses in data that
cryptographically protected. See section 4 for further discussion
In certain scenarios, i.e. 5.1 (full IPv6) and 5.2.1.2 (RSIP), end
to-end IPSEC would become possible, especially using the "
firewalls" model advocated in [Bellovin].
The loss of transparency at the Intranet/Internet boundary may
considered a security feature, since it provides a well defined
at which to apply restrictions. This form of security is subject
the "crunchy outside, soft inside" risk, whereby any
penetration of the boundary exposes the entire Intranet to
attack. The lack of end-to-end security applied within the
also ignores insider threats
It should be noted that security applied above the transport level
such as SSL, SSH, PGP or S/MIME, is not affected by network
transparency issues
This document and the related issues have been discussed
by the IAB. Special thanks to Steve Deering for a detailed review
to Noel Chiappa. Useful comments or ideas were also received from
Austein, John Bartas, Jim Bound, Scott Bradner, Vint Cerf,
Dawkins, Anoop Ghanwani, Erik Guttmann, Eric A. Hall, Graham Klyne
Dan Kohn, Gabriel Montenegro, Thomas Narten, Erik Nordmark,
Paxson, Michael Quinlan, Eric Rosen, Daniel Senie,
Schulzrinne, Bill Sommerfeld, and George Tsirtsis
[Bellovin] Distributed Firewalls, S. Bellovin, available
http://www.research.att.com/~smb/papers/distfw.pdf
http://www.research.att.com/~smb/papers/distfw.ps (
in progress).
[Berners-Lee] Weaving the Web, T. Berners-Lee, M. Fischetti
HarperCollins, 1999, p 208.
[Saltzer] End-To-End Arguments in System Design, J.H. Saltzer
D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4,
November 1984, pp 277-288.
[IEN 48] Cerf, V., "The Catenet Model for Internetworking,"
Information Processing Techniques Office,
Advanced Research Projects Agency, IEN 48, July 1978.
Carpenter Informational [Page 14]
RFC 2775 Internet Transparency February 2000
[CATENET] Pouzin, L., "A Proposal for Interconnecting
Switching Networks," Proceedings of EUROCOMP,
University, May 1974, pp. 1023-36.
[STD 7] Postel, J., "Transmission Control Protocol", STD 7,
793, September 1981.
[RFC 1546] Partridge, C., Mendez, T. and W. Milliken, "
Anycasting Service", RFC 1546, November 1993.
[RFC 1597] Rekhter, Y., Moskowitz, B., Karrenberg, D. and G.
Groot, "Address Allocation for Private Internets",
1597, March 1994.
[RFC 1633] Braden, R., Clark, D. and S. Shenker, "
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC 1889] Schulzrinne, H., Casner, S., Frederick, R. and V
Jacobson, "RTP: A Transport Protocol for Real-
Applications", RFC 1889, January 1996.
[BCP 5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot
G. and E. Lear, "Address Allocation for
Internets", BCP 5, RFC 1918, February 1996.
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D
and L. Jones, "SOCKS Protocol Version 5", RFC 1928,
March 1996.
[RFC 1958] Carpenter, B., "Architectural Principles of
Internet", RFC 1958, June 1996.
[RFC 2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "
Selective Acknowledgement Options", RFC 2018,
1996.
[RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for
the location of services (DNS SRV)", RFC 2052,
1996.
[RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv
Address Behaviour Today", RFC 2101, February 1997.
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF
Services", RFC 2210, September 1997.
Carpenter Informational [Page 15]
RFC 2775 Internet Transparency February 2000
[RFC 2309] Braden, B., Clark, D., Crowcroft, J., Davie, B.,
Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
Minshall, G., Partridge, C., Peterson, L.,
Ramakrishnan, K., Shenker, S., Wroclawski, J. and L
Zhang, "Recommendations on Queue Management
Congestion Avoidance in the Internet", RFC 2309,
1998.
[RFC 2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture
the Internet Protocol", RFC 2401, November 1998.
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z
and W. Weiss, "An Architecture for
Service", RFC 2475, December 1998.
[RFC 2581] Allman, M., Paxson, V. and W. Stevens, "TCP
Control", RFC 2581, April 1999.
[NAT-ARCH] Hain, T., "Architectural Implications of NAT", Work
Progress
[NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol
with the IP Network Address Translator (NAT)", Work
Progress
[SECMECH] Bellovin, S., "Security Mechanisms for the Internet",
Work in Progress
[RSIP] Lo, J., Borella, M. and D. Grabelsky, "Realm
IP: A Framework", Work in Progress
[HIP] Moskowitz, R., "The Host Identity Payload", Work
Progress
Carpenter Informational [Page 16]
RFC 2775 Internet Transparency February 2000
Author's
Brian E.
c/o
Suite 150
1890 Maple
Evanston, IL 60201
EMail: brian@icair.
Carpenter Informational [Page 17]
RFC 2775 Internet Transparency February 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Carpenter Informational [Page 18]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
