0

Question: Highlight the part of the algorithm detailed in RFC826 which makes Arp Poison Routing (APR) possible and briefly explain your reasoning.

I am not 100% sure on this question, what is it asking for? I have read the document RFC826 but still confused.

Does it mean this this algorithm?

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
?Do I speak the protocol in ar$pro?
Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
?Am I the target protocol address?
Yes:
If Merge_flag is false, add the triplet <protocol type,
sender protocol address, sender hardware address> to
the translation table.
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes:
Swap hardware and protocol fields, putting the local
hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on
the same hardware on which the request was received.

Source: http://www.faqs.org/rfcs/rfc826.html

Thanks

1
Contributor
1
Reply
2
Views
8 Years
Discussion Span
Last Post by scottyscotty19
0

Anybody have any ideas?

I have done all the other 19 questions, but I am still stuck on this one.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.