Internet Engineering Task Force Shin Miyakawa
INTERNET-DRAFT NTT Communications
<draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt>
Expires: December 24, 2002
June 24, 2002
Requirements for IPv6 prefix delegation
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.''
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
The internet-draft will expire in 6 months. The date of expiration will
be December 24, 2002.
Abstract
This document describes requirements about how an IPv6 address prefix
should be delegated to an IPv6 subscriber's network (or "site").
Shin Miyakawa FORMFEED[Page 1]
INTERNET-DRAFT Jun 2002
1. Motivation
With the deployment of IPv6 [Deering, 1998] ,several commercial ISPs
are ready to offer their services to the public in conjunction with
widely deployed IP subscription method such as ADSL and so on. But,
thinking about following situation of IPv6 commercial service as one
of the most likely examples,
IPv6 ISP router
|
| point-to-point link
|
User's Site router
|
----+----- User's Site Network
though it is needed a standardized way to delegate one or more IPv6
address prefix(es) from the IPv6 ISP to the User's site
automatically, it is not identified clearly yet.
Therefore, this documents clarifies requirements for IPv6 address
prefix delegation from the ISP to the site, especially from the
(commercial) ISP point of view to boost IPv6 business quick as
possible.
2. Requirements for prefix delegation management
Focusing commercial IPv6 ISP service, there are several kinds of
category of requirements for the mechanism / protocol to delegate one
or more IPv6 prefixes from ISP to a site.
- layer 2 consideration
The method should work on any layer 2 technologies. In other words,
it should be layer 2 technology independent. Though, at the same
time, it should be noted that now ISP would like to have a solution
for Point-to-Point link which has own authentication mechanism first.
PPP link with CHAP authentication is a good example. (Simulated)
Ethernet and IEEE802.11 (wireless LAN) should be covered in near
future, but they have low priority (just) for now. It should be
clarified that the method should work with all L2 protocols either
with authentication mechanism or without, but ISP would like to take
advantage of a L2 protocol's authentication mechanism if it exits.
- accounting
Shin Miyakawa FORMFEED[Page 2]
INTERNET-DRAFT Jun 2002
It should provides accounting capability such as logging about by
whom, when and what prefix(es) is used for the service with proper
authentication techniques.
- kinds of prefixes
It should be able to delegate both statically and dynamically
assigned prefix assignment by authenticated identification, depended
by resources and/or any reasons.
- negotiation between ISP and site
ISP may deny the service, due to various reasons such as there is no
contract or bad financial credit etc. Also ISP should be able to use
one single technique to pass parameters of the prefix such as scope
(global and/or site), prefix length (/48, /64 or any other length)
and any other appropriate related information to the site. On the
other hand, a site should be able to request multiple prefixes to the
ISP. Also a site should be able to pass parameters of the prefix
such as scope (global and/or site), prefix length (/48, /64 or any
other length), number of prefixes and so on to the ISP to negotiate.
3. References
[RFC2460]
Deering, 1998. S. Deering and R. Hinden, "Internet Protocol, Ver-
sion 6 (IPv6) Specification", RFC2460 (December 1998).
Shin Miyakawa FORMFEED[Page 3]
INTERNET-DRAFT Jun 2002
Acknowledgements
People in Internet Association of Japan have gave me a lot of good input.
Team members of NTT Communications IPv6 project, especially Toshi Yamasaki
and Yasuhiro Shirasaki, gave me quite useful suggestions for this
document. Chairs of IETF IPv6 working group especially Bob Hinden
who gave me a good suggestions before I submitted this draft.
Also communications with other folks in the IPv6 community, such
as WIDE/KAME project, IPv6 and DHCP teams in Cisco systems and so on have
been quite helpful. Thanks a lot.
Shin Miyakawa FORMFEED[Page 4]
INTERNET-DRAFT Jun 2002
Author's address
Shin Miyakawa, Ph.D
Innovative IP Architecture Center, NTT Communications Corporation
Tokyo, Japan
Tel: +81-3-6800-3262
Fax: +81-3-5265-2990
Email: miyakawa@nttv6.jp
Shin Miyakawa FORMFEED[Page 5]