[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rethinking the transition: ditching IPv4
On Fri, 13 Jul 2007 13:14:12 +0200
Iljitsch van Beijnum <iljitsch@muada.com> wrote:
> Dear IPv6 operators,
>
<snip>
>
> 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 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.