[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Re: TRRP-Via - option header vs. encapsulation
- To: "Robin Whittle" <rw@firstpr.com.au>
- Subject: [RRG] Re: TRRP-Via - option header vs. encapsulation
- From: "William Herrin" <bill@herrin.us>
- Date: Tue, 18 Sep 2007 09:52:52 -0400
- Cc: "Routing Research Group list" <rrg@psg.com>
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Lit+1DhDi43jN3PA3tVXx3DM93tXze+6AVMdgfT31DgDq5A/O/NP694N2MNe2PsAu+FDwQ8NO+7Z+fSxl6Qzta3SJsrq7KEVoXryDzDiRXq6N6cZrdvdesgczApcyQhcbV3nx5K229xdzx8ddNew+Ds9QxpZ6poDrObgYzDQUKg=
- In-reply-to: <46EE9325.90109@firstpr.com.au>
- References: <46EE9325.90109@firstpr.com.au>
On 9/17/07, Robin Whittle <rw@firstpr.com.au> wrote:
> Loose Source Routing Via IP option
>
> 1 Destination address Destination address
> is changed to be that remains that of the
> of the intermediate original packet - the
> router. destination host.
Robin,
Thanks for your comments. I had given up on the Via option in part
because of the need for all routers in the path to be upgraded to
support it but your observation about loose source routing resolves
that problem. I've revised the TRRP Via option as a result and posted
the new version here: http://bill.herrin.us/network/trrp-via02.html
> I don't know enough about ICMP messages to know whether the other
> desired benefit would really occur - enabling Path MTU Discovery
> between the ITR and ETR, with the sending host getting the messages
> and adjusting its packet lengths accordingly.
>
> Does the router generating the ICMP message back to the sending host
> include just the basic IPv4 header and "8 bytes following", or is it
> supposed to include the option parts of the header too? If the
> latter, the sending host will not recognise the option parts, since
> the ITR added them - which would break PMTUD.
My interpretation of the RFCs is that the router MUST return the
entire IP header including options, plus 8 bytes of payload. Those 8
bytes of payload will include the UDP or TCP port numbers if its a UDP
or TCP packet. The router MAY return additional payload up to what
will fit in a packet the size of IPv4's minimum MTU which is something
like 536 bytes.
Path MTU discovery is the other problem with the Via option. The host
can't be expected to understand the fragmentation needed message for
the altered packet and since the fragmentation needed message doesn't
return to the ITR, the ITR can't mediate. That's one reason I picked
GRE as the default encapsulation for TRRP instead of Via.
I tried to tackle PMTUD from a couple different directions in the
draft at http://bill.herrin.us/network/trrp-via02.html based in part
on Brian Carpenter's comments on how PMTUD works in IPv6. I'd be
interested in your comments; the approach may work for Ivip and LISP
as well.
And I now owe you a more careful read of Ivip. ;)
Regards,
Bill Herrin
--
William D. Herrin herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg