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

["Alper Yegin" <alper.yegin at yegin.org>]

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
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