[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re:2401bis Issue #68 -- VPNs with overlapping IP address ranges
Hi Steve,
Since, there is one common method being followed (which does not
require
any interoperability), I am trying to see whether we should make
this requirement as
'Should' rather than 'MUST'.
Thanks
Ravi
At 11:03 AM 9/17/03 -0400, Stephen Kent wrote:
>At 12:08 +0530 9/17/03, Ravi Kumar wrote:
>> Hi,
>> Implementations (including ours) allocate one or more public IP
>> addresses for each subscriber.
>> It is expected that IKE negotiations and IPSEC traffic come with
>> this(these) IP address(es) as
>> 'Destination IP'. Based on this, subscriber ID is extracted locally
>> and after decryption, the packets
>> are forwarded onto the subscriber network.
>> It is not mandatory to negotiate Subscriber ID via IKE.
>> Due to this, I feel, we should not make negotiation of subscribe ID
>> mandatory.
>> But, if same public IP address is used across multiple subscribers,
>> then subscriber ID via IKE
>> is needed. The proposed text should take care of above.
>>Thanks
>> Ravi
>
>Ravi,
>
>Use of multiple public addresses, one per subscriber net per Ipsec
>implementation, does provide another means of identifying the subscriber
>net, but this requires an ability to acquire the multiple, public
>addresses at each end. In that sense, this is a less general approach than
>using a subscriber net ID internal to IPsec (IKE). In general I think we
>are better off with a mechanism that works in all cases, vs. one that
>works only if it is possible to acquire enough public addresses from an
>ISP to assign one to each subscriber net address behind the device.
>
>Steve
The Views Presented in this mail are completely mine. The company is not
responsible for what so ever.
----------
Ravi Kumar CH
Rendezvous On Chip (I) Pvt Ltd
Hyderabad, INDIA
ROC HOME PAGE:
http://www.roc.co.in