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

[Brian E Carpenter <brian@hursley.ibm.com>]

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

"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