Re: [shara] Updated SHARA BOF description

[<[e-mail]>]

Marcelo,

The description focuse now strongly to distributed NAT, while that is not the only intent of this work - from my point of view more as side-effect. Thus the new version of chapter looks somewhat misleading.

The host having port restricted IPv4 address may or may not implement the NAT internally. If, as is likely, it is running applications or protocols that would face problems with port restricted addresses, NAT can be used to hide the problematics from them, but those apps and protocols that do understand port restricted address, or don't care, should be able to totally avoid NAT and have the benefits of NATless communication (but the port restriction).

This was part of the original BOF description:"..and/or require NATless IPv4 connectivity."

The port restriction anyways is something apps needs to live with - with port restricted addresses the restriction comes already from the network, instead of another apps running on a same host.

So the solutions that are proposed indeed enable distributed NAT functionality, but also enable NATless IPv4 communication. So on the "motivation of shara" I'd like to see benefits and potential issues of having NATless communication possible, but with limited port availability.

On the solution space the same thing, as this BOF is not only about distributed NAT. For example, in DS-Lite environment the NAT can actually be at CGN, while the host is - at the same time - able to get port restricted IPv4 address for those applications that are capable of using them. For other apps CGN is used.

Best regards,

	Teemu

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of ext marcelo bagnulo braun
>Sent: 04 March, 2009 20:43
>To: [e-mail]
>Subject: [shara] Updated SHARA BOF description
>
>Hi,
>
>We have updated the SHARA bof description to adapt its scope 
>to the non-wg forming bof that was accepted by the ADs.
>
>Please find it below.
>
>Comments are welcome
>
>Regards, marcelo
>
>(on behalf of Bernard, Magnus and myself)
>
>
>
>Sharing IPv4 Addresses (SHARA) BOF
>
>In the current Internet, it is fairly common for ISPs to 
>provision their subscribers with a single public IPv4 address 
>and for those subscribers to use NAT technology to allow 
>multiple machines in their networks to access the Internet. 
>This setup essentially requires one public IPv4 address per 
>subscriber. As the IPv4 free address pool becomes depleted, it 
>seems likely that  ISPs will not have enough public IPv4 
>addresses to assign one address per subscriber. When that 
>happens, multiple subscriber networks will have to share a 
>single public IPv4 address. Multiple approaches have been 
>proposed in order to implement the sharing of public
>IPv4 addresses, as described in section 2.1 of 
>draft-arkko-townsley-coexistence-00.
>
>The goal of this BOF is to discuss and gain understanding of a 
>particular family of solutions, the so called distributed-NAT 
>approaches described in section 2.1.2 of draft-arkko-townsley- 
>coexistence-00. This family of solutions, essentially assigns 
>a public IP address and a port range to each subscriber and 
>relies on some form of port range routing capability within 
>the ISP network. The result is that each subscriber still 
>obtains at least a part of a public IP address and retains 
>some of the capabilities of the current configuration.
>
>During the BOF we intend to discuss the following items:
>- Problem characterization: We need to understand what is 
>exactly the problem, what are the different scenarios that are 
>affected by the IPv4 address space depletion and what are the 
>possible approaches to address the problem. In addition, we 
>need to identify the different relevant aspects of the problem 
>and solution space that need to be taken into account during 
>the discussion of the solution space.
>- Motivation for SHARA: Discuss the benefits and potential 
>issues with a distributed NAT approach.
>- Distributed NAT approaches: Explore the solution space for 
>distributed NATs and the implications of the relevant aspects 
>previously identified.
>- Interaction with other efforts. There are a significant 
>number of efforts in related areas, such as the work being 
>done in the BEHAVE WG and the SOFTWIRES WG. It is then 
>relevant to understand how the proposed mechanisms interact with these.
>- Implication for the deployment of IPv6. Any mechanism that 
>aims to extend the lifetime of IPv4 can potentially delay IPv6 
>deployment. An analysis of the impact of the adoption of these 
>techniques is needed.
>
>
>This is non-wg forming BOF and the goal is to provide input 
>material to the community in general and the IESG in 
>particular for them to scope out what gaps still need to be 
>addressed in chartered WG items in other WGs.
>_______________________________________________
>shara mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/shara
>