One document matched: draft-perlman-rbridge-01.txt
Differences from draft-perlman-rbridge-00.txt
Network Working Group R. Perlman
Internet-Draft Sun
Expires: January 17, 2005 J. Touch
USC/ISI
A. Yegin
Samsung
July 19, 2004
RBridges: Transparent Routing
draft-perlman-rbridge-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This design provides the ability to have an entire campus, with
multiple physical links, look to IP like a single subnet. This
allows zero configuration of the switches within the campus, and
allows nodes to move around within the campus without changing IP
Perlman, et al. Expires January 17, 2005 [Page 1]
Internet-Draft RBridges: Transparent Routing July 2004
addresses. This capability is often provided today with bridges.
Bridges do accomplish this goal. However, bridges have
disadvantages: routing is confined to a spanning tree (precluding
pair-wise shortest paths), the header on which the spanning tree
forwards has no hop count, spanning tree forwarding in the presence
of temporary loops spawns exponential copies of packets, nodes can
have only a single point of attachment, and the spanning tree, in
order to avoid temporary loops, is slow to start forwarding on new
ports. The design in this paper avoids these disadvantages of
bridges while maintaining the advantages. This design works for both
IPv4 and IPv6.
This document is a work in progress; we invite you to participate on
the rbridge mailing list at http://www.postel.org/rbridge
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Detailed RBridge Design . . . . . . . . . . . . . . . . . . . 5
2.1 Link State Protocol . . . . . . . . . . . . . . . . . . . 5
2.2 Spanning Tree . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Designated Bridge . . . . . . . . . . . . . . . . . . . . 6
2.4 Learning endnode location . . . . . . . . . . . . . . . . 6
2.5 Distributed ARP query . . . . . . . . . . . . . . . . . . 7
2.6 Forwarding header . . . . . . . . . . . . . . . . . . . . 7
3. Rbridge Addresses, parameters, and constants . . . . . . . . . 9
4. Handling non-IP packets . . . . . . . . . . . . . . . . . . . 10
5. Handling on-campus IP Packets . . . . . . . . . . . . . . . . 11
6. Handling off-campus IP packets . . . . . . . . . . . . . . . . 12
7. Handling ARP Queries . . . . . . . . . . . . . . . . . . . . . 13
8. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1 Avoiding encapsulation in some cases . . . . . . . . . . . 14
8.1.1 Avoiding encapsulation for on-campus IP packets . . . 14
8.1.2 Avoiding encapsulation for off-campus IP packets . . . 14
8.2 Effects on L3 TTL . . . . . . . . . . . . . . . . . . . . 14
8.3 Using L3 Encapsulation . . . . . . . . . . . . . . . . . . 15
8.4 Topology Issues . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
12.2 Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
Perlman, et al. Expires January 17, 2005 [Page 2]
Internet-Draft RBridges: Transparent Routing July 2004
1. Introduction
In traditional IPv4 and IPv6 networks, each link must have a unique
prefix. This means that a node that moves from one link to another
must change its IP address, and a node with multiple links must have
multiple addresses. It also means that a company with many links
(separated by routers) will have difficulty making full use of its IP
address block (since any link not fully populated will waste
addresses), and routers require significant configuration.
Bridges avoid these problems because bridges can transparently glue
many physical links into what appears to IP to be a single LAN.
However, bridge routing via the spanning tree concentrates traffic
onto selected links, is slow to bring new connectivity on-line
because temporary loops are very dangerous (because there is no hop
count in the header and there may be exponential proliferation of
packets during loops), and routes cannot be pair-wise shortest paths,
but instead whatever path remains after the spanning tree eliminates
redundant paths.
There have been proposals for having routers within a campus
automatically number links with distinct IP subnet numbers. Although
this makes a campus plug-and-play, it requires a large number of IP
subnet numbers, a node must change its address if it moves to a
different link, and addresses of nodes might fluctuate as the
topology changes and links must be renumbered.
NB : the term 'campus' needs to be clearly defined. A campus refers
to a set of links connected by either Rbridges or bridges. In other
words, the campus is terminated by traditional IP routers, in the
same way that an IP subnet would be terminated by an IP router. A
campus will look to IP nodes like a single IP subnet, whether the
interconnection of the links is done with bridges, Rbridges, or some
combination of the two.
This proposal introduces RBridges [Pe04] (Routing Bridges), which
allow transparent interconnection of many links without the
disadvantages of bridges.
RBridges are fully compatible with current bridges as well as current
IPv4 and IPv6 routers. They are as invisible to current IP routers
as bridges are, and like routers, they terminate a bridged spanning
tree.
The main idea is to have RBridges run a link state protocol amongst
themselves (IS-IS is ideal, since its TLV encoding easily allows new
information to be carried in link state information, as this proposal
requires).
Perlman, et al. Expires January 17, 2005 [Page 3]
Internet-Draft RBridges: Transparent Routing July 2004
The next step is for RBridges to learn the location of endnodes.
They can learn the location and layer 3 addresses of IP endnodes from
ARP replies (IPv4) or ND messages (IPv6) (RFC1122, RFC1812, etc.).
It may also be necessary to learn layer 2 addresses of nodes (for
support of protocols that are not carried inside IP headers, and for
transporting IP packets destined off the campus to a specific IP
router). These can be learned through receipt of data packets, as
bridges do.
Once an RBridge learns the location of a directly attached endnode,
it informs the other RBridges in its link state information.
RBridge forwarding can be done, as with a router, via pairwise
shortest paths. RBridges could also maintain MPLS paths between
themselves, and route packets on an MPLS path.
To prevent the temporary loop issues with bridges, RBridges must
always forward based on a header with a hop count, and must avoid
packet proliferation by only forwarding in one direction, and
specifying the intended next recipient while the packet is in
transit. Because current L2 protocols do not always support TTLs
(notably Ethernet does not), this may require the use of an
encapsulation header with a TTL field, e.g., an outer IP wrapper or a
shim layer.
An Rbridge uses multiple devices to emulate an L2 bridge, using an
internal fabric of tunnels and routing independent of to the
transited traffic. Transited traffic is usually encapsulated at the
Rbridge system ingress in either an L2 or L3 + L2 header that directs
the traffic towards the Rbridge system egress. Rbridges are similar
to Recursive Routers, which provide similar transit to emulate a
single L3 router, in that case using L3 + L2 encapsulation
[To01][To03].
Perlman, et al. Expires January 17, 2005 [Page 4]
Internet-Draft RBridges: Transparent Routing July 2004
2. Detailed RBridge Design
2.1 Link State Protocol
Running a link state protocol among RBridges is straightforward. It
is the same as running a level 1 routing protocol in an area. IS-IS
is a more appropriate choice than OSPF in this case because it is
easy in IS-IS to define new TLVs for carrying new information.
However, the instance of IS-IS that RBridges will implement will be
separate from any routing protocol that IP routers will implement,
just as the spanning tree messages are not implemented by IP routers.
To keep the instances separate, RBridge routing messages should be
sent to a different layer 2 multicast address than IS-IS routing
messages. Alternatively, they can be differentiated by having a
different "area address", where, in order to keep RBridges
configuration-free, the RBridge area address would be a constant for
all RBridges, and would not be one that would ever appear as a real
IS-IS area address.
Additional information that RBridge link state information will carry
is:
o layer 2 addresses of non-IP nodes within the campus
o (layer 3, layer 2) addresses of IP nodes within the campus. For
data compression, perhaps only the portion of the address
following the campus-wide prefix need be carried. This will be
more of an issue for IPv6 than for IPv4.
2.2 Spanning Tree
There will be cases when RBridges may need to send packets to all
links. These cases include:
o layer 2 multicast or broadcast packets
o distributed RBridge layer 3 address location query
In this case the packets must be sent through a spanning tree.
However, there is no need to implement a separate spanning tree
protocol in addition to the link state protocol. Instead, the link
state information can be used to create a single spanning tree
throughout the campus. This is done by choosing the RBridge with
lowest ID, and calculating the Dijkstra tree with that RBridge as
Root.
Perlman, et al. Expires January 17, 2005 [Page 5]
Internet-Draft RBridges: Transparent Routing July 2004
In the case of multiple equal cost links, some tie-breaker must be
used to ensure that all RBridges calculate the same spanning tree.
We suggest using the ID of the parent as the tie breaker (if a node
can be attached to either parent P1 or P2 with the same cost, choose
P1 if P1's ID is lower than P2).
In the case of multicast L2 addresses, the rbridge may treat these as
broadcast, or may include existing techniques for emulating multicast
at L2, i.e., snooping IGMP and/or PIM-SM packets to configure an
internal, L2 multicast tree.
2.3 Designated Bridge
It is useful for one RBridge on each link to have special duties.
Thus one RBridge per link should be elected Designated RBridge.
IS-IS already holds such an election.
The Designated RBridge is the one on the link that will learn the
identities of attached endnodes, initiate a distributed ARP when an
ARP query is received for an unknown destination, and answer ARP
queries when the target node is known.
2.4 Learning endnode location
There are several mechanisms for learning endnode location. RBridges
could learn, like bridges do, from data packets. If this is done, it
is essential that this learning only occur on the source's link.
Otherwise RBridges on transit links, as well as other RBridges on the
destination's link, will be confused and think that the source
resides on their link.
If learning is to occur on data packets, this confusion can be
prevented by marking packets in transit, and ensuring that only the
Designated RBridge learn endnode locations, and only the Designated
RBridge forwards packets onto the LAN (and removes the transit mark).
This form of learning needs to be done to learn layer 2 addresses of
nodes that are speaking protocols that are not carried in IP frames.
For packets carried in IP frames, it is not necessary to learn in the
data path. Instead destination locations can be learned either from
ARP replies (or ND discovery) or from link state information.
If Designated RBridge R receives an IP packet for D, and D is
on-campus (D's prefix is the campus prefix), and D is unknown to R, R
initiates a "distributed ARP query". Likewise if R receives an ARP
query for target D, R initiates a distributed ARP query.
Perlman, et al. Expires January 17, 2005 [Page 6]
Internet-Draft RBridges: Transparent Routing July 2004
2.5 Distributed ARP query
The distributed ARP query is carried by RBridges through the RBridge
spanning tree. Each Designated RBridge, in addition to forwarding
the query through the spanning tree, initiates an ARP query on its
link(s). If a reply is received by Designated RBridge R2, R2
initiates a link state update to inform all the other RBridges of D's
location and layer 2 address.
The distributed ARP query must be sent to a (new, to be assigned)
layer 2 multicast address. The fields it must contain are:
Layer 2 header:
o destination = newly defined l2 multicast address
o source = transmitting RBridge (replaced hop by hop)
o protocol type = same as encapsulated RBridge
Body:
o TTL (for safety if the RBridge spanning tree has temporary loops)
o target IP address (IPv4 or IPv6)
Intermediate RBridges decrement the above TTL, and replace the source
RBridge with their own layer 2 address on the outgoing interface.
2.6 Forwarding header
It is essential that RBridges coexist with ordinary bridges.
Therefore, a packet in transit must look to ordinary bridges like an
ordinary layer 2 packet. For packets to IP destinations on the
campus, it is not necessary for packets to be encapsulated, since
routing could be done on the IP header. However, this would result
in the TTL being decremented by the RBridges, which would look
different to customers than if the campus were connected by bridges.
Therefore, it is likely we will opt for encapsulating all packets as
they traverse the campus.
Although the forwarding header must look like an ordinary layer 2
header to bridges, it must be differentiable from ordinary layer 2
packets by RBridges. For this we need a new layer 2 protocol type
("Ethertype"). An encapsulated packet would look as follows:
Perlman, et al. Expires January 17, 2005 [Page 7]
Internet-Draft RBridges: Transparent Routing July 2004
+----------------------+-----------------+
| encapsulation header | original packet |
+----------------------+-----------------+
Figure 1: Encapsulated packet
The encapsulation header contains:
o L2 destination = next RBridge
o L2 source = transitting Rbridge (the most one that most recently
handled this packet)
o protocol type = "to be assigned...RBridge encapsulated packet"
o TTL = starts at some value and decremented by each RBridge.
Discarded if=0
Note that the outer L2 destination is the next RBridge rather than
the destination's L2 address. This prevents proliferation of
packets, since a single RBridge destination is specified. The
alternative would be that multiple RBridges might decide to forward
the packet, creating extra copies.
Perlman, et al. Expires January 17, 2005 [Page 8]
Internet-Draft RBridges: Transparent Routing July 2004
3. Rbridge Addresses, parameters, and constants
Each Rbridge needs a unique ID within the campus. The simplest such
address is a unique 6-byte ID, since such an ID is easily obtainable
as any of the EUI-48's owned by that Rbridge. IS-IS already requires
each router to have such an address.
A parameter is the value to which to initially set the hop count in
the envelope. Recommended default=20.
A new Ethertype must be assigned to indicate an RBridge-encapsulated
packet.
A layer 2 multicast address must be assigned for use as the
destination address in distributed ARP queries.
Perlman, et al. Expires January 17, 2005 [Page 9]
Internet-Draft RBridges: Transparent Routing July 2004
4. Handling non-IP packets
RBridges must learn the source's location based on receipt of data
packets, just like a bridge would. However, only the first RBridge
must see the source address; otherwise, since the packet is routed by
a pairwise shortest path, intermediate RBridges and bridges will be
confused about the location of the source.
Therefore, the first RBridge (and only the Designated RBridge on the
source's link) encapsulates the packet with an encapsulation header.
The specified next RBridge, R2, will look up the layer 2 destination
in the inner header to determine the forwarding direction. Then R2
will replace the layer 2 source and destination addresses in the
outer header with R2 as source and next Rbridge as destination,
decrement the TTL, and forward the packet. If R2 is the Designated
RBridge on the destination's link, R2 removes the outer header and
forwards the packet exactly as transmitted by the source.
Perlman, et al. Expires January 17, 2005 [Page 10]
Internet-Draft RBridges: Transparent Routing July 2004
5. Handling on-campus IP Packets
Here, RBridges forward based on the layer 3 header. If the layer 3
header is used, there is the advantage that the campus can encompass
links with incompatible layer 2 addresses. This enables IP nodes in
the campus to communicate even if they speak incompatible layer 2
protocols. However, it will not allow two such nodes to communicate
if they are not speaking IP, unless the layer 2 protocols are
sufficiently similar that RBridges can translate the headers. Such
functionality is beyond the scope of this document, however.
It might also be nice to eliminate the inner layer 2 header.
However, future uses might be made if the original layer 2 header
were preserved where possible (where source and destination were on
compatible layer 2 links). For instance, it might be nice to update
ARP caches based on receipt of data packets.
Each intermediate RBridge that receives an on-campus IP packet looks
up the layer 3 destination address in its forwarding table, and
replaces the source and destination addresses in the outer layer 2
header, and decrements the encapsulation header's TTL. If the TTL is
0, the packet is discarded. If this Rbridge is the Designated
RBridge on the destination's link, this RBridge removes the
encapsulation header and forwards the packet onto the destination's
link.
Perlman, et al. Expires January 17, 2005 [Page 11]
Internet-Draft RBridges: Transparent Routing July 2004
6. Handling off-campus IP packets
Here, RBridges must forward based on the destination in the original
layer 2 header, because the endnode must be able to choose which
router to send off-campus packets to. In particular, an IP router
must be able to forward to another IP router across the campus.
So such packets are handled the same way as non-IP packets.
Perlman, et al. Expires January 17, 2005 [Page 12]
Internet-Draft RBridges: Transparent Routing July 2004
7. Handling ARP Queries
If the target address is unknown, initiate a distributed ARP query.
If the target address is known, reply with a proxy ARP reply, giving
the target's true layer 2 address.
When initiating a distributed ARP query (or IPv6 neighbor
solicitation) remember the address of the requesting node. When the
information is discovered, respond to the requester.
Perlman, et al. Expires January 17, 2005 [Page 13]
Internet-Draft RBridges: Transparent Routing July 2004
8. Issues
8.1 Avoiding encapsulation in some cases
8.1.1 Avoiding encapsulation for on-campus IP packets
In theory, on-campus IP packets need not be encapsulated with an
additional layer 2 header. The original layer 2 header can be
discarded and replaced with one where the layer 2 destination is
replaced by the next RBridge, and the source layer 2 address is
replaced by something that will not confuse bridge learning (since
packets will be injected into each segment from unpredictable
directions because shortest path routes will be used).
The disadvantages of this approach are:
o the IP header's TTL would be decremented by each RBridge, making
the customer aware that bridges have been replaced by RBridges,
and possibly breaking IP protocols that expect the TTL not to be
decremented over an L2 system
o the original layer 2 addresses might need to be preserved for some
conceivable uses
8.1.2 Avoiding encapsulation for off-campus IP packets
Likewise, in theory, off-campus IP packets need not be encapsulated.
The TTL in the IP header can be decremented. The same disadvantages
as for on-campus IP packets apply, including the concerns on the
impact of decremented TTL on other IP protocol behavior. However,
there is the additional disadvantage that since the actual layer 2
destination has to be preserved end-to-end there is the danger of
packet proliferation if multiple RBridges decide to forward the
packet, which can occur while the topology is adjusting.
8.2 Effects on L3 TTL
In general, an Rbridge should have no effect on a Layer 3, e.g., IP
TTL field, since the Rbridge is a Layer 2 device. The TTLs which
ensure loop-free operation in an Rbridge system should occur in the
encapsulation header, and not affect any of the headers of the packet
passed through the Rbridge system. The Rbridge should do nothing to
transited packets other than that which would be done by an
equivalent L2 system.
Perlman, et al. Expires January 17, 2005 [Page 14]
Internet-Draft RBridges: Transparent Routing July 2004
8.3 Using L3 Encapsulation
Rbridges may use L3, e.g., IP encapsulation to provide a routable
internal address and a loop-check indicator. This allows the Rbridge
system to use L3 routing algorithms, e.g., OSPF, using existing L3
implementations. As with any Rbridge system, packets are forwarded
only within the preconfigured Rbridge system. Intermediate L2
bridges are allowed whether L2 or L3 encapsulation is used. L3
encapsulation processing - including ICMP handling, fragmentation,
etc., are well-defined (e.g., RFC2003).
In this case, the L3 encapsulation should not decrement the TTL of
the transited packet, since (as per RFC2003) the Rbridge system would
not be considered a forwarding (i.e., L3) 'tunnel'. Further,
changing the IP TTL would potentially affect the reachability of all
1's broadcast or multicast, which would not reach the full L2 subnet.
The primary disadvantage to L3 encapsulation is the increased
overhead of encapsulation (e.g., adding both an L3 and subsequent
outer L2 header) and complexity of providing L2 services (broadcast
notably) within the L3 subnet (RFC1122, RFC1812). Note that L3
supports fragmentation and reassembly for tunnels, notably both for
IPv4 and IPv6 encapsulation. Reassembly would be required at the
egress, which increases the load on the egress Rbridge in tracking
and storing the fragments, but the resulting transited packet is
generally transparent to the process. The primary effect would be if
there were a large amount of reordering (increasing the reassembly
load) or high packet loss (resulting in failed reassembly and thus
lost packets). In the latter case, packet loss is amplified because
of the lack of fate sharing of the fragments of a single transited
packet.
8.4 Topology Issues
It may be possible for an rbridge system to forward the same
encapsulated packet over the same physical link multiple times. This
could occur when rbridge systems overlap, or when the tunnels of an
rbridge system are not explicitly matched to the underlying topology.
In this case, loops are still avoided because internally an rbridge
campus uses a loop-free routing protocol, and externally the rbridge
campus acts like a single bridge in the outer L2 spanning tree
system. The repeating use of individual links may affect
performance, but is strictly not avoidable and does not affect
correctness.
Perlman, et al. Expires January 17, 2005 [Page 15]
Internet-Draft RBridges: Transparent Routing July 2004
9. Security Considerations
The goal is for RBridges to not add additional security issues over
what would be present with traditional bridges. RBridges will not be
able to prevent nodes from impersonating other nodes, for instance,
by issuing bogus ARP replies. However, RBridges will not interfere
with any schemes that would secure neighbor discovery.
As with routing schemes, authentication of RBridge messages would be
a simple addition to the design (and it would be accomplished the
same way as it would be in IS-IS). However, any sort of
authentication requires additional configuration, which might
interfere with the perception that RBridges, like bridges, are zero
configuration.
Perlman, et al. Expires January 17, 2005 [Page 16]
Internet-Draft RBridges: Transparent Routing July 2004
10. Conclusions
This design allows transparent interconnection of multiple links into
a single IP subnet. Management would be just like with bridges
(plug-and-play). But this design avoids the disadvantages of
bridges. Temporary loops are not a problem so failover can be as
fast as possible, and shortest paths can be followed.
The design is compatible with current IP nodes and routers, and with
current bridges.
Perlman, et al. Expires January 17, 2005 [Page 17]
Internet-Draft RBridges: Transparent Routing July 2004
11. Acknowledgments
We anticipate that many people will contribute to this design, and
invite you to join the mailing list at http://www.postel.org/rbridge
Perlman, et al. Expires January 17, 2005 [Page 18]
Internet-Draft RBridges: Transparent Routing July 2004
12. References
12.1 Normative References
[1] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[2] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[3] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[4] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, RFC
826, November 1982.
[5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[6] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990.
[7] IEEE 802.1d bridging standard, "IEEE 802.1d bridging standard",
.
[8] Perlman, R., "RBridges: Transparent Routing", Infocom , March
2004.
[9] Perlman, R., "Interconnection: Bridges, Routers, Switches, and
Internetworking Protocols", Addison Wesley Chapter 3, 1999.
[10] Touch, J., "Dynamic Internet overlay deployment and management
using the X-Bone", Computer Networks Vol. 36, No. 2-3, July
2001.
[11] Touch, J., Wang, Y., Eggert, L. and G. Finn, "A Virtual
Internet Architecture", ISI Technical Report ISI-TR-570,
Workshop on Future Directions in Network Architecture (FDNA)
2003, March 2003.
12.2 Informative References
[12] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[13] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
Perlman, et al. Expires January 17, 2005 [Page 19]
Internet-Draft RBridges: Transparent Routing July 2004
November 1990.
[14] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923,
September 2000.
[15] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-08 (work in progress), March 2004.
[16] Kent, S., "IP Authentication Header",
draft-ietf-ipsec-rfc2402bis-07 (work in progress), March 2004.
[17] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-14 (work in progress), June 2004.
Authors' Addresses
Radia Perlman
Sun Microsystems
Phone:
Fax:
EMail: Radia.Perlman@Sun.COM
URI:
Joe Touch
USC/Information Sciences Institute
Phone:
Fax:
EMail: touch@isi.edu
URI:
Alper Yegin
Samsung Advanced Institute of Technology
Phone:
Fax:
EMail: alper.yegin@samsung.com
URI:
Perlman, et al. Expires January 17, 2005 [Page 20]
Internet-Draft RBridges: Transparent Routing July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Perlman, et al. Expires January 17, 2005 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 11:36:36 |