This section describes node operations for performing basic functions (such as sending and receiving data) on a Logical Link. The application of these basic functions to the operation of the various IPv6 protocols such as Neighbor Discovery is described in Appendix A.
The majority of this section applies only to NBMA networks when used to provide point to point and point to multipoint SVCs.
Before a node can send or receive IPv6 datagrams its underlying IPv6/NBMA interface(s) must first join a Logical Link.
An IPv6/NBMA driver SHALL establish a pt-pt VC to the MARS associated with its Logical Link, and register as a Cluster Member [5]. The node's IPv6/NBMA interface will then be a member of the LL, have a Cluster Member ID (CMI) assigned, and can begin supporting IPv6 and IPv6 ND operations.
The encapsulation mechanism for, and key field values of, MARS control messages shall be defined in companion documents specific to particular NBMA network technologies.
This section describes the node's behavior when it gets a JoinLocalGroup request from the IPv6 Layer. The details of how this behavior is achieved are going to be implementation specific. If a JoinLocalGroup for a node-local address is received, the IPv6/NBMA driver shall
return success indication to the caller and take no additional action.
If a JoinLocalGroup is received for an address with greater than node-local scope, the IPv6/NBMA driver shall send an appropriate single group MARS_JOIN request to register this address with the MARS.
If a LeaveLocalGroup for a node-local address is received, the IPv6/NBMA driver shall return success indication to the caller and take no additional action.
If a LeaveLocalGroup is received for an address with greater than node-local scope, the IPv6/NBMA driver shall send an appropriate single group MARS_LEAVE request to deregister this address with the MARS.
Separate processing and encapsulation rules apply for outbound unicast and multicast packets.
The IP level 'next hop' for each outbound unicast IPv6 packet is used to identify a pt-pt VC on which to forward the packet.
For NBMA networks where LLC/SNAP encapsulation is typically used, the IPv6 packet SHALL be
encapsulated with the following LLC/SNAP header and sent over the VC. Otherwise an alternative rule
shall be specified in the NBMA-specific companion document.
If no pt-pt VC exists for the next hop address for the packet, the node shall place a call to set up a VC to the next hop destination.
The sending node should queue the packet that triggered the call request, and send it when the call is established.
If the call to the next hop destination node fails the sending node shall discard the packet that triggered the call setup. At this time no rules are specified for mapping outbound packets to VCs using anything more than the packet's destination address.
The IP level 'next hop' for each outbound multicast IPv6 packet is 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 used, multicast packets
shall be encapsulated. For NBMA networks that do not use LLC/SNAP encapsulation,
an
alternative rule shall be specified in the NBMA-specific companion document.
If the packet's destination is one of the following multicast addresses, it shall be sent over the IPv6/NBMA driver's direct pt-pt VC to the MARS: Solicited-node address with link-local scope, The All-nodes and routers address with link-local scope and A DHCP-v6 relay or server multicast address.
If packet's destination is any other address, then the usual MARS client mechanisms are used by the IPv6/NBMA driver to select and/or establish a pt-mpt VC on which the packet is to be sent.
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 specified in section 4.4.2 shall have their pkt$cmi field compared to the local IPv6/NBMA driver's own CMI. If the pkt$cmi in the header matches the local 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.
For NBMA networks that do not use LLC/SNAP encapsulation, alternative rules shall be
specified in the NBMA-specific companion document.
VC Setup and release for unicast data
Before sending a packet to a new destination within the same LL a 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.
A Redirect message results in the sending (redirected) node creating a new pt-pt VC to a new receiving node. the Redirect message shall contain the link layer (NBMA) address of the new receiving IPv6/NBMA interface. The redirected node will set up a pt-pt 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. Even after the source has reacted to a redirect, the destination will
continue to send IPv6 packets back to the redirected node on the old path.
VCs are released when no longer needed.
NBMA SVC Signaling Support and MTU issues
Mechanisms for signaling the establishment and teardown of pt-pt and pt-mpt SVCs for different NBMA networks shall be specified in companion documents. Since any given IPv6/NBMA driver will not know if the remote end of a VC is in the same LL, drivers shall implement NBMA-specific mechanisms to negotiate acceptable MTUs at the VC level. These mechanisms shall be specified in companion documents.
However, IPv6/NBMA drivers can assume that they will always be talking to another driver attached to the same type of NBMA network.