RE: IPv6 Type 0 Routing Header issues

itojun@itojun.org (Jun-ichiro itojun Hagino 2.0) Sat, 28 April 2007 02:31 UTC

Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhcie-0002B1-Ps; Fri, 27 Apr 2007 22:31:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhcid-00028U-H3 for ipv6@ietf.org; Fri, 27 Apr 2007 22:31:27 -0400
Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhcic-0004L8-Lu for ipv6@ietf.org; Fri, 27 Apr 2007 22:31:27 -0400
Received: by coconut.itojun.org (Postfix, from userid 501) id 706E41C064; Sat, 28 Apr 2007 11:31:25 +0900 (JST)
To: alh-ietf@tndh.net
In-Reply-To: Your message of "Fri, 27 Apr 2007 12:24:20 -0700" <02e801c78901$a7dd2890$f79779b0$@net>
References: <02e801c78901$a7dd2890$f79779b0$@net>
X-Mailer: Cue version 0.8 (070406-1309/itojun)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Message-Id: <20070428023125.706E41C064@coconut.itojun.org>
Date: Sat, 28 Apr 2007 11:31:25 +0900
From: itojun@itojun.org
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: ipv6@ietf.org
Subject: RE: IPv6 Type 0 Routing Header issues
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

	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@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@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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