ISP and NAT (question and some thoughts)

Alex P. Rudnev alex at virgin.relcom.eu.net
Mon Oct 18 18:29:29 UTC 1999


Yes, but...

The first step doing any increase difficult was done when the
HOST_NAME->IP_ADDRESS translation was chosen instead of

 HOST_NAME:SERVICE -> IP_ADDRESS:PORT

Now we have a lot of troubles due to this choose.


On Mon, 18 Oct 1999 jeanlou.dupont at na.marconicomms.com wrote:

> Date: Mon, 18 Oct 1999 13:33:14 -0400
> From: jeanlou.dupont at na.marconicomms.com
> To: Alex P. Rudnev <alex at virgin.relcom.eu.net>
> Cc: nanog at merit.edu
> Subject: Re: ISP and NAT (question and some thoughts)
> 
> 
> 
> 
> 
> oups... just thought of an important issue:
> 
> I guess the clients would care about the address remarking;
> the DNS process is a good example...
> 
> jld.
> 
> 
> 
> ---
> 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" <alex at virgin.relcom.eu.net> on 10/18/99 12:46:50 PM
> 
> To:   nanog at merit.edu
> 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)





More information about the NANOG mailing list