[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Re: IPv4/6/ngng or IPv4-map-encap then IPngng
Robin,
On Jun 11, 2008, at 9:32 PM, Robin Whittle wrote:
1) IPv4 + NAT, more NAT, and forever NAT
2) IPv6 + some new network element (ITR/ETR, a new layer,
a new transport protocol, etc.)
3) IPngng
OK. What about:
3a) Map-encap for IPv4.
which gives us more time to think properly about:
3b) IPngng
My understanding of the situation is that the immediate problem with
IPv4 isn't (I'm told) routing scalability, but rather addressable end
points. As more IPv4 end points are put into play, it will exacerbate
the routing scalability problem, but we've been there before and the
tools we used then (filtering) will undoubtedly be used again. As
such, (3a) solves a different problem than the one that is likely to
drive increased IPv6 utilization.
OK, but aren't we busying ourselves here making a mere
recommendation to this outfit who are so disconnected from reality?
My hope, at least, is that our recommendation will allow for at least
some reconnection with reality.
I am
convinced there is enough scope for NAT and efficient use of IPv4 -
especially with map-encap - to keep IPv4 going indefinitely.
Indeed. However, if you're doing NAT, what's the point of doing map-
encap? As others have noted, NAT effectively creates a locator/
identifier split, allowing the public address to be (relatively)
easily renumbered without impacting the RFC 1918 identifiers inside
the NAT boundary.
Still, if NAT-PT hasn't been used for more than a few tests with the
IPv6 faithful
I suspect this is because IPv6 itself hasn't been used for more than a
few tests with the IPv6 faithful.
Since we are talking revolution ...
[much elided not because there is anything wrong with it, but because
I think it something of this nature should be put into draft form]
I remain unconvinced that a revolution is actually realistic. I never
got an answer to my question regarding what people think is "Doing it
Right" or even what is "Doing it Wrong", but if you make the
assumption that having something that is actually used is a part of
"Doing it Right", the _only_ way we're going to get their (at least in
my lifetime) is by evolutionary incremental change.
However, with all that said, one advantage of map-encap (done right)
is that the stuff that is mapped and encapped can be fixed for all
eternity while the stuff that transports the encapped stuff can be
changed. As such, fixing something that has a reasonable chance of
being scalable for all eternity (e.g., 128 bits) seems like a
reasonable thing to do.
Regards,
-drc
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg