×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Question on creating a 6to4 Tunnel Address for the site prefix

Answered Question
Mar 12th, 2014
User Badges:

Hi All,

Question on IPv6 6to4 tunneling:

When I go to assign an IPv6 address to my LAN-side router port that will ultimately be used in the /48 site prefix, are there any rhymes or reason on how they should be created other than starting with 2002?

For example:

If my WAN port address on my router is 68.86.75.12/24, and I specify my tunnel source as this WAN port, then on my LAN port I specify the IPv6 address used to derive the site prefix, do I have to convert 68.86.75.12 into hex format, coming up with:

2002:4456:4b0c:1111::1/64, which then translates to site prefix 2002:4456:4b0c/48?

Or can I pretty much just make up whatever I want as long as it isn't on a private space (i.e. fec0)?

Also, would all of my hosts sitting behind the LAN port assigned with 2002:4456:4b0c:1111::1/64 also have to have addresses assigned on the 2002:4456:4b0c:1111 prefix? Or can the hosts use private addressing like feco or fc00?

Thanks Guys,

Dean R

Correct Answer by James Leinweber about 3 years 5 months ago

6to4 tunnel address are comprised of:

   2002 IANA assigned prefix + 32 bits of public IPv4 address + 80 bits of site/host info

So, yes, you have to convert 68.86.75.12 into exactly :4456:4b0c:  You get to play with the bottom bits if you like; post-Vista windows will repeat the v4 address in the bottom 32 bits, for example.  The design was premised on the idea that most sites would eventually have native /48s routed their way, and you could use the same 16-bit subnet design and 64-bit hosts parts with your initial 6to4 addresses as with your eventual public addresses. 

If you had a native v6-only host talking to your own 6to4 border relay your relay could replicate your internal v6 subnet & host part across the tunnel to the destination in the bottom 80 bits.   If you have multiple hosts sharing a single uplink gateway, they do all have to use the same /48 prefix that lives on the outside v4-only interface of the gateway.  Getting individual packets back to the correct host would be an exciting exercise for your dual-stack inside gateway and v6 firewall. 

6to4 was really designed for individual dual stack hosts each with its own public v4 address that didn't have native IPv6 uplink.  In an era of IPv4 exhaustion, multiple hosts behind v4-NAT boxes, and increasingly availble native v6, 6to4 is an obsolete transition model.

The only v6-address a remote v6 server can be allowed to see is the special 6to4 address; if you have multiple inside hosts your gateway/firewall has to handle mapping the lower 80 bits of the 6to4 addresses with the common /48 prefix back to whatever your internal v6 addresses are.  If your v6 hosts are on fd00::/7 ULA site-scope v6 addresses this will be in addition to rather than instead of their 6to4 addresses with the shared /48 prefix, and unless they are unusually well behaved and using very recent software they may be spraying a mixture of v6 6to4 and ULA source addresses around more or less at random, with very bad connectivity results.

The fec0::/10 "site-local" addresses were officially deprecated in favor of fd00::/7 ULA in 2004 by RFC-3879, and conforming v6 routers will actually reject packets with those addresses rather than forwarding them.

What's going on is that the 3rd-party anycast dual-stack relays which you are hoping exist somewhere are advertising 192.88.99.0/24 routes on their v4 side and 2002::/16 routes on v6, and doing stateless conversion between 6to4 IPv6 addresses and native IPv4 addresses for any packets that happen to come their way.  In order for the protocol-41 wrapping to work there has to be a fixed mapping from  the embedded, special form v6 address back to your unique, public v4 address.  So you can't pick bits 17-48 of the address at random, or the far relay won't be able to return the v4-encapsulated v6 payload packets back to you.

All of the automatic tunneling mechanisms like Teredo, 6to4, and ISATAP are being deprecated for unreliable delivery, inadequate security, excess latency, and jitter reasons compared to native v6.  For problems with 6to4 specifically, see e.g.

   http://www.potaroo.net/ispcol/2010-12/6to4fail.html

The modern alternative to 6to4 is to have an ISP with native v6 at its border run 6rd between an in-ISP relay and upgraded CPE modems at the customers; French ISP "FREE" was among the first to do this.  It's a temporary expedient until the ISP finishes getting native v6 all the way to the customer.  6rd clients get to use native v6 addresses with nice, sane global prefixes and routing, and except for packet-size issues get to ignore whatever 6rd or 6PE tunneling the ISP is indulging in the middle miles.

-- Jim Leinweber, WI State Lab of Hygiene

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
James Leinweber Fri, 03/14/2014 - 09:43
User Badges:
  • Silver, 250 points or more

6to4 tunnel address are comprised of:

   2002 IANA assigned prefix + 32 bits of public IPv4 address + 80 bits of site/host info

So, yes, you have to convert 68.86.75.12 into exactly :4456:4b0c:  You get to play with the bottom bits if you like; post-Vista windows will repeat the v4 address in the bottom 32 bits, for example.  The design was premised on the idea that most sites would eventually have native /48s routed their way, and you could use the same 16-bit subnet design and 64-bit hosts parts with your initial 6to4 addresses as with your eventual public addresses. 

If you had a native v6-only host talking to your own 6to4 border relay your relay could replicate your internal v6 subnet & host part across the tunnel to the destination in the bottom 80 bits.   If you have multiple hosts sharing a single uplink gateway, they do all have to use the same /48 prefix that lives on the outside v4-only interface of the gateway.  Getting individual packets back to the correct host would be an exciting exercise for your dual-stack inside gateway and v6 firewall. 

6to4 was really designed for individual dual stack hosts each with its own public v4 address that didn't have native IPv6 uplink.  In an era of IPv4 exhaustion, multiple hosts behind v4-NAT boxes, and increasingly availble native v6, 6to4 is an obsolete transition model.

The only v6-address a remote v6 server can be allowed to see is the special 6to4 address; if you have multiple inside hosts your gateway/firewall has to handle mapping the lower 80 bits of the 6to4 addresses with the common /48 prefix back to whatever your internal v6 addresses are.  If your v6 hosts are on fd00::/7 ULA site-scope v6 addresses this will be in addition to rather than instead of their 6to4 addresses with the shared /48 prefix, and unless they are unusually well behaved and using very recent software they may be spraying a mixture of v6 6to4 and ULA source addresses around more or less at random, with very bad connectivity results.

The fec0::/10 "site-local" addresses were officially deprecated in favor of fd00::/7 ULA in 2004 by RFC-3879, and conforming v6 routers will actually reject packets with those addresses rather than forwarding them.

What's going on is that the 3rd-party anycast dual-stack relays which you are hoping exist somewhere are advertising 192.88.99.0/24 routes on their v4 side and 2002::/16 routes on v6, and doing stateless conversion between 6to4 IPv6 addresses and native IPv4 addresses for any packets that happen to come their way.  In order for the protocol-41 wrapping to work there has to be a fixed mapping from  the embedded, special form v6 address back to your unique, public v4 address.  So you can't pick bits 17-48 of the address at random, or the far relay won't be able to return the v4-encapsulated v6 payload packets back to you.

All of the automatic tunneling mechanisms like Teredo, 6to4, and ISATAP are being deprecated for unreliable delivery, inadequate security, excess latency, and jitter reasons compared to native v6.  For problems with 6to4 specifically, see e.g.

   http://www.potaroo.net/ispcol/2010-12/6to4fail.html

The modern alternative to 6to4 is to have an ISP with native v6 at its border run 6rd between an in-ISP relay and upgraded CPE modems at the customers; French ISP "FREE" was among the first to do this.  It's a temporary expedient until the ISP finishes getting native v6 all the way to the customer.  6rd clients get to use native v6 addresses with nice, sane global prefixes and routing, and except for packet-size issues get to ignore whatever 6rd or 6PE tunneling the ISP is indulging in the middle miles.

-- Jim Leinweber, WI State Lab of Hygiene

Dean Romanelli Tue, 03/18/2014 - 07:57
User Badges:

Jelein,

Thank you very much for this very thorough answer.  I do have one follow up, however:

For the part where you confirm that the conversion from 68.86.75.12 to hex format of 4456:4b0c, this would give us a 6to4 prefix of 2002:4456:4b0c.  However, since we can play with the bottom bits as you also noted, there is one section in the 128 bit address I am uncertain of:

2002:4456:4b0c:????::/64 (EUI-64)

What should bits 49-64 be assigned? (The ones above with the ????)

James Leinweber Tue, 03/18/2014 - 14:21
User Badges:
  • Silver, 250 points or more

There isn't any particular standard as to what bits 49-64 should be that I'm aware of.  The most common choices would be either all zero, or replicating whatever subnet structure you were using or planning to use with a global (but not yet routed) 2000::/3 prefix and a presumed /48 delegation, or with site-specific ULA addresses.   All three of ULA, 6to4, and "normal" global delegations typically result in /48 prefixes upstream, 16 bits for your own subnetting, and 64 bits of host part.

In terms of the host part, only 62 bits are available to be chosen at random or by design; the individual/group bit (72) and the universal/local bit (71) from the modified EUI-64 mapping should both be 0 for administrator specified unicast addresses, e.g. when assigned staticly, or by DHCP, or based on a mapping from IPv4.

-- Jim Leinweber, WI State Lab of Hygiene

Actions

This Discussion