[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIIT solution
- To: "Fred L. Templin" <ftemplin@IPRG.nokia.com>, <v6ops@ops.ietf.org>
- Subject: RE: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIIT solution
- From: "Bound, Jim" <Jim.Bound@hp.com>
- Date: Wed, 2 Oct 2002 12:50:10 -0400
- Delivery-date: Wed, 02 Oct 2002 09:52:12 -0700
- Envelope-to: v6ops-data@psg.com
- Thread-index: AcJphfFiDhsfIVgIRC6l4lr67TGwbwArZxFw
- Thread-topic: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIIT solution
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.
>
>
>