Subject: Rethinking the transition: ditching IPv4

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 13 Jul 2007 13:14:12 +0200

Dear IPv6 operators,

For years now, we've been telling people that they should start  
running IPv6, or at least, start to think about running IPv6. This  
message was explicitly or implicitly accompanied by the notion that  
we'd be running IPv4 "for decades".

Now that the end of the IPv4 address space (down to 1099 million  
today from 1300 January 1st even though 46.0.0.0/8 was reclaimed)  
starts overlapping with medium-term planning (such as equipment  
purchases made today) people are actually thinking about IPv6.

But, not with the result we'd like to see: more often than not, the  
conclusion is: we need to support IPv4 anyway, layers of NAT and all,  
so adding IPv6 to IPv4 only makes things more complex and doesn't buy  
us anything until many others are using it first.

The way to get out of this vicious circle is to drop IPv4. IPv6  
network infrastructure is much simpler than IPv4 network  
infrastructure for several reasons:

- no need to carve small pieces of address space into even smaller  
subnets
- no need to guess at numbers of hosts per subnet
- no need to manage individual router addresses with EUI-64 addressing
- no need to do NAT

So kicking IPv4 out of your routers actually makes life simpler.

But we still need to talk to the IPv4 world. For very many  
applications, this can easily be done using proxies without incurring  
all the trouble that is lurking behind NAT-PT. For instance, see my  
little proof of concept draft:

http://www.ietf.org/internet-drafts/draft-van-beijnum-v6ops-connect- 
method-00.txt

However, proxied connectivity to the IPv4 world won't be good enough  
for all applications. But we can have our cake and eat it too if we  
can tunnel IPv4 over IPv6: this retains the simplicity of the routed  
IPv6-only network while still providing the full IPv4 experience  
where desired.

I understand that there is already a proposal that supports this:  
http://www.dstm.info/

I'm not sure if this is necessarily the best approach, I'm thinking  
some kind of PPP over IPv6 would be better, because PPP has a long  
track record. But the exact way in which this happens isn't the most  
important thing. What counts is that such a mechanism, much like dial- 
up, can provide individual IPv4 addresses to individual hosts as  
needed. This also allows two hosts right next to each other to have  
different classes of IPv4 connectivity (NAT/no NAT, firewalled/open)  
without the need to do complex things in the routed network.

And because addresses can be obtained/released as applications need  
them and no addresses are lost for subnetting, this allows for  
extremely efficient use of IPv4 resources.

An approach like this could actually simplify networks, and as such,  
make people happy to switch to IPv6. We don't have to do a whole lot  
to make this possible, providing some guidance on proxying and maybe  
a way to easily set up IPv4 over IPv6 proxying on demand is all  
that's really needed.

---

From: Mark Smith <[email-masked]>
Date: Sat, 14 Jul 2007 13:03:43 +0930

On Fri, 13 Jul 2007 13:14:12 +0200

> Dear IPv6 operators,
<snip>
> I understand that there is already a proposal that supports this:  

I haven't looked into dstm (had heard of it, haven't got around to
looking into it, thanks for the URL), however I've been thinking about
something similar to what you've mentioned above. Tentatively I've
given it the name "4to6". Here's a summary of the ideas. Please bear in
mind that some of them aren't fully thought through! :

* conceptually, IPv4 is carried over IPv6, like IPv4 is carried over
MPLS - IPv4 is natively present on the subnets of the edge of the "4to6
domain". IPv4 is tunnelled within IPv6 within the "4to6 domain", while
routers at the edge of the 4to6 domain encapsulate or decapsulate IPv4
in IPv6, with native IPv4 being used over the first and last hops.

* IPv4 subnets are assigned corresponding IPv6 subnets, coming from
within a reserved public IPv6 prefix. I'd though 2004::/16 would be a
nice one.

* The IPv6 "4to6" address is built by using the IPv4 prefix and prefix
length as follows :

[4to6 prefix/16 bits][IPv4 prefix/prefix length][filler zero bits][IPv4 node address]

e.g. for an IPv4 prefix of 1.0.1.1/24, the IPv6 "4to6" prefix would be

2004:0100:0100::1/40

for 2.2.2.2/30, the IPv6 "4to6" prefix would be 

2004:0202:0200::2/46

* The 2004:0100:0100::/40 IPv6 prefix would be announced in IPv6 RAs,
in addition to any other IPv6 prefixes, such as globals or ULAs

* "4to6" aware end-nodes would recognise the 4to6 reserved prefix, and
use the embedded IPv4 prefix information to generate an IPv4 address.
They could randomly pick the IPv4 host address, and use IPv6's DAD
procedures to avoid addressing collisions. In other words, IPv6's
addressing configuration mechanisms can be used to configure IPv4
addresses. If they need to send packets to a remote "4to6" node, which
they recognise by the destination prefix falling within the "4to6"
reserved prefix, they can perform the IPv4 in IPv6 encapsulation
themselves, rather than the upstream "4to6 domain" edge router having
to do it.

* The advantage of indirectly expressing the IPv4 prefix length in the
"4to6" IPv6 announced prefix length is that if there are two "4to6"
aware end-nodes attached to the same link, at the IPv4 layer, they'd
recognise that they are direct peers, and therefore can directly
communicate via IPv4 i.e. vanilla and standard IPv4 only operation. The
IPv6 encapsulation overhead is only borne when sending IPv4 traffic to
offlink IPv4 destinations.

* Legacy IPv4 only nodes would continue to operate as
normal. IPv4 PMTUD would cope with the overhead added by the "4to6"
encapsulation - of course that could be avoided by making the MTUs of
the links within the "4to6 domain" large enough to hide the
encapsulation overhead. Their addresses would be assigned via
conventional methods, although the upstream "4to6" edge router could
automate that, by using IPv6 methods to determine an available "4to6"
address e.g. via DAD, and then allocate addresses to the IPv4 only end
nodes via DHCPv4.

* It can be deployed incrementally. As routers have their software
upgraded to support "4to6", they can have their IPv4 routing protocols
disabled, and have IPv4 switched off on their non-IPv4 supporting links
to other "4to6" routers. The "4to6 domain" can be grown incrementally
over time, transparently to IPv4 nodes both already attached to it and
those that are newly attached to it.

* There would have to be a rule to prevent the IPv4 route table being
imported into the IPv6 DFZ via this "4to6" address mapping/method. This
can be easily enforced at the edges of the native IPv6 Internet if there
is a single /16 reserved prefix for the "4to6" IPv6 address space. The
"4to6" methods only meant to be used to support legacy IPv4 nodes in
local and native IPv6 domains, either during transition of those nodes
to IPv6, or to continue to support IPv4 nodes that cannot be upgraded
to IPv6. If those IPv4-only nodes need IPv4 Internet connectivity, the
IPv4 traffic would travel to the "4to6 domain" edge that is the closest
attachment to the IPv4 only Internet, to be then forwarded natively
over IPv4.

* As you've mentioned, the operational costs would be lower, as there
would only be a single IPv6 routing protocol running throughout the
network, and the only routing nodes that would need to be IPv4/IPv6
dual stack would be the ones on the edge of the "4to6 domain".
Troubleshooting with the "4to6 domain" is via standard IPv6
troubleshooting tools. IPv4 troubleshooting is limited to links at the
edge of the "4to6 domain."

* I've only just thought of this now, however as IPv6 is deployed, and
therefore IPv6 multicast capabilities are deployed at the same time, if
there is a mapping fir or ability to tunnel IPv4 multicast inside to
IPv6 multicast, then IPv4 multicast capabilities are being deployed at
the same time that "4to6"/IPv6 unicast is being deployed.

Would this sort of method achieve what you've been suggesting ?

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 14 Jul 2007 14:17:13 +0930

On Sat, 14 Jul 2007 13:03:43 +0930

<snip>

> offlink IPv4 destinations.

This was a bit wrong. It applies whether the end-node is "4to6" aware
or not.

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 14 Jul 2007 10:51:47 +0100

Mark Smith wrote:
[..]
> e.g. for an IPv4 prefix of 1.0.1.1/24, the IPv6 "4to6" prefix would be

What you are describing any further just looks an awful lot like 6to4,
see RFC3056 + RFC3068, with the exception that you want to abuse another
/16 for this and re-introduce NATPT. It uses: 2002:<aabb>:<ccdd>::/48

When going over IPv6 it is native IPv6, when going over IPv4 it becomes
IPv6 in IPv4. One would just have to extend this with magic saying that
when the last 32bits match the host itself it should strip the IPv6
header or something similar and do the translation to native IPv4.

You need to upgrade all your client programs to support IPv6 in this
case, it could avoid the server to be upgraded, but hey then you get
into NAT situations and it is all just NATPT again anyway.

Better keep your network like most people at the moment have:
 - Native IPv6 with public IPs for every host
 - NAT for IPv4 (unless one is able to get public IPs for their hosts)

This mechanism is called dual-stack, it is very simple, and allows all
hosts to very cleanly use all their programs, albeit maybe some
protocols are not happy with the NAT but one would have that with NATPT
too so that doesn't matter. For IPv4 addresses, just use RFC1918.

As for the native IPv6 part, which is one of the biggest challenges
today it seems with not enough ISPs providing IPv6 connectivity yet: use
a tunnel, there are enough providers who are able to do that for free
even and quite a number nowadays who can provide paid connectivity too.

> in addition to any other IPv6 prefixes, such as globals or ULAs

You can't RA a /40. You can RA a /64 though, thus you have to subnet it
first.

Greets,
 Jeroen

---

From: Mark Smith <[email-masked]>
Date: Sat, 14 Jul 2007 20:54:52 +0930

On Sat, 14 Jul 2007 10:51:47 +0100
Jeroen Massar <[email-masked]> wrote:

> see RFC3056 + RFC3068, 

No, not at all. It's sort of the the reverse of 6to4, hence the
tenative name of "4to6".

The purpose of this is to automatically tunnel IPv4 over IPv6, except
for the first and last hops of the IPv4 forwarding path, within a local
domain e.g. an enterprise network, site or AS. 

The current model of introducing IPv6 to an existing IPv4 network,
other than parallel hardware deployment, or MPLS 6PE, seems to be dual
stack everywhere, including in the non-edge routers of your network.
Deploying dual stack is quite resource intensive, due to having to run
both IPv4 and IPv6 forwarding tables, and for organisations not running
IS-IS, dual "ships in the night" routing protocols on every router.
This would be a common implementation scenario for most enterprise
networks, and possibly could be one of the reasons for some resistence
to deploying IPv6 - they've only sized their hardware for IPv4, so are
faced with expensive upgrades or hardware replacements. My suggested
method and other similar ones might not require that.

Broadly, it is the MPLS model. IPv4 only at the edges, IPv6 natively
across the network (within the scope of where ever this method is
implemented), and the IPv4 aware edge routers automatically tunneling
IPv4 in IPv6 between the edge routers. No dual stack required on
routers that are not at the edges of the network, no IPv4 routing
protocols required at all, and only a single IPv6 routing protocol.
This assumes that a single forwarding toplogy for both IPv4 and IPv6 is
acceptable, and I think most organisations who'd use this method would
be happy with that because it's simpler, predictable and easier to
manage link capacity. That's typically how people deployed IP, IPX or
Appletalk in parallel in the past.

> with the exception that you want to abuse another

I probably should have deleted the 2nd paragraph that I left in - I was
addressing Iljitsch's paragraph before, and leaving the 2nd paragraph
in might have confused the issue.

I'm only presenting a method of transitioning a local network to IPv6
while continuing to support either legacy IPv4 nodes or IPv4/IPv6 nodes
that continue to require IPv4 addresses. I'm not trying to provide any
sort of gateway between native IPv6 nodes and the IPv4 Internet. A
network with the above "4to6" method implemented would probably have a
native connection to the IPv4 Internet and a separate native connection
to the IPv6 Internet.

> You can't RA a /40. You can RA a /64 though, thus you have to subnet it

The main idea behind this was to express the IPv4 prefix information,
including the IPv4 prefix length within an IPv6 RA. 

This idea was so that "4to6" aware end-nodes (which are
also native IPv6 nodes) could perform the encapsulation of IPv4 inside
IPv6 for non-local destinations themselves, rather than having the
upstream first hop router do it, taking some of the load off of it.

Such a node might be one that only has native IPv6
external connectivity, yet provides access to IPv4 destinations, with
the IPv4 address configured on an internal loopback interface, rather
than on any physical ones. This scenario might apply to a residential
ISP who deploys native IPv6 only on the link to the customer, yet
continues to provide access to the IPv4 Internet, by announcing the
"4to6" prefix in an RA, containing the embedded public IPv4 address
that the end user would use.

If this is useful and able to be done (there could be an issue with
IPv4 traffic coming from the ISP's router to the customer being
decapsulated from IPv6, rather than just being forwarded directly to
the IPv6 node - I still haven't thought through everything fully), then
I think the zero bit filled part of the mapping that I suggested
further could be shifted to directly after the reserved /16, rather
than after the IPv4 prefix bits.

Regards,
Mark.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 14 Jul 2007 15:10:46 +0200

This is what softwires do, and the reason why we developed it. No need for
anything else.

Regards,
Jordi

> De: Mark Smith <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Sat, 14 Jul 2007 20:54:52 +0930
> Para: Jeroen Massar <[email-masked]>
> CC: Iljitsch van Beijnum <[email-masked]>, IPv6 Operations
> <[email-masked]>
> Asunto: Re: Rethinking the transition: ditching IPv4
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Mark Smith <[email-masked]>
Date: Sat, 14 Jul 2007 23:21:45 +0930

On Sat, 14 Jul 2007 15:10:46 +0200

> This is what softwires do, and the reason why we developed it. No need for

That's convenient, I'll start reading up.

Thanks,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sun, 15 Jul 2007 19:06:15 +0930

Hi,

> This is what softwires do, and the reason why we developed it. No need for

I've had a bit of a read, and I think softwires is providing a solution
to a problem quite different to the one I'm describing. Softwires seems
to be focusing on a service provider/customer tunnelling problem, where
as the focus of my suggested method is an alternative IPv6 transition
mechanism for the interior of the service provider or enterprise
network.

As an example of how different they are, in the method I've suggested,
there is no need for any sort of control protocol to negotiate and
bring up a tunnel. If an edge "4to6" router receives a IPv6 "4to6"
route via the native IPv6 IGP from a remote "4to6" router, then the
local "4to6" router already knows from that "4to6" route advertisement
it received that 

* there is a contiguous and currently available native IPv6 path to the
remote "4to6" router

* the range or set of IPv4 destination addresses  it should
encapsulate in IPv6 to forward towards that remote "4to6" edge router,
based on the embedded IPv4 prefix value and prefix length received in
that "4to6" route advertisement

In effect, the "4to6" tunnels are dynamic, and the IPv6 IGP is
operating as the tunnel provisioning and availability protocol. 

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sun, 15 Jul 2007 20:03:06 +0930

On Sun, 15 Jul 2007 19:06:15 +0930
Mark Smith <[email-masked]> wrote:

> to a problem quite different to the one I'm describing.

Ok, my mistake, I've had a bit more of a read, and found that the
"softwires mesh model" describes what I'd suggested.

Regards,
Mark.