As per Relevance of the word workshop, we have this rfc below:
Network Working Group M.
Request for Comments: 2956 SURFnet ExpertiseCentrum
Category: Informational October 2000
Overview of 1999 IAB Network Layer
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 is an overview of a workshop held by the
Architecture Board (IAB) on the Internet Network Layer
hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999.
goal of the workshop was to understand the state of the network
and its impact on continued growth and usage of the Internet
Different technical scenarios for the (foreseeable) future and
impact of external influences were studied. This report lists
conclusions and recommendations to the Internet Engineering
Force (IETF) community
Table of
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conclusions and Observations . . . . . . . . . . . . . . . 3
2.1 Transparency. . . . . . . . . . . . . . . . . . . . . . 3
2.2 NAT, Application Level Gateways & Firewalls . . . . . . 4
2.3 Identification and Addressing . . . . . . . . . . . . . 4
2.4 Observations on Address Space . . . . . . . . . . . . . 5
2.5 Routing Issues. . . . . . . . . . . . . . . . . . . . . 5
2.6 Observations on Mobility. . . . . . . . . . . . . . . . 6
2.7 DNS Issues. . . . . . . . . . . . . . . . . . . . . . . 7
2.8 NAT and RSIP. . . . . . . . . . . . . . . . . . . . . . 7
2.9 NAT, RSIP and IPv6. . . . . . . . . . . . . . . . . . . 8
2.10 Observations on IPv6. . . . . . . . . . . . . . . . . . 9
3. Recommendations. . . . . . . . . . . . . . . . . . . . . . 10
3.1 Recommendations on Namespace . . . . . . . . . . . . . . 10
3.2 Recommendations on RSIP. . . . . . . . . . . . . . . . . 10
3.3 Recommendations on IPv6. . . . . . . . . . . . . . . . . 10
3.4 Recommendations on IPsec . . . . . . . . . . . . . . . . 11
Kaat Informational [Page 1]
RFC 2956 1999 IAB Network Layer Workshop October 2000
3.5 Recommendations on DNS . . . . . . . . . . . . . . . . . 11
3.6 Recommendations on Routing . . . . . . . . . . . . . . . 12
3.7 Recommendations on Application Layer and APIs. . . . . . 12
4. Security Considerations. . . . . . . . . . . . . . . . . . 12
References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Participants. . . . . . . . . . . . . . . . . . . 15
Author's Address. . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
1.
From July 7 to July 9, 1999 the Internet Architecture Board (IAB
held a workshop on the architecture of the Internet Network Layer
The Network Layer is usually referred to as the IP layer. The
of the workshop was to discuss the current state of the Network
and the impact various currently deployed or future mechanisms
technologies might have on the continued growth and usage of
Internet
The most important issues to be discussed were
o Status of IPv6 deployment and transition
o Alternative technical strategies in case IPv6 is not
o Globally unique addresses and 32 bit address
o Global connectivity and
o Fragmentation of the
o End to end transparency and the progressive loss
o End to end
o Complications of address sharing mechanisms (NAT, RSIP
o Separation of identification and location in
o Architecture and scaling of the current routing
The participants looked into several technical scenarios
discussed the feasibility and probability of the deployment of
scenario. Among the scenarios were for example full migration
IPv6, IPv6 deployment only in certain segments of the network,
significant deployment of IPv6 and increased segmentation of the IPv
address space due to the use of NAT devices
Based on the discussion of these scenarios several trends
external influences were identified which could have a large
on the status of the network layer, such as the deployment
wireless network technologies, mobile networked devices and
purpose IP devices
Kaat Informational [Page 2]
RFC 2956 1999 IAB Network Layer Workshop October 2000
The following technical issues were identified to be important goals
o Deployment of end to end
o Deployment of end to end
o Global connectivity and reachability should be
o It should be easy to deploy new
o It should be easy to connect new hosts and networks to
Internet ("plug and ping")
By the notion "deployment of end to end transport" it is meant
it is a goal to be able to deploy new applications that span from
host to any other host without intermediaries, and this
transport protocols with similar span (see also [1]).
This document summarizes the conclusions and recommendations made
the workshop. It should be noted that not all participants
with all of the statements, and it was not clear whether
agreed with all of them. The recommendations made however are
on strong consensus among the participants
2. Conclusions and
The participants came to a number of conclusions and observations
several of the issues mentioned in section 1. In the
sections 2.1-2.10 these conclusions will be described
2.1
In the discussions transparency was referred to as the
Internet concept of a single universal logical addressing scheme
the mechanisms by which packets may flow from source to
essentially unaltered [1]. This traditional end to end
has been lost in the current Internet, specifically the
that IPv4 addresses are globally unique or invariant is no
true
There are multiple causes for the loss of transparency, for
the deployment of network address translation devices, the use
private addresses, firewalls and application level gateways,
and caches. These mechanisms increase fragmentation of the
layer, which causes problems for many applications on the Internet
It adds up to complexity in applications design and inhibits
deployment of new applications. In particular, it has a
effect on the deployment of end to end IP security
Kaat Informational [Page 3]
RFC 2956 1999 IAB Network Layer Workshop October 2000
Another consequence of fragmentation is the deployment of "split DNS
or "two faced DNS", which means that the correspondence between
given FQDN and an IPv4 address is no longer universal and stable
long periods (see section 2.7).
End to end transparency will probably not be restored due to the
that some of the mechanisms have an intrinsic value (e.g. firewalls
caches and proxies) and the loss of transparency may be considered
some as a security feature. It was however concluded that end to
transparency is desirable and an important issue to pursue
Transparency is further explored in [1].
2.2 NAT, Application Level Gateways &
The previous section indicated that the deployment of NAT (
Address Translation), Application Level Gateways and firewalls
loss of network transparency. Each of them is incompatible
certain applications because they interfere with the assumption
end to end transparency. NAT especially complicates setting
servers, peer to peer communications and "always-on" hosts as
endpoint identifiers, i.e. IP addresses, used to set up
are globally ambiguous and not stable (see [2]).
NAT, application level gateways and firewalls however are
increasingly widely deployed as there are also advantages to each
either real or perceived. Increased deployment causes a
decline of network transparency and this inhibits the deployment
new applications. Many new applications will require
Application Level Gateways (ALGs) to be added to NAT devices,
those applications will work correctly when running through a
device. However, some applications cannot operate effectively
NAT even with an ALG
2.3 Identification and
In the original IPv4 network architecture hosts are globally
permanently and uniquely identified by an IPv4 address. Such an
address is used for identification of the node as well as
locating the node on the network. IPv4 in fact mingles the
of node identity with the mechanism used to deliver packets to
node. The deployment of mechanisms that separate the network
multiple address spaces breaks the assumption that a host can
uniquely identified by a single IP address. Besides that, hosts
wish to move to a different location in the network but keep
identity the same. The lack of differentiation between the
and the location of a host leads to a number of problems in
current architecture
Kaat Informational [Page 4]
RFC 2956 1999 IAB Network Layer Workshop October 2000
Several technologies at this moment use tunneling techniques
overcome the problem or cannot be deployed in the case of
address spaces. If a node could have some sort of a
identifier or endpoint name this would help in solving a number
problems
It was concluded that it may be desirable on theoretical grounds
separate the node identity from the node locator. This is
true for IPsec, since IP addresses are used (in transport mode)
identifiers which are cryptographically protected and hence
remain unchanged during transport. However, such a separation
identity and location will not be available as a near-term solution
and will probably require changes to transport level protocols
However, the current specification of IPsec does allow to use
other identifier than an IP address
2.4 Observations on Address
There is a significant risk that a single 32 bit global address
is insufficient for foreseeable needs or desires. The participants
opinions about the time scale over which new IPv4 addresses
still be available for assignment ranged from 2 to 20 years
However, there is no doubt that at the present time, users
obtain as much IPv4 address space as they desire. This is partly
result of the current stewardship policies of the Regional
Registries (RIRs).
It was concluded that it ought to be possible for anybody to
global addresses when required or desired. The absence of
inhibits the deployment of some types of applications. It
however be noted that there will always be administrative boundaries
firewalls and intranets, because of the need for security and
implementation of policies. NAT is seen as a
complication on these boundaries. It is often perceived as
security feature because people are confusing NATs with firewalls
2.5 Routing
A number of concerns were raised regarding the scaling of the
routing system. With current technology, the number of prefixes
can be used is limited by the time taken for the routing algorithm
converge, rather than by memory size, lookup time, or some
factor. The limit is unknown, but there is some speculation,
extremely unclear validity, that it is on the order of a few
thousand prefixes. Besides the computational load of
routing tables, the time it takes to distribute routing
across the network, the robustness and security of the
routing system are also important issues. The only known
Kaat Informational [Page 5]
RFC 2956 1999 IAB Network Layer Workshop October 2000
scheme which produces scalable routing mechanisms depends
topologically aggregated addresses, which requires that
renumber when their position in the global topology changes
Renumbering remains operationally difficult and expensive ([3], [4]).
It is not clear whether the deployment of IPv6 would solve
current routing problems, but it should do so if it makes
easier
At least one backbone operator has concerns about the
time of internetwork-wide routing during a failover. This
believes that current convergence times are on the order of half
minute, and possibly getting worse. Others in the routing
did not believe that the convergence times are a current issue. Some
who believe that real-time applications (e.g. telephony)
sub-second convergence, are concerned about the implications
convergence times of a half minute on such applications
Further research is needed on routing mechanisms that might
palliate the current entropy in the routing tables, and can
reduce the convergence time of routing computations
The workshop discussed global routing in a hypothetical scenario
no distinguished root global address space. Nobody had an idea
to make such a system work. There is currently no well-
proposal for a new routing system that could solve such a problem
For IPv6 routing in particular, the GSE/8+8 proposal and IPNG
analysis of this proposal ([5]) are still being examined by the IESG
There is no consensus in the workshop whether this proposal could
made deployable
2.6 Observations on
Mobility and roaming require a globally unique identifier. This
not have to be an IP address. Mobile nodes must have a widely
identifier for their location on the network, which is an issue
private IP addresses are used or the IP address is ambiguous (
also section 2.3). Currently tunnels are used to route traffic to
mobile node. Another option would be to maintain state
at intermediate points in the network if changes are made to
packets. This however reduces the flexibility and it breaks the
to end model of the network. Keeping state in the network is
considered a bad thing. Tunnels on the other hand reduce the
size. Mobility was not discussed in detail as a separate
workshop is planned on this topic
Kaat Informational [Page 6]
RFC 2956 1999 IAB Network Layer Workshop October 2000
2.7 DNS
If IPv6 is widely deployed, the current line of thinking is that
renumbering will be significantly more frequent than today.
will have an impact on DNS updates. It is not clear what the
of DNS updates might be, but in the most aggressive models it
be millions a day. Deployment of the A6 record type which is
to map a domain name to an IPv6 address, with the provision
indirection for leading prefix bits, could make this possible ([6]).
Another issue is the security aspect of frequent updates, as
would have to been done dynamically. Unless we have fully
DNS, it could increase security risks. Cached TTL values
introduce problems as the cached records of renumbered hosts will
be updated in time. This will become especially a problem if
renumbering is needed
Another already mentioned issue is the deployment of split DNS (
section 2.1). This concept is widely used in the Intranet model
where the DNS provides different information to inside and
queries. This does not necessarily depend on whether
addresses are used on the inside, as firewalls and policies may
make this desirable. The use of split DNS seems inevitable
Intranets will remain widely deployed. But operating a split
raises a lot of management and administrative issues. As a
around, a DNS Application Level Gateway ([7]) (perhaps as
extension to a NAT device) may be deployed, which intercepts
messages and modifies the contents to provide the
answers. This has the disadvantage that it interferes with the
of DNSSEC ([8]).
The deployment of split DNS, or more generally the existence
separate name spaces, makes the use of Fully Qualified Domain
(FQDNs) as endpoint identifiers more complex
2.8 NAT and
Realm-Specific IP (RSIP), a mechanism for use with IPv4, is a
item of the IETF NAT WG. It is intended as an alternative (or as
complement) to network address translation (NAT) for IPv4, but
uses are possible (for example, allowing end to end traffic
firewalls). It is similar to NAT, in that it allows sharing a
number of external IPv4 addresses among a number of hosts in a
address domain (called a 'realm'). However, it differs from NAT
that the hosts know that different externally-visible IPv4
are being used to refer to them outside their local realm, and
Kaat Informational [Page 7]
RFC 2956 1999 IAB Network Layer Workshop October 2000
know what their temporary external address is. The addresses
other information are obtained from an RSIP server, and the
are tunneled across the first routing realm ([9], [10]).
The difference between NAT and RSIP - that an RSIP client is aware
the fact that it uses an IP address from another address space,
with NAT, neither endpoint is aware that the addresses in the
are being translated - is significant. Unlike NAT, RSIP has
potential to work with protocols that require IP addresses to
unmodified between the source and destination. For example,
NAT gateways preclude the use of IPsec across them, RSIP servers
allow it [11].
The addition of RSIP to NATs may allow them to support
applications that cannot work with traditional NAT ([12]), but
does require that hosts be modified to act as RSIP clients.
requires changes to the host's TCP/IP stack, any layer-three
that needs to be made RSIP-aware will have to be modified (e.g. ICMP
and certain applications may have to be changed. The exact
needed to host or application software are not quite well known
this moment and further research into RSIP is required
Both NAT and RSIP assume that the Internet retains a core of
address space with a coherent DNS. There is no fully prepared
for NAT or RSIP without such a core; therefore NAT and RSIP face
uncertain future whenever the IPv4 address space is finally
(see section 2.4). Thus it is also a widely held view that in
longer term the complications caused by the lack of globally
addresses, in both NAT and RSIP, might be a serious handicap ([1]).
If optimistic assumptions are made about RSIP (it is still
defined and a number of features have not been implemented yet),
combination of NAT and RSIP seems to work in most cases.
RSIP introduces specific new problems, as well as removing some
the NAT issues, remains to be determined
Both NAT and RSIP may have trouble with the future
application, especially when this needs QoS features, security and/
multicast. And if it needs peer to peer communication (i.e.
would be no clear distinction between a server and a client)
assumes "always-on" systems, this would probably be complex with
NAT and RSIP (see also section 2.2).
2.9 NAT, RSIP and IPv
Assuming IPv6 is going to be widely deployed, network
translation techniques could play an important role in the
process from IPv4 to IPv6 ([13]). The impact of adding RSIP
Kaat Informational [Page 8]
RFC 2956 1999 IAB Network Layer Workshop October 2000
to hosts is not quite clear at this moment, but it is less
adding IPv6 support since most applications probably don't need to
changed. And RSIP needs no changes to the routing infrastructure
but techniques such as automatic tunneling ([14]) and 6to4 ([15])
would also allow IPv6 traffic to be passed over the existing IPv
routing infrastructure. While RSIP is principally a tool
extending the life of IPv4, it is not a roadblock for the
to IPv6. The development of RSIP is behind that of IPv6, and
study into RSIP is required to determine what the issues with
might be
2.10 Observations on IPv
An important issue in the workshop was whether the deployment of IPv
is feasible and probable. It was concluded that the transition
IPv6 is plausible modulo certain issues. For example
need to be ported to IPv6, and production protocol stacks
production IPv6 routers should be released. The core protocols
finished, but other standards need to be pushed forward (e.g. MIBs).
A search through all RFCs for dependencies on IPv4 should be made,
was done for the Y2K problem, and if problems are found they must
resolved. As there are serious costs in implementing IPv6 code,
business arguments are needed to promote IPv6.
One important question was whether IPv6 could help solve the
problems in the routing system and make the Internet scale better
It was concluded that "automatic" renumbering is really
when prefixes are to be changed periodically to get the
topology and routing optimized. This also means that any IP
and configuration dependencies in protocols and applications
have to be removed ([3]). One example that was mentioned is the
of IP addresses in the PKI (IKE). There might also be
issues with "automatic" renumbering as DNS records have to be
dynamically (see also section 2.7).
Realistically, because of the dependencies mentioned, IPv
renumbering cannot be truly automatic or instantaneous, but it
the potential to be much simpler operationally than IPv4 renumbering
and this is critical to market and ISP acceptance of IPv6.
Another issue is whether existing TCP connections (using the
address(es)) should be maintained across renumbering. This
make things much more complex and it is foreseen that old and
addresses would normally overlap for a long time
There was no consensus on how often renumbering would take place
how automatic it can be in practice; there is not much
with renumbering (maybe only for small sites).
Kaat Informational [Page 9]
RFC 2956 1999 IAB Network Layer Workshop October 2000
3.
3.1 Recommendation on
The workshop recommends the IAB to appoint a panel to make
recommendations to the IETF about
i) whether we should encourage more parts of the stack to adopt
namespace for end to end interactions, so that a) NAT
'better', and b) we have a little more independence between
internetwork and transport and above layers
ii) if so, whether we should have a single system-wide
for this function, or whether it makes more sense to
various subsystems to chose the namespace that makes sense
them
iii) and also, what namespace(s) [depending on the output of
point above] that ought to be
3.2 Recommendations on
RSIP is an interesting idea, but it needs further refinement
study. It does not break the end to end network model in the
way as NAT, because an RSIP host has explicit knowledge of
temporary global address. Therefore, RSIP could solve some of
issues with NAT. However, it is premature to recommend it as
mainstream direction at this time
It is recommended that the IETF should actively work on RSIP,
the details and study the issues
3.3 Recommendations on IPv
3.3.1
The current model of TLA-based addressing and routing should
actively pursued. However, straightforward site renumbering
TLA addresses is really needed, should be as nearly automatic
possible, and should be shown to be real and credible by the IPv
community
3.3.2
Network address translation techniques, in addition to
immediate use in pure IPv4 environments, should also be viewed
part of the starting point for migration to IPv6. Also RSIP,
successful, can be a starting point for IPv6 transition
Kaat Informational [Page 10]
RFC 2956 1999 IAB Network Layer Workshop October 2000
While the basic concepts of the IPv4 specific mechanisms NAT and
are also being used in elements of the proposed migration path
IPv6 (in NAT-PT for NAT, and SIIT and AIIH for RSIP), NAT and
for IPv4 are not directly part of a documented transition path
IPv6.
The exact implications, for transition to IPv6, of having NAT
RSIP for IPv4 deployed, are not well understood. Strategies
transition to IPv6, for use in IPv4 domains using NAT and RSIP
IPv4, should be worked out and documented by the IETF
3.3.3
The draft analysis of the 8+8/GSE proposal should be evaluated by
IESG and accepted or rejected, without disturbing ongoing IPv
deployment work. The IESG should use broad expertise,
liaison with the endpoint namespace panel (see section 3.1) in
evaluation
3.4 Recommendations on
It is urgent that we implement and deploy IPsec using some
identifier than 32-bit IP addresses (see section 2.3). The
IPsec specifications support the use of several different
types (e.g. Domain Name, User@Domain Name). The IETF should
implementation and deployment of non-address Identities with IPsec
We strongly urge the IETF to completely deprecate the use of
binary 32-bit IP addresses within IPsec, except in certain
limited circumstances, such as router to router tunnels;
particular any IP address dependencies should be eliminated
ISAKMP and IKE
Ubiquitous deployment of the Secure DNS Extensions ([8]) should
strongly encouraged to facilitate widespread deployment of
(including IKE) without address-based Identity types
3.5 Recommendations on
Operational stability of DNS is paramount, especially during
transition of the network layer, and both IPv6 and some
address translation techniques place a heavier burden on DNS. It
therefore recommended to the IETF that, except for those changes
are already in progress and will support easier renumbering
networks and improved security, no fundamental changes or
to the DNS be made for the foreseeable future
In order to encourage widespread deployment of IPsec,
deployment of DNSSEC is recommended to the operational community
Kaat Informational [Page 11]
RFC 2956 1999 IAB Network Layer Workshop October 2000
3.6 Recommendations on
The only known addressing scheme which produces scalable
mechanisms depends on topologically aggregated addresses,
requires that sites renumber when their position in the
topology changes. Thus recommendation 3.3.1 is vital for
IPv6.
Although the same argument applies to IPv4, the installed base
simply too large and the PIER working group showed that little can
done to improve renumbering procedures for IPv4. However, NAT and/
RSIP may help
In the absence of a new addressing model to replace
aggregation, and of clear and substantial demand from the
community for a new routing architecture (i.e. path-
mechanism) there is no reason to start work on standards for a "
generation" routing system in the IETF. Therefore, we recommend
work should continue in the IRTF Routing Research Group
3.7 Recommendations on Application layer and
Most current APIs such as sockets are an obstacle to migration to
new network layer of any kind, since they expose network
internal details such as addresses
It is therefore recommended, as originally recommended in RFC 1900
[3], that IETF protocols, and third-party applications, avoid
explicit awareness of IP addresses, when efficient operation of
protocol or application is feasible in the absence of such awareness
Some applications and services may continue to need to be aware of
addresses. Until we once again have a uniform address space for
Internet, such applications and services will necessarily
limited deployability, and/or require ALG support in NATs
Also we recommend an effort in the IETF to generalize APIs to
abstraction from all network layer dependencies, perhaps as a side
effect of the namespace study of section 3.1.
4. Security
The workshop did not address security as a separate topic, but
role of firewalls, and the desirability of end to end deployment
IPsec, were underlying assumptions. Specific recommendations
security are covered in sections 3.4 and 3.5.
Kaat Informational [Page 12]
RFC 2956 1999 IAB Network Layer Workshop October 2000
[1] Carpenter, B., "Internet Transparency", RFC 2775,
2000.
[2] Hain, T., "Architectural Implications of NAT", Work
Progress
[3] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
1900, February 1996.
[4] Ferguson, P and H. Berkowitz, "Network Renumbering Overview
Why would I want it and what is it anyway?", RFC 2071,
1997.
[5] M. Crawford, A. Mankin, T. Narten, J.W. Stewart, III, L. Zhang
"Separating Identifiers and Locators in Addresses: An
of the GSE Proposal for IPv6", Work in Progress
[6] Crawford, M., and C. Huitema, "DNS Extensions to Support IPv
Address Aggregation and Renumbering", RFC 2874, July 2000.
[7] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan
"DNS extensions to Network Address Translators (DNS_ALG)",
2694, September 1999.
[8] Eastlake, D., "Domain Name System Security Extensions",
2535, March 1999.
[9] M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi "Realm
IP: Protocol Specification", Work in Progress
[10] M. Borella, J. Lo, D. Grabelsky, G. Montenegro "Realm
IP: Framework", Work in Progress
[11] G. Montenegro, M. Borella, "RSIP Support for End-to-end IPsec",
Work in Progress
[12] M. Holdrege, P. Srisuresh, "Protocol Complications with the
Network Address Translator", Work in Progress
[13] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
Kaat Informational [Page 13]
RFC 2956 1999 IAB Network Layer Workshop October 2000
[14] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv
Hosts and Routers", RFC 2893, August 2000.
[15] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv
Clouds", Work in Progress
Kaat Informational [Page 14]
RFC 2956 1999 IAB Network Layer Workshop October 2000
Appendix A.
Harald Alvestrand harald@alvestrand.
Ran Atkinson rja@corp.home.
Rob Austein sra@hactrn.
Steve Bellovin smb@research.att.
Randy Bush randy@psg.
Brian E Carpenter brian@hursley.ibm.
Vint Cerf vcerf@MCI.
Noel Chiappa jnc@lcs.mit.
Matt Crawford crawdad@fnal.
Robert Elz kre@munnari.OZ.
Tony Hain tonyhain@microsoft.
Matt Holdrege matt@ipverse.
Erik Huizer huizer@cs.utwente.
Geoff Huston gih@telstra.
Van Jacobson van@cisco.
Marijke Kaat Marijke.Kaat@surfnet.
Daniel Karrenberg Daniel.Karrenberg@ripe.
John Klensin klensin@jck.
Peter Lothberg roll@Stupi.
Olivier H. Martin Olivier.Martin@cern.
Gabriel Montenegro gab@sun.
Keith Moore moore@cs.utk.
Robert (Bob) Moskowitz rgm@htt-consult.
Philip J. Nesser II pjnesser@nesser.
Kathleen Nichols kmn@cisco.
Erik Nordmark nordmark@eng.sun.
Dave Oran oran@cisco.
Yakov Rekhter yakov@cisco.
Bill Sommerfeld sommerfeld@alum.mit.
Bert Wijnen wijnen@vnet.ibm.
Lixia Zhang lixia@cs.ucla.
Author's
Marijke
SURFnet ExpertiseCentrum
P.O. Box 19115
3501 DC
The
Phone: +31 30 230 5305
Fax: +31 30 230 5329
EMail: Marijke.Kaat@surfnet.
Kaat Informational [Page 15]
RFC 2956 1999 IAB Network Layer Workshop October 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
Kaat Informational [Page 16]
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
