Subject: RE: Permanent infrastructure was(RE: POLL: Consensus for moving forward with Teredo?)

From: "Bound, Jim" <[email-masked]>
Date: Mon, 3 May 2004 12:57:55 -0400

very well articulated.  this is useful mail to me for technology
clarity.
thanks
/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tony Hain
> Sent: Monday, May 03, 2004 12:05 PM
> To: Bound, Jim; 'Liu Min'; 'Pekka Savola'; [email-masked]
> 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: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Bound, Jim
> > Sent: Saturday, May 01, 2004 6:14 AM
> > To: Liu Min; Pekka Savola; [email-masked]
> > 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: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Liu Min
> > > Sent: Saturday, May 01, 2004 1:19 AM
> > > To: 'Pekka Savola'; [email-masked]
> > > 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: [email-masked]
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] 
> [mailto:[email-masked]] 
> > > > On
> > > Behalf
> > > > Of Pekka Savola
> > > > Sent: Saturday, May 01, 2004 1:32 AM
> > > > To: [email-masked]
> > > > 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)
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> 
> 
> 
>