RE: IPv6 Type 0 Routing Header issues

"Tony Hain" <alh-ietf@tndh.net> Fri, 27 April 2007 19:24 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 1HhW3a-0007W7-Ld; Fri, 27 Apr 2007 15:24:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhW3Z-0007W2-FW for ipv6@ietf.org; Fri, 27 Apr 2007 15:24:37 -0400
Received: from static-66-15-163-216.bdsl.verizon.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhW3Y-0005oV-0x for ipv6@ietf.org; Fri, 27 Apr 2007 15:24:37 -0400
Received: from eagle (127.0.0.1:1815) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id <S2F2925> for <ipv6@ietf.org> from <alh-ietf@tndh.net>; Fri, 27 Apr 2007 12:24:32 -0700
From: Tony Hain <alh-ietf@tndh.net>
To: "'Manfredi, Albert E'" <albert.e.manfredi@boeing.com>
References: <CA7D9B4A761066448304A6AFC09ABDA9015AD161@XCH-NE-1V2.ne.nos.boeing.com> <017501c78855$84a6f380$8df4da80$@net> <CA7D9B4A761066448304A6AFC09ABDA9015AD169@XCH-NE-1V2.ne.nos.boeing.com>
In-Reply-To: <CA7D9B4A761066448304A6AFC09ABDA9015AD169@XCH-NE-1V2.ne.nos.boeing.com>
Date: Fri, 27 Apr 2007 12:24:20 -0700
Message-ID: <02e801c78901$a7dd2890$f79779b0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AceIAa6HuP4+0Lm9RSu2Fd9lb2FPKgAEcskgABBiriAAKYdiIAABFofA
Content-Language: en-us
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
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
Reply-To: alh-ietf@tndh.net
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

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
--------------------------------------------------------------------