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

["Fred L. Templin" <ftemplin@IPRG.nokia.com>]

On this subject, I think plenty of time has gone by and I have seen no
follow-up discussion. I recall Randy Bush saying something regarding
silence as a determining factor at the v6ops interim meeting, but I
believe he was only referring to official group concensus. In this
case, I need to interpret things for myself and the silence is
speaking volumes to me. I take this to mean one of the following:

 1) No one cares about the subject
 2) No one feels that the scenarios listed in my message
    carry operational concerns for v6ops

As I have said, I have gone to some trouble to bring this discussion
to the list, but the discussion has not been rejoined. With that in
mind, it is going to be very difficult for me to justify going to
even more trouble on the subject of a unified solution proposal.

Fred
ftemplin@iprg.nokia.com

Fred L. Templin wrote:
> The comments on naming and prefix allocation are noted and appreciated.
> But, the main purpose of my original message was to initiate discussion
> within the community on the operational aspects of anticipated scenarios
> (which is consistent with my understanding of the v6ops charter.) I have
> gone to some trouble to initiate this discussion, and have done so *only*
> as a perceived professional responsibility to the community. It will be
> difficult for me to justify going to even more trouble if the operational
> aspects of my original message below are not thoroughly discussed within
> this forum.
>
> Fred
> ftemplin@iprg.nokia.com
>
> 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.
>
>
>