draft-ietf-mpls-icmp-00.txt | draft-ietf-mpls-icmp-01.txt | |||
---|---|---|---|---|
MPLS Working Group | MPLS Working Group R.Bonica | |||
INTERNET DRAFT Ron Bonica | Internet Draft MCIWorldCom | |||
July 1999 MCI WorldCom | Document: draft-ietf-mpls-icmp-01.txt D.Tappan | |||
Expires January 2000 Daniel C. Tappan | ||||
Cisco Systems | Cisco Systems | |||
Der-Hwa Gan | D.Gan | |||
Juniper Networks | Juniper Networks | |||
December 1999 | ||||
ICMP Extensions for MultiProtocol Label Switching | ICMP Extensions for MultiProtocol Label Switching | |||
draft-ietf-mpls-icmp-00.txt | ||||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of [RFC-2026]. | all provisions of Section 10 of [RFC-2026]. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. Internet-Drafts are draft documents valid for a maximum of | |||
six months and may be updated, replaced, or obsoleted by other | ||||
Internet-Drafts are draft documents valid for a maximum of six | documents at any time. It is inappropriate to use Internet-Drafts as | |||
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." | reference material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
1. Abstract | 1. Abstract | |||
The current memo proposes extensions to ICMP that permit LSRs to | The current memo proposes extensions to ICMP that permit Label | |||
append MPLS information to ICMP messages. | Switching Routers to append MPLS information to ICMP messages. | |||
2. Conventions used in this document | 2. Conventions used in this document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in | |||
be interpreted as described in [RFC-2119]. | this document are to be interpreted as described in [RFC-2119]. | |||
3. Introduction | 3. Introduction | |||
Routers and destination hosts use the Internet Control Message | Routers and destination hosts use the Internet Control Message | |||
Protocol (ICMP) [RFC-792] to convey control information to source | Protocol (ICMP) [RFC-792] to convey control information to source | |||
hosts. Network operators use this information to detect and diagnose | hosts. Network operators use this information to diagnose routing | |||
Layer 3 routing problems. | problems. | |||
Bonica, Tappan, Hwa Draft-Expires May 2000 1 | ||||
When a router receives an undeliverable IP datagram, it can send an | When a router receives an undeliverable IP datagram, it can send an | |||
ICMP message to the host that originated the datagram. The ICMP | ICMP message to the host that originated the datagram. The ICMP | |||
message indicates why the datagram could not be delivered. It also | message indicates why the datagram could not be delivered. It also | |||
contains the IP header and leading payload bytes of the | contains the IP header and leading payload octets of the "original | |||
undeliverable datagram. | datagram". | |||
MPLS Label Switching Routers (LSRs) also use ICMP to convey control | In this document, the term "original datagram" refers to the | |||
datagram to which the ICMP message is a response. | ||||
MPLS Label Switching Routers (LSR) also use ICMP to convey control | ||||
information to source hosts. Sections 2.3 and 2.4 of [ENCODE] | information to source hosts. Sections 2.3 and 2.4 of [ENCODE] | |||
describe the interaction between MPLS and ICMP. | describe the interaction between MPLS and ICMP. | |||
When an LSR receives an undeliverable MPLS labeled datagram, it | When an LSR receives an undeliverable MPLS encapsulated datagram, it | |||
removes the entire MPLS label stack, exposing the encapsulated IP | removes the entire MPLS label stack, exposing the previously | |||
datagram. The router then submits the IP datagram to a network- | encapsulated IP datagram. The LSR then submits the IP datagram to a | |||
forwarding module for error processing. Error processing can include | network-forwarding module for error processing. Error processing can | |||
ICMP message generation. | include ICMP message generation. | |||
Although the ICMP message contains the non-delivery reason, IP | The ICMP message indicates why the original datagram could not be | |||
header and leading payload bytes, it contains no information | delivered. It also contains the IP header and leading octets of the | |||
regarding the MPLS label stack that encapsulated the datagram when | original datagram. | |||
it arrived at the LSR. | ||||
The current memo proposes extensions to ICMP that permit LSRs to | The ICMP message, however, includes no information regarding the | |||
append MPLS label stack information to the ICMP message body. Hence, | MPLS label stack that encapsulated the original datagram when it | |||
ICMP messages regarding undeliverable MPLS encapsulated datagrams | arrived at the LSR. This omission is significant because the LSR | |||
SHOULD include the MPLS label stack, as it arrived at the router | would have routed the original datagram based upon information | |||
that is sending the ICMP message. The ICMP message MUST also include | contained by the MPLS label stack. | |||
the IP header and leading payload bytes of the undeliverable | ||||
datagram. | ||||
Network operators will use this information to detect and diagnose | The current memo proposes extensions to ICMP that permit an LSR to | |||
MPLS problems. | append MPLS label stack information to ICMP messages. ICMP messages | |||
regarding MPLS encapsulated datagrams SHOULD include the MPLS label | ||||
stack, as it arrived at the router that is sending the ICMP message. | ||||
The ICMP message MUST also include the IP header and leading payload | ||||
octets of the original datagram. | ||||
Network operators will use this information to diagnose routing | ||||
problems. | ||||
4. Motivation | 4. Motivation | |||
ICMP extensions defined in the current memo support enhancements to | ICMP extensions defined in the current memo support enhancements to | |||
TRACEROUTE. The enhanced TRACEROUTE, like older TRACEROUTE | TRACEROUTE. The enhanced TRACEROUTE, like older implementations, | |||
implementations, reports each IP router and LSR that a datagram | indicates which nodes the original datagram visited en route to its | |||
visits en route to its destination. The enhanced TRACEROUTE differs | ultimate destination. It differs from older implementations in that | |||
from older implementations in that it indicates which nodes were | it also indicates the original datagrams MPLS encapsulation status | |||
visited while traversing a Label Switched Path (LSP). | as it arrived at each node. | |||
Figure 1 contains sample output from an enhanced TRACEROUTE | Figure 1 contains sample output from an enhanced TRACEROUTE | |||
implementation. | implementation. | |||
Bonica,Tappan,Gan Draft-Expires May 2000 2 | ||||
>Traceroute 166.45.2.74 | >Traceroute 166.45.2.74 | |||
traceroute to 166.45.2.74, 30 hops max, 40 byte packets | traceroute to 166.45.2.74, 30 hops max, 40 byte packets | |||
1 166.45.5.1 1.281 ms 1.103 ms 1.096 ms | 1 166.45.5.1 1.281 ms 1.103 ms 1.096 ms | |||
2 166.45.4.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2001 | ||||
2 166.45.4.1 1.281 ms 1.103 ms 1.096 ms | mplsExpBits1=0 | |||
mplsLabel1=2001 mplsExpBits1=0 | 3 166.45.3.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2002 | |||
3 166.45.3.1 1.281 ms 1.103 ms 1.096 ms | mplsExpBits1=0 | |||
mplsLabel1=2002 mplsExpBits1=0 | 4 166.45.6.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2003 | |||
4 166.45.6.1 1.281 ms 1.103 ms 1.096 ms | mplsExpBits1=0 | |||
mplsLabel1=2003 mplsExpBits1=0 | ||||
5 166.45.2.1 1.281 ms 1.103 ms 1.096 ms | 5 166.45.2.1 1.281 ms 1.103 ms 1.096 ms | |||
6 166.45.2.74 1.281 ms 1.103 ms 1.096 ms | 6 166.45.2.74 1.281 ms 1.103 ms 1.096 ms | |||
Figure 1. Enhanced TRACEROUTE sample output | Figure 1. Enhanced TRACEROUTE sample output | |||
5. Disclaimer | 5. Disclaimer | |||
The current memo does not define the general relationship between | The current memo does not define the general relationship between | |||
ICMP and MPLS. Sections 2.3 and 2.4 of [ENCODE] define this | ICMP and MPLS. Sections 2.3 and 2.4 of [ENCODE] define this | |||
relationship. | relationship. | |||
Specifically, this document defers to [ENCODE] with respect to the | Specifically, this document defers to [ENCODE] with respect to the | |||
following issues: | following issues: | |||
- conditions upon which LSRs emit ICMP messages | - conditions upon which an LSR emits ICMP messages | |||
- handling of ICMP messages bound for hosts that are identified | - handling of ICMP messages bound for hosts that are identified | |||
by private addresses | by private addresses | |||
The current memo does not define encapsulation specific TTL | The current memo does not define encapsulation specific TTL | |||
manipulation procedures. It defers to Section 10 of [MPLSATM] and | manipulation procedures. It defers to Section 10 of [MPLSATM] and | |||
Section 5.4 of [MPLSFRAME] in this matter. | Section 5.4 of [MPLSFRAME] in this matter. | |||
When encapsulation specific TTL manipulation procedures defeat the | When encapsulation specific TTL manipulation procedures defeat the | |||
basic TRACEROUTE mechanism, they will also defeat enhanced | basic TRACEROUTE mechanism, they will also defeat enhanced | |||
TRACEROUTE implementations. | TRACEROUTE implementations. | |||
6. Backward Compatibility | The current memo does not address extensions to ICMPv6. These should | |||
be addressed in a separate draft. | ||||
ICMP extensions proposed in this document MUST be backward | 6. Formal Syntax | |||
compatible with the syntax described in RFC-792. Extensions proposed | ||||
in this memo MUST NOT change or deprecate any field defined in RFC- | ||||
792. | ||||
7. Formal Syntax | This section defines a data structure that an LSR can append to | |||
selected ICMP messages. The data structure contains the MPLS label | ||||
stack that encapsulated the original datagram when it arrived at the | ||||
LSR. | ||||
This section describes a data structure that can be appended to the | The data structure defined herein can be appended to the following | |||
following ICMP message types: | ICMP message types: | |||
Bonica,Tappan,Gan Draft-Expires May 2000 3 | ||||
1) Destination Unreachable | 1) Destination Unreachable | |||
2) Time Exceeded | 2) Time Exceeded | |||
3) Parameter Problem | 3) Parameter Problem | |||
4) Source Quench | 4) Source Quench | |||
5) Redirect | 5) Redirect | |||
The above listed ICMP message types specify a fixed length of 56 | According to RFC-792, the final field contained by each of these | |||
bytes. When the data structure defined in this section is appended | ICMP message types reflects the IP header and leading 64 bits of the | |||
to an ICMP message, the ICMP _total length_ field MUST equal the | original datagram. [RFC-1812] recommends that this final field be | |||
data structure length plus 56. | extended to include as much of the original datagram as possible. | |||
When an LSR appends the data structure defined herein to an ICMP | ||||
message, the final field of the ICMP message body MUST contain the | ||||
first 128 octets of the original datagram. At least 20 of these 128 | ||||
octets represent the IP header of the original datagram. | ||||
If the original datagram was shorter than 128 octets, the final | ||||
field MUST be padded with 0's. | ||||
When an LSR appends the data structure defined herein to an ICMP | ||||
message, the ICMP "total length" MUST be equal to the data structure | ||||
length plus 156. The first octet of the data structure must be | ||||
displaced 156 octets from the beginning of the ICMP message. | ||||
The data structure defined in this section consists of a common | The data structure defined in this section consists of a common | |||
header followed by object instances. Each object instance consists | header followed by object instances. Each object instance consists | |||
of an object header plus contents. | of an object header plus contents. | |||
Currently, only one object class is defined. This object class | Currently, two object classes are defined. One object class contains | |||
contains an entire MPLS label stack, formatted exactly as it was | an entire MPLS label stack, formatted exactly as it was when it | |||
when it arrived at the LSR that sends the ICMP message. | arrived at the LSR that sends the ICMP message. The other contains | |||
some portion of the original datagram that could not be included in | ||||
the final field of the ICMP message body (i.e., the octet 129 and | ||||
beyond). | ||||
Both object classes are optional. | ||||
In the future, additional object classes may be defined. | In the future, additional object classes may be defined. | |||
7.1 Common Header | 6.1 Common Header | |||
0 1 2 3 | 0 1 2 3 | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
| Vers | (Reserved) | Checksum | | | Vers | (Reserved) | Checksum | | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
The fields in the common header are as follows: | The fields in the common header are as follows: | |||
Bonica,Tappan,Gan Draft-Expires May 2000 4 | ||||
Vers: 4 bits | Vers: 4 bits | |||
ICMP extension version number. This is version 1. | ICMP extension version number. | |||
This is version 2. | ||||
Checksum: 16 bits | Checksum: 16 bits | |||
The one's complement of the one's complement sum of the data | The one's complement of the one's complement sum of the data | |||
structure, with the checksum field replaced by zero for the | structure, with the checksum field replaced by zero for the purpose | |||
purpose of computing the checksum. An all-zero value means that | of computing the checksum. An all-zero value means that no checksum | |||
no checksum was transmitted. | was transmitted. | |||
If the checksum field contains a value other than described | ||||
above, bytes 56 and beyond of the ICMP message do not contain | ||||
the data structure described by this memo. These bytes may | ||||
contain an extended ICMP payload as described in Section 4.3.2.3 | ||||
of [RFC-1812]. | ||||
Reserved: | If the checksum field contains a value other than described above, | |||
the ICMP message does not include the extensions described in this | ||||
memo. This, however, does not imply that the ICMP message is | ||||
malformed. It may be in strict compliance with RFC-1812. | ||||
Must be set to 0. | Reserved: Must be set to 0. | |||
7.2 Object Header | 6.2 Object Header | |||
Every object consists of one or more 32-bit words with a one-word | Every object consists of one or more 32-bit words with a one-word | |||
header, with the following format: | header, with the following format: | |||
0 1 2 3 | ||||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
| Length | Class-Num | C-Type | | | Length | Class-Num | C-Type | | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
| | | | | | |||
// (Object contents) // | | // (Object contents) // | | |||
| | | | | | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
An object header has the following fields: | An object header has the following fields: | |||
Length: 16 bits | Length: 16 bits | |||
Length of the object, measured in bytes, including the object | Length of the object, measured in octets, including the object | |||
header and object contents. | header and object contents. | |||
Class-Num: 8 bits | Class-Num: 8 bits | |||
Identifies object class. Currently, the only one object class | Identifies object class. | |||
is defined. This is the MPLS Stack Entry Object. | ||||
C-Type: 8 bits | C-Type: 8 bits | |||
Identifies object sub-type. Currently, only one object sub-type | Identifies object sub-type. | |||
is defined. | ||||
7.3 MPLS Stack Entry Object Class | Bonica,Tappan,Gan Draft-Expires May 2000 5 | |||
An instance of the MPLS Entry Object class represents the entire | 6.3 MPLS Stack Entry Object Class | |||
MPLS label stack, formatted exactly as it was when it arrived at the | ||||
LSR that sends the ICMP message. | ||||
In the illustration below, bytes 0-3 depict the first member of the | A single instance of the MPLS Entry Object class represents the | |||
entire MPLS label stack, formatted exactly as it was when it arrived | ||||
at the LSR that sends the ICMP message | ||||
In the illustration below, octets 0-3 depict the first member of the | ||||
MPLS label stack. Each remaining member of the MPLS label stack is | MPLS label stack. Each remaining member of the MPLS label stack is | |||
represented by another 4 bytes that share the same format. | represented by another 4 octets that share the same format. | |||
Syntax follows: | Syntax follows: | |||
MPLS Stack Entry Class = 1, C-Type = 1. | MPLS Stack Entry Class = 1, C-Type = 1. | |||
0 1 2 3 | 0 1 2 3 | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
| Label |EXP |S| TTL | | | Label |EXP |S| TTL | | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
| | | | | | |||
// Remaining MPLS Stack Entries // | | // Remaining MPLS Stack Entries // | | |||
| | | | | | |||
+-------------+-------------+-------------+-------------+ | +-------------+-------------+-------------+-------------+ | |||
Label: 20 bits | Label: 20 bits | |||
Exp: Experimental Use, 3 bits | Exp: Experimental Use, 3 bits | |||
S: Bottom of Stack, 1 bit | S: Bottom of Stack, 1 bit | |||
TTL: Time to Live, 8 bits | TTL: Time to Live, 8 bits | |||
6.4 Extended Payload Object Class | ||||
An instance of the Extended Payload Object class represents some | ||||
portion of the original datagram that could not be fit in the final | ||||
field of the ICMP message body (i.e., octets beyond 128). | ||||
Syntax follows: | ||||
MPLS Stack Entry Class = 2, C-Type = 1. | ||||
0 1 2 3 | ||||
+-------------+-------------+-------------+-------------+ | ||||
| | | ||||
| // Remaining MPLS Stack Entries // | | ||||
| | | ||||
+-------------+-------------+-------------+-------------+ | ||||
Bonica,Tappan,Gan Draft-Expires May 2000 6 | ||||
7. Backward Compatibility | ||||
ICMP extensions proposed in this document MUST be backward | ||||
compatible with the syntax described in RFC-792. Extensions proposed | ||||
in this memo MUST NOT change or deprecate any field defined in RFC- | ||||
792. | ||||
The extensions defined herein are in keeping with the spirit, if not | ||||
the letter of RFC-1812. In order to support IP-in-IP tunneling, RFC- | ||||
1812 extends the final field of selected ICMP messages to include a | ||||
greater portion of the original datagram. Unfortunately, it extends | ||||
this field to a variable length without adding a length attribute. | ||||
This memo binds the length of that final field to an arbitrarily | ||||
large value (128 octets). Fixing the length of that field | ||||
facilitates extension of the ICMP message. An additional object is | ||||
provided through which octets 129 and beyond can be appended to the | ||||
ICMP message. | ||||
As few datagrams contain L3 or L4 header information beyond octet | ||||
128, it is unlikely that the extensions described herein will | ||||
disable any applications that rely upon RFC-1812 style ICMP | ||||
messages. | ||||
8.Security Considerations | 8.Security Considerations | |||
This memo presents no security considerations beyond those already | This memo presents no security considerations beyond those already | |||
presented by current ICMP applications (e.g., traceroute). | presented by current ICMP applications (e.g., traceroute). | |||
9. References | 9. References | |||
[ARCH], Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | [ARCH], Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | |||
Label Switching Architecture", Internet Draft <draft-ietf-mpls-arch- | Label Switching Architecture", Internet Draft <draft-ietf-mpls-arch- | |||
02.txt>, July, 1998 | 06.txt>, August, 1999 | |||
[ENCODE], Rosen, E., Rekhter, Y., Tappan, D, Farinacci, D., | [ENCODE], Rosen, E., Rekhter, Y., Tappan, D, Farinacci, D., | |||
Fedorkow, G., Li, T., Conta, A., _MPLS Stack Encoding_, Internet | Fedorkow, G., Li, T., Conta, A., "MPLS Stack Encoding", Internet | |||
Draft, <draft-ietf-mpls-label-encapse-03.txt>, September 1998. | Draft, <draft-ietf-mpls-label-encapse-07.txt>, September 1999. | |||
[FRAME], Callon, R., Doolan, P., Feldman, N., Fredette, A., | [FRAME], Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, | |||
Swallow, G., and A. Viswanathan, "A Framework for Multiprotocol | G., and A. Viswanathan, "A Framework for Multiprotocol Label | |||
Label Switching", Internet Draft <draft-ietf-mpls-framework-02.txt>, | Switching", Internet Draft <draft-ietf-mpls-framework-05.txt>, | |||
November 1997. | September 1999. | |||
[MPLSATM], Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., | [MPLSATM], Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., | |||
Rosen, E., Swallow, G, _MPLS using ATM VC Switching_, <draft-ietf- | Rosen, E., Swallow, G, "MPLS using ATM VC Switching", <draft-ietf- | |||
mpls-atm-01.txt>, November, 1998. | mpls-atm-01.txt>, November, 1998. | |||
[MPLSFRAME], Conta, A., Doolan, P., Malis, A., _Use of Label | Bonica,Tappan,Gan Draft-Expires May 2000 7 | |||
Switching on Frame Relay Networks_, <draft-ietf-mpls-fr-03.txt>, | [MPLSFRAME], Conta, A., Doolan, P., Malis, A., "Use of Label | |||
Switching on Frame Relay Networks", <draft-ietf-mpls-fr-03.txt>, | ||||
November, 1998. | November, 1998. | |||
[RFC-792], Postel, J., _Internet Control Message Protocol_, RFC 792, | [RFC-792], Postel, J., "Internet Control Message Protocol", RFC 792, | |||
ISI, September 1981. | ISI, September 1981. | |||
[RFC-1812], Baker, F., _Requirements for IP Version 4 Routers_, RFC | [RFC-1812], Baker, F., "Requirements for IP Version 4 Routers", RFC | |||
1812, June 1995. | 1812, June 1995. | |||
[RFC-2026], Bradner, S., _Internet Standards Process _ Revision 3_, | [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", | |||
RFC 2026, Harvard University, October 1996. | RFC 2026, Harvard University, October 1996. | |||
[RFC-2119], Bradner, S,, "Key words for use in RFCs to Indicate | [RFC-2119], Bradner, S,, "Key words for use in RFCs to Indicate | |||
Requirement Levels", RFC 2119, Harvard University, March 1997 | Requirement Levels", RFC 2119, Harvard University, March 1997 | |||
10. Author's Addresses | 10. Acknowledgments | |||
Thanks to Yakov Rekhter and Mike Heard for their contributions to | ||||
this memo. | ||||
11. Author's Addresses | ||||
Ronald P. Bonica | Ronald P. Bonica | |||
MCI WorldCom | MCI WorldCom | |||
2100 Reston Parkway | 22001 Loudoun County Pkwy | |||
Reston, Virginia, U.S.A. 20191 | Ashburn, Virginia, 20147 | |||
Phone: +1 703 715 7176 | Phone: 703 886 1681 | |||
Email: rbonica@mci.net | Email: rbonica@mci.net | |||
Daniel C. Tappan | Daniel C. Tappan | |||
Cisco Systems | Cisco Systems | |||
250 Apollo Drive | 250 Apollo Drive | |||
Chelmsford, Massachusetts, 01824 | Chelmsford, Massachusetts, 01824 | |||
Email: tappan@cisco.com | Email: tappan@cisco.com | |||
Der-Hwa Gan | Der-Hwa Gan | |||
Juniper Networks | Juniper Networks | |||
385 Ravendale Drive | 385 Ravendale Drive | |||
Mountain View, California 94043 | Mountain View, California 94043 | |||
Email: dhg@juniper.net | Email: dhg@juniper.net | |||
Bonica,Tappan,Gan Draft-Expires May 2000 8 | ||||
Full Copyright Statement | ||||
"Copyright (C) The Internet Society (date). All Rights Reserved. | ||||
This document and translations of it may be copied and furnished to | ||||
others, and derivative works that comment on or otherwise explain it | ||||
or assist in its implmentation may be prepared, copied, published | ||||
and distributed, in whole or in part, without restriction of any | ||||
kind, provided that the above copyright notice and this paragraph | ||||
are included on all such copies and derivative works. However, this | ||||
document itself may not be modified in any way, such as by removing | ||||
the copyright notice or references to the Internet Society or other | ||||
Internet organizations, except as needed for the purpose of | ||||
developing Internet standards in which case the procedures for | ||||
copyrights defined in the Internet Standards process must be | ||||
followed, or as required to translate it into | ||||
Bonica,Tappan,Gan Draft-Expires May 2000 9 | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |