Subject: Re: PANA FAQ

From: Thomas Narten <[email-masked]>
Date: Wed, 15 May 2002 10:33:29 -0400

Apologies for the length, but I think too many of these questions are
just answered with yes/no, which does little to explain to the reader
what PANA is doing.

> PANA FAQ
> =========

> Q1: What is PANA?
> A:  PANA is 
>     - a layer two agnostic network layer messaging protocol for
>       authenticating IP hosts for network access

OK.

>     - a transport protocol for authentication payload (EAP)
>       between a client (IP based) and a server (agent) in the access
>       network.

Might be better to say something like:

a single protocol that all clients can use, regardless of the AAA
infrastructure that may (or may not) reside on the
network. Conceptually, PANA allows clients to interact with the
infrastrcuture AAA, but in a protocol-neutral way that doesn't require
that the client understand the AAA protocols in local use.

> Q2: Does PANA aim to replace link layer authentication?
> A:  No. PANA will complement and/or coexist with link layer
>     authentication mechanisms to enable network layer
> authentication.

Add: PANA may be a substitute for link-layer authentication in
environments where L2 authentication is unavailable (or cannot be
used). There are drawbacks and limitations to this approach, but some
people have indicated that this is still a useful application in some
environments.

> Q3: Do we still need PANA if the link-layer supports authentication?

Add:

A: Sometimes yes, sometimes no.

> A:  It is a common practice to use higher-layer authentication on top
>     of link-layer authentication. For example in 3GPP and 3GPP2, PPP is
>     used for authentication after link-layer authentication succeeds.
>     Or, http-redirect method is used as a higher-layer user
>     authentication in some other network access architectures. Hence
>     even if link-layer authentication exists, PANA is needed in
>     certain scenarios.

add: In some cases, L2 authentication is also used to (implicitely)
authorize IP service. In such environments, PANA may not be useful or
necessary.

> Q4: Access control should always be an L2 function. Does PANA violate
>     the layering principles?

IMO, wrong question.

Q4: Some folk argue that access control can only be done correctly as
     an L2 function. If done at L3, there is no way to protect the L2
     infrastructure from DOS attacks, local (but improper) usage of
     the L2 infrastructure, spoofing a properly athenticated (at L3)
     device, etc.  Is PANA still useful given these concerns?

Who can answer this one?
     
> Q5: Is PANA specifically targeted for mobile/wireless networks?
> A:  No. PANA is applicable for any type of network that requires the
>     host that is attaching to it for access to authenticate itself
>     before being granted access.

Add: note that PANA is specifically also targeted at broadcast links,
as opposed to point-to-point links. This is one reason why PPP is not
deemed adequate.

> Q6: Does PANA deal with mobility?
> A:  No. However mobile IP based networks may use PANA for network
>     access authentication.

I'd go further.

MIPv4 developed its own protocols for performing PANA-like functions
(e.g., MN-FA interaction). MIPv6 does not have a FA and has not (yet)
developed MIP-specific mechanisms for gaining access to a foreign
network. It is expected that PANA would provide such functionality
without the need for a MIP-specific protocol.

Also,

PANA does deal with mobility in the "Road Warrier" sense, where a
traditional client "dials in" to a NAS via PPP. But PPP is oriented
towards point-to-point links, and the same functionality is needed in
broadcast LAN environments (e.g., hotel or airport LANs, etc.)

> Q7: Does PANA introduce new security vulnerabilities as a result of
>     being an L3 solution?
> A:  Requirements for dealing with security issues are part of the
>     charter.

This is a non-answer.

The real answer is yes. There are potential DOS vulnerabilities,
theft-of-service vulnerabilities. This topic should be expanded upon
and better understood. For example, I've heard some folks assert
they'd never deploy something based on PANA unless PANA allowed
sufficient key distribution/derivation mechanisms so that the PANA
Client could use (say) IPsec to encrypt/authenticate all traffic.

> Q8: Does PANA do access control?
> A:  No. PANA enables access control indirectly.

Expand on this please. Most readers won't understand what this means
or how PANA and access control fit together.

> Q9: Does PANA require a AAA protocol/infrastructure in the access
>     network?
> A:  PANA may interact with backend AAA infrastructures such as RADIUS
>     or Diameter. But it is not a requirement.

In those cases where no AAA is used, what is the model? Please expand.

> Q10: What is the PaC and the PAA?
> A:   PaC : PANA Client
>      PAA : PANA Authentication Agent
>      The PaC and PAA are the client and server elements of the
>      protocol.

> Q11: Where is the PAA located in the access network?
> A:   The PAA should be on an IP capable network element on the same
>      subnet as the PaC. Hence it can be on the NAS or WLAN AP or first hop 
>      router.

Hmm. Should != must in my book. What is it? And note, since PANA is an
L3 thing, I would expect the answer to be something like: the PAA
resides on the same IP link as that client (i.e., no IP router between
them)

> Q12: Is PAA always co-located with the enforcement point?
>      It doesn't have to be. When they are separated, there needs to be
>      another transport between two for client provisioning. This 
>      transport is outside the scope of PANA.

This needs more explanation. For example, there  may not even be a
single enforcement point! There has been list discussion in the past
about multiple first-hop routers, with the client able to switch from
one to the other.

I think more text about the model is needed here. I understand that
the enforcement point could be the first hop router(s), or something
between the local domain and the internet. None of this will be
obvious to the reader, but presumably is important to understand.

> Q13: How does the PaC know the address of the PAA?
> A:   Possibilities include:
>      - A discovery mechanism
>      - Multicast or anycast

A: Since the PAA is on the same link/subnet as the PaC, there are
number of techniques that could be used (e.g., multicast or anycast).

> Q14: Does PANA assign the client/host an IP address?
> A:   No. 

A: PANA does not perform any address assignment functions. In
particular, a PaC must obtain an IP address before being able to
invoke PANA functions. See also Q4.

(see also last Q!)

> Q15: What type of authorization does PANA provide?
> A:   It provides only a binary authorization to indicate whether the PaC
>      can access the network or not. It doesn't deal with finer granularity
>      authorization, such as negotiating QoS parameters.

Could be more clear. Suggested reword:

A: It provides only a binary authorization to indicate whether the PaC
   is allowed to access full IP services on the network. It doesn't
   deal with finer granularity authorization, such as negotiating QoS
   parameters, authorizing individual services (http vs. ssh),
   individual users sharing the same device, etc.

> Q16: Is PANA applicable to IPv6 only?
> A:   No. PANA is IP version agnostic in addition to being L2 agnostic.

> Q17: What is the role of EAP in PANA?
> A:   EAP is the authentication protocol for which PANA is the
>      transport.

reword:

A: The current thinking is that a sufficient solution would be for
   PANA to carry EAP (with some possible EAP extensions). The PANA WG
   will not be extending EAP, but may define requirements for an EAP
   WG.

> Q18: Is PANA a client-server or peer-peer protocol?
> A:   PANA is a client-server protocol.

> Q19: Does the PAA know (or need to know) when the PaC has disconnected
>      from the network?
> A:   In some networks it may be required to know when the client has
>      disconnected. This may be accomplished via mechanisms such as
>      heartbeat etc.

This last sentence could be more clear. My suggestion:

A: Some networks do not provide an L2 mechanism to indicate when
     connectivity between the client and PAA has been lost. Such
     notification is desirable in order for the PAA to cleanup
     resources when a client moves away from the network (e.g., inform
     the enforcement points that the client is no longer
     connected). PANA will need to provide a hearbeat-type mechanism
     to provide this functionality. It's usage will be optional,
     depending on the specific L2.

> Q20: Does PANA provide per-packet authentication and encryption?

> A:   No, this is outside the scope of PANA. Though, PANA carries EAP
>      and certain EAP methods generates session keys for this purpose.
>      Therefore PANA is an enabler for per-packet protection. The keys
>      generated can be used with link-layer protection, or network
>      layer protection (IPsec). Generation and distribution of these
>      keys is outside the scope of PANA.

Reword:

A: PANA itself does not do this. However, PANA must provide a way for
   such per-packet authentication/encryption to be achieved. For
   example, it may be sufficient if there exist EAP methods that can
   generate session keys.  Therefore PANA is an enabler for per-packet
   protection. The keys generated could (for example) be used with
   link-layer protection, or network layer protection
   (IPsec). Generation and distribution of these keys is outside the
   scope of PANA.

> Q21: Does the PaC have to configure an IP address before using PANA?

> A:   No. Since both PaC and the PAA are on the same IP subnet, PaC can
>      use unspecified IP address and still go through PANA. IP address
>      allocation and configuration can happen before or after PANA
>      authentication.

whoa! I'm surprised nobody said anything about this. This seems
inconsistent with (my version of) Q14. I'm also not sure what this
buys. It smells to me of wanting PANA to take place before addresses
are handed out. But I thought this was not something PANA was trying
to do. There has been lots of discussion about this in the past.

Thomas

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 15 May 2002 18:01:18 -0700

Hi Thomas,

> just answered with yes/no, which does little to explain to the reader

I guess we were little too brief on answering them...for the benefit
of the people who are familiar with the ongoing discussions. Clearly
more explanations are useful, and especially needed for the first
time readers. Thanks for the extended comments...

Comments below...

> that the client understand the AAA protocols in local use.

Sure. This is good to add.

> people have indicated that this is still a useful application in some

Yes.

> authorize IP service. In such environments, PANA may not be useful or

Good point.

>      device, etc.  Is PANA still useful given these concerns?

I think "Q2+Q3" answers this question.

> as opposed to point-to-point links. This is one reason why PPP is not

Will add this too.

> broadcast LAN environments (e.g., hotel or airport LANs, etc.)

Good to capture.

> and better understood. For example, I've heard some folks assert

Yes. But one thing to note is that: If L2 is not secured, L3 is more
vulnerable to such attacks. But this is the same with L2 authentication.
If L1 is not secured, then L2 authentication protocol is vulnerable
to a similar set of attacks. (please read this with A2 in mind).

> Client could use (say) IPsec to encrypt/authenticate all traffic.

Yes. And Q20 addresses that.

> or how PANA and access control fit together.

Client access authentication should be followed by access
control to make sure only authenticated and authorized
clients can send and receive IP packets via access network.
Access control can involve setting access control lists on the
enforcement points. Identifying clients which should be allowed
access is done by PANA protocol exchange. Though transporting
the required information to the  enforcement points in the network
is outside the scope of PANA.

> In those cases where no AAA is used, what is the model? Please expand.

When the access network doesn't rely on a IETF-defined AAA protocol
(e.g., RADIUS, Diameter), then it can still use a proprietary backend
system, or rely on the information locally stored on the authentication
agents.

> resides on the same IP link as that client (i.e., no IP router between

We can make it a "must". (note that people can still use it over an IP
tunnel
if they want to get their clients authenticated to a far-away node, given
that
they provide an out-of-band agent discovery method. Tunnel is a link
anyways...)

> obvious to the reader, but presumably is important to understand.

Sure. We can expand on it:

PANA does not require PAA to be co-located with the enforcement
point. Network access enforcement can be provided by one or more
nodes on the same IP subnet as the client (e.g., multiple routers), or
on another subnet in the access domain (e.g., gateway to the Internet,
depending on the network architecture). When the PAA and the
enforcement  point(s) are separated, there needs to be another transport
for  client provisioning. This transport is needed to create access control
lists to allow authenticated and authorized clients on the enforcement
points.
This transport is outside the scope of PANA.

> invoke PANA functions. See also Q4.

See below for my comment, as well.

>    individual users sharing the same device, etc.

Yes, this is better.

>    will not be extending EAP, but may define requirements for an EAP

I'd say "if extensions to EAP are needed." I'm not sure if we already
identified a need for extensions..

>      depending on the specific L2.

Agreed.

OK.

> to do. There has been lots of discussion about this in the past.

PANA's independence from address allocation was already established
in the current charter. It wasn't clear whether that also meant being
able to do PANA before address allocation. I posed this question
at the last IETF, and suggested this clarification. There was no objection.

Before and after IETF, people had expressed interest in this feature,
especially because they don't want to hand out IP addresses until they now
the client is authorized. Also IP address provided might depend on the
identity of the client. This is a very useful and needed feature.

> Thomas

Thanks Thomas, for taking time and providing these useful comments.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 15 May 2002 23:07:51 -0400

> >    (IPsec). Generation and distribution of these keys is outside the

If there is no objection, I would like to add this part to Security
Consideration section of usage scenarios draft.  (Other sections are
also now being revised according to the possible charter update.)

Thanks,
Yoshihiro Ohba

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 May 2002 13:49:37 -0400

OK, so I gather a revised FAQ will be forthcoming.

On the last point, however, ...

> at the last IETF, and suggested this clarification. There was no

This significantly muddies up the issue in my mind. First of all, if
you require that PANA work before a client has an IP address, you no
longer have an L3-only solution. You will need some hacks to send
stuff to/from the right link-layer addresses, since there are no IP
addresses.

Second, this may mean generic IP protocols/mechanisms won't work. For
example, if there is a need to run IPsec (as part of the PANA
exchange), you can't do that unless you have a proper IP address.

Finally, I think allowing PANA to work in the absence of a client
having an IP address muddies up the notion that PANA is orthogonal
from address assignment. I.e., you now are opening the door to some
scenarios where the client uses DHCP to get an address, then talks to
PANA. But in other scenarios, DHCP (or stateless addr conf) is
disallowed and (a possibly different??) version of PANA must be used
that works before the client has an IP address. What are clients
supposed to do in general? It seems like the behavior might be tied to
the operational choices made by the access network, but the client
probably doesn't know what choices have been made.

> identity of the client. This is a very useful and needed feature.

I'm not sure I agree with (or fully understand the need for) this. I'd
like to hear more from the list.

Thomas

---

From: John Schnizlein <[email-masked]>
Date: Wed, 22 May 2002 14:52:29 -0400

At 01:49 PM 5/22/2002, Thomas Narten wrote:

>> people ... don't want to hand out IP addresses until they [know]
>> the client is authorized. Also IP address provided might depend on 
>> the identity of the client. This is a very useful and needed feature.
>

I thought the consensus was that PANA was not supposed to be 
involved in assigning IP addresses.

If someone wants authentication before an IP address is assigned, 
it seems clear that they want layer-2 authentication.

Assigning IP addresses based on authenticating the identity of 
the user of the host is precisely the function that motivated 
draft-ietf-dhc-agentopt-radius-00.txt. 
This specification enables the layer-2 authenticator to forward the 
user's identity, and any other AAA attributes necessary, to the
DHCP server for its use in address assignment.

There is no need to make this function a feature of PANA.

John

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 22 May 2002 16:46:48 -0400

When IPv6 address autoconfiguration is used, it is possible to perform
PANA by using link-local address before a /64 prefix is assigned to
each subscriber of DSL connection or PDP context.  The access router
could make a decision on whether it advertises a distinct /64 prefix
to a subscriber based on the PANA authentication result.  A text
relating to this is described in page 6 of the current usage scenarios
draft.  I think this kind of PANA usage is useful.  I assume in the
above example that subscribers are physically partitioned, e.g., each
subscriber is connected to a different Ethernet port at the access
router.  Additional consideration would be necessary in the above
example on how to advertise a distinct prefix to each subscriber when
multiple subscribers are on the same broadcast media.

Anyway, some IP address (a link-local address in the above example) is
necessary for PANA messaging.  But I don't like to use 0.0.0.0 for
PANA since that requires broadcast for PANA messaging and thus
consumes bandwidth.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 22 May 2002 16:36:51 -0700

> OK, so I gather a revised FAQ will be forthcoming.

Yup.

> stuff to/from the right link-layer addresses, since there are no IP

This would be similar to what is done with router discovery and dhcp.

> exchange), you can't do that unless you have a proper IP address.

I'm not sure if I understand why we would need IPsec.

> probably doesn't know what choices have been made.

Either the client has to know the operational choices, or discover
them. This is the same case when client can use either address autoconfig
or dhcp for address configuration. How does it know which one to use...

In the networks that are configured to use PANA before IP address
configuration, the network side can initiate PANA upon seeing that
client is attempting to get an address (sending router discovery, or
dhcp discovery).

Otherwise, if network is OK with IP address allocation prior to
using PANA, then it can kick in PANA as soon as client starts
sending packets other than for IP address allocation.

> like to hear more from the list.

Meanwhile, let me point to an e-mail that also talks about the need
for doing PANA before IP address configuration... It was sent on the
mailing list on April 11 by Prakash Jayaraman. It's attached..

alper

Subject: Re: Question for vendors and operators
From: Prakash Jayaraman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 11 Apr 2002 15:42:38 -0700

[email-masked] wrote:
> 
> Hello,
> 
> We would like to hear from vendors and operators if PANA would be
> something that solves a problem in their networks and hence would like
> to see it standardized.
> Would PANA be something that operators would deploy as an alternative
> to doing authentication via PPPoE or PPP or 802.1x or via http
> redirect?
> 
> -Basavaraj

In our NAS environment, we are looking for a solution to authorize,
authenticate a user (a person) before we allow him/her to use 
the network. Note that NAS supports multiple providers for
customers and so it supports dynamic provider selection. It
also supports multiple contexts (multiple address spaces,
overlapping or not) for administrative, billing and security 
reasons.

The medium between the users and NAS is either P2P (traditional
dialup lines, DSL, ATM links etc.) or broadcast (cable-modem
network).

1) PPP - currently widely in use.
   * Only one PPP connection is allowed per link.
   * NAS authenticates the user using CHAP and assigns
       IP address using IPCP.
   * CHAP phase is also used to do "dynamic provider selection".

2) To support more than one user,
   * If you need to support more than one user with just PPP, 
     NAT gets used at the customer-premises. CPE equipment
     to do this are widely available these days. 
   * PPPoE 
       - supports more than one user.
       - DISCOVERY stage also works as a signalling protocol to perform
         dynamic service selection. But in our implementation, we do not
         use this feature. We prefer to use out-of-band means to 
         do service selection.

3) DHCP - not very widely in use.
   * NAS acts either as DHCP relay agent or as server (depending on the
     configuration).

Problems with PPPoE:
   Have to install a special client on the CPE and it creates management
     trouble as it is not part of most clients.
   More software layers on the NAS - we would like to use less software
     if possible. 
   Hardware switching becomes very tricky due to the extra 6-byte
header.
     (Part of the reason is that when encapsulated in LLC-AAL5, the
      destination IP address is on the second cell. This is not an
      issue if we don't have this 6-byte header).
     Such tricks are not trivial and result in use of additional
hardware
     resources. The solutions that we have are not easy to do and we
     prefer not having to go through such issues in the next-gen 
     hardware.
   Since we are using PPPoE only to support multiple-clients at the 
     customer-side, I prefer the customers use PPP+NAT to PPPoE or
     DHCP.
   
Problems with PPP:
   We are using PPP for AAA and address assignment only, in a NAS
     application.
   We only support IP within PPP. Support for other protocols is of
   no practical use for the NAS application today.
   That being the case, we would like to support IP directly, but it
   is not that big a deal to support PPP (with or without NAT) and 
   we don't intend to stop supporting it. 

   PPP supports assignment of IP-address, DNS and WINS addresses only.
   Sometimes, we need to support some more configuration parameters
   for which we think DHCP would be the way to go. 

   I don't think we will remove support for PPP even in a distant
   future, but we would like to discontinue support for PPPoE as soon
   as possible.

   Supporting PPP+NAT, requires intelligent CPE throughout the
     life of the connection. This could become a major issue
     for network and user administration.

Problems with DHCP:
   * Does not have the authentication mechanism and so can't use it
     in untrusted environment. But then there are ISPs already
     that have begun to use DHCP on P2P links for the sole reason
     that there is absolutely no administrative overhead.
   * We are being asked to AAA the users before
     network-access is granted. We are using a proprietary application
     layer method to do so and that is not simple either and it does not
     seem to work in all situations.

Problems in a network with statically assigned IP-address:
   * We would like to AAA the users before the machine is
     allowed to access the network.
   * Application layer proprietary AAA mechanism might work,
     but we would like to see a standard solution.

AAA-ing the machine using layer-2 parameters is probably useful,
but it is not sufficient for providing user-specific services. Any
AAA phase before network-access (with and without the use of DHCP, 
before or after DHCP if DHCP is used) will be useful for our
application. 

Any such mechanism should provide an NAS with both of the following.
 * dynamic service-provider selection (for IP-address assignment).
 * complete layer-2 independent two-way AAA mechanism.

- prakash

---

From: Glen Zorn <[email-masked]>
Date: Fri, 24 May 2002 01:53:26 -0700

> > identity of the client. This is a very useful and needed feature.

Exactly why _real_ L2 authentication is so useful and needed.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 24 May 2002 06:44:40 -0400

> I'm not sure if I understand why we would need IPsec.

Certain EAP negotiations may require the creation of a secure channel
prior to doing some of the EAP exchanges in order to protect the EAP
exchange. IPsec would be a logical candidate for this. This has been
discussed some on the EAP list.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 24 May 2002 06:42:20 -0400

Yoshihiro Ohba <[email-masked]> writes:

> each subscriber of DSL connection or PDP context.

Yes. So IPv6, at least, has the advantage that a PANA Client has an IP
address it can use to communicate with the PAA. But IPv4 does not have
this feature.

> The access router could make a decision on whether it advertises a
> distinct /64 prefix to a subscriber based on the PANA authentication
> result.

This is much trickier, because I believe this changes the way (say in
IPv6) Neighbor Discovery works. In particular, the normal scenario
would be:

client gets RA that excludes addresses
client gets authenticated via PANA
client doesn't have a global IPv6 address, and doesn't know that it
  needs to send out RS again (since the RA that it would get now is different)

The point is, this may impact existing mechanisms for configuring
addresses and change the way the client has to behave. Not just to use
PANA, but also how it does address configuration when PANA is
present. 
  
> A text relating to this is described in page 6 of the current usage
> scenarios draft.  I think this kind of PANA usage is useful.  I
> assume in the above example that subscribers are physically
> partitioned, e.g., each subscriber is connected to a different
> Ethernet port at the access router.

This assumption would seem to be problematical in wireless scenarios.

> Additional consideration would
> be necessary in the above example on how to advertise a distinct
> prefix to each subscriber when multiple subscribers are on the same
> broadcast media.

Won't this be a common case?

> necessary for PANA messaging.

Yes. Note that IPv4 doesn't have this today.

Thomas

---

From: Glen Zorn <[email-masked]>
Date: Fri, 24 May 2002 06:50:11 -0700

At 06:44 AM 5/24/2002 -0400, Thomas Narten wrote:
>exchange. IPsec would be a logical candidate for this.

Yes, but as you point out, an IP address is needed before you can run 
IPsec.  Since this is not the case in either PPP or 802.11, it's hard for 
me to see how IPsec can be considered a candidate in the general case...

>This has been

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 24 May 2002 14:02:23 -0400

Thomas,

>   needs to send out RS again (since the RA that it would get now is different)

I think client does not have to send out RS again, since it would be
the responsibility of the router to resend RA immediately when the
contents of the RA are going to change (due to insertion of the
authorized prefix in this case).  So IPv6 ND software would work as it
is at least at the client side.

> This assumption would seem to be problematical in wireless scenarios.

In wireless environment that provides IP connectivity over logical
point-to-point L2 link such as 3GPP, this assumption still holds, I
think.

> Won't this be a common case?

I don't think this is a common case.  If multiple subscribers are on
the same multi-access link, it is a common practice that a prefix
is shared among them.

> Yes. Note that IPv4 doesn't have this today.

Right, this usage is for IPv6 only.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 24 May 2002 13:04:46 -0700

> me to see how IPsec can be considered a candidate in the general case...

and there are EAP solutions addressing the secure channel issue: EAP TTLS,
PEAP.
They can be used with PPP, 802.1x, and PANA.

alper

---

From: Thomas Narten <[email-masked]>
Date: Fri, 24 May 2002 19:13:09 -0400

> me to see how IPsec can be considered a candidate in the general case...

IPsec can be used in the general PANA case, *if* PANA requires that
clients have an IP address prior to the PANA exchange. The meta point
I'm trying to better understand is whether such a requirement makes
sense, or whether it should be possible to use PANA before a client
has been assigned an address.

Thomas

---

From: Glen Zorn <[email-masked]>
Date: Sat, 25 May 2002 04:59:40 -0700

At 07:13 PM 5/24/2002 -0400, Thomas Narten wrote:
>clients have an IP address prior to the PANA exchange.

Oh, certainly!  I was talking about the general case for _EAP_.  Sorry for 
any confusion.

>The meta point