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(_at_)cisco(_dot_)com
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf