Internet-Draft Grenville Armitage
Lucent Technologies
Peter Schulter
BrightTiger Technologies
Markus Jork, Geraldine Harter
Digital
July 22nd, 1997
Transient Neighbors for IPv6 over ATM
<draft-ietf-ion-tn-01.txt>
Status of this Memo
This document was submitted to the IETF Internetworking over NBMA
(ION) WG. Publication of this document does not imply acceptance by
the ION WG of any ideas expressed within. Comments should be
submitted to the ion@nexen.com mailing list.
Distribution of this memo is unlimited.
This memo is an internet draft. Internet Drafts are working documents
of the Internet Engineering Task Force (IETF), its Areas, and its
Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the
"lid-abstracts.txt" listing contained in the Internet-Drafts shadow
directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This document describes an architecture and protocols for IPv6 over
ATM. It allows conventional host-side operation of the Neighbor
Discovery protocol, while also supporting the establishment of
'shortcut' ATM forwarding paths. This is achieved through the use of
Redirects to create Transient Neighbors, standard IPv6 protocol
operation within the IPv6 Logical Link, and inter-router NHRP for
location of off-Link destinations. Shortcuts are discovered by
egress routers when triggered either by detection of suitable packet
flows, or source host initiation. NHRP is used to locate a better
link level first hop, and the result is announced to the source host
using a Neighbor Discovery Redirect message.
Armitage, et al. Expires January 22nd, 1998 [Page 1]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
Revision History
June 1997, version 01 as an official ION working group work item.
Host tokens now generated to look like EUI-64 addresses.
Updated "on-link" definitions to match current ND spec.
March 1997, version 00 (again) as an official ION working group
work item. Augmented MARS now required, add SVC signalling
procedures, host token, and other issues raised at December
1996 IETF and on the ION mailing list. Name changed to draft-
ietf-ion-tn-00.txt.
October 1996, version 01 under ION working group.
Significantly expanded description of IPv6 Neighbor Discovery,
DHCPv6, IGMPv6 protocol operation (based on IPv6 specific
material from draft-ietf-ion-ipv6atm-framework-00.txt). New
authors added.
June 1996, version 00 (again)
Reissued under the ION working group. No substantive changes.
Prelude to June 1996 IETF. Name changed to draft-armitage-
ion-tn-00.txt
April 1996, version 00 under IP-ATM working group.
Documents and expands on an informal presentation at the March
1996 IETF.
1. Introduction.
The IPv4 world evolved an approach to address resolution that
focussed on 'link layer' level protocol operation. ATMARP [3], and
more currently NHRP [8], are the consequences of this model when
applied to the IP over ATM world. IPv6 developers opted to migrate
away from a link layer specific approach, chosing to combine a number
of tasks into a protocol known as Neighbor Discovery [7], intended to
be non-specific across a number of link layer technologies.
A key assumption made by Neighbor Discovery's actual protocol is that
the link technology underlying a given IP interface is capable of
native multicasting. This is not particularly true of ATM interfaces
(a point that lead to the development of the MARS protocol, RFC 2022
[5]).
The IP/ATM community also considers it important to show how Neighbor
Discovery can be applied to the location of 'shortcut' routes (where
IP routing boundaries are 'shortcut' if they are found to be merely
logical boundaries between nodes attached to the same physical link
network).
This document synthesizes a general solution of IPv6 and IPv6 ND over
ATM that supports shortcut routing without requiring large scale
Armitage, et al. Expires January 22nd, 1998 [Page 2]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
multicasting of ND messages around an ATM network. The salient
components are:
- The IPv6 Neighbor model, where neighbors are discovered through
the use of messages multicast to members of an IP interface's
local Logical Link.
- The MARS model, allowing emulation of general multicast using
multicast servers and point to multipoint calls provided by the
underlying link network.
- The NHRP service for seeking out the link layer identities of IP
interfaces who are logically distant in an IP topological sense.
- The modeling of IP traffic as 'flows', and using the existence
of a flow as the basis for attempting to set up a shortcut link
level connection.
In summary, this document proposes that:
The IPv6 "Link" is generalised to "Logical Link" (LL) in ATM
environments, analogous to the generalisation of IPv4 IP Subnet to
Logical IP Subnet (LIS) in RFC1577.
IPv6 over ATM interfaces utilize RFC 2022 (MARS) for general
intra-link multicasting, and use the MARS itself to distribute
discovery messages within the Logical Link in an optimal fashion.
For destinations not currently considered to be Neighbors
(initially this will include just about any destination not in the
Logical Link), a host sends the packets to its default router.
The egress router from a Logical Link is responsible for detecting
the existence of an IP packet 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 destination IP
address.
The last router/NHS before the target of the NHRP query ascertains
the target interface's preferred ATM address.
The originally querying router then issues a Redirect to the IP
source, identifying the flow's destination as a transient
Neighbor.
Host-initiated triggering of shortcut discovery, regardless of the
existence of a packet flow, is also supported through specific
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 protocols
for each link layer technology.
When the destination of a flow is solicited as a transient
Armitage, et al. Expires January 22nd, 1998 [Page 3]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
neighbor, the returned ATM address will be the one chosen by the
destination when the flow was originally established through hop-
by-hop processing. This supports the existing ND ability for
destinations to perform their own dynamic interface load sharing.
2. Logical Links, and Transient Neighbors.
IPv6 contains a concept of on-link and off-link. Neighbors are those
nodes that are considered on-link and whose link-layer addresses may
therefore be located using Neighbor Discovery. Borrowing from the
terminology definitions in the ND text:
on-link - an address that is assigned to a neighbor's interface on
a shared link. A host considers an address to be on-link
if:
- it is covered by one of the link's prefixes, or
- a neighboring router specifies the address as the
target of a Redirect message, or
- a Neighbor Advertisement message is received for the
target address, or
- a Neighbor Discovery message is received from the
address.
off-link - the opposite of "on-link"; an address that is not
assigned to any interfaces attached to a shared link.
Off-link nodes are considered to only be accessible through one of
the routers directly attached to the link.
The ATM environment complicates the sense of the word 'link' in much
the same way as it complicated the sense of 'subnet' in the IPv4
case. For IPv4 this required the definition of the Logical IP Subnet
(LIS) - an administratively constructed set of hosts that would share
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 'on
link' with respect to each other.
The members of an LL are an IPv6 interface's initial set of
neighbors, and each interface's Link Local address only needs to
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 IPv6
interface's set of Neighbors. However, this does not change the set
of interfaces that make up its LL. This leads to three possible
relationships between any two IPv6 interfaces:
Armitage, et al. Expires January 22nd, 1998 [Page 4]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
- On LL, Neighbor.
- Off LL, Neighbor.
- Off LL, not Neighbor.
Off LL Neighbors represent the 'shortcut' connections, where it has
been ascertained that direct connectivity at the ATM level is
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 neighbors
within a Logical Link (intra-LL) and neighbors beyond the LL (inter-
LL). The goal is to allow both inter- and intra-LL neighbor discovery
to involve no changes to the host-side IPv6 stack for ATM.
3.1 Intra-LL - ND over emulated multicast.
The basic model of ND assumes that a link layer interface will do
something meaningful with an ICMPv6 packet sent to a multicast IP
destination address. (IPv6 assumes that multicasting is an integral
part of the Internet service.) This document assumes multicast
support will be provided using the RFC 2022 (MARS) [5] service. In
the same way as an IPv4 LIS is considered to map directly onto an
IPv4 MARS Cluster, an IPv6 LL maps directly onto an IPv6 MARS
Cluster.
The goal of intra-LL operation is that the IPv6 layer must be able to
simply pass multicast ICMPv6 packets down to the IPv6/ATM driver
without any special, ATM specific processing. The underlying
mechanism for distributing Neighbor Discovery and Router Discovery
messages then works as expected.
Sections 3.1.1 and 3.1.2 are informational, and describe the
limitations of various mechanisms below the IPv6 layer for
distributing ND and RD messages. Section 3.1.3 describes the
additional functionality that SHALL be required of any MARS used in
conformance with this document.
3.1.1 Simplistic approach - Use MARS 'as is'.
The IPv6/ATM 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, VC 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
Armitage, et al. Expires January 22nd, 1998 [Page 5]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
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 an ATM environment it becomes equally (or more) important
to minimize the number of independent VCs that a given ATM 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.
3.1.2 MARS as a Link (Multicast) Server.
One possible aggregation mechanism is for every node's IPv6/ATM
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/ATM 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 we can multiplex ICMP packets in addition to the
original 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 only accepts MARS
Armitage, et al. Expires January 22nd, 1998 [Page 6]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
messages on ClusterControlVC, ICMP messages 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.
3.1.3 Mandatory augmented MARS behavior.
To minimise unwanted traffic delivery across ClusterControlVC, the
following augmention to MARS functionality SHALL be employed for
conformance with this document:
- Clients register with the MARS as members of their Solicited
Nodes multicast group.
- When the MARS receives a data packet (identified by its LLC/SNAP
encapsulation), it scans the group membership database to find
the ATM addresses of the destination group's members.
- The MARS then checks to see if every group member currently has
its pt-pt control VC open to the MARS. If so, the MARS sends a
copy of the data packet directly to each group member over the
existing pt-pt VCs.
- If one or more of the discovered group members do not have an
open pt-pt VC to the MARS, or if there are no group members
listed, the packet is sent out ClusterControlVC instead. No
copies of the packet are sent over the existing (if any) pt-pt
VCs.
Section 4.4.2 describes the matching client-side behavior.
3.2 Inter-LL - Redirects, and their generation.
The key to creating transient neighbors is the Redirect message
(section 8 [7]). IPv6 allows a router to inform the members of an LL
that there is a better 'first hop' to a given destination (section
8.2 [7]). The advertisement itself is achieved through a Router
Redirect message, which may carry the link layer address of this
better hop.
A transmitting host only listens to Router Redirects from the router
that is currently acting as the default router for the IP destination
that the Redirect refers to. If a Redirect arrives that indicates a
better first hop for a given destination, and supplies a link layer
(ATM) address to use as the better first hop, the associated Neighbor
Cache entry in the source host is updated and its reachability set to
STALE. Updating the cache in this context involves building a new VC
to the new ATM address. If this is successful, the old VC is torn
down only if it no longer required (as this VC was to the router, it
Armitage, et al. Expires January 22nd, 1998 [Page 7]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
may still be required by other packets from the host that are heading
to the router).
The manner by which a router determines a better first-hop is not
specified or constrained in [7]. This document defines such a
mechanism.
3.2.1 Redirect Triggers.
Support for shortcut connections is justified on the grounds that
demanding flows of IP packets may exist between source/destination
pairs that are separated by IP routing boundaries. NHRP [8] is built
on the premise that the source itself decides to seek a shortcut
connection. The Cell Switch Router [11] and the IP Switch [12]
models place the detection and management of IP packet flows into the
routers (where flows cross the edges of IP routing boundaries).
This document provides two mechanisms for triggering the discovery of
a better first hop:
Router-based flow identification/detection.
Host-initiated shortcut request
The host initiated trigger is discussed further in section 3.2.3.
A router SHALL only track flows that originate from a directly
attached host (a host that is within the LL-local scope of one of the
router's interfaces). IP packets arriving from another router are
never used to trigger the generation of a Router Redirect.
The actual algorithm(s) for determining when a flow should trigger an
attempt to resolve a better first hop are not defined in this
document.
3.2.2 Use of NHRP between routers.
Once flow detection has occurred, or a host trigger has been
detected, routers SHALL use NHRP in an NHS to NHS mode to establish
the IP to link level address mapping of a better first hop. The
routers will perform the following functions:
- Construct NHRP Requests and Replies.
- Parse incoming NHRP Requests and Replies from other NHSes
(routers).
- Forward NHRP Requests towards an NHS that is topologically
closer to the IPv6 target.
- Forward NHRP Replies towards an NHS that is topologically closer
to the requester.
- Perform syntax translation between Neighbor Solicitations and
Armitage, et al. Expires January 22nd, 1998 [Page 8]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
outbound NHRP Requests.
- Perform syntax translation between inbound NHRP Replies and
Neighbor Redirects or Neighbor Advertisements.
The destination of the flow that caused the trigger (or the target of
the host initiated trigger) is used as the target for resolution in a
NHRP Request. The router then forwards this NHRP Request to the next
closest NHS. The process continues (as it would for normal NHRP)
until the Request reaches an NHS that believes the IP target is
within link-local scope of one of its interfaces. (This may
potentially occur within a single router.)
The last hop router SHALL resolve the NHRP Request from mapping
information contained in its neighbor cache for the interface on
which the specified target is reachable. If there is no appropriate
entry in the neighbor cache, or the destination is currently
considered unreachable, the last hop router SHALL perform Neighbor
Discovery on the local interface, and build the NHRP Reply from the
resulting answer. (Note, in the case where the NHRP Request
originated due to flow detection, there must already be a hop-by-hop
flow of packets going through the last hop router towards the target.
In this typical case the Neighbor cache will already have the desired
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 the
originating router, the return of the NHRP Reply results in the
following events:
A Router Redirect is constructed using the IP/ATM mapping carried
in the NHRP Reply.
The Router Redirect is unicast to the IP packet flow's source
(using the VC on which the flow is arriving at the router, if it
is a pt-pt VC).
(It is worth noting that the router constructing the NHRP Reply does
so using the ATM address returned by the target host when the target
host first accepted the flow of IP traffic. This retains a useful
feature of ND - destination interface load sharing.)
The behavior for host initiated shortcuts is covered in the next
section.
[The specific syntax translation rules between NHRP and ND messages
are TBD.]
3.2.3 Host Triggered Redirection
A source host may also want to trigger a redirection to a transient
neighbor. To support host-triggered redirects, routers conforming to
Armitage, et al. Expires January 22nd, 1998 [Page 9]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
this document SHALL recognize specific Neighbor Discovery messages
sent by hosts to trigger resolutions of off-link addresses.
To perform host-triggered redirects, a source host creates a Neighbor
Solicitation message for the off-LL destination which is also
destined to the off-LL target (rather than the off-LL target's
solicited node multicast address). Because this NS packet is
addressed to a unicast address, the sending host forwards it to the
next hop router for traffic to the off-LL destination.
A router SHALL consider a unicast NS to an off-LL address as a
request for a host-triggered redirect. A suitable NHRP Request is
constructed and sent as described in section 3.2.2. The original NS
message is discarded.
Once the NHRP Reply is received by the originating router, the router
constructs a Neighbor Advertisement message containing the IPv6
address of the transient neighbor, the ATM datalink address returned
by the NHRP resolution process, and the Overide bit set to 1.
If the NHRP Reply returns the address of an egress router rather than
of the destination node itself, then the Router bit MUST be set to 1
in the NA message and the egress router MUST behave as a proxy router
as defined in [7].
When the soliciting node receives the NA message it will update its
Neighbor and Destination caches. The next packet sent to the
transient neighbor will create a direct VC to that neighbor (or to
the best egress router towards that neighbor as determined by NHRP).
3.3. Neighbor Unreachability Detection.
Neighbor Solicitations sent for the purposes of Neighbor
Unreachability Detection (NUD) are unicast to the Neighbor in
question, using the VC that is already open to that Neighbor. This
suggests that as far as NUD is concerned, the Transient Neighbor is
indistinguishable from an On-LL Neighbor.
3.4. Duplicate Address Detection.
Duplicate Address Detection is only required within the link-local
scope, which in this case is the LL-local scope. Transient Neighbors
are outside the scope of the LL. No particular interaction is
required between the mechanism for establishing shortcuts and the
mechanism for detection of duplicate link local addresses.
4 Node Operation Concepts
This section describes of node operations for performing basic
functions (such as sending and receiving data) on an LL. The
application of these basic functions to the operation of the various
IPv6 protocols such as Neighbor Discovery is described in Appendix A.
Armitage, et al. Expires January 22nd, 1998 [Page 10]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
4.1.Connecting to a LL
Before a node can send or receive IPv6 datagrams it must first join a
Logical Link. This is done by the node's MARS client establishing a
pt-pt VC to the MARS and registering as a Cluster Member [5]. The
MARS will then add the node's MARS client to ClusterControlVC. After
this is done the node is a member of the LL, has been assigned a
Cluster Member ID (CMI), and can begin supporting IPv6 and IPv6 ND
operations.
The encapsulation of MARS control messages (between MARS and MARS
Clients) remains the same as shown in RFC 2022:
[0xAA-AA-03][0x00-00-5E][0x00-03][MARS control message]
(LLC) (OUI) (PID)
Within actual MARS control messages:
The mar$afn field in MARS messages remains 0x0F.
The mar$pro field in MARS messages SHALL be 0x86DD.
The mar$op.version field in MARS messages remains 0x00.
The mar$spln and mar$tpln fields (where relevant) are either 0
(for null or non-existent information) or 16 (for the full IPv6
protocol address).
When a host starts up it SHALL issue a single 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-local
scope.
When an IPv6/ATM router interface starts up, in addition to the
operations required for a host, it SHALL issue:
- A single group MARS_JOIN for the All-routers address with link-
local scope.
- A block MARS_JOIN for the range(s) of IPv6 multicast addresses
(with greater than link-local scope) for which promiscuous
reception is required.
4.2 Joining a Multicast Group
This section describes the node's behavior when it gets a
JoinLocalGroup request from the IPv6 Layer. The IPv6/ATM driver
examines each group address to determine how the join request is to
be handled.
If a JoinLocalGroup for a node-local address is received then no
Armitage, et al. Expires January 22nd, 1998 [Page 11]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
action is taken and the JoinLocalGroup function returns success to
the caller. (Node-local addresses are not handled by the IPv6/ATM
layer.)
When the IPv6/ATM driver receives a request to join a non node-local
multicast group, it sends an appropriate MARS_JOIN request to
register its cluster-wide membership of the specified group.
4.3. Leaving a Multicast Group
This section describes the node's behavior when it gets a
LeaveLocalGroup request from the IPv6 Layer. The IPv6/ATM driver
examines each group address to determine how the leave request is to
be handled.
If a LeaveLocalGroup for a node-local address is received then no
action is taken and the LeaveLocalGroup function returns success to
the caller. (Node-local addresses are not handled by the IPv6/ATM
layer.)
When the IPv6/ATM driver receives a request to leave a non node-local
multicast group, it sends an appropriate MARS_LEAVE request to de-
register its cluster-wide membership of the specified group.
4.4. Sending Data
The processing of packets outbound from the local IPv6 layer depends
on whether they have unicast or multicast destinations.
4.4.1. Sending Unicast Data
When a node is given an IPv6 unicast packet to send, the node must
map the next hop address to a PtP VC over which the packets are to
be sent. (Minimally, the mapping may be based on the destination
address, but may also include the flow label information to
facilitate handling QoS based flows. How the flow labels are used is
a topic still being discussed by the IPv6 community.)
If a PtP VC for the next hop address exists, the packet SHALL be
encapsulated in the following LLC/SNAP header, and sent over that VC.
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
If no PtP VC exists for the next hop address for the packet, then the
node will have to place a call to set up a VC to the next hop
destination. Any time the IPv6/ATM driver receives a unicast packet
for transmission the IPv6 Network layer should already have performed
Neighbor Discovery on the next hop to determine the link-layer
address (e.g. ATM Address) of the next hop. Thus, the information
needed to place the call to the next hop will already be available on
the sending node.
During call placement, the sending node will queue the packet that
triggered the call request so that it can be sent when the circuit is
Armitage, et al. Expires January 22nd, 1998 [Page 12]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
established.
If the call to the next hop destination node fails the sending node
will discard the packet that triggered the call setup. Persistent
failure to create a VC to the next hop destination will be detected
and handled at the IPv6 Network Layer through NUD.
4.4.2. Sending Multicast Data
Multicast packets SHALL be transmitted using the following
encapsulation:
[0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6 packet]
The driver's Cluster Member ID (CMI) is copied into the 2 octet
pkt$cmi field prior to transmission.
If the packet's destination is one of the following multicast
addresses, it is sent over the MARS client's PtP 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.
The MARS will redistribute the IPv6 packet appropriately as described
in section 3.1.3. (If the VC to the MARS has been idle timed out for
some reason, it must be re-established before forwarding the packet
to the MARS.)
If packet's destination is any other address, then the usual MARS
client mechanisms are used to select and/or establish a pt-mpt VC on
which the packet is to be sent.
4.5. Receiving Data
Packets received using the encapsulation shown in section 4.4.1
SHALL be de-encapsulated and passed up to the IPv6 layer. The IPv6
layer then determines how the incoming packet is to be handled.
Packets received using the encapsulation shown in section 4.4.2 SHALL
have their pkt$cmi field compared to the receiving client's CMI. If
the pkt$cmi in the header matches the receiver's CMI the packet SHALL
be silently dropped. Otherwise, the packet SHALL be de-encapsulated
and passed to the IPv6 layer. The IPv6 layer then determines how the
incoming packet is to be handled.
4.6. Unicast Data VC Setup and Release
Unicast VCs are maintained separately from multicast VCs. Since the
setup and maintenance of multicast VCs are handled by the MARS client
on each IPv6 node, and this is described [5], only the setup and
maintenance of unicast VCs will be described here. Currently, only
Armitage, et al. Expires January 22nd, 1998 [Page 13]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
best effort unicast VCs are considered. The creation of VCs for
other classes of service is outside the scope of this document.
IPv4 over ATM mechanisms (RFC 1577 and NHRP) establish VCs from a
sending node towards the receiving node (since until the address
resolution mechanism provides the sender with a mapping, neither the
sender nor the target node have the ability to set up a VC). IPv6
differs in that, in the most common situation, the receiving node
will be the first to establish a direct ATM VC between itself and the
nominal sender. This is a consequence of the Neighbor
Solicitation/Advertisement exchange sequence.
When one node in an LL has a packet to send to another node in the
same LL it will first perform a Neighbor Discovery on the destination
address. This is done to resolve the IPv6 destination address into a
link-layer address which the sender can then use to send unicast
packets. The Neighbor Discovery operation is performed by the sending
node transmitting a Neighbor Solicitation packet to the appropriate
solicited-node multicast address associated with the destination or
next hop address for the outgoing packet. When the solicited node
receives this packet it will respond with a Neighbor Advertisement
packet which it will unicast to the soliciting node. Since the
Neighbor Solicitation packet contains the data-link address of the
soliciting node, the solicited node has all the information it
requires to unicast the Neighbor Advertisement. Thus, since the
solicited node is generally the first to send a unicast packet in any
exchange between two nodes, it will be the one which will initiate
the setup of the PtP VC between the two.
The creation of a PtP VC is coupled with the Neighbor Discovery
mechanism. Because IPv6 will not attempt to send a unicast data
packet until it has completed the Neighbor Solicitation process and
has a valid Neighbor cache entry for the next hop destination, there
will be no need to try to create a PtP VC until IPv6 has resolved the
next hop address to an ATM datalink address. Thus, if the IPv6/ATM
driver receives a unicast packet for transmission, it can expect that
the IPv6 layer will also provide the datalink address for the
immediate destination (just as a MAC address is provided to Ethernet,
for example). The IPv6/ATM driver can then use this information to
either create a new VC, or to determine if there is already a
suitable VC set up to the destination. Note that the datalink
address supplied by IPv6 will be that of the next hop, which is not
necessarily the same as that of the destination (e.g. the
destination node is reachable only through a router).
Creation of a new PtP VC as the result of a Redirect message (either
a redirect to a node on the same LL, or a shortcut redirect to a node
outside the LL) results in the sending (redirected) node creating a
VC to a new receiving node. The redirected node does not know, or
care if the new node to which it has been redirected is on it's LL or
not since it has all the information necessary to set up the new PtP
VC in the redirect message (this includes the link-layer address
option). Since no further Neighbor Discovery operations are required
after a redirect, the target does not need to be on the LL, but does
Armitage, et al. Expires January 22nd, 1998 [Page 14]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
need to be reachable at the link layer (in fact, the target of the
redirect may be an egress router, or a router closer to the
destination). When redirected, the sending node will set up a PtP VC
to the new node if one does not previously exist. The redirected
node will then use the new VC to send data rather than whatever VC it
had previously been using.
Redirects are unidirectional. That is, the redirected node will
create a new PtP VC over which it will send data previously sent on
another VC (sending data to a different router for example), but the
destination node will continue to send data back to the redirected
node on the old path. This happens because the destination node has
no way of determining the IPv6 address of the 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 new VC. The non-redirected
node will continue to send data to the redirected node over the old
path. This is consistent with the way IPv6 redirects operate, in
that they are not intended to provide symetrical redirection. If the
non-redirected node eventually receives a redirect it should discover
the existing VC to the target node and use that rather than creating
a new VC.
Once a PtP VC is established it is desirable that it be released
when no longer needed to save both node and network resources. The
simplest option would be to release the VC after some period of
inactivity. Another would be to tie the VC to the IPv6 Destination
or Neighbor cache entries so that the VC was released as the result
of a state change in the caches. [This is TBD, and requires
discussion in the WG and on the mailing list.]
4.7 UNI 3.0/3.1 SVC Signalling Support
When an IPv6 node places a call to another IPv6 node, it should
follow the procedures in [13] and [14] for signalling UNI 3.0/3.1
SVCs and negotiating MTU. The default MTU size on a LL is 9188 bytes
as specified in [14].
Because of the nature of both IPv6 and transient neighbor discovery,
the IPv6/ATM driver will not know if the called party is on the
calling node's LL. The calling party cannot assume that called party
will have the same default MTU as its LL. Thus, an appropriate MTU
MUST be negotiated for each call placed using the procedures
described in [14].
Note that while the procedures in [14] still apply to IPv6 over ATM,
IPv6 Path MTU Discovery [15] is used by nodes and routers rather than
IPv4 MTU discovery. Additionally, while IPv6 nodes are not required
to implement Path MTU Discovery, IPv6/ATM nodes SHOULD implement it.
Also, since IPv6 nodes will negotiate an appropriate MTU for each VC,
Path MTU should never be triggered since neither node should ever
receive a Packet Too Big message to trigger Path MTU Discovery. When
nodes are communicating via one or more routers Path MTU Discovery
will be used just as it is for legacy networks.
Armitage, et al. Expires January 22nd, 1998 [Page 15]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
5. Interface Tokens, Link Layer Address Options, Link-Local Addresses
5.1 Interface Tokens
Each IPv6 interface must have a interface token which is used to form
IPv6 autoconfigured addresses. This interface token must be unique
within a Logical Link to prevent the creation of duplicate addresses
when stateless address configuration is used.
In cases where two nodes on the same LL produce the same interface
token then one interface MUST choose another host-token. All
implementations MUST support manual configuration of interface tokens
to allow operators to manually change a interface token on a per-LL
basis. Operators may choose to manually set interface tokens for
reasons other than eliminating duplicate addresses.
All interface tokens MUST be 64 bits in length and formatted as
described in the following sections. The hosts tokens will be based
on the format of an EUI-64 identifier [10]. For IPv6 use, the
semantics of the EUI-64 Global/Local indicator bit has been inverted.
(A universally administered EUI-64 is signified by a Global/Local
indicator bit value of 0, while a globally unique IPv6 interface
token is signified by a 1 in the corresponding position.)
5.1.1 Interface Tokens Based on MAC or ESI values
When the underlying ATM interface is identified by an ATM End System
Address (AESA, formerly known as an NSAPA), the interface token will
be formed from the ESI and SEL values in the AESA as follows:
[0x00][ESI][SEL]
[0x00] is a one octet field which is always set to 0.
Note that the bit corresponding to the EUI-64 Global/Local bit
is always reset indicating that this address is not a globally
unique IPv6 interface token.
[ESI] is a six octet field.
This field always contains the six octet ESI value for the
AESA used to address the specific instance of the IPv6/ATM
interface.
[SEL] is a one octet field.
This field always contains the SEL value from the AESA used to
address the specific instance of the IPv6/ATM interface.
5.1.2 Interface Tokens Based on EUI-64 Values
Where the underlying ATM NIC driver has access to a set of one or
more 64 bit EUI-64 values unique to the ATM NIC (e.g. EUI-64
addresses configured into the NIC's ROM), the IPv6/ATM interface
Armitage, et al. Expires January 22nd, 1998 [Page 16]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
SHOULD use one of these values to create a unique interface token.
after inverting the Global/Local identifier bit. (Any relationship
between these values and the ESI(s) registered with the local ATM
switch by the ATM driver are outside the scope of this document.)
When EUI-64 values are used for IPv6 interface tokens the only
modification allowed to the octet string read from the NIC is
inversion of the Global/Local identifier bit.
5.1.3 Interface Tokens Based on Native E.164 Addresses
When an interface uses Native E.164 addresses then the E.164 values
will be used to generate an interface token as follows:
[D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]
[D14] A single octet containing the semi-octet representing the most
significant E.164 digit shifted left four bits to the most
significant four bits of the octet. The lower four bits MUST be set
to 0. Note that the EUI-64 Global/Local indicator is set to 0
indicating that this is not a globally unique IPv6 interface token.
[D13D12] A single octet containing the semi-octet representing the
second most significant E.164 digit [D13] shifted left four places to
the most significant bits of the octet, and the third most
significant semi-octet in the four least significant bits of the
octet.
[D11D10] - [D1D0] Octets each containing two E.164 digits, one in the
most significant four bits, and one in the least significant four
bits as indicated.
5.1.4 Multiple Logical Links on a Single Interface
Physical ATM interfaces are commonly used to provide multiple logical
ATM interfaces. Each logical ATM interface might be associated with a
different SEL field of a common AESA prefix, or a set of entirely
separate ESIs might have been registered with the local ATM switch to
create a range of unique AESAs.
In either case, the minimum information required to uniquely identify
each logical ATM interface is (within the context of the local switch
port) their ESI+SEL combination. Since each logical ATM interface
can support an independent IPv6 interface, two separate scenarios are
possible:
- A single host with IPv6/ATM interfaces onto a number of
independent Logical Links.
- A set of 2 or more 'virtual hosts' (vhosts) might share a common
ATM NIC and driver. Each vhost is free to establish IPv6/ATM
interfaces associated with different or common LLs. However,
vhosts are bound by the same requirement as normal hosts - no
two interfaces to the same LL can share the same interface
Armitage, et al. Expires January 22nd, 1998 [Page 17]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
token.
In the first scenario, since each IPv6/ATM interface is associated
with a different LL, each interface's external identity can be
differentiated by the LL prefix. Thus, the host can re-use a single
unique interface token across all such IPv6/ATM interfaces. This
token SHALL be constructed using the rules in section 5.1.1 (ignoring
the possible variations in SEL). (Internally the host will tag
received packets in some locally specific manner to identify what
IPv6/ATM interface they arrived on. However, this is an issue
generic to all IPv6 interfaces, and does not required definition in
this document.)
The second scenario is more complex, but likely to be rarer. For the
purpose of conformance with this document, each vhost SHALL select a
different interface token from the range of 64 bit values available
to the ATM NIC (as described in 5.1.1). Each vhost SHALL implement
IPv6/ATM interfaces in such a way that no two or more vhosts end up
advertising the same interface token onto the same LL. (Conformance
with this requirement may be achieved by choosing different SEL
values, ESI values, or both.)
5.2 Link Layer Address Options
Neighbor Discovery defines two options for carrying link-layer
specific source and target addresses. In this case these options must
carry full ATM addresses.
The source and target link-layer address options must carry any one
of the three possibilities, and indicate which one it is.
The format for these two options when in an ATM environment is
adapted from the MARS [5] and NHRP [8] specs, and SHALL be:
[Type][Length][NTL][STL][..ATM Number..][..ATM Subaddress..]
| Fixed || Link layer address |
[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 bytes
are added to the end of the option to ensure its length is a multiple
of 8 octets. (For example, a single ATM address in AESA format would
result in 24 bytes of real data, require no padding, and result in
[Length] being set to 3.)
[NTL] is a one octet 'Number Type & Length' field.
Defines the type and length of the ATM number immediately following
the [STL] field. The format is as follows:
Armitage, et al. Expires January 22nd, 1998 [Page 18]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|x| length |
+-+-+-+-+-+-+-+-+
The most significant bit is reserved and MUST be set to zero. The
second most significant bit (x) is a flag indicating whether the ATM
number is in:
ATM Forum AESA format (x = 0).
Native E.164 format (x = 1).
The bottom 6 bits is an unsigned integer value indicating the length
of the associated ATM address in octets.
The [STL] is a one octet 'Subaddress Type & Length' field.
Format is the same as the [NTL] field. Defines the length of the
subaddress field, if it exists. If it does not exist this entire
octet field MUST be zero. If the subaddress exists it will be in
AESA format, so flag x SHALL be zero.
[ATM Number] is a variable length field. It is always present.
[ATM Subaddress] is a variable length field. It may or may not be
present. When it is not, the option ends after the [ATM Number] (or
any additional padding for 8 byte alignment).
5.3 Link-Local Addresses
The IPv6 link-local address is formed by appending the interface
token, as defined above, to the prefix FE80::/64.
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Token |
+----------+-----------------------+----------------------------+
6. Flow Detection
The relationship between IPv6 packet flows, Quality of Service
guarantees, and optimal use of underlying IP and ATM 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 ATM network resources through the
establishment of inter-LL shortcuts. The definition of what
constitutes a 'flow' is outside the scope of this document.
In the future, accurate mapping of IPv6 flows onto ATM level 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
Armitage, et al. Expires January 22nd, 1998 [Page 19]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
extended to include new TLV options (see section 4.6 of RFC 1790
[7]). However, if new options are required, the specification of
these options must be co-ordinated with the IPNG working group. Since
RFC 1790 specifies that nodes must silently ignore options they do
not understand, new options can be added at any time without breaking
backward compatability with existing implementations.
NHRP also provides mechanisms for adding optional TLVs to NHRP
Requests and NHRP Replies. Future developments of this document's
IPv6/ATM architecture will require consistent QoS extensions to both
ND and NHRP in order to ensure they are semantically equivalent
(syntactic differences are also undesirable, but can be tolerated).
7. Conclusion and Open Issues.
This document provides an architecture and protocols for supporting
IPv6 over ATM. The proposed solution requires no ATM-specific changes
to the Neighbor Discovery and Router Discovery protocols within hosts
(or routers if a shortcut mechanism is not implemented). No special
protocol is required at all in the hosts to support the use of ATM
level shortcuts. Some extensions to the functionality of a MARS are
required to minimize the VC resource cost associated with
distributing Discovery messages around a Logical Link. Router-
identified IP flows or host indications trigger the discovery of
shortcut paths. It is noted that the IPv6 Router Redirect message is
designed to support the advertisement of new Neighbors in NBMA
environments, and uses the Redirect message in exactly that role.
Router to router NHRP is used to support the discovery of shortcut
routes to Transient Neighbors.
There are a number of open issues, both in general and specific
senses:
- Need to clarify further the conditions under which sources may
ignore a Redirect.
- Need to specify more clearly how a shortcut route may be
invalidated or purged.
- More detailed text is required to provide the specific syntax
mapping between Neighbor Discovery messages and NHRP
Request/Reply packets.
As with all open issues, contributions to the ION mailing list are
solicited (ion@nexen.com).
8. Security Consideration
While this proposal does not introduce any new security mechanisms
all current IPv6 security mechanisms will work without modification
for ATM. This includes both authentication and encryption for both
Neighbor Discovery protocols as well as the exchange of IPv6 data
Armitage, et al. Expires January 22nd, 1998 [Page 20]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
packets. The MARS protocol is modified in a manner that does not
affect or augment the security offered by RFC 2022 in any way.
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/ATM occurred while employed at Bellcore.
Elements of section 5 were borrowed from Matt Crawford's draft on
IPv6 over Ethernet.
Author's address
Grenville Armitage
Bell Laboratories, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
USA
Email: gja@lucent.com
Peter Schulter
BrightTiger Technologies
125 Nagog Park
Acton, MA 01720
Email: paschulter@acm.org
Markus Jork
European Applied Research Center
Digital Equipment Corporation
CEC Karlsruhe
Vincenz-Priessnitz-Str. 1
D-76131 Karlsruhe
Germany
email: jork@kar.dec.com
Geraldine Harter
Digital UNIX Networking
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
Email: harter@zk3.dec.com
References.
[1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC-1883, December 1995.
[2] ATM Forum, "ATM User Network Interface (UNI) Specification
Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs,
NJ, June 1995.
Armitage, et al. Expires January 22nd, 1998 [Page 21]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
[3] M. Crawford, "A Method for the Transmission of IPv6 Packets over
Ethernet Networks", RFC 1972, August 1996.
[4] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaption Layer
5", RFC 1483, USC/Information Science Institute, July 1993.
[5] G.J. Armitage, "Support for Multicast over UNI 3.1 based ATM
Networks", RFC 2022, Bellcore, November 1996.
[6] S. Deering, R. Hinden, "IP Version 6 Addressing Architecture",
RFC-1884, December 1995.
[7] T. Narten, E. Nordmark, W.A. Simpson, "Neighbor Discovery for IP
Version 6 (IPv6)", RFC 1970, August 1996.
[8] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)",
INTERNET DRAFT, draft-ietf-rolc-nhrp-11.txt, March 1997.
[9] S. Thomson, T. Nartin, "IPv6 Stateless Address
Autoconfiguration", RFC 1971, August 1996.
[10] "64-Bit Global Identifier Format Tutorial",
http://standards.ieee.org/db/oui/tutorials/EUI64.html.
[11] Y. Katsube, K. Nagami, H. Esaki, "Toshiba's Router Architecture
Extensions for ATM : Overview", RFC 2098, 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] M. Perez, et al, "ATM Signalling Support for IP over ATM", RFC
1755, February 1995
[14] R. Atkinson, "Default IP MTU for use over ATM AAL5", RFC 1626,
May 1994
[15] J. McCann, et al, "Path MTU Discovery for IP version 6", RFC
1981, August 1996
Armitage, et al. Expires January 22nd, 1998 [Page 22]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
Appendix A. IPv6 Protocol Operation Description
The IPv6 over ATM 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 ATM, 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, ATM 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 ATM address on the LL.
When the local node IPv6/ATM 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 ATM
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 ATM address on the LL.
Armitage, et al. Expires January 22nd, 1998 [Page 23]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
The solicited node's IPv6/ATM 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 VC between the solicited 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 ATM 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 so that they can exchange data over the newly created
PtP VC.
An IPv6 host can also send an Unsolicited Neighbor Advertisement to
the all-nodes multicast address. When the local node IPv6/ATM
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 wil 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/ATM driver gets the JoinLocalGroup
request from the IPv6 Network Layer, it follows the process
described in section 4.2. Joining a Multicast Group.
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/ATM 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 server 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/ATM 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
Armitage, et al. Expires January 22nd, 1998 [Page 24]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
which receive the RA message will process the message as described in
section 4.5 and pass the RA message up to the IPv6 datalink 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 IPv6/ATM 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 PtP 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 ATM address, contained in the
Router Advertisement message's Source Link-Layer Address Option.
If a PtP 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 IPv6/ATM driver, such as
released VCs (see section 4.6. Unicast Data VC Setup and Release)
and the inability to create a VC to a neighbor (see section 4.4.1.
Sending Unicast Data), are detected and handled at the IPv6 Network
Layer, through Neighbor Unreachability Detection. The node IPv6/ATM
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
Armitage, et al. Expires January 22nd, 1998 [Page 25]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
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 IPv6/ATM 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 IPv6/ATM 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 IPv6/ATM 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 [IPV6-
ADDRCONF] 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 IPv6/ATM 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 be sent the message. The IPv6 Network
Armitage, et al. Expires January 22nd, 1998 [Page 26]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
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 [IPV6-ADDRCONF], 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/ATM 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 node's IPv6/ATM driver of the IPv6 host that triggered the
Redirect will receive the encapsulated Redirect over one of it's
PtP VCs. It will the de-encapsulate the packet, and pass the
Redirect message to the IPv6 Network Layer, as described section 4.5.
Armitage, et al. Expires January 22nd, 1998 [Page 27]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
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], 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 ATM 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/ATM driver the IPv6 packet and the link-layer address of
the next-hop node when it sends data to the redirected destination.
The node IPv6/ATM driver will determine if a VC to the next-hop
destination exists. If a PtP VC does not exist, then the IPv6/ATM
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 [IPV6-
ADDRCONF] and [IPV6-DHCP]. 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 configuration mechanisms 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 over the framework described in
Armitage, et al. Expires January 22nd, 1998 [Page 28]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
this document.
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 [IPV6-ADDRCONF] 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 [IPV6-
DHCP].
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 ATM/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
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.
Armitage, et al. Expires January 22nd, 1998 [Page 29]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
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/ATM driver gets the request
from the IPv6 Network Layer to send the packet, it follows the steps
described in section 4.4.2. Sending Multicast Data. 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 and will pass the message up to the IPv6 network
layer. 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 to ATM IPv6/ATM driver the packet and
link-layer address of the DHCPv6 client (obtained through
Neighbor Discovery if necessary). The node IPv6/ATM driver will
then transmit the packet as described in section 4.4.1. This will
result a new PtP VC being created between the server and the client
if one did not previously exist.
The DHCP client's node IPv6/ATM driver will receive the
encapsulated packet from the DHCP Server or Relay Agent, as
described in section 4.5. Receiving Data . 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. An PtP VCwill 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 ATM. 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 ATM LL could
Armitage, et al. Expires January 22nd, 1998 [Page 30]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
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. The
Internet Group Management Protocol (IGMPv6) will continue to work
unmodified over the framework described in this document.
An IPv6 multicast router receives all IPv6 multicast packets on the
LL 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 IPv6/ATM 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. Sending Multicast Data .
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 transmitted to the
MARS server over the PtP VC connecting the mutlicast router to the
MARS server. The MARS server then relays the packet to it's
ClusterControlVC, sending the packet to all nodes in the LL. Each
node's IPv6/ATM drivers will receive the packet from the
ClusterControlVC via it's MARS client. The incoming packet will be
de-encapsulated and passed 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 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/ATM driver
gets the request from the IPv6 Network Layer to send the packet, it
follows the steps described in 4.4.2. Sending Multicast Data.
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-
Armitage, et al. Expires January 22nd, 1998 [Page 31]
Internet Draft draft-ietf-ion-tn-01.txt July 22nd, 1997
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.
Armitage, et al. Expires January 22nd, 1998 [Page 32]