RE: An alternative to TCP (part 1)
Yes, however, I think we have three terms here: 1. end-to-end: path from host to host 2. Network edge: Internet access edge 3. Network edge: LAN edge Maybe, start using local edge to indicate the LAN edge Tina Iliff -Original Message- From: John Stracke [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 08, 2001 9:18 AM To: [EMAIL PROTECTED] Subject: Re: An alternative to TCP (part 1) Kevin Farley wrote: > So you think your PC is the edge of the Internet? Isn't that what the end-to-end principle means? -- /=\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist || |eCal Corp. |World domination should never be left to chance.| |[EMAIL PROTECTED]|| \=/
RE: An alternative to TCP (part 2)
I do agree with your point regarding the possibility of differentiated services QoS degrading router performance. In my opinion it may add slight delays in transport. However, I do see a benefit in offering more than two service levels. I guess that you can say that assured forwarding and expedited forwarding can be combined and implemented as the "real-time" service level. This is another topic of discussion though. Tina Iliff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 7:44 PM To: [EMAIL PROTECTED] Subject: RE: An alternative to TCP (part 2) > I have a question: > If the traffic class field in the IPv6 header was changed, as suggested, to > a set of flags, then how would a full gammit of differentiated services be > indicated? In other words, if there is only one flag indicating type of > service, then different levels of, for example, assured forwarding or > expedited forwarding cannot be supported or implemented. I think for the sake of routing system performance it's better to provide only two classes of services: real-time (expediated forwarding) and best-effort (classical IP service level). I think it's better not to implement assured forwarding in routing system, or the network layer but instead in the end-node system, or the transport protocol layer. Other quality of service parameter such as peak bit rate, sustained bit rate, guarranteed frame rate may be associated with the IPv6 flow label.
RE: An alternative to TCP (part 2)
I have a question:
If the traffic class field in the IPv6 header was changed, as suggested, to
a set of flags, then how would a full gammit of differentiated services be
indicated? In other words, if there is only one flag indicating type of
service, then different levels of, for example, assured forwarding or
expedited forwarding cannot be supported or implemented.
Tina Iliff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 8:28 AM
To: [EMAIL PROTECTED]
Subject: Re: An alternative to TCP (part 2)
ATP Header Format
The IPv6 packet whose payload contains an ATP packet must conform to latest
IPv6 specification, currently RFC 2460. ATP suggest that the traffic class
field should renamed to 'flags'. The leftmost bit could be RTP(real time
payload), the rightmost be ECN(Explicit Congestion notification), the others
are reserved. When RTP = 0, the packet falls in best-effort class of
service. When RTP = 1, the packet should be transmitted with as minimum
delay as possible.
Here is the pseudo-C data structure of an ATP header:
struct ATP-Packet
{
struct IPv6-Fixed-Header /* IPv6 fixed header */
{
version: 4;
flag-RTP: 1;
flags-reserved: 6;
flag-ECN: 1;
flow-label: 24
payload-length: 16;
next-header: 8;
hop-limit: 8;
source-addr: 128;
destination-addr: 128;
};
OPTIONAL IP-EXTENSION-HEADERS1; /* chain of the IPv6 extension headers
that must appear before the authentication header. */
OPTIONAL struct AuthenticationHeader /* IPSec AH */
{
AHnextHeader: 8;
AHpayloadLength: 8;
reserved: 16;
SPI: 32;
AHsequenceNumber: 32;
AuthData: VARIABLE (4..1020 bytes) /* must be 32-bit aligned.*/
Padding: VARIABLE(0..4 bytes) /* make the header to 64-bit aligned */
};
OPTIONAL IP-EXTENSION-HEADERS2; /* chain of the IPv6 extension headers
that may appear after the authentication header. */
ATP-flags-reserved: 5;
flag-RST: 1;
flag-SYN: 1; /* maybe it should be in the IPv6 fixed header? */
flag-FIN: 1;
Reserved: 4;
WindowSize: 20;
union {
Checksum: 32;
AckBitmap: 32;
};
SequenceNumber: 32;
HeaderStackPointer: 8;
DataSegmentLength: 24;
OPTIONAL ATP-extension-headers;
Payload: VARIABLE(0..224-1 bytes);
Padding: VARIABLE(0..7 bytes);
OPTIONAL UrgentData;
};
ATP-flags-reserved: reserved flags.
flagRST: a control flag meaning ¡®reset¡¯.
flagSYN: a control flag meaning ¡®synchronize¡¯
flagFIN: a control flag meaning ¡®finish¡¯.
The meanings of the three flags are borrowed from TCP.
Reserved: 4 bits. They may be used to extent window size in the future.
Window-size: Size of the sending window. The size refers to packet instead
of byte.
Checksum: When ATP operates in non-security-extent mode the field is valid.
Method to compute the checksum of an ATP packet is the same as TCP, only
that the word length is now 32 bits. The fields which affect the checksum
include the source and destination address in the IP fixed header, the whole
ATP fixed header, all of the ATP optional headers, and the ATP payload. The
checksum field in the ATP header is cleared to zero before checksum is
computed. The payload is padding with zero to 64-bit alignment.
AckBitmap: When ATP operates in security-extent mode the field is valid. It
is a 32-bit map of selective acknowledgement. See 'Selective Acknowledgement
Header¡¯below.
SequenceNumber: When ATP operates in non-security-extent mode it means the
sequence number of current packet. When ATP operates in security-extent
mode, it means the sequence number of an accumulatively acknowledged
accepted packet.
HeaderStackPointer: indicates the offset of the 64-bit word following the
last ATP extension header. The offset is relative to the start position of
the ATP fixed header. The unit of the pointer is 64-bit word. It is abnormal
if the value of the field is 0 or 1. No extension header exists if the value
is 2. Format of the ATP extension headers are described in following
paragraphs.
DataSegmentLength: the length in bytes of the ATP payload. Unlike the IPv6
payload length which counts IPv6 extension headers, data segment length of
an ATP packet does not count the fixed header or extension headers.
Payload is of variable length, from 0 to 2**24-1 bytes.
Padding makes the payload 64-bit aligned.
UrgentData is a special ATP extension header. See following paragraphs.
ATP Extension Headers
General Format:
struct general_ATP_extension_header
{
Bit-Field2: VARIABLE(0..512 bytes);
HeaderPointer: 8;
OptionCode: 8;
Bit-Field1: 16;
};
HeaderPointer has similar meaning as HeaderStackerPointer. It point to the
first 64-bit word of the current extension header. The pointer refers to
64-bit word. It is the offset relative to the start position of the ATP
fixed header. The pointer points to the fixed header if the value is 2,
which means reaching bottom of the header stack. Pointer value 0 and 1 are
reserved. One may get the byte addres
RE: NATs *ARE* evil!
Well, let me correct myself. It is more along the lines of firewall security being broken in the sense of all firewalls would have to be open to entire networks instead of limiting individual hosts. IP would be broken in the sense of routers not being able to distinguish which route to choose in the case of multiple hosts having the same IP address but they are located behind different firewalls, routers, etc in different enterprises. Tina Iliff -Original Message- From: Iliff, Tina Sent: Friday, December 15, 2000 11:48 AM To: 'Dave Robinson'; Keith Moore Cc: M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: NATs *ARE* evil! Yes! TCP breaks due to the fact that "true" source/destination sockets cannot be defined. The destination would not know where to send a response except in the case where DNS is used...unless I need to do more reading Tina Iliff -Original Message- From: Dave Robinson [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 11:11 AM To: Keith Moore Cc: M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: NATs *ARE* evil! What's the problem with locally significant addresses? Having thousands of 10 networks will never present a problem unless those networks at some point would like to talk to each other. Is that where this whole discussion is going (or coming from) - that ultimately the more NAT'ing we do, the more headaches we're creating for ourselves en route to true global connectivity? Dave -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 10:56 AM To: Dave Robinson Cc: Keith Moore; M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: NATs *ARE* evil! because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless.
RE: NATs *ARE* evil!
Yes! TCP breaks due to the fact that "true" source/destination sockets cannot be defined. The destination would not know where to send a response except in the case where DNS is used...unless I need to do more reading Tina Iliff -Original Message- From: Dave Robinson [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 11:11 AM To: Keith Moore Cc: M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: NATs *ARE* evil! What's the problem with locally significant addresses? Having thousands of 10 networks will never present a problem unless those networks at some point would like to talk to each other. Is that where this whole discussion is going (or coming from) - that ultimately the more NAT'ing we do, the more headaches we're creating for ourselves en route to true global connectivity? Dave -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 10:56 AM To: Dave Robinson Cc: Keith Moore; M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: NATs *ARE* evil! because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless.
RE: NATs *ARE* evil!
I could see valid cases for both reasons suggested below. Another reason from the customer point of view may be to lower costs. Tina Iliff -Original Message- From: Tony Dal Santo [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 14, 2000 1:54 PM To: Dennis Glatting Cc: Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: NATs *ARE* evil! Dennis Glatting wrote: > On Thu, 14 Dec 2000, Sean Doran wrote: > > > So, why are people deploying them? > > Just to name two... > > 1) With NAT I ask for much smaller address spaces. Consequently, I don't > have to disclose my network details, deployment is less likely to be > delayed, and both my non-recurring and recurring cost is lower. > > 2) I don't have to renumber my entire enterprise should I change service > providers, rather only the Internet interface devices. What exactly is the state of the IPv4 "address pool"? I realize there is a PERCEIVED shortage, and this is usually the main motivation for NAT. But is there a real shortage? Are "reasonable" requests for addresses being denied? As for the renumbering hassle, if you have a small installation, renumbering shouldn't be all that difficult (especially when using DHCP). For large installations, doesn't the organization own the address pool, and take it with them when they change ISPs? I know this used to be the case. If it isn't an address issue, is it a routing issue? Is it that the routing tables/protocols/hardware can't handle the large number of routes? Are ISPs refusing to carry reasonable routes? Seems to me if the entire address space was broken up into subnets of 4096, there would be about 1 million routes. What is the current size? I think I remember seeing numbers on the order of 50,000. If there is a real shortage or routing problem, I understand the motivation to use NAT. There really wouldn't be a reasonable alternative. But I have yet to hear anyone claim that a reasonable request has been denied. Based on that, I tend to think most NAT installations are motiviated by other (and in my opinion less valid) issues such as "security". Tony Dal Santo
