RE: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIIT solution

[Jung Cyndi-ACJ099 <ACJ099@motorola.com>]

I agree with Brian and Tony.  Besides, a grand unified tool is just going to
be one
more tool - I thought v6ops was going to start from scenarios in different
environments , examine the problems in each and show how the currentset
of tools apply or reveal where we need another tool, but only with great 
justification create any new transition tools.

On the other hand, if there is some additional benefit by making some of
these
tools work together, or if they can take advantage of the knowledge that
they are
co-located in the same system (say the 6to4 router at the ISP edge of an
isatap
or 6over4 domain), that might be worth identifying.  Similarly, if there are
some bad interactions between transition tools, those interactions need to
be
identified so people can avoid wasting time trying to make them work
together.

Cyndi

-----Original Message-----
From: Fred L. Templin [mailto:ftemplin@IPRG.nokia.com]
Sent: Tuesday, October 01, 2002 1:15 PM
To: v6ops@ops.ietf.org
Subject: Operational requirements for a unified
6to4/isatap/teredo/6over4/SIIT solution


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.