[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rethinking the transition: ditching IPv4
On Sat, 14 Jul 2007 10:51:47 +0100
Jeroen Massar <jeroen@unfix.org> wrote:
> Mark Smith wrote:
> [..]
> > * 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
>
> What you are describing any further just looks an awful lot like 6to4,
> 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
> /16 for this and re-introduce NATPT. It uses: 2002:<aabb>:<ccdd>::/48
>
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.
> 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.
>
> > * 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
>
> You can't RA a /40. You can RA a /64 though, thus you have to subnet it
> first.
>
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.