Re: PPAC needed? (was RE: [Pana] Other suggestions for pana-pana)

[Yoshihiro Ohba <yohba at tari.toshiba.com>]

On Tue, Oct 10, 2006 at 01:29:43PM +0300, Alper Yegin wrote:
> Let's walk over this step by step.
> 
> For deployments that don't mind handing out non-temporary IP addresses prior
> to PANA authentication, we don't have a problem.
> 
> For deployments where PaC's PRPA is a link-local address, obviously PaC
> would know to configure a POPA via DHCP. No problem.
> 
> For deployments where PaC's PRPA is a temporarily allocated address (an IPv4
> address), a POPA configuration needs to take place. The question is: How
> does this get initiated?
> 
> If PAA and DHCP server are co-located, than an API can trigger the DHCP
> server to initiate the process. No protocol work is needed.
> 
> [One WG choice is to stop here for now. Meaning: Deployments/architectures
> that want to split the PAA and DHCP server, they've gotta deal with it.]
> 
> If PAA and DHCP server are not co-located, we have two options to consider:
> a- Trigger PaC to initiate the process
> b- Trigger DHCP server to initiate the process
> 
> Option (a) can be achieved by defining one bit in PANA. There were two

I think option (a) can be achieved by defining additional information
(a flag?) in draft-ietf-dhc-paa-option.  If this is a deployment
issue on DHCP reconfiguration, solving it within DHCP could make
sense.

Yoshihiro Ohba

> questions on that approach:
> 1- How does the PAA know to set that bit? 
> 
>    PRPA/POPA configuration type is a deployment choice. As such, it would
>    be one of the PAA configuration parameters.
> 
> 2- Even in that case, wouldn't we still need a PAA-DHCP interaction, so that
> the DHCP server knows when to allocate PRPA vs. POPA?
> 
>    This is not a "must have." One can design architectures using this bit
> and not necessarily requiring any PAA-DHCP interaction. For example: EP
> allows unspecified sourced DHCP packets from unauthenticated PaCs to hit the
> DHCP server. And the DHCP server allocates PRPA to such PaCs. Upon PANA
> authentication, now the EP allows PRPA-sourced DHCP packets from the
> authenticated PaC to hit the DHCP server. And now DHCP allocates POPA. DHCP
> server in that deployment can make the distinction based on the source
> address. Or, if the DHCP relay and EP are co-located, EP can also set some
> bits on DHCP to signal that PaC is an authenticated one.
> 
>   Anyways, this is just an example of how using option (a) does not
> automatically mean option (b) must also be implemented.
> 
> [Second WG choice is to stop here. Meaning: Define one bit of PANA to signal
> PaC's need to configure another IP address.]
> 
> 
> Option (b) requires another protocol design. [I don't even propose we
> identify this as a WG choice right now, as we wouldn't want to venture into
> more protocol design.]
> 
> Comments?
> 
> Alper
> 
> 
> 
> 
> 
> 
> 
> 

_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana