Cette page appartient aux archives web de l'EPFL et n'est plus tenue à jour.
This page belongs to EPFL's web archive and is no longer updated.

appli.ppt / ipagain.ppt

Hi, I, again, have some questions:

appli.ppt
p.9
If I'm not mistaken, a TCP server port is a port on which a machine listen for incoming connections. So, In passive-mode, why is port 1515 on S not listed as such ? And, always in passive-mode, the OK arrow of the second connection is reversed, I think.

p.13, 3.
It is said that a root name server knows the IP addresses of all level-2 domains. But there's a lot of level-2 domains ! So is it not all top-level domains ? And then, another name server which knows all level-2 domains related to this top-level domain gives the final answer ?
And how is the database of these top-level (level-2) domains maintained up-to-date at a root server ?


ipagain.ppt
p.4
R1 sends an ICMP redirect to inform A that a shorter route exists through R2. Ok, but how does R1 knows about the connection A-R2 ? R1 being on link with A and R2 doesn't automatically imply that A and R2 are also on link. So, does the ICMP redirect function only with certain network topologies ?

p.14/43
When PMTU is enabled, isn't the "don't fragment" flag set ? Is this case, a router cannot fragment a TCP packet even if the PMTU estimation failed, all it can do is send an ICMP message to inform that the packet is too big.

p.22/44
In this slide, the physical address seems to be deducted from the IP address, but where does this 33:33 comes form ? Is it just a default value set when some part of the physical address can't be deducted.
The solicited-node address ff02::1:80b2:9c26/128 corresponds to a machine which has a physical address ending by 80.b2.9c.26. This doesn't correspond to lrcsun13' physical address but it does correspond to the translated IP address of lrcsun13. So, will lrcsun13 reply to ff02::1:80b2:9c26/128 ?

Ok, it's all for tonight.
Posted by René Giller on Monday 5 February 2007 at 15:50
Comments
appli.ppt
p.9
If I'm not mistaken, a TCP server port is a port on which a machine listen for incoming connections. So, In passive-mode, why is port 1515 on S not listed as such ?

A: you are right, 1515 should be listed too.

And, always in passive-mode, the OK arrow of the second connection is reversed, I think.

A: this OK is not very important for what is being explained here, but still here is an explanation why it makes sense to have the arrow as it is: in active mode ok=synack (second step in opening tcp connection), then server can start to send data, in passive mode ok=ack (third step in opening tcp connection), then server can start to send data.

p.13, 3.

A: warning: these p.13 answers are not yet discussed with Professor Le Boudec, so not yet double checked!

It is said that a root name server knows the IP addresses of all level-2 domains. But there's a lot of level-2 domains ! So is it not all top-level domains ?

A: it seems that this is a typo, so it should be written that root servers know ip addresses of all top level domain servers (for redudancy, there are actually many root servers and also more than one dns servers for each top level domain).

And then, another name server which knows all level-2 domains related to this top-level domain gives the final answer ?

A: a top level domain (.com for example) dns servers (there are more then one of these for .com because of redundancy) must know all dns servers (have list of their IP addresses) for all level-2 domain names within its domain (.com dns servers must know dns servers of microsoft.com, abc.com etc. ; as these are registered, the information is available).

...A: Level-n (n=1(top), 2, 3, etc) dns server is either authoritative server for queried name, or it knows dns servers for corresponding "one dot longer" () subdomain part of the queried name (abc.com is one dot longer than com, for queried name shop.abc.com; subdomains' dns servers information is available from registration) and replies with ip(s) of this(these) subdomain dns servers and the process goes on until an authoritative dns server is found that kowns ip address for queried name.


And how is the database of these top-level (level-2) domains maintained up-to-date at a root server ?

A: Root servers are the only DNS servers that have to be found without any other information being cached. (To solve this bootstrapping problem all caching dns servers have a pre-configured list of numeric addresses for all root servers.). IP addresses of the DNS servers for all top-level domains (TLDs) such as ORG, COM, NL and AU are contained in a "manually made" file called "root zone file" that changese rare (usually less than 100 times per year) and is known by all root servers.
Posted by Slavisa Sarafijanovic on Tuesday 6 February 2007 at 16:59
ipagain.ppt
p.4
R1 sends an ICMP redirect to inform A that a shorter route exists through R2. Ok, but how does R1 knows about the connection A-R2 ? R1 being on link with A and R2 doesn't automatically imply that A and R2 are also on link. So, does the ICMP redirect function only with certain network topologies ?

A: you are right, it functions only if R1 R2 and A are all on the same LAN (that is how R1 knows about the connection A-R2).

p.14/43
When PMTU is enabled, isn't the "don't fragment" flag set ? Is this case, a router cannot fragment a TCP packet even if the PMTU estimation failed, all it can do is send an ICMP message to inform that the packet is too big.

A: "don't fragment" flag needs to be set during proces of PMTU discovery, and do not have necessarly to be set later, so the listed fragmentation cases are possible.
Posted by Slavisa Sarafijanovic on Wednesday 7 February 2007 at 15:41
p22/44: for the 33:33 see here http://en.wikipedia.org/wiki/IP_Multicast or here http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a0080203e90.shtml

for the second question: the host has an ipv4 unicast address assigned, so i guess the address in question is in line with slide 19 (solicited multicast -> XXXX:XXXX lowest 32 bits of unicast address)
Posted by Manuel Flury on Friday 16 February 2007 at 10:02