Re: [shara] port randomization (draft-ymbk-aplusp-03)

Teemu, hi.
>
> Now if the non-contiguous port set is less random, say contains multiple non-contiguous ranges allocated with port masks (see the same draft), less effort is needed in dhcp-client (no AES calls needed) and multiplexing gateway, as no AES calls are needed and mapping tables can be simpler (as bitmasks can be used). In DHCP server effort is pretty similar except for key generation part that is not needed.
>   
Exactly.
> Comments? This is interesting topic to look into.
>
> I don't think these are issues for the end-nodes, but maybe someone who would be involved in gateway implementation could comment their perspectives?
>   
ISP's already have issues with not enough memory in CPE for firmwares 
even without v6 and/or shared IP solution. With growing complexity of 
shared IP solution their problem is not going away, but getting bigger 
:) If we suspect, that ISP will replace all the HW, then we can go 
complex. If we suspect, that ISP will want to "just upgrade" CPE 
firmware to support IPv6 and shared IP, then we need to do something 
that would fit into HW of yesterday and today. Am I somehow thinking 
into sensible direction?

regards, Jan Zorz
> Best regards,
>
> 	Teemu
>
>
>   
>> -----Original Message-----
>> From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] 
>> On Behalf Of ext Randy Bush
>> Sent: 12 March, 2009 18:18
>> To: shara@ietf.org
>> Subject: Re: [shara] port randomization (draft-ymbk-aplusp-03)
>>
>> would a potential implementor care to speak to any resource 
>> and scaling aspects of non-contiguous port assignment?
>>
>> randy
>> _______________________________________________
>> shara mailing list
>> shara@ietf.org
>> https://www.ietf.org/mailman/listinfo/shara
>>
>>     
> _______________________________________________
> shara mailing list
> shara@ietf.org
> https://www.ietf.org/mailman/listinfo/shara
>