source route reversal

Scott Bradner <sob@newdev.harvard.edu> Sat, 28 January 1995 02:24 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16015; 27 Jan 95 21:24 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16010; 27 Jan 95 21:24 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa21325; 27 Jan 95 21:24 EST
Received: from newdev.harvard.edu by venera.isi.edu (5.65c/5.61+local-20) id <AA01136>; Fri, 27 Jan 1995 18:00:52 -0800
Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id UAA21529 for rreq@isi.edu; Fri, 27 Jan 1995 20:31:04 -0500 (EST)
Date: Fri, 27 Jan 1995 20:31:04 -0500 (EST)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199501280131.UAA21529@newdev.harvard.edu>
To: rreq@isi.edu
Subject: source route reversal

A question on the current rr draft  (I don't know the answer)

A number of places the current draft says that if there is a source 
route in the packet and any response (ICMP etc) has to be generated, 
the source route MUST be reversed and used to direct the return packet.  
The issue of doing this sort of thing came up in the IPv6 source route 
discussions and some people like Tony Li had strong thoughts that this type of
behavior should not be required.  

Is this something that should be brought up for specific discussion?

Scott