Options for draft-ietf-6man-uri-zoneid

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 29 April 2012 07:54 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DAD21F84F3 for <ipv6@ietfa.amsl.com>; Sun, 29 Apr 2012 00:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.522
X-Spam-Level:
X-Spam-Status: No, score=-101.522 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBn7WcV0HnaB for <ipv6@ietfa.amsl.com>; Sun, 29 Apr 2012 00:54:23 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A28DE21F84D3 for <ipv6@ietf.org>; Sun, 29 Apr 2012 00:54:22 -0700 (PDT)
Received: by werb10 with SMTP id b10so1540219wer.31 for <ipv6@ietf.org>; Sun, 29 Apr 2012 00:54:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=yj2EpPY3ZsBN1oU6lR5qy579vU3cqgcxCiBG+qEOiN4=; b=Z6/pGo+ZrUeJM6VUvFiy0C8cJ2B+leLPLwd5wlD0aDpOIweCf1jFqFlrfnnmbiiHKP NCHDQaGXf7jeSCe/WqIBB8nkTPi/C0IyY0Orek2ir8u/28eFp4o5e6IUN8MDQtP+8KZR iHnsuqOaYuWxPzm7rC4v9k3oeC1xnfuWcR+r8WfGHHoXaRlsfCRJdp/FOKdDn0scGevP k0U7FEarAOhPTPgmfHYGmidUe2dQmvcT2c1sZvkz9+HEdYOwjHBr5Us9xgvf4CMndBjl e6JlbS5xotR/rht0NvgVHKD+HDklV2XeQjv0wxe/Zx41hPUPSVyAnbXGSLDp2dfoFS+5 f/BQ==
Received: by 10.216.135.206 with SMTP id u56mr10611677wei.29.1335686061770; Sun, 29 Apr 2012 00:54:21 -0700 (PDT)
Received: from [192.168.1.65] (host-2-102-219-73.as13285.net. [2.102.219.73]) by mx.google.com with ESMTPS id gd4sm29911931wib.6.2012.04.29.00.54.19 (version=SSLv3 cipher=OTHER); Sun, 29 Apr 2012 00:54:20 -0700 (PDT)
Message-ID: <4F9CF3A8.7000801@gmail.com>
Date: Sun, 29 Apr 2012 08:54:16 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man <ipv6@ietf.org>
Subject: Options for draft-ietf-6man-uri-zoneid
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Apr 2012 07:54:23 -0000

Hi,

In the IETF 83 discussion of draft-ietf-6man-uri-zoneid-00,
there was no clear consensus on the approach to pursue. In fact,
almost the same discussion occurred around draft-fenner-literal-zone
several years ago, but at that time the topic was simply dropped.

This note summarises the main options. As a reminder, the problem to
be solved is how to tell a browser which interface to use when sending
packets to a literal link-local address. The reason for doing this is
purely for diagnostic purposes, since the Zone ID that identifies an
interface has no significance outside the sending host. For more details,
see the two drafts mentioned above.

What we have today: link local address with no Zone ID
   http://[fe80::a]

The user cannot select the outgoing interface if there is more than one.

The obvious solution would be to use the RFC4007 syntax (for an
example Zone ID of en1):

   http://[fe80::a%en1]

However, this is impossible because % is *always* an escape character in
URI syntax [RFC3986]. There is no chance of the URI community accepting
such a hack to the syntax, so it isn't an option for us.

The available options are therefore

1) Leave the problem unsolved.

This would mean that per-interface diagnostics would still have to be
performed using ping or ping6

   ping fe80::a%en1

Advantage: works today.

Disadvantage: less convenient than using a browswer.

2) Escaping the escape character as allowed by RFC 3986:

   http://[fe80::a%25en1]

Advantage: allows use of browser.
Disadvantage: ugly and confusing, doesn't allow simple cut and paste.

3) With alternative separator such as _

   http://[fe80::a_en1]

Advantage: allows use of browser.
Disadvantage: doesn't allow simple cut and paste.

4) With the "IPvFuture" syntax left open in RFC 3986:

   http://[v6.fe80::a_en1]

Advantage: allows use of browser.
Disadvantage: ugly and redundant, doesn't allow simple cut and paste.

Thus, the WG has to choose between options 1), 2), 3) and 4).

Opinions welcome!

    Brian Carpenter