Re: [shara] Updated SHARA BOF description

["[e-mail]" <[e-mail]>]

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.

>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. 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?

>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.. 

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).

>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?

Best regards,

	Teemu