|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: ISP and NAT (question and some thoughts)
Hmm, there is some interesting idea in this message - to keep some track of the initial (pre-NAT) address/port somewhere in the packet (may be in the start packets, at least)... > > I think this has merit. If I understand RSIP correctly (which is meant to > replace NAT), you need an RSIP enabled client and an RSIP enabled router. > Therefore, people are considering doing deployment changes. Problem is > that once the pkt leaves the RSIP enabled router destined to the Internet, > one has no idea that the IP address and port number (auto-generated by the > RSIP router) are really masking a NAT address. By tweaking a bit in the > IPv4 header (that is transitive and won't harm anyone by looking at it) as > you suggested might make more sense and thereby give downstream users an > idea that the pkt they are seeing is really an RSIP modified packet. > > Basically - a merge of RSIP and your idea. Any IETF RSIP people want to > pick up on this? > > -Hank > > > > > >There are a couple of unused bits in the IPv4 header that one could use. > I thought of this during the last "paper" to expand address space that > circulated this summer on nanog. > > > >Unfortunately, the real problem is deployment. Once you decide to change > the protocol in any way that is not completely downward compatible, > everyone has to deploy the modification. I'm going to hazard a guess that > IPv6 will really be widely deployed by tunneling it in IPv4. And I'll > hazard that much of the IPv6 traffic will just contain tunnelled "private" > IPv4 traffic. Tunnel inside tunnel. So much for header compression. > > > > --Dean > > > >Around 01:13 PM 10/18/1999 -0400, rumor has it that > [email protected] said: > >> > >> > >> > >>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) > >> > >> > >> > >> > >> > >> > >> > >> > >> > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Plain Aviation, Inc [email protected] > > LAN/WAN/UNIX/NT/TCPIP http://www.av8.com > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > 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)
|