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

[Ralph Droms <rdroms at cisco.com>]

A couple of practical considerations...

Adding PAA-DHCP interaction now involves an entirely different protocol
suite and creates inter-protocol entanglements.  While there may be some
standards-based ways for PAA-EP interaction (SNMP? [I know the issue is out
of scope for the doc itself]), there is no such mechanism in place for DHCP
today.

DHCPv4 reconfiguration is, as far as I know, not implemented anywhere, so a
requirement for DHCPv4 reconfiguration is another inter-protocol
entanglement.

I don't intend to imply that these considerations are show-stoppers; I do
see a difference in practice between PAA-EP interaction and PAA_DHCP
interaction.

- Ralph


On 10/9/06 8:47 PM, "Yoshihiro Ohba" <yohba at tari.toshiba.com> wrote:

> Alper,
> 
> On Mon, Oct 09, 2006 at 10:19:45PM +0300, Alper Yegin wrote:
>>>> Or...
>>>> 
>>>> PRPA can be a temporary IP address allocated by the DHCP.
>>>> Unspecified-sourced clients are allowed to hit the DHPC server and
>>> allocated
>>>> the temp IP address. Once the client is PANA authenticated, now the
>>>> PRPA-sourced IP packet is allowed to hit the DHCP server and allocated
>>>> permanent address.
>>> 
>>>> There may be other (better) architectural solutions that do not require
>>>> PAA-DHCP signaling.
>>>> 
>>> If the DHCP server hands out temporary and permanent addresses depending
>>> on whether authentication has occurred or not, I don't see how you get
>>> around some sort of PAA-DHCP interaction anyway. This could be via
>>> option 82 information inserted by the PAA, or some other direct
>>> communication (or just assume that they are co-located for these cases).
>> 
>> In my above example, the deployment depends on the EP doing the appropriate
>> filtering. Anyways, this is just an example of how "a" deployment can
>> achieve this without requiring PAA-DHCP interaction.
> 
> I don't see much difference between PAA-EP interaction and PAA-DHCP
> interaction.  In fact, I tend to view the DHCP server as another EP.
> 
> Since DHCP server can send a reconfiguration trigger to DHCP client, I
> think we can simply rely on such a DHCP functionality and simplify
> PANA not requiring PaC to take any active role for IP address
> reconfiguration.
> 
> Yoshihiro Ohba
> 
> 
>> 
>> I acknowledge that some other deployments may prefer relying on PAA-DHCP
>> interaction. I'm fine with that, as long as we don't need to build any more
>> bits into the PANA specification to support that :-)
>> 
>> Alper
>> 
>> 
>> 
>> 
>>> 
>>> - Mark
>>>> 
>>>> 
>>>>>> Not only that, but also in a given deployment the IP address
>>>>>> 
>>>>> configuration
>>>>> 
>>>>>> mechanism may not even be based on DHCP. It's simpler and more
>>> scalable
>>>>>> 
>>>>> to
>>>>> 
>>>>>> give a one-bit heads up to the PaC, and let it do whatever it does to
>>>>>> configure another IP address.
>>>>>> 
>>>>>> 
>>>>> This is a classic argument over where the complexity lies - in the PaC
>>>>> or in the Network. I think there are tradeoffs both ways on this. I do
>>>>> think that the communication from the PAA to PaC here should be
>>>>> optional,  leaving the door open for the Network to  hand out a new IP
>>>>> address on its own accord without relying on the PaC to ask for one in
>>>>> all cases where it is necessary.
>>>>> 
>>>> 
>>>> Sure, that's fine.
>>>> 
>>>> 
>>>>> In general, renegotiating an IP address is typically problematic on
>>> IPv4
>>>>> networks today (HIP and such aside). I don't think PANA should be
>>>>> recommending this as not all stacks, transports, and applications can
>>>>> handle it without difficulty (e.g., if this is a MUST for PANA, it
>>>>> raises the bar considerably for where PANA could be used).
>>>>> 
>>>> 
>>>> It's not a MUST for PANA (more specifically "for PaC").
>>>> 
>>>> Alper
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> - Mark
>>>>> 
>>>>> - Mark
>>>>> 
>>>>>> Alper
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> - Mark
>>>>>>> 
>>>>>>> 
>>>>>>>> Yoshihiro Ohba
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Sun, Oct 08, 2006 at 01:04:03AM +0300, Alper Yegin wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> If the initial address (PRPA) is not a link-local address, then
>>> you
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> can
>>>>>>> 
>>>>>>> 
>>>>>>>>>> use it both before and after PANA. Either it is a private address
>>>>>>>>>> 
>>>>> that
>>>>> 
>>>>>>>>>> gets NATed or a public address. If the underlying
>>>>>>>>>> protection (e.g. IPsec) needs another address, it may have to get
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> another
>>>>>>> 
>>>>>>> 
>>>>>>>>>> address which PANA does not have to worry about it i guess.
>>>>>>>>>> Missing something ?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> You only talked about the IPsec case.
>>>>>>>>> 
>>>>>>>>> But for example in DSL case, the PaC cannot know whether the PRPA
>>> is
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> good
>>>>>>> 
>>>>>>> 
>>>>>>>>> for post-PANA data communication or not. Unless the PRPA is a link-
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> local
>>>>>>> 
>>>>>>> 
>>>>>>>>> address, the PaC cannot tell one way or the other. And there is no
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> IKE/IPsec
>>>>>>> 
>>>>>>> 
>>>>>>>>> in that case.
>>>>>>>>> 
>>>>>>>>> Alper
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> -mohan
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> ----- Original Message ----
>>>>>>>>>> From: Alper Yegin <alper.yegin at yegin.org>
>>>>>>>>>> To: Mohan Parthasarathy <mohanp at sbcglobal.net>; Yoshihiro Ohba
>>>>>>>>>> <yohba at tari.toshiba.com>; Mark Townsley <townsley at cisco.com>
>>>>>>>>>> Cc: pana at ietf.org
>>>>>>>>>> Sent: Friday, October 6, 2006 1:19:37 PM
>>>>>>>>>> Subject: RE: PPAC needed? (was RE: [Pana] Other suggestions for
>>>>>>>>>> 
>>>>> pana-
>>>>> 
>>>>>>> pana)
>>>>>>> 
>>>>>>> 
>>>>>>>>>> Mohan,
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> So,
>>>>>>>>>>> we can
>>>>>>>>>>> potentially make it by restricting what sort of an address it
>>>>>>>>>>> 
>>>>> obtains
>>>>> 
>>>>>>>>>>> before running
>>>>>>>>>>> PANA so that it does not require a new one after (it can be
>>> outside
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>> the
>>>>>>> 
>>>>>>> 
>>>>>>>>>>> PANA spec)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> I'm not sure I understand this proposal. Can you please elaborate?
>>>>>>>>>> 
>>>>>>>>>> Thanks.
>>>>>>>>>> 
>>>>>>>>>> Alper
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 
>> 
> 
> _______________________________________________
> Pana mailing list
> Pana at ietf.org
> https://www1.ietf.org/mailman/listinfo/pana

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