flow detection, or host originated explicit requests. Neighbor
Discovery is used without modification for all intra-LL control
(including the initiation of NBMA shortcut discovery). Router to
router NHRP is used to obtain the IPv6/NBMA address mappings for
shortcut targets outside a source's Logical Link.
7. Security Considerations
This architecture introduces no new protocols, but depends on
existing protocols (NHRP, IPv6, ND, MARS) and is therefore subject to
all the security threats inherent in these protocols. This
architecture should not be used in a domain where any of the base
protocols are considered unacceptably insecure. However, this
protocol itself does not introduce additional security threats.
While this proposal does not introduce any new security mechanisms
all current IPv6 security mechanisms will work without modification
for NBMA. This includes both authentication and encryption for both
Neighbor Discovery protocols as well as the exchange of IPv6 data
packets. The MARS protocol is modified in a manner that does not
affect or augment the security offered by RFC2022.
Acknowledgments
Eric Nordmark confirmed the usefulness of ND Redirect messages in
private email during the March 1996 IETF. The discussions with
various ION WG members during the June and December 1996 IETF helped
solidify the architecture described here. Grenville Armitage's
original work on IPv6/NBMA occurred while employed at Bellcore.
Elements of section 5 were borrowed from Matt Crawford's memo on IPv6
over Ethernet.
Authors' Addresses
Grenville Armitage
Bell Laboratories, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
USA
EMail: gja@lucent.com
Peter Schulter
Bright Tiger Technologies
125 Nagog Park
Acton, MA 01720
EMail: paschulter@acm.org
Markus Jork
European Applied Research Center
Digital Equipment GmbH
CEC Karlsruhe
Vincenz-Priessnitz-Str. 1
D-76131 Karlsruhe
Germany
EMail: jork@kar.dec.com
Geraldine Harter
Digital UNIX Networking
Compaq Computer Corporation
110 Spit Brook Road
Nashua, NH 03062
EMail: harter@zk3.dec.com
References
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC2460, December 1998.
[2] ATM Forum, "ATM User Network Interface (UNI) Specification
Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood
Cliffs, NJ, June 1995.
[3] Crawford, M., "A Method for the Transmission of IPv6 Packets over
Ethernet Networks", RFC1972, August 1996.
[4] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC1483, July 1993.
[5] Armitage, G., "Support for Multicast over UNI 3.1 based ATM
Networks", RFC2022, November 1996.
[6] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998.
[7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC2461, December 1998.
[8] Luciani, J., Katz, D., Piscitello, D. Cole B and N. Doraswamy,
"NBMA Next Hop Resolution Protocol (NHRP)", RFC2332, April 1998.
[9] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462, December 1998.
[10] "64-Bit Global Identifier Format Tutorial",
http://standards.ieee.org/db/oui/tutorials/EUI64.html.
[11] Katsube, Y., Nagami, K. and H. Esaki, "Toshiba's Router
Architecture Extensions for ATM : Overview", RFC2098, February
1997.
[12] P. Newman, T. Lyon, G. Minshall, "Flow Labeled IP: ATM under
IP", Proceedings of INFOCOM'96, San Francisco, March 1996,
pp.1251-1260
[13] Piscitello, D. and J. Lawrence, "The Transmission of IP
Datagrams over the SMDS Service", RFC1209, March 1991.
[14] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", STD 37, RFC826,
November 1982.
[15] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
version 6", RFC1981, August 1996.
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[17] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM
Networks", RFC2492, January 1999.
[18] C. Perkins, J. Bound, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", Work in Progress.
[19] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998.
Appendix A. IPv6 Protocol Operation Description
The IPv6 over NBMA model described in this document maintains the
complete semantics of the IPv6 protocols. No changes need to be made
to the IPv6 Network Layer. Since the concept of the security
association is not being changed for NBMA, this framework maintains
complete IPv6 security semantics and features. This allows IPv6 nodes
to choose their responses to solicitations based on security
information as is done with other datalinks, thereby maintaining the
semantics of Neighbor Discovery since it is always the solicited node
that chooses what (and even if) to reply to the solicitation. Thus,
NBMA will be transparent to the network layer except in cases where
extra services (such as QoS VCs) are offered.
The remainder of this Appendix describes how the core IPv6 protocols
will operate within the model described here.
A.1 Neighbor Discovery Operations
Before performing any sort of Neighbor discover operation, each node
must first join the all-node multicast group, and it's solicited node
multicast address (the use of this address in relation to DAD is
described in A.1.4). The IPv6 network layer will join these
multicast groups as described in 4.2.
A.1.1 Performing Address Resolution
An IPv6 host performs address resolution by sending a Neighbor
Solicitation to the solicited-node multicast address of the target
host, as described in [7]. The Neighbor Solicitation message will
contain a Source Link-Layer Address Option set to the soliciting
node's NBMA address on the LL.
When the local node's IPv6/NBMA driver is passed the Neighbor
Solicitation message from the IPv6 network layer, it follows the
steps described in section 4.4.2 Sending Multicast Data.
One or more nodes will receive the Neighbor Solicitation message.
The nodes will process the data as described in section 4.5 and pass
the de-encapsulated packets to the IPv6 network layer.
If the receiving node is the target of the Neighbor Solicitation it
will update its Neighbor cache with the soliciting node's NBMA
address, contained in the Neighbor Solicitation message's Source
Link-Layer Address Option as described in [7].
The solicited IPv6 host will respond to the Neighbor Solicitation
with a Neighbor Advertisement message sent to the IPv6 unicast
address of the soliciting node. The Neighbor Advertisement message
will contain a Target Link-Layer Address Option set to the solicited
node's NBMA address on the LL.
The solicited node's IPv6/NBMA driver will be passed the Neighbor
Advertisement and the soliciting node's link-layer address from the
IPv6 network layer. It will then follow the steps described in
section section 4.4.1 to send the NA message to the soliciting node.
This will create a pt-pt VC between the solicited node and soliciting
node if one did not already exist.
The soliciting node will then receive the Neighbor Advertisement
message over the new PtP VC, de-encapsulate the message, and pass it
to the IPv6 Network layer for processing as described in section 4.5.
The soliciting node will then make the appropriate entries in it's
Neighbor cache, including caching the NBMA link-layer address of the
solicited node as described in [7].
At this point each system has a complete Neighbor cache entry for the
other system. They can exchange data over the pt-pt VC newly created
by the solicited node when it returned the Neighbor Advertisement, or
create a new VC.
An IPv6 host can also send an Unsolicited Neighbor Advertisemnent to
the all-nodes multicast address. When the local node IPv6/NBMA driver
is passed the Neighbor Advertisement from the IPv6 network layer, it
follows the steps described in section 4.4.2 to send the NA message
to the all-nodes multicast address. Each node will process the
incoming packet as described in section 4.5 and then pass the packet
to the IPv6 network layer where it will be processed as described in
[7].
A.1.2 Performing Router Discovery
Router Discovery is described in [7]. To support Router Discovery an
IPv6 router will join the IPv6 all-routers multicast group address.
When the IPv6/NBMA driver gets the JoinLocalGroup request from the
IPv6 Network Layer, it follows the process described in section 4.2.
IPv6 routers periodically send unsolicited Router Advertisements
announcing their availability on the LL. When an IPv6 router sends
an unsolicited Router Advertisement, it sends a data packet addressed
to the IPv6 all-nodes multicast address. When the local node
IPv6/NBMA driver gets the Router Advertisement message from the IPv6
network layer, it transmits the message by following steps described
in section 4.4.2. The MARS will transmit the packet on the LL's
ClusterControlVC, which sends the packets to all nodes on the LL.
Each node on the LL will then process the incoming packet as
described in section 4.5 and pass the received packet to the IPv6
Network layer for processing as appropriate.
To perform Router Discovery, an IPv6 host sends a Router Solicitation
message to the all-routers multicast address. When the local node
IPv6/NBMA driver gets the request from the IPv6 Network Layer to send
the packet, it follows the steps described in section 4.4.2. The RS
message will be sent to either those nodes which have joined the
all-routers multicast group or to all nodes. The nodes which receive
the RA message will process the message as described in section 4.5
and pass the RA message up to the IPv6 layer for processing. Only
those nodes which are routers will process the message and respond to
it.
An IPv6 router responds to a Router Solicitation by sending a Router
Advertisement addressed to the IPv6 all-nodes multicast address if
the source address of the Router Solicitation was the unspecified
address. If the source address in the Router Solicitation is not the
unspecified address, the the router will unicast the Router
Advertisement to the soliciting node. If the router sends the Router
Advertisement to the all-nodes multicast address then it follows the
steps described above for unsolicited Router Advertisements.
If the Router Advertisement is to be unicast to the soliciting node,
the IPv6 network layer will give the node's IPv6/NBMA driver the
Router Advertisement and link-layer address of the soliciting node
(obtained through Address Resolution if necessary) which will send
the packet according to the steps described in section 4.4.1 This
will result in a new pt-pt VC being created between the router and
the soliciting node if one did not already exist.
The soliciting node will receive and process the Router Advertisement
as described in section 4.5 and will pass the RA message to the IPv6
network layer. The IPv6 network layer may, depending on the state of
the Neighbor cache entry, update the Neighbor cache with the router's
NBMA address, contained in the Router Advertisement message's Source
Link-Layer Address Option.
If a pt-pt VC is set up during Router Discovery, subsequent IPv6 best
effort unicast data between the soliciting node and the router will
be transmitted over the new PtP VC.
A.1.3 Performing Neighbor Unreachability Detection (NUD)
Neighbor Unreachability Detection (NUD) is the process by which an
IPv6 host determines that a neighbor is no longer reachable, as
described in [7]. Each Neighbor cache entry contains information used
by the NUD algorithm to detect reachability failures. Confirmation
of a neighbor's reachability comes either from upper-layer protocol
indications that data recently sent to the neighbor was received, or
from the receipt of a Neighbor Advertisement message in response to a
Neighbor Solicitation probe.
Connectivity failures at the node's IPv6/NBMA driver, such as
released VCs (see section 4.6) and the inability to create a VC to a
neighbor (see section 4.4.1), are detected and handled at the IPv6
network layer, through Neighbor Unreachability Detection. The node's
IPv6/NBMA driver does not attempt to detect or recover from these
conditions.
A persistent failure to create a VC from the IPv6 host to one of its
IPv6 neighbors will be detected and handled through NUD. On each
attempt to send data from the IPv6 host to its neighbor, the node's
IPv6/NBMA driver will attempt to set up a VC to the neighbor, and
failing to do so, will drop the packet. IPv6 reachability
confirmation timers will eventually expire, and the neighbor's
Neighbor cache entry will enter the PROBE state. The PROBE state will
cause the IPv6 host to unicast Neighbor Solicitations to the
neighbor, which will be dropped by the local node's IPv6/NBMA driver
after again failing to setup the VC. The IPv6 host will therefore
never receive the solicited Neighbor Advertisements needed for
reachability confirmation, causing the neighbor's entry to be deleted
from the Neighbor cache. The next time the IPv6 host tries to send
data to that neighbor, address resolution will be performed.
Depending on the reason for the previous failure, connectivity to the
neighbor could be re-established (for example, if the previous VC
setup failure was caused by an obsolete link-layer address in the
Neighbor cache).
In the event that a VC from an IPv6 neighbor is released, the next
time a packet is sent from the IPv6 host to the neighbor, the node's
IPv6/NBMA driver will recognize that it no longer has a VC to that
neighbor and attempt to setup a new VC to the neighbor. If, on the
first and on subsequent transmissions, the node is unable to create a
VC to the neighbor, NUD will detect and handle the failure as
described earlier (handling the persistent failure to create a VC
from the IPv6 host to one of its IPv6 neighbors). Depending on the
reason for the previous failure, connectivity to the neighbor may or
may not be re-established.
A.1.4 Performing Duplicate Address Detection (DAD)
An IPv6 host performs Duplicate Address Detection (DAD) to determine
that the address it wishes to use on the LL (i.e. a tentative
address) is not already in use, as described in [9] and [7].
Duplicate Address Detection is performed on all addresses the host
wishes to use, regardless of the configuration mechanism used to
obtain the address.
Prior to performing Duplicate Address Detection, a host will join the
all-nodes multicast address and the solicited-node multicast address
corresponding to the host's tentative address (see 4.2. Joining a
Multicast Group). The IPv6 host initiates Duplicate Address Detection
by sending a Neighbor Solicitation to solicited-node multicast
address corresponding to the host's tentative address, with the
tentative address as the target. When the local node's IPv6/NBMA
driver gets the Neighbor Solicitation message from the IPv6 network
layer, it follows the steps outlined in section 4.4.2. The NS
message will be sent to those nodes which joined the target
solicited-node multicast group or to all nodes. The DAD NS message
will be received by one or more nodes on the LL and processed by each
as described in section 4.5. Note that the MARS client of the
sending node will filter out the message so that the sending node's
IPv6 network layer will not see the message. The IPv6 network layer
of any node which is not a member of the target solicited-node
multicast group will discard the Neighbor Solicitation message.
If no other hosts have joined the solicited-node multicast address
corresponding to the tentative address, then the host will not
receive a Neighbor Advertisement containing its tentative address as
the target. The host will perform the retransmission logic described
in [9], terminate Duplicate Address Detection, and assign the
tentative address to the NBMA interface.
Otherwise, other hosts on the LL that have joined the solicited-node
multicast address corresponding to the tentative address will process
the Neighbor Solicitation. The processing will depend on whether or
not receiving IPv6 host considers the target address to be tentative.
If the receiving IPv6 host's address is not tentative, the host will
respond with a Neighbor Advertisement containing the target address.
Because the source of the Neighbor Solicitation is the unspecified
address, the host sends the Neighbor Advertisement to the all-nodes
multicast address following the steps outlined in section 4.4.2. The
DAD NA message will be received and processed by the MARS clients on
all nodes in the LL as described in section 4.5. Note that the
sending node will filter the incoming message since the CMI in the
message header will match that of the receiving node. All other
nodes will de-encapsulate the message and pass it to the IPv6 network
layer. The host performing DAD will detect that its tentative
address is the target of the Neighbor Advertisement, and determine
that the tentative address is not unique and cannot be assigned to
its NBMA interface.
If the receiving IPv6 host's address is tentative, then both hosts
are performing DAD using the same tentative address. The receiving
host will determine that the tentative address is not unique and
cannot be assigned to its NBMA interface.
A.1.5 Processing Redirects
An IPv6 router uses a Redirect Message to inform an IPv6 host of a
better first-hop for reaching a particular destination, as described
in [7]. This can be used to direct hosts to a better first hop
router, another host on the same LL, or to a transient neighbor on
another LL. The IPv6 router will unicast the Redirect to the IPv6
source address that triggered the Redirect. The router's IPv6/NBMA
driver will transmit the Redirect message using the procedure
described in section 4.4.1. This will create a VC between the router
and the redirected host if one did not previously exist.
The IPv6/NBMA driver of the IPv6 host that triggered the Redirect
will receive the encapsulated Redirect over one of it's pt-pt VCs.
It will the de-encapsulate the packet, and pass the Redirect message
to the IPv6 Network Layer, as described section 4.5.
Subsequent data sent from the IPv6 host to the destination will be
sent to the next-hop address specified in the Redirect Message. For
NBMA networks, the Redirect Message should contain the link-layer
address option as described in [7] and section 5.2, thus the
redirected node will not have to perform a Neighbor Solicitation to
learn the link-layer address of the node to which it has been
redirected. Thus, the redirect can be to any node on the NBMA
network, regardless of the LL membership of the new target node.
This allows NBMA hosts to be redirected off their LL to achieve
shortcut by using standard IPv6 protocols.
Once redirected, the IPv6 network layer will give the node's
IPv6/NBMA driver the IPv6 packet and the link-layer address of the
next-hop node when it sends data to the redirected destination. The
node's IPv6/NBMA driver will determine if a VC to the next-hop
destination exists. If a pt-pt VC does not exist, then the IPv6/NBMA
driver will queue the data packet and initiate a setup of a VC to the
destination. When the VC is created, or if one already exists, then
the node will encapsulate the outgoing data packet and send it on the
VC.
Note that Redirects are unidirectional. The redirected host will
create a VC to the next-hop destination as specified in the Redirect
message, but the next-hop will not be redirected to the source host.
Because no Neighbor Discovery takes place, the next-hop destination
has no way of determining the identity of the caller when it receives
the new VC. Also, since ND does not take place on redirects, the
next-hop receives no event that would cause it to update it's
neighbor or destination caches. However, it will continue to
transmit data back to the redirected host on the former path to the
redirected host. The next-hop node should be able to use the new VC
from the redirected destination if it too receives a redirect
redirecting it to the redirected node. This behavior is consistent
with [7].
A.2 Address Configuration
IPv6 addresses are auto-configured using the stateless or stateful
address auto-configuration mechanisms, as described in [9] and [18].
The IPv6 auto-configuration process involves creating and verifying
the uniqueness of a link-local address on an LL, determining whether
to use stateless and/or stateful configurationmechanisms to obtain
addresses, and determining if other (non- address) information is to
be autoconfigured. IPv6 addresses can also be manually configured, if
for example, auto-configuration fails because the autoconfigured
link-local address is not unique. An LL administrator specifies the
type of autoconfiguration to use; the hosts on an LL receive this
autoconfiguration information through Router Advertisement messages.
The following sections describe how stateless, stateful and manual
address configuration will work in an IPv6/NBMA environment.
A.2.1 Stateless Address Configuration
IPv6 stateless address configuration is the process by which an IPv6
host autoconfigures its interfaces, as described in [IPV6-ADDRCONF].
When an IPv6 host first starts up, it generates a link-local address
for the interface attached to the Logical Link. It then verifies the
uniqueness of the link-local address using Duplicate Address
Detection (DAD). If the IPv6 host detects that the link-local
address is not unique, the autoconfiguration process terminates. The
IPv6 host must then be manually configured.
After the IPv6 host determines that the link-local address is unique
and has assigned it to the interface on the Logical Link, the IPv6
host will perform Router Discovery to obtain auto-configuration
information. The IPv6 host will send out a Router Solicitation and
will receive a Router Advertisement, or it will wait for an
unsolicited Router Advertisement. The IPv6 host will process the M
and O bits of the Router Advertisement, as described in [9] and as a
result may invoke stateful address auto- configuration.
If there are no routers on the Logical Link, the IPv6 host will be
able to communicate with other IPv6 hosts on the Logical Link using
link-local addresses. The IPv6 host will obtain a neighbor's link-
layer address using Address Resolution. The IPv6 host will also
attempt to invoke stateful auto-configuration, unless it has been
explicitly configured not to do so.
A.2.2 Stateful Address Configuration (DHCP)
IPv6 hosts use the Dynamic Host Configuration Protocol (DHCPv6) to
perform stateful address auto-configuration, as described in [18].
A DHCPv6 server or relay agent is present on a Logical Link that has
been configured with manual or stateful auto-configuration. The
DHCPv6 server or relay agent will join the IPv6 DHCPv6 Server/Relay-
Agent multicast group on the Logical Link. When the node's IPv6/NBMA
driver gets the JoinLocalGroup request from the IPv6 network layer,
it follows the process described in section 4.2.
An IPv6 host will invoke stateful auto-configuration if M and O bits
of Router Advertisements indicate it should do so, and may invoke
stateful auto-configuration if it detects that no routers are present
on the Logical Link. An IPv6 host that is obtaining configuration
information through the stateful mechanism will hereafter be referred
to as a DHCPv6 client.
A DHCPv6 client will send a DHCPv6 Solicit message to the DHCPv6
Server/Relay-Agent multicast address to locate a DHCPv6 Agent. When
the soliciting node's IPv6/NBMA driver gets the request from the IPv6
Network Layer to send the packet, it follows the steps described in
section 4.4.2. This will result in one or more nodes on the LL
receiving the message. Each node that receives the solicitation
packet will process it as described in section section 4.5. Only the
IPv6 network layer of the DHCPv6 server/relay-agent will accept the
packet and process it.
A DHCPv6 Server or Relay Agent on the Logical Link will unicast a
DHCPv6 Advertisement to the DHCPv6 client. The IPv6 network layer
will give the node's IPv6/NBMA driver the packet and link-layer
address of the DHCPv6 client (obtained through Neighbor Discovery if
necessary). The node IPv6/NBMA driver will then transmit the packet
as described in section 4.4.1. This will result in a new pt-pt VC
being created between the server and the client if one did not
previously exist.
The DHCP client's IPv6/NBMA driver will receive the encapsulated
packet from the DHCP Server or Relay Agent, as described in section
4.5. The node will de-encapsulate the multicast packet and then pass
it up to the IPv6 Network Layer for processing. The IPv6 network
layer will deliver the DHCPv6 Advertise message to the DHCPv6 client.
Other DHCPv6 messages (Request, Reply, Release and Reconfigure) are
unicast between the DHCPv6 client and the DHCPv6 Server. Depending
on the reachability of the DHCPv6 client's address, messages
exchanged between a DHCPv6 client and a DHCPv6 Server on another LL
are sent either via a router or DHCPv6 Relay-Agent. Prior to sending
the DHCPv6 message, the IPv6 network layer will perform Neighbor
Discovery (if necessary) to obtain the link-layer address
corresponding to the packet's next-hop. A pt-pt VC will be set up
between the sender and the next hop, and the encapsulated packet
transmitted over it, as described in 4.4. Sending Data.
A.2.3 Manual Address Configuration
An IPv6 host will be manually configured if it discovers through DAD
that its link-local address is not unique. Once the IPv6 host is
configured with a unique interface token, the auto-configuration
mechanisms can then be invoked.
A.3 Internet Group Management Protocol (IGMP)
IPv6 multicast routers will use the IGMPv6 protocol to periodically
determine group memberships of local hosts. In the framework
described here, the IGMPv6 protocols can be used without any special
modifications for NBMA. While these protocols might not be the most
efficient in this environment, they will still work as described
below. However, IPv6 multicast routers connected to an NBMA LL could
optionally optimize the IGMP functions by sending
MARS_GROUPLIST_REQUEST messages to the MARS serving the LL and
determining group memberships by the MARS_GROUPLIST_REPLY messages.
Querying the MARS for multicast group membership is an optional
enchancement and is not required for routers to determine IPv6
multicast group membership on a LL.
There are three ICMPv6 message types that carry multicast group
membership information: the Group Membership Query, Group Membership
Report and Group Membership Reduction messages. IGMPv6 will continue
to work unmodified over the IPv6/NBMA architecture described in this
document.
An IPv6 multicast router receives all IPv6 multicast packets on the
LL by joining all multicast groups in promiscuous mode [5]. The MARS
server will then cause the multicast router to be added to all
existing and future multicast VCs. The IPv6 multicast router will
thereafter be the recipient of all IPv6 multicast packets sent within
the Logical Link.
An IPv6 multicast router discovers which multicast groups have
members in the Logical Link by periodically sending Group Membership
Query messages to the IPv6 all-nodes multicast address. When the
local node's IPv6/NBMA driver gets the request from the IPv6 network
layer to send the Group Membership Query packet, it follows the steps
described in 4.4.2. The node determines that the destination address
of the packet is the all-nodes multicast address and passes the
packet to the node's MARS client where the packet is encapsulated and
directly transmitted to the MARS. The MARS then relays the packet to
all nodes in the LL. Each node's IPv6/NBMA drivers will receive the
packet, de-encapsulate it, and passed it up to the IPv6 Network
layer. If the originating node receives the encapsulated packet, the
packet will be filtered out by the MARS client since the Cluster
Member ID of the receiving node will match the CMI in the packet's
MARS encapsulation header.
IPv6 hosts in the Logical Link will respond to a Group Membership
Query with a Group Membership Report for each IPv6 multicast group
joined by the host. IPv6 hosts can also transmit a Group Membership
Report when the host joins a new IPv6 multicast group. The Group
Membership Report is sent to the multicast group whose address is
being reported. When the local node IPv6/NBMA driver gets the request
from the IPv6 network layer to send the packet, it follows the steps
described in 4.4.2. The node determines that the packet is being
sent to a multicast address so forwards it to the node's MARS client
for sending on the appropriate VC.
The Group Membership Report packets will arrive at every node which
is a member of the group being reported through one of the VC
attached to each node's MARS client. The MARS client will de-
encapsulate the incoming packet and the packet will be passed to the
IPv6 network layer for processing. The MARS client of the sending
node will filter out the packet when it receives it.
An IPv6 host sends a Group Membership Reduction message when the host
leaves an IPv6 multicast group. The Group Membership Reduction is
sent to the multicast group the IPv6 host is leaving. The
transmission and receipt of Group Membership Reduction messages are
handled in the same manner as Group Membership Reports.
Appendix B. Alternative models of MARS support for Intra-LL ND
B.1 Simplistic approach - Use MARS 'as is'.
The IPv6/NBMA driver utilizes the standard MARS protocol to establish
a VC forwarding path out of the interface on which it can transmit
all multicast IPv6 packets, including ICMPv6 packets. The IPv6
packets are then transmitted, and received by the intended
destination set, using separate pt-mpt VCs per destination group.
In this approach all the protocol elements in [5] are used 'as is'.
However, SVC resource consumption must be taken into consideration.
Unfortunately, ND assumes that link level multicast resources are
best conserved by generating a sparsely distributed set of Solicited
Node multicast addresses (to which discovery queries are initially
sent). The original goal was to minimize the number of innocent
nodes that simultaneously received discovery messages really intended
for someone else.
However, in connection oriented NBMA environments it becomes equally
(or more) important to minimize the number of independent VCs that a
given NBMA interface is required to originate or terminate. If we
treat the MARS service as a 'black box' the sparse Solicited Node
address space can lead to a large number of short-use, but longer
lived, pt-mpt VCs (generated whenever the node is transmitting
Neighbor Solicitations). Even more annoying, these VCs are only
useful for additional packets being sent to their associated
Solicited Node multicast address. A new pt-pt VC is required to
actually carry the unicast IPv6 traffic that prompted the Neighbor
Solicitation.
The axis of inefficiency brought about by the sparse Solicited Nodes
address space is orthogonal to the VC mesh vs Multicast Server
tradeoff. Typically a multicast server aggregates traffic flow to a
common multicast group onto a single VC. To reduce the VC consumption
for ND, we need to aggregate across the Solicited Node address space
- performing aggregation on the basis of a packet's function rather
than its explicit IPv6 destination. The trade-off here is that the
aggregation removes the original value of scattering nodes sparsely
across the Solicited Nodes space. This is a price of the mismatch
between ND and connection oriented networks.
B.2 MARS as a Link (Multicast) Server.
One possible aggregation mechanism is for every node's IPv6/NBMA
driver to trap multicast ICMPv6 packets carrying multicast ND or RD
messages, and logically remap their destinations to the All Nodes
group (link local scope). By ensuring that the All Nodes group is
supported by an MCS, the resultant VC load within the LL will be
significantly reduced.
A further optimization is for every node's IPv6/NBMA driver to trap
multicast ICMPv6 packets carrying multicast ND or RD messages, and
send them to the MARS itself for retransmission on ClusterControlVC
(involving a trivial extension to the MARS itself.) This approach
recognizes that in any LL where IPv6 multicasting is supported:
- Nodes already have a pt-pt VC to their MARS.
- The MARS has a pt-mpt VC (ClusterControlVC) out to all Cluster
members (LL members registered for multicast support).
Because the VCs between a MARS and its MARS clients carry LLC/SNAP
encapsulated packets, ICMP packets can be multiplexed along with
normal MARS control messages. In essence the MARS behaves as a
multicast server for non-MARS packets that it receives from around
the LL.
As there is no requirement that a MARS client accepts only MARS
control messages on ClusterControlVC, ICMP packets received in this
fashion may be passed to every node's IP layer without further
comment. Within the IP layer, filtering will occur based on the
packet's actual destination IP address, and only the targeted node
will end up responding.
Regrettably this approach does result in the entire Cluster's
membership having to receive a variety of ICMPv6 messages that they
will always throw away.
Appendix C. Flow detection
The relationship between IPv6 packet flows, Quality of Service
guarantees, and optimal use of underlying IP and NBMA network
resources are still subjects of ongoing research in the IETF
(specifically the ISSLL, RSVP, IPNG, and ION working groups). This
document currently only describes the use of flow detection as a
means to optimize the use of NBMA network resources through the
establishment of inter-LL shortcuts.
C.1. The use of non-zero FlowID to suppress flow detection
For the purposes of this IPv6/NBMA architecture, a flow is:
A related sequence of IPv6 packets that the first hop router is
allowed to perform flow-detection on for the purposes of
triggering shortcut discovery.
How these packets are considered to be related to each other (e.g.
through common header fields such as IPv6 destination addresses) is a
local configuration issue.
The flow-detection rule specifies that only packets with a zero
FlowID can be considered as flows for which shortcut discovery may be
triggered. The rationale behind this decision is:
NBMA shortcuts are for the benefit of 'the network' optimizing its
forwarding of IPv6 packets in the absence of any other guidance
from the host.
It is desirable for an IPv6/NBMA host to have some mechanism for
overriding attempts by 'the network' to optimize its internal
forwarding path.
A zero FlowID has IPv6 semantics of "the source allows the network
to utilize its own discretion in providing best-effort forwarding
service for packets with zero FlowID"
The IPv6 semantics of zero FlowID are consistent with the flow-
detection rule in this document of "if the FlowID is zero, we are
free to optimize the forwarding path using shortcuts"
A non-zero FlowID has IPv6 semantics of "the source has previously
established some preferred, end to end hop by hop forwarding
behaviour for packets with this FlowID"
The IPv6 semantics of non-zero FlowID are consistent with the
flow-detection rule in this document of "if the FlowID is non-
zero, do not attempt to impose a shortcut".
A non-zero FlowID might be assigned by the source host after
negotiating a preferred forwarding mechanism with 'the network' (e.g.
through dynamic means such as RSVP, or administrative means).
Alternatively it can simply be assigned randomly by the source host,
and the network will provide default best effort forwarding (an IPv6
router defaults to providing best-effort forwarding for packets whose
FlowID/source-address pair is not recognized).
Thus, the modes of operation supported by this document becomes:
Zero FlowID
Best effort forwarding, with optional shortcut discovery
triggered through flow-detection.
Non-zero FlowID
Best effort forwarding if the routers along the path have not
been otherwise configured with alternative processing rules for
this FlowID/source-address pair. Flow detection relating to
shortcut discovery is suspended.
If the routers along the path have been configured with
particular processing rules for this FlowID/source-address pair,
the flow is handled according to those rules. Flow detection
relating to shortcut discovery is suspended.
Mechanisms for establishing particular per-hop processing rules for
packets with non-zero FlowID are neither constrained by, nor implied
by, this document.
C.2. Future directions for Flow Detection
In the future, accurate mapping of IPv6 flows onto NBMA VCs may
require more information to be exchanged during the Neighbor
Discovery process than is currently available in Neighbor Discovery
packets. In these cases, the IPv6 Neighbor Discover protocols can be
extended to include new TLV options (see section 4.6 of RFC1970
[7]). However, if new options are required, the specification of
these options must be co-ordinated with the IPNG working group.
Since RFC1970 specifies that nodes must silently ignore options they
do not understand, new options can be added at any time without
breaking backward compatibility with existing implementations.
NHRP also provides mechanisms for adding optional TLVs to NHRP
Requests and NHRP Replies. Future developments of this document's
architecture will require consistent QoS extensions to both ND and
NHRP in order to ensure they are semantically equivalent (syntactic
differences are undesirable, but can be tolerated).
Support for QoS on IPv6 unicast flows will not require further
extensions to the existing MARS protocol. However, future support for
QoS on IPv6 multicast flows may require extensions. MARS control
messages share the same TLV extension mechanism as NHRP, allowing QoS
extensions to be developed as needed.
Appendix D. Shortcut Limit Option
For NS messages sent as a shortcut trigger, a new type of ND option
is needed to pass on the information about the data flow hop limit
from the host to the router. The use of this ND option is defined in
section 3.2.2 of this specification. Its binary representation
follows the rules of section 4.6 of RFC1970:
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 | Shortcut Limit| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type 6
Length 1
Shortcut Limit 8-bit unsigned integer. Hop limit for shortcut
attempt.
Reserved1 This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Reserved2 This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Description
The shortcut limit option is used by a host in a Neighbor
Solicitation message sent as a shortcut trigger to a default
router. It restricts the router's shortcut query to targets
reachable via the specified number of hops. The shortcut limit is
given relative to the host requesting the shortcut. NS messages
with shortcut limit values of 0 or 1 MUST be silently ignored.
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 assigns.
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.