Re: ISP and NAT (question and some thoughts)

[jeanlou.dupont () na marconicomms com]

I guess going to IPv6 would be simpler in this case.
Or, we can maybe dream of some 'service locator' function tied to inter-domain
MPLS tunnels...

again, just food-for-thoughts.
jld.





"Alex P. Rudnev" <alex () virgin relcom eu net> on 10/18/99 02:29:29 PM

To:   Jeanlou Dupont/RMQ/RELTECCORP@RELTECCORP
cc:   nanog () merit edu

Subject:  Re: ISP and NAT (question and some thoughts)




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 () na marconicomms com wrote:

> Date: Mon, 18 Oct 1999 13:33:14 -0400
> From: jeanlou.dupont () na marconicomms com
> To: Alex P. Rudnev <alex () virgin relcom eu net>
> Cc: nanog () 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 () virgin relcom eu net> on 10/18/99 12:46:50 PM
>
> To:   nanog () 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)