Subject: Link-local IPv6 addresses in URIs

From: Kerry Lynn <[email-masked]>
Date: Mon, 14 Nov 2011 00:41:12 -0500

Greetings,

I've noticed that a "bug" has re-appeared in Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=700999

In older versions of Firefox (e.g. 3.6.23) it is possible to enter URIs of
the form http://[fe80::206:98ff:fe00:232%tap0] in the
location bar and get a positive result.  This capability is quite handy in
simple testing scenarios and obviously requires the client and server
to be on a common link (so I don't necessarily see how it creates a
security risk.)

According to a note attached to the bug, the regression occurred as a
result of fixing a security bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=<https://bugzilla.mozilla.org/show_bug.cgi?id=700999>
504014 <https://bugzilla.mozilla.org/show_bug.cgi?id=504014>
I don't seem to have access to that bug, so I don't know the complete
rationale.  However, the note on 700999 says the title is "Enforce RFC
3986 syntax for IPv6 literals".  It goes on to say that RFC 3986
"disallows" interface specifiers (a.k.a. zone indices:
http://en.wikipedia.org/wiki/IPv6_address#Link-local_addresses_and_zone_indices
).

I don't see how a link-local address can be used in this context w/o
using a zone index.  Granted, RFC 3986 doesn't cover this case but
it also doesn't prohibit it.  This leads me to suspect it was an oversight,
so I'm wondering if RFC 3986 needs to be updated to cover it link-
local IPv6 literals?  If so, is there a reference that could be used to
derive the necessary ABNF?

Thanks, -K-

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Nov 2011 22:40:13 +1300

Kerry,

On 2011-11-14 18:41, Kerry Lynn wrote:
> using a zone index.  

As soon as there's more than one interface, there is an issue.

> Granted, RFC 3986 doesn't cover this case but
> it also doesn't prohibit it.  

Yes it does, because the ABNF for IPv6address is for an address, not
a scoped address. A scoped address would not conform to the ABNF, so
that amounts to a prohibition.

> This leads me to suspect it was an oversight,

This part of RFC 3986 derives from RFC 2732 (which had broken ABNF,
and didn't allow for a scoped address, because they didn't exist then).

> derive the necessary ABNF?

I don't believe so. The ABNF has never been extended to cover RFC 4007
as far as I know.

Getting RFC 3986 updated would be reasonably complicated I suspect.
It involves a chat with the W3C people for a start.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2011 18:00:27 +1300

Dear 6man,

Kerry and I talked about this. It seems to me that, given we allow for
IPv6 literals in URIs principally for diagnostic purposes, it is indeed
unfortunate that http://[fe80::206:98ff:fe00:232%tap0] is not
allowed by the formal syntax.

This would need to be fixed by a small RFC that updates 3986,
just as 2732 updated 2396 in its day.

Do people agree that this is a reasonable thing to do? If so, I'll
follow it up appropriately (i.e. I will draft something when time permits).

Regards
   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Nov 2011 13:13:13 +0800

On Nov 17, 2011, at 13:00, Brian E Carpenter wrote:

> Do people agree that this is a reasonable thing to do? 

Yes please!

I trust that the update spec will explain the "for debugging" focus and will have appropriate warning 

-- that the link identifiers are node-local names with node-local semantics, and 
-- about security considerations, e.g., that this capability might be used to send packets to random links from malicious web pages unless properly restricted in a browser.

Grüße, Carsten

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 17 Nov 2011 01:14:14 -0500

On Thu, Nov 17, 2011 at 12:13 AM, Carsten Bormann <[email-masked]> wrote:

> My ABNF is pretty rusty, so I offer the following extension to the RFC 3986
IPv6address rule only as a starting point:

/ "FE80::" [ *3( h16 ":" ) h16 ] [ "%" 1*4(ALPHA / DIGIT) ]

If we proceed with this, should we fix the IPv6address rule to align with
RFC 5952 or just make the minimal change?

> -- about security considerations, e.g., that this capability might be used
> to send packets to random links from malicious web pages unless properly
> restricted in a browser.
>
> You mean "specified links", right?  I still don't understand the security
risk
this poses, so maybe we could discuss it offline.

Thanks, -K-

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 Nov 2011 07:56:01 -0500

> follow it up appropriately (i.e. I will draft something when time permits).

I agree that it is reasonable to do.

Regards,
Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 17 Nov 2011 13:11:38 -0600

Yes from me. Thanks.

Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, November 17, 2011 12:00 AM
To: 6man
Cc: Kerry Lynn
Subject: Re: Link-local IPv6 addresses in URIs

Dear 6man,

Regards
   Brian

> It involves a chat with the W3C people for a start.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Tomoyuki Sahara <[email-masked]>
Date: Fri, 18 Nov 2011 11:27:14 +0900

Hi,

That sounds good to me too.

> / "FE80::" [ *3( h16 ":" ) h16 ] [ "%" 1*4(ALPHA / DIGIT) ]

I have some comments:

  - An interface name may be longer than 4 characters.  But I know we should
    have some limit so I suggest 15 because it's maximum length of interface
    name on *BSD and Linux systems.

  - FYI, there was an attempt to define textual representation of zone id:
    http://tools.ietf.org/html/draft-ietf-ipngwg-scoping-arch-04#section-12

  - Can we have a dot in interface name?  On Linux systems, VLAN interfaces
    have one.  An example in the draft above has "%pvc1.3" (may be an ATM
    interface?).

Thanks,
Tomoyuki.

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 17 Nov 2011 21:53:59 -0500

On Thu, Nov 17, 2011 at 9:27 PM, Tomoyuki Sahara <[email-masked]> wrote:

> Thanks for the reference.  I'll take a look at it before revising the ABNF
again.

-K-

---

From: Brian Haberman <[email-masked]>
Date: Fri, 18 Nov 2011 08:50:52 -0500

>     http://tools.ietf.org/html/draft-ietf-ipngwg-scoping-arch-04#section-12

Published as RFC 4007 (http://tools.ietf.org/html/rfc4007).

Regards,
Brian

---

From: François-Xavier Le Bail <[email-masked]>
Date: Fri, 18 Nov 2011 07:33:01 -0800 (PST)

>________________________________
> From: Kerry Lynn <[email-masked]>
>To: Tomoyuki Sahara <[email-masked]> 
>Cc: 6man <[email-masked]> 
>Sent: Friday, November 18, 2011 3:53 AM
>Thanks for the reference.  I'll take a look at it before revising the ABNF again.

Hi,

In Linux, you can use any character in VLAN interface name :
examples:
ip link add link eth0 name eth0.5  type vlan id 5
ip link add link eth0 name eth0-6  type vlan id 6
ip link add link eth0 name eth0#7  type vlan id 7
ip link add link eth0 name eth0-8  type vlan id 8
ip link add link eth0 name eth0+9  type vlan id 9
ip link add link eth0 name eth0_10  type vlan id 10
ip link add link eth0 name eth0,11  type vlan id 11
ip link add link eth0 name eth0:::12  type vlan id 12
ip link add link eth0 name eth0.+-  type vlan id 13

Thanks,
Francois-Xavier

---

From: François-Xavier Le Bail <[email-masked]>
Date: Fri, 18 Nov 2011 08:03:29 -0800 (PST)

> From: François-Xavier Le Bail <[email-masked]>
> To: Kerry Lynn <[email-masked]>; Tomoyuki Sahara <[email-masked]>

Luckily, the "%" is invalid.

Francois-Xavier

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Nov 2011 15:57:08 +1300

>> / "FE80::" [ *3( h16 ":" ) h16 ] [ "%" 1*4(ALPHA / DIGIT) ]

That's one option; another one is to define the syntax for *any*
address format and restrict it to fe80::/10 by a SHOULD.
I'm inclined towards the latter, in case some other use case
shows up later.

>     name on *BSD and Linux systems.

Seems reasonable.

>     http://tools.ietf.org/html/draft-ietf-ipngwg-scoping-arch-04#section-12

That's RFC 4007 now.

>     have one.  An example in the draft above has "%pvc1.3" (may be an ATM

Yes, we can use the character set "unreserved" from the URI syntax
which is defined by

   unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

      Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2011 14:30:03 +1100

On a related issue to link locals in URI's, we don't currently have
a good method of supporting link locals in the DNS.  Sure we can
add them as AAAA records but they are essentially useless as the
scope information is lost.  People keep saying use LL for disconnected
but it just doesn't work without more support.

Mark

DNS
host.example.net. SAAAA  FE80::1 link.example.net.
host.example.net. SAAAA  2001:DB8::1 .		; "." indicates global scope
host.example.net. SAAAA  ::ffff:198.51.100.0 .	; "." indicates global scope
host.example.net. AAAA  2001:DB8::1
host.example.net. A  198.51.100.1

RA LINK-NAME link.example.net
DHCP LINK-NAME link.example.net

getaddrinfo()
AI_FILTERED  filter scoped addresses which don't match a local scope name.
	     Set in AI_DEFAULT.

If you get a response to a SAAAA lookup you don't need to do a A/AAAA lookup
as it is a superset of A and AAAA.

host.example.net SAAAA :: .  indicates a machine that exist but is off net

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Tue, 22 Nov 2011 17:34:49 +0100

>but it just doesn't work without more support.

For disconnected operation, why not have getaddrinfo fill in the scope?
Just set it to the interface over which the DNS reply arrived. 

I have to admit that this may become a bit tricky if the DNS resolver is local
or if interface information is lost in some other way.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Nov 2011 09:52:59 +1300

>> but it just doesn't work without more support.

Other people keep saying "use ULA for disconnected". The fact
that you can put ULA into (er, local) DNS without any fancy
stuff is a distinct advantage.

IMHO link-local should be used only for bootstrapping a host and
for diagnostic purposes. I guess I could statically configure a
printer on fe00::a%1 if I really had no choice.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Nov 2011 10:35:55 +1300

On 2011-11-19 05:03, François-Xavier Le Bail wrote:

...
> Luckily, the "%" is invalid.

Unfortunately, the obvious subset in URI syntax is more limited:

If you could live without #+,.: it would be much simpler.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Nov 2011 13:03:18 +1300

Kerry,

> In the case of link-
> local adresses stored in AAAA records, the zone index would seem to
> indicate the corresponding interface with respect to the *server* (assuming
> a multi-homed server here).

Which is completely and utterly irrelevant to any host except
that one particular physical DNS server. So I don't see what
possible use it has for anyone.

Regards
   Brian

On 2011-11-23 10:56, Kerry Lynn wrote:
> On Tue, Nov 22, 2011 at 3:52 PM, Brian E Carpenter <
> [email-masked]> wrote:
> 
>> This is a distinctly different problem than the one that kicked off the
> link-
> local discussion.  In the web browser case, you know the link-local
> destination address of the server a priori but it only has validity with
> respect to a particular link, and there's no way to indicate the zone
> index to the browser (assuming multi-homed client here).  The once-
> existing capability was removed because there is no RFC support for it.
> 
> The DNS case seems like a server-side issue.  In the case of link-
> local adresses stored in AAAA records, the zone index would seem to
> indicate the corresponding interface with respect to the *server* (assuming
> a multi-homed server here).  What's more, the DNS server would need to
> keep track of the interface on which the query arrived and only respond
> with a link-local address if the client and server are on the same
> interface.
> 
> Some additional observations:
> - If you want to stay with link-local addresses then perhaps multicast
>   DNS is the best solution for you.
> - If you want to stay with unicast DNS, then ULAs have the advantage
>   of being routable and the problem goes away.
> - If you want to stay with link-local addresses *and* DNS, then perhaps
>   you need to engage dnsext WG to discuss the server-side issues.
> 
> -K-
> 
> 
>   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Nov 2011 13:14:56 +1300

On 2011-11-23 11:09, Kerry Lynn wrote:
> On Tue, Nov 22, 2011 at 4:56 PM, Kerry Lynn <[email-masked]> wrote:
> 
>>> BTW, I realized this whole conversation is probably re: local host files
> just after I hit the "send" button ;-)

Yes, I could put

fe80::a%1  printer1.local

in my hosts file I guess. Except that on my o/s, the zone ID is
not handled by the resolver at all, unsurprisingly.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Nov 2011 12:48:02 +1100

> printer on fe00::a%1 if I really had no choice.

ULA has similar scope issues.  It's just that the OS don't knock
you over when you do bind(), connect(), sendto() and sendmsg()
without scope information.  You can avoid using non local ULA with
the same filtering mechanisms.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 23 Nov 2011 03:28:33 +0000

> IMHO link-local should be used only for bootstrapping a host and for diagnostic purposes. I guess I could statically configure a printer on fe00::a%1 if I really had no choice.

I would rather not rely on DNS for that. Local discovery protocols like UPNP look more adequate to the task of printer discovery.

-- Christian Huitema

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 22 Nov 2011 16:56:36 -0500

link-

-K-

  Brian

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 22 Nov 2011 17:09:29 -0500

---

From: Philip Homburg <[email-masked]>
Date: Wed, 23 Nov 2011 13:59:53 +0100

>the same filtering mechanisms.

I think this a different discussion. It is whether you want to mix local and
global information in DNS. My preference would be to keep it separate (i.e.
never have globally visible zones that contain local addresses) but other
people may think differently.

However, that is a much more generic discussion that doesn't belong on this
list, but should on dnsext or something like that.

---

From: François-Xavier Le Bail <[email-masked]>
Date: Wed, 23 Nov 2011 05:57:16 -0800 (PST)

> From: Brian E Carpenter <[email-masked]>
> To: François-Xavier Le Bail <[email-masked]>
> Cc: Kerry Lynn <[email-masked]>; Tomoyuki Sahara <[email-masked]>; 6man <[email-masked]>
> Sent: Tuesday, November 22, 2011 10:35 PM

I totally agree, my (unclear) message was only a warning for Linux users.

François-Xavier