Re: Source address selection insufficient?

[Brian E Carpenter <brc@zurich.ibm.com>]

Antonio Tapiador del Dujo wrote:
> 
> El jueves, 04 de marzo de 2004, a las 14:52:31, marcelo bagnulo escribió:
> >
> > The problem concerns what it is called in the draft "source address
> > discovery"
> > In this option, it is proposed that when a packet that does not comply with
> > ingress filtering arrives to the site exit router, the router informs the
> > host about the correct source address to use with a given destination.
> >
> > A big assumption made in this scenario is that the host *can* change the
> > source address.
> > This may be more or less simple when the host is initiating a communication,
> > since when the hosts received the icmp error informing about the proper
> > source address, the host may be able to retransmit the packet with a
> > different source address.
> >
> > However, when the host within the multihomed site is replying to a received
> > packet, the host cannot change the source address because the reply packet
> > would have a different address than the initial packet, so it wouldn't be
> > recognized as a reply of the initial packet by the initiator host.
> 
> What about marking packets that may be source-address-corrected,
> using an extension header, or maybe a single bit?
> 
> The multihomed host knows which packets can be corrected, and which
> ones must not.
> Legacy hosts would not be corrected, their traffic would be source
> address routed or managed by other site exit solution.

I definitely feel that marking packets would make this type of solution
more robust in some ways, but it has distinct problems - we don't
have a bit for this, and we really want to avoid extension headers
if we can (MTU size issues, etc.)
> 
> Upper layers solutions may use this mark for their own needs.

I suspect ULPs will want to avoid knowing anything about MH events,
unless you include the transport layer as a ULP.

   Brian