draft-ietf-ipngwg-6over4-02.txt   rfc2529.txt 
IETF B. Carpenter, IBM Network Working Group B. Carpenter
Internet Draft C. Jung, 3Com Request for Comments: 2529 IBM
January 1998 Category: Standards Track C. Jung
3Com
March 1999
Transmission of IPv6 over IPv4 Domains without Explicit Tunnels Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
draft-ietf-ipngwg-6over4-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its Internet community, and requests discussion and suggestions for
areas, and its working groups. Note that other groups may also improvements. Please refer to the current edition of the "Internet
distribute working documents as Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This memo specifies the frame format for transmission of IPv6 [IPV6] This memo specifies the frame format for transmission of IPv6 [IPV6]
packets and the method of forming IPv6 link-local addresses over IPv4 packets and the method of forming IPv6 link-local addresses over IPv4
domains. It also specifies the content of the Source/Target Link- domains. It also specifies the content of the Source/Target Link-
layer Address option used in the Router Solicitation, Router layer Address option used in the Router Solicitation, Router
Advertisement, Neighbor Solicitation, and Neighbor Advertisement Advertisement, Neighbor Solicitation, and Neighbor Advertisement and
and Redirect messages, when those messages are transmitted on an Redirect messages, when those messages are transmitted on an IPv4
IPv4 multicast network. multicast network.
The motivation for this method is to allow isolated IPv6 hosts, The motivation for this method is to allow isolated IPv6 hosts,
located on a physical link which has no directly connected IPv6 located on a physical link which has no directly connected IPv6
router, to become fully functional IPv6 hosts by using an IPv4 router, to become fully functional IPv6 hosts by using an IPv4 domain
domain that supports IPv4 multicast as their virtual local that supports IPv4 multicast as their virtual local link. It uses
link. It uses IPv4 multicast as a "virtual Ethernet." IPv4 multicast as a "virtual Ethernet".
^L
Table of Contents: Table of Contents
1. Introduction....................................................2 1. Introduction....................................................2
2. Maximum Transmission Unit.......................................3 2. Maximum Transmission Unit.......................................2
3. Frame Format....................................................3 3. Frame Format....................................................3
4. Stateless Autoconfiguration and Link-Local Addresses............4 4. Stateless Autoconfiguration and Link-Local Addresses............3
5. Address Mapping -- Unicast......................................4 5. Address Mapping -- Unicast......................................4
6. Address Mapping -- Multicast....................................5 6. Address Mapping -- Multicast....................................4
7. Scaling and Transition Isues....................................5 7. Scaling and Transition Isues....................................5
8. IANA considerations.............................................6 8. IANA Considerations.............................................6
9. Security considerations.........................................6 9. Security Considerations.........................................6
Acknowledgements...................................................7 Acknowledgements...................................................7
References.........................................................7 References.........................................................7
APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8 APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8
Authors' Addresses.................................................9 Authors' Addresses.................................................9
Full Copyright Notice..............................................9 Full Copyright Notice.............................................10
1. Introduction 1. Introduction
This memo specifies the frame format for transmission of IPv6 [IPV6] This memo specifies the frame format for transmission of IPv6 [IPV6]
packets and the method of forming IPv6 link-local addresses over IPv4 packets and the method of forming IPv6 link-local addresses over IPv4
multicast "domains". For the purposes of this document, an IPv4 domain multicast "domains". For the purposes of this document, an IPv4
is a fully interconnected set of IPv4 subnets, within the same local domain is a fully interconnected set of IPv4 subnets, within the same
multicast scope, on which there are at least two IPv6 nodes conforming local multicast scope, on which there are at least two IPv6 nodes
to this specification. This IPv4 domain could form part of the conforming to this specification. This IPv4 domain could form part
globally-unique IPv4 address space, or could form part of a private of the globally-unique IPv4 address space, or could form part of a
IPv4 network [RFC 1918]. private IPv4 network [RFC 1918].
This memo also specifies the content of the Source/Target Link-layer This memo also specifies the content of the Source/Target Link-layer
Address option used in the Router Solicitation, Router Advertisement, Address option used in the Router Solicitation, Router Advertisement,
Neighbor Solicitation, Neighbor Advertisement and Redirect messages Neighbor Solicitation, Neighbor Advertisement and Redirect messages
described in [DISC], when those messages are transmitted on an IPv4 described in [DISC], when those messages are transmitted on an IPv4
multicast domain. multicast domain.
The motivation for this method is to allow isolated IPv6 hosts, The motivation for this method is to allow isolated IPv6 hosts,
located on a physical link which has no directly connected IPv6 located on a physical link which has no directly connected IPv6
router, to become fully functional IPv6 hosts by using an IPv4 multicast router, to become fully functional IPv6 hosts by using an IPv4
domain as their virtual local link. Thus, at least one IPv6 router multicast domain as their virtual local link. Thus, at least one
using the same method must be connected to the same IPv4 domain if IPv6 router using the same method must be connected to the same IPv4
IPv6 routing to other links is required. domain if IPv6 routing to other links is required.
IPv6 hosts connected using this method do not require IPv4-compatible IPv6 hosts connected using this method do not require IPv4-compatible
addresses or configured tunnels. In this way IPv6 gains considerable addresses or configured tunnels. In this way IPv6 gains considerable
independence of the underlying links and can step over many hops of independence of the underlying links and can step over many hops of
IPv4 subnets. The mechanism is known formally as "IPv6 over IPv4" IPv4 subnets. The mechanism is known formally as "IPv6 over IPv4" or
or "6over4" and colloquially as "virtual Ethernet." "6over4" and colloquially as "virtual Ethernet".
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" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
^L
2. Maximum Transmission Unit 2. Maximum Transmission Unit
The default MTU size for IPv6 packets on an IPv4 domain is 1480 The default MTU size for IPv6 packets on an IPv4 domain is 1480
octets. This size may be varied by a Router Advertisement [DISC] octets. This size may be varied by a Router Advertisement [DISC]
containing an MTU option which specifies a different MTU, or by containing an MTU option which specifies a different MTU, or by
manual configuration of each node. manual configuration of each node.
Note that if by chance the IPv6 MTU size proves to be too large for Note that if by chance the IPv6 MTU size proves to be too large for
some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While
undesirable, this is not disastrous. However, the IPv4 "do not fragment" undesirable, this is not disastrous. However, the IPv4 "do not
bit MUST NOT be set in the encapsulating IPv4 header. fragment" bit MUST NOT be set in the encapsulating IPv4 header.
3. Frame Format 3. Frame Format
IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4 IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4
protocol type of 41, the same as has been assigned in [RFC 1933] for protocol type of 41, the same as has been assigned in [RFC 1933] for
IPv6 packets that are tunneled inside of IPv4 frames. The IPv4 IPv6 packets that are tunneled inside of IPv4 frames. The IPv4
header contains the Destination and Source IPv4 addresses. The IPv4 header contains the Destination and Source IPv4 addresses. The IPv4
packet body contains the IPv6 header followed immediately by the packet body contains the IPv6 header followed immediately by the
payload. payload.
skipping to change at page 4, line 5 skipping to change at page 3, line 45
+-------+-------+-------+-------+-------+------+------+ +-------+-------+-------+-------+-------+------+------+
If there are IPv4 options, then padding SHOULD be added to the IPv4 If there are IPv4 options, then padding SHOULD be added to the IPv4
header such that the IPv6 header starts on a boundary that is a 32- header such that the IPv6 header starts on a boundary that is a 32-
bit offset from the end of the datalink header. bit offset from the end of the datalink header.
The Time to Live field SHOULD be set to a low value, to prevent such The Time to Live field SHOULD be set to a low value, to prevent such
packets accidentally leaking from the IPv4 domain. This MUST be a packets accidentally leaking from the IPv4 domain. This MUST be a
configurable parameter, with a recommended default of 8. configurable parameter, with a recommended default of 8.
^L
4. Stateless Autoconfiguration and Link-Local Addresses 4. Stateless Autoconfiguration and Link-Local Addresses
The Interface Identifier [AARCH] of an IPv4 interface is the 32-bit The Interface Identifier [AARCH] of an IPv4 interface is the 32-bit
IPv4 address of that interface, with the octets in the same order in IPv4 address of that interface, with the octets in the same order in
which they would appear in the header of an IPv4 packet, padded at which they would appear in the header of an IPv4 packet, padded at
the left with zeros to a total of 64 bits. Note that the "Universal/ the left with zeros to a total of 64 bits. Note that the "Universal/
Local" bit is zero, indicating that the Interface Identifer is not Local" bit is zero, indicating that the Interface Identifer is not
globally unique. When the host has more than one IPv4 address in use globally unique. When the host has more than one IPv4 address in use
on the physical interface concerned, an administrative choice of one on the physical interface concerned, an administrative choice of one
of these IPv4 addresses is made. of these IPv4 addresses is made.
skipping to change at page 5, line 5 skipping to change at page 4, line 45
Length: Length:
1 (in units of 8 octets). 1 (in units of 8 octets).
IPv4 Address: IPv4 Address:
The 32 bit IPv4 address, in network byte order. This is the address The 32 bit IPv4 address, in network byte order. This is the address
the interface currently responds to, and may be different from the the interface currently responds to, and may be different from the
Interface Identifier for stateless autoconfiguration. Interface Identifier for stateless autoconfiguration.
^L
6. Address Mapping -- Multicast 6. Address Mapping -- Multicast
IPv4 multicast MUST be available. An IPv6 packet with a multicast IPv4 multicast MUST be available. An IPv6 packet with a multicast
destination address DST MUST be transmitted to the IPv4 multicast destination address DST MUST be transmitted to the IPv4 multicast
address of Organization-Local Scope using the mapping below. These address of Organization-Local Scope using the mapping below. These
IPv4 multicast addresses SHOULD be taken from the block 239.192.0.0/16, IPv4 multicast addresses SHOULD be taken from the block
a sub-block of the Organization-Local Scope address block, or, if 239.192.0.0/16, a sub-block of the Organization-Local Scope address
all of those are not available, from the expansion blocks block, or, if all of those are not available, from the expansion
defined in [ADMIN]. Note that when they are formed blocks defined in [ADMIN]. Note that when they are formed using the
using the expansion blocks, they use only a /16 sized block. expansion blocks, they use only a /16 sized block.
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| 239 | OLS | DST14 | DST15 | | 239 | OLS | DST14 | DST15 |
+-------+-------+-------+-------+ +-------+-------+-------+-------+
DST14, DST15 last two bytes of IPv6 multicast address. DST14, DST15 last two bytes of IPv6 multicast address.
OLS from the configured Organization-Local OLS from the configured Organization-Local
Scope address block. SHOULD be 192, Scope address block. SHOULD be 192,
see [ADMIN] for details. see [ADMIN] for details.
No new IANA registration procedures are required for the above. No new IANA registration procedures are required for the above. See
See appendix A. for a list of all the multicast groups that must be appendix A. for a list of all the multicast groups that must be
joined to support Neighbor Discovery. joined to support Neighbor Discovery.
7. Scaling and Transition Issues 7. Scaling and Transition Issues
The multicast mechanism described in Section 6 above appears to have The multicast mechanism described in Section 6 above appears to have
essentially the same scaling properties as native IPv6 over most essentially the same scaling properties as native IPv6 over most
media, except for the slight reduction in MTU size which will media, except for the slight reduction in MTU size which will
slightly reduce bulk throughput. On an ATM network, where IPv4 slightly reduce bulk throughput. On an ATM network, where IPv4
multicast relies on relatively complex mechanisms, it is to be multicast relies on relatively complex mechanisms, it is to be
expected that IPv6 over IPv4 over ATM will perform less well than expected that IPv6 over IPv4 over ATM will perform less well than
native IPv6 over ATM. native IPv6 over ATM.
The "IPv6 over IPv4" mechanism is intended to take its place in the The "IPv6 over IPv4" mechanism is intended to take its place in the
range of options available for transition from IPv4 to IPv6. In range of options available for transition from IPv4 to IPv6. In
particular it allows a site to run both IPv4 and IPv6 in coexistence, particular it allows a site to run both IPv4 and IPv6 in coexistence,
without having to configure IPv6 hosts either with IPv4-compatible without having to configure IPv6 hosts either with IPv4-compatible
addresses or with tunnels. Interfaces of the IPv6 router and hosts addresses or with tunnels. Interfaces of the IPv6 router and hosts
will of course need to be enabled in "6over4" mode. will of course need to be enabled in "6over4" mode.
A site may choose to start its IPv6 transition by configuring one A site may choose to start its IPv6 transition by configuring one
IPv6 router to support "6over4" on an interface connected to IPv6 router to support "6over4" on an interface connected to the
the site's IPv4 domain, and another IPv6 format on an interface site's IPv4 domain, and another IPv6 format on an interface connected
connected to the IPv6 Internet. Any enabled "6over4" hosts to the IPv6 Internet. Any enabled "6over4" hosts in the IPv4 domain
in the IPv4 domain will then be able to communicate both with the will then be able to communicate both with the router and with the
router and with the IPv6 Internet, without manual configuration of a IPv6 Internet, without manual configuration of a tunnel and without
tunnel and without the need for an IPv4-compatible IPv6 address, the need for an IPv4-compatible IPv6 address, either stateless or
either stateless or stateful address configuration providing the IPv6 stateful address configuration providing the IPv6 address to the IPv6
address to the IPv6 host. host.
^L During transition, routers may need to advertise at least two IPv6
During transition, routers may need to advertise at least two prefixes, one for the native LAN (e.g. Ethernet) and one for
IPv6 prefixes, one for the native LAN (e.g. Ethernet) and one for "6over4". As with any IPv6 prefix assigned to an IPv6 subnet, the
"6over4." As with any IPv6 prefix assigned to an IPv6 subnet, the latter MUST be unique within its scope, whether site-local or global
latter MUST be unique within its scope, whether site-local or addressing is used.
global addressing is used.
Also note that when a router is handling both native LAN and Also note that when a router is handling both native LAN and "6over4"
"6over4" on the same physical interface, during on the same physical interface, during stateless autoconfiguration,
stateless autoconfiguration, there is a period when IPv6 link-local there is a period when IPv6 link-local addresses are used, in both
addresses are used, in both cases with the prefix FE80::/64. cases with the prefix FE80::/64. Note that the prefix-length for
Note that the prefix-length for these link-local adddress MUST these link-local adddress MUST then be 128 so that the two cases can
then be 128 so that the two cases can be distinguished. be distinguished.
As the site installs additional IPv6 routers, "6over4" hosts As the site installs additional IPv6 routers, "6over4" hosts which
which become physically adjacent to IPv6 routers can be changed to become physically adjacent to IPv6 routers can be changed to run as
run as native IPv6 hosts, with the the only impact on IPv6 native IPv6 hosts, with the the only impact on IPv6 applications
applications being a slight increase in MTU size. At some stage being a slight increase in MTU size. At some stage during transition,
during transition, it might be convenient to dual home hosts it might be convenient to dual home hosts in both native LAN and
in both native LAN and "6over4" mode, but this is not required. "6over4" mode, but this is not required.
8. IANA considerations 8. IANA Considerations
No assignments by the IANA are required beyond those in [ADMIN]. No assignments by the IANA are required beyond those in [ADMIN].
9. Security considerations 9. Security Considerations
Implementors should be aware that, in addition to posssible attacks Implementors should be aware that, in addition to posssible attacks
against IPv6, security attacks against IPv4 must also be considered. against IPv6, security attacks against IPv4 must also be considered.
Use of IP security at both IPv4 and IPv6 levels should nevertheless Use of IP security at both IPv4 and IPv6 levels should nevertheless
be avoided, for efficiency reasons. For example, if IPv6 is running be avoided, for efficiency reasons. For example, if IPv6 is running
encrypted, encryption of IPv4 would be redundant except if traffic encrypted, encryption of IPv4 would be redundant except if traffic
analysis is felt to be a threat. If IPv6 is running authenticated, analysis is felt to be a threat. If IPv6 is running authenticated,
then authentication of IPv4 will add little. Conversely, IPv4 then authentication of IPv4 will add little. Conversely, IPv4
security will not protect IPv6 traffic once it leaves the IPv6-over- security will not protect IPv6 traffic once it leaves the IPv6-over-
IPv4 domain. Therefore, implementing IPv6 security is required even IPv4 domain. Therefore, implementing IPv6 security is required even
if IPv4 security is available. if IPv4 security is available.
There is a possible spoofing attack in which spurious 6over4 There is a possible spoofing attack in which spurious 6over4 packets
packets are injected into a 6over4 domain from outside. Thus, are injected into a 6over4 domain from outside. Thus, boundary
boundary routers MUST discard multicast IPv4 packets with source routers MUST discard multicast IPv4 packets with source or
or destination multicast addresses of organisation local scope destination multicast addresses of organisation local scope as
as defined in section 6 above, if they arrive on physical defined in section 6 above, if they arrive on physical interfaces
interfaces outside that scope. To defend against spurious outside that scope. To defend against spurious unicast 6over4
unicast 6over4 packets, boundary routers MUST discard incoming packets, boundary routers MUST discard incoming IPv4 packets with
IPv4 packets with protocol type 41 from unknown sources, i.e. protocol type 41 from unknown sources, i.e. IPv6-in-IPv4 tunnels
IPv6-in-IPv4 tunnels must only be accepted from trusted sources. must only be accepted from trusted sources. Unless IPSEC
Unless IPSEC authentication is available, the RECOMMENDED technique authentication is available, the RECOMMENDED technique for this is to
for this is to configure the boundary router only to accept configure the boundary router only to accept protocol type 41 packets
protocol type 41 packets from source addresses within a trusted from source addresses within a trusted range or ranges.
range or ranges.
^L
Acknowledgements Acknowledgements
The basic idea presented above is not original, and we have had The basic idea presented above is not original, and we have had
invaluable comments from Matt Crawford, Steve Deering, Dan invaluable comments from Matt Crawford, Steve Deering, Dan
Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, Thomas Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, Thomas Narten,
Narten, and other members of the IPNG and NGTRANS working groups. and other members of the IPNG and NGTRANS working groups.
This document is seriously ripped off from RFC 1972 written by This document is seriously ripped off from RFC 1972 written by Matt
Matt Crawford. Brian Carpenter was at CERN when the work was started. Crawford. Brian Carpenter was at CERN when the work was started.
References References
[AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373 Architecture", RFC 2373, July 1998.
[ADMIN] Meyer, D., "Administratively Scoped IP Multicast", [ADMIN] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, BCP 23. RFC 2365, July 1998.
[CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address [CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462 Autoconfiguration", RFC 2462, December 1998.
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461 Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460 (IPv6) Specification", RFC 2460, December 1998.
[RFC 791] Postel, J., "Internet Protocol", RFC 791 [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.
Lear, E., "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
RFC 1918 RFC 1918, February 1996.
[RFC 1933] Gilligan, R., and Nordmark, E., "Transition Mechanisms for [RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933 IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC 2119] Key words for use in RFCs to Indicate Requirement Levels. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
S. Bradner, RFC 2119 Requirement Levels", BCP 14, RFC 2119, March 1997.
^L [RFC 1972] Crawford, M., "A Method for the Transmission of IPv6
Packets over Ethernet Networks", RFC 1972, August 1996.
APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery
The following IPv4 multicast groups are used to support Neighbor The following IPv4 multicast groups are used to support Neighbor
Discovery with this specification. The IPv4 addresses listed Discovery with this specification. The IPv4 addresses listed in this
in this section were obtained by looking at the IPv6 multicast section were obtained by looking at the IPv6 multicast addresses that
addresses that Neigbour Discovery uses, and deriving the resulting Neigbour Discovery uses, and deriving the resulting IPv4 "virtual
IPv4 "virtual link-layer" addresses that are generated from them link-layer" addresses that are generated from them using the
using the algorithm given in Section 6. algorithm given in Section 6.
all-nodes multicast address all-nodes multicast address
- the administratively-scoped IPv4 multicast address used to - the administratively-scoped IPv4 multicast address used to
reach all nodes in the local IPv4 domain supporting this reach all nodes in the local IPv4 domain supporting this
specification. 239.OLS.0.1 specification. 239.OLS.0.1
all-routers multicast address all-routers multicast address
- the administratively-scoped IPv4 multicast address to reach - the administratively-scoped IPv4 multicast address to reach
all routers in the local IPv4 domain supporting this all routers in the local IPv4 domain supporting this
specification. 239.OLS.0.2 specification. 239.OLS.0.2
solicited-node multicast address solicited-node multicast address
- an administratively scoped multicast address that is computed - an administratively scoped multicast address that is computed
as a function of the solicited target's address by taking the as a function of the solicited target's address by taking the
low-order 24 bits of the IPv4 address used to form the IPv6 low-order 24 bits of the IPv4 address used to form the IPv6
address, and prepending the prefix FF02:0:0:0:0:1:FF00::/104 address, and prepending the prefix FF02:0:0:0:0:1:FF00::/104
[AARCH]. This is then mapped to the IPv4 [AARCH]. This is then mapped to the IPv4 multicast address by
multicast address by the method described in this document. the method described in this document. For example, if the
For example, if the IPv4 address used to form the IPv6 address IPv4 address used to form the IPv6 address is W.X.Y.Z, then
is W.X.Y.Z, then the IPv6 solicited node multicast address is the IPv6 solicited node multicast address is
FF02::1:255.X.Y.Z and the corresponding IPv4 multicast address is FF02::1:255.X.Y.Z and the corresponding IPv4 multicast
239.OLS.Y.Z address is 239.OLS.Y.Z
^L
Authors' Addresses Authors' Addresses
Brian E. Carpenter Brian E. Carpenter
Internet Division Internet Division
IBM United Kingdom Laboratories IBM United Kingdom Laboratories
MP 185, Hursley Park MP 185, Hursley Park
Winchester, Hampshire S021 2JN, UK Winchester, Hampshire S021 2JN, UK
Email: brian@hursley.ibm.com EMail: brian@hursley.ibm.com
Cyndi Jung Cyndi Jung
3Com Corporation 3Com Corporation
5400 Bayfront Plaza, Mailstop 3219 5400 Bayfront Plaza, Mailstop 3219
Santa Clara, California 95052-8145 Santa Clara, California 95052-8145
Email: cmj@3Com.com EMail: cmj@3Com.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at line 429 skipping to change at line 406
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
^L
 End of changes. 48 change blocks. 
155 lines changed or deleted 132 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/