[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rethinking the transition: ditching IPv4
This is what softwires do, and the reason why we developed it. No need for
anything else.
Regards,
Jordi
> De: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Sat, 14 Jul 2007 20:54:52 +0930
> Para: Jeroen Massar <jeroen@unfix.org>
> CC: Iljitsch van Beijnum <iljitsch@muada.com>, IPv6 Operations
> <v6ops@ops.ietf.org>
> Asunto: 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.
>
**********************************************
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.