Re: [shara] Shara scope

Hi,

I ment that there's no need to work here about how NATs work (or how those are traversed) in general, but indeed the coexistence with NATs and placement of NAT are of interest.

While new phones could be containing support for this feature, the old ones definitely would not. Thus the gateway serving large number of terminals would need to provide public IPv4 address or NAT for some while letting others use shared addresses. And this distribution would likely change as legacy devices would go away and new ones come in, and even more so when IPv6 becomes common.

About the signaling. On the DHCP-based solutions, I think (at least in our proposal solution) the signaling could work by node sending in DHCPDISCOVER indication of its support for shared addresses, and with that it would implicitly indicate no need for NATting by the delegating host (if it indeed delegates shared addresses). On the chain of delegating nodes the first node that does not indicate support for shared addresses in its DHCPDISCOVER essentially indicates to the node above to provide private IPv4 address and instantiate NAT.

Best regards,

        Teemu

>-----Original Message-----
>From: ext Olaf Maennel [mailto:omaennel@net.t-labs.tu-berlin.de]
>Sent: 27 January, 2009 10:42
>To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>Cc: shara@ietf.org
>Subject: Re: [shara] Shara scope
>
>
>Hi,
>
>Teemu, i completely agree with your definition of the scope.
>we tried in our draft to separate the functionality of NAT and
>port-range.  ...and i think its possible to cleanly separate
>those two functions.
>
>However, there is an interconnection point. because port-range
>proposals will need NATs, when connecting legacy devices. As
>we don't expect that all end-devices will be upgradable (okay,
>your phones will be - but hosts behind them not necessarily).
>So there must be some NATing involved somewhere, and actually
>i believe this could be designed in a really flexible manner.
>For example in your mobile setting: (1) laptop behind the
>phone could do it NATing itself (and only send "port-range
>packets"), (2) the mobile phone could do the NATing, or (3)
>the base station ??, or (4) the NATing could be done somewhere
>in the providers network (a la cgn's).
>All we have to do in port-range is to signal where NATing is
>possible. Which i believe would be the connection point with behave...
>
>Cheers,
>
>    olaf
>
>
>On 27/01/09 9:23 AM, "teemu.savolainen@nokia.com"
><teemu.savolainen@nokia.com> wrote:
>> Hi,
>>
>> And behave works with NATs.. I would think NAT, CGN, or multiple
>> instances are not to be part of this work item as such, as those are
>> already handled elsewhere?
>>
>> What is not done elsewhere is the "port range" and its
>implications to
>> protocols, networks, hosts, and applications.
>>
>> What could be also discussed to some extent is port restricted IP
>> address integration to some already existing solutions. For example
>> DHCP-based port restricted IP address allocation mechanism could be
>> used as DS-Lite extension, but also as stand-alone feature on
>> point-to-point links. Also other address assignment methods,
>like MIP,
>> could be extended with port restricted IP address allocation support.
>>
>> Whatever mechanism to allocate these addresses is used,
>there are some
>> common problems like how multiplexing/routing is to be done, blind
>> attacks, protocols not having ports, fragmentation etc.
>>
>> One approach could be to define here the concept of port restricted
>> addresses and sort out the generic problems, and maybe
>define the DHCP
>> extension as one mechanism, and leave the adoption of the concept to
>> other technologies to be done in corresponding working groups.
>>
>> Best regards,
>>
>>     Teemu
>>
>> ________________________________
>> From: shara-bounces@ietf.org [mailto:shara-bounces@ietf.org]
>On Behalf
>> Of ext pierre.levis@orange-ftgroup.com
>> Sent: 26 January, 2009 14:45
>> To: shara@ietf.org
>> Subject: [shara] Shara scope
>>
>>
>> Hi,
>>
>> So, shara deals with "port range" and softwire deals with DS-lite,
>> which is fine with me, even if all IPv4 shared address solutions in
>> the same WG would also make sense.
>>
>> But what about other solutions? I'm thinking of CGN in its
>Double NAT version.
>> It is a solution already deployed in some ISPs' networks and
>the only
>> one currently available on shelves (even if DS-lite implementations
>> make quick progress).
>>
>> Shouldn't we integrate a BCP document in the "Proposed Work" section
>> to cover this item? Basically considerations of where to locate the
>> CGN and how to route the traffic between customers and CGN?
>>
>>
>>
>> Pierre
>> _______________________________________________
>> 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