As per Relevance of the word different, we have this rfc below:
Network Working Group D.
Request for Comments: 2023 E.
Category: Standards Track Bay Networks, Inc
October 1996
IP Version 6 over
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
The Point-to-Point Protocol (PPP) [1] provides a standard method
encapsulating Network Layer protocol information over point-to-
links. PPP also defines an extensible Link Control Protocol,
proposes a family of Network Control Protocols (NCPs)
establishing and configuring different network-layer protocols
This document defines the method for transmission of IP Version 6 [2]
packets over PPP links as well as the Network Control Protocol (NCP
for establishing and configuring the IPv6 over PPP. It also
the method of forming IPv6 link-local addresses on PPP links
Table of
1. Introduction .......................................... 2
1.1. Specification of Requirements ...................... 2
2. Sending IPv6 Datagrams ................................ 3
3. A PPP Network Control Protocol for IPv6 ............... 3
4. IPV6CP Configuration Options .......................... 4
4.1. Interface-Token ................................... 4
4.2. IPv6-Compression-Protocol.......................... 7
5. Stateless Autoconfiguration and Link-Local Addresses .. 9
A. IPV6CP Recommended Options ............................. 9
Security Considerations ....................................... 10
References .................................................... 10
Acknowledgments ............................................... 10
Authors' Addresses ............................................ 10
Haskin & Allen Standards Track [Page 1]
RFC 2023 IP Version 6 over PPP October 1996
1.
PPP has three main components
1. A method for encapsulating datagrams over serial links
2. A Link Control Protocol (LCP) for establishing, configuring
and testing the data-link connection
3. A family of Network Control Protocols (NCPs) for
and configuring different network-layer protocols
In order to establish communications over a point-to-point link,
end of the PPP link must first send LCP packets to configure and
the data link. After the link has been established and
facilities have been negotiated as needed by the LCP, PPP must
NCP packets to choose and configure one or more network-
protocols. Once each of the chosen network-layer protocols has
configured, datagrams from each network-layer protocol can be
over the link
In this document, the NCP for establishing and configuring the IPv
over PPP is referred as the IPv6 Control Protocol (IPV6CP).
The link will remain configured for communications until explicit
or NCP packets close the link down, or until some external
occurs (power failure at the other end, carrier drop, etc.).
1.1. Specification of
In this document, several words are used to signify the
of the specification. These words are often capitalized
MUST This word, or the adjective "required", means that
definition is an absolute requirement of the specification
MUST NOT This phrase means that the definition is an
prohibition of the specification
SHOULD This word, or the adjective "recommended", means that
may exist valid reasons in particular circumstances
ignore this item, but the full implications must
understood and carefully weighed before choosing
different course
MAY This word, or the adjective "optional", means that
item is one of an allowed set of alternatives.
implementation which does not include this option MUST
Haskin & Allen Standards Track [Page 2]
RFC 2023 IP Version 6 over PPP October 1996
prepared to inter-operate with another implementation
does include the option
2. Sending IPv6
Before any IPv6 packets may be communicated, PPP must reach
Network-Layer Protocol phase, and the IPv6 Control Protocol
reach the Opened state
Exactly one IPv6 packet is encapsulated in the Information field
PPP Data Link Layer frames where the Protocol field indicates
hex 0057 (Internet Protocol Version 6).
The maximum length of an IPv6 packet transmitted over a PPP link
the same as the maximum length of the Information field of a PPP
link layer frame. PPP links supporting IPv6 must allow at least 576
octets in the information field of a data link layer frame
3. A PPP Network Control Protocol for IPv
The IPv6 Control Protocol (IPV6CP) is responsible for configuring
enabling, and disabling the IPv6 protocol modules on both ends of
point-to-point link. IPV6CP uses the same packet exchange
as the Link Control Protocol (LCP). IPV6CP packets may not
exchanged until PPP has reached the Network-Layer Protocol phase
IPV6CP packets received before this phase is reached should
silently discarded
The IPv6 Control Protocol is exactly the same as the Link
Protocol [1] with the following exceptions
Data Link Layer Protocol
Exactly one IPV6CP packet is encapsulated in the Information
of PPP Data Link Layer frames where the Protocol field
type hex 8057 (IPv6 Control Protocol).
Code
Only Codes 1 through 7 (Configure-Request, Configure-Ack
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-
and Code-Reject) are used. Other Codes should be treated
unrecognized and should result in Code-Rejects
Haskin & Allen Standards Track [Page 3]
RFC 2023 IP Version 6 over PPP October 1996
IPV6CP packets may not be exchanged until PPP has reached
Network-Layer Protocol phase. An implementation should be
to wait for Authentication and Link Quality Determination to
before timing out waiting for a Configure-Ack or other response.
is suggested that an implementation give up only after
intervention or a configurable amount of time
Configuration Option
IPV6CP has a distinct set of Configuration Options, which
defined below
4. IPV6CP Configuration
IPV6CP Configuration Options allow negotiation of desirable IPv
parameters. IPV6CP uses the same Configuration Option format
for LCP [1], with a separate set of Options. If a
Option is not included in a Configure-Request packet, the
value for that Configuration Option is assumed
Up-to-date values of the IPV6CP Option Type field are specified
the most recent "Assigned Numbers" RFC [5]. Current values
assigned as follows
1 Interface-
2 IPv6-Compression-
4.1. Interface-
This Configuration Option provides a way to negotiate a
32-bit interface token to be used for the
autoconfiguration [3] at the local end of the link (see
5). The interface token MUST be unique within the PPP link; i.e
upon completion of the negotiation different Interface-
values are to be selected for the ends of the PPP link
Before this Configuration Option is requested, an
must choose its tentative Interface-Token. It is recommended
a non-zero value be chosen in the most random manner possible
order to guarantee with very high probability that
implementation will arrive at a unique token value. A good way
choose a unique random number is to start with a unique seed
Suggested sources of uniqueness include machine serial numbers
Haskin & Allen Standards Track [Page 4]
RFC 2023 IP Version 6 over PPP October 1996
other network hardware addresses, system clocks, etc. Note that
may not be sufficient to use a link-layer address alone as
seed, since it will not always be unique. Thus it is
that the seed should be calculated from a variety of sources
are likely to be different even on identical systems and as
sources as possible be used simultaneously. Good sources
uniqueness or randomness are required for the Interface-
negotiation to succeed. If a good source of randomness cannot
found, it is recommended that a zero value be used for
Interface-Token transmitted in the Configure-Request. In
case the PPP peer may provide a valid non-zero Interface-Token
its response as described below. Note that if at least one of
PPP peers is able to generate a unique random number, the
negotiation will succeed
When a Configure-Request is received with the Interface-
Configuration Option and the receiving peer implements
option, the received Interface-Token is compared with
Interface-Token of the last Configure-Request sent to the peer
Depending on the result of the comparison an implementation
respond in one of the following ways
If the two Interface-Tokens are different but the
Interface-Token is zero, a Configure-Ack is sent with a non-
Interface-Token value suggested for use by the remote peer.
a suggested Interface-Token MUST be different from the Interface
Token of the last Configure-Request sent to the peer
If the two Interface-Tokens are different and the
Interface-Token is not zero, the Interface-Token MUST
acknowledged, i.e. a Configure-Ack is sent with the
Interface-Token, meaning that the responding peer agrees with
Interface-Token requested
If the two Interface-Tokens are equal and are not zero,
Configure-Nak MUST be sent specifying a different non-
Interface-Token value suggested for use by the remote peer
If the two Interface-Tokens are equal to zero, the Interface
Tokens negotiation MUST be terminated by transmitting
Configure-Reject with the Interface-Token value set to zero.
this case a unique Interface-Token can not be negotiated
If a Configure-Request is received with the Interface-
Configuration Option and the receiving peer does not
this option, Configure-Rej is sent
Haskin & Allen Standards Track [Page 5]
RFC 2023 IP Version 6 over PPP October 1996
A new Configure-Request SHOULD NOT be sent to the peer
normal processing would cause it to be sent (that is, until
Configure-Nak is received or the Restart timer runs out).
A new Configure-Request MUST NOT contain the Interface-
option if a valid Interface-Token Configure-Reject is received
Reception of a Configure-Nak with a suggested Interface-
different from that of the last Configure-Nak sent to the
indicates a unique Interface-Token. In this case a
Configure-Request MUST be sent with the token value suggested
the last Configure-Nak from the peer. But if the
Interface-Token is equal to the one sent in the last Configure
Nak, a new Interface-Token MUST be chosen. In this case, a
Configure-Request SHOULD be sent with the new
Interface-Token. This sequence (transmit Configure-Request
receive Configure-Request, transmit Configure-Nak,
Configure-Nak) might occur a few times, but it is
unlikely to occur repeatedly. More likely, the Interface-
chosen at either end will quickly diverge, terminating
sequence
If negotiation about the Interface-Token is required, and the
did not provide the option in its Configure-Request, the
SHOULD be appended to a Configure-Nak. The tentative value of
Interface-Token given must be acceptable as the remote Interface
Token; i.e. should be different from the token value selected
the local end of the PPP link. The next Configure-Request
the peer may include this option. If the next Configure-
does not include this option the peer MUST NOT send
Configure-Nak with this option included. It should assume that
peer's implementation does not support this option
By default, an implementation SHOULD attempt to negotiate
Interface-Token for its end of the PPP connection
Haskin & Allen Standards Track [Page 6]
RFC 2023 IP Version 6 over PPP October 1996
A summary of the Interface-Token Configuration Option format
shown below. The fields are transmitted from left to right
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 | Interface-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Token (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
6
Interface-
The 32-bit Interface-Token which is very likely to be unique
the link or zero if a good source of uniqueness can not be found
Default Token
If no valid interface token can be successfully negotiated,
default Interface-Token value should be assumed. The
for recovering from such a case are unspecified. One approach
to manually configure the interface token of the interface
4.2. IPv6-Compression-
This Configuration Option provides a way to negotiate the use of
specific IPv6 packet compression protocol. The IPv6-Compression
Protocol Configuration Option is used to indicate the ability
receive compressed packets. Each end of the link must
request this option if bi-directional compression is desired.
default, compression is not enabled
IPv6 compression negotiated with this option is specific to IPv
datagrams and is not to be confused with compression
from negotiations via Compression Control Protocol (CCP),
potentially effect all datagrams
Haskin & Allen Standards Track [Page 7]
RFC 2023 IP Version 6 over PPP October 1996
A summary of the IPv6-Compression-Protocol Configuration
format is shown below. The fields are transmitted from left
right
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 | IPv6-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
2
>= 4
IPv6-Compression-
The IPv6-Compression-Protocol field is two octets and
the compression protocol desired. Values for this field
always the same as the PPP Data Link Layer Protocol field
for that same compression protocol
Up-to-date values of the IPv6-Compression-Protocol field
specified in the most recent "Assigned Numbers" RFC [5].
Current values are assigned as follows
Value (in hex)
004f IPv6 Header
The Data field is zero or more octets and contains additional
as determined by the particular compression protocol
No IPv6 compression protocol enabled
Haskin & Allen Standards Track [Page 8]
RFC 2023 IP Version 6 over PPP October 1996
5. Stateless Autoconfiguration and Link-Local
The interface token, which is used for forming IPv6 addresses of
PPP interface, SHOULD be negotiated in the IPV6CP phase of the
connection setup (see section 4.1). If no valid interface token
been successfully negotiated, procedures for recovering from such
case are unspecified. One approach is to manually configure
interface token of the interface
As long as the interface token is negotiated in the IPV6CP phase
the PPP connection setup, it is redundant to perform
address detection as a part of the IPv6 Stateless
protocol [3]. Therefore it is recommended that for PPP links
the IPV6CP Interface-Token option enabled the default value of
DupAddrDetectTransmits autoconfiguration variable [3] be zero
Link-local addresses of PPP interfaces have the following format
| 10 bits | 86 bits | 32 bits |
+----------+--------------+---------------------+-----------------+
|1111111010| 0 | Interface Token |
+----------+--------------+---------------------+-----------------+
The most significant 10 bits of the address is the Link-Local
FE80::. 86 zero bits pad out the address between the Link-
prefix and the Interface Token fields
A. IPV6CP Recommended
The following Configurations Options are recommended
Interface-
IPv6-Compression-
Haskin & Allen Standards Track [Page 9]
RFC 2023 IP Version 6 over PPP October 1996
Security
Security issues are not discussed in this memo
[1] Simpson, W., "The Point-to-Point Protocol", STD 51, RFC 1661,
July 1994.
[2] Deering, S., and R. Hinden, Editors, "Internet Protocol
Version 6 (IPv6) Specification", RFC 1883, December 1995.
[2] Hinden, R., and S. Deering, "IP Version 6
Architecture", RFC 1884, December 1995.
[3] Thomson, S., and T. Narten, "IPv6 Stateless
Autoconfiguration", RFC 1971, August 1996.
[4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
for IP Version 6 (IPv6)", RFC 1970, August 1996.
[5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
1700, October 1994.
This document borrows from the Magic-Number LCP option and as such
partially based on previous work done by the PPP working group
Authors'
Dimitry
Bay Networks, Inc
2 Federal
Billerica, MA 01821
email: dhaskin@baynetworks.
Ed
Bay Networks, Inc
2 Federal
Billerica, MA 01821
email: eallen@baynetworks.
Haskin & Allen Standards Track [Page 10]
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
