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

["Bound, Jim" <Jim.Bound@hp.com>]

Hi Fred,

I agree with Brian' comment it should be new.

Can you articulate for us exactly what the outcome of this is and its objective?

Once I hear that it could be we are missing some pieces for this unification or maybe not but it is vague to me now?

thanks
/jim

> -----Original Message-----
> From: Fred L. Templin [mailto:ftemplin@IPRG.nokia.com]
> Sent: Tuesday, October 01, 2002 4: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.
> 
> 
>