|
|
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 tunneling just to have "some" header as
a separator between the UDP header and the SCTP header?
On using UDP just to encapsulate a transport packet, While thinking out
loudly, I will go back to the basics. UDP has three functions - (1)
identify the end points of
Communications - port numbers, (2) ensure end points and data integrity
- checksum, and (3) define/carry an atomic datagram - datagram length.
The duplication of functions with SCTP has been recognized already as a
fact.
UDP is being given the role, or function of bypassing NATs, who seem to
be agnostic of SCTP/DDCP - this has nothing to do with the basic
functions of UDP, but rather with the shortcomings of NATs....
I imagine the IPv6 guys would have something to say about this...
I wonder if any of the two drafts is going to be on the Standards track.
Regards,
Alex Conta
> -----Original Message-----
> From: Phelan, Tom [mailto:tphelan@xxxxxxxxxxxx]
> Sent: Tuesday, April 27, 2010 1:46 PM
> To: Alex Conta; L.Wood@xxxxxxxxxxxx; fred@xxxxxxxxx
> Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx
> Subject: RE: UDP encaps for SCTP and DCCP -- why not just tunnel it?
>
>
> 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 tunneling, the tunnel endpoints either
> both have public IP addresses or they both exist in the same
> private IP address space. This provides a coordination of
> the inner addresses such that they are meaningful to both the
> sender and receiver. In these conditions, DCCP can be
> tunneled just like everything else.
>
> However, there are many situations where these conditions
> don't apply. One very common situation where these conditions
> don't exist is when the client, managed by one organization,
> is in a private address space behind a NAT and the server,
> managed by another organization, is in the public address
> space. This situation, and the several variants that are
> possible, are more the target of the DCCP encap draft.
>
> In the private-client-nat-public-server configuration, the
> client will initially set the outer and inner source
> addresses to private addresses (possibly the same address for
> both, possibly different). The NAT will change the outer
> source address to a public address, but not the inner. When
> the inner packet is extracted at the server, the inner source
> address will be meaningless (and leaks information that is
> normally held private). On the return path, it'll be the
> destination address that's meaningless.
>
> You can imagine many ways that the client can set inner
> addresses to values that would mean something to the server,
> but it's difficult to see how the server could set the inner
> addresses meaningfully without having the client's private
> address leaked to it (define a "neutral" address space?).
>
> But if you do solve the inner address meaning problem, what
> have you gained? Nothing, I believe. The inner addresses
> are fundamentally useless. So why carry useless fields?
> Make it IP header/UDP header/transport header. This is the
> approach all three current drafts take.
>
> Tom P.
>
>
> > -----Original Message-----
> > From: tsv-area-bounces@xxxxxxxx
> [mailto:tsv-area-bounces@xxxxxxxx] On
> > Behalf Of Alex Conta
> > Sent: Tuesday, April 27, 2010 9:54 AM
> > To: L.Wood@xxxxxxxxxxxx; fred@xxxxxxxxx
> > Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx
> > Subject: RE: UDP encaps for SCTP and SCCP
> >
> > 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 say that I agree with Fred's concern 100% about
> duplications
> > of functions.
> >
> > I would perhaps even go a little further, if the
> counter-argument is
> > that with "UDP lite", there is a minimization of
> duplication, and that
> > is:
> >
> > my concern would be that besides the dupplication, there is some
> > additional burden in processing a packet that has mutliple header
> > layers, when passing the packet from one layer to the
> other. It's not
> > much, but there is, and can add-up - there are the little
> things that,
> > when in larhe numbers, contribute to a considerable load.
> If that can
> > be eliminated, I see it as a plus...
> >
> > Alex Conta
> >
> > > -----Original Message-----
> > > From: tsv-area-bounces@xxxxxxxx
> [mailto:tsv-area-bounces@xxxxxxxx]
> > > On Behalf Of L.Wood@xxxxxxxxxxxx
> > > Sent: Tuesday, April 27, 2010 6:38 AM
> > > To: fred@xxxxxxxxx
> > > Cc: dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg@xxxxxxxx
> > > Subject: RE: UDP encaps for SCTP and SCCP
> > >
> > >
> > > 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 just across its own
> > > headers and pseudo-header' to decrease the computational
> overhead -
> > > that should be a fixed value.
> > >
> > > Using a UDP (or lite) port to indicate what is being done
> here with
> > > a particular weird encap, as well as the original ports on the
> > > interior packet, is something that this approach is stuck with, I
> > > think.
> > >
> > > Lloyd Wood
> > > http://sat-net.com/L.Wood ________________________________________
> > > From: Fred Baker [fred@xxxxxxxxx]
> > > Sent: 27 April 2010 10:55
> > > To: Lars Eggert
> > > Cc: bidulock@xxxxxxxxxxx; dccp@xxxxxxxx; tsv-area@xxxxxxxx; tsvwg
> > > list; Wood L Dr (Electronic Eng); Michael Welzl
> > > Subject: Re: UDP encaps for SCTP and SCCP
> > >
> > > From my perspective, I would prefer to run a native encapsulation
> > > rather than host it in UDP. If one wants a UDP
> encapsulation, I have
> > > no opinion on which of the choices to make, but I would suggest a
> > > characteristic you want to have. There is no point having
> UDP ports
> > > *and* SCTP/DCCP ports, and no point in having a UDP
> checksum *and*
> > > an SCTP checksum. I would recommend removing the duplicated
> > > functions from the interior protocol and relying on UDP's
> > > counterpart, even if it is inferior, as it will be more readily
> > > deployed.
> > >
> > > On Apr 27, 2010, at 10:42 AM, Michael Welzl wrote:
> > >
> > > > 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 developed.
> > > >
> > > > Now, they are not used much (on the Internet involving
> > > NATs); at least
> > > > DCCP isn't. That's a problem. UDP encapsulation is a
> way to try to
> > > > solve this problem - and saying that we shouldn't do this
> > > because the
> > > > protocols aren't used is a bit stupid, isn't it?
> > > >
> > > > To repeat this more clearly and bluntly:
> > > >
> > > > tool X isn't working well => noone uses it.
> > > > So let's not fix tool X because noone uses it anyway. Hmmm...
> > > >
> > > > Cheers,
> > > > Michael
> > > >
> > > >
> > > > On Apr 27, 2010, at 9:47 AM, Lars Eggert wrote:
> > > >
> > > >> 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 either
> > > approach." (Which
> > > >> would be fine, but doesn't quite match the earlier feeling
> > > I got from
> > > >> the community, i.e., that we do want UDP encaps for these
> > > protocols.)
> > > >>
> > > >> Lars
> > > >
> > >
> > http://www.ipinc.net/IPv4.GIF
> >
> >
>
>
|
|
