Re: ISP and NAT (question and some thoughts)
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)
No any solutions touching _application_ level could survive in a few next years... (IPv6 for example). On Mon, 18 Oct 1999 jeanlou.dupont@na.marconicomms.com wrote:
Date: Mon, 18 Oct 1999 14:45:57 -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)
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)
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)
participants (2)
-
Alex P. Rudnev -
jeanlou.dupont＠na.marconicomms.com