North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: ISP and NAT (question and some thoughts)

  • From: Alex P. Rudnev
  • Date: Mon Oct 18 13:45:45 1999 
The problem with the address space is not in the packets themself (the IP
address can be _easily_ increased by the source-routing, for example); the
primary problem is in the existing applications which has only 1 DST ip
address and 1 DST port.

The address space can be increased by the DST-port space, but DST port
exist only at the L4 (if we treat IP as L3 and TCP as L4, don't blame me
please) level and this prevent a lot of Internat interaction (ICMP
interaction, for example) from work. NAT does the same, but in the hidden
manner, and it can use IP<->IP direct translation if necessary.

There was a few papers sent here, all with the same mistake - the lack of
address space exist not in the IP packet (use the pair PROVIDER,CUSTOMER)
address schema to deliver the packet, with the SO option; but in the TCP,
UDP and other IP stacks (TCP connection is identified ny the
DST(A,P),SRC(A,P) set of parameters, where to place PROVIDER address
here).

On the other hand, NAT engine became more and more robust, it allow to do
more and more with it; but just this make this engine more and more
complex - too complex for the end customer... This was the core reason of
my message below.

/ All written was not the set of axioms, of course.
Alex.

 On Mon, 18 Oct 1999
[email protected] wrote:

> Date: Mon, 18 Oct 1999 13:13:18 -0400
> From: [email protected]
> To: Alex P. Rudnev <[email protected]>
> Cc: [email protected]
> Subject: Re: ISP and NAT (question and some thoughts)
> 
> 
> 
> just a thought...
> 
> why not expand the IPv4 address field using the 'Fragment offset' and
> 'Identification' fields?
> Use those fields to mark packets at the edge with the destination AS number, for
> example.
> Customer equipment could use private address space and not bother with the edge
> remarking process.
> (I know that the fragmentation function would be lost due to this 'extension'.)
> (I am also aware of transitioning problems related to what I am proposing; the
> routers in the network cannot be upgrade all at once...)
> 
> thoughts/comments?
> 
> jld.
> 
> 
> 
> 
> 
> "Alex P. Rudnev" <[email protected]> on 10/18/99 12:46:50 PM
> 
> To:   [email protected]
> cc:    (bcc: Jeanlou Dupont/RMQ/RELTECCORP)
> 
> Subject:  ISP and NAT (question and some thoughts)
> 
> 
> 
> 
> 
> 
> Today we see the classical schema ISP/customer; this means
> - the customer have his own address space, requested by him (directly or
> undirectly)
> - due to the lack of public addresses, the customers are forced to use
> NAT; just NAT provide some extra security
> - ISP do not provide NAT themself; NAT configuration is not easy task and
> cause a lot of headache for the customers (just as a lot of money they pay
> to the network admins).
> 
> First question - is this picture right or it is wrong?
> 
> The second question. What prevent the _future ISP_ from some another
> schema, when:
> - the customer always use the private address space, for example,
> 10.0.0.0/8;
> - the provider bother about address translation, just as about name
> translation (DNS re-writing), just as about the address allocation (not
> the customer but the provider - if existing address space is not enough);
> - the providers's software learn about _open, or public_ services which
> must be translated statically, from the customer using (for example) DNS.
> 
> Don't answer _it's too slow_.
> 
> This is my attempt to predict where we are going this days. Today the
> _know-how_ the customer should know is too huge - if (if I am the admin of
> the company, not ISP!) I open electronic
> market or want to get Internet for the companies employees, I must
> allocate space (why? What for? It's not my concern, if we think a little),
> I must prove I need this addresses (why? This is my business how much
> addresses I need internally; and let's software decide how much addresses
> I need externally), and I should configure firewalls and NAT's. We used to
> think about it as about the normal admin's knowledge; but why we are sure
> it's normal. If you got a car (in USA, not in the Russia), you don't
> bother about the oil stations or about the roads - you just use it.
> 
> This is not really a dump question. If it is possible to build such
> Internet service when every customer should be free to use any address
> space in the hidden way, and ISP (not the customer) bother about the
> global address and name translation, we should have just this hierarchical
> address schema IPv6 offer to us. On the other hand, it means a great
> increase in the NAT engine.
> 
> 
> Aleksei Roudnev, Network Operations Center, Relcom, Moscow
> (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N
> 13729 (pager)
> (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
> 
> 
> 
> 
> 
> 
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)