One document matched: draft-ietf-ion-ipv6-ind-02.txt
Differences from draft-ietf-ion-ipv6-ind-01.txt
ION/IPng Working Groups A. Conta (Lucent)
INTERNET-DRAFT R. Duggal (Lucent)
June 1999
Extensions to IPv6 Neighbor Discovery for Inverse Discovery
Specification
draft-ietf-ion-ipv6-ind-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo describes extensions to the IPv6 Neighbor Discovery that
allow a node to solicit and be advertised an IPv6 address
corresponding to a given link-layer address. These extensions are
called Inverse Neighbor Discovery. They specifically apply to Frame
Relay networks but they may also apply to other networks with similar
behavior.
Conta Expires in six months [Page 1]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
Table of Contents
1. Introduction......................................................3
2. Inverse Neighbor Discovery Messages...............................3
2.1 Inverse Neighbor Discovery Solicitation Message...............3
2.2 Inverse Neighbor Discovery Advertisement Message..............5
3. Inverse Neighbor Discovery Options Format.........................7
3.1 Target Address List...........................................7
4. Inverse Neighbor Discovery Protocol...............................8
4.1 Sender Node Processing........................................8
4.2 Receiver Node Processing......................................9
4.2.1 Processing Inverse Neighbor Discovery Solicitations.......9
4.2.2 Processing Inverse Neighbor Discovery Advertisements......9
4.3 Message Validation...........................................10
4.3.1 Validation of Inverse Neighbor Discovery Solicitations...10
4.3.2 Validation of Inverse Neighbor Discovery Advertisements..11
5. Security Considerations..........................................12
6. Acknowledgments..................................................13
7. References.......................................................13
8. Authors' Addresses...............................................15
Appendix A..........................................................16
Conta Expires in six months [Page 2]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
1. Introduction
This document defines extensions to the IPv6 Neighbor Discovery (ND).
The extensions are called IPv6 Inverse Neighbor Discovery (IND). The
IPv6 Inverse Neighbor Discovery (IND) allows a node that knows the
link-layer address of a directly connected remote node to learn the
IPv6 addresses of that node. A node using IND sends solicitations and
receives advertisements for one or more IPv6 addresses corresponding
to a known link-layer address.
The Inverse Neighbor Discovery (IND) specifically applies to Frame
Relay networks. It may apply also to other networks that have a
similar behavior.
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as
defined in [KEYWORDS].
There is a number of similarities and differences between the
mechanisms described here and those defined for Inverse ARP for IPv4
in [INV-ARP] or its replacement documents.
2. Inverse Neighbor Discovery Messages
The following messages are defined:
2.1. Inverse Neighbor Discovery Solicitation Message
A node sends an Inverse Neighbor Discovery Solicitation message to
request an IPv6 address corresponding to a link-layer address of the
target node while also providing its own link-layer address to the
target. Since the remote node IPv6 addresses are not known, Inverse
Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node
multicasts [IPv6], [IPv6-FR], [ENCAPS]. However, at link layer level,
an IND Solicitation is sent directly to the target node, identified
by the known link-layer address.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Conta Expires in six months [Page 3]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
IP Fields:
Source Address
An IPv6 address assigned to the interface from
which this message is sent.
Destination Address
The IPv6 all-node multicast address. This address
is specified in its link-scope format, which is
FF02::1.
Hop Limit 255
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the
destination link-layer address, then the sender
SHOULD include this header.
ICMP Fields:
Type [TBD]
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Required options:
Source Link-Layer Address
The link-layer address of the sender.
Target Link-Layer Address
The link-layer address of the target node.
Conta Expires in six months [Page 4]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
Other valid options:
MTU The MTU configured for this link [IPv6-ND].
Future versions of this protocol may add other option types.
Receivers MUST silently ignore any options they do not recognize and
continue processing the message.
2.2 Inverse Neighbor Discovery Advertisement Message
A node sends Inverse Neighbor Discovery Advertisements in response to
Inverse Neighbor Discovery Solicitations.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
An address assigned to the interface from which the
advertisement is sent.
Destination Address
The Source Address of an invoking Inverse Discovery
Neighbor Solicitation.
Hop Limit 255
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the
destination address, then the sender SHOULD include
this header.
ICMP Fields:
Type [TBD]
Conta Expires in six months [Page 5]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Res(erved) This two bit reserved field MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
O Override flag. When set, the O-bit indicates that
the advertisement should override an existing ND
cache entry and update the cached mapping of the
link-layer address to IPv6 address [ND]. When it is
not set the advertisement will not update a cached
link-layer address to IPv6 address mapping though
it will update an existing Neighbor Cache entry for
which no IPv6 address is known. It SHOULD be set.
Reserved 29-bit unused field. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Required options:
Source Link-Layer Address
This field is copied from the Target link-layer
address field of the Inverse Neighbor Discovery
Solicitation.
Target Link-Layer Address
This field is copied from the Source link-layer
address field of the Inverse Neighbor Discovery
Solicitation.
Target Address List
The list of one or more IPv6 addresses of the
interface identified by the Target Link-Layer
Address in the Inverse Neighbor Discovery
Solicitation message that prompted this
advertisement.
Other valid options:
MTU The MTU configured for this link
[IPv6-ND].
Future versions of this protocol may add other option types.
Conta Expires in six months [Page 6]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
Receivers MUST silently ignore any options they do not recognize and
continue processing the message.
3. Inverse Neighbor Discovery Options Formats
Inverse Neighbor Discovery advertisment messages include Neighbor
Discovery options as well as an Inverse Neighbor Discovery specific
option: the Target Address List.
3.1 Target Address List
The Target Address List option is a TLV (type, length, variable size
field) option, with the following fields:
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
~
|
+-+-+-+-+...
Fields:
Type [TBD]
Conta Expires in six months [Page 7]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
Length The length of the option (including the Type,
Length, and the Reserved fields) in units of 8
octets. The minimum value for Length is 3, for one
IPv6 address.
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver..
IPv6 Addresses One or more IPv6 addresses of the Frame Relay
Interface identified by the Target Link-Layer
Address.
The number of addresses "n" in the list is calculated based on the
length of the option:
n = (Length - 1)/2 (Length is the number of groups of 8 octets)
If the list of IPv6 addresses does not fit in one IND advertisement
message, one or more IND advertisement messages with the same fields
as the first message, MAY follow. The Target Address List option(s)
of the second, and subsequent message(s) contain the rest of the IPv6
addresses of the interface identified by the Target Link-Layer
Address, which did not fit in the first message.
4. Inverse Neighbor Discovery Protocol
IND operates essentially the same as ND [IPv6-ND]: the solicitor of a
target IP address sends on an interface a solicitation message, the
target node responds with an advertisement message containing the
information requested. The information learned may be stored in the
Neighbor Discovery cache [IPv6-ND], as well as IPv6 address
structures which may be associated with the interface.
4.1 Sender Node Processing
A soliciting node formats an IND solicitation message as defined in a
previous section, encapsulates the packet for the specific link-layer
and sends it directly to the target node. Although the destination IP
address is the all-node multicast address, the message is sent only
to the target node. The significant fields for the IND protocol are
the Source IP address, the Source link-layer address, the Target
link-layer address, and the MTU. The latter can be used in setting
the optimum value of the MTU for the link.
While awaiting a response, the sender SHOULD retransmit Neighbor
Conta Expires in six months [Page 8]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
Solicitation messages approximately every RetransTimer
(expiration)[IPv6-ND], even in the absence of additional traffic to
the neighbor. Retransmissions MUST be rate-limited to at most one
solicitation per neighbor every RetransTimer.
If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT
[IPv6-ND] solicitations, inverse address resolution has failed. The
sender MUST return ICMP destination unreachable indications with code
3 (Address Unreachable) for each packet queued awaiting inverse
address resolution. Since the error occurs on the packet originating
node, an implementation is not required to actually create and send
an ICMP error packet to the source, as long as the upper-layer sender
is notified through an appropriate mechanism (e.g. return value from
a procedure call). Note, however, that an implementation may find it
convenient in some cases to return errors to the sender by taking the
offending packet, generating an ICMP error message, and then
delivering it (locally) through the generic error handling routines.
4.2 Receiver Node Processing
4.2.1 Processing Inverse Neighbor Solicitation Messages
For every IND solicitation, the receiving node may format in response
a proper IND advertisement using the link-layer source and target
address pair as well as the IPv6 source address from the IND
solicitation message. If a node is unable or unwilling to advertise,
it ignores the solicitation.
Further, the receiver node of the IND solicitation may put the
sender's IPv6 address/link-layer address mapping - i.e. the source IP
address and the Source link-layer address from the solicitation
message - into its ND cache [IPv6-ND] as it would for a ND
solicitation.
Because IPv6 nodes may have multiple IPv6 addresses per interface, a
node responding to an IND solicitation MUST return in the Target
Address List option a list containing one or more IPv6 addresses
corresponding to the interface identified by the Target Link-Layer
Address field in the solicitation message.
4.2.2 Processing Inverse Neighbor Advertisement Messages
The receiver node of the IND advertisement puts the sender's IPv6
address/link-layer address mapping - i.e. the IP addresses from
Target addresses list and the Source link-layer address from the IND
Conta Expires in six months [Page 9]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
advertisement message - into its ND cache [IPv6-ND] as it would for
a ND advertisement.
4.3 Message Validation
Inverse Neighbor Discovery messages are validated as follows:
4.3.1 Validation of Inverse Neighbor Discovery Solicitations
A node MUST silently discard any received Inverse Neighbor
Solicitation messages that do not satisfy all of the following
validity checks:
- The IP Hop Limit field has a value of 255, i.e., the packet
could not possibly have been forwarded by a router.
- If the message includes an IP Authentication Header, the
message authenticates correctly.
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 24 or more
octets.
- The Target Link-Layer Address is a required option and MUST
be present.
- The Source Link-Layer Address is a required option and MUST
be present.
- All included options have a length that is greater than
zero.
The content of the Reserved field, and of any unrecognized options,
MUST be ignored. Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new options;
Conta Expires in six months [Page 10]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
backward-incompatible changes may use different Code values.
The contents of any Neighbor Discovery [IPv6-ND] options that are not
specified to be used with Inverse Neighbor Discovery Solicitation
messages MUST be ignored and the packet processed as normal. The only
defined option that may appear besides the required options is the
MTU option.
An Inverse Neighbor Solicitation that passes the validity checks is
called a "valid solicitation".
4.3.2 Validation of Inverse Neighbor Discovery Advertisements
A node MUST silently discard any received Inverse Neighbor Discovery
Advertisement messages that do not satisfy all of the following
validity checks:
- The IP Hop Limit field has a value of 255, i.e., the packet
could not possibly have been forwarded by a router.
- If the message includes an IP Authentication Header, the
message authenticates correctly.
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 24 or more
octets.
- Source Link-Layer Address option is present.
- Target Link-Layer Address option is present.
- The Target Address List option is present.
- The length of the Target Address List option is at least 3.
Conta Expires in six months [Page 11]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
- All other included options have a length that is greater
than zero.
The contents of the Reserved fields, and of any unrecognized options,
MUST be ignored. Future, backward-compatible changes to the protocol
may specify the contents of the Reserved fields or add new options;
backward-incompatible changes may use different Code values.
The contents of any defined options [IPv6-ND] that are not specified
to be used with Inverse Neighbor Advertisement messages MUST be
ignored and the packet processed as normal. The only defined option
that may appear besides the required options is the MTU option.
An Inverse Neighbor Advertisement that passes the validity checks is
called a "valid advertisement".
5. Security Considerations
When being employed on point to point virtual circuits, as it is the
case with Frame Relay networks, Inverse Neighbor Discovery messages
are less sensitive to impersonation attacks from on-link nodes, as it
would be the case with broadcast links.
Like Neighbor Discovery, the protocol reduces the exposure to threats
from off-link nodes in the absence of authentication by ignoring IND
packets received from off-link senders. The Hop Limit field of all
received packets is verified to contain 255, the maximum legal value.
Because routers decrement the Hop Limit on all packets they forward,
received packets containing a Hop Limit of 255 must have originated
from a neighbor.
Inverse Neighbor Discovery protocol packet exchanges can be
authenticated using the IP Authentication Header [IPSEC-Auth]. A
node SHOULD include an Authentication Header when sending Inverse
Neighbor Discovery packets if a security association for use with the
IP Authentication Header exists for the destination address. The
security associations may have been created through manual
configuration or through the operation of some key management
protocol.
Received Authentication Headers in Neighbor Discovery packets MUST be
verified for correctness and packets with incorrect authentication
MUST be ignored.
It SHOULD be possible for the system administrator to configure a
node to ignore any Inverse Neighbor Discovery messages that are not
Conta Expires in six months [Page 12]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
authenticated using either the Authentication Header or Encapsulating
Security Payload. Such a switch SHOULD default to allowing
unauthenticated messages.
Confidentiality issues are addressed by the IP Security Architecture
and the IP Encapsulating Security Payload documents [IPSEC], [IPSEC-
ESP].
6. Acknowledgments
Thanks to Steve Deering, Thomas Narten and Eric Nordmark who spent
time discussing the idea of Inverse Neighbor Discovery, and reviewing
this specification. Also thanks to Dan Harrington, Milan Merhar,
Barbara Fox, and Martin Mueller for a thorough reviewing.
7. References
[IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[IPv6-ND] T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[ICMPv6] A. Conta, S. Deering "Internet Control Message Protocol for
the Internet Protocol Version 6", RFC 2463, December 1998.
[IPv6-FR] A. Conta, A. Malis, M. Mueller, "Transmission of IPv6
Packets over Frame Relay networks" Work in Progress, December 1997.
[IPSEC] Atkinson, R., S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[IPSEC-Auth] Atkinson, R., S. Kent, "IP Authentication Header", RFC
2402, December 1998.
[IPSEC-ESP] Atkinson, R., S. Kent, "IP Encapsulating Security
Protocol (ESP)", RFC 2406, November 1998.
[ASSIGN] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700.
Conta Expires in six months [Page 13]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
[ENCAPS] C. Brown, A. Malis, "Multiprotocol Interconnect over Frame
Relay", RFC 2427, November 1998.
[INV-ARP] T. Bradley, C. Brown, A.Malis "Inverse Address Resolution
Protocol",RFC 2390, August 1998
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Conta Expires in six months [Page 14]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
8. Authors' Addresses
Alex Conta
Lucent Technologies Inc.
300 Baker Ave, Suite 100
Concord, MA 01742
+1-978-287-2842
email: aconta@lucent.com
Raj Duggal
Lucent Technologies Inc.
300 Baker Ave, Suite 100
Concord, MA 01742
+1-978-287-2805
email: rduggal@lucent.com
Conta Expires in six months [Page 15]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
Appendix A
A. Inverse Neighbor Discovery with Frame Relay Networks
This appendix documents the details of using the Inverse Neighbor
Discovery on Frame Relay Networks, which were too specific to be part
of the more general content of the previous sections.
A.1 Introduction
The Inverse Neighbor Discovery (IND) specifically applies to Frame
Relay nodes. Frame Relay permanent virtual circuits (PVCs) and
switched virtual circuits (SVCs) are identified in a Frame Relay
network by a Data Link Connection Identifier (DLCI). Each DLCI
defines for a Frame Relay node a single virtual connection through
the wide area network (WAN). A DLCI has in general a local
significance.
By way of specific signaling messages, a Frame Relay network may
announce to a node a new virtual circuit with its corresponding DLCI.
The DLCI identifies to a node a virtual circuit, and can be used as
the equivalent of a remote node link-layer address, allowing a node
to identify at link layer level the node at the other end of the
virtual circuit. For instance in Figure 1., node A (local node)
identifies the virtual circuit to node B (remote node) by way of DLCI
= 50. However, the signaling message does not contain information
about the DLCI used by a remote node to identify the virtual circuit
to the local node, which could be used as the equivalent of the local
link-layer address. For instance in Figure 1., node B (remote node)
may identify the virtual circuit to node A by way of DLCI = 70.
Furthermore, the message being transmitted at link-layer level and
completely independent of the IPv6 protocol does not include any IPv6
addressing information. Therefore it seems to be useful to define a
protocol that allows a Frame Relay node to discover the equivalent of
a local link layer address, that is, the identifier by way of which
remote nodes identify the node, and more importantly discover the
IPv6 addresses of the interface at the other end of the virtual
circuit, identified by the remote link-layer address.
Conta Expires in six months [Page 16]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
~~~~~~~~~~~ Remote
{ } Node
+-----+ DLCI { } DLCI+-----+
| A |-50------{--+----+----+--}---------70-| B |
+-----+ { } +-----+
Local { } Frame Relay
Node ~~~~~~~~~~~ Network Cloud
Figure 1.
The IPv6 Inverse Neighbor Discovery (IND) protocol allows a Frame
Relay node to discover dynamically the DLCI by which a remote node
identifies the virtual circuit. It also allows a node to learn the
IPv6 addresses of a node at the remote end of a virtual circuit.
A.2. Inverse Neighbor Discovery Messages
The Inverse Neighbor Discovery messages are generated by Frame Relay
nodes as follows:
A.2.1. Inverse Neighbor Discovery Solicitation Message
The sender of an Inverse Neighbor Discovery Solicitation does not
know the remote node's IPv6 addresses, but knows the equivalent of a
remote node link-layer address. Inverse Neighbor Discovery (IND)
Solicitations are sent as IPv6 all-node multicasts [IPv6], [IPv6-FR],
[ENCAPS]. However, at link layer level, an IND Solicitation is sent
directly to the target node, identified by the known link-layer
address (DLCI).
The fields of the message which are filled following considerations
specific to Frame Relay are:
Source Link-Layer Address
For the sender Frame Relay node, the Source Link-Layer Address is
the equivalent of the link-layer address by which the remote node
identifies the source of this message. The sender may have no
knowledge of this information, and may leave this field empty.
Therefore prior to any Inverse Neighbor Discovery processing, the
receiver of this message replaces this field, whether filled in or
not by the sender, with information carried by the Frame Relay
header in the DLCI field. The field is encoded in DLCI format as
defined by [IPv6-FR].
Target Link-Layer Address
For sender Frame Relay node, the Target Link-Layer Address field
is filled with the value known as the equivalent of the target
Conta Expires in six months [Page 17]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
node link-layer address. This value is the DLCI of the VC to the
target node. It is encoded in DLCI format [IPv6-FR].
To illustrate the generating of a IND Solicitation message by a Frame
Relay node, let's consider as an example Node A (Figure 1.) which
sends an IND solicitation to Node B. The Solicitation message fields
will have the following values:
At Node A (sender of the IND solicitation message).
Source Link-Layer Address
DLCI=unknown (overwritten by the receiver).
Target Link-Layer Address
DLCI=50.
At Node B (receiver of the IND solicitation message).
Source Link-Layer Address
DLCI=70 (filled in by the receiver).
Target Link-Layer Address
DLCI=50.
Note: For Frame Relay, both the above addresses are in Q.922 format
(DLCI), which can have 10 (default), 17, or 23 significant addressing
bits [IPv6-FR]. The option length (link-layer address) is expressed
in 8 octet units, therefore, the DLCI will have to be extracted from
the 8 bytes based on the EA field (bit 0) of the second, third, or
forth octet (EA = 1). The C/R, FECN, BECN, DE fields in the Q.922
address have no significance for IND and are set to 0 [IPv6-FR].
MTU
The value filled in the MTU option is the MTU for the virtual
circuit identified by the known DLCI [IPv6-FR].
A.2.2 Inverse Neighbor Discovery Advertisement Message
A Frame Relay node sends Inverse Neighbor Discovery Advertisements in
response to Inverse Neighbor Discovery Solicitations.
The fields of the message which are filled following considerations
specific to Frame Relay are:
The "Override" Bit in the message header.
For Frame Relay, the Inverse Neighbor Discovery Advertisement
Conta Expires in six months [Page 18]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
messages unlike the Neighbor Discovery Advertisement messages
carrying DLCI format link-layer addresses, SHOULD have the
Override bit "O", in the message header set to 1.
Source Link-Layer Address
For Frame Relay, this field is copied from the Target link-layer
address field of the Inverse Neighbor Discovery Solicitation. It
is encoded in DLCI format [IPv6-FR].
Target Link-Layer Address
For Frame Relay, this field is copied from the Source link-layer
address field of the Inverse Neighbor Discovery Solicitation. It
is encoded in DLCI format [IPv6-FR].
For example if Node B (Figure 1.) responds to an IND solicitation
sent by Node A. with an IND advertisement, these fields will have the
following values:
At Node B (sender of the advertisement message):
Source Link-Layer Address
DLCI=50 (was Target in Solicitation Message).
Target Link-Layer Address
DLCI=70 (was Source in Solicitation Message).
At Node A (receiver of the advertisement message from B).
Source Link-Layer Address
DLCI=50 (was Target in Solicitation Message).
Target Link-Layer Address
DLCI=70 (was Source in Solicitation Message).
Target Address List
The list of one or more IPv6 addresses of the interface identified
by the Target Link-Layer Address in the Inverse Neighbor Discovery
Solicitation message that prompted this advertisement.
MTU
The MTU configured for this link (virtual circuit) [IPv6-ND].
Note: In case of Frame Relay networks, the IND messages are sent
on a virtual circuit, which acts like a virtual-link. If the
virtual circuit breaks, all participants to the circuit receive
appropriate link layer signaling messages, which can be propagated
to the upper layers, including IPv6.
Conta Expires in six months [Page 19]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
A.3. Inverse Neighbor Discovery Protocol
This section of the appendix documents only the specific aspects of
Inverse Neighbor Discovery with Frame Relay Networks.
A.3.1 Sender Node Processing
A soliciting Frame Relay node formats an IND solicitation message as
defined in a previous section, encapsulates the packet for the Frame
Relay link-layer [IPv6-FR] and sends it to the target Frame Relay
node. Although the destination IP address is the IPv6 all-node
multicast address, the message is sent only to the target Frame Relay
node. The target node is the known remote node on the link
represented by the virtual circuit.
A.3.2 Receiver Node Processing
A.3.2.1 Processing Inverse Neighbor Solicitation Messages
A Frame Relay node, before further processing, is replacing in the
Source link-layer address the existent DLCI value with the DLCI value
from the Frame Relay header of the frame containing the message. The
DLCI value has to be formated appropriately in the Source link-layer
address field [IPv6-FR]. This operation is required to allow a
correct interpretation of the fields in the further processing of the
IND solicitation message.
For a Frame Relay node, the MTU value from the solicitation message
MAY be used to set the receiver's MTU to a value that is more
optimal, in case that was not already done at the interface
configuration time.
A.3.2.2 Processing Inverse Neighbor Advertisement Messages
The receiver Frame Relay node of the IND advertisement puts the
sender's IPv6 address/link-layer address mapping - i.e. the Target IP
addresses and the Source link-layer address from the IND
advertisement message - into its ND cache [IPv6-ND] as it would for
a ND advertisement.
Further, the receiver Frame Relay node of the IND advertisement may
store the Target link-layer address from the message as the DLCI
value at the remote end of the VC. This DLCI value is the equivalent
of the link-layer address by which the remote node identifies the
receiver.
Conta Expires in six months [Page 20]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery June 25, 1999
If the receiver node of the IND advertisement has a pool of IPv6
addresses, and if the implementation allows, it may take decisions to
pairing specific local IPv6 addresses to specific IPv6 addresses from
the target list in further communications on the VC. More
specifically, such a pairing may be based on IPv6 addresses being on
the same subnet.
Conta Expires in six months [Page 21]
1239
| PAFTECH AB 2003-2026 | 2026-04-23 01:30:14 |