RE: IPv6 Type 0 Routing Header issues
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPv6 Type 0 Routing Header issues



	i don't understand, rthdr0 must be killed, grilled, diced into million
	pieces.  say farewell.  you did not do my exercise even:
	- how many hops you can make w/ a packet sized 1280?

itojun



> Manfredi, Albert E wrote:
> > > -----Original Message-----
> > > From: Tony Hain [mailto:alh-ietf at tndh.net]
> > > Sent: Thursday, April 26, 2007 6:52 PM
> > >
> > > As I recall the primary goal was to allow a system to state a specific
> > > transit path because it was the one that the subscriber had a
> > > contract with.
> > > Think dialing a local number to get a specific long-distance carrier's
> > > presence, rather than paying the extortion rate that the
> > > local provider
> > > charges for their random selection of long-distance.
> > 
> > That makes good sense for the sending host. But the receiving host would
> > have no reason to forward anything beyond the destination address of the
> > packet, no matter what the extension header says. Except for the case of
> > multiple IP addresses in that host, which I had not considered.
> 
> Well by definition a host does not forward, else it becomes a router.
> In any case, I don't recall discussion about using it for alternate path
> selection to the same destination, but assuming the source tried RH0 using
> the address set from dns, it would be a lot simpler than the shim6 sillyness
> with exactly the same security downsides. The thing that it doesn't do is
> take the alternate addressing out of the source host and put it under
> control of the network boundary policy. 
> 
> > 
> > If Steve Deering wanted all hosts, whether set to forward packets or
> > not, to process extension headers, my only conclusion is that he was
> > thinking of multiple IP addresses in that host.
> 
> Except for hop-by-hop, the extension headers are explicitly about taking the
> end-to-end options out of the base IPv6 header. Essentially every extension
> header is there for processing by the receiving host. The fact that there
> are artifacts of the routing extension that might be useful to the receiving
> host was not a design goal. 
> 
> > 
> > Just trying to figure out what the corner cases are.
> 
> What you are witnessing is the eternal struggle for -control- between the
> end system oriented implementers and the network operations oriented
> implementers. There are use cases on both sides that can & will be abused.
> People tend to disparage the use cases that don't fit their particular take
> on the 'who is in control' issue, and rather than defining best practice
> configurations they would rather take the easy out of abolishing things that
> give the other side some degree of control. 
> 
> Tony
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.