Subject: IPv6 Zone Identifiers Considered Hateful

From: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 19 Mar 2012 10:55:48 +0000

I've obviously not been doing all my homework, and RFC 4007 slipped my attention.  Worse, for all the communication my IPv6 nodes are doing amongst themselves using link-local addresses, it's never really been much more than a hastily-justified curiosity why, when I ping one from the other using link-local-scoped addresses, I have to put in this zone identifier (%ifname on BSD and Linux).

Yesterday, I configured a DNS server to listen just using a link-local address, the one autoconfigured for an ethernet card accessible to all the nodes.  It's a host, not a router, so I'm relying on that address not being routable and being filtered at the router.  It didn't work.  The server would not start until I specified the zone suffix.  Now I am wondering why, given that there is no ambiguous link-local address anywhere around here, I need to do that.  Can't it figure it out itself?

What about the other problems with this suffix?  It's host-specific, so it's unsafe to share it over the network (I need to share the DNS server using stateless DHCPv6).  The format differs between OSes (Windows uses %n).  It interferes with URLs, if Wikipedia is to be believed.  It breaks expectations, essentially because it's the exception to the rule that the address bits (and hence the address format) conveys all the required information.

So zone suffixes are considered hateful.  Yes, it's true, I enjoy a good whinge and it's a shame I had to learn this on-demand, but really, their use should be limited to just those circs where it's actually necessary, and let's be honest, that ought to be very rare.

Cheers,
Sabahattin

---

From: Francis Dupont <[email-masked]>
Date: Mon, 19 Mar 2012 13:56:00 +0100

In your previous mail you wrote:

>  So zone suffixes are considered hateful.

=> in fact it is not the problem: link-local address
are considered hateful.

Regards

[email-masked]

PS: at least for use in standard applications.

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 19 Mar 2012 09:38:36 -0500

> Yesterday, I configured a DNS server to listen just using a link-local address, the one autoconfigured for an ethernet card accessible to all the nodes.  It's a host, not a router, so I'm relying o…

Sure, it can, until a new network interface appears on that box (VPN, 
tunnel, hardware, etc.).

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: "t.petch" <[email-masked]>
Date: Tue, 20 Mar 2012 09:24:27 +0100

Top posting because it fits the Subject well, the details below less so.

There is currently a thread in 6man on

Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt
http://www.ietf.org/mail-archive/web/ipv6/current/msg15505.html

on how to put this zoneid into a URI which, given that zone ids start with a %
and that RFC3986 gives that character special, syntactical significance, would
appear to verge on the impossible.  As and when IPv6 gets rolled out, I suspect
that this topic will bite, or haunt, an ever growing number of people - which
makes it worth some consideration now.

Tom Petch

----- Original Message -----
From: "Sabahattin Gucukoglu" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 19, 2012 11:55 AM
Subject: IPv6 Zone Identifiers Considered Hateful

I've obviously not been doing all my homework, and RFC 4007 slipped my
attention.  Worse, for all the communication my IPv6 nodes are doing amongst
themselves using link-local addresses, it's never really been much more than a
hastily-justified curiosity why, when I ping one from the other using
link-local-scoped addresses, I have to put in this zone identifier (%ifname on
BSD and Linux).

Yesterday, I configured a DNS server to listen just using a link-local address,
the one autoconfigured for an ethernet card accessible to all the nodes.  It's a
host, not a router, so I'm relying on that address not being routable and being
filtered at the router.  It didn't work.  The server would not start until I
specified the zone suffix.  Now I am wondering why, given that there is no
ambiguous link-local address anywhere around here, I need to do that.  Can't it
figure it out itself?

What about the other problems with this suffix?  It's host-specific, so it's
unsafe to share it over the network (I need to share the DNS server using
stateless DHCPv6).  The format differs between OSes (Windows uses %n).  It
interferes with URLs, if Wikipedia is to be believed.  It breaks expectations,
essentially because it's the exception to the rule that the address bits (and
hence the address format) conveys all the required information.

So zone suffixes are considered hateful.  Yes, it's true, I enjoy a good whinge
and it's a shame I had to learn this on-demand, but really, their use should be
limited to just those circs where it's actually necessary, and let's be honest,
that ought to be very rare.

Cheers,
Sabahattin

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Mar 2012 11:11:38 -0400

--On Tuesday, March 20, 2012 09:24 +0100 "t.petch"
<[email-masked]> wrote:

> on how to put this zoneid into a URI which, given that zone
> ids start with a % and that RFC3986 gives that character
> special, syntactical significance, would appear to verge on
> the impossible.  As and when IPv6 gets rolled out, I suspect
> that this topic will bite, or haunt, an ever growing number of
> people - which makes it worth some consideration now.

Tom,

FWIW, zoneids are nothing special in that regard.  While it has
been used less in recent years than a decade or two ago, "%" has
had a special meaning in some email addresses for a long time,
requiring either special treatment in MAILTO or that users know
how to escape the character and that applications follow the
decoding rules exactly and in the correct order.  Tricky
interpretation of "+" in HTML has also made it difficult to use
that character in email addresses in many web-like contexts and,
for it, incorrect interpretations of the decoding rules in
applications has contributed to making escaping the character
into %2B an insufficient workaround.

While RFC 3986 makes the rules perfectly clear, we've seen
applications get the coding and decoding wrong.  Expecting end
users to understand the rules about when escaping is required
and to apply them correctly is, at least IMO, pretty hopeless.

Having IRIs as an overlay on URIs that can, unbeknown to the
user, create even more %-encodings, increases the risks and
complications.  We will almost certainly see applications that,
in the hope of a better user experience (and regardless of what
we tell them in standards) try to decode URIs that contain %
characters into IRIs and getting that wrong.

I think it is all a nightmare waiting to happen.  You may or may
not agree.  Certainly those who are working on IRIs and URIs
either don't see the risks or see them as acceptable.   

Either way, there is nothing particularly special about IPv6
zone identifiers in that regard.  If nothing, interactions
between those zone identifiers and presentation of IPv6
addresses to users (in URIs or otherwise) ought to reinforce a
conclusion the IETF reached years ago but we seem to keep
forgetting.  That conclusion was that protocols and methods that
expose IP addresses (whether IPv4 or IPv6) to users are
generally a bad idea.  If we believe it, we should be designing
in ways that hide or abstract that information, whether into the
DNS, into better location-identifier separation, or otherwise.
That principle doesn't help with special syntax in email
addresses or with the URI<->IRI<->user interactions, but might
call for some careful thinking about zone identifiers and/or
IPv6 addresses and URIs.

The context in which many of us take the opportunity to pledge
to the universal deployment of IPv6 is not intended to numb the
pain of self-inflicted bullets to our feet.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Mar 2012 10:16:10 +1300

>> people - which makes it worth some consideration now.

Just to clarify: the authors of draft-ietf-6man-uri-zoneid
are well aware of the fact that the draft has to be updated
because of that issue, and that discussion is ongoing in the
6man WG for now.

It is also very clear that this whole proposal is only of value
for low-level connectivity diagnosis and has no meaning outside
that context.

    Brian

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 21 Mar 2012 13:44:31 -0400

> From: Sabahattin Gucukoglu [[email-masked]]
> 
> [...] when I ping one from the other using link-local-scoped
> addresses, I have to put in this zone identifier (%ifname on BSD and
> Linux).
> [...]
> Can't it figure it out itself?

OK, I know nothing about the subject, but when I do "ifconfig" I get:

    eth0      Link encap:Ethernet  HWaddr 00:16:35:AF:82:03  
	      inet addr:135.55.22.90  Bcast:135.55.22.255  Mask:255.255.255.0
	      inet6 addr: fe80::216:35ff:feaf:8203/64 Scope:Link
	      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
	      [...]

Looking at the link-local address, it appears to be constructed from
the interface's MAC address, and basically nothing else.

This suggests that the link-local address of another system on an
attached network would contain that system's MAC address, but nothing
to identify which network, and thus, *this* system has no algorithmic
way to determine which interface goes to the proper network.

Dale

---

From: Craig Finseth <[email-masked]>
Date: Wed, 21 Mar 2012 12:54:42 -0500

> way to determine which interface goes to the proper network.

You've just rediscovered what the "link local" part of the link-local
address means: the address is local to the link!  It is not globally
unique or even unique within a host, it is just unique within a link.
Thus, if a host has more than one interface (and most do: at least one
network interface + loopback, which is a separate interface), you need
to tell it which one you mean when you use link-local addresses.

-- 
Craig A. Finseth

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 21 Mar 2012 13:57:24 -0400

> From: Craig Finseth [[email-masked]]
> 

Actually, it's globally *unique*, because it contains the MAC address.
The problem is that it's not *routable*, even within the context of a
single host.  And unless you give an application on the host guidance,
it depends on host-context routing to get its output packets to the
correct wire.  It's hard to remain aware that host-context routing is
important, because it's almost always worked.

Dale

---

From: Craig Finseth <[email-masked]>
Date: Wed, 21 Mar 2012 15:15:27 -0500

On Wed, Mar 21, 2012 at 12:57 PM, Worley, Dale R (Dale)
<[email-masked]> wrote:
> important, because it's almost always work.

Well, it's globally unique to a host, not to an interface: the host
(in general) uses the same link-local address on all interfaces.
Thus, you can't tell from the address which interface it refers to.

--
Craig A. Finseth

---

From: Fred Baker <[email-masked]>
Date: Wed, 21 Mar 2012 21:43:53 +0100

> I've obviously not been doing all my homework, and RFC 4007 slipped my attention.  Worse, for all the communication my IPv6 nodes are doing amongst themselves using link-local addresses, it's never…

To be honest, I'm still not sure I understand the argument for a zone identifier.

From MIF's perspective, if the same prefix is placed on multiple interfaces, the system might see peers using a given address on multiple interfaces, and at least some devices might be expected to route between the interfaces. Architecturally, this can be easy to solve or hard. We have any number of cases (think about PPP for example) in which we bundle multiple interfaces under a common super-interface and "do something". In PPP Multilink, we might segment messages into smaller frames, distribute them across a number of interfaces to the same place, and reconstitute the original message on the other side. In this case, it seems that we want IP to use two layers of interfaces, a virtual one instantiated by multiple lower layer interfaces, and place the prefix on the virtual interface. When we are wondering what MAC address should be associated with a given IP address, we ask each of the lower layer interfaces, and if we get a result on one of them we know where we're going. The big issue will be routing among the physical interfaces - something required for it to be seamless and yet not as trivial as it might sound.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Mar 2012 10:51:36 +1300

> To be honest, I'm still not sure I understand the argument for a zone identifier.

I've always viewed them as a fault diagnosis tool, mainly.
But the first paragraph of section 6 of RFC 4007 makes a stack
implementation argument:

>> 6.  Zone Indices
>> 
>>    Because the same non-global address may be in use in more than one
>>    zone of the same scope (e.g., the use of link-local address fe80::1
>>    in two separate physical links) and a node may have interfaces
>>    attached to different zones of the same scope (e.g., a router
>>    normally has multiple interfaces attached to different links), a node
>>    requires an internal means to identify to which zone a non-global
>>    address belongs.  This is accomplished by assigning, within the node,
>>    a distinct "zone index" to each zone of the same scope to which that
>>    node is attached, and by allowing all internal uses of an address to
>>    be qualified by a zone index.

In other words if the IETF doesn't define the zone index, every
implementor will have to do so anyway. Also, read the last clause
carefully: it says the stack MUST allow OPTIONAL use of the zone
index internally.

> From MIF's perspective, if the same prefix is placed on multiple interfaces, 

The prefix fe80::/10 is automatically on every interface. That's the
only case where I'm certain we need a zone index in practice, but the
definition isn't limited to that case.

   Brian

> the system might see peers using a given address on multiple interfaces, and at least some devices might be expected to route between the interfaces. Architecturally, this can be easy to solve or hard. We have any number of cases (think about PPP for example) in which we bundle multiple interfaces under a common super-interface and "do something". In PPP Multilink, we might segment messages into smaller frames, distribute them across a number of interfaces to the same place, and reconstitute the original message on the other side. In this case, it seems that we want IP to use two layers of interfaces, a virtual one instantiated by multiple lower layer interfaces, and place the prefix on the virtual interface. When we are wondering what MAC address should be associated with a given IP address, we ask each of the lower layer interfaces, and if we get a result on one of them we know where we're going. The big issue will be routing among the physical interfaces - something req
uired for it to be seamless and yet not as trivial as it might sound.

---

From: Fred Baker <[email-masked]>
Date: Thu, 22 Mar 2012 01:29:56 +0100

> carefully: it says the stack MUST allow OPTIONAL use of the zone

Implementors generally *do* have some internal form of a zone index, and it doesn't look at all like what the RFC describes. It is a machine address or a lookup index of some kind for a table that is associated with an interface. Sometimes, part of it is a card identifier.

> definition isn't limited to that case.

The use of something to get me to the interface table in question isn't what I am questioning. It's the use of that particular something...

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Mar 2012 16:49:34 +1300

Fred,

> Implementors generally *do* have some internal form of a zone index, and it doesn't look at all like what the RFC describes. It is a machine address or a lookup index of some kind for a table that…

Yes, someone recently cited fe-0/0/1 as a real-world example of an
interface identifier (in practice equivalent to a zone identifier)
RFC 4007 says nothing about the syntax of the identifier. Clearly
the mapping to a 32 bit integer is a local matter in the node; look
at RFC 4007 and the socket API together.

> The use of something to get me to the interface table in question isn't what I am questioning. It's the use of that particular something...

IMHO it is very limited, mainly for diagnostic use. We need to get
it right but it has no mainstream value that I can see.

    Brian

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Mar 2012 11:50:44 +0000

> Thus, you can't tell from the address which interface it refers to.

That kind of setup is pretty rare these days AFAIK.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall: South or southeast 5 to 7, decreasing 4 at times. Rough or very
rough. Fair. Moderate or good.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 22 Mar 2012 12:48:25 -0400

> Thus, you can't tell from the address which interface it refers to.

But remember we're talking about the address given to "ping" -- it's
not the address of *this* host, but the address of some host that is
on some network on which this host has an interface.  So the fact that
this host uses the same link-local address on all interfaces, while
true, is not important.  What's important is that given the link-local
address of *some other host*, there is no algorithmic way to determine
which of this host's interfaces is needed to access it.

In regard to URIs:

People have spoken about the annoyance of using "%" to introduce the
zone identifier, and the fact that "%" is special in URIs and would
need escaping, etc.  But (1) it's unlikely anyone will write URIs with
zone identifiers, since they'd only be usable on a single host, and
(2) the syntax of RFC 3986 ("Uniform Resource Identifier (URI):
Generic Syntax") does not provide for specifying zone identifers on
IPv6 addresses.  Indeed, it says "This syntax does not support IPv6
scoped addressing zone identifiers."

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Mar 2012 11:27:18 +1300

On 2012-03-23 05:48, Worley, Dale R (Dale) wrote:
...

> scoped addressing zone identifiers."

This is a current topic in 6man so it may change.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Wed, 28 Mar 2012 10:13:53 +0200

>  the interface's MAC address, and basically nothing else.
       ^^^^^^^^^^^

=> note the IEEE spec says device MAC address and if the common
interpretation is device == NIC there is at least one vendor where
device == machine, i.e., you get the same MAC address so same link-local
address on all the 10 interfaces of a 10 interface box!

Regards

PS: I maintain my opinion: zone identifiers don't suck, link-local
addresses used where they should not definitely suck.

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 28 Mar 2012 10:27:35 -0400

>>  the interface's MAC address, and basically nothing else.

Maybe link local addresses are erroneously used where one should use 
RFC4193 (Unique Local IPv6 Unicast Addresses) with L=1? (I mean where 
link local addresses are inconvenient but not necessary.)

I.e. something like FDxx:yyyy:zzzz:nnnn:id
where xx:yyyy:zzzz is 40 random bits that you pick-up as you wish,
nnnn is a subnet id for your (local) routing scheme
id is the 64 bits interface ID ...

It's a suggestion.

I guess the trouble of assigning addresses in this way is much smaller 
than tracking link local addresses derived from hardware serial numbers. 
The interface ID assignment strategy/tools with RFC4193 is deemed to be 
close to the strategy/tools useful for globally routable addresses.

Is this well explained in the IPv6 tutorials?

Regards,

-- 
- Thierry Moreau