Re: [shara] Updated SHARA BOF description

[marcelo bagnulo braun <[e-mail]>]

[e-mail] escribió:
> Hi Marcelo,
>
> Inline:
>
>   
>> -----Original Message-----
>> From: ext marcelo bagnulo braun [mailto:[e-mail]] 
>> Sent: 05 March, 2009 13:26
>> To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>> Cc: [e-mail]
>> Subject: Re: [shara] Updated SHARA BOF description
>>
>> Hi Teemu,
>>
>> About this scenario that you describe, i think that what you 
>> mean is that instead of having the NAT CPE acquiing the public 
>> address and the port range, the host itself acquires it, is 
>> that correct?
>>     
>
> Yes.
>
> But this host can also act like CPE, if it implements and shares the IPv4 address to other devices, e.g. in scenario
>    
> IPv4 host -- WLAN -- IPv4 cellular -- gateway -- IPv4 Internet
>
> I.e. sometimes the IPv4 cellular is just a host that gets port restricted IPv4 address for NATless communication, and maybe has internal NAT, but sometimes it acts as a CPE for other devices, to which itself allocates private IPv4 addresses and provides NAT functionality.
>
> Generally, I think name CPE relates more to a specific deployment scenario rather than to an entity that exist in protocol level as such. Thinking about CPEs may help to understand the functionality being discussed, but that same functionality can just as easily be implemented by some other kinds of nodes.
>   
Let's see

either the device that acquires the public v4 address and the port range 
uses them for its apps (this is the case where the host directly 
acquires the IP address and the port range)
or
the device that acquires the public IPv4 address and the port range is 
forwarding packets for apps running in other nodes, and it is performing 
the nat fucntion

correct?

>   
>> As i see it, the shara problem has two sides: the internal 
>> side (that goes between the host and where the public address 
>> and port range is
>> acquired) and the public side, that goes between the entity 
>> acquiring the address and the port range that the PRR.
>> I see these two sides somehow orthogonal. I mean, the internal 
>> side can be a network running private IPv4 with a nat in the 
>> CPE (which acquires the public address and the port range), it 
>> can be an IPv6 network, with a nat64 (which acquires the 
>> public IPv4 address and the port range) or can be just a host, 
>> which directly acquires the address and the port range.
>>     
>
> Good description.
>
>   
>> Now, i understand that we are focusing in the external part 
>> i.e. how does the CPE NAT/NAT64/host acquires the address and 
>> the port range and how is the ISP network works in the case 
>> this is used. We are not focusing in how the internal part 
>> works beyond to the fact that these 3 cases must be supported.
>>     
>
> I agree, we could look at the internal side as well, but we can leave that for later as well.
fwiw, i think the focus should be in the external side, but i am not 
suggesting that the considerations of the internal side are out of 
scope. I personally beleive that any approach that does not support all 
the identified internal scenarios is a non starter, so that part is very 
relavant. Just that ther may the need for additional protocol work, that 
may be different for the IPv4 NAT than the one for the NAT64 case than 
the one of the host, so that is why, i think we should focus in the 
common part.


>  But do we then have to call that as distributed NAT, as doesn't the name choice hint on one aspect of the internal side functionality then? Rather "distributed addresses" or "distributed shared addresses" or something?
>
>   

SHARA approaches?



>> I think we should scope the discussion to the external part of 
>> the problem (even if we need to understand the impact on the 
>> internal part, such as the impact in UPnp and the like)
>>     
>
> That is a good place to start discussions.
>
>   
>> So, i don't think that the case you bring is not considered in 
>> the bof, just that only the external part (of all use cases) 
>> is the focus
>>
>> I do agree that the distributed nat terminology is probably 
>> not the best option, but we were trying to rely on the 
>> terminology used in draft-townsley...
>>     
>
> Maybe the draft-townsley is not most up-to-date anymore - its missing discussion from interim, IETF#73, mailing list.. 
>
>   
agree (n i think the authors agree as well)


> I brought this up because the name "distributed NAT" sounded for me like BOF would be focusing too much on distributed NATs (thus missing benefits apps could obtain from NATless communication), while if I understand you now correctly the BOF is still focusing on shared addresses and pros/cons with those - which include the possibility of NAT distribution (which has its own PROs and CONs e.g. in relation to ALG deployment possibilities).
>   

right

>   
>> Makes sense?
>>     
>
> Yes. I think it would be good to define this internal and external separation on BOF description and say we focus on external part first. Will you update the BOF proposal to be more descriptive?
>
>   
i will
(Will wait for some additional feedback though)
thanks, marcelo



> Best regards,
>
> 	Teemu
>
>
>
>
>