Re: IPv6 Zone Identifiers Considered Hateful
In your previous mail you wrote: Looking at the link-local address, it appears to be constructed from 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 francis.dup...@fdupont.fr PS: I maintain my opinion: zone identifiers don't suck, link-local addresses used where they should not definitely suck.
Re: IPv6 Zone Identifiers Considered Hateful
Francis Dupont wrote: In your previous mail you wrote: Looking at the link-local address, it appears to be constructed from 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 francis.dup...@fdupont.fr PS: I maintain my opinion: zone identifiers don't suck, link-local addresses used where they should not definitely suck. 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::::id where xx:: is 40 random bits that you pick-up as you wish, 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
Re: IPv6 Zone Identifiers Considered Hateful
Craig Finseth snar...@gmail.com wrote: 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. That kind of setup is pretty rare these days AFAIK. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall: South or southeast 5 to 7, decreasing 4 at times. Rough or very rough. Fair. Moderate or good.
RE: IPv6 Zone Identifiers Considered Hateful
From: Craig Finseth [snar...@gmail.com] 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 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. 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
Re: IPv6 Zone Identifiers Considered Hateful
On 2012-03-23 05:48, Worley, Dale R (Dale) wrote: ... 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. This is a current topic in 6man so it may change. Brian
RE: IPv6 Zone Identifiers Considered Hateful
From: Sabahattin Gucukoglu [m...@sabahattin-gucukoglu.com] [...] 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
Re: IPv6 Zone Identifiers Considered Hateful
On Wed, Mar 21, 2012 at 12:44 PM, Worley, Dale R (Dale) dwor...@avaya.com wrote: 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. 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
RE: IPv6 Zone Identifiers Considered Hateful
From: Craig Finseth [snar...@gmail.com] 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. 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
Re: IPv6 Zone Identifiers Considered Hateful
On Wed, Mar 21, 2012 at 12:57 PM, Worley, Dale R (Dale) dwor...@avaya.com wrote: From: Craig Finseth [snar...@gmail.com] 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. 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 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
Re: IPv6 Zone Identifiers Considered Hateful
On Mar 19, 2012, at 11:55 AM, Sabahattin Gucukoglu wrote: 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). 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.
Re: IPv6 Zone Identifiers Considered Hateful
On 2012-03-22 09:43, Fred Baker wrote: On Mar 19, 2012, at 11:55 AM, Sabahattin Gucukoglu wrote: 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). 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.
Re: IPv6 Zone Identifiers Considered Hateful
On Mar 21, 2012, at 10:51 PM, Brian E Carpenter wrote: 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. 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. 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. 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...
Re: IPv6 Zone Identifiers Considered Hateful
Fred, On 2012-03-22 13:29, Fred Baker wrote: On Mar 21, 2012, at 10:51 PM, Brian E Carpenter wrote: 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. 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. 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. 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. 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
Re: IPv6 Zone Identifiers Considered Hateful
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 m...@sabahattin-gucukoglu.com To: ietf@ietf.org 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
URIs and zone IDs (was: Re: IPv6 Zone Identifiers Considered Hateful)
--On Tuesday, March 20, 2012 09:24 +0100 t.petch daedu...@btconnect.com wrote: 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, 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
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
Re: IPv6 Zone Identifiers Considered Hateful
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 francis.dup...@fdupont.fr PS: at least for use in standard applications.
Re: IPv6 Zone Identifiers Considered Hateful
On 03/19/2012 05:55 AM, Sabahattin Gucukoglu wrote: 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? 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: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org
