PANA Working Group L. Morand
Internet-Draft France Telecom R&D
Intended status: Informational R. Maglione
Expires: March 18, 2007 Telecom Italia
J. Kaippallimalil
Huawei Technologies
A. Yegin
Samsung
September 14, 2006
Application of PANA framework to DSL networks
draft-morand-pana-panaoverdsl-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on March 18, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides guidelines for PANA deployment over DSL access
networks. The document specifically describes the introduction of
PANA in DSL networks migrating from a traditional PPP access model to
Morand, et al. Expires March 18, 2007 [Page 1]
Internet-Draft PANA over DSL networks September 2006
a pure IP-based access environment.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. PANA Framework Overview . . . . . . . . . . . . . . . . . . . 3
5. PANA in DSL environment . . . . . . . . . . . . . . . . . . . 4
5.1. Evolution of DSL Environment . . . . . . . . . . . . . . . 4
5.2. Advisability of Introducing PANA in DSL Environment . . . 5
6. Applicability of PANA to IP Session based DSL Environment . . 7
6.1. Functional Architecture . . . . . . . . . . . . . . . . . 7
6.1.1. Location of PAA and EP . . . . . . . . . . . . . . . . 7
6.1.2. Location of the PaC . . . . . . . . . . . . . . . . . 8
6.2. IP Address Configuration . . . . . . . . . . . . . . . . . 9
6.3. PANA and Dynamic ISP Selection . . . . . . . . . . . . . . 10
6.3.1. Selection as Part of the DHCP protocol or an
Attribute of DSL Access Line . . . . . . . . . . . . . 11
6.3.2. Selection as Part of the PANA Authentication . . . . . 11
6.4. Cryptographic Protection . . . . . . . . . . . . . . . . . 11
6.5. Example of Basic Flows . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Morand, et al. Expires March 18, 2007 [Page 2]
Internet-Draft PANA over DSL networks September 2006
1. Introduction
PANA (Protocol for carrying Authentication for Network Access) design
provides support for various types of deployments. DSL networks were
identified as a typical example of such a deployment. This document
provides guidelines for PANA deployment over DSL access networks.
The document specifically describes the introduction of PANA in DSL
networks migrating from a traditional PPP access model to a pure IP-
based access environment. In such environment, additional
authentication mechanisms are required to provide a complete secure
network access solution to Network Access Providers (NAP) willing to
overtake inadequate methods such as basic DSL link-layer
identification or application-layer ad-hoc authentication mechanisms
(e.g., HTTP redirects with web-based login).
2. Specification of Requirements
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 [RFC2119].
3. Terminology
This document uses the PANA terminology defined in
[I-D.ietf-pana-pana].
This document uses the DSL Forum terminology defined in [TR25],
[TR59] and [WT146].
4. PANA Framework Overview
PANA (Protocol for carrying Authentication for Network Access) is a
link-layer agnostic transport for EAP [RFC3748] to enable network
access authentication between clients and access networks.
The motivation to define such a protocol and the requirements are
described in [RFC4058]. Protocol details are documented in
[I-D.ietf-pana-pana]. There are components that are part of a
complete secure network access solution but are outside of the PANA
protocol specification, including IP address configuration,
authentication method choice, filter rule installation, data traffic
protection, PAA-EP protocol and PAA discovery. These components
except for IP address configuration (see Appendix A of
[I-D.ietf-pana-pana]) are described in separate documents (see
[I-D.ietf-pana-framework], [I-D.ietf-pana-snmp] and
[I-D.ietf-dhc-paa-option].
Morand, et al. Expires March 18, 2007 [Page 3]
Internet-Draft PANA over DSL networks September 2006
Figure 1 illustrates the functional entities involved in the PANA
framework and the interfaces (protocols, APIs) among them. See
[I-D.ietf-pana-pana] and [I-D.ietf-pana-framework] for further
details.
RADIUS/
Diameter/
+-----+ PANA +-----+ LDAP/ API +-----+
| PaC |<----------------->| PAA |<---------------->| AS |
+-----+ +-----+ +-----+
^ ^
| |
| +-----+ |
IKE/ +-------->| EP |<--------+ SNMP/ API
4-way handshake +-----+
Figure 1: PANA Functional Model
PaC: PANA Client
PAA: PANA Authentication Agent
AS: Authentication Server
EP: Enforcement Point
PANA design provides support for various types of deployments. DSL
networks were identified as a typical example of such a deployment
(see Appendix A of [RFC4058]).
5. PANA in DSL environment
5.1. Evolution of DSL Environment
Traditional DSL deployments followed the architectural guidelines
provided in [TR25] or [TR59]. Theses architectures use ATM to
aggregate the access networks into a regional broadband network. The
traffic aggregated from the access nodes (DSLAM) is steered to an IP
node, the Broadband Remote Access Server (BRAS). In this
environment, PPP sessions are set-up between the CPN (Customer
Premises Network) and the BRAS, which acts as either a PPP
termination point or a L2TP Access Concentrator (LAC) tunnelling
multiple subscriber PPP sessions directly to an Internet/Corporate
Service Provider. The CPN is usually defined as the combination of
the DSL Modem/RG, acting as the termination point of the physical DSL
signal, and the subscriber's computers and other devices (named hosts
hereafter) connected to the DSL Modem/RG.
Morand, et al. Expires March 18, 2007 [Page 4]
Internet-Draft PANA over DSL networks September 2006
Host--+ +-- ISP1
| DSL link |
+-- DSL Modem/RG --- DSLAM --- BRAS --+-- ISP2
| |
Host--+ +-- ISP3
<-------- CPN --------> <------ NAP ------> <-- ISP -->
Figure 2: DSL Model
The devices at the customer premises have been shown as "hosts" in
the above network.
DSL architectures are now emerging from a "low" speed best effort
delivery network to an infrastructure capable of supporting higher
subscriber bit rates. At the application layer, DSL service
providers are looking to support enhanced services layered on top of
basic Internet access, including entertainment video services
(Broadcast TV and VoD), video conferencing, VoIP, gaming, and
business class services (e.g. IP VPN), that have prohibitive
requirements to deploy them in a pure ATM based environment. Moving
to on a Gigabit Ethernet instead of an ATM aggregation network offers
an highly efficient transport technology for delivering large amounts
of bandwidth to a highly distributed access node topology.
In this evolution path towards Giga Ethernet, there is in parallel a
growing interest in migrating from the traditional PPP access model
to one relying on an network access control of IP sessions
establishment. The "IP Sessions" model is a concept introduced in
DSL Forum that covers a cycle consisting of IP session Detection and
creation, application of IP session policies, and IP session
termination. Details of this work are documented in [WT146].
Basically, an IP session represents subscriber IP traffic which is
associated with a subscriber's IP address parameters. A subscriber
may have multiple IP addresses (or sessions) in simultaneous use. An
IP session may in turn be associated with multiple IP flows. The
relation between subscribers and policies associated with it are
described in [WT134]. The policy relationships in this document show
that subscribers have services that are governed by policies. Thus,
the same subscriber policies govern all IP sessions/flows belonging
to the subscriber.
5.2. Advisability of Introducing PANA in DSL Environment
Among other challenges for DSL environment migrating from pure PPP
based networks, one is the need for the creation of an IP session
subscriber authentication model to secure network access and IP
address management provided by a DHCP infrastructure. Indeed,
Morand, et al. Expires March 18, 2007 [Page 5]
Internet-Draft PANA over DSL networks September 2006
contrary to PPP environment, an IP sessions model has no built-in
mechanisms for authentication purposes in a DHCP based environment.
Hence additional mechanisms are required to provide Network Access
Providers (NAP) with an explicit access authentication solution.
Providing a native support of EAP frames over IP, PANA is therefore a
natural candidate to provide the protocol support of an IP subscriber
authentication model. Moreover, PANA provides functionalities
fulfilling basic and advanced security requirements within an IP
session based environment (as described in [WT146]) , such as:
o IP address based session management mechanisms, using an explicit
session identifier;
o Authentication mechanism independent of the physical medium type;
o Per-session enforcement policies (i.e. filters) depending on the
creation and deletion of the PANA session;
o Session keep-alive and session monitoring functionalities.
In this new context for DSL networks, PANA may be introduced to
authenticate the credentials of a user prior to the setup of an IP
session. The user selects the service provider and authenticates
itself. During IP session setup, policies for the use of connection
resources related to the IP session are established in the BRAS.
These policies govern the subscriber's use of network resources. IP
flows are accounted for and associated with the IP session and the
service session that triggered it.
Some examples to illustrate use cases for PANA in the DSL IP Session
model are given below:
o A user has an intelligent terminal (e.g. smart phone) that is able
to provide both voice and data services. In this case, the user
has subscribed two services e.g. VoIP and Internet. Following a
PANA authentication, an IP session is created based on the single
IP address allocated to the terminal. However it is possible to
distinguish two distinct IP flows within the same IP session, one
for each service, and the accounting policy may be different for
theses two flows. The service provider is therefore able to
associate the accounting records to each flow within the same IP
session in order to bill the two services according to the
subscribed rates.
o A user has subscribed to two services in addition to Internet
access e.g. VoIP and IP TV. Each of these services has a
Morand, et al. Expires March 18, 2007 [Page 6]
Internet-Draft PANA over DSL networks September 2006
dedicated host associated with it. The hosts authenticate on
behalf of the subscriber. After successful multiple PANA
authentications (one per host), a distinct IP address is allocated
to each of these hosts. Thus, there are at this point three IP
sessions related to the same IP subscriber. The VoIP and IP TV
flows may be provided a differentiated level of quality.
Corresponding accounting records and their association with the
service sessions need to be maintained for billing and settlement.
o A user starts a session in one network, authenticates using PANA
and starts using a network service. At some point in time, the
user moves to another network (i.e., continues the session in
another network). In this case, there are two IP sessions (that
results subsequent to PANA authentication in first network, and
PANA authentication in second network) used during the course of
the same service session. Accounting (in the service provider)
should be able to associate the flows related to the two IP
sessions (from different networks) with the same service session.
6. Applicability of PANA to IP Session based DSL Environment
6.1. Functional Architecture
6.1.1. Location of PAA and EP
In a PPP based environment, the BRAS is in charge of interfacing with
CPE for authenticating and authorizing them for the network access
service as well as performing policy control by acting as en
enforcement point. In an IP session based environment, such
functionalities may be provided at the same level by locating the PAA
and EP entities in the BRAS. One advantage provided by this
implementation is to preserve a improved and well-established DSL
network configuration. Moreover, PAA and EP being collocated, there
is no need to rely on an external interface between them to carry the
authorized client attributes i.e. filters, an API being sufficient in
that case. However, it is possible to have PAA and BRAS/EP not
collocated, as described in [I-D.ietf-pana-framework]. In that
specific case, a PAA-BRAS interface may be based on SNMP (see
[I-D.ietf-pana-snmp]) or on the future ANCP protocol (see charter of
the ANCP IETF Working Group [www.ietf.org/html.charters/
ancp-charter.html]).
In such a configuration, the PAA will have to verify the credentials
provided by a PaC located in the CPN and authorize network access to
the host associated with the client and identified by a Device
Identifier (DI).
Morand, et al. Expires March 18, 2007 [Page 7]
Internet-Draft PANA over DSL networks September 2006
As described in [WT146], the subscriber IP address is the main mean
of classifying and managing an IP subscriber session. Therefore,
despite the fact that a link-layer identifier (e.g. MAC address) may
be used in some cases, the subscriber IP address will have to be the
Device Identifier (DI) used in PANA by PAA/EP as a handle to control
and police the network access.
The host in CPN that can be authenticated by the PAA, and therefore
where the PaC should be implemented, will be determined by the
operation mode of the DSL Modem/RG, which may act as either a Layer-2
Ethernet bridge (Bridged Mode) or a Layer-3 IP router (Routed Mode).
6.1.2. Location of the PaC
6.1.2.1. Bridged Mode
In the Bridged mode, the DSL Modem/RG acts as a simple link-layer
bridge. The DSL Modem/RG is here transparent at the IP layer. The
hosts (e.g. PC) connected to the DSL Modem/RG in the CPN and the
BRAS are then on the same IP link. Hosts may have a statically
configured IP address or obtain an IP address from a DHCP server
through the DSLAM (acting as a DHCP-Relay agent) and the BRAS
(filtering DHCP requests towards the DHCP server).
In this model, the PaC can be easily implemented in the hosts. Any
host connected to the DSL Modem/RG will be authenticated by the PAA
locating in the BRAS. It is therefore possible to perform a network
access control on a per-host basis, as required by the IP session
model.
Host--+
(PaC) |
+-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP
| (Bridge) (PAA,EP)
Host--+
(PaC)
Figure 3: Bridged Mode
6.1.2.2. Routed Mode
In the Routed mode, the DSL Modem/RG acts as an IP router for the
CPN. In this configuration, only the DSL Modem/RG and BRAS are on
the same IP link. The DSL Modem/RG may have a statically configured
IP address or obtain an IP address from a DHCP server through the
DSLAM (acting as a DHCP-Relay agent) and the BRAS (filtering DHCP
requests towards the DHCP server). Hosts connected to the DSL
Modem/RG may use either (1) either private IP addresses in an IPv4
environment with the DSL Modem/RG implemented a Network Address Port
Morand, et al. Expires March 18, 2007 [Page 8]
Internet-Draft PANA over DSL networks September 2006
Translation (NAPT) function or (2) routable IP addresses if the modem
is an IPv6 router.
In the IPv4 context (1), the simplest method is to implement the PaC
in the DSL Modem/RG. Only the DSL Modem/RG will be authenticated/
authorized by the PAA. All hosts at the customer premises will then
have access to the service provider's network using private IP
addresses obtained from the DSL Modem/RG.
(NOTE: Per-host authentication may be achieve also in the Routed mode
if the EP function is performed by the DSL Modem/RG. However it is
for further studies to see how to introduce such a configuration in
the global DSL Forum "IP Sessions" model.)
In the IPv6 case (2), the BRAS will detect any new IP address used by
the DSL Modem/RG and the hosts connected to the DSL Modem/RG if they
use an non-local IP address. To allow a suitable network access
rights management based on the IP address, PANA clients will have to
be therefore implemented in the DSL Modem/RG and the hosts. As in
the Bridged Mode, the network access control is also performed on a
per-host basis, in addition to the handling of the DSL Modem/RG 's
own IP sessions.
Host--+
|
+-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP
| (Router, PaC) (PAA,EP)
Host--+
IPv4 Case (1)
Host--+
(PaC) |
+-- DSL Modem/RG --- DSLAM --- BRAS ----- ISP
| (Router, PaC) (PAA,EP)
Host--+
(PaC)
IPv6 Case (2)
Figure 4: Routed Mode
6.2. IP Address Configuration
As described in [I-D.ietf-pana-framework], the PaC MUST obtain an IP
address prior to performing PANA-based authentication, called pre-
PANA address (PRPA).
In the context of PANA deployment in DSL environment based on the IP
Sessions model, the PRPA MAY be configured by the following methods:
Morand, et al. Expires March 18, 2007 [Page 9]
Internet-Draft PANA over DSL networks September 2006
1. The PaC MAY be statically configured with an IP address. This
address is therefore used as a PRPA.
2. The PaC MAY dynamically configure the PRPA using DHCPv4 [RFC2131]
or DHCPv6 [RFC3315].
3. In IPv6, the PaC MAY also configure non-link-local address(es)
using IPv6 stateless auto-configuration [RFC2461] if router
advertisements with prefixes are made available.
(NOTE: PANA supports also hosts using IPv4 link-local addresses
[RFC3927] as PRPA. However, at this time, it is not clear if such IP
address configuration is supported in the DSL Forum "IP Sessions"
model.)
After a successful authentication, the PaC MAY have to configure a
new IP address for communication with other nodes if the PRPA is a
local-use (e.g., a link-local or private address) or a temporarily
allocated IP address. This IP address is called a post-PANA address
(POPA). An operator might choose allocating a POPA only after
successful PANA authorization either to prevent waste of premium
(e.g., globally routable) IP resources until the PaC is authorized
(especially in the IPv4 case), or to enable PaC identity based
address assignment. POPA can be configured using DHCP [RFC2131]
[RFC3315] or using IPv6 stateless auto-configuration [RFC2461].
See Appendix A of [I-D.ietf-pana-pana] for further details on IP
address configuration.
6.3. PANA and Dynamic ISP Selection
In some installations, a BRAS is shared by multiple service
providers. Each service provider configures the BRAS with a specific
IP address space.
The hosts at the customer premises network indicate their choice of
service provider and the BRAS chooses the IP address from the
appropriate service provider's pool. In many cases, the address is
assigned not by the BRAS but by the AAA server that is managed fully
by the service provider.
This simplifies the management of the DSL access network as it is not
always necessary to configure each DSL access line with the service
provider's identity. The service provider is chosen dynamically by
the DSL Modem/RG. This is typically known as "dynamic Internet
Service Provider selection". The AAA function is usually overloaded
to perform dynamic ISP selection.
Morand, et al. Expires March 18, 2007 [Page 10]
Internet-Draft PANA over DSL networks September 2006
6.3.1. Selection as Part of the DHCP protocol or an Attribute of DSL
Access Line
The ISP selection, therefore the IP address pool, can be conveyed
based on the DHCP protocol exchange using, e.g., the 'client-id'
field of a DHCP packet, or by associating the DSL access line to the
service provider before the PANA authentication begins. When any of
these schemes is used, the IP address used during PANA authentication
(PRPA) is the ultimate IP address and it does not have to be changed
upon successful authorization.
6.3.2. Selection as Part of the PANA Authentication
The ISP selection of the client can be explicitly conveyed during the
PANA authentication (see "Network Selection" in
[I-D.ietf-pana-pana]). In that case, the client can be assigned a
temporary IP address (PRPA) prior to PANA authentication. This IP
address might be obtained via DHCP with a lease reasonably long to
complete PANA authentication, or via stateless auto-configuration.
In either case, successful PANA authentication signalling prompts the
client to obtain a new (long term) IP address via DHCP. This new IP
address (POPA) replaces the previously allocated temporary IP
address.
6.4. Cryptographic Protection
DSL networks are protected by physical means. Eavesdropping and
spoofing attacks are prevented by keeping the unintended users
physically away from the network media. Therefore, generally
cryptographic protection of data traffic is not common.
Nevertheless, if enhanced security is deemed necessary for any
reason, IPsec-based access control can be enabled on DSL networks as
well by using the method described in [I-D.ietf-pana-ipsec].
6.5. Example of Basic Flows
The following flows are provided for illustration. In the proposed
use case, PANA clients are implemented in hosts connected to a DSL
Modem/RG acting as an Ethernet bridge (which is therefore transparent
at the IP layer). IP addresses are configured using DHCP. DSL
network operator allocates temporary IP addresses (e.g. private IPv4
addresses) until hosts are authenticated. After a successful
authentication, hosts have to configure a new IP address for
communication with other nodes.
Morand, et al. Expires March 18, 2007 [Page 11]
Internet-Draft PANA over DSL networks September 2006
Host BRAS DHCP Auth. Acct.
(PaC) (PAA/EP) Server Server Server
| | | | |
| 1.DHCP Discover | | |
|------------->|2.DHCP Discover| | |
| |-------------->| | |
| |3.DHCP Offer (PRPA) | |
| |<--------------| | |
|4.DHCP Offer(PRPA) | | |
|<-------------| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+ |
| PANA Authentication Phase | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+ |
| 5.DHCP Discover | | |
|------------->| 6.DHCP Discover | |
| |-------------->| | |
| | 7.DHCP Offer (POPA) | |
| |<--------------| | |
| 7.DHCP Offer(POPA) | | |
|<-------------| | | |
+-+-+-+-+-+-+-+-+-+-+ | | |
| PaC Updating | | | |
| IP Address | | | |
+-+-+-+-+-+-+-+-+-+-+ | | |
| | 8. ACR(START) | |
| |------------------------------------------->|
| | 9. ACA | |
| |<-------------------------------------------|
| | | | |
| | | | |
| | | | |
Disconnection | | | |
=================X | | |
| | 10. ACR(STOP) | |
| |------------------------------------------->|
| | 11. ACA | |
| |<-------------------------------------------|
| | | | |
Figure 5: Basic Flows
The host performs a DHCP procedure to configure an IP address that
will be used as PRPA.
After configuration of the IP address, a PANA authentication
procedure is performed between the host and the BRAS, that
involves here a remote authentication server . This phase may be
initiated either by the host or the BRAS detecting the use of the
Morand, et al. Expires March 18, 2007 [Page 12]
Internet-Draft PANA over DSL networks September 2006
PRPA. For further details, see [I-D.ietf-pana-pana].
Following a successful authentication/authorization, the
Authentication server passes any relevant service parameters for
this subscriber IP session.
The BRAS authorizes therefore the creation of the PANA session and
creates an IP Session context for that subscriber. The user
service policy is applied to the IP session.
As a temporary IP address was used as PRPA, the host performs a
new DHCP procedure to configure a permanent IP address (aka POPA).
When configured, the PaC notifies the PAA about the change of
address and the BRAS updates the IP Session context with this new
IP address. For further details, see [I-D.ietf-pana-pana].
The BRAS should start accounting at this stage (using for instance
Accounting Request (ACR) START and Accounting Answer (ACA) over a
Diameter interface with a remote accounting server).
When the user disconnects (L2 indication) or if there is an
explicit PANA session termination request, the IP Session is
terminated and accounting of the IP Session is stopped.
7. Security Considerations
The DSL infrastructure that connects the CPE to the DSLAM/BRAS is
assumed to run over a physically-secured non-shared media. For that
reason, neither the use of a key-generating EAP method nor a secure
L2/L3 channel bootstrapped by PANA is required. The current DSL
deployments are satisfied by using non-key-generating client-only
authentication methods (e.g., CHAP and its EAP equivalent EAP-MD5).
The same model can be maintained even with the PANA-based
deployments. If next generation deployments prefer key-generating
mutual authentication methods, they can be naturally used with PANA
too.
8. References
8.1. Normative References
[I-D.ietf-dhc-paa-option]
Kumar, S., "DHCP options for PANA Authentication Agents",
draft-ietf-dhc-paa-option-04 (work in progress),
September 2006.
Morand, et al. Expires March 18, 2007 [Page 13]
Internet-Draft PANA over DSL networks September 2006
[I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for
Network Access (PANA)", draft-ietf-pana-pana-12 (work in
progress), August 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
8.2. Informative References
[I-D.ietf-pana-framework]
Jayaraman, P., "Protocol for Carrying Authentication for
Network Access (PANA) Framework",
draft-ietf-pana-framework-07 (work in progress),
August 2006.
[I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA Enabling IPsec based Access
Control", draft-ietf-pana-ipsec-07 (work in progress),
July 2005.
[I-D.ietf-pana-snmp]
Mghazli, Y., "SNMP usage for PAA-EP interface",
draft-ietf-pana-snmp-06 (work in progress), June 2006.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang,
"Protocol for Carrying Authentication for Network Access
(PANA) Requirements", RFC 4058, May 2005.
Morand, et al. Expires March 18, 2007 [Page 14]
Internet-Draft PANA over DSL networks September 2006
[TR25] DSL Forum TR-025, "Core Network Architecture for Access to
Legacy Data Network over ADSL", September 1999.
[TR59] DSL Forum TR-059, "DSL Evolution - Architecture
Requirements for the Support of QoS-Enabled IP Services",
September 2003.
[WT134] DSL Forum WT-134 Draft Version 1.0, "Policy Control
Framework for DSL", April 2006.
[WT146] DSL Forum WT-146 Draft Version 1.0, "IP Sessions",
February 2006.
Authors' Addresses
Lionel Morand
France Telecom R&D
38-40 rue du general Leclerc
92794 Issy-Les-Moulineaux Cedex 9
France
Phone: +33 1 45296257
Email: lionel.morand@orange-ft.com
Roberta Maglione
Telecom Italia
Via G. Reiss Romoli 274
10148 Torino,
Italy
Email: mario.ullio@telecomitalia.it
John Kaippallimalil
Huawei Technologies
1700 Alma Drive, Suite 100
Plano, TX,
USA
Phone: +1 972 509 5599
Email: jkaippal@huawei.com
Morand, et al. Expires March 18, 2007 [Page 15]
Internet-Draft PANA over DSL networks September 2006
Alper E. Yegin
Samsung
Email: alper01.yegin@partner.samsung.com
Morand, et al. Expires March 18, 2007 [Page 16]
Internet-Draft PANA over DSL networks September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Morand, et al. Expires March 18, 2007 [Page 17]