Re: Path MTU (was: RE:)
Mike Mestnik wrote:
>> mac address changes at every hop. The mac is *always* going to be your
> Assuming you could, do the imposible and, find out what the original mac
> was. (We seam to agree)You can't send a pkt to a mac address not on your
> local network.
I can only deal with the possible.
>> next-hop router's address. No use sending it back to it, it doesn't
> Not next-hop, where talking about source MAC, the last(previous)-hop.
OK. Talking again about a stub net. The last router to touch the packet
would be the router that all packets for your net come in on and go out
on. It's the same router. outgoing Next hop and incoming prev hop are
the same router. Semantics.
>> care.
>>
> What do you mean by care? If I take you literaly, that router cared enuff
> to send us the original pkt. The idea is the host(router) that gave us
> the pkt had a reverse route for the IP. This MUST be true
> since(other-wise) that router should/would have been the one to red flag
> the pkt.
>
What information are you going to send that router? Are you going to
tell it that it sent you a packet it shouldn't have? What type of
packet? Are you going to send an icmp dest unreachable? The router is
forwarding packets. It's not the originator of the packet and if you
send it a icmp dest unr. back to it, it's going to discard the packet.
It simply won't know what you are talking about and drop the packet.
> In cases where that router made a mistake it would/might send the reject
> pkt back to us. In these cases we can do one of two things, keep state
> and see that we can just drop this pkt or subtract one from the
> TTL(eventualy it will be out of time) and bounce it back.
OK, here's my last on this. Let's have a scenario that is pretty common.
udp packet with a spoofed source address. That's spoofed IP address. The
packet is sent from the originating host and travels along the net thru
routers that care about *1* thing - destination. They look at the
destination address and forward the packet out the right interface.
Period. It moves along the net and finally gets to your network and hits
your debian firewall, which is forwarding for an internal LAN. You are a
firewall and you look at the source address and note that it says it's
coming from your internal net, however it is coming in on the external
interface. Decision? Reject the packet? As I've said before, you don't
know where to send it. Your stack is going to create a packet with a
desstination address of a host on your *internal* net and then your
routing table is going to make the decision to route that packet out
your internal interface. It's that simple. There are no 'what if we
could find the original mac address' or 'maybe the prev-hop router will
do something if I send a packet'.
At this point, we've gone miles past a response to path mtu discovery,
and Steven's has a great book on TCP/IP.
Reply to: