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