Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt

From: Brian Haberman <[email-masked]>
Date: Wed, 01 Feb 2012 09:13:04 -0500

On 1/29/12 5:37 PM, Brian E Carpenter wrote:
> Hi,
>
> I've only seen one comment on this question. Any more, or should
> the authors just decide?

I tend to favor option 2.  It avoids affecting legacy support of the 
IPv6address syntax.

Regards,
Brian

>
> Regards
>     Brian Carpenter
>
> On 2012-01-04 15:23, Brian E Carpenter wrote:
>> Representing IPv6 Zone Identifiers in Uniform Resource Identifiers
>>
>> We'd like feedback on this. In particular, which of the two options
>> proposed do people prefer?
>>
>>     OPTION 1:
>>
>>     The existing syntax of IPv6address is extended by adding a specific
>>     option for the case of link-local addresses.
>>
>>     OPTION 2:
>>
>>     The existing syntax of IPv6address is retained, and a zone identifier
>>     may be added optionally to any literal address.  This allows
>>     flexibility for unknown future uses.
>>
>>   - Brian&  Bob
>>
>> -------- Original Message --------
>> Subject: I-D Action: draft-carpenter-6man-uri-zoneid-00.txt
>> Date: Tue, 06 Dec 2011 17:27:00 -0800
>> From: [email-masked]
>> Reply-To: [email-masked]
>> To: [email-masked]
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>> 	Title           : Representing IPv6 Zone Identifiers in Uniform Resource Identifiers
>> 	Author(s)       : Brian Carpenter
>>                            Robert M. Hinden
>> 	Filename        : draft-carpenter-6man-uri-zoneid-00.txt
>> 	Pages           : 6
>> 	Date            : 2011-12-06
>>
>>     This document describes how the Zone Identifier of an IPv6 scoped
>>     address can be represented in a Uniform Resource Identifier that
>>     includes a literal IPv6 address.  It updates RFC 3986 and RFC 4007.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-carpenter-6man-uri-zoneid-00.txt
>>
>>
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tomoyuki Sahara <[email-masked]>
Date: Thu, 2 Feb 2012 10:48:10 +0900

> proposed do people prefer?

OPTION 2 seems better to me.
It's easier to implement.

Thanks,
Tomoyuki

---

From: "t.petch" <[email-masked]>
Date: Fri, 3 Feb 2012 14:47:04 +0100

Brian

Did you look at the INET-ADDRESS-MIB when preparing this? I ask because it
defines [RFC4001] a 4 byte zone index; and a display hint of 'd' is decimal:-)

"InetAddressIPv6z ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
    DESCRIPTION
        "Represents a non-global IPv6 network address, together
         with its zone index:

           Octets   Contents         Encoding
            1-16    IPv6 address     network-byte order
           17-20    zone index       network-byte order

         The corresponding InetAddressType value is ipv6z(4).

         The zone index (bytes 17-20) is used to disambiguate
         identical address values on nodes that have interfaces
         attached to different zones of the same scope.  The zone index
         may contain the special value 0, which refers to the default
         zone for each scope.
    SYNTAX       OCTET STRING (SIZE (20))

Tom Petch

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Feb 2012 08:11:41 +1300

Thanks Tom, this is new to me. I don't understand
where the 'decimal' hint comes from, given that the
practice has always been to use alphanumerics.

Does anyone know if this is actually used, and if so, how?

Regards
   Brian Carpenter

---

From: "t.petch" <[email-masked]>
Date: Fri, 3 Feb 2012 21:01:32 +0100

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "6man" <[email-masked]>
Sent: Friday, February 03, 2012 8:11 PM

Brian

My exposure to zoneids started with the installation of Windows 2000
Servers, but there was no SNMP involved there; I cannot recall if
URI were in use, I think not, and the ids I saw were, I think, numeric.

I did see that RFC4007 says that
"   Implementations choosing to follow the
   recommended basic API [10] will want to restrict their index values
   to those that can be represented by the sin6_scope_id field of the
   sockaddr_in6 structure."
but I am not sure what that means, in terms of character set.

Tom Petch

---

From: Fernando Gont <[email-masked]>
Date: Fri, 03 Feb 2012 17:39:25 -0300

> Does anyone know if this is actually used, and if so, how?

Jumping into the "discussion" -- (please shell if I misunderstood the
question).

Windows uses decimal zone-ID's. e.g.; fe80::1%1

(where %1, %2, etc. are the different interfaces...)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Feb 2012 10:25:08 +1300

> but I am not sure what that means, in terms of character set.

Not much, since it's a uint32_t.

"Linux only supports it for link scope addresses, in that case sin6_scope_id contains the interface index (see netdevice(7)) "

In other words, if it's presented as "eth0" or "foobar99" in a URI,
it will get mapped into an interface number before it goes into a
socket call. That mapping will be o/s and host dependent. At least in Linux,
it's netdevice ioctls that convert between an interface name and its index
number.

"SIOCGIFNAME
    Given the ifr_ifindex, return the name of the interface in ifr_name. This is the only ioctl which returns its result in
ifr_name.
SIOCGIFINDEX
    Retrieve the interface index of the interface into ifr_ifindex. "

I assume that the MIB is intended to hold the index, up to 4 bytes long,
not the name.

   Brian

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 03 Feb 2012 23:11:44 -0800

At Fri, 3 Feb 2012 21:01:32 +0100,

> but I am not sure what that means, in terms of character set.

(I've not read the the uri-zoneid draft, but anyway) In terms of
RFC4007 zone indices are primarily numeric numbers.  Only in the
textual representation of <address>%<zone_id>, and only optionally for
convenience, the zone_id part can be a more human-understandable form,
such as an network interface name that can uniquely identify the
corresponding zone in the context of <address>%<zone_id>.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Brian Haberman <[email-masked]>
Date: Sat, 04 Feb 2012 08:20:39 -0500

On 2/4/12 2:11 AM, JINMEI Tatuya / 神明達哉 wrote:
> "t.petch"<[email-masked]>  wrote:
>
> textual representation of<address>%<zone_id>, and only optionally for
> corresponding zone in the context of<address>%<zone_id>.

The zone ID information included in the InetAddressIPv6z object in RFC 
4001 was modeled after the description of the zone ID in RFC 4007.  As 
Jinmei points out, the user friendly name is mapped to an easily indexed 
interface number to determine the actual zone.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Feb 2012 08:24:38 +1300

> interface number to determine the actual zone.

Exactly, and obviously in a URI it will be the user friendly name.
The mapping is a host-specific function.

   Brian C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Feb 2012 11:40:58 +0100

Hi,

I have one question. The I-D restricts zoneid names to 15 characters:

      ZoneID = 1*15unreserved

This raises the question why limiting this to 15 characters. I know
that at my Linux and MacOS X boxes have this limit (and I would not be
surprised if BSDs do as well) but at the end it is a #define. So the
question is whether this limit should be hard coded in the URI format.
Looking at RFC 3986, I see

      reg-name    = *( unreserved / pct-encoded / sub-delims )
or
      port        = *DIGIT

and it appears there is no limit in the URI format on DNS names or
port numbers (even though today's DNS and transport protocols put
limits on those things).

/js

PS: I am asking this question because there is a MIB object ifName
    that has a limit of 255 ASCII characters (I assume basically due
    to SNMP constraints) and there is a YANG module in the making
    which currently allows 255 UTF-8 characters and I think it would
    be nice to think a moment about how these things fit together.

PS: RFC 3493 only says there is a constant IF_NAMESIZE - so the socket
    API does not really say what the interface name size limit really
    is.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "t.petch" <[email-masked]>
Date: Tue, 7 Feb 2012 11:05:20 +0100

Juergen

This topic kicked off with
http://www.ietf.org/mail-archive/web/ipv6/current/msg14975.html
as  a report of some unexpected behaviour in Firefox and the view
there was that BSD and Linux imposed a limit of 15 characters.

The question also arose as to whether or not this impacted DNS.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Feb 2012 13:58:49 +0100

> there was that BSD and Linux imposed a limit of 15 characters.

While 15 characters seem to be a common length restriction in todays
Unix implementations, there does not seem to be an architectural
constraint that it has to be 15 - the socket API functions say there
is a limit but they leave it open what it is. On a really low-end
Juniper router in our lab (without doing anything to it), I find
interface names like sp-0/0/0.16383 - already 14 characters. But then
I also realize that this interface name contains characters that do
not fit the unreserved production of RFC 3986 either.

So in short, I think we should avoid putting up length restrictions
and we may need to think what to do about interface names that contain
characters not matching the unreserved production of RFC 3986. Perhaps
if all characters are digits, we can treat the value as an interface
number as a last resort.

/js

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Feb 2012 09:53:10 +1300

On 2012-02-08 01:58, Juergen Schoenwaelder wrote:
> characters not matching the unreserved production of RFC 3986. 

I don't see any particular value in limiting the ZoneID string to 15.

Reserved characters can always be % escaped; that's not an issue,
but should be mentioned in the text.

> Perhaps

The interface number is uint32 anyway, in the MIB and the socket API,
which limits it to decimal 4294967295, i.e. ten characters. In any
case the name/number mapping is host-specific and has nothing whatever
to do with the URI format.

   Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Feb 2012 08:17:42 +0100

> I don't see any particular value in limiting the ZoneID string to 15.

Good.
 
> but should be mentioned in the text.

The text currently says

    ZoneID = 1*15unreserved

and my understanding of unreserved is that it does not allow %
escaping. So the ZoneID production should likely be changed to
something like this:

    ZoneID = *( unreserved / pct-encoded )

/js

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Feb 2012 08:41:33 +1300

Hi Juergen,

>     ZoneID = *( unreserved / pct-encoded )

Well, I'd like a URI guru to confirm that, but it makes sense,
except that it needs to be 1* since a null string isn't useful.

The new draft has ZoneID = 1*unreserved but that's easy to fix.

Thanks
    Brian

---

From: "t.petch" <[email-masked]>
Date: Fri, 10 Feb 2012 12:43:54 +0100

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>; "t.petch"
<[email-masked]>; "6man" <[email-masked]>
Sent: Wednesday, February 08, 2012 8:41 PM

> except that it needs to be 1* since a null string isn't useful.

Since this is an update to RFC3986, I think that, once this list has
come to a consensus, then the I-D should be mentioned on the
URI list, [email-masked]  (being non-IETF, this list can be a bit of a pain
to use).  Note that this is not the uri-review list, which is for new
schemes, which this is not.

Tom Petch

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2012 08:25:08 +1300

Tom,

On 2012-02-11 00:43, t.petch wrote:
...

> schemes, which this is not.

Of course, this draft needs to be checked and I expect we will consult
with the Apps ADs and the W3C liaison to ensure that all bases are covered.

    Brian