Hello,
Recent offline discussions have postulated a unified solution as a
"widely applicable" mechanism that may satisfy most of the deployment
scenarios envisioned by the design teams. (6to4, teredo, isatap, 6over4
and SIIT have all been mentioned as candidates for unification.) Since
most of the unification would need to take place within the intra-site
scope, I propose that the name '6over4' be (re)adopted for that portion
of the unified scheme so that we would once again have:
6to4 + 6over4
as the unified solution (where "6over4" in this new sense combines the
necessary aspects of rfc 2529, teredo, isatap, etc.) A comment was made
during these discussions that, before any work on unification begins,
scenarios must be identified in which a unified solution would be more
useful than several seperate solutions.
I am convinced that technical obstacles to realize such a unification are
minimal and could be specified in a (bis) on RFC 2529. But the comment on
identifying scenarios carries obvious operational implications - hence the
decision to bring this topic to v6ops. I have listed below two possible
scenarios in which a unified solution might be more useful than seperate
solutions, but I leave it to the community to debate the merits of these
scenarios and/or postulate others. As such, please direct all follow-up
discussion to the v6ops list.
Sincerely,
Fred Templin
ftemplin@iprg.nokia.com
1) Dual-stack router with native IPv6 connectivity
**************************************************
The teredo specification ('shipworm-08.txt') deals with the "server" and "relay"
functions as seperable entitites. When the functions are implemented in seperate
boxes, the server cannot know in advance which relay will be used so it MUST
assign clients the Global Teredo IPv6 service prefix (defined in 'shipworm-08.txt'
as an IANA-assigned prefix of the form XXXX:XXXX/32). But, when the teredo server
and relay occur in the same box the paradigm is identical to that of the isatap
router function specified in 'isatap-04.txt'.
The isatap router specification allows the advertisement of *any* globally routable
IPv6 prefix(es) to clients up to and including /64's; not just prefixes derived
from a specific IANA-assigned /32. By integrating the isatap router paradigm, the
unified solution would allow native IPv6 prefix advertisements when the server
and relay functions coincide, and whether isatap-style IPv6-in-IPv4 tunneling or
teredo-style IPv6-in-UDP/IPv4 tunneling are used. Also, isatap-04.txt specifies
a means for clients to discover and affiliate with multiple routers for the site.
This means could also be applied for teredo in a unified solution.
2) Teredo server requiring a mapped address
*******************************************
The 'shipworm-08.txt' specification assumes that the teredo server address
will never require "mapping", as is required for teredo clients and that the
32-bit server IPv4 address alone is needed. As such, the specification seeks
a /32 IANA assignment for the Global Teredo Service prefix. But, this decision
casts in stone the assumption of no mapping requirement for servers, since a /32
assignment does not allow enough available bits (e.g., for encoding a 16-bit
server port number) for future applications.
One possible reason for the /32 target procurement is the difficulty in obtaining
coarser-grained prefixes from IANA and unnecessary address space exhaustion. But,
the 6to4 example shows that /16 prefixes can be obtained if the need is justified.
In the case that a /16 simply cannot be procured, one alternative could be to claim
an unused /20 prefix for teredo that would allow enough bits for future expansion.
One such /20 exists that is currently unused (and unusable!) for other applications:
2002:f000::/20
This prefix is part of the 6to4 2002::/16, but is unused because it matches
the IPv4 "Class E" experimental address space. There are +'s and -'s assocaited
with claiming this /20 for teredo, however. On the '+' side, an otherwise-unusable
/20 would be put to good use and a unified address prefix for transition mechanisms
with room for expansion would be realized. On the '-' side, all 6to4 realys would
need to be modified to either also support the teredo relay function, or advertise
the subset of 2002::/16 to exclude 2002::f000/32.