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

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 01 Oct 2002 13:15:06 -0700

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
[email-masked]

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Oct 2002 16:40:01 +0200

I haven't been in any off line discussions, but I am dead against
this. We should keep things simple and we should keep things
modular. 

I oppose any overloading of the 2002:: address space, because 
overloading is evil.

I oppose any attempt to reuse the name "6over4" beyond the clean,
simple usage defined in RFC 2529. If you want to do something
new, choose a new name, rather than overloading the old one.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 2 Oct 2002 10:56:00 -0700

Brian E Carpenter wrote:
> I haven't been in any off line discussions, but I am dead 
> against this. We should keep things simple and we should keep 
> things modular. 

I strongly agree. For one any attempt to unifiy 6over4 & isatap will
dilute their clear strengths. While each play in the space of the
intranet, the fundemental technology difference of ipv4-multicast
enabled vs. not provides each a clear deployment space. Any attempt to
combine them will create a mechansim that is both more complex than
6over4, and restricted to the same subset of intranet deployments.

Tony

> I oppose any attempt to reuse the name "6over4" beyond the 
> clean, simple usage defined in RFC 2529. If you want to do 
> something new, choose a new name, rather than overloading the old one.
> 
>    Brian
> 
> "Fred L. Templin" wrote:
> > 
> > Hello,
> > 
> > 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
> > 
> > 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
> > [email-masked]
> > 
> > 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.
> > 
> > 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.
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> - - Brian E Carpenter