Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

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 15:14:56 1999

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)






Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.