draft-ietf-ipngwg-pppext-ipv6cp-00.txt   draft-ietf-ipngwg-pppext-ipv6cp-01.txt 
Internet Engineering Task Force Internet Engineering Task Force
Internet Draft Dimitry Haskin INTERNET-DRAFT Dimitry Haskin
Expires July 1996 Ed Allen Expires August 1996 Ed Allen
<draft-ietf-ipngwg-pppext-ipv6cp-00.txt> Bay Networks, Inc. <draft-ietf-ipngwg-pppext-ipv6cp-01.txt> Bay Networks, Inc.
January 1996 February 1996
IP Version 6 over PPP IP Version 6 over PPP
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at page 5, line 25 skipping to change at page 5, line 25
assigned as follows: assigned as follows:
1 Interface-Token 1 Interface-Token
2 IPv6-Compression-Protocol 2 IPv6-Compression-Protocol
4.1. Interface-Token 4.1. Interface-Token
Description Description
This Configuration Option provides a way to negotiate a unique This Configuration Option provides a way to negotiate a unique
64-bit interface token to be used for the address 48-bit interface token to be used for the address
autoconfiguration [3] at the local end of the link (see section 5). autoconfiguration [3] at the local end of the link (see section 5).
The interface token MUST be unique within the PPP link; i.e. upon The interface token MUST be unique within the PPP link; i.e. upon
completion of the negotiation different Interface-Token values are completion of the negotiation different Interface-Token values are
to be selected for the ends of the PPP link. to be selected for the ends of the PPP link.
Before this Configuration Option is requested, an implementation Before this Configuration Option is requested, an implementation
must choose its tentative Interface-Token. It is recommended that must choose its tentative Interface-Token. It is recommended that
a non-zero value be chosen in the most random manner possible in a non-zero value be chosen in the most random manner possible in
order to guarantee with very high probability that an order to guarantee with very high probability that an
implementation will arrive at a unique token value. A good way to implementation will arrive at a unique token value. A good way to
choose a unique random number is to start with a unique seed. choose a unique random number is to start with a unique seed.
Suggested sources of uniqueness include machine serial numbers, Suggested sources of uniqueness include machine serial numbers,
other network hardware addresses, time-of-day clocks, etc. other network hardware addresses, system clocks, etc. Note that it
Note that it may not be sufficient to use a link-layer address may not be sufficient to use a link-layer address alone as the
alone as the seed, since it will not always be unique. Thus seed, since it will not always be unique. Thus it is suggested
it is suggested that the seed should be calculated from a variety that the seed should be calculated from a variety of sources that
of sources that are likely to be different even on identical are likely to be different even on identical systems and as many
systems and as many sources as possible be used simultaneously. sources as possible be used simultaneously. Good sources of
Good sources of uniqueness or randomness are required for the uniqueness or randomness are required for the Interface-Token
Interface-Token negotiation to succeed. If a good source of negotiation to succeed. If a good source of randomness cannot be
randomness cannot be found, it is recommended that a zero found, it is recommended that a zero value be used for the
value be used for the Interface-Token transmitted in the Interface-Token transmitted in the Configure-Request.
Configure-Request. Note that if at least one of the PPP peers
is able to generate a unique random number, the token negotiation Note that if at least one of the PPP peers is able to generate
will succeed. a unique random number, the token negotiation will succeed.
When a Configure-Request is received with the Interface-Token When a Configure-Request is received with the Interface-Token
Configuration Option and the receiving peer implements this option, Configuration Option and the receiving peer implements this option,
the received Interface-Token is compared with the Interface-Token the received Interface-Token is compared with the Interface-Token
of the last Configure-Request sent to the peer. Depending on the of the last Configure-Request sent to the peer. Depending on the
result of the comparison an implementation MUST respond in one of result of the comparison an implementation MUST respond in one of
the following ways: the following ways:
If the two Interface-Tokens are different, the Interface-Token If the two Interface-Tokens are different, the Interface-Token
MUST be acknowledged, i.e. Configure-Ack is sent with the MUST be acknowledged, i.e. Configure-Ack is sent with the
skipping to change at page 7, line 33 skipping to change at page 7, line 33
Interface-Token for its end of the PPP connection. Interface-Token for its end of the PPP connection.
A summary of the Interface-Token Configuration Option format is A summary of the Interface-Token Configuration Option format is
shown below. The fields are transmitted from left to right. shown below. The fields are transmitted from left to right.
0 1 2 3 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 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-Token | Type | Length | Interface-Token
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Token (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Token (cont) | Interface-Token (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
1 1
Length Length
10 8
Interface-Token Interface-Token
The 64-bit Interface-Token which is very likely to be unique The 48-bit Interface-Token which is very likely to be unique
to one end of the link or zero if a good sources of uniqueness to one end of the link or zero if a good sources of uniqueness
can not be found. can not be found.
Default Default
No Interface-Token is selected. No Interface-Token is selected.
4.2. IPv6-Compression-Protocol 4.2. IPv6-Compression-Protocol
Description Description
This Configuration Option provides a way to negotiate the use of a This Configuration Option provides a way to negotiate the use of
specific compression protocol. The IPv6-Compression-Protocol a specific compression protocol. The IPv6-Compression-Protocol
Configuration Option is used to indicate the ability to receive Configuration Option is used to indicate the ability to receive
compressed packets. Each end of the link must separately request compressed packets. Each end of the link must separately request
this option if bi-directional compression is desired. By default, this option if bi-directional compression is desired. By default,
compression is not enabled. compression is not enabled.
A summary of the IPv6-Compression-Protocol Configuration Option format A summary of the IPv6-Compression-Protocol Configuration Option format
is shown below. The fields are transmitted from left to right. is shown below. The fields are transmitted from left to right.
0 1 2 3 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 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
skipping to change at page 8, line 41 skipping to change at page 8, line 41
Type Type
2 2
Length Length
>= 4 >= 4
IPv6-Compression-Protocol IPv6-Compression-Protocol
The IPv6-Compression-Protocol field is two octets and indicates the The IPv6-Compression-Protocol field is two octets and indicates
compression protocol desired. Values for this field are always the compression protocol desired. Values for this field are always
the same as the PPP Data Link Layer Protocol field values for that the same as the PPP Data Link Layer Protocol field values for that
same compression protocol. same compression protocol.
Up-to-date values of the IPv6-Compression-Protocol field are Up-to-date values of the IPv6-Compression-Protocol field are
specified in the most recent "Assigned Numbers" RFC [5]. specified in the most recent "Assigned Numbers" RFC [5].
Current values are assigned as follows: Current values are assigned as follows:
Value (in hex) Protocol Value (in hex) Protocol
skipping to change at page 9, line 25 skipping to change at page 9, line 25
Default Default
No compression protocol enabled. No compression protocol enabled.
5. Stateless Autoconfiguration and Link-Local Addresses 5. Stateless Autoconfiguration and Link-Local Addresses
The interface token, which is used for forming IPv6 addresses of The interface token, which is used for forming IPv6 addresses of
a PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP a PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP
connection setup (see section 4.1). If no valid interface token has connection setup (see section 4.1). If no valid interface token has
been successfully negotiated, procedures for recovering from such a been successfully negotiated, procedures for recovering from such
case are unspecified. One approach is to manually configure all IPv6 a case are unspecified. One approach is to manually configure
addresses of the interface. the interface token of the interface.
As long as the interface token is negotiated in the IPV6CP phase of
the PPP connection setup, it is redundant to perform duplicate
address detection as a part of the IPv6 Stateless Autoconfiguration
protocol [3]. Therefore it is recommended that for PPP links with
the IPV6CP Interface-Token option enabled the default value of the
DupAddrDetectTransmits autoconfiguration variable [3] be zero.
Link-local addresses of PPP interfaces have the following format: Link-local addresses of PPP interfaces have the following format:
| 10 bits | 16 bits | 38 bits | 64 bits | | 10 bits | 70 bits | 48 bits |
+----------+--------------+----------------+----------------------+ +----------+--------------+----------------+----------------------+
|1111111010| Interface ID | 0 | Interface Token | |1111111010| 0 | Interface Token |
+----------+--------------+----------------+----------------------+ +----------+--------------+----------------+----------------------+
The most significant 10 bits of the address is the Link-Local prefix The most significant 10 bits of the address is the Link-Local prefix
FE80::. Other address fields are as followed: FE80::. 70 zero bits pad out the address between the Link-Local
prefix and the Interface Token fields.
Interface ID - [Robert Elz will provide the text for the
"Interface ID" description].
Interface Token - the 64-bit link-unique interface token.
38 zero bits pad out the address between the Interface ID and the
Interface Token fields.
A. IPV6CP Recommended Options A. IPV6CP Recommended Options
The following Configurations Options are recommended: The following Configurations Options are recommended:
Interface-Token Interface-Token
IPv6-Compression-Protocol IPv6-Compression-Protocol
Security Considerations Security Considerations
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
References References
[1] W. Simpson, "The Point-to-Point Protocol", RFC 1661, July 1994. [1] W. Simpson, "The Point-to-Point Protocol", RFC 1661, July 1994.
[2] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 [2] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6
(IPv6) Specification", Internet Draft. (IPv6) Specification", RFC 1883, December 1995.
[2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
Internet Draft RFC 1884, December 1995.
[3] S. Thomson, T. Narten, "IPv6 Stateless Address [3] S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", Internet Draft Autoconfiguration", Work in progress
[4] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery for IP [4] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery for
Version 6 (IPv6)", Internet Draft IP Version 6 (IPv6)", Work in progress
[5] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700, [5] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700,
October 1994. October 1994.
Acknowledgments Acknowledgments
[TBA] This document borrows from the Magic-Number LCP option and as such is
partially based on previous work done by the PPP working group.
Authors' Addresses Authors' Addresses
Dimitry Haskin Dimitry Haskin
Bay Networks, Inc. Bay Networks, Inc.
2 Federal Street 2 Federal Street
Billerica, MA 01821 Billerica, MA 01821
email: dhaskin@baynetworks.com email: dhaskin@baynetworks.com
Ed Allen Ed Allen
 End of changes. 19 change blocks. 
47 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/