North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: ISP and NAT (question and some thoughts)
No any solutions touching _application_ level could survive in a few next years... (IPv6 for example). On Mon, 18 Oct 1999 [email protected] wrote: > Date: Mon, 18 Oct 1999 14:45:57 -0400 > From: [email protected] > To: Alex P. Rudnev <[email protected]> > Cc: [email protected] > 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" <[email protected]> on 10/18/99 02:29:29 PM > > To: Jeanlou Dupont/RMQ/[email protected] > cc: [email protected] > > 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 [email protected] wrote: > > > Date: Mon, 18 Oct 1999 13:33:14 -0400 > > From: [email protected] > > To: Alex P. Rudnev <[email protected]> > > Cc: [email protected] > > 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" <[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) > > > > > > 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)
|