[RRG] IPv4/6/ngng or IPv4-map-encap then IPngng

[Robin Whittle <rw@firstpr.com.au>]

Hi David,

I haven't been able to reply to all the interesting RRG messages,
but here goes for this one, in the "Re: [RRG] GSE?" thread:

> More seriously, the reality is that to date, IPv6 has seen
> essentially zero use so ripping it out and replacing it with
> something else would not operationally impact significant numbers
> of people.

I agree.

> However, with that said, I would agree that this isn't so much a
> technical issue as a political one.  

Yes, in terms of gathering the troops with a common purpose which
will actually prepare the new planet for billions of non-technical
colonists, in a short enough time that they don't become toast on
the old planet.


> From my perspective, I have always felt we have 3 options:
> 
> 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
> 
> As far as I can tell, proposals to "Do it Right" are option (3)
> since they will require pretty much the same level of effort in
> terms of redeploying protocol stacks and modifying applications
> (I'd argue that applications knowing address structure and
> keeping copies of addresses in their data space is an example of
> how to "Do it Wrong").
> 
> I'm hoping we can get by with option (2).
> 
> I suspect we're going to end up with option (1).

OK.  What about:

  3a)  Map-encap for IPv4.

which gives us more time to think properly about:

  3b)  IPngng

I have my own ideas about that, since it needs to have a much better
migration plan than IPv6 did.

>> NAT-PT has been buried
> 
> Please don't take the actions of the IETF as reflections on
> reality.  

OK, but aren't we busying ourselves here making a mere
recommendation to this outfit who are so disconnected from reality?

Maybe so . . .   IPv6 was never attractive enough to folks to
actually adopt, let alone adopt to the exclusion of IPv4.  I am
convinced there is enough scope for NAT and efficient use of IPv4 -
especially with map-encap - to keep IPv4 going indefinitely.  That
is not what I want - because it is easy to imagine something better.
 But without something more immediately useful than IPv6, and with a
much better transition arrangement, I think the population en-masse
is going to stay *together* on Planet IPv4 no matter how hot it gets.

The big thing about the Internet is that it is everyone together.
On IPv6 it is rather lonely and misses the point - until everyone
else moves too.


> In all of the recent IPv6-only 'experiments' that have
> taken place at operations meetings, the IETF, and RIR meetings,
> _all_ of them used NAT-PT.  Some reasonably successfully.  Like
> NAT itself, NAT-PT meets a functional need and the market will
> make its own decisions as to whether it lives or dies, regardless
> of what folks at the IETF might say.

Still, if NAT-PT hasn't been used for more than a few tests with the
IPv6 faithful - that is is it not suitable for Comcast etc. to sell
IPv6 only services to the mass market - and if has been officially
junked by the IETF, then I say that IPv6 migration arrangements are
a shambles.

Below is a wild and crazy IPngng idea.

  - Robin


<cue: eye-rolling & exasperation from those who have seen too
      much similar stuff before>


Since we are talking revolution, what about keeping BGP as it is,
doing Ivip-like map-encap with TTR mobility for IPv4.  Later, we
create a new version of IP - say IPv99 (in homage to the Secret
Agent and because no-one will need a later version . . ) with 64 bit
addresses.

This is intended to offer a much cleaner transition mechanism for
applications and end-users than IPv4 offers.  There are no
dual-stack machines - the IPv99 stack handles IPv4 as a natural
subset of its operations.  IPv99 applications can always talk
directly to IPv4 hosts, but this is just a sketch and there are many
other things to consider.  Probably IPv4 connectivity to IPv99 hosts
would be limited.

An IPv99 address such as:

   xx xx xx xx 00 00 00 00 (hex)

represents the existing IPv4 address xx xx xx xx.

Packets addressed from IPv99 hosts to such addresses go to IPv4
hosts, either by IPv4 packets directly (the sending host has IPv4
and IPv99 connectivity) or via IPv99 and then to some ALG or
whatever which sends them as IPv4 packets and handles the returning
packets too.

Packets with addresses:

   xx xx xx xx 00 00 00 01
to xx xx xx xx FF FF FF FF

are IPv99 native addresses.

Ultimately there may be a native IPv99 backbone, and there would be
a native IPv99 header, of course.

In the meantime, all IPv99 hosts in the above address range can be
reached via a router at the IPv4 address xx xx xx xx.  This includes
especially if this xx xx xx xx address is handled by map-encap.

(For better or worse, overall IPv99 address allocation is therefore
based on existing IPv4 allocation.  Good because no new mechanisms
are needed and because each IP address gives a potentially vast
number of IPv99 addresses at a site.  Bad, probably, because it
imports stuff which may be suboptimal forever into IPv99.)

So you could have 2^32 uniquely addressable IPv99 hosts reachable
over the IPv4 Internet, via each IPv4 address, including especially
having them reachable via a portable, multihomable and potentially
mobile single IPv4 address.  There are PMTU things to sort out with
all this, but that needs to be sorted anyway as part of the IPv4
map-encap system.

All IPv99 hosts have a new stack, which translates between the
outside world and the IPv99 API for IPv99 applications.  Maybe an
IPv99 machine can run unmodified IPv4 applications via some
adaptation layer which enables the unmodified IPv4 apps to talk
through the actual IPv99 stack to IPv4 addresses only.  (This would
involve some ALG or NAT-like device with IPv4 address space.)

Packets sent to and from IPv4 addresses within the IPv99 address
space are sent with IPv4 headers and IPv99 addressed packets are
sent with IPv99 headers.  How the packets get to their destination
depends on what other IPv99 networks the host has a native
connection to and whether it has an actual IPv4 service, or reaches
IPv4 hosts via the IPv99 service.

Applications would require something of a rewrite, but could still
do IPv4 things with the IPv4 Internet, so perhaps it is not really a
dual-stack system.

To what degree the IPv99 to IPv99 communications would differ from
existing IPv4 protocols I am not sure, but I would want to add some
kind of PMTU discovery message which could test the MTU along a
bunch of routers without actually being very long itself.  However,
to make that happen over the existing IPv4 DFZ would require
significant changes to those routers.  I am more thinking about an
IPv99 future, with a more elegant PMTU handling arrangement in all
its routers than is the case with IPv4 or IPv6.

The key thing is to make a new protocol which sees the IPv4 world as
a special subset of its own space and protocols, and which uses the
IPv4 network with map-encap to avoid the need, initially, for a new
backbone.  The robust multihoming, portability and potentially
mobility of map-encap makes this much more attractive, I think, than
relying on the existing /24 limits of BGP to slice up the IPv4 space
as the basis for a lasting 32 bit extension such as this.

I am not sure if there have been other attempts to use a robust,
finely slicing, map-encap IPv4 infrastructure as the basis for
IPngng flights of fancy such as this.

There could be hundreds of millions of separate IPv99 networks
accessible reliably over IPv4, without much further burden on the
IPv4 BGP control plane.

I still think 128 bits of address is 64 too many.  They are long to
store and process, since 64 bits is a perfectly good length for a
CPU register.  128 bits bloats the headers excessively, especially
for VoIP packets and doubly so for map-encap IPv6.

I am not sure whether map-encap would be used within the native
IPv99 network.  A native IPv99 network would probably need its own
map-encap system for multihoming, TE and portability, so it might as
well be used for mobility too.  How that would blend with or be
based on the original IPv4 map-encap system, I am not sure.  Would
it slice finer than the left-most 32 bits?

(Maybe a GSE-souped-up IPv6 wouldn't need map-encap for multihoming
and portability.  It would need it for TTR-style mobility.  I am not
sure how GSE-IPv6 would do TE.)







--
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