Re: [v6ops] IPv4 trajectory

[Alexandru Petrescu <[e-mail]>]

Le 31/03/2015 07:35, Fred Baker (fred) a écrit :
[...]

> 1) IPv4-only network
> 2) IPv4 with bits of IPv6 here and there, in some combination of overlay and native
> 3) IPv4+IPv6 (native) dual stack network
> 4) IPv6+IPv4 non-native, translated or overlay (e.g., as a service)
> 5) IPv6 with little bits of IPv4 here and there; your printer might be an example
> 6) IPv6-only

Makes sense.  These are qualifiers for networks.

One would try to fit in the computers as well, as the printer example.

It is customary to see current computers having both an IPv6 stack and 
an IPv4 stack on them.  But some computers only have IPv4, whereas the 
rest have IPv4 and IPv6 stacks.  There are no computers (to my 
knowledge) which have only IPv6 stacks.

Recently we noticed a cellular end-user device which can work only in 
IPv6 mode, or only in IPv4 mode.  But it can not have both an IPv4 
address and an IPv6 address on it even though the network to which it 
connects offers it both simultaneously on same APN.

>
> In steps 1 and 2, it is an IPv4 network, possibly with some toys in
> it playing IPv6. We might have toys playing AppleTalk and DECNet too.
> IPv4 is the workhorse, and toys is toys.
>
> In step 3, every host in the network has an IPv4 address and an IPv6
> address, or constructively could have if it wants one, and every
> router is carrying IPv4 routing as well as IPv6 routing. It’s likely
> multiplexing IPv4 addresses, and IPv4 is increasingly broken. But the
> big question is what applications and providers support IPv6; as long
> as a big one (Skype?) is not making the transition, people have a
> business reason to keep IPv4 going. As applications become dual
> stack, traffic levels approach a 50/50 distribution, barring some
> specific reason they would be forced to IPv4 or IPv6.
>
> Right now, most networks are still in step 1, and those that have a
> clue are somewhere between step 2 and step 3. But some are moving, or
> at least experimenting, with step 4.

I agree.

> steps 4-6 are fundamentally about an IPv6 network.

I agree, we're not there yet.

> In step 4, the network is optimizing configurations and costs by
> making IPv4 a translation or an overlay, but IPv4 remains an
> important aspect of the network. Obvious examples include anything
> listed. IPv4 might reach the host one way or another, or be
> translated some distance away, but a client using IPv4 can reach an
> IPv4-only server, and it can reply, and part of the path in between
> is IPv6-only.
>
> In step 5, IPv4 has taken a place comparable to AppleTalk; yes,
> there’s some there, but where, precisely? And in step 6, we have
> finally turned IPv4 off entirely, and with it probably Bisync and
> X.25.
>
>
> Now, what assumptions am I making? I believe that an IPv4 packet can
> make it end to end until step 5; it might spend part of that as a
> translated IPv6 packet or in a tunnel of some kind, but it can get
> there. As of step 5, that is no longer the case. Exactly how that
> happens is Not My Department. Note that many core networks don’t
> describe themselves as IPv4, IPv6, or dual stack networks; they
> describe themselves as MPLS networks that carry IP as a payload.
>
>
> Listing LISP... to me, LISP is yet another encapsulation, a tunnel
> broker, and one that is particularly complex. It can carry IPv6
> across an IPv4 network or IPv4 over an IPv6 network. Someone
> suggested it should be on the list, and it’s on the list. One thing I
> actually expect is that the list of technologies we might invite
> deployment reports regarding is longer than the list of technologies
> people actually use. We might learn something from that.

Makes sense.

Alex

>
>
> Is anyone’s head exploding yet? >
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>