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

[Mohan Parthasarathy <mohanp at sbcglobal.net>]

>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.
>
I guess this is the FORCERENEW option i guess.

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

I have to agree with Yoshi that this can be solved outside of PANA. Hence,
we should not need any extra bit.

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

I don't think option b is needed.

-mohan


>Comments?
>
>Alper











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