Subject: [Pana] Pana-framework : Issues 194,195,196,197,199,200

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 15 Nov 2005 18:27:01 -0800

Mark,

I have handled most of the issues pertaining to section 5 and 6 in this mail.
They are marked as issues 194,195,196,197,199 and 200. I have included
Issues 198 and 201 in a separate mail.

> >5.  IP Address Configuration
> >
> >  The PaC configures an IP address before the PANA protocol exchange
> > 
> >
> Again, does "configures" include DHCP?
> 
Yes, it includes DHCP also. This is stated more clearly below. So, i am not
sure what we have to clarify here.

> >  begins.  This address is called a pre-PANA address (PRPA).  After a
> >  successful authentication, the client may have to configure a post-
> >  PANA address (POPA) 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.  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 client is authorized, or to enable client identity based address
> >  assignment.
> >
> >  In case the PaC is a IPv4/IPv6 dual-stacked node, it may configure
> >  more than one PRPA.  After a successful PANA authentication the PaC
> >  may configure multiple POPAs.
> >
> > 
> >
> Aha, so the reference to "multiple IP addresses" before is only in the 
> case of IPv4 and IPv6 (one each)?
>
I am not sure where this "before" refers to. I checked all the occurences of
"multiple" and this is the only reference to multiple IP addressees is "miltiple
POPAs" here in this section.   I think we should remove the text because
the dual stacked case is explained later in the same section and is much
more clearer. So, i suggest removing this paragraph.

> >  There are different methods by which a PRPA can be configured.
> >
> >  1. In some deployments (e.g., DSL networks) the PaC may be statically
> >     configured with an IP address.  This address SHOULD be used as a
> >     PRPA.
> >
> >  2. In IPv4, most clients attempt to configure an address dynamically
> >     using DHCP [RFC2131]. 
> >
> Most? There are a lot configuring addresses dynamically with PPP IPCP (I
> 
> still think PPPoE is more common in the EU and Asia than DHCP since 
> cable dominance is more prevalent in N.A.).
> 
Ok, reword the sentence to say

    2. In IPv4, some clients attempt to confugure and address dynamically
        using DHCP [RFC 2131]

> >If they are unable to configure an address
> >     using DHCP, they can configure a link-local address using
> >     [I-D.ietf-zeroconf-ipv4-linklocal].
> >
> >     When the network access provider is able to run a DHCP server on
> >     the access link, the client would configure the PRPA using DHCP.
> >     This address may be from a private address pool [RFC1918].  Also,
> >     the lease time on the address may vary.  For example, a PRPA
> >     configured solely for running PANA can have a short lease time.
> >     The PRPA may be used for local-use only (i.e., only for on-link
> >     communication, such as for PANA and IPsec tunneling with EP), or
> >     also for ultimate end-to-end data communication.
> >
> >     In case there is no running DHCP server on the link, the client
> >     would fall back to configuring a PRPA via zeroconfiguration
> >     technique [I-D.ietf-zeroconf-ipv4-linklocal].  This yields a long-
> >     term address that can only be used for on-link communication.
> >
> >  3. In IPv6, clients automatically configure a link-local address
> >     [RFC2462] when they initialize an interface.  Additionally, they
> >     may also configure global address(es) when DHCP or router
> >     advertisements with global prefixes are made available to the
> >     them.
> >
 > >
> >
> >  In case PAA is not on the same IP subnet as the PaCs are, the
> >  deployment must ensure that a non-link-local PRPA is configurable by
> >  the clients.
> >
> >  When a PRPA is configured, the client starts the PANA protocol
> >  exchange.  By that time, a dual-stacked client might have configured
> >  both an IPv4 address, and one or more IPv6 addresses as PRPAs.
> > 
> >
> Why would one have more than one IPv6 address as a PRPA?
> 
I don't think it is needed. So, we will fix the sentence to say

    By that time, a dual stacked client might have configured both an IPv4 address
    and IPv6 addresses as PRPAs.

> 
> >  When the client successfully authenticates to the network, it may be
> >  required to configure POPAs for its subsequent data communication
> >  with the other nodes.
> > 
> >
> And how is this done? Renegotiating IPCP (possible, but often 
> impractical), a DHCP Force-renew of some sort?
> 
This is explained a little bit below in detail. In IPv4 case, the Pac may
have to unconfigure the PRPA and configure just the POPA. In IPv6,
it keeps both the PRPA and POPA. Unconfigure really means, just
deassign the address and start using the new address. If DHCP was
used to configure PRPA, it will expire sooner or later. I think the
later paragraphs explain this and i suggest we don't do anything here.

> >  If the client is already configured with a non-temporary address that
> >  can be used with data communication, it is not required to configure
> >  a POPA. 
> >
> "non-temporary address that can be used with data communication" don't 
> you mean "globally routable" or some such here? If so, please say it. 
> This phrase is almost impossible to nail down the meaning for. This 
> model is particularly useful in an
> 
Okay, we can say globally routable address instead of non-temporary address.

> >Otherwise, the PANA-Bind-Request message allows the PAA to
> >  indicate the available configuration methods to the PaC.  The PaC can
> >  choose one of the methods and act accordingly.
> >
> >  1. If the network relies on physical or link layer security, the PaC
> >     can configure a POPA using DHCP [RFC2131] [RFC3315] or using IPv6
> >     stateless auto-configuration [RFC2461].  If IPv4 is being used, a
> >     PRPA is likely to be a link-local or private address, or an
> >     address with a short DHCP lease.
> >
> Wait, you just said that the PRPA address might be "non-temporary.." 
> just above, now you are saying it is likely a short-leased address?
> 
> The way I understand it has to work is that the PRPA is either (1) 
> temporary, or (2) permanent. If temporary, it must be replaced with a 
> POPA. If permanent, it need not be replaced with a POPA.
> 
Correct. The PRPA can be a link-local address or an address with
a short lease. I guess DHCP addresses will be short leased addresses.
I suggest we remove this sentence as it seems like the same thing is 
repeated again and again causing more confusion..

> Use a reference when referring to "private address"
> 
> > An IPv4 PRPA SHOULD be
> >     unconfigured when the POPA is configured to prevent IPv4 address
> >     selection problem [I-D.ietf-zeroconf-ipv4-linklocal]. 
> >
> Does this draft talk only about unconfiguring a link-local address, or 
> also unconfiguring a globally routable address (which I gather a PRPA 
> MAY be)?
> 
Only a link-local address. Because the globally routable address may
be configured statically. As long as the PRPA is sutiable to be used
as POPA, then there is no need to unconfigure the address. Perhaps,
it can be clarified explicitly here.

-mohan

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 20 Nov 2005 01:10:41 +0200

> Okay, we can say globally routable address instead of non-temporary

That'd not work.

POPA shall be configured when the PRPA is solely used for the sake of
running PANA. For example, PRPA may be a link-local IPv4 address. Or,
PRPA may be configured via DHCP with a very short lease. 

Otherwise, if the PRPA is also good for general data communication after
PANA authentication, then it can be kept and there is no need to
configure POPA.

That's what we meant. So, how can we capture this in the document?

Replacing "non-temporary" with "global" does not work, because POPA
don't have to be a global address, and nothing prevents PRPA from being
a global address. 

> > also unconfiguring a globally routable address (which I gather a
PRPA

The above text does not care what kind of PRPA was configured. If POPA
is configured as suggested by the network, then the PRPA must be
unconfigured. Though a link-local PRPA is more likely, I don't think we
need to rule out a global PRPA. 

> it can be clarified explicitly here.

Alper

---

From: Mohan Parthasarathy <[email-masked]>
Date: Sat, 19 Nov 2005 15:48:24 -0800 (PST)

--- Alper Yegin <[email-masked]> wrote:

> > > >  If the client is already configured with a
> non-temporary address
> that
> > > >  can be used with data communication, it is
> not required to
> configure
> > > >  a POPA.
> > > >
> > > "non-temporary address that can be used with
> data communication"
> don't
> > > you mean "globally routable" or some such here?
> If so, please say
> it.
> > Okay, we can say globally routable address instead
> of non-temporary
> > address.
> 
> That'd not work.
> 
The problem comes from the fact that we have not
mentioned the fact that POPA need not be a global
address. The normal case is PRPA is a link-local
address or DHCP with short lease. So, most likely
POPA will be reconfigured. You don't reconfigure
because it is a private address. I guess that
is your point. 

-mohan

> > > >  indicate the available configuration methods
> to the PaC.  The PaC
> can
> > > >  1. If the network relies on physical or link
> layer security, the
> PaC
> > > >     can configure a POPA using DHCP [RFC2131]
> [RFC3315] or using
> IPv6
> > > >     stateless auto-configuration [RFC2461]. 
> If IPv4 is being
> used, a
> > > temporary, or (2) permanent. If temporary, it
> must be replaced with
> a
> > > >     unconfigured when the POPA is configured
> to prevent IPv4
> address
> > > >     selection problem
> > > Does this draft talk only about unconfiguring a
> link-local address,
> or
> > > also unconfiguring a globally routable address
> (which I gather a
> PRPA
> > > MAY be)?
>

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 20 Nov 2005 19:22:44 +0200

> mentioned the fact that POPA need not be a global

We haven't because it could be a private address or a global address.
This is a deployment decision.

> The normal case is PRPA is a link-local

PRPA may be:
- a link-local address
- a DHCP-configured private address
- a DHCP- or (IPv6) auto-configured global address

POPA may be:
- a DHCP-configured private address
- a DHCP- or (IPv6) auto-configured global address

Going back to the original text:

	If the client is already configured with a non-temporary 
	address that can be used with data communication, 
	it is not required to configure a POPA.

Maybe what we need to do is to remove the word "non-temporary".

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 20 Nov 2005 23:13:43 -0500

I think we might need to explain what non-temporary address (or
temporary address) means, e.g., a non-temporary address is a private
or a global address for which lease period is long enough to run
applications during the authorization lifetime of the PaC.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 21 Nov 2005 18:45:58 -0500

> Maybe what we need to do is to remove the word "non-temporary".

I agree that removing the word "non-temporary" is simpler, and please
forget my previous comment on this issue.

Yoshihiro Ohba

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 21 Nov 2005 16:08:08 -0800 (PST)

--- Alper Yegin <[email-masked]> wrote:

> > > running PANA. For example, PRPA may be a
> link-local
> > > IPv4 address. Or,
> > > PRPA may be configured via DHCP with a very
> short
> > > lease.
> > >
> > > Otherwise, if the PRPA is also good for general
> data
> > > communication after
> > > PANA authentication, then it can be kept and
> there
> > > is no need to
> > > configure POPA.
> > >
> > > That's what we meant. So, how can we capture
> this in
> > > the document?
> > >
Yes. But i guess this is somehow not captured well i
guess.

> non-temporary 
Yes, that will help. I am wondering whether we should
mention what cases a PRPA will be unconfigured i.e the
common cases. And state explicitly that PRPA being
private is not one of the reasons as it is a
deployment decision.

-mohan

> Alper
> 
> 
> 
> > 
> > -mohan
> > 
> > 
> > > > > >Otherwise, the PANA-Bind-Request message
> allows
> > > the PAA to
> > > > > Wait, you just said that the PRPA address
> might
> > > be "non-temporary.."
> > > > > just above, now you are saying it is likely
> a
> > > short-leased address?
> > > > >
> > > > > The way I understand it has to work is that
> the
> > > PRPA is either (1)
> > > > > POPA. If permanent, it need not be replaced
> with
> > > a POPA.
> > > > >
> > > > Correct. The PRPA can be a link-local address
> or
> > > an address with
> > > > I suggest we remove this sentence as it seems
> like
> > > the same thing is
> > > The above text does not care what kind of PRPA
> was
> > > configured. If POPA
> > > is configured as suggested by the network, then
> the
> > > PRPA must be
> > > > Only a link-local address. Because the
> globally
> > > routable address may
> > > > be configured statically. As long as the PRPA
> is
> > > sutiable to be used
> > > > as POPA, then there is no need to unconfigure
> the
> > > address. Perhaps,