Iljitsch van Beijnum wrote: > On 14 feb 2008, at 21:21, Dan Wing wrote: > >> What seems useful is a mechanism where the UDP encapsulation can be >> attempted and the native (non-UDP encapsulted) protocol can be >> attempted. > > I was thinking along similar lines. Notwithstanding what I said > earlier, sometimes encapsulating something in UDP to make it pass > through whathever needs passing through can be useful. For instance, > there have been one or two occasions where I could have used IPv6 in > UDP encapsulation but without all the baggage that comes with Teredo. > > But it seems to me that a much better approach to this is first of all > to make it optional, like you suggest, and secondly, make it a generic > mechanism that can be used for ALL protocols rather that define it > separately for one protocol at a time. Protocol options are bad. Especially ones like this which are quite hard to negotiate. What the draft is saying, is just design the darn thing to work only over UDP, rather than natively over IP. It'll work on the v4 Internet and in the v6 Internet too. Odds are good your protocol needed ports and a checksum anyway. So what exactly is this 'baggage'? > > In essence, something like this would increase the address lenght by > 16 bits. Well, as I am sure you know, the reason NAT is so successful is that it basically does extend the IP address space by 16 bits, but in a backwards compatible way, making it incrementally deployable. Thus, you get high utility and ease of deployment, the double whammy that leads to success, as draft-iab-protocol-success discusses. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@xxxxxxxxx http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf