PPP IPV6 Control Protocol Extensions for Prefix
Soohong Daniel Park <soohong.park <at> samsung.com>
2003-06-14 05:23:04 GMT
Hello all
I am wondering if this draft should be discussed as an interesting draft
and
taked at PPPEXT WG. I know most people will not take kindly to making an
"option" mandatory. However the original intent of my draft is to be
processed
with "draft-ietf-pppext-ipv6-dns-addr-02.txt" which is a working item in
PPPEXT WG
simultaneously since this draft is also to provide another option for
[RFC 2472] .
[RFC 2472] said
>4. IPV6CP Configuration Options
> The only IPV6CP options defined in this document are Interface-
> Identifier and IPv6-Compression-Protocol. Any other IPV6CP
> configuration options that can be defined over time are to be
defined
> in separate documents.
I guess we can define extra two options, IPv6 DNS server address Option
and IPv6 Prefix Option
Sometimes local peer want to negotiate and configure each global prefix
of IPv6.
It is still very rough draft and not submitted yet.
It will update [RFC 2472].
I would also encourage any review comments you may have.
Regards
Daniel (Soohong Daniel Park)
Mobile Platform Lab,SAMSUNG Electronics
Network Working Group S. Daniel Park
Internet-Draft SAMSUNG Electronics
Expires: November, 2003 June, 2003
Updates: RFC 2472
Category : Informational
Document : draft-park-pppext-ipv6-prefix-00.txt
PPP IPV6 Control Protocol Extensions for Prefix
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.
Copyright Notice
Copyright (C) The Internet Societyi (2003). All Rights Reserved,
Abstract
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol and a family of Network
Control Protocols (NCPs) for establishing and configuring different
network-layer protocols.
This draft extends the NCP for establishing and configuring IPv6
over PPP, defining the negotiation of IPv6 Global-Scope Prefix.
1. Introduction
The Point-to-Point Protocol (PPP) [2] provides a standard method
for transporting multi-protocol datagrams over point-to-point links.
PPP defines an extensible Link Control Protocol and a family of
Network Control Protocols (NCPs) for establishing and configuring
different network-layer protocols.
This document extends the NCP for establishing and configuring
IPV6 over PPP [7], defining the negotiation of Global-Scope Prefix
for IPv6.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [1].
3. Additional IPV6CP Configuration Option
The IPv6 Prefix Configuration option provides a method of obtaining
the valid IPv6 Global-Scope Prefix on the local IPv6 network.
For implementation convenience, these option is designed to serve
identical purposes, (e.g. existing Prefix is about to be expired,
current Prefix is still only link or site scope not global, current
Prefix in invalid for some reasons from link and local peer,
there is no unique global Prefix on the local link. etc...) except
that when receive a IPv6 Prefix Option, an attempt MUST be made to
compose of IPv6 address using the IPv6 Prefix Option before using
the original IPv6 Prefix.
4. IPv6 Prefix Option
Description
The IPv6 Prefix Option defines a method for negotiating with
the remote peer the IPv6 Prefix to be used on the local end of
the link. If local peer requests an IPv6 Prefix (some reasons in
section 3 will tipicaly occur this option) the remote peer
specifies the address by NAKing this option, and returning the
valid IPv6 Prefix.
This IPv6 Prefix Option provides a way to negotiate a unique
global Prefix to be used for the address autoconfiguration[4]
at the local end of the link. A Configure-Request MUST contain
exactly one instance of the IPv6 Prefix Option. The IPv6 Prefix
MUST be unique within the PPP link.
Before this IPv6 Prefix Option is requested, an implementation
chooses its current IPv6 Prefix or Link-scope Prefix.
When a Configure-Request is received with the IPv6 Prefix Option
and the receiving peer implements this option, the received IPv6
Prefix is compared with the current valid IPv6 Prefix. Depending
on the result of the comparison an implementation MUST respond
in one of the following ways:
If the two IPv6 Prefixs are different. a Configure-Nak is sent
with a valid IPv6 Prefix value suggested for use by the remote
peer. Such a suggested IPv6 Prefix MUST be valid global Prefix.
If the two IPv6 Prefixs are equal and global scope, the IPv6
Prefix MUST be acknowledged, i.e. a Configure-Ack is sent with
the current IPv6 Prefix, meaning that the responding peer agrees
with the IPv6 Prefix requested. Some parameters like preferred-
lifetime, valid-lifetime in this option SHOULD be updated.
If a Configure-Request is received with the IPv6 Prefix 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 IPv6 Prefix option if
a valid IPv6 Prefix Configure-Reject is received.
If negotiation of the IPv6 Prefix is required, and the peer did
not provide the option in its Configure-Request, the option SHOULD
be appended to a Configure-Nak. The invalid value of the IPv6
Prefix given must be acceptable as the remote IPv6 Prefix.
By default, an implementation SHOULD attempt to negotiate the
IPv6 Prefix for its end of the PPP connection.
The format of the IPv6 Prefix option is:
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 | preferred-lifetime(cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
preferred-lifetime | valid-lifetime(cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
valid-lifetime | Prefix-length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| IPv6 Prefix |
| (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD
Length
27
preferred-lifetime: The recommended preferred lifetime for the IPv6
Prefix in the option, expressed in units of
seconds. A value of 0xFFFFFFFF represents
infinity.
valid-lifetime: The valid lifetime for the IPv6 Prefix in the
option, expressed in units of seconds. A value of
0xFFFFFFFF represents infinity.
Prefix-length: Length for this Prefix in bits
IPv6-Prefix: A Global-Scope IPv6 Prefix
5. Security Considerations
The use of these extensions is as secure as the link itself.
(desceibed in [4])
References
Normative
[1] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] W. Simpson, Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[3] Miyakawa, S., "Requirements for IPv6 Prefix delegation",
Internet-Draft, (work in progress), November 2002.
[4] Thomson, S., and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Informative
[5] H. Hiller, "PPP IPV6 Control Protocol Extensions for DNS Server
Addresses", Internet-Draft (work in progress), June 2003.
[6] O. Troan, "IPv6 Prefix Options for DHCPv6", Internet-Draft
(work in progress), November 2002.
[7] Haskin, D., E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.
Author's Address
Soohong Daniel Park
Mobile Platform Laboratory, SAMSUNG Electronics
Email: soohong.park <at> samsung.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RSS Feed