As per Relevance of the word multicast, we have this rfc below:
Network Working Group G.
Request for Comments: 2491 Lucent
Category: Standards Track P.
Bright Tiger
M.
Digital Equipment
G.
January 1999
IPv6 over Non-Broadcast Multiple Access (NBMA)
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document describes a general architecture for IPv6 over
networks. It forms the basis for subsidiary companion documents
describe details for various specific NBMA technologies (such as
or Frame Relay). The IPv6 over NBMA architecture allows
host-side operation of the IPv6 Neighbor Discovery protocol,
also supporting the establishment of 'shortcut' NBMA forwarding
when dynamically signaled NBMA links are available. Operations
administratively configured Point to Point NBMA links are
described
Dynamic NBMA shortcuts are achieved through the use of IPv6
Discovery protocol operation within Logical Links, and inter-
NHRP for the discovery of off-Link NBMA destinations. Both flow
triggered and explicitly source-triggered shortcuts are supported
1. Introduction
Non Broadcast Multiple Access (NBMA) networks may be utilized in
variety of ways. At one extreme, they can be used to simply
administratively configurable point to point service, sufficient
interconnect IPv6 routers (and even IPv6 hosts, in
Armitage, et. al. Standards Track [Page 1]
RFC 2491 IPv6 over NBMA networks January 1999
situations). At the other extreme, NBMA networks that support
establishment and teardown of Virtual Circuits (or
equivalents) may be used to emulate the service provided to the IPv
layer by conventional broadcast media such as Ethernet.
this emulation requires complex convergence protocols,
to support IPv6 multicast
This document describes a general architecture for IPv6 over
networks. It forms the basis for companion documents that
details specific to various NBMA technologies (for example, ATM [17]
or Frame Relay). The IPv6 over NBMA architecture allows
host-side operation of the IPv6 Neighbor Discovery protocol,
also supporting the establishment of 'shortcut' NBMA forwarding
(when dynamically signaled NBMA links are available).
The majority of this document focuses on the use of
managed point to point and point to multipoint calls
interfaces on an NBMA network. These will be generically referred
as "SVCs" in the rest of the document. The use of
configured point to point calls will also be discussed. Such
will be generically referred to as "PVCs". Depending on context
either may be shortened to "VC".
Certain NBMA networks may provide a form of connectionless
(e.g. SMDS). In these cases, a "call" or "VC" shall be considered
implicitly exist if the sender has an NBMA destination address
which it can transmit packets whenever it desires
1.1 Neighbor Discovery
A key difference between this architecture and previous IP over
protocols is its mechanism for supporting IPv6 Neighbor Discovery
The IPv4 world evolved an approach to address resolution
depended on the operation of an auxiliary protocol operating at
'link layer' - starting with Ethernet ARP (RFC 826 [14]). In
world of NBMA (Non Broadcast, Multiple Access) networks ARP has
applied to IPv4 over SMDS (RFC 1209 [13]) and IPv4 over ATM (RFC 1577
[3]). More recently the ION working group has developed NHRP (
Hop Resolution Protocol [8]), a general protocol for
intra-subnet and inter-subnet address resolution applicable to
range of NBMA network technologies
IPv6 developers opted to migrate away from a link layer
approach, chosing to combine a number of tasks into a protocol
as Neighbor Discovery [7], intended to be non-specific across
number of link layer technologies. A key assumption made by
Discovery's actual protocol is that the link technology underlying
Armitage, et. al. Standards Track [Page 2]
RFC 2491 IPv6 over NBMA networks January 1999
given IP interface is capable of native multicasting. This is
particularly true of most NBMA network services, and usually
convergence protocols to emulate the desired service. (The
protocol, RFC 2022 [5], is an example of such a
protocol.) This document augments and optimizes the MARS protocol
use in support of IPv6 Neighbor Discovery, generalizing
applicability of RFC 2022 beyond ATM networks
1.2 NBMA Shortcuts
A shortcut is an NBMA level call (VC) directly connecting two
endpoints that are logically separated by one or more routers at
IP level. IPv6 packets traversing this VC are said to 'shortcut'
routers that are in the logical IPv6 path between the VC's endpoints
NBMA shortcuts are a mechanism for minimizing the consumption
resources within an IP over NBMA cloud (e.g. router hops and
VCs).
It is important that NBMA shortcuts are supported whenever IP
deployed across NBMA networks capable of supporting
establishment of calls (SVCs or functional equivalent). For IPv
over NBMA, shortcut discovery and management is achieved through
mixture of Neighbor Discovery and NHRP
1.3 Key components of the IPv6 over NBMA architecture
1.3.1 NBMA networks providing PVC support
When the NBMA network is used in PVC mode, each PVC will
exactly two nodes and the use of Neighbor Discovery and other IPv
features is limited. IPv6/NBMA interfaces have only one neighbor
each Link. The MARS and NHRP protocols are NOT necessary,
multicast and broadcast operations collapse down to an NBMA
unicast operation. Dynamically discovered shortcuts are
supported
The actual details of encapsulations and link token generation
be covered by companion documents covering specific NBMA technology
They SHALL conform to the following guidelines
Both unicast and multicast IPv6 packets SHALL be transmitted
PVC links using the encapsulation described in section 4.4.1.
Interface tokens for PVC links SHALL be constructed as
in section 5. Interface tokens need only be unique between the
nodes on the PVC link
Armitage, et. al. Standards Track [Page 3]
RFC 2491 IPv6 over NBMA networks January 1999
This use of PVC links does not mandate, nor does it prohibit
use of extensions to the Neighbor Discovery protocol which may
developed for either general use of for use in PVC
(for example, Inverse Neighbor Discovery).
NBMA-specific companion documents MAY additionally specify
concatenation of IPv6 over PPP and PPP over NBMA mechanisms as
OPTIONAL approach to point to point IPv6.
Except where noted above, the remainder of this document focuses
the SVC case
1.3.2 NBMA networks providing SVC support
When the NBMA network is used in SVC mode, the key components are
- The IPv6 Neighbor model, where neighbors are discovered
the use of messages multicast to members of an IPv6 interface'
local IPv6 Link
- The MARS model, allowing emulation of general multicast
multipoint calls provided by the underlying NBMA network
- The NHRP service for seeking out the NBMA identities of
interfaces who are logically distant in an IP topological sense
- The modeling of IP traffic as 'flows', and optionally using
existence of a flow as the basis for attempting to set up
shortcut link level connection
In summary
The IPv6 "Link" is generalized to "Logical Link" (LL) in
environments (analogous to the generalization of IPv4 IP Subnet
Logical IP Subnet in RFC 1209 and subsequently RFC 1577).
IPv6/NBMA interfaces utilize RFC 2022 (MARS) for general intra
Logical Link multicasting. The MARS itself is used to
distribute discovery messages within the Logical Link
For destinations not currently considered to be Neighbors, a
sends the packets to one of its default routers
When appropriately configured, the egress router from a
Link is responsible for detecting the existence of an IP
flow through it that might benefit from a shortcut connection
While continuing to conventionally forward the flow's packets
the router initiates an NHRP query for the flow's
IP address
Armitage, et. al. Standards Track [Page 4]
RFC 2491 IPv6 over NBMA networks January 1999
The last router/NHS before the target of the NHRP
ascertains the target interface's preferred NBMA address
The originally querying router then issues a Redirect to the
source, identifying the flow's destination as a
Neighbor
Host-initiated triggering of shortcut discovery, regardless of
existence of a packet flow, is also supported through
Neighbor Solicitations sent to a source host's default router
A number of key advantages are claimed for this approach. These are
The IPv6 stacks on hosts do not implement separate ND
for each link layer technology
When the destination of a flow is solicited as a
neighbor, the returned NBMA address will be the one chosen by
destination when the flow was originally established through hop
by-hop processing. This supports the existing ND ability for IPv
destinations to perform their own dynamic interface load sharing
1.4 Terminology
The bit-pattern or numeric value used to identify a particular
interface at the NBMA level will be referred to as an "NBMA address".
(An example would be an ATM End System Address, AESA, when
this architecture to ATM networks, or an E.164 number when
this architecture to SMDS networks.)
The call that, once established, is used to transfer IP packets
one NBMA interface to another will be referred to as an SVC or
depending on whether the call is dynamically established through
signaling mechanism, or administratively established. The
signaling mechanisms used to establish or tear down an SVC will
defined in the NBMA-specific companion specifications. Certain
networks may provide a form of connectionless service (e.g. SMDS).
these cases, a "call" or "SVC" shall be considered to
exist if the sender has an NBMA destination address to which it
transmit packets whenever it desires
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [16].
Armitage, et. al. Standards Track [Page 5]
RFC 2491 IPv6 over NBMA networks January 1999
1.5 Document Structure
The remainder of this document is structured as follows: Section 2
explains the generalization of IPv6 Link to "Logical Link" when
over NBMA networks, and introduces the notion of the
Neighbor. Section 3 describes the modifications to the MARS
for efficient distribution of ND messages within a Logical Link,
the rules and mechanisms for discovering Transient Neighbors
Section 4 covers the basic rules governing IPv6/NBMA
initialization, packet and control message encapsulations, and
for SVC management. Section 5 describes the general rules
constructing Interface Tokens, the Link Layer Address Option,
Link Local addresses. Section 6 concludes the normative sections
the document. Appendix A provides some non-normative
text regarding the operation of Ipv6 Neighbor Discovery. Appendix
describes some sub-optimal solutions for emulating the
of Neighbor Discovery messages around a Logical Link. Appendix
discusses shortcut suppression and briefly reviews the
relationships between flow detection and mapping of flows onto
of differing qualities of service
2. Logical Links, and Transient Neighbors
IPv6 contains a concept of on-link and off-link. Neighbors are
nodes that are considered on-link and whose link-layer addresses
therefore be located using Neighbor Discovery. Borrowing from
terminology definitions in the ND text
on-link - an address that is assigned to a neighbor's interface
a shared link. A host considers an address to be on
link if
- it is covered by one of the link's prefixes,
- a neighboring router specifies the address as
target of a Redirect message,
- a Neighbor Advertisement message is received for
target address,
- a Neighbor Discovery message is received from
address
off-link - the opposite of "on-link"; an address that is
assigned to any interfaces attached to a shared link
Off-link nodes are considered to only be accessible through one
the routers directly attached to the link
Armitage, et. al. Standards Track [Page 6]
RFC 2491 IPv6 over NBMA networks January 1999
The NBMA environment complicates the sense of the word 'link' in
the same way as it complicated the sense of 'subnet' in the IPv
case. For IPv4 this required the definition of the Logical IP
(LIS) - an administratively constructed set of hosts that would
the same routing prefixes (network and subnetwork masks).
This document considers the IPv6 analog to be a Logical Link (LL).
An LL consists of nodes administratively configured to be '
link' with respect to each other
The members of an LL are an IPv6 interface's initial set
neighbors, and each interface's Link Local address only needs
be unique amongst this set
It should be noted that whilst members of an LL are IPv6 Neighbors
it is possible for Neighbors to exist that are not, administratively
members of the same LL
Neighbor Discovery events can result in the expansion of an IPv
interface's set of Neighbors. However, this does not change the
of interfaces that make up its LL. This leads to three
relationships between any two IPv6 interfaces
- On LL, Neighbor
- Off LL, Neighbor
- Off LL, not Neighbor
Off LL Neighbors represent the 'shortcut' connections, where it
been ascertained that direct connectivity at the NBMA level
possible to a target that is not a member of the source's LL
Neighbors discovered through the operation of unsolicited messages
such as Redirects, are termed 'Transient Neighbors'.
3. Intra-LL and Inter-LL Discovery
This document makes a distinction between the discovery of
within a Logical Link (intra-LL) and neighbors beyond the LL (inter
LL). The goal is to allow both inter- and intra-LL neighbor
to involve no changes to the host-side IPv6 stack for
interfaces
Note that section 1.3.1 applies when the NBMA network is being
to provide only configured point to point (PVC) service
Armitage, et. al. Standards Track [Page 7]
RFC 2491 IPv6 over NBMA networks January 1999
3.1 Intra-LL - ND over emulated multicast
The basic model of ND assumes that a link layer interface will
something meaningful with an ICMPv6 packet sent to a multicast
destination address. (IPv6 assumes that multicasting is an
part of the Internet service.) This document assumes
support will be provided using the RFC 2022 (MARS) [5]
(generalized for use over other NBMA technologies in addition
ATM). An IPv6 LL maps directly onto an IPv6 MARS Cluster in the
way an IPv4 LIS maps directly onto an IPv4 MARS Cluster
The goal of intra-LL operation is that the IPv6 layer must be able
simply pass multicast ICMPv6 packets down to the IPv6/NBMA
without any special, NBMA specific processing. The
mechanism for distributing Neighbor Discovery and Router
messages then works as expected
Sections 3.1.1 describes the additional functionality that SHALL
required of any MARS used in conformance with this document
Background discussion of these additions is provided in Appendix B
3.1.1 Mandatory augmented MARS and MARS Client behavior
IPv6/NBMA interfaces SHALL register as MARS Cluster members
described in section 4.1, and SHALL send certain classes of
IPv6 packets directly to their local MARS as described in
4.4.2.
The MARS itself SHALL then re-transmit these packets according to
following rules
- When the MARS receives an IPv6 packet, it scans the
membership database to find the NBMA addresses of the IPv
destination group's members
- The MARS then checks to see if every group member currently
its pt-pt control VC open to the MARS. If so, the MARS sends
copy of the data packet directly to each group member over
existing pt-pt VCs
- If one or more of the discovered group members do not have
open pt-pt VC to the MARS, or if there are no group
listed, the packet is sent out ClusterControlVC instead.
copies of the packet are sent over the existing (if any) pt-
VCs
Armitage, et. al. Standards Track [Page 8]
RFC 2491 IPv6 over NBMA networks January 1999
3.2 Inter-LL - Redirects, and their generation
Shortcut connections are justified on the grounds that
flows of IP packets may exist between source/destination pairs
are separated by IP routing boundaries. Shortcuts are created
Transient Neighbors
The key to creating transient neighbors is the Redirect
(section 8 [7]). IPv6 allows a router to inform the members of an
that there is a better 'first hop' to a given destination (
8.2 [7]). The advertisement itself is achieved through a
Redirect message, which may carry the link layer address of
better hop
A transmitting host only listens to Router Redirects from the
that is currently acting as the default router for the IP
that the Redirect refers to. If a Redirect arrives that indicates
better first hop for a given destination, and supplies a link
(NBMA) address to use as the better first hop, the
Neighbor Cache entry in the source host is updated and
reachability set to STALE. Updating the cache in this
involves building a new VC to the new NBMA address. If this
successful, the old VC is torn down only if it no longer
(since the old VC was to the router, it may still be required
other packets from the host that are heading to the router).
Two mechanisms are provided for triggering the discovery of a
first hop
Router-based flow identification/detection
Host-initiated shortcut request
Section 3.2.1 discusses flow-based triggers, section 3.2.2
the host initiated trigger, and section 3.2.3 discusses the use
NHRP to discover mappings for IPv6 targets in remote LLs
3.2.1 Flow Triggered Redirection
The modification of forwarding paths based on the dynamic
of IP packet flows is at the core of models such as the Cell
Router [11] and the IP Switch [12]. Responsibility for
flows is placed into the routers, where packets cross the edges of
routing boundaries
Armitage, et. al. Standards Track [Page 9]
RFC 2491 IPv6 over NBMA networks January 1999
For the purpose of conformance with this document, a router
choose to initiate the discovery of a better first-hop when
determines that an identifiable flow of IP packets are
through it
Such a router
SHALL only track flows that originate from a directly
host (a host that is within the LL-local scope of one of
router's interfaces).
SHALL NOT use IP packets arriving from another router
trigger the generation of a Router Redirect
SHALL only consider IPv6 packets with FlowID of zero for
purposes of flow detection as defined in this section
SHALL utilize NHRP as described in section 3.2.3 to ascertain
better first-hop when a suitable flow is detected,
advertise the information in a Router Redirect
IPv6 routers that support the OPTIONAL flow detection
described above SHALL support administrative mechanisms to switch
flow-detection. They MAY provide mechanisms for adding
constraints to the categories of IPv6 packets that constitute
'flow'.
The actual algorithm(s) for determining what sequence of IPv6
constitute a 'flow' are outside the scope of this document.
C discusses the rationale behind the use of non-zero FlowID
suppress flow detection
3.2.2 Host Triggered
A source host MAY also trigger a redirection to a transient neighbor
To support host-triggered redirects, routers conforming to
document SHALL recognize specific Neighbor Solicitation messages
by hosts as requests for the resolution of off-link addresses
To perform a host-triggered redirect, a source host SHALL
Create a Neighbor Solicitation message referring to the off-
destination (target) for which a shortcut is
Address the NS message to the router that would be the next
for traffic sent towards the off-LL target (rather than
target's solicited node multicast address).
Armitage, et. al. Standards Track [Page 10]
RFC 2491 IPv6 over NBMA networks January 1999
Use the standard ND hop limit of 255 to ensure the NS won't
discarded by the router
Include the shortcut limit option defined in appendix D. The
of this option should be equal to the hop limit of the data
for which this trigger is being sent. This ensures that the
is able to restrict the shortcut attempt to not exceed the
of the data flow
Forward the NS packet to the router that would be the next hop
traffic sent towards the off-LL target
Routers SHALL consider a unicast NS with shortcut limit option as
request for a host-triggered redirect. However, actual
discovery is OPTIONAL for IPv6 routers
When shortcut discovery is not supported, the router SHALL
a Redirect message identifying the router itself as the
'shortcut', and return it to the soliciting host
If shortcut discovery is to be supported, the router's response
be
A suitable NHRP Request is constructed and sent as described
section 3.2.3. The original NS message SHOULD be discarded
Once the NHRP Reply is received by the originating router,
router SHALL construct a Redirect message containing the IPv
address of the transient neighbor, and the NBMA link layer
returned by the NHRP resolution process
The resulting Redirect message SHALL then be transmitted back
the source host. When the Redirect message is received, the
host SHALL update its Neighbor and Destination caches
The off-LL target is now considered a Transient Neighbor.
next packet sent to the Transient Neighbor will result in
creation of the direct, shortcut VC (to the off-LL target itself
or to the best egress router towards that neighbor as
by NHRP).
If a NHRP NAK or error indication is received for a host-
shortcut attempt, the requesting router SHALL construct a
message identifying the router itself as the best 'shortcut',
return it to the soliciting host
Armitage, et. al. Standards Track [Page 11]
RFC 2491 IPv6 over NBMA networks January 1999
3.2.3 Use of NHRP between routers
Once flow detection has occurred, or a host trigger has
detected, routers SHALL use NHRP in an NHS to NHS mode to
the IPv6 to link level address mapping of a better first hop
IPv6/NBMA routers supporting shortcut discovery will need to
some or all of the following functions
- Construct NHRP Requests and Replies
- Parse incoming NHRP Requests and Replies from other
(routers).
- Forward NHRP Requests towards an NHS that is
closer to the IPv6 target
- Forward NHRP Replies towards an NHS that is topologically
to the requester
- Perform syntax translation between Neighbor Solicitations
outbound NHRP Requests
- Perform syntax translation between inbound NHRP Replies
Redirects
The destination of the flow that caused the trigger (or the target
the host initiated trigger) is used as the target for resolution in
NHRP Request. The router then forwards this NHRP Request to the
closest NHS. The process continues (as it would for normal NHRP
until the Request reaches an NHS that believes the IP target
within link-local scope of one of its interfaces. (This
potentially occur within a single router.)
As NHRP resolution requests always follow the routed path for a
target protocol address, the scope of a shortcut request will
automatically bounded to the scope of the IPv6 target address. (e.g
resolution requests for site-local addresses will not be
across site boundaries.)
The last hop router SHALL resolve the NHRP Request from
information contained in its neighbor cache for the interface
which the specified target is reachable. If there is no
entry in the Neighbor cache, or the destination is
considered unreachable, the last hop router SHALL perform
Discovery on the local interface, and build the NHRP Reply from
resulting answer. (Note, in the case where the NHRP
originated due to flow detection, there must already be a hop-by-
Armitage, et. al. Standards Track [Page 12]
RFC 2491 IPv6 over NBMA networks January 1999
flow of packets going through the last hop router towards the target
In this typical case the Neighbor cache will already have the
information.)
The NHRP Reply is propagated back to the source of the NHRP Request
using a hop-by-hop path as it would for normal NHRP
If the discovery process was triggered through flow detection at
originating router, the return of the NHRP Reply results in
following events
A Redirect is constructed using the IPv6/NBMA mapping carried
the NHRP Reply
The Redirect is unicast to the IP packet flow's source (using
VC on which the flow is arriving at the router, if it is a bi
directional pt-pt VC).
Any Redirect message sent by a router MUST conform to all
rules described in [7] so that the packet is properly validated
the receiving host. Specifically, if the target of the
short-cut is the destination host then the ICMP Target
MUST be the same as the ICMP Destination Address in the
message. If the target of the short-cut is an egress router
the ICMP Target Address MUST be a Link Local address of the
router that is unique to the NBMA cloud to which the router's
interface is attached
Also note that egress routers may subsequently redirect the
host. To do so, the Link Local ICMP Source Address of the
message MUST be the same as the Link Local ICMP Target Address
the original Redirect message
Note that the router constructing the NHRP Reply does so using
NBMA address returned by the target host when the target host
accepted the flow of IP traffic. This retains a useful feature
Neighbor Discovery - destination interface load sharing
Upon receipt of a NHRP NAK reply or error indication for a flow
triggered shortcut attempt, no indication is sent to the source
the flow
3.2.3.1 NHRP/ND packet translation rules
The following translation rules are meant to augment the
format specification in section 5 of the NHRP specification [8],
covering those packet fields specifically utilized by the IPv6/
architecture
Armitage, et. al. Standards Track [Page 13]
RFC 2491 IPv6 over NBMA networks January 1999
NHRP messages are constructed and sent according to the rules in [8].
The value of the NBMA technology specific fields such as ar$afn
ar$pro.type, ar$pro.snap and link layer address format are defined
NBMA-specific companion documents. Source, destination or
protocol addresses in the common header or CIE of a NHRP message
always IPv6 addresses of length 16.
When constructing an host-triggered NHRP resolution request
response to a Neighbor Solicitation
The ar$hopcnt field MUST be smaller than the shortcut limit
specified in the shortcut limit option included in the
NS message. This ensures that hosts have control over the reach
their shortcut request. Note that the shortcut limit given in
option is relative to the requesting host, thus the requirement
ar$hopcnt being smaller than the given shortcut limit
The Flags field in the common header of the NHRP
request SHOULD have the Q and S bits set
The U bit SHOULD be set. NBMA and protocol source addresses
those of the router constructing the request
The target address from the NS message is used as the
destination protocol address. A CIE SHALL NOT be specified
When constructing a NHRP resolution request as a result of
detection, the choice of values is configuration dependent
A NHRP resolution reply is build according to the rules in [8].
For each CIE returned, the holding time is 10 minutes
The MTU may be 0 or a value specified in the NBMA-
companion document
A successful NHRP resolution reply for a host-triggered
attempt is translated into an IPv6 Redirect message as follows
IP Fields
Source
The link-local address assigned to the router's
from which this message is sent
Destination
IPv6 Source Address of the triggering
Hop
255
Armitage, et. al. Standards Track [Page 14]
RFC 2491 IPv6 over NBMA networks January 1999
ICMP Fields
Target
NHRP Client Protocol
Destination
Target of triggering NS (this is equivalent to the
Destination Protocol Address
Target link-layer
NHRP Client NBMA
All NHRP extensions currently defined in [8] have no effect
NHRP/ND translation and MAY be used in NHRP messages for IPv6.
3.2.3.2 NHRP Purge rules
Purges are generated by NHRP when changes are detected
invalidate a previously issued NHRP Reply (this may include
changes, or a target host going down or changing identity). Any IPv
shortcut previously established on the basis of newly
information SHOULD be torn down
Routers SHALL keep track of NHRP cache entries for which they
issued Neighbor Advertisements or Router Redirects. If a NHRP
is received that invalidates information previously issued to
host, the router SHALL issue a Router Redirect specifying the
itself as the new best next-hop for the affected IPv6 target
Routers SHALL keep track of Neighbor cache entries that
previously been used to generate an NHRP Reply. The expiry of
such Neighbor cache entry SHALL result in a NHRP Purge being
towards the router that originally requested the NHRP Reply
3.3. Neighbor Unreachability Detection
Neighbor Solicitations sent for the purposes of
Unreachability Detection (NUD) are unicast to the Neighbor
question, using the VC that is already open to that Neighbor.
suggests that as far as NUD is concerned, the Transient Neighbor
indistinguishable from an On-LL Neighbor
3.4. Duplicate Address Detection
Duplicate Address Detection is only required within the link-
scope, which in this case is the LL-local scope. Transient
are outside the scope of the LL. No particular interaction
required between the mechanism for establishing shortcuts and
mechanism for detection of duplicate link local addresses
Armitage, et. al. Standards Track [Page 15]
RFC 2491 IPv6 over NBMA networks January 1999
4 Node Operation Concepts
This section describes node operations for performing basic
(such as sending and receiving data) on a Logical Link.
application of these basic functions to the operation of the
IPv6 protocols such as Neighbor Discovery is described in Appendix A
The majority of this section applies only to NBMA networks when
to provide point to point and point to multipoint SVCs. Section 7
discusses the case where the NBMA network is being used to
only point to point PVCs
4.1.Connecting to a Logical Link
Before a node can send or receive IPv6 datagrams its
IPv6/NBMA interface(s) must first join a Logical Link
An IPv6/NBMA driver SHALL establish a pt-pt VC to the MARS
with its Logical Link, and register as a Cluster Member [5].
node's IPv6/NBMA interface will then be a member of the LL, have
Cluster Member ID (CMI) assigned, and can begin supporting IPv6
IPv6 ND operations
If the node is a host or router starting up it SHALL issue a
group MARS_JOIN for the following groups
- Its derived Solicited-node address(es) with link-local scope
- The All-nodes address with link-local scope
- Other configured multicast groups with at least link-
scope
If the node is a router it SHALL additionally issue
- A single group MARS_JOIN for the All-routers address
link-local scope
- A block MARS_JOIN for the range(s) of IPv6 multicast
(with greater than link-local scope) for which
reception is required
The encapsulation mechanism for, and key field values of,
control messages SHALL be defined in companion documents specific
particular NBMA network technologies
4.2 Joining a Multicast Group
This section describes the node's behavior when it gets
JoinLocalGroup request from the IPv6 Layer. The details of how
behavior is achieved are going to be implementation specific
Armitage, et. al. Standards Track [Page 16]
RFC 2491 IPv6 over NBMA networks January 1999
If a JoinLocalGroup for a node-local address is received,
IPv6/NBMA driver SHALL return success indication to the caller
take no additional action. (Packets sent to node-local
never reach the IPv6/NBMA driver.)
If a JoinLocalGroup is received for an address with greater
node-local scope, the IPv6/NBMA driver SHALL send an
single group MARS_JOIN request to register this address with
MARS
4.3. Leaving a Multicast Group
This section describes the node's behavior when it gets
LeaveLocalGroup request from the IPv6 Layer. The details of how
behavior is achieved are going to be implementation specific
If a LeaveLocalGroup for a node-local address is received,
IPv6/NBMA driver SHALL return success indication to the caller
take no additional action. (Packets sent to node-local
never reach the IPv6/NBMA driver.)
If a LeaveLocalGroup is received for an address with greater
node-local scope, the IPv6/NBMA driver SHALL send an
single group MARS_LEAVE request to deregister this address with
MARS
4.4. Sending Data
Separate processing and encapsulation rules apply for
unicast and multicast packets
4.4.1. Sending Unicast Data
The IP level 'next hop' for each outbound unicast IPv6 packet is
to identify a pt-pt VC on which to forward the packet
For NBMA networks where LLC/SNAP encapsulation is typically
(e.g. ATM or SMDS), the IPv6 packet SHALL be encapsulated with
following LLC/SNAP header and sent over the VC
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet
(LLC) (OUI) (PID
For NBMA networks that do not use LLC/SNAP encapsulation,
alternative rule SHALL be specified in the NBMA-specific
document
Armitage, et. al. Standards Track [Page 17]
RFC 2491 IPv6 over NBMA networks January 1999
If no pt-pt VC exists for the next hop address for the packet,
node SHALL place a call to set up a VC to the next hop destination
Any time the IPv6/NBMA driver receives a unicast packet
transmission the IPv6 layer will already have determined the link
layer (NBMA) address of the next hop. Thus, the information
to place the NBMA call to the next hop will be available
The sending node SHOULD queue the packet that triggered the
request, and send it when the call is established
If the call to the next hop destination node fails the sending
SHALL discard the packet that triggered the call setup.
failure to create a VC to the next hop destination will be
and handled at the IPv6 Network Layer through NUD
At this time no rules are specified for mapping outbound packets
VCs using anything more than the packet's destination address
4.4.2. Sending Multicast Data
The IP level 'next hop' for each outbound multicast IPv6 packet
used to identify a pt-pt or pt-mpt VC on which to forward the packet
For NBMA networks where LLC/SNAP encapsulation is typically
(e.g. ATM or SMDS), multicast packets SHALL be encapsulated in
following manner
[0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv
packet
(LLC) (OUI) (PID) (mars encaps
The IPv6/NBMA driver's Cluster Member ID SHALL be copied
the 2 octet pkt$cmi field prior to transmission
For NBMA networks that do not use LLC/SNAP encapsulation,
alternative rule SHALL be specified in the NBMA-specific
document. Some mechanism for carrying the IPv6/NBMA driver'
Cluster Member ID SHALL be provided
If the packet's destination is one of the following
addresses, it SHALL be sent over the IPv6/NBMA driver's direct pt-
VC to the MARS
- A Solicited-node address with link-local scope
- The All-nodes address with link-local scope
- The All-routers address with link-local scope
- A DHCP-v6 relay or server multicast address
Armitage, et. al. Standards Track [Page 18]
RFC 2491 IPv6 over NBMA networks January 1999
The MARS SHALL then redistribute the IPv6 packet as described
section 3.1.1. (If the VC to the MARS has been idle timed out
some reason, it MUST be re-established before forwarding the
to the MARS.)
If packet's destination is any other address, then the usual
client mechanisms are used by the IPv6/NBMA driver to select and/
establish a pt-mpt VC on which the packet is to be sent
At this time no rules are specified for mapping outbound packets
VCs using anything more than the packet's destination address
4.5. Receiving Data
Packets received using the encapsulation shown in section 4.4.1
be de-encapsulated and passed up to the IPv6 layer. The IPv6
then determines how the incoming packet is to be handled
Packets received using the encapsulation specified in section 4.4.2
SHALL have their pkt$cmi field compared to the local IPv6/
driver's own CMI. If the pkt$cmi in the header matches the local
the packet SHALL be silently dropped. Otherwise, the packet SHALL
de-encapsulated and passed to the IPv6 layer. The IPv6 layer
determines how the incoming packet is to be handled
For NBMA networks that do not use LLC/SNAP encapsulation,
rules SHALL be specified in the NBMA-specific companion document
The IPv6/NBMA driver SHALL NOT attempt to filter out multicast IPv
packets arriving with encapsulation defined for unicast packets,
attempt to filter out unicast IPv6 packets arriving
encapsulation defined for multicast packets
4.6. VC Setup and release for unicast data
Unicast VCs are maintained separately from multicast VCs. The
and maintenance of multicast VCs are handled by the MARS client
each IPv6/NBMA driver [5]. Only the setup and maintenance of pt-
VCs for unicast IPv6 traffic will be described here. Only
effort unicast VCs are considered. The creation of VCs for
classes of service is outside the scope of this document
Before sending a packet to a new destination within the same LL
node will first perform a Neighbor Discovery on the intra-LL target
This is done to resolve the IPv6 destination address into a link
layer address which the sender can then use to send unicast packets
Armitage, et. al. Standards Track [Page 19]
RFC 2491 IPv6 over NBMA networks January 1999
Appendix A.1.1 contains non-normative, descriptive text covering
Neighbor Solicitation/Advertisement exchange and
establishment of a new SVC
A Redirect message (either a redirect to a node on the same LL, or
shortcut redirect to a node outside the LL) results in the
(redirected) node creating a new pt-pt VC to a new receiving node
the Redirect message SHALL contain the link layer (NBMA) address
the new receiving IPv6/NBMA interface. The redirected node does
concern itself where the new receiving node is located on the
network. The redirected node will set up a pt-pt VC to the new
if one does not previously exist. The redirected node will then
the new VC to send data rather than whatever VC it had
been using
Redirects are unidirectional. Even after the source has reacted to
redirect, the destination will continue to send IPv6 packets back
the redirected node on the old path. This happens because
destination node has no way of determining the IPv6 address of
other end of a new VC in the absence of Neighbor Discovery. Thus
redirects will not result in both ends of a connection using the
VC. IPv6 redirects are not intended to provide
redirection. If the non-redirected node eventually receives
redirect it MAY discover the existing VC to the target node and
that rather than creating a new VC
It is desirable that VCs are released when no longer needed
An IPv6/NBMA driver SHALL release any VC that has been idle for 20
minutes
This time limit MAY be reduced through configuration or as
in companion documents for specific NBMA networks
If a Neighbor or Destination cache entry is purged then any
associated with the purged entry SHOULD be released
If the state of an entry in the Neighbor cache is set to STALE,
any VCs associated with the stale entry SHOULD be released
4.7 NBMA SVC Signaling Support and MTU issues
Mechanisms for signaling the establishment and teardown of pt-pt
pt-mpt SVCs for different NBMA networks SHALL be specified
companion documents
Armitage, et. al. Standards Track [Page 20]
RFC 2491 IPv6 over NBMA networks January 1999
Since any given IPv6/NBMA driver will not know if the remote end of
VC is in the same LL, drivers SHALL implement NBMA-
mechanisms to negotiate acceptable MTUs at the VC level.
mechanisms SHALL be specified in companion documents
However, IPv6/NBMA drivers can assume that they will always
talking to another driver attached to the same type of NBMA network
(For example, an IPv6/NBMA driver does not need to consider
possibility of establishing a shortcut VC directly to an IPv6/
driver.)
5. Interface Tokens, Link Layer Address Options, Link-Local
5.1 Interface
Each IPv6 interface must have an interface token from which to
IPv6 autoconfigured addresses. This interface token must be
within a Logical Link to prevent the creation of duplicate
when stateless address configuration is used
In cases where two nodes on the same LL produce the same
token then one interface MUST choose another host-token.
implementations MUST support manual configuration of interface
to allow operators to manually change a interface token on a per-
basis. Operators may choose to manually set interface tokens
reasons other than eliminating duplicate addresses
All interface tokens MUST be 64 bits in length and formatted
described in the following sections. The hosts tokens will be
on the format of an EUI-64 identifier [10]. Refer to [19 -
A] for a description of creating IPv6 EUI-64 based
identifiers
5.1.1 Single Logical Links on a Single NBMA
Physical NBMA interfaces will generally have some local
that may be used to generate a unique IPv6/NBMA interface token.
exact mechanism for generating interface tokens SHALL be specified
companion documents specific to each NBMA network
5.1.2 Multiple Logical Links on a Single NBMA
Physical NBMA interfaces MAY be used to provide multiple logical
interfaces. Since each logical NBMA interface MAY support
independent IPv6 interface, two separate scenarios are possible
- A single host with separate IPv6/NBMA interfaces onto a
of independent Logical Links
Armitage, et. al. Standards Track [Page 21]
RFC 2491 IPv6 over NBMA networks January 1999
- A set of 2 or more 'virtual hosts' (vhosts) sharing a
NBMA driver. Each vhost is free to establish IPv6/
interfaces associated with different or common LLs. However
vhosts are bound by the same requirement as normal hosts -
two interfaces to the same LL can share the same
token
In the first scenario, since each IPv6/NBMA interface is
with a different LL, each interface's external identity can
differentiated by the LL's routing prefix. Thus, the host can re-
a single unique interface token across all its IPv6/NBMA interfaces
(Internally the host will tag received packets in some
specific manner to identify what IPv6/NBMA interface they arrived on
However, this is an issue generic to IPv6, and does not
clarification in this document.)
The second scenario is more complex, but likely to be rarer
When supporting multiple logical NBMA interfaces over a
physical NBMA interface, independent and unique identifiers SHALL
generated for each virtual NBMA interface to enable the
of unique IPv6/NBMA interface tokens. The exact mechanism
generating interface tokens SHALL be specified in companion
specific to each NBMA network
5.2 Link Layer Address
Neighbor Discovery defines two option fields for carrying link-
specific source and target addresses
Between IPv6/NBMA interfaces, the format for these two options
adapted from the MARS [5] and NHRP [8] specs. It SHALL be
[Type][Length][NTL][STL][..NBMA Number..][..
Subaddress..]
| Fixed || Link layer
|
[Type] is a one octet field
1 for Source link-layer address
2 for Target link-layer address
[Length] is a one octet field
The total length of the option in multiples of 8 octets. Zeroed
are added to the end of the option to ensure its length is a
of 8 octets
Armitage, et. al. Standards Track [Page 22]
RFC 2491 IPv6 over NBMA networks January 1999
[NTL] is a one octet 'Number Type & Length' field
[STL] is a one octet 'SubAddress Type & Length' field
[NBMA Number] is a variable length field. It is always present.
contains the primary NBMA address
[NBMA Subaddress] is a variable length field. It may or may not
present. This contains any NBMA subaddress that may be required
If the [NBMA Subaddress] is not present, the option ends after
[NBMA Number] ( and any additional padding for 8 byte alignment).
The contents and interpretation of the [NTL], [STL], [NBMA Number],
and [NBMA Subaddress] fields are specific to each NBMA network,
SHALL be specified in companion documents
5.3 Link-Local
The IPv6 link-local address is formed by appending the
token, as defined above, to the prefix FE80::/64.
10 bits 54 bits 64
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Token |
+----------+-----------------------+----------------------------+
6. Conclusion and Open
This document describes a general architecture for IPv6 over
networks. It forms the basis for subsidiary companion documents
provide details for various specific NBMA technologies (such as
or Frame Relay). The IPv6 over NBMA architecture allows
host-side operation of the IPv6 Neighbor Discovery protocol,
also supporting the establishment of 'shortcut' NBMA forwarding
(when dynamically signaled NBMA links are available).
The IPv6 "Link" is generalized to "Logical Link" in an
manner to the IPv4 "Logical IP Subnet". The MARS protocol
augmented and used to provide relatively efficient intra Logical
multicasting of IPv6 packets, and distribution of Discovery messages
Shortcut NBMA level paths are supported either through router
flow detection, or host originated explicit requests.
Discovery is used without modification for all intra-LL
(including the initiation of NBMA shortcut discovery). Router
router NHRP is used to obtain the IPv6/NBMA address mappings
shortcut targets outside a source's Logical Link
Armitage, et. al. Standards Track [Page 23]
RFC 2491 IPv6 over NBMA networks January 1999
7. Security
This architecture introduces no new protocols, but depends
existing protocols (NHRP, IPv6, ND, MARS) and is therefore subject
all the security threats inherent in these protocols.
architecture should not be used in a domain where any of the
protocols are considered unacceptably insecure. However,
protocol itself does not introduce additional security threats
While this proposal does not introduce any new security
all current IPv6 security mechanisms will work without
for NBMA. This includes both authentication and encryption for
Neighbor Discovery protocols as well as the exchange of IPv6
packets. The MARS protocol is modified in a manner that does
affect or augment the security offered by RFC 2022.
Eric Nordmark confirmed the usefulness of ND Redirect messages
private email during the March 1996 IETF. The discussions
various ION WG members during the June and December 1996 IETF
solidify the architecture described here. Grenville Armitage'
original work on IPv6/NBMA occurred while employed at Bellcore
Elements of section 5 were borrowed from Matt Crawford's memo on IPv
over Ethernet
Armitage, et. al. Standards Track [Page 24]
RFC 2491 IPv6 over NBMA networks January 1999
Authors'
Grenville
Bell Laboratories, Lucent
101 Crawfords Corner
Holmdel, NJ 07733
EMail: gja@lucent.
Peter
Bright Tiger
125 Nagog
Acton, MA 01720
EMail: paschulter@acm.
Markus
European Applied Research
Digital Equipment
CEC
Vincenz-Priessnitz-Str. 1
D-76131
EMail: jork@kar.dec.
Geraldine
Digital UNIX
Compaq Computer
110 Spit Brook
Nashua, NH 03062
EMail: harter@zk3.dec.
Armitage, et. al. Standards Track [Page 25]
RFC 2491 IPv6 over NBMA networks January 1999
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[2] ATM Forum, "ATM User Network Interface (UNI)
Version 3.1", ISBN 0-13-393828-X, Prentice Hall,
Cliffs, NJ, June 1995.
[3] Crawford, M., "A Method for the Transmission of IPv6 Packets
Ethernet Networks", RFC 1972, August 1996.
[4] Heinanen, J., "Multiprotocol Encapsulation over ATM
Layer 5", RFC 1483, July 1993.
[5] Armitage, G., "Support for Multicast over UNI 3.1 based
Networks", RFC 2022, November 1996.
[6] Hinden, R. and S. Deering, "IP Version 6
Architecture", RFC 2373, July 1998.
[7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
IP Version 6 (IPv6)", RFC 2461, December 1998.
[8] Luciani, J., Katz, D., Piscitello, D. Cole B and N. Doraswamy
"NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[9] Thomson, S. and T. Narten, "IPv6 Stateless
Autoconfiguration", RFC 2462, 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
Architecture Extensions for ATM : Overview", RFC 2098,
1997.
[12] P. Newman, T. Lyon, G. Minshall, "Flow Labeled IP: ATM
IP", Proceedings of INFOCOM'96, San Francisco, March 1996,
pp.1251-1260
[13] Piscitello, D. and J. Lawrence, "The Transmission of
Datagrams over the SMDS Service", RFC 1209, March 1991.
[14] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet
for Transmission on Ethernet Hardware", STD 37, RFC 826,
November 1982.
Armitage, et. al. Standards Track [Page 26]
RFC 2491 IPv6 over NBMA networks January 1999
[15] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for
version 6", RFC 1981, August 1996.
[16] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[17] Armitage, G., Schulter, P. and M. Jork, "IPv6 over
Networks", RFC 2492, January 1999.
[18] C. Perkins, J. Bound, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", Work in Progress
[19] Hinden, R. and S. Deering, "IP Version 6
Architecture", RFC 2373, July 1998.
Armitage, et. al. Standards Track [Page 27]
RFC 2491 IPv6 over NBMA networks January 1999
Appendix A. IPv6 Protocol Operation
The IPv6 over NBMA model described in this document maintains
complete semantics of the IPv6 protocols. No changes need to be
to the IPv6 Network Layer. Since the concept of the
association is not being changed for NBMA, this framework
complete IPv6 security semantics and features. This allows IPv6
to choose their responses to solicitations based on
information as is done with other datalinks, thereby maintaining
semantics of Neighbor Discovery since it is always the solicited
that chooses what (and even if) to reply to the solicitation. Thus
NBMA will be transparent to the network layer except in cases
extra services (such as QoS VCs) are offered
The remainder of this Appendix describes how the core IPv6
will operate within the model described here
A.1 Neighbor Discovery
Before performing any sort of Neighbor discover operation, each
must first join the all-node multicast group, and it's solicited
multicast address (the use of this address in relation to DAD
described in A.1.4). The IPv6 network layer will join
multicast groups as described in 4.2.
A.1.1 Performing Address
An IPv6 host performs address resolution by sending a
Solicitation to the solicited-node multicast address of the
host, as described in [7]. The Neighbor Solicitation message
contain a Source Link-Layer Address Option set to the
node's NBMA address on the LL
When the local node's IPv6/NBMA driver is passed the
Solicitation message from the IPv6 network layer, it follows
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
the de-encapsulated packets to the IPv6 network layer
If the receiving node is the target of the Neighbor Solicitation
will update its Neighbor cache with the soliciting node's
address, contained in the Neighbor Solicitation message's
Link-Layer Address Option as described in [7].
Armitage, et. al. Standards Track [Page 28]
RFC 2491 IPv6 over NBMA networks January 1999
The solicited IPv6 host will respond to the Neighbor
with a Neighbor Advertisement message sent to the IPv6
address of the soliciting node. The Neighbor Advertisement
will contain a Target Link-Layer Address Option set to the
node's NBMA address on the LL
The solicited node's IPv6/NBMA driver will be passed the
Advertisement and the soliciting node's link-layer address from
IPv6 network layer. It will then follow the steps described
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
node if one did not already exist
The soliciting node will then receive the Neighbor
message over the new PtP VC, de-encapsulate the message, and pass
to the IPv6 Network layer for processing as described in section 4.5.
The soliciting node will then make the appropriate entries in it'
Neighbor cache, including caching the NBMA link-layer address of
solicited node as described in [7].
At this point each system has a complete Neighbor cache entry for
other system. They can exchange data over the pt-pt VC newly
by the solicited node when it returned the Neighbor Advertisement,
create a new VC
An IPv6 host can also send an Unsolicited Neighbor Advertisemnent
the all-nodes multicast address. When the local node IPv6/NBMA
is passed the Neighbor Advertisement from the IPv6 network layer,
follows the steps described in section 4.4.2 to send the NA
to the all-nodes multicast address. Each node will process
incoming packet as described in section 4.5 and then pass the
to the IPv6 network layer where it will be processed as described
[7].
A.1.2 Performing Router
Router Discovery is described in [7]. To support Router Discovery
IPv6 router will join the IPv6 all-routers multicast group address
When the IPv6/NBMA driver gets the JoinLocalGroup request from
IPv6 Network Layer, it follows the process described in section 4.2.
IPv6 routers periodically send unsolicited Router
announcing their availability on the LL. When an IPv6 router
an unsolicited Router Advertisement, it sends a data packet
to the IPv6 all-nodes multicast address. When the local
IPv6/NBMA driver gets the Router Advertisement message from the IPv
network layer, it transmits the message by following steps
in section 4.4.2. The MARS will transmit the packet on the LL'
Armitage, et. al. Standards Track [Page 29]
RFC 2491 IPv6 over NBMA networks January 1999
ClusterControlVC, which sends the packets to all nodes on the LL
Each node on the LL will then process the incoming packet
described in section 4.5 and pass the received packet to the IPv
Network layer for processing as appropriate
To perform Router Discovery, an IPv6 host sends a Router
message to the all-routers multicast address. When the local
IPv6/NBMA driver gets the request from the IPv6 Network Layer to
the packet, it follows the steps described in section 4.4.2. The
message will be sent to either those nodes which have joined
all-routers multicast group or to all nodes. The nodes which
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.
those nodes which are routers will process the message and respond
it
An IPv6 router responds to a Router Solicitation by sending a
Advertisement addressed to the IPv6 all-nodes multicast address
the source address of the Router Solicitation was the
address. If the source address in the Router Solicitation is not
unspecified address, the the router will unicast the
Advertisement to the soliciting node. If the router sends the
Advertisement to the all-nodes multicast address then it follows
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
Router Advertisement and link-layer address of the soliciting
(obtained through Address Resolution if necessary) which will
the packet according to the steps described in section 4.4.1
will result in a new pt-pt VC being created between the router
the soliciting node if one did not already exist
The soliciting node will receive and process the Router
as described in section 4.5 and will pass the RA message to the IPv
network layer. The IPv6 network layer may, depending on the state
the Neighbor cache entry, update the Neighbor cache with the router'
NBMA address, contained in the Router Advertisement message's
Link-Layer Address Option
If a pt-pt VC is set up during Router Discovery, subsequent IPv6
effort unicast data between the soliciting node and the router
be transmitted over the new PtP VC
Armitage, et. al. Standards Track [Page 30]
RFC 2491 IPv6 over NBMA networks January 1999
A.1.3 Performing Neighbor Unreachability Detection (NUD
Neighbor Unreachability Detection (NUD) is the process by which
IPv6 host determines that a neighbor is no longer reachable,
described in [7]. Each Neighbor cache entry contains information
by the NUD algorithm to detect reachability failures.
of a neighbor's reachability comes either from upper-layer
indications that data recently sent to the neighbor was received,
from the receipt of a Neighbor Advertisement message in response to
Neighbor Solicitation probe
Connectivity failures at the node's IPv6/NBMA driver, such
released VCs (see section 4.6) and the inability to create a VC to
neighbor (see section 4.4.1), are detected and handled at the IPv
network layer, through Neighbor Unreachability Detection. The node'
IPv6/NBMA driver does not attempt to detect or recover from
conditions
A persistent failure to create a VC from the IPv6 host to one of
IPv6 neighbors will be detected and handled through NUD. On
attempt to send data from the IPv6 host to its neighbor, the node'
IPv6/NBMA driver will attempt to set up a VC to the neighbor,
failing to do so, will drop the packet. IPv6
confirmation timers will eventually expire, and the neighbor'
Neighbor cache entry will enter the PROBE state. The PROBE state
cause the IPv6 host to unicast Neighbor Solicitations to
neighbor, which will be dropped by the local node's IPv6/NBMA
after again failing to setup the VC. The IPv6 host will
never receive the solicited Neighbor Advertisements needed
reachability confirmation, causing the neighbor's entry to be
from the Neighbor cache. The next time the IPv6 host tries to
data to that neighbor, address resolution will be performed
Depending on the reason for the previous failure, connectivity to
neighbor could be re-established (for example, if the previous
setup failure was caused by an obsolete link-layer address in
Neighbor cache).
In the event that a VC from an IPv6 neighbor is released, the
time a packet is sent from the IPv6 host to the neighbor, the node'
IPv6/NBMA driver will recognize that it no longer has a VC to
neighbor and attempt to setup a new VC to the neighbor. If, on
first and on subsequent transmissions, the node is unable to create
VC to the neighbor, NUD will detect and handle the failure
described earlier (handling the persistent failure to create a
from the IPv6 host to one of its IPv6 neighbors). Depending on
reason for the previous failure, connectivity to the neighbor may
may not be re-established
Armitage, et. al. Standards Track [Page 31]
RFC 2491 IPv6 over NBMA networks January 1999
A.1.4 Performing Duplicate Address Detection (DAD
An IPv6 host performs Duplicate Address Detection (DAD) to
that the address it wishes to use on the LL (i.e. a
address) is not already in use, as described in [9] and [7].
Duplicate Address Detection is performed on all addresses the
wishes to use, regardless of the configuration mechanism used
obtain the address
Prior to performing Duplicate Address Detection, a host will join
all-nodes multicast address and the solicited-node multicast
corresponding to the host's tentative address (see 4.2. Joining
Multicast Group). The IPv6 host initiates Duplicate Address
by sending a Neighbor Solicitation to solicited-node
address corresponding to the host's tentative address, with
tentative address as the target. When the local node's IPv6/
driver gets the Neighbor Solicitation message from the IPv6
layer, it follows the steps outlined in section 4.4.2. The
message will be sent to those nodes which joined the
solicited-node multicast group or to all nodes. The DAD NS
will be received by one or more nodes on the LL and processed by
as described in section 4.5. Note that the MARS client of
sending node will filter out the message so that the sending node'
IPv6 network layer will not see the message. The IPv6 network
of any node which is not a member of the target solicited-
multicast group will discard the Neighbor Solicitation message
If no other hosts have joined the solicited-node multicast
corresponding to the tentative address, then the host will
receive a Neighbor Advertisement containing its tentative address
the target. The host will perform the retransmission logic
in [9], terminate Duplicate Address Detection, and assign
tentative address to the NBMA interface
Otherwise, other hosts on the LL that have joined the solicited-
multicast address corresponding to the tentative address will
the Neighbor Solicitation. The processing will depend on whether
not receiving IPv6 host considers the target address to be tentative
If the receiving IPv6 host's address is not tentative, the host
respond with a Neighbor Advertisement containing the target address
Because the source of the Neighbor Solicitation is the
address, the host sends the Neighbor Advertisement to the all-
multicast address following the steps outlined in section 4.4.2.
DAD NA message will be received and processed by the MARS clients
all nodes in the LL as described in section 4.5. Note that
sending node will filter the incoming message since the CMI in
message header will match that of the receiving node. All
Armitage, et. al. Standards Track [Page 32]
RFC 2491 IPv6 over NBMA networks January 1999
nodes will de-encapsulate the message and pass it to the IPv6
layer. The host performing DAD will detect that its
address is the target of the Neighbor Advertisement, and
that the tentative address is not unique and cannot be assigned
its NBMA interface
If the receiving IPv6 host's address is tentative, then both
are performing DAD using the same tentative address. The
host will determine that the tentative address is not unique
cannot be assigned to its NBMA interface
A.1.5 Processing
An IPv6 router uses a Redirect Message to inform an IPv6 host of
better first-hop for reaching a particular destination, as
in [7]. This can be used to direct hosts to a better first
router, another host on the same LL, or to a transient neighbor
another LL. The IPv6 router will unicast the Redirect to the IPv
source address that triggered the Redirect. The router's IPv6/
driver will transmit the Redirect message using the
described in section 4.4.1. This will create a VC between the
and the redirected host if one did not previously exist
The IPv6/NBMA driver of the IPv6 host that triggered the
will receive the encapsulated Redirect over one of it's pt-pt VCs
It will the de-encapsulate the packet, and pass the Redirect
to the IPv6 Network Layer, as described section 4.5.
Subsequent data sent from the IPv6 host to the destination will
sent to the next-hop address specified in the Redirect Message.
NBMA networks, the Redirect Message should contain the link-
address option as described in [7] and section 5.2, thus
redirected node will not have to perform a Neighbor Solicitation
learn the link-layer address of the node to which it has
redirected. Thus, the redirect can be to any node on the
network, regardless of the LL membership of the new target node
This allows NBMA hosts to be redirected off their LL to
shortcut by using standard IPv6 protocols
Once redirected, the IPv6 network layer will give the node'
IPv6/NBMA driver the IPv6 packet and the link-layer address of
next-hop node when it sends data to the redirected destination.
node's IPv6/NBMA driver will determine if a VC to the next-
destination exists. If a pt-pt VC does not exist, then the IPv6/
driver will queue the data packet and initiate a setup of a VC to
destination. When the VC is created, or if one already exists,
the node will encapsulate the outgoing data packet and send it on
VC
Armitage, et. al. Standards Track [Page 33]
RFC 2491 IPv6 over NBMA networks January 1999
Note that Redirects are unidirectional. The redirected host
create a VC to the next-hop destination as specified in the
message, but the next-hop will not be redirected to the source host
Because no Neighbor Discovery takes place, the next-hop
has no way of determining the identity of the caller when it
the new VC. Also, since ND does not take place on redirects,
next-hop receives no event that would cause it to update it'
neighbor or destination caches. However, it will continue
transmit data back to the redirected host on the former path to
redirected host. The next-hop node should be able to use the new
from the redirected destination if it too receives a
redirecting it to the redirected node. This behavior is
with [7].
A.2 Address
IPv6 addresses are auto-configured using the stateless or
address auto-configuration mechanisms, as described in [9] and [18].
The IPv6 auto-configuration process involves creating and
the uniqueness of a link-local address on an LL, determining
to use stateless and/or stateful configurationmechanisms to
addresses, and determining if other (non- address) information is
be autoconfigured. IPv6 addresses can also be manually configured,
for example, auto-configuration fails because the
link-local address is not unique. An LL administrator specifies
type of autoconfiguration to use; the hosts on an LL receive
autoconfiguration information through Router Advertisement messages
The following sections describe how stateless, stateful and
address configuration will work in an IPv6/NBMA environment
A.2.1 Stateless Address
IPv6 stateless address configuration is the process by which an IPv
host autoconfigures its interfaces, as described in [IPV6-ADDRCONF].
When an IPv6 host first starts up, it generates a link-local
for the interface attached to the Logical Link. It then verifies
uniqueness of the link-local address using Duplicate
Detection (DAD). If the IPv6 host detects that the link-
address is not unique, the autoconfiguration process terminates.
IPv6 host must then be manually configured
After the IPv6 host determines that the link-local address is
and has assigned it to the interface on the Logical Link, the IPv
host will perform Router Discovery to obtain auto-
information. The IPv6 host will send out a Router Solicitation
will receive a Router Advertisement, or it will wait for
Armitage, et. al. Standards Track [Page 34]
RFC 2491 IPv6 over NBMA networks January 1999
unsolicited Router Advertisement. The IPv6 host will process the
and O bits of the Router Advertisement, as described in [9] and as
result may invoke stateful address auto- configuration
If there are no routers on the Logical Link, the IPv6 host will
able to communicate with other IPv6 hosts on the Logical Link
link-local addresses. The IPv6 host will obtain a neighbor's link
layer address using Address Resolution. The IPv6 host will
attempt to invoke stateful auto-configuration, unless it has
explicitly configured not to do so
A.2.2 Stateful Address Configuration (DHCP
IPv6 hosts use the Dynamic Host Configuration Protocol (DHCPv6)
perform stateful address auto-configuration, as described in [18].
A DHCPv6 server or relay agent is present on a Logical Link that
been configured with manual or stateful auto-configuration.
DHCPv6 server or relay agent will join the IPv6 DHCPv6 Server/Relay
Agent multicast group on the Logical Link. When the node's IPv6/
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
of Router Advertisements indicate it should do so, and may
stateful auto-configuration if it detects that no routers are
on the Logical Link. An IPv6 host that is obtaining
information through the stateful mechanism will hereafter be
to as a DHCPv6 client
A DHCPv6 client will send a DHCPv6 Solicit message to the DHCPv
Server/Relay-Agent multicast address to locate a DHCPv6 Agent.
the soliciting node's IPv6/NBMA driver gets the request from the IPv
Network Layer to send the packet, it follows the steps described
section 4.4.2. This will result in one or more nodes on the
receiving the message. Each node that receives the
packet will process it as described in section section 4.5. Only
IPv6 network layer of the DHCPv6 server/relay-agent will accept
packet and process it
A DHCPv6 Server or Relay Agent on the Logical Link will unicast
DHCPv6 Advertisement to the DHCPv6 client. The IPv6 network
will give the node's IPv6/NBMA driver the packet and link-
address of the DHCPv6 client (obtained through Neighbor Discovery
necessary). The node IPv6/NBMA driver will then transmit the
as described in section 4.4.1. This will result in a new pt-pt
being created between the server and the client if one did
previously exist
Armitage, et. al. Standards Track [Page 35]
RFC 2491 IPv6 over NBMA networks January 1999
The DHCP client's IPv6/NBMA driver will receive the
packet from the DHCP Server or Relay Agent, as described in
4.5. The node will de-encapsulate the multicast packet and then
it up to the IPv6 Network Layer for processing. The IPv6
layer will deliver the DHCPv6 Advertise message to the DHCPv6 client
Other DHCPv6 messages (Request, Reply, Release and Reconfigure)
unicast between the DHCPv6 client and the DHCPv6 Server.
on the reachability of the DHCPv6 client's address,
exchanged between a DHCPv6 client and a DHCPv6 Server on another
are sent either via a router or DHCPv6 Relay-Agent. Prior to
the DHCPv6 message, the IPv6 network layer will perform
Discovery (if necessary) to obtain the link-layer
corresponding to the packet's next-hop. A pt-pt VC will be set
between the sender and the next hop, and the encapsulated
transmitted over it, as described in 4.4. Sending Data
A.2.3 Manual Address
An IPv6 host will be manually configured if it discovers through
that its link-local address is not unique. Once the IPv6 host
configured with a unique interface token, the auto-
mechanisms can then be invoked
A.3 Internet Group Management Protocol (IGMP
IPv6 multicast routers will use the IGMPv6 protocol to
determine group memberships of local hosts. In the
described here, the IGMPv6 protocols can be used without any
modifications for NBMA. While these protocols might not be the
efficient in this environment, they will still work as
below. However, IPv6 multicast routers connected to an NBMA LL
optionally optimize the IGMP functions by
MARS_GROUPLIST_REQUEST messages to the MARS serving the LL
determining group memberships by the MARS_GROUPLIST_REPLY messages
Querying the MARS for multicast group membership is an
enchancement and is not required for routers to determine IPv
multicast group membership on a LL
There are three ICMPv6 message types that carry multicast
membership information: the Group Membership Query, Group
Report and Group Membership Reduction messages. IGMPv6 will
to work unmodified over the IPv6/NBMA architecture described in
document
An IPv6 multicast router receives all IPv6 multicast packets on
LL by joining all multicast groups in promiscuous mode [5]. The
server will then cause the multicast router to be added to
Armitage, et. al. Standards Track [Page 36]
RFC 2491 IPv6 over NBMA networks January 1999
existing and future multicast VCs. The IPv6 multicast router
thereafter be the recipient of all IPv6 multicast packets sent
the Logical Link
An IPv6 multicast router discovers which multicast groups
members in the Logical Link by periodically sending Group
Query messages to the IPv6 all-nodes multicast address. When
local node's IPv6/NBMA driver gets the request from the IPv6
layer to send the Group Membership Query packet, it follows the
described in 4.4.2. The node determines that the destination
of the packet is the all-nodes multicast address and passes
packet to the node's MARS client where the packet is encapsulated
directly transmitted to the MARS. The MARS then relays the packet
all nodes in the LL. Each node's IPv6/NBMA drivers will receive
packet, de-encapsulate it, and passed it up to the IPv6
layer. If the originating node receives the encapsulated packet,
packet will be filtered out by the MARS client since the
Member ID of the receiving node will match the CMI in the packet'
MARS encapsulation header
IPv6 hosts in the Logical Link will respond to a Group
Query with a Group Membership Report for each IPv6 multicast
joined by the host. IPv6 hosts can also transmit a Group
Report when the host joins a new IPv6 multicast group. The
Membership Report is sent to the multicast group whose address
being reported. When the local node IPv6/NBMA driver gets the
from the IPv6 network layer to send the packet, it follows the
described in 4.4.2. The node determines that the packet is
sent to a multicast address so forwards it to the node's MARS
for sending on the appropriate VC
The Group Membership Report packets will arrive at every node
is a member of the group being reported through one of the
attached to each node's MARS client. The MARS client will de
encapsulate the incoming packet and the packet will be passed to
IPv6 network layer for processing. The MARS client of the
node will filter out the packet when it receives it
An IPv6 host sends a Group Membership Reduction message when the
leaves an IPv6 multicast group. The Group Membership Reduction
sent to the multicast group the IPv6 host is leaving.
transmission and receipt of Group Membership Reduction messages
handled in the same manner as Group Membership Reports
Armitage, et. al. Standards Track [Page 37]
RFC 2491 IPv6 over NBMA networks January 1999
Appendix B. Alternative models of MARS support for Intra-LL
B.1 Simplistic approach - Use MARS 'as is'.
The IPv6/NBMA driver utilizes the standard MARS protocol to
a VC forwarding path out of the interface on which it can
all multicast IPv6 packets, including ICMPv6 packets. The IPv
packets are then transmitted, and received by the
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
best conserved by generating a sparsely distributed set of
Node multicast addresses (to which discovery queries are
sent). The original goal was to minimize the number of
nodes that simultaneously received discovery messages really
for someone else
However, in connection oriented NBMA environments it becomes
(or more) important to minimize the number of independent VCs that
given NBMA interface is required to originate or terminate. If
treat the MARS service as a 'black box' the sparse Solicited
address space can lead to a large number of short-use, but
lived, pt-mpt VCs (generated whenever the node is
Neighbor Solicitations). Even more annoying, these VCs are
useful for additional packets being sent to their
Solicited Node multicast address. A new pt-pt VC is required
actually carry the unicast IPv6 traffic that prompted the
Solicitation
The axis of inefficiency brought about by the sparse Solicited
address space is orthogonal to the VC mesh vs Multicast
tradeoff. Typically a multicast server aggregates traffic flow to
common multicast group onto a single VC. To reduce the VC
for ND, we need to aggregate across the Solicited Node address
- performing aggregation on the basis of a packet's function
than its explicit IPv6 destination. The trade-off here is that
aggregation removes the original value of scattering nodes
across the Solicited Nodes space. This is a price of the
between ND and connection oriented networks
B.2 MARS as a Link (Multicast) Server
One possible aggregation mechanism is for every node's IPv6/
driver to trap multicast ICMPv6 packets carrying multicast ND or
messages, and logically remap their destinations to the All
Armitage, et. al. Standards Track [Page 38]
RFC 2491 IPv6 over NBMA networks January 1999
group (link local scope). By ensuring that the All Nodes group
supported by an MCS, the resultant VC load within the LL will
significantly reduced
A further optimization is for every node's IPv6/NBMA driver to
multicast ICMPv6 packets carrying multicast ND or RD messages,
send them to the MARS itself for retransmission on
(involving a trivial extension to the MARS itself.) This
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
members (LL members registered for multicast support).
Because the VCs between a MARS and its MARS clients carry LLC/
encapsulated packets, ICMP packets can be multiplexed along
normal MARS control messages. In essence the MARS behaves as
multicast server for non-MARS packets that it receives from
the LL
As there is no requirement that a MARS client accepts only
control messages on ClusterControlVC, ICMP packets received in
fashion may be passed to every node's IP layer without
comment. Within the IP layer, filtering will occur based on
packet's actual destination IP address, and only the targeted
will end up responding
Regrettably this approach does result in the entire Cluster'
membership having to receive a variety of ICMPv6 messages that
will always throw away
Armitage, et. al. Standards Track [Page 39]
RFC 2491 IPv6 over NBMA networks January 1999
Appendix C. Flow
The relationship between IPv6 packet flows, Quality of
guarantees, and optimal use of underlying IP and NBMA
resources are still subjects of ongoing research in the
(specifically the ISSLL, RSVP, IPNG, and ION working groups).
document currently only describes the use of flow detection as
means to optimize the use of NBMA network resources through
establishment of inter-LL shortcuts
C.1. The use of non-zero FlowID to suppress flow
For the purposes of this IPv6/NBMA architecture, a flow is
A related sequence of IPv6 packets that the first hop router
allowed to perform flow-detection on for the purposes
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
local configuration issue
The flow-detection rule specifies that only packets with a
FlowID can be considered as flows for which shortcut discovery may
triggered. The rationale behind this decision is
NBMA shortcuts are for the benefit of 'the network' optimizing
forwarding of IPv6 packets in the absence of any other
from the host
It is desirable for an IPv6/NBMA host to have some mechanism
overriding attempts by 'the network' to optimize its
forwarding path
A zero FlowID has IPv6 semantics of "the source allows the
to utilize its own discretion in providing best-effort
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
free to optimize the forwarding path using shortcuts
A non-zero FlowID has IPv6 semantics of "the source has
established some preferred, end to end hop by hop
behaviour for packets with this FlowID
Armitage, et. al. Standards Track [Page 40]
RFC 2491 IPv6 over NBMA networks January 1999
The IPv6 semantics of non-zero FlowID are consistent with
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
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 IPv
router defaults to providing best-effort forwarding for packets
FlowID/source-address pair is not recognized).
Thus, the modes of operation supported by this document becomes
Zero
Best effort forwarding, with optional shortcut
triggered through flow-detection
Non-zero
Best effort forwarding if the routers along the path have
been otherwise configured with alternative processing rules
this FlowID/source-address pair. Flow detection relating
shortcut discovery is suspended
If the routers along the path have been configured
particular processing rules for this FlowID/source-address pair
the flow is handled according to those rules. Flow
relating to shortcut discovery is suspended
Mechanisms for establishing particular per-hop processing rules
packets with non-zero FlowID are neither constrained by, nor
by, this document
C.2. Future directions for Flow
In the future, accurate mapping of IPv6 flows onto NBMA VCs
require more information to be exchanged during the
Discovery process than is currently available in Neighbor
packets. In these cases, the IPv6 Neighbor Discover protocols can
extended to include new TLV options (see section 4.6 of RFC 1970
[7]). However, if new options are required, the specification
these options must be co-ordinated with the IPNG working group
Since RFC 1970 specifies that nodes must silently ignore options
do not understand, new options can be added at any time
breaking backward compatibility with existing implementations
Armitage, et. al. Standards Track [Page 41]
RFC 2491 IPv6 over NBMA networks January 1999
NHRP also provides mechanisms for adding optional TLVs to
Requests and NHRP Replies. Future developments of this document'
architecture will require consistent QoS extensions to both ND
NHRP in order to ensure they are semantically equivalent (
differences are undesirable, but can be tolerated).
Support for QoS on IPv6 unicast flows will not require
extensions to the existing MARS protocol. However, future support
QoS on IPv6 multicast flows may require extensions. MARS
messages share the same TLV extension mechanism as NHRP, allowing
extensions to be developed as needed
Appendix D. Shortcut Limit
For NS messages sent as a shortcut trigger, a new type of ND
is needed to pass on the information about the data flow hop
from the host to the router. The use of this ND option is defined
section 3.2.2 of this specification. Its binary
follows the rules of section 4.6 of RFC 1970:
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
attempt
Reserved1 This field is unused. It MUST be initialized
zero by the sender and MUST be ignored by
receiver
Reserved2 This field is unused. It MUST be initialized
zero by the sender and MUST be ignored by
receiver
Armitage, et. al. Standards Track [Page 42]
RFC 2491 IPv6 over NBMA networks January 1999
The shortcut limit option is used by a host in a
Solicitation message sent as a shortcut trigger to a
router. It restricts the router's shortcut query to
reachable via the specified number of hops. The shortcut limit
given relative to the host requesting the shortcut. NS
with shortcut limit values of 0 or 1 MUST be silently ignored
Armitage, et. al. Standards Track [Page 43]
RFC 2491 IPv6 over NBMA networks January 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Armitage, et. al. Standards Track [Page 44]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
