[25554] in North American Network Operators' Group
Re: ISP and NAT (question and some thoughts)
daemon@ATHENA.MIT.EDU (Alex P. Rudnev)
Tue Oct 19 06:03:55 1999
Date: Tue, 19 Oct 1999 13:55:57 +0400 (MSD)
From: "Alex P. Rudnev" <alex@virgin.relcom.eu.net>
To: Hank Nussbacher <hank@ibm.net.il>
Cc: Dean Anderson <dean@av8.com>, jeanlou.dupont@na.marconicomms.com,
nanog@merit.edu
In-Reply-To: <3.0.5.32.19991019081717.008006d0@max.ibm.net.il>
Message-ID: <Pine.SUN.4.10.9910191354520.547-100000@virgin.relcom.eu.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
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
> jeanlou.dupont@na.marconicomms.com 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" <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)
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > Plain Aviation, Inc dean@av8.com
> > 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)
