As per Relevance of the word solicitation, we have this rfc below:
Network Working Group A.
Request for Comments: 3122 Transwitch
Category: Standards Track June 2001
Extensions to IPv6 Neighbor Discovery for Inverse
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This memo describes extensions to the IPv6 Neighbor Discovery
allow a node to determine and advertise an IPv6 address
to a given link-layer address. These extensions are called
Neighbor Discovery. The Inverse Neighbor Discovery (IND)
originally developed for Frame Relay networks, but may also apply
other networks with similar behavior
Conta Standards Track [Page 1]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
Table of
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....................... 6
3.1 Target Address List......................................... 6
4. Inverse Neighbor Discovery Protocol............................. 9
4.1 Sender Node Processing...................................... 9
4.2 Receiver Node Processing.................................... 9
4.2.1 Processing Inverse Neighbor Discovery Solicitations..... 9
4.2.2 Processing Inverse Neighbor Discovery Advertisements... 10
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. IANA Considerations............................................ 13
7. Acknowledgments................................................ 13
8. References..................................................... 13
9. Authors' Addresses............................................. 14
Appendix A........................................................ 15
Full Copyright Statement.......................................... 20
Conta Standards Track [Page 2]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
1.
This document defines extensions to the IPv6 Neighbor
(ND)[IPv6-IND]. The extensions are called IPv6 Inverse
Discovery (IND). The IPv6 Inverse Neighbor Discovery (IND) allows
node that knows the link-layer address of a directly connected
node to learn the IPv6 addresses of that node. A node using
sends solicitations and receives advertisements for one or more IPv
addresses corresponding to a known link-layer address
The Inverse Neighbor Discovery (IND) was originally developed
Frame Relay networks, but may also apply to other networks
similar behavior
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as
in [KEYWORDS].
There are a number of similarities and differences between
mechanisms described here and those defined for Inverse ARP for IPv
in [INV-ARP] or its replacement documents
2. Inverse Neighbor Discovery
The following messages are defined
2.1. Inverse Neighbor Discovery Solicitation
A node sends an Inverse Neighbor Discovery Solicitation message
request an IPv6 address corresponding to a link-layer address of
target node while also providing its own link-layer address to
target. Since the remote node IPv6 addresses are not known,
Neighbor Discovery (IND) Solicitations are sent as IPv6 all-
multicasts [IPv6], [IPv6-FR], [ENCAPS]. However, at link
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 Standards Track [Page 3]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
Source
An IPv6 address assigned to the interface from which this
is sent
Destination
The IPv6 all-node multicast address. This address is specified
its link-scope format, which is FF02::1.
Hop Limit 255
Authentication
If a Security Association for the IP Authentication Header
between the sender and the destination, then the sender
include this header
ICMP Fields
Type 141
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Reserved This field is unused. It MUST be initialized
zero by the sender and MUST be ignored by
receiver
Required options
The sender node MUST send the following options in the
message
Source Link-Layer
The link-layer address of the sender
Target Link-Layer
The link-layer address of the target node
Other valid options
The sender node MAY choose to add the following options in
Solicitation message
Source Address
The list of one or more IPv6 addresses of the interface
by the Source Link-Layer Address. This option is defined
section 3.
Conta Standards Track [Page 4]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
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
continue processing the message
2.2 Inverse Neighbor Discovery Advertisement
A node sends Inverse Neighbor Discovery Advertisements in response
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields
Source
An address assigned to the interface from which the
is sent
Destination
The Source Address of an invoking Inverse Discovery
Solicitation
Hop Limit 255
Authentication
If a Security Association for the IP Authentication Header
between the sender and the destination address, then the
SHOULD include this header
ICMP Fields
Type 142
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Conta Standards Track [Page 5]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
Reserved 32-bit unused field. It MUST be initialized
zero by the sender and MUST be ignored by
receiver
Required options
The sender node MUST send the following options in the
message
Source Link-Layer Address The link-layer address of the sender
Target Link-Layer
The link-layer address of the target, that is, the sender
the advertisement
Target Address
The list of one or more IPv6 addresses of the
identified by the Target Link-Layer Address in the
Neighbor Discovery Solicitation message that prompted
advertisement. This option is defined in Section 3.
Other valid options
The sender node MAY choose to add the following option in
Advertisement message
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
continue processing the message
3. Inverse Neighbor Discovery Options
Inverse Neighbor Discovery messages include Neighbor
options [IPv6-ND] as well as an Inverse Neighbor Discovery
options: the Source Address List and the Target Address List
3.1 Source/Target Address
The Source Address List and the Target Address List option are
options (type, length, variable size field) (see Section 4.6
[IPv6-ND] with the following fields
Conta Standards Track [Page 6]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
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 9 for Source Address
10 for Target Address
Note: These Option Type values should be assigned from the IPv
Neighbor Discovery family of values
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
IPv6 address
Reserved This field is unused. It MUST be initialized
zero by the sender and MUST be ignored by
receiver
IPv6 Addresses One or more IPv6 addresses of the interface
Conta Standards Track [Page 7]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
Description
The Source Address List contains a list of IPv6 addresses of
interface identified by the Source Link-Layer Address
The Target Address List contains a list of IPv6 addresses of
interface identified by the Target Link-Layer Address
The number of addresses "n" in the list is calculated based on
length of the option
n = (Length - 1)/2 (Length is the number of groups of 8 octets
The Source Address List MUST fit in one IND Solicitation message
Therefore in case all IPv6 addresses of an interface do not fit
one messages, the option does not contain a complete list. For
complete list of IPv6 addresses, a node should rely on the
Advertisement message
The Target Address List SHOULD be the complete list of addresses
the interface identified by the Target Link-Layer Address. If
list of IPv6 addresses of an interface does not fit in one
Advertisement message, one or more IND Advertisement messages,
the same fields as the first message, SHOULD follow. The
Address List option(s) of the second, and subsequent message(s
SHOULD contain the rest of the IPv6 addresses of the
identified by the Target Link-Layer Address, which did not fit in
first message
Note 1: The scope of the Inverse Neighbor Discovery mechanism
limited to IPv6 address discovery, that is, providing address
information. Therefore, it does not make any provisions or
regarding how a node uses the addresses that were returned in
Inverse Discovery message. Furthermore, it does not exclude
particular type of IPv6 address from the Source or Target
List. For example, if an interface has manually configured,
autoconfigured addresses, including temporary ones, unicast
multicast, etc..., the list should not exclude any
Note 2: An implementation MUST NOT send duplicates in the IPv
address list
Conta Standards Track [Page 8]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
4. Inverse Neighbor Discovery
IND operates essentially the same as ND [IPv6-ND]: the solicitor of
target IP address sends on an interface a solicitation message,
target node responds with an advertisement message containing
information requested. The information learned MAY be stored in
Neighbor Discovery cache [IPv6-ND], as well as IPv6
structures which may be associated with the interface
4.1 Sender Node
A soliciting node formats an IND Solicitation message as defined in
previous section, encapsulates the packet for the specific link-
and sends it directly to the target node. Although the
IP address is the all-node multicast address, the message is
only to the target node. The significant fields for the IND
are the Source IP address, the Source link-layer address, the
link-layer address, and the MTU. The latter can be used in
the optimum value of the MTU for the link
While awaiting a response, the sender SHOULD retransmit
Solicitation messages approximately every
(expiration)[IPv6-ND], even in the absence of additional traffic
the neighbor. Retransmissions MUST be rate-limited to at most
solicitation per neighbor every RetransTimer
If no IND Advertisement is received after MAX_MULTICAST_
[IPv6-ND] solicitations, inverse address resolution has failed.
the sending of the Solicitation was required by an upper-layer,
sender module MUST notify the error to the upper-layer through
appropriate mechanism (e.g., return value from a procedure call).
4.2 Receiver Node
4.2.1 Processing Inverse Neighbor Solicitation
For every IND Solicitation, the receiving node SHOULD format
response a proper IND Advertisement using the link-layer source
target address pair as well as the IPv6 source address from the
Solicitation message
If a node updates the Neighbor Discovery Cache with
learned from IND messages, the receiver node of the IND
SHOULD put the sender's IPv6 address/link-layer address mapping -
i.e., the source IP address and the Source link-layer address
the solicitation message - into its ND cache [IPv6-ND] as it
for a ND solicitation
Conta Standards Track [Page 9]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
Because IPv6 nodes may have multiple IPv6 addresses per interface,
node responding to an IND Solicitation SHOULD return in the
Address List option a list containing one or more IPv6
corresponding to the interface identified by the Target Link-
Address field in the solicitation message. The list MUST not
duplicates
4.2.2 Processing Inverse Neighbor Advertisement
If a node updates The Neighbor Discovery Cache with
learned from IND messages, the receiver node of the IND
SHOULD put the sender's IPv6 address/link-layer address mapping -
i.e., the IP addresses from Target addresses list and the
link-layer address from the IND advertisement message - into its
cache [IPv6-ND] as it would for a ND advertisement
4.3 Message
Inverse Neighbor Discovery messages are validated as follows
4.3.1 Validation of Inverse Neighbor Discovery
A node MUST silently discard any received Inverse
Solicitation messages that do not satisfy all of the
validity checks
- The IP Hop Limit field has a value of 255, i.e., the
could not possibly have been forwarded by a router
- If the message includes an IP Authentication Header,
message authenticates correctly
- ICMP Checksum is valid
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 24 or
octets
- The Target Link-Layer Address is a required option and
be present
- The Source Link-Layer Address is a required option and
be present
- All included options have a length that is greater
zero
Conta Standards Track [Page 10]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
The content of the Reserved field, and of any unrecognized options
MUST be ignored. Future, backward-compatible changes to the
may specify the contents of the Reserved field or add new options
backward-incompatible changes may use different Code values
The contents of any Neighbor Discovery [IPv6-ND] options that are
specified to be used with Inverse Neighbor Discovery
messages MUST be ignored and the packet processed as normal.
only defined option that may appear besides the required options
the MTU option
An Inverse Neighbor Solicitation that passes the validity checks
called a "valid solicitation".
4.3.2 Validation of Inverse Neighbor Discovery
A node MUST silently discard any received Inverse Neighbor
Advertisement messages that do not satisfy all of the
validity checks
- The IP Hop Limit field has a value of 255, i.e., the
could not possibly have been forwarded by a router
- If the message includes an IP Authentication Header,
message authenticates correctly
- ICMP Checksum is valid
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 48 or
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.
- All other included options have a length that is
than zero
The contents of the Reserved fields, and of any unrecognized options
MUST be ignored. Future, backward-compatible changes to the
may specify the contents of the Reserved fields or add new options
backward-incompatible changes may use different Code values
Conta Standards Track [Page 11]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
The contents of any defined options [IPv6-ND] that are not
to be used with Inverse Neighbor Advertisement messages MUST
ignored and the packet processed as normal. The only defined
that may appear besides the required options is the MTU option
An Inverse Neighbor Advertisement that passes the validity checks
called a "valid advertisement".
5. Security
When being employed on point to point virtual circuits, as it is
case with Frame Relay networks, Inverse Neighbor Discovery
are less sensitive to impersonation attacks from on-link nodes, as
would be the case with broadcast links
Like Neighbor Discovery, the protocol reduces the exposure to
from off-link nodes in the absence of authentication by ignoring
packets received from off-link senders. The Hop Limit field of
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
from a neighbor
Inverse Neighbor Discovery protocol packet exchanges can
authenticated using the IP Authentication Header [IPSEC-Auth].
node SHOULD include an Authentication Header when sending
Neighbor Discovery packets if a security association for use with
IP Authentication Header exists for the destination address.
security associations may have been created through
configuration or through the operation of some key
protocol
Received Authentication Headers in Inverse Neighbor Discovery
MUST be verified for correctness and packets with
authentication MUST be ignored
In case of use with Frame Relay, to avoid an IP
Authentication verification failure, the Frame Relay
preprocessing of a Neighbor Discovery Solicitation message
contains a DLCI format Source link-layer address option, MUST be
by the receiver node after it completed IP Security processing
It SHOULD be possible for the system administrator to configure
node to ignore any Inverse Neighbor Discovery messages that are
authenticated using either the Authentication Header or
Security Payload. Such a switch SHOULD default to
unauthenticated messages
Conta Standards Track [Page 12]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
Confidentiality issues are addressed by the IP Security
and the IP Encapsulating Security Payload documents [IPSEC], [IPSEC
ESP].
6. IANA
IANA was requested to assign two new ICMPv6 type values, as
in Section 2.1 and 2.2. They were assigned from the
range of messages, as defined in Section 2.1 of RFC 2463. There
no ICMPv6 code values defined for these types (other than 0);
assignments are to be made under Standards Action as defined in
2434.
IANA was also requested to assign two new ICMPv6 Neighbor
Option types as defined in Section 3.1. No outside reviewing
necessary
7.
Thanks to Steve Deering, Thomas Narten and Erik Nordmark
discussing the idea of Inverse Neighbor Discovery. Thanks to
Narten, and Erik Nordmark, and also to Dan Harrington, Milan Merhar
Barbara Fox, Martin Mueller, and Peter Tam for a thorough reviewing
Also it should be acknowledged that parts of the text in
specification derived from the IPv6 Neighbor Discovery text [IPv6-
ND].
8.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
[IPv6-ND] Narten, T., Nordmark, E. and W. Simpson "
Discovery for IP Version 6 (IPv6)", RFC 2461,
1998.
[ICMPv6] Conta, A., and S. Deering "Internet Control
Protocol for the Internet Protocol Version 6",
2463, December 1998.
[IPv6-FR] Conta, A., Malis, A. and M. Mueller, "Transmission
IPv6 Packets over Frame Relay Networks", RFC 2590,
1999. December 1997.
[IPSEC] Atkinson, R. and S. Kent, "Security Architecture
the Internet Protocol", RFC 2401, November 1998.
Conta Standards Track [Page 13]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
[IPSEC-Auth] Atkinson, R. and S. Kent, "IP Authentication Header",
RFC 2402, December 1998.
[IPSEC-ESP] Atkinson, R. and S. Kent, "IP Encapsulating
Protocol (ESP)", RFC 2406, November 1998.
[ASSIGN] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, March 1994.
[ENCAPS] Brown, C. and A. Malis, "Multiprotocol
over Frame Relay", RFC 2427, November 1998.
[INV-ARP] Bradley, T., Brown, C. and A. Malis "Inverse
Resolution Protocol", RFC 2390, August 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
9. Authors'
Alex
Transwitch
3 Enterprise
Shelton, CT 06484
Phone: +1-203-929-8810
EMail: aconta@txc.
Conta Standards Track [Page 14]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
Appendix
A. Inverse Neighbor Discovery with Frame Relay
This appendix documents the details of using the Inverse
Discovery on Frame Relay Networks, which were too specific to be
of the more general content of the previous sections
A.1
The Inverse Neighbor Discovery (IND) specifically applies to
Relay nodes. Frame Relay permanent virtual circuits (PVCs)
switched virtual circuits (SVCs) are identified in a Frame
network by a Data Link Connection Identifier (DLCI). Each
defines for a Frame Relay node a single virtual connection
the wide area network (WAN). A DLCI has in general a
significance
By way of specific signaling messages, a Frame Relay network
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
the equivalent of a remote node link-layer address, allowing a
to identify at link layer level the node at the other end of
virtual circuit. For instance in Figure 1., node A (local node
identifies the virtual circuit to node B (remote node) by way of
= 30. However, the signaling message does not contain
about the DLCI used by a remote node to identify the virtual
to the local node, which could be used as the equivalent of the
link-layer address. For instance in Figure 1., node B (remote node
may identify the virtual circuit to node A by way of DLCI = 62.
Furthermore, the message being transmitted at link-layer level
completely independent of the IPv6 protocol does not include any IPv
addressing information. The Inverse Neighbor Discovery is a
that allows a Frame Relay node to discover the equivalent of a
link layer address, that is, the identifier by way of which
nodes identify the node, and more importantly discover the IPv
addresses of the interface at the other end of the virtual circuit
identified by the remote link-layer address
Conta Standards Track [Page 15]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
~~~~~~~~~~~
{ }
+-----+ DLCI { } DLCI+-----+
| A |-30------{--+----+----+--}---------62-| B |
+-----+ { } +-----+
Local { } Frame
Node ~~~~~~~~~~~ Network
Figure 1.
The IPv6 Inverse Neighbor Discovery (IND) protocol allows a
Relay node to discover dynamically the DLCI by which a remote
identifies the virtual circuit. It also allows a node to learn
IPv6 addresses of a node at the remote end of a virtual circuit
A.2. Inverse Neighbor Discovery
Frame Relay nodes generate Inverse Neighbor Discovery messages
follows
A.2.1. Inverse Neighbor Discovery Solicitation
The sender of an Inverse Neighbor Discovery Solicitation does
know the remote node's IPv6 addresses, but knows the equivalent of
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
directly to the target node, identified by the known link-
address (DLCI).
The fields of the message, which are filled following
specific to Frame Relay are
Source Link-Layer
For the sender Frame Relay node, the Source Link-Layer Address
the equivalent of the link-layer address by which the remote
identifies the source of this message. The sender may have
knowledge of this information. If the sender knows
information, it SHOULD include it in the field, otherwise
SHOULD live it zero (empty). This information, if present, can
used for network debugging purposes. Regardless of the sender'
action on this field, prior to any Inverse Neighbor
processing, the receiver of this message replaces this field
whether filled in or not by the sender, with information
by the Frame Relay header in the DLCI field. The field is
in DLCI format as defined by [IPv6-FR].
Conta Standards Track [Page 16]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
Target Link-Layer
For sender Frame Relay node, the Target Link-Layer Address
is filled with the value known as the equivalent of the
node link-layer address. This value is the DLCI of the VC to
target node. It is encoded in DLCI format [IPv6-FR].
To illustrate the generating of a IND Solicitation message by
Frame Relay node, let's consider as an example Node A (Figure 1.)
which sends an IND solicitation to Node B. The
message fields will have the following values
At Node A (sender of the IND solicitation message).
Source Link-Layer
DLCI=unknown (overwritten by the receiver).
Target Link-Layer
DLCI=30.
At Node B (receiver of the IND solicitation message).
Source Link-Layer
DLCI=62 (filled in by the receiver).
Target Link-Layer
DLCI=30.
Note: For Frame Relay, both the above addresses are in Q.922
(DLCI), which can have 10 (default), or 23 significant
bits [IPv6-FR]. The option length (link-layer address) is
in 8 octet units, therefore, the DLCI will have to be extracted
the 8 bytes based on the EA field (bit 0) of the second, third,
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].
The value filled in the MTU option is the MTU for the
circuit identified by the known DLCI [IPv6-FR].
A.2.2 Inverse Neighbor Discovery Advertisement
A Frame Relay node sends Inverse Neighbor Discovery Advertisements
response to Inverse Neighbor Discovery Solicitations
The fields of the message, which are filled following
specific to Frame Relay are
Conta Standards Track [Page 17]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
Source Link-Layer
For Frame Relay, this field is copied from the Target link-
address field of the Inverse Neighbor Discovery Solicitation.
is encoded in DLCI format [IPv6-FR].
Target Link-Layer
For Frame Relay, this field is copied from the Source link-
address field of the Inverse Neighbor Discovery Solicitation.
is encoded in DLCI format [IPv6-FR].
For example if Node B (Figure 1.) responds to an IND
sent by Node A. with an IND advertisement, these fields will have
following values
At Node B (sender of the advertisement message):
Source Link-Layer
DLCI=30 (was Target in Solicitation Message).
Target Link-Layer
DLCI=62 (was Source in Solicitation Message).
At Node A (receiver of the advertisement message from B).
Source Link-Layer
DLCI=30 (was Target in Solicitation Message).
Target Link-Layer
DLCI=62 (was Source in Solicitation Message).
Target Address
The list of one or more IPv6 addresses of the interface
by the Target Link-Layer Address in the Inverse Neighbor
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
on a virtual circuit, which acts like a virtual-link. If
virtual circuit breaks, all participants to the circuit
appropriate link layer signaling messages, which can be
to the upper layers, including IPv6.
A.3. Inverse Neighbor Discovery
This section of the appendix documents only the specific aspects
Inverse Neighbor Discovery with Frame Relay Networks
Conta Standards Track [Page 18]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
A.3.1 Sender Node
A soliciting Frame Relay node formats an IND solicitation message
defined in a previous section, encapsulates the packet for the
Relay link-layer [IPv6-FR] and sends it to the target Frame
node. Although the destination IP address is the IPv6 all-
multicast address, the message is sent only to the target Frame
node. The target node is the known remote node on the
represented by the virtual circuit
A.3.2 Receiver Node
A.3.2.1 Processing Inverse Neighbor Solicitation
A Frame Relay node, before further processing, is replacing in
Source link-layer address the existent DLCI value with the DLCI
from the Frame Relay header of the frame containing the message.
DLCI value has to be formatted appropriately in the Source link-
address field [IPv6-FR]. This operation is required to allow
correct interpretation of the fields in the further processing of
IND solicitation message
For a Frame Relay node, the MTU value from the solicitation
MAY be used to set the receiver's MTU to a value that is
optimal, in case that was not already done at the
configuration time
A.3.2.2 Processing Inverse Neighbor Advertisement
The receiver Frame Relay node of the IND Advertisement MAY put
sender's IPv6 address/link-layer address mapping - i.e., the
IP addresses and the Source link-layer address from the
advertisement message - into its ND cache [IPv6-ND] as it would
a ND Advertisement
Further, the receiver Frame Relay node of the IND Advertisement
store the Target link-layer address from the message as the
value at the remote end of the VC. This DLCI value is the
of the link-layer address by which the remote node identifies
receiver
If the receiver node of the IND Advertisement has a pool of IPv
addresses, and if the implementation allows, it may take decisions
pairing specific local IPv6 addresses to specific IPv6 addresses
the target list in further communications on the VC.
specifically, such a pairing may be based on IPv6 addresses being
the same subnet, that is having the same prefix
Conta Standards Track [Page 19]
RFC 3122 Extensions to IPv6 Neighbor Discovery June 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Conta Standards Track [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
