[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Permanent infrastructure was(RE: POLL: Consensus for moving forward with Teredo?)
very well articulated. this is useful mail to me for technology
clarity.
thanks
/jim
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tony Hain
> Sent: Monday, May 03, 2004 12:05 PM
> To: Bound, Jim; 'Liu Min'; 'Pekka Savola'; v6ops@ops.ietf.org
> Subject: Permanent infrastructure was(RE: POLL: Consensus for
> moving forward with Teredo?)
>
> Changing the subject to make counting the poll easier ...
>
> There is no permanent infrastructure component in either 6to4
> or teredo, and they are no less secure than any other
> approach. Every node is supposed to prefer a non-tunneled
> prefix over a tunneled one, so these mechanisms stop being
> used when there is a non-tunneled path to the other end.
> Also, they are not arbitrary prefixes, they are based on the
> 'controlled' IPv4 address.
> If organizations want more absolute control over their IPv6
> packet headers, they will need to deploy a dual-stack native
> path first. When they really want a single protocol routing
> infrastructure, DSTM makes sense. The only time ISATAP makes
> sense for people with these concerns is when they want
> 'controlled' prefixes (see note above about control of IPv4),
> but don't want to upgrade the routing infrastructure at the
> same time.
>
> Note: this is just another example where the complexity of
> various requirements is outside the scope of the IETF. All of
> these mechanisms have value to some environments, and will
> raise concerns in others. The IETF needs to point out where
> the design value is, and any significant issues when used
> outside the design point, and stop trying to make everyone
> deploy an identical network.
>
> Tony
>
>
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> > Behalf Of Bound, Jim
> > Sent: Saturday, May 01, 2004 6:14 AM
> > To: Liu Min; Pekka Savola; v6ops@ops.ietf.org
> > Subject: RE: POLL: Consensus for moving forward with Teredo?
> >
> > This made me think of something to relay to the WG (thanks Liu Min).
> >
> > I have heard from three different users in the ISR (Intelligence,
> > Surveillance, and Reconnaissance) deployment community, all
> different
> > entities, that any transition mechanisms, which use special IPv6
> > prefixes are a non-starter in certain cases. The two that are not
> > useful for that reason are 6to4 and Teredo. They present a
> potential
> > security hole because nodes can create them ad hoc theoretically and
> > IPv6 packets could be sent to them, and they are not within the
> > address space defined by these communities, and causes
> permanent infrastructure.
> > These nets use stateless and dominant IPv6 nets reducing IPv4
> > immedidately when possible, and using mechanisms to connect
> to legacy
> > IPv4. The two mechanisms that may work well at this time
> are DSTM and
> > ISATAP, and objective is to let ISATAP phase out automatically with
> > deployment (large advantage of ISATAP to them). Rigorous security
> > holes for DSTM and ISATAP are being searched now. That is all I
> > really know at this point and it is new.
> >
> > /jim
> >
> > > -----Original Message-----
> > > From: owner-v6ops@ops.ietf.org
> > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Liu Min
> > > Sent: Saturday, May 01, 2004 1:19 AM
> > > To: 'Pekka Savola'; v6ops@ops.ietf.org
> > > Subject: RE: POLL: Consensus for moving forward with Teredo?
> > >
> > > I think NAT traversal in IPv6 transition is a very
> important issue
> > > and should be solved. Although Teredo needs special
> > > IPv6 address prefix and need Teredo relay in every IPv6
> network, it
> > > is reasonably secure and already out there. There are also other
> > > mechanisms for this issue and each of them has different
> properties
> > > and applying scenarios. We should go forward with these
> transition
> > > mechanisms and let the market to make the final decision.
> > >
> > >
> > >
> > >
> > > Best Wishes,
> > >
> > > Liu Min
> > > Institute of Computing Technology
> > > Chinese Academy of Sciences
> > > Tel: (86-10) 6256 5533-9240
> > > E-mail: liumin@ict.ac.cn
> > >
> > >
> > > > -----Original Message-----
> > > > From: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org]
> > > > On
> > > Behalf
> > > > Of Pekka Savola
> > > > Sent: Saturday, May 01, 2004 1:32 AM
> > > > To: v6ops@ops.ietf.org
> > > > Subject: POLL: Consensus for moving forward with Teredo?
> > > >
> > > > Hi,
> > > >
> > > > (co-chair hat on)
> > > >
> > > > As identified in the scenarios analysis at IETF59 and in
> > > > draft-savola-v6ops-tunneling-01.txt, there appears to a
> need which
> > > > cannot be filled by another mechanism for Teredo at least
> > > in one major
> > > > Unmanaged scenario.
> > > >
> > > > Is there rough consensus to move forward with Teredo?
> > > (i.e., to adopt
> > > > it as WG document in this WG or elsewhere, for Proposed
> Standard.)
> > > >
> > > > The main issue raised has been to call for a more extensive
> > > > analysis for the deployment implications of native, 6to4, and
> > > Teredo. There is
> > > > already discussion of this in the Unmanaged Analysis
> > > document. There
> > > > seemed to be very little energy or interest in the WG to drive
> > > > this much further.
> > > >
> > > > The options regarrding Teredo at this stage seem to be:
> > > >
> > > > a) Go forward with Teredo, hone the deployment
> implications in the
> > > > unmanaged analysis in parallel (if and as appropriate),
> > > >
> > > > b) Conclude that there is no sufficiently strong need for
> > > Teredo, and
> > > > not support its advancement (for PS) at this stage, or
> > > >
> > > > c) Decide that we need to analyze the scenarios or
> deployment more
> > > > before being able to make a decision.
> > > >
> > > > If so, please state where you believe more analysis
> is needed..
> > > > and volunteer if possible :)
> > > >
> > > > If you have an opinion, please state it within a week, i.e., by
> > > > next Friday, 7th May.
> > > >
> > > > Thanks!
> > > >
> > > > (co-chair hat off)
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
>
>
>
>