No subject


Sun Jul 8 18:14:56 CDT 2012


gre     47      GRE             # General Routing Encapsulation
(name in protocols list, name on rfc1701 is Generic Routing Encapsulation)

Most IP tunnels use some protocol other than TCP or UDP, simply to avoid the 
overheads of even UDP.  GRE is lighter weight than UDP.  In the case of PPTP,
though, Microsoft added a completely broken congestion control algorithm that
means it is no longer as lightweight as a pure GRE tunnel.  However the 
sequencing part of the congestion control is required to implement guaranteed
sequencing for the pppd (it's OK for ppp to lose packets, just like line noise
on a modem line, but ppp is not designed to handle out of order packets).

The "normal" use of GRE is between routers, tunnelling either 1476-byte MTU
packets (14 byte overhead, prevent fragmentation on most links) or 1500-byte
packets (which means you can't set the "do not fragment" flag on the actual
GRE packets, and you will suffer a fragmentation penalty, but you won't die
on broken TCP stacks).

I'm surprised that RTP (VoIP transport) was implemented over UDP rather than 
as a separate protocol, as this makes the performance of VoIP that bit lower.

If you want to know how much more light weight... a while 32-bit word more.
Doesn't seem much?  It's 15% of the headers on each packet, and then in the
case of RTP you add another 12 bytes minimum.

GRE: 12-bytes version, IHL, ToS, len, ID, flags, frag, TTL, prot, csum
     4-byte src IP
     4-byte dst IP
     5-bits indicating presence of options
     3-bits indicating tunnel depth permitted
     5-bits flags
     3-bits version (0)
     2-bytes protocol being carried
     ==============================
     24 bytes

UDP: 12-bytes version, IHL, ToS, len, ID, flags, frag, TTL, prot, csum
     4-byte src IP
     4-byte dst IP
     2-byte src port
     2-byte dst port
     2-byte length
     2-byte checksum
     ===============
     28 bytes (not including any options, which would add more)

RTP: An example of trying to build a light-weight protocol on top of UDP,
     this sits on top of UDP and adds minimum 12 bytes, sometimes more,
     on top of the UDP header... note that in RFC793 (TCP, 1981) RTP was listed
     as side-by-side with TCP as a voice transport, rather than on top of
     UDP (not mentioned in that document).  [a 1981 rfc mentioning VoIP...
     it's only taken almost 20 years to become viable...]

Of course if you want things to be slow, you can always tunnel PPP over SSH.

David.

> Marcus
> 
> Angus North schrieb:
> > 
> > Hi everyone
> > 
> > Just wondering - wasn't it a little silly to invent a new protocol for PPTP
> > (# 47)
> > given that it will be blocked by default by most firewall configurations?
> > Remote users and PPTP administrators will often have no control over these
> > firewalls
> > e.g if an employee of company A visits company B, and whilst there, would
> > like to
> > connect via PPTP to company A's LAN from company B's LAN. In most
> > cases,company B will not cater for PPTP, and the employee will have no
> > control over company B's firewall.
> > Since PPTP is all about making secure remote access easy, why not use
> > unreserved TCP ports, that
> > most firewalls let through?
> > 
> > Cheers
> > Angus

-- 
----------------------------------------------
David Luyer
Senior Network Engineer
Pacific Internet (Aust) Pty Ltd
Phone:  +61 3 9674 7525
Fax:    +61 3 9699 8693
Mobile: +61 4 1064 2258, +61 4 1114 2258
http://www.pacific.net.au        NASDAQ: PCNTF
<< fast 'n easy >>
----------------------------------------------





More information about the pptp-server mailing list