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
The problem with the address space is not in the packets themself (the IP
address can be _easily_ increased by the source-routing, for example); the
primary problem is in the existing applications which has only 1 DST ip
address and 1 DST port.
The address space can be increased by the DST-port space, but DST port
exist only at the L4 (if we treat IP as L3 and TCP as L4, don't blame me
please) level and this prevent a lot of Internat interaction (ICMP
interaction, for example) from work. NAT does the same, but in the hidden
manner, and it can use IP<->IP direct translation if necessary.
There was a few papers sent here, all with the same mistake - the lack of
address space exist not in the IP packet (use the pair PROVIDER,CUSTOMER)
address schema to deliver the packet, with the SO option; but in the TCP,
UDP and other IP stacks (TCP connection is identified ny the
DST(A,P),SRC(A,P) set of parameters, where to place PROVIDER address
here).
On the other hand, NAT engine became more and more robust, it allow to do
more and more with it; but just this make this engine more and more
complex - too complex for the end customer... This was the core reason of
my message below.
/ All written was not the set of axioms, of course.
Alex.