分享
 
 
 

RFC2023 - IP Version 6 over PPP

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group D. HaSKIN

Request for Comments: 2023 E. Allen

Category: Standards Track Bay Networks, Inc.

October 1996

IP Version 6 over PPP

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Abstract

The Point-to-Point Protocol (PPP) [1] provides a standard method of

encapsulating Network Layer protocol information over point-to-point

links. PPP also defines an extensible Link Control Protocol, and

proposes a family of Network Control Protocols (NCPs) for

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 specifies

the method of forming IPv6 link-local addresses on PPP links.

Table of Contents

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

1. Introduction

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 establishing

and configuring different network-layer protocols.

In order to establish communications over a point-to-point link, each

end of the PPP link must first send LCP packets to configure and test

the data link. After the link has been established and optional

facilities have been negotiated as needed by the LCP, PPP must send

NCP packets to choose and configure one or more network-layer

protocols. Once each of the chosen network-layer protocols has been

configured, datagrams from each network-layer protocol can be sent

over the link.

In this document, the NCP for establishing and configuring the IPv6

over PPP is referred as the IPv6 Control Protocol (IPV6CP).

The link will remain configured for communications until eXPlicit LCP

or NCP packets close the link down, or until some external event

occurs (power failure at the other end, carrier drop, etc.).

1.1. Specification of Requirements

In this document, several Words are used to signify the requirements

of the specification. These words are often capitalized.

MUST This word, or the adjective "required", means that the

definition is an absolute requirement of the specification.

MUST NOT This phrase means that the definition is an absolute

prohibition of the specification.

SHOULD This word, or the adjective "recommended", means that there

may exist valid reasons in particular circumstances to

ignore this item, but the full implications must be

understood and carefully weighed before choosing a

different course.

MAY This word, or the adjective "optional", means that this

item is one of an allowed set of alternatives. An

implementation which does not include this option MUST be

prepared to inter-operate with another implementation which

does include the option.

2. Sending IPv6 Datagrams

Before any IPv6 packets may be communicated, PPP must reach the

Network-Layer Protocol phase, and the IPv6 Control Protocol must

reach the Opened state.

Exactly one IPv6 packet is encapsulated in the Information field of

PPP Data Link Layer frames where the Protocol field indicates type

hex 0057 (Internet Protocol Version 6).

The maximum length of an IPv6 packet transmitted over a PPP link is

the same as the maximum length of the Information field of a PPP data

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 IPv6

The IPv6 Control Protocol (IPV6CP) is responsible for configuring,

enabling, and disabling the IPv6 protocol modules on both ends of the

point-to-point link. IPV6CP uses the same packet exchange mechanism

as the Link Control Protocol (LCP). IPV6CP packets may not be

exchanged until PPP has reached the Network-Layer Protocol phase.

IPV6CP packets received before this phase is reached should be

silently discarded.

The IPv6 Control Protocol is exactly the same as the Link Control

Protocol [1] with the following exceptions:

Data Link Layer Protocol Field

Exactly one IPV6CP packet is encapsulated in the Information field

of PPP Data Link Layer frames where the Protocol field indicates

type hex 8057 (IPv6 Control Protocol).

Code field

Only Codes 1 through 7 (Configure-Request, Configure-Ack,

Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack

and Code-Reject) are used. Other Codes should be treated as

unrecognized and should result in Code-Rejects.

Timeouts

IPV6CP packets may not be exchanged until PPP has reached the

Network-Layer Protocol phase. An implementation should be prepared

to wait for Authentication and Link Quality Determination to finish

before timing out waiting for a Configure-Ack or other response. It

is suggested that an implementation give up only after user

intervention or a configurable amount of time.

Configuration Option Types

IPV6CP has a distinct set of Configuration Options, which are

defined below.

4. IPV6CP Configuration Options

IPV6CP Configuration Options allow negotiation of desirable IPv6

parameters. IPV6CP uses the same Configuration Option format defined

for LCP [1], with a separate set of Options. If a Configuration

Option is not included in a Configure-Request packet, the default

value for that Configuration Option is assumed.

Up-to-date values of the IPV6CP Option Type field are specified in

the most recent "Assigned Numbers" RFC[5]. Current values are

assigned as follows:

1 Interface-Token

2 IPv6-Compression-Protocol

4.1. Interface-Token

Description

This Configuration Option provides a way to negotiate a unique

32-bit interface token to be used for the address

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 completion of the negotiation different Interface-Token

values are to be selected for the ends of the PPP link.

Before this Configuration Option is requested, an implementation

must choose its tentative Interface-Token. It is recommended that

a non-zero value be chosen in the most random manner possible in

order to guarantee with very high probability that an

implementation will arrive at a unique token value. A good way to

choose a unique random number is to start with a unique seed.

Suggested sources of uniqueness include machine serial numbers,

other network hardware addresses, system clocks, etc. Note that it

may not be sufficient to use a link-layer address alone as the

seed, since it will not always be unique. Thus it is suggested

that the seed should be calculated from a variety of sources that

are likely to be different even on identical systems and as many

sources as possible be used simultaneously. Good sources of

uniqueness or randomness are required for the Interface-Token

negotiation to succeed. If a good source of randomness cannot be

found, it is recommended that a zero value be used for the

Interface-Token transmitted in the Configure-Request. In this

case the PPP peer may provide a valid non-zero Interface-Token in

its response as described below. Note that if at least one of the

PPP peers is able to generate a unique random number, the token

negotiation will succeed.

When a Configure-Request is received with the Interface-Token

Configuration Option and the receiving peer implements this

option, the received Interface-Token is compared with the

Interface-Token of the last Configure-Request sent to the peer.

Depending on the result of the comparison an implementation MUST

respond in one of the following ways:

If the two Interface-Tokens are different but the received

Interface-Token is zero, a Configure-Ack is sent with a non-zero

Interface-Token value suggested for use by the remote peer. Such

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 received

Interface-Token is not zero, the Interface-Token MUST be

acknowledged, i.e. a Configure-Ack is sent with the requested

Interface-Token, meaning that the responding peer agrees with the

Interface-Token requested.

If the two Interface-Tokens are equal and are not zero, a

Configure-Nak MUST be sent specifying a different non-zero

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 the

Configure-Reject with the Interface-Token value set to zero. In

this case a unique Interface-Token can not be negotiated.

If a Configure-Request is received with the Interface-Token

Configuration Option and the receiving peer does not implement

this option, Configure-Rej is sent.

A new Configure-Request SHOULD NOT be sent to the peer until

normal processing would cause it to be sent (that is, until a

Configure-Nak is received or the Restart timer runs out).

A new Configure-Request MUST NOT contain the Interface-Token

option if a valid Interface-Token Configure-Reject is received.

Reception of a Configure-Nak with a suggested Interface-Token

different from that of the last Configure-Nak sent to the peer

indicates a unique Interface-Token. In this case a new

Configure-Request MUST be sent with the token value suggested in

the last Configure-Nak from the peer. But if the received

Interface-Token is equal to the one sent in the last Configure-

Nak, a new Interface-Token MUST be chosen. In this case, a new

Configure-Request SHOULD be sent with the new tentative

Interface-Token. This sequence (transmit Configure-Request,

receive Configure-Request, transmit Configure-Nak, receive

Configure-Nak) might occur a few times, but it is extremely

unlikely to occur repeatedly. More likely, the Interface-Tokens

chosen at either end will quickly diverge, terminating the

sequence.

If negotiation about the Interface-Token is required, and the peer

did not provide the option in its Configure-Request, the option

SHOULD be appended to a Configure-Nak. The tentative value of the

Interface-Token given must be acceptable as the remote Interface-

Token; i.e. should be different from the token value selected for

the local end of the PPP link. The next Configure-Request from

the peer may include this option. If the next Configure-Request

does not include this option the peer MUST NOT send another

Configure-Nak with this option included. It should assume that the

peer's implementation does not support this option.

By default, an implementation SHOULD attempt to negotiate the

Interface-Token for its end of the PPP connection.

A summary of the Interface-Token Configuration Option format is

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-Token

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Interface-Token (cont)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

1

Length

6

Interface-Token

The 32-bit Interface-Token which is very likely to be unique on

the link or zero if a good source of uniqueness can not be found.

Default Token Value

If no valid interface token can be successfully negotiated, no

default Interface-Token value should be assumed. The procedures

for recovering from such a case are unspecified. One approach is

to manually configure the interface token of the interface.

4.2. IPv6-Compression-Protocol

Description

This Configuration Option provides a way to negotiate the use of a

specific IPv6 packet compression protocol. The IPv6-Compression-

Protocol Configuration Option is used to indicate the ability to

receive compressed packets. Each end of the link must separately

request this option if bi-directional compression is desired. By

default, compression is not enabled.

IPv6 compression negotiated with this option is specific to IPv6

datagrams and is not to be confused with compression resulting

from negotiations via Compression Control Protocol (CCP), which

potentially effect all datagrams.

A summary of the IPv6-Compression-Protocol Configuration Option

format is 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 IPv6-Compression-Protocol

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data ...

+-+-+-+-+

Type

2

Length

>= 4

IPv6-Compression-Protocol

The IPv6-Compression-Protocol field is two octets and indicates

the compression protocol desired. Values for this field are

always the same as the PPP Data Link Layer Protocol field values

for that same compression protocol.

Up-to-date values of the IPv6-Compression-Protocol field are

specified in the most recent "Assigned Numbers" RFC[5].

Current values are assigned as follows:

Value (in hex) Protocol

004f IPv6 Header Compression

Data

The Data field is zero or more octets and contains additional data

as determined by the particular compression protocol.

Default

No IPv6 compression protocol enabled.

5. Stateless Autoconfiguration and Link-Local Addresses

The interface token, which is used for forming IPv6 addresses of 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

been successfully negotiated, procedures for recovering from such a

case are unspecified. One approach is to manually configure 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:

10 bits 86 bits 32 bits

+----------+--------------+---------------------+-----------------+

1111111010 0 Interface Token

+----------+--------------+---------------------+-----------------+

The most significant 10 bits of the address is the Link-Local prefix

FE80::. 86 zero bits pad out the address between the Link-Local

prefix and the Interface Token fields.

A. IPV6CP Recommended Options

The following Configurations Options are recommended:

Interface-Token

IPv6-Compression-Protocol

Security Considerations

Security issues are not discussed in this memo.

References

[1] Simpson, W., "The Point-to-Point Protocol", STD 51, RFC1661,

July 1994.

[2] Deering, S., and R. Hinden, Editors, "Internet Protocol,

Version 6 (IPv6) Specification", RFC1883, December 1995.

[2] Hinden, R., and S. Deering, "IP Version 6 Addressing

Architecture", RFC1884, December 1995.

[3] Thomson, S., and T. Narten, "IPv6 Stateless Address

Autoconfiguration", RFC1971, August 1996.

[4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery

for IP Version 6 (IPv6)", RFC1970, August 1996.

[5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC

1700, October 1994.

Acknowledgments

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

Dimitry Haskin

Bay Networks, Inc.

2 Federal Street

Billerica, MA 01821

email: dhaskin@baynetworks.com

Ed Allen

Bay Networks, Inc.

2 Federal Street

Billerica, MA 01821

email: eallen@baynetworks.com

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有