[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Marc's objections to Teredo (was RE: POLL: Consensus for moving forward with Teredo?)



Not piling on marc and fully support the Tunnel Broker and believe it is
very important to IPv6 deployment.

But I do think Christian has responded well to the objections.  Esp. the
complexity issue.  We must let the market decide what is complex it is
not in our charter IMO and would take time away from the work we do
technically well here.

/jim

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Christian Huitema
> Sent: Friday, April 30, 2004 5:33 PM
> To: Marc Blanchet; Pekka Savola; v6ops@ops.ietf.org
> Subject: Marc's objections to Teredo (was RE: POLL: Consensus 
> for moving forward with Teredo?)
> 
> I obviously disagree with several of Marc's objections to Teredo:
> 
> > - there are other ways on the table to do nat-traversal.
> 
> Sure. If another solution has clear benefits, it should be 
> standardized as well. That is not a reason for not progressing Teredo.
> 
> > - teredo introduces many security issues, such as very open relays
> that
> > are subject to be used for large scale DDOS
> 
> Uh? Teredo does not actually introduce any "open relay". Each 
> session that goes through the relay has to perform an initial 
> 3-ways handshake, which makes it very hard to use in a large 
> scale DDOS.
> 
> > - teredo is complex to implement
> 
> Complex to implement is an emotional statement. The 
> assessment of complexity in the IETF is "running code", not 
> emotions. There already are two independent and interoperable 
> implementations. This meets the standard for going to DS.
> 
> > - teredo introduces states and buffering in relays when the first
> packets
> > are sent, which have important issues in implementing.
> 
> "Important issues"? There are exactly the same issues with 
> ARP, or IPv6 ND. 
> 
> > - teredo does not work for symmetric NATs and the "fallback" for a
> user in
> > this situation is "no service".
> 
> Uh, no. There are three fallbacks. One is to simply go buy another NAT
> -- most of the modern NAT do work with Teredo, as analyzed in 
> draft-jennings-midcom-stun-results-00.txt. The other is to go 
> program the Teredo port number in the NAT, using the 
> management interface -- which is probably OK for the 
> dedicated users. And the third is to obtain service by another way.
> 
> -- Christian Huitema
> 
> 
>