diff options
Diffstat (limited to 'doc/rfc/rfc3572.txt')
| -rw-r--r-- | doc/rfc/rfc3572.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc3572.txt b/doc/rfc/rfc3572.txt new file mode 100644 index 0000000..9e78b2f --- /dev/null +++ b/doc/rfc/rfc3572.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group T. Ogura +Request for Comments: 3572 M. Maruyama +Category: Informational NTT Network Innovation Labs + T. Yoshida + Werk Mikro Systems + July 2003 + + + Internet Protocol Version 6 over MAPOS + (Multiple Access Protocol Over SONET/SDH) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +IESG Note + + This memo documents a way of carrying IPv6 packets over MAPOS + networks. This document is NOT the product of an IETF working group + nor is it a standards track document. It has not necessarily + benefited from the widespread and in-depth community review that + standards track documents receive. + +Abstract + + Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed + link-layer protocol that provides multiple access capability over a + Synchronous Optical NETwork/Synchronous Digital Hierarchy + (SONET/SDH). + + This document specifies the frame format for encapsulating an IPv6 + datagram in a MAPOS frame. It also specifies the method of forming + IPv6 interface identifiers, the method of detecting duplicate + addresses, and the format of the Source/Target Link-layer Addresses + option field used in IPv6 Neighbor Discovery messages. + + + + + + + + + + +Ogura, et. al. Informational [Page 1] + +RFC 3572 IPv6 over MAPOS July 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Frame Format for Encapsulating IPv6 Datagrams. . . . . . . . . 3 + 2.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Maximum Transmission Unit (MTU). . . . . . . . . . . . . 3 + 2.3. Destination Address Mapping. . . . . . . . . . . . . . . 4 + 2.3.1. Unicast. . . . . . . . . . . . . . . . . . . . . 4 + 2.3.2. Multicast . . . . . . . . . . . . . . . . . . . . 4 + 3. Interface Identifier . . . . . . . . . . . . . . . . . . . . . 6 + 4. Duplicate Address Detection. . . . . . . . . . . . . . . . . . 8 + 5. Source/Target Link-layer Address Option. . . . . . . . . . . . 9 + 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 10 + 6.1. Issues concerning Link-layer Addresses . . . . . . . . . 10 + 6.1.1. Protection against fraudulent reception + of traffic . . . . . . . . . . . . . . . . . . . 10 + 6.1.2. Protection against improper traffic. . . . . . . 11 + 6.2. Uniqueness of Interface Identifiers. . . . . . . . . . . 11 + 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 + 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 + +1. Introduction + + Multiple Access Protocol over SONET/SDH (MAPOS) [1][2] is a high- + speed link-layer protocol that provides multiple access capability + over SONET/SDH. Its frame format is based on the HDLC-like (High + Level Data Link Control) framing [3] for PPP. A component called a + "Frame Switch" [1] allows multiple nodes (hosts and routers) to be + connected together in a star topology to form a LAN. Using long-haul + SONET/SDH links, the nodes on such a "SONET-LAN" can span a wide + geographical area. + + This document specifies the frame format for encapsulating an + Internet Protocol version 6 (IPv6) [4] datagram in a MAPOS frame, the + method of forming IPv6 interface identifiers, the method of detecting + duplicate addresses, and the format of the Source/Target Link-layer + Addresses option field used in Neighbor Discovery messages such as + Router Solicitation, Router Advertisement, Neighbor Solicitation, + Neighbor Advertisement, and Redirect messages. + + In the remainder of this document, the term "MAPOS" is used unless + the distinction between MAPOS version 1 [1] and MAPOS 16 [2] is + required. + + + + + + + +Ogura, et. al. Informational [Page 2] + +RFC 3572 IPv6 over MAPOS July 2003 + + +2. Frame Format for Encapsulating IPv6 Datagrams + +2.1. Frame Format + + MAPOS uses the same HDLC-like framing as PPP-over-SONET, described in + [3]. The MAPOS frame begins and ends with a flag sequence 01111110 + (0x7E), and the MAPOS frame header contains address, control, and + protocol fields. The address field contains a destination HDLC + address. In MAPOS 16, the address field is extended to 16 bits, and + the control field of MAPOS version 1 is omitted. The frame check + sequence (FCS) field is 16 bits long by default, but a 32-bit FCS may + be used optionally. Details of the MAPOS frame format are described + in [1][2]. + + An IPv6 datagram is encapsulated in the MAPOS frame. In the case of + encapsulating an IPv6 datagram, the protocol field must contain the + value 0x0057 (hexadecimal). The IPv6 datagram is stored in the + information field which follows immediately after the protocol field. + That is, this field contains the IPv6 header followed immediately by + the payload. Figure 1 shows the frame format. The fields are + transmitted from left to right. + + +----------+----------+----------+----------+ + | | | Control/ | Protocol | + | Flag | Address | Address | 16 bits | + | 01111110 | 8 bits | 8 bits | (0x0057) | + +----------+----------+----------+----------+ + +-------------+------------+----------+----------- + | | | | Inter-frame + | IPv6 header | FCS | Flag | fill or next + | and payload | 16/32 bits | 01111110 | address + +-------------+------------+----------+------------ + + Figure 1. Frame format. + +2.2. Maximum Transmission Unit (MTU) + + The length of the information field of the MAPOS frame may vary, but + shall not exceed 65,280 (64K - 256) octets [1][2]. The default + maximum transmission unit (MTU) is 65,280 octets. + + However, the MTU size may be reduced by a Router Advertisement [5] + containing an MTU option that specifies a smaller MTU, or by manual + configuration of each node. If a Router Advertisement received on a + MAPOS interface has an MTU option specifying an MTU larger than + 65,280, or larger than a manually configured value, that MTU option + may be logged for the system management but must be otherwise + ignored. + + + +Ogura, et. al. Informational [Page 3] + +RFC 3572 IPv6 over MAPOS July 2003 + + +2.3. Destination Address Mapping + + This section specifies the method of mapping an IPv6 destination + address to the address field in the MAPOS frame header. + +2.3.1. Unicast + + In unicasting, the address field of a MAPOS frame contains the HDLC + address that has been assigned via NSP (Node Switch Protocol) [6] to + the MAPOS interface, which has the IPv6 unicast destination address. + + In order to determine the destination HDLC address that corresponds + to an IPv6 unicast destination address, the sender uses Link-layer + Address Resolution described in [5]. + +2.3.2. Multicast + + Address resolution is never performed on IPv6 multicast addresses. + An IPv6 multicast destination address is mapped to the address field + in the MAPOS frame header as described below for MAPOS version 1 and + MAPOS 16. + + MAPOS version 1: + + The address field of the MAPOS version 1 frame header contains an 8- + bit-wide destination HDLC address [1]. The least significant bit + (LSB) of the field must always be 1 to indicate the end of the field. + The most significant bit (MSB) is used to indicate whether the frame + is a unicast or a multicast frame. + + In the case of an IPv6 multicast, the MSB of the address field is 1 + to indicate that the frame is multicast. As described above, the LSB + of the address field is 1. The other six bits of the address field + must contain the lowest-order six bits of the IPv6 multicast address. + Figure 2 shows the address field of the MAPOS version 1 frame header + in the case of an IPv6 multicast, where D(1) through D(6) represent + the lowest-order six bits of the IPv6 multicast address. Exceptions + arise when these six bits are either all zeros or all ones. In these + cases, they should be altered to the bit sequence 111110. That is, + the address field should be 0xFD (hexadecimal). + + + + + + + + + + + +Ogura, et. al. Informational [Page 4] + +RFC 3572 IPv6 over MAPOS July 2003 + + + MSB LSB + +-+-+-+-+-+-+-+-+ + | | | | + |1|D(6) - D(1)|1| + | | | | + +-+-+-+-+-+-+-+-+ + ^ ^ + | | + | EA bit (always 1) + 1 (multicast) + + Figure 2. Address mapping in multicasting (MAPOS version 1). + + MAPOS 16: + + The address field of the MAPOS 16 frame header contains the 16-bit- + wide destination HDLC address [2]. The LSB of the first octet must + always be 0 to indicate the continuation of this field, and the LSB + of the second octet must always be 1 to indicate the end of this + field. The MSB of the first octet is used to indicate whether the + frame is a unicast or a multicast frame. + + In the case of an IPv6 multicast, the MSB of the first octet is 1 to + indicate that the frame is multicast. As described above, the LSB of + the first octet is 0 and the LSB of the second octet is 1. The other + 13 bits of the address field must contain the lowest-order 13 bits of + the IPv6 multicast address. Figure 3 shows the address field of the + MAPOS 16 frame header in the case of an IPv6 multicast, where D(1) + through D(13) represent the lowest-order 13 bits of the IPv6 + multicast address. Exceptions arise when these 13 bits are either + all zeros or all ones. In these cases, the address field should be + 0xFEFD (hexadecimal). + + MSB LSB + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | | | | + |1|D(13)-D(8) |0| D(7)-D(1) |1| + | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ^ ^ ^ + | | | + | | +-- EA bit (always 1) + | +-- EA bit (always 0) + 1 (multicast) + + Figure 3. Address mapping in multicasting (MAPOS 16). + + + + + +Ogura, et. al. Informational [Page 5] + +RFC 3572 IPv6 over MAPOS July 2003 + + +3. Interface Identifier + + This section specifies the method of forming the interface identifier + [7]. + + A node that has one or more MAPOS interfaces must create one or more + EUI-64 [8] based interface identifiers. Here, it should be noted + that deriving interface identifiers from HDLC addresses of MAPOS + interfaces is undesirable for the following reasons. + + 1. When a node is connected to a frame switch, an HDLC address is + assigned to the interface of the node from the frame switch via + NSP [6]. (In the remainder of this document, the term "MAPOS + address" is used to refer to the address.) The value of the MAPOS + address assigned to the interface depends on the combination of + the switch number of the frame switch and the port number of the + frame switch to which the interface is connected. The switch + number is required to be unique only within a MAPOS multi-switch + environment [6]; that is, there can be frame switches that have + the same switch number in different MAPOS multi-switch environment + separated by IP routers. Therefore, the uniqueness of a MAPOS + address is guaranteed only within a MAPOS multi-switch + environment. + + Furthermore, if an implementation ensures that the link between + the interface of the node and the port of the frame switch is + hot-swappable, the port number of the frame switch or the frame + switch connected to the interface of the node can be changed, so + the MAPOS address assigned to the interface can also be changed + without performing a system re-start of the node. + + In short, the global uniqueness of a MAPOS address is not + guaranteed, and a MAPOS address is not a built-in address but can + be changed without performing a system re-start. Thus, if an + interface identifier were derived from a MAPOS address, it could + also be changed without a system re-start. This would not follow + the recommendation in [7]. + + 2. In the case of a point-to-point connection between two nodes, the + same MAPOS address is assigned to each interface. Specifically, + in the case of MAPOS version 1, the assigned address is 0x03 [6], + and in the case of MAPOS 16, the assigned address is 0x0003 [2]. + It is not easy to achieve link-locality of the interface + identifier in a strict manner using the same Link-layer address. + + For the above reasons, nodes with MAPOS interfaces must not derive + their interface identifiers from their MAPOS addresses. + + + + +Ogura, et. al. Informational [Page 6] + +RFC 3572 IPv6 over MAPOS July 2003 + + + The following are methods of forming an interface identifier in + the order of preference. These are almost the same as the methods + described in [9] except that a MAPOS address must not be used as a + source of uniqueness when an IEEE global identifier is + unavailable. + + 1) If an IEEE global identifier (EUI-48 or EUI-64) is available + anywhere on the node, it should be used to construct the interface + identifier due to its uniqueness. When extracting an IEEE global + identifier from another device on the node, care should be taken + to ensure that the extracted identifier is presented in canonical + ordering [10]. + + The only transformation from an EUI-64 identifier is to invert the + "u" bit (universal/local bit in IEEE EUI-64 terminology). For + example, for a globally unique EUI-64 identifier as shown in + Figure 4: + + MSB LSB + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+----------------+ + + Figure 4. Globally unique EUI-64 identifier. + + where "c" are the bits of the assigned company_id, "0" is the + value of the universal/local bit to indicate global scope, "g" is + the group/individual bit, and "e" are the bits of the extension + identifier, the IPv6 interface identifier would be as shown in + Figure 5. The only change is inverting the value of the + universal/local bit. + + MSB LSB + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+----------------+ + + Figure 5. IPv6 interface identifier derived from a globally unique + EUI-64 identifier. + + In the case of an EUI-48 identifier, it is first converted to the + EUI-64 format by inserting two octets, with hexadecimal values of + 0xFF and 0xFE, in the middle of the 48-bit MAC (between the + company_id and extension-identifier portions of the EUI-48 value). + + + +Ogura, et. al. Informational [Page 7] + +RFC 3572 IPv6 over MAPOS July 2003 + + + For example, for a globally unique 48-bit EUI-48 identifier as + shown in Figure 6: + + MSB LSB + |0 1|1 3|3 4| + |0 5|6 1|2 7| + +----------------+----------------+----------------+ + |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+ + + Figure 6. Globally unique EUI-48 identifier. + + where "c" are the bits of the assigned company_id, "0" is the + value of the universal/local bit to indicate global scope, "g" is + the group/individual bit, and "e" are the bits of the extension + identifier, the IPv6 interface identifier would be as shown in + Figure 7. + + MSB LSB + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + |cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+----------------+ + + Figure 7. IPv6 interface identifier derived from a globally unique + EUI-48 identifier. + + 2) If an IEEE global identifier is not available, a different source + of uniqueness should be used. Suggested sources of uniqueness + include machine serial numbers, etc. MAPOS addresses must not be + used. + + In this case, the "u" bit of the interface identifier must be set + to 0. + + 3) If a good source of uniqueness cannot be found, it is recommended + that a random number be generated. In this case the "u" bit of + the interface identifier must be set to 0. + +4. Duplicate Address Detection + + Immediately after the system start-up, the MAPOS address has not yet + been assigned to a MAPOS interface. The assignment is not completed + until the adjacent frame switch, or adjacent node in the case of a + point-to-point connection between two nodes, has delivered the MAPOS + address to the interface via NSP [6]. Until then, no data + transmission can be performed on the interface. Thus, a node must + + + +Ogura, et. al. Informational [Page 8] + +RFC 3572 IPv6 over MAPOS July 2003 + + + conduct duplicate address detection [11] on all unicast addresses of + MAPOS interfaces after the MAPOS address assignment has been + completed by NSP. + +5. Source/Target Link-layer Address Option + + As specified in [5], the Source/Target Link-layer Address option is + one of the options included in Neighbor Discovery messages. In [5], + the length of the Source/Target Link-layer Address option field is + specified in units of 8 octets. However, in the case of MAPOS, the + length of the address field is 2 octets (MAPOS 16) or 1 octet (MAPOS + version 1)[1][2]. Thus, if the exact form of the address field is + embedded in the Link-layer Address field of the Source/Target Link- + layer Address option field, the total length of the option field is 4 + octets (MAPOS 16) or 3 octets (MAPOS version 1), both of which are + shorter than 8 octets. + + For the above reason, in the case of MAPOS, the Link-layer Address + field of the Source/Target Link-layer Address option must be extended + with zeros in order to extend the length of the option field to 8 + octets, and the Length field must be set to 1 as shown below. + + MAPOS version 1: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | All 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | All 0 | Address | All 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fields: + + Type: 1 for Source link-layer address. + 2 for Target link-layer address. + + Length: 1 (in units of 8 octets). + + Address: MAPOS version 1 8-bit address. + + Figure 8. Format of the Source/Target Link-layer Address option + field (MAPOS version 1). + + + + + + + + +Ogura, et. al. Informational [Page 9] + +RFC 3572 IPv6 over MAPOS July 2003 + + + MAPOS 16: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | All 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link-layer Address | All 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fields: + + Type: 1 for Source link-layer address. + 2 for Target link-layer address. + + Length: 1 (in units of 8 octets). + + Link-layer Address: MAPOS 16 16-bit address. + + Figure 9. Format of the Source/Target Link-layer Address option + field (MAPOS 16). + +6. Security Considerations + + In MAPOS, a link-layer address (MAPOS address) is assigned to a + network interface by a frame switch via NSP; unlike other link-layer + protocols such as Ethernet that use a built-in address on a network + interface. Security considerations derived from this are described + in 6.1 and 6.2. Because there is no link-layer security in MAPOS, + the same security considerations as those of other link-layer + protocols would be applied to other points. + +6.1. Issues concerning Link-layer Addresses + +6.1.1. Protection against fraudulent reception of traffic + + In MAPOS, a MAPOS address is assigned by a frame switch, and it + consists of the switch number and the port number of the switch to + which the network interface is connected. (In the case of a point- + to-point connection between two nodes, a fixed address is assigned to + their network interfaces.) This brings the following advantages. + + 1. The value of the MAPOS address of a MAPOS network interface + indicates the location of the interface in the MAPOS network. In + other words, the value itself of the destination address of a + MAPOS frame defines the actual location of the network interface + to which the frame should be finally delivered. Therefore, as + long as MAPOS addresses of network interfaces of nodes that have + + + +Ogura, et. al. Informational [Page 10] + +RFC 3572 IPv6 over MAPOS July 2003 + + + been connected to the network through proper administrative + process are held and frames are delivered only to those addresses, + other nodes cannot receive frames unless their network interfaces + are connected to the same ports of frame switches as those to + which network interfaces of properly administered nodes are + connected. This makes fraudulent reception of traffic difficult. + + 2. In the case where MAPOS addresses are not administered as + mentioned above, it is possible that a malicious node could hijack + traffic by spoofing its IPv6 address in a response to an IPv6 + Neighbor Discovery. Even in this case, the node must advertise + the true MAPOS address of its network interface in the response so + that it can receive successive frames. This makes it easy to + pinpoint the location of the host. + +6.1.2. Protection against improper traffic + + A MAPOS frame does not have a field for including its sender's + address. Therefore, in the case where a node sends one-way improper + traffic maliciously or accidentally, there is no way to obtain the + sender's MAPOS address from the traffic and this leads to difficulty + in identifying the node (because source IP addresses might be + forged). + + An effective way to alleviate the difficulty is to moderate the size + of MAPOS multi-switch environment [6]. A common approach is to + separate it using IP routers. This makes it easy to identify the + node sending improper traffic within the multi-switch environment. + To secure the environment against improper traffic from outside it, + boundary IP routers need to block it using packet filtering based on + IP layer information. + +6.2. Uniqueness of Interface Identifiers + + Global uniqueness of a MAPOS address is not guaranteed, and a MAPOS + address is not a built-in address but can be changed without + performing a system re-start if an implementation ensures that the + link between the network interface of the node and the port of the + frame switch is hot-swappable. Thus, an interface identifier must + not be derived from a MAPOS address in order to ensure that the + interface identifier is not changed without a system re-start. + + As a consequence, in IP Version 6 over MAPOS, the existence of + network interfaces other than MAPOS that have IEEE global identifier + based addresses has great importance in creating interface + identifiers. However, it may be common for there to be no such + interfaces on a node, so a different source of uniqueness must be + used. Therefore, sufficient care should be taken to prevent + + + +Ogura, et. al. Informational [Page 11] + +RFC 3572 IPv6 over MAPOS July 2003 + + + duplication of interface identifiers. At present, there is no + protection against duplication through accident or forgery. + +7. References + + [1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access protocol + over SONET/SDH Version 1", RFC 2171, June 1997. + + [2] Murakami, K. and M. Maruyama, "MAPOS 16 - Multiple Access + Protocol over SONET/SDH with 16 Bit Addressing", RFC 2175, June + 1997. + + [3] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, + July 1994. + + [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for + IP Version 6 (IPv6)", RFC 2461, December 1998. + + [6] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension - + Node Switch Protocol", RFC 2173, June 1997. + + [7] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + [8] IEEE, "Guidelines of 64-bit Global Identifier (EUI-64) + Registration Authority", + http://standards.ieee.org/db/oui/tutorials/EUI64.html, March + 1997. + + [9] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, + December 1998. + + [10] Narten, T. and C. Burton, "A Caution On The Canonical Ordering + Of Link-Layer Addresses", RFC 2469, December 1998. + + [11] Thompson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + + + + + + + + + + +Ogura, et. al. Informational [Page 12] + +RFC 3572 IPv6 over MAPOS July 2003 + + +8. Authors' Addresses + + Tsuyoshi Ogura + NTT Network Innovation Laboratories + 3-9-11, Midori-cho + Musashino-shi + Tokyo 180-8585, Japan + + EMail: ogura@core.ecl.net + + + Mitsuru Maruyama + NTT Network Innovation Laboratories + 3-9-11, Midori-cho + Musashino-shi + Tokyo 180-8585, Japan + + EMail: mitsuru@core.ecl.net + + + Toshiaki Yoshida + Werk Mikro Systems + 250-1, Mikajiri + Kumagaya + Saitama 360-0843, Japan + + EMail: yoshida@peta.arch.ecl.net + + + + + + + + + + + + + + + + + + + + + + + + +Ogura, et. al. Informational [Page 13] + +RFC 3572 IPv6 over MAPOS July 2003 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 implementation 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 languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Ogura, et. al. Informational [Page 14] + |