I don't think that counts as a we-chose-to-use-SCTP end user...
SIGTRAN infrastructure in the telephony providers doesn't go through NAT. ergo,
SCTP's most popular use doesn't need to go through NAT. And DCCP doesn't need
to go through NAT, because no-one uses DCCP... so there's no need to tunne
Hi,
please keep this discussion focused on which approach we should follow for
UDP-encapsulating DCCP and SCTP.
I'm happy Lloyd posted his views. I'm hoping other community members will speak
up as well. If I were asked to characterize current consensus, I'd probably say
"disinterest for eithe
Hi,
Okay, I herewith speak up: yes I want to see UDP encapsulation for
both these protocols
(but right now I'm not sure which one).
Both SCTP and DCCP are useful - if there was no consensus on that,
ever, these
groups would never have been formed, and the protocols would never have
been de
"A bit stupid"?
UDP encapsulation of these protocols can already be done. Tunnelling is not
new. IP packet, UDP header, IP outer header, you're done.
What is not needed or justified is a 'special' encap which requires
documentation, implementation, and then deployment - because lack of deployme
Fred,
advocating removing the interior protocol checksum across header and payload
(and reconstituting/recomputing it afterwards) violates end-to-endidness and
weakens the reliability guarantee. Bad idea. From a checksum perspective, you'd
do better saying 'use UDP lite with a minimal check jus
Hi,
On Apr 27, 2010, at 12:06 PM,
wrote:
"A bit stupid"?
Sorry - I didn't mean to be personal, my point was that this
looks like a self-contradicting (somehow circular) argument.
UDP encapsulation of these protocols can already be done. Tunnelling
is not new. IP packet, UDP header,
They're already deployment failures.
Straightforward UDP tunnelling (encapsulate IP packet in UDP payload, that's
all) is not happening for these protocols.
A custom encapsulation method tailored just to carrying these protocols (in
effect, a pointless addition to each protocol) is not justified
IMHO, what should drive the use or no use of UDP is "the need and use of
UDP functons", rather then "the need to make the SCTP and SCCP more
popular because of using a popular transport". Perhaps I am not reading
right the motivation, but I somehow get that frm the thread - sorry...
Which is to sa
(forwarding a mail from Fred Baker that didn't get through to the list)
Begin forwarded message:
From: Fred Baker
Date: April 27, 2010 10:55:10 AM GMT+01:00
To: Lars Eggert
Cc: bidul...@openss7.org, dccp@ietf.org, tsv-a...@ietf.org, tsvwg
list , Lloyd Wood , Michael
Welzl
Subject: Re: U
Hi All,
Well, quite a few issues have been brought up here. Here are my
thoughts on one of them.
Why not just tunnel it? "Just tunnel it" means IP header/UDP
header/inner IP header/"real" transport header. The problem here is in
the addresses in the inner IP header.
In most uses of IPv4 tunne
Hi Fred,
I can understand in general your point that things should not be done multiple
times.
So you argue not to have a UDP and SCTP/DCCP checksum and not to duplicate the
port
numbers. I would like to address these suggestions individually:
1. Checksum
SCTP uses a 32-bit CRC32c which is m
On Apr 26, 2010, at 9:07 PM, Jukka Manner wrote:
> Hi Lloyd,
>
> I have to object here. :)
>
> On 22.4.2010 13:50, l.w...@surrey.ac.uk wrote:
>
>> The GUT draft and recreating IP packets strikes me as problematic in
>> implementation, just as much as NATs. I'd rather have a simple
>> IP-in-IP
On Apr 26, 2010, at 10:34 PM, wrote:
>
> On 26 Apr 2010, at 20:07, Jukka Manner wrote:
>
>> Hi Lloyd,
>>
>> I have to object here. :)
>>
>> On 22.4.2010 13:50, l.w...@surrey.ac.uk wrote:
>>
>>> The GUT draft and recreating IP packets strikes me as problematic in
>>> implementation, just as
But encapsulation methods intended for endhosts wind up in middleboxes.
Look at Cisco's RBSCP and WAAS (and the recently discontinued NCE), which
already rewrite between SCTP and TCP checksums.
Any new encap method blessed by the IETF must be considered for worst-case
middlebox use - where rewr
That's hardly integrated into a shipping IP stack.
FreeBSD may be an SCTP reference implementation, but that's not significant
deployment.
-Original Message-
From: Michael Tüxen [mailto:michael.tue...@lurchi.franken.de]
Sent: 27 April 2010 19:16
To: Wood L Dr (Electronic Eng)
Cc: jukka.
Why not craft the inner packet with inner src and destination to a local
loopback address (127.0.0.1) before sticking it in the UDP header?
Preserves layering, preserves multihoming, avoids public/private address space
concerns, prevents similar tunnelling by middleboxes.
Of course, there's tra
Tom P.
>From a quick glance to your message, it is not clear why one would need
or want
IP tunneling from end-node to end-node in this case - sorry if I missed
the explanation.
Both Inner and Outer IP headers seem to have the same IP addresses, if I
get it right.
Is perhaps the role given to IP
17 matches
Mail list logo
