From: markp on 1 Apr 2010 11:49 "Cesar Rabak" <csrabak(a)bol.com.br> wrote in message news:hp2enu$7tr$1(a)news.eternal-september.org... > Em 1/4/2010 02:09, JosephKK escreveu: >> On Wed, 31 Mar 2010 00:31:23 +0200, Hans-Bernhard >> Br�ker<HBBroeker(a)t-online.de> wrote: >> >>> Didi wrote: >>>> On Mar 30, 1:44 am, Hans-Bernhard Br�ker<HBBroe...(a)t-online.de> >>>> wrote: >>>>> Didi wrote: >>> >>>>>> I tried today to figure out a simple way to give users of our >>>>>> new netmca (http://tgi-sci.com/tgi/nmcatb.htm) to locate its >>>>>> IP address once it gets one via dhcp when there is no internet >>>>>> at the moment >>> >>>>> I believe that, strictly speaking, that can't happen. If you have no >>>>> internet at the moment, you don't have DHCP either. Remember that >>>>> DHCP >>>>> itself is a UDP service. >> >>>>> UDP in turn works on top of IP, and that, for >>>>> better or for worse, is "internet". >> >> This erroneous statement alone shows that you are ill prepared to >> participate >> in this discussion. If you think UDP "sits" on top of IP you are very >> mistaken. >> It is a parallel (at the same level) link/transport protocol. > > If you think you have a lesson to teach please: > > Can you show the erroneous part of the statement explaining us how an UDP > datagram could be *sent* to a network without the IP layer? > > Remember *you* wrote they're 'parallel' so they can be used in exchange of > each other, right? > >> >> Moreover, you desired email reply shows arrogant disregard for USENET >> norms. > > Your not very informed reply shows an arrogrant ignorance for the Internet > RFC or equivalent ISO models. > > -- > Cesar Rabak > GNU/Linux User 52247. > Get counted: http://counter.li.org/ Add to that the datagram part can have a length of 64Kbytes, to send that over the internet will require splitting into max MTU packet sizes and then re-assembled. Of course UDP sits above IP!! Mark.
From: Albert Manfredi on 1 Apr 2010 15:57 On Mar 29, 5:19 am, Didi <d...(a)tgi-sci.com> wrote: > Uhm, not so sure. Same level as UDP in that they both have the > Ethernet > protocol type set to "internet", perhaps; but the data inside a UDP > packet > are encapsulated into that level, whereas the ARP data are purely > Ethernet > encapsulated. This should put it one level lower - at least > unofficially? I totally agree with you that ARP and UDP are in different protocol layers, but your response here is confusing. ARP uses a Type of 0x806, whereas IPv4 uses 0x0800. See: http://www.iana.org/assignments/ethernet-numbers So, ARP frames are only encapsulated by the Ethernet frame, nothing more. Whereas UDP datagrams are encapsulated inside an IP datagram, which in turn is inside the Ethernet frame. Bert
From: glen herrmannsfeldt on 1 Apr 2010 16:50 In comp.protocols.tcp-ip Albert Manfredi <bert22306(a)hotmail.com> wrote: (snip) > I totally agree with you that ARP and UDP are in different protocol > layers, but your response here is confusing. > ARP uses a Type of 0x806, whereas IPv4 uses 0x0800. See: > http://www.iana.org/assignments/ethernet-numbers > So, ARP frames are only encapsulated by the Ethernet frame, nothing > more. Whereas UDP datagrams are encapsulated inside an IP datagram, > which in turn is inside the Ethernet frame. Counting that way, why not any of the higher layers? Back to ICMP for a moment. As ICMP is also carried in an IP frame, it seems that it should be the same layer as TCP and UDP. In terms of ping, that makes sense. In terms of route redirect or source quench, it doesn't. In the latter case, the ICMP are to help the IP layer and not much about anything higher. ARP is there to help IP send frames on networks where layer 2 needs such help. -- glen
From: Albert Manfredi on 1 Apr 2010 18:56 On Apr 1, 4:50 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > > I totally agree with you that ARP and UDP are in different protocol > > layers, but your response here is confusing. > > ARP uses a Type of 0x806, whereas IPv4 uses 0x0800. See: > >http://www.iana.org/assignments/ethernet-numbers > > So, ARP frames are only encapsulated by the Ethernet frame, nothing > > more. Whereas UDP datagrams are encapsulated inside an IP datagram, > > which in turn is inside the Ethernet frame. > > Counting that way, why not any of the higher layers? > > Back to ICMP for a moment. As ICMP is also carried in > an IP frame, it seems that it should be the same layer as TCP > and UDP. In terms of ping, that makes sense. In terms of > route redirect or source quench, it doesn't. In the latter > case, the ICMP are to help the IP layer and not much about > anything higher. ICMP is at the same layer as UDP, TCP, or IGMP, for that matter. But neither ICMP nor IGMP are meant to provide the general purpose "transport layer" services that TCP and UDP provide. I'd classify ICMP and IGMP as special purpose protocols to control or monitor layer 3 devices. > ARP is there to help IP send frames on networks where > layer 2 needs such help. True. ARP is network-agnostic. It happens to have been used in IP nets most often, but that does not mean that it can ONLY be used to resolve IP addresses to physical addresses. It could in principle have been used for DECnet or any of those other forgotten protocols. Bert
From: glen herrmannsfeldt on 1 Apr 2010 19:04
In comp.protocols.tcp-ip Albert Manfredi <bert22306(a)hotmail.com> wrote: (snip) > True. ARP is network-agnostic. It happens to have been used in IP nets > most often, but that does not mean that it can ONLY be used to resolve > IP addresses to physical addresses. It could in principle have been > used for DECnet or any of those other forgotten protocols. Make that should have been used for DECnet. As I remember, DECnet changes the MAC address based on the DECnet address, such that no ARP is needed. You can only do that for one protocol per interface, though. There was not so long ago on another newsgroup someone who had a system that uses DHCP to assign the IP address, then brings up DECnet. Somehow the change of MAC address confused other parts of the system. Then Appletalk has AARP instead of using ARP. I don't know IPX very well, so I don't know what it does. -- glen |