RE: PPP IPV6 Control Protocol Extensions for Prefix
Soohong Daniel Park <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <014d01c3358b$33cb17a0$b7cbdba8@daniel7209> |
Hello all I attach modified draft. By fully discussion, we will be able to decide related drafts to be either RFC or not. Of course this approach is just Informational Track... Regards Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Karl Fox Sent: Wednesday, June 18, 2003 11:56 AM To: James Carlson Cc: [email protected]; 'Bernard Aboba'; [email protected] Subject: RE: PPP IPV6 Control Protocol Extensions for Prefix I believe consensus has emerged on both of these drafts. Please make any final arguments, as I'll be making a statement in a couple of days. Karl On Tue, 2003-06-17 at 16:07, James Carlson wrote: > Glen Zorn writes: > > I think that it would be a good thing, if possible, to raise the level > > of discussion about our draft above the level of blind ideology. I also > > think it would be a good idea if the people making these ideological > > arguments would actually read the document (WINS is not even mentioned > > therein). > > Agreed, but that (omitting WINS) doesn't make this rehash of RFC 1877 > any more acceptable than it was the first time around. Please see the > archives. > > Here's an excerpt from one of the relevant messages: > > From: Craig Fox <[email protected]> > Subject: Re: IPCP negotiation of router, DNS? > To: [email protected] (Andy Stadler) > Date: Fri, 10 Nov 95 15:14:04 PST > Cc: [email protected] > [...] > Microsoft has proposed extensions to negotiate up to two DNS addresses. > There is currently an internet-draft out. I expect that it will become > an informational RFC as it is used by Windows 95 and Windows NT already. > > There has been no discussion, that I can remember, about negotiatiing the > domain info. > > The consensus of the IETF PPP Working Group in the past is that DHCP > should be used to determine the DNS and domain info as well as other > high-level information. > [...] > > Here's what one of the implementors later had to say about RFC 1877: > > From: Gurdeep Singh Pall <[email protected]> > To: "'Ravindra C.P'" <[email protected]>, > "'[email protected]'" > <[email protected]> > Subject: RE: DNS address through IPCP ? > Date: Thu, 3 Jul 1997 10:35:29 -0700 > > Windows 95 and Windows NT use IPCP options to request DNS and WINS > addresses from the peer. This behavior is specified in an informational > document - RFC1877. > > It was agreed at Dallas '95 IETF that implementions should use the new > DHCP-INFORM packet (a stateless configuration request sent after IPCP is > up) to get DNS address and other configuration options. It was also > agreed that this information should be included in the new IPCP i-ds. > > Gurdeep > > PS: Note that the DHCP-INFORM allows just the configuration options to > be retrieved without the IP address. > > My reading of the record is that RFC 1877 was published as > Informational mostly because it had already shipped, not because the > working group agreed that it was the right thing to do. > > Please describe what has changed in the last 8 years that makes > negotiating application-layer details within in the link layer more > acceptable today than it was the last time we discussed this. I'm > looking, but I just don't see it.
PPP IPV6 Control Protocol Extensions for Prefix-0618.txt
(text/plain, 9.6 KB)
Network Working Group S. Daniel Park
Internet-Draft Syam Madanapalli
Expires: December 17, 2003 SAMSUNG
Updates: RFC 2472 June 18, 2003
Category: Informational
Document: draft-park-pppext-ipv6cp-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 Society (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 PPP Network Control Protocol for IPv6
(IPv6CP)[2472] for the negotiation of IPv6 Global-Scope Prefix.
Park, Syam Expires December 2003 [Page 1]
Internet-Draft IPv6CP for Prefix June 2003
1. Introduction
The Point-to-Point Protocol (PPP) [1661] 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.
The PPP Network Control Protocol for IPv6 (IPv6CP) [2472] defines
options for the negotiation of desirable IPv6 parameters. This draft
extends IPv6CP for the negotiation of IPv6 Global-Scope Prefix.
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 [2119].
3. IPv6 Prefix Option
The IPv6 Prefix Configuration Option defines a method for
negotiating the IPv6 Prefix with the remote peer that can be used
on the local end of the link. When a local peer requests an IPv6
Prefix by sending a Configuration-Request with IPv6 Prefix Option,
then the remote peer confirms/specifies the prefix by ACKing or
NAKing this option. In case of Configure-Nack, the remote peer
specifies the new valid IPv6 Prefix.
This IPv6 Prefix Option provides a way to negotiate a unique
global Prefix to be used for the address autoconfiguration [2462]
at the local end of the link. A Configure-Request MUST contain
exactly one instance of the IPv6 Prefix Option.
This IPv6 Prefix Option uses the same packet exchange mechanism
as the Link Control Protocol (LCP).
When sending a Configure-Request, a Node can choose the default
prefix (if it has been configured with any default prefix), the
prefix that was negotiated earlier or a NULL/invalid Prefix.
If a Configure-Request is received with the IPv6 Prefix Option and
the receiving peer does not implement this option, Configure-
Reject is sent. In this case the local node must be configured
using manual mode or DHCPv6 or some other mechanism.
Park, Syam Expires December 2003 [Page 2]
Internet-Draft IPv6CP for Prefix June 2003
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred-lifetime | Valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid-lifetime | Reserved | Prefix-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Prefix |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD
Length: 28 bytes
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.
Park, Syam Expires December 2003 [Page 3]
Internet-Draft IPv6CP for Prefix June 2003
Reserved: Initialized to zero by sending node, Receiving
node ignores this field.
Prefix-length: Length for this Prefix in bits
IPv6-Prefix: A Global-Scope IPv6 Prefix
4. Security Considerations
The IPv6 Control Protocol extension to PPP can be used with all
defined PPP authentication and encryption mechanisms.
(described in [2472]
5. References
Normative
[2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[1661] W. Simpson, Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[2462] Thomson, S., and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Informative
[2472] Haskin, D., E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.
6. Authors' Addresses
Soohong Daniel Park
Mobile Platform Laboratory, SAMSUNG Electronics
Email:[email protected]
Syam Madanapalli
Network Systems Division, SAMSUNG India Software Operations
Email:[email protected]
Park, Syam Expires December 2003 [Page 4]
Internet-Draft IPv6CP for Prefix June 2003
7. 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.
Park, Syam Expires December 2003 [Page 5]