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

["Tony Hain" <alh-ietf@tndh.net>]

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 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
> 
> "Fred L. Templin" wrote:
> > 
> > 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.
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> - - Brian E Carpenter 
> Distinguished Engineer, Internet Standards & Technology, IBM 
> On assignment at the IBM Zurich Laboratory, Switzerland
>