I-D ACTION:draft-beloeil-ipv6-dns-resolver-option-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Router Advertisement DNS resolver Option Author(s) : L. Beloeil Filename: draft-beloeil-ipv6-dns-resolver-option-00.txt Pages : 0 Date: 2002-10-1 This document defines the DNS resolver (DNSR) option used to advertise IPv6 addresses of DNS resolvers on a link. The DNSR option, which lists the IPv6 addresses of DNS resolvers that all nodes of the link may use to resolve name or address, is attached to IPv6 Neighbor Discovery Router Advertisement messages that are sent across a link. This document specifies the process used by a host to decide how to configure the IPv6 addresses of DNS resolvers that the host could uses in IPv6 networks. This document defines the mechanism by which a node processes the DNSR option and updates valid IPv6 addresses of DNS resolvers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-beloeil-ipv6-dns-resolver-option-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-beloeil-ipv6-dns-resolver-option-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-beloeil-ipv6-dns-resolver-option-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-beloeil-ipv6-dns-resolver-option-00.txt
Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt
Robert, I believe we are just going to disagree on the issue you have. You seem to be saying that the addr arch document (in order to go to Draft) requires that there exist at least 2 implementations that enforce the requirement that IIDs are exactly 64 bits. That is, they MUST NOT allow IIDs of length other than 64 to be used/configured. The actual requirement that IIDs be 64 bits is not an implementation requirement (in the addressing architecture document). It is a principle that is to be followed by other documents that specify usage of the IID. The last part of Section 2.5.1 says: The details of forming interface identifiers are defined in the appropriate IPv6 over link specification such as IPv6 over Ethernet [ETHER], IPv6 over FDDI [FDDI], etc. All the other IPv6 over foo documents are consistent with addr arch in this regard. I also remain unconvinced that the wording: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. translates into a requirement that there exist implementations that disallow IIDs of length other than 64. Following this logic, I suspect one could effectively prevent just about any document from being advanced to Draft. Documents typically have a number of principles that are not testable or enforceable, or where no one would bother to actually enforce something because the actual cost is too high. Consider: 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses [...] |80 bits | 16 | 32 bits| +--+--+ |..||IPv4 address | +--++-+ Note: The IPv4 address used in the IPv4-compatible IPv6 address must be a globally-unique IPv4 unicast address. What implementations prevent a non-globally unique IPv4 address from being used here? By your logic, this requirement would need to be stricken from the document. Or: All interfaces are required to have at least one link-local unicast address (see section 2.8 for additional required addresses). By your logic, we have to show that there are implementations that actually enforce that. I.e, it's not enough that implementations in practice assign a LL address to an interface, we need to show that there are implementations that prevent the possibility of the interface ever operating without a LL address. This is unreasonable. As a more general case, consider a protocol that specifies behavior X. For example, protocol X must rate limit messages of type Y. Well, anyone can come along and implement protocol X over raw sockets and have it flood the network with messages of type Y violating the required rate limitingf behavior. By your reasoning, an implementation of a protocol that doesn't also prevent another implementation running over raw sockets from violoating the spec would not be compliant. In general, no implementation can ensure that the spec is not violated when viewed in this light. Popping up a level, the arguments being used are fairly legalistic (on both mine and your side). Based on some of your earlier mail messages to the WG, it would seem that your real goal here is to do away with the requirement that all IIDs be 64 bits long and in particular you would like to remove the 'u' bit from the IID. But this was discussed explicitly within the WG and there appeared to be little support for your position. It is time to advance addr arch to Draft Standard and move on. Thomas IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Link local address for tunnel interfaces
Hi, Is it required to have a link local address on a tunnel interface. I am implementing IPv6 in IPv6 tunnels and wanted to know whether I should install a link local address on the tunnel interface. Is there any document that talks about this ? If it is required, how should I calculate a unique link local address ? regards Mukesh -- ** Everything of importance has been said before, by someone who quoted it as from somebody else. ** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ** IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt
Date:Wed, 02 Oct 2002 10:33:56 -0400 From:Thomas Narten [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | I believe we are just going to disagree on the issue you have. That may be, but I would hope that there is at least one member of the IESG who understands that 2026 is not just there to be disregarded when it is inconvenient. | You seem to be saying that the addr arch document (in order to go to | Draft) requires that there exist at least 2 implementations that | enforce the requirement that IIDs are exactly 64 bits. Either that, or the text that is in doc that requires that needs to be removed. Yes, that's what 2026 requires. | That is, they | MUST NOT allow IIDs of length other than 64 to be used/configured. Yes. The text quite clearly states that IIDs are required to be 64 bits. Why exactly is it that you can't find the two implementations of this that would make my argument here irrelevant? I suspect that you have tried. That would be a simple answer. It doesn't matter much what the answer is, whether the requirement is unimplementable (which I doubt, a if (prefixlen != 64) return (EINVAL); would be pretty easy to add...) or whether it is just that in practice, everyone believes that this is a nonsense requirement, but in any case, it is not being implemented, and hence cannot be in a DS. | The actual requirement that IIDs be 64 bits is not an implementation | requirement (in the addressing architecture document). Hmm - that's another interesting argument. But go read it again. The doc doesn't say that other specs must not define IIDs to be any other length (to which I would object, I think, or not because of the requirement itself but because I don't believe that docs should ever specify what other docs are allowed to define - it is a dumb thing to attempt in any case). What it says, quite clearly, is that the IID must always be exactly 64 bits. No restrictions upon in what contexts (just the couple of well known assumptions). If the doc wanted to set out reasons why people should only ever use 64 bit IIDs, without actually making that a requirement, that would be fine, but that is not what it is doing. It doesn't even attempt to justify the requirement, there's no rationale at all, it is simply stated. | The last part of Section 2.5.1 says: | |The details of forming interface identifiers are defined in the |appropriate IPv6 over link specification such as IPv6 over |Ethernet [ETHER], IPv6 over FDDI [FDDI], etc. Yes, but that's how the IID is to be created, not now big it is to be. And in any case, that sentence is fine. | I also remain unconvinced that the wording: | |For all unicast addresses, except those that start with binary value |000, Interface IDs are required to be 64 bits long and to be |constructed in Modified EUI-64 format. | | translates into a requirement that there exist implementations that | disallow IIDs of length other than 64. I can't see how you can avoid are required to be 64 bits long. | Following this logic, I suspect | one could effectively prevent just about any document from being | advanced to Draft. Only ones that shouldn't be advanced. And note, all that is required to allow it to advance, is for the unimplemented feature to be removed. | Documents typically have a number of principles | that are not testable or enforceable, The ones in question here are both testable and enforceable. So, that isn't relevant. But if the WG wanted to rewrite this one as a general guideline or something, it would probably cause less problems. That is get rid of the are required to be language etc. | or where no one would bother to actually enforce something | because the actual cost is too high. This is exactly (one of) the case(s) where 2026 should apply. If a doc is requiring something that cannot be implemented (reasonably) then the requirement should be removed. If that isn't done, then someone who later takes the doc, knows it is a DS (or more), and hence knows that it has been fully implemented, gets the thing, and then says OK, all of this is proved implementable, I have to implement it all, not knowing that everyone who went before knows this is a joke, and that no-one actually bothered implementing some particular part, because it is too hard, or just plain wrong, or just unwanted (not useful) in practice. This is exactly why 2026 requires at least 2 implementations of *everything*. | Consider: | | 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses | [...] | |80 bits | 16 | 32 bits| | +--+--+ | |..||IPv4 address | | +--++-+ | Note: The IPv4 address used in the
Re: Link local address for tunnel interfaces
Mukesh Gupta wrote: Hi, Is it required to have a link local address on a tunnel interface. I am implementing IPv6 in IPv6 tunnels and wanted to know whether I should install a link local address on the tunnel interface. Is there any document that talks about this ? RFC 2373, Section 2.8 requires that a node recognize itself by Its Link-Local Address for each interface. That would include any virtual interfaces created by a tunnel. If it is required, how should I calculate a unique link local address ? Appendix A of 2373 discusses creating EUI-64 identifiers which can be used in the creation of link-local addresses. Regards, Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Link local address for tunnel interfaces
Date:Wed, 02 Oct 2002 09:33:44 -0700 From:Mukesh Gupta [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Is it required to have a link local address on a tunnel interface. I am | implementing IPv6 in IPv6 tunnels and wanted to know whether I should | install a link local address on the tunnel interface. Is there any | document that talks about this ? Yes, the addr arch doc requires LL addresses on every interface (and that includes tunnels). | If it is required, how should I calculate a unique link local address ? However you like I think. But one common method is to use the underlying tunnel address to form the IID. For v6 in v6, you could use the IID of the underlying v6 interface (or any v6 interface). Or the low N bits of that where N is 128 - the prefix length of the tunnel. kre IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt
Robert, Actually no. If you go back and look at the record, I think you'll see that there was much more support for a change than for no change. Just re-read the messages and see. The best the chairs could come up with was no consensus to change the doc. Nb: not consensus against changing the doc. As I recall it, just about the only real opposition (actually stated on the list) to changing this came from you... (I don't know, obviously, but it is possible that the chairs then believed that they couldn't change the doc, because attempting to specify something that an IESG member doesn't like, or not to specify something that they do like, can cause a doc to get held at discuss in the IESG forever...) If you believe there is some sort of process problem here, there are appropriate channels for raising such issues. Wondering whether there may be an issue here while at the same time not actually raising the issue is not helpful, IMO. Incidentally, I sent the first message on this thread to the IESG (only). Since then, it has been between us, with cc's going to both the IESG and the WG. But it has never been made clear whether in this small exchange you've been speaking on behalf of the IESG, or just making your own personal arguments. Which? To be clear, I'm speaking for myself, as one of the INT ADs, and the Area Advisor for this WG in particular. The other ADs, who have been cc'ed on this thread, will form their own opinions I'm sure. I chose to cc my original response to your note back to the ipng mailing list as a small step in having the IESG be more transparent. Thomas IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt
Hi Robert, (I don't know, obviously, but it is possible that the chairs then believed that they couldn't change the doc, because attempting to specify something that an IESG member doesn't like, or not to specify something that they do like, can cause a doc to get held at discuss in the IESG forever...) This is not the case, at all... Even one of the WG chairs, in the message that started this discussion (in its most recent go around anyway) said, on the list, on Aug 4 ... Yes. I expressed a personal technical opinion (which I still hold). But, there was not sufficient support for my opinion on the WG mailing list to constitute a consensus to make a change to the document. I accepted that fact, and the change was not made. Margaret IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
draft-ietf-ipv6-dns-discovery-06.txt
Dear wg chairs, draft-ietf-ipv6-dns-discovery-06.txt has been published on Sept. 20th to answer comments raised on the -05 revision. No other comments have been raised in the mailing list so far. The document authors would like to request a working group last call on this new revision. - Alain, on behalf of the draft-ietf-ipv6-dns-discovery-06 authors. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: AD review of draft-ietf-ipngwg-rfc2292bis-07.txt
Thomas Narten wrote: I'm asking about the second. I wonder, for example, whether someone familiar with the POSIX/Austin Group work has reviewed the document. My concern is that there may be some fairly trivial inconsistencies with this document and the basic API. It would be nice to try and fix those (if they exist). Can anyone speak to this point? So I took a look at 2292bis-07. Please note I am not speaking on behalf of posix/austin group, but rather simply as someone who has been witness to the standardization efforts there. I reviewed primarily for alignment with 2553bis and the latest posix/austin standard. I did not review, for example, correctness of constant values and data structures for match against IPv6 protocol RFCs (hopefully there have already been enough eyes that have done that). Some comments for alignment with the latest POSIX standard: - I suggest you update the Posix references, using the same reference as 2553bis, which I show below (note the spec has now also been approved by ISO): IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX) Open Group Technical Standard: Base Specifications, Issue 6 December 2001 ISO/IEC 9945-1:2002, 9945-2:2002, 9945-3:2002, 9945-4:2002 Information technology -- Portable Operating System Interface (POSIX) -- Parts 1, 2, 3 and 4 http://www.opengroup.org/austin - protocol family constants (PF_xxx) are not defined in this latest POSIX standard, replace all PF_xxx with AF_xxx (e.g. PF_INET - AF_INET) - section 21.1 shows msg_iovlen as type size_t, the latest POSIX defines msg_iovlen as type int Some editorial comments: - section 7.1 in this sentence, CMSG_LEN should be CMSG_SPACE (see the nice diagram on page 67, an ancillary data object includes the padding at the end) When the application uses ancillary data it must pass the returned length to CMSG_LEN() to determine how much memory is needed for the ancillary data object (including the cmsghdr structure). - section 8 typo in first paragraph last sentence Hob-by-Hop - section 10.5 inet6_opt_next, the statement Typep points the option type field does not seem right, for typep to point to the option type field, it would have to be passed as 'uint8_t **typep'; I think you mean it points to a buffer into which the option type is stored, or using wording similar to lenp, typep stores the option type - section 11.1 you should cite one or more references upon which this statement is based: Also, path MTU discovery for multicast has severe scalability limitations and should thus be avoided by default. - the data type usage in the example code could be cleaner, for example in section 22 page 72: int extlen; int cmsglen; extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3); cmsglen = CMSG_SPACE(extlen); inet6_rth_space() returns a size_t into int extlen. int extlen is passed to CMSG_SPACE which expects unsigned int. CMSG_SPACE returns unsigned int into int cmsglen. and so on. A minor technical comment: - There is an inconsistency in the inet6_opt_set_val and inet6_opt_get_val functions. In both functions, the offset argument is type size_t, but the function return value (also an offset) is type int. Given the intended usage of these functions, where the return value of one call can be used as the offset argument on the next call, the data type of the offset argument should be type int. I also want to point out an issue that might be raised if this API is ever brought to the Austin group (IEEE/OpenGroup/ISO) for standardization. The functions and macros listed below use a variety of data types for things that represent a size, including int, unsigned int, and size_t. All these items, or at least those of type size_t, could instead be of type socklen_t. Note that some of the items identified are for use with msg_controllen and cmsg_len, which are type socklen_t. Here is the rationale for socklen_t from the latest POSIX standard: The type socklen_t was invented to cover the range of implementations seen in the field. The intent of socklen_t is to be the type for all lengths that are naturally bounded in size; that is, that they are the length of a buffer which cannot sensibly become of massive size: network addresses, host names, string representations of these, ancillary data, control messages, and socket options are examples. Truly boundless sizes are represented by size_t as in read(), write(), and so on. All socklen_t types were originally (in BSD UNIX) of type int. During the development of IEEE Std 1003.1-2001, it was decided to change all buffer lengths to size_t, which appears at face value to make sense. When dual mode 32/64-bit systems came along, this choice unnecessarily complicated system interfaces because size_t (with long) was a
IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt
I made the mistake of allowing my arm to be twisted into reviewing draft-ietf-ipngwg-addr-arch-v3-10.txt last week, and was sad to find what appears to be an ambiguity in some of text that deals with subnet-scope multicast. Given that this document was already before the IESG at the time I found this, I've been discussing this with our AD, who brought in our WG chairs once he and I agreed that there might be a problem here, but we felt that the discussion of what to do about this really should take place out in the open on the WG mailing list. So, what I said (after some initial clarifying discussion) was: In the absence of a precise definition of the distinction between a link and a subnet, it is unclear what a router should do with a packet addressed to a transient multicast address with subnet-local scope. Excerpting from the draft: 2 link-local scope 3 subnet-local scope 4 admin-local scope ... link-local and site-local multicast scopes span the same topological regions as the corresponding unicast scopes. subnet-local scope is given a different and larger value than link-local to enable possible support for subnets that span multiple links. admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration. So subnet-local is a larger scope than link-local, and may be derived automatically from physical connectivity (in some completely unspecified way!). So what should a router do with that packet? To forward or not to forward, that is the question. One could address this concern by adding text (somewhere) to the effect that, until such time as a standards track document specifies how a router should determine what the subnet-scope boundaries are and what a router should do with an otherwise valid packet addressed to a multicast address with scop set to subnet-local, routers should handle such packets precisely as they would if scop were set to link-local. Or something like that. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: 2292bis ip6_rthdr0 flexible array member
On Thu, 26 Sep 2002 13:03:53 +0900 JINMEI Tatuya / 神明達哉 [EMAIL PROTECTED] wrote: On Wed, 25 Sep 2002 13:52:58 -0700, Michael Hunter [EMAIL PROTECTED] said: [4 people's opinions about ip6r0_addr] (correct me if I'm wrong or miss someone.) That is as I read it. [...] [...] Another thought: most user applications are expected to use inet6_rth_xxx functions, instead of directly getting access to the address part following the rthdr[0] structure. Thus, either 1 nor 2 affects the typical user applications. So why create incompatibilities with 2292 if you expect the feature being broken to be used less in the future? Whats the gain? See Vlad's response. So the gain was: 1) it would make it more consistent with the rest of the API 2) it makes handling a corner case cleaner I personally don't see these as a strong enough reason to break the API. I strongly disgree with Vlan'd comment that Additionally 2292bis has some other incompatibilities with 2292 this one being the least of the problems. So that argument doesn't fly. Thats a slippery slope leading you to completely abandoning backwards compatability. You should have strong technical reasons for each and every breakage of the API independent of what else you have broken. [...] Additionally, I suspect the removal actually breaks user code so much. As I said before, user applications are usually expected to use library functions for source routing and to not use the ip6r0_addr member directly. In fact, we, the KAME project, do not use the member name in about 80 IPv6 applications we provide. I also searched on I think this is overstating your case. This is the advanced API. You don't expect it to be used in many of you applications. The real point is that you don't use it in the less then 5 (ping, telnet, traceroute, 'sniffer') applictions that might need it. recent source code of FreeBSD and NetBSD (which have not supported 2292bis yet). The only occurrence of ip6r0_addr other than in user applications is in tcpdump, where no compatibility issue exists since tcpdump uses its own header definitions. Which is telling about the stability and widespread acceptance of this API. I think its very likely that one of the reasons they needed private headers had to do with the variations of API between 2292 and 2292bis. [...] I understand your frustration, but I'm afraid no one can win in this kind of discussion. We just need a compromise, and I hope you kindly allow us to go with the current definition. [...] I agree on this point. I'm tired. I'm done. This just isn't THAT important. Note my frustration and go on. mph IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt
Rob, The subnet-scope is delineated in the same manner as the scopes 6,7,8,9... That is, a router maintains a scope zone id per interface. So, if I have a router that has interfaces 1,2,3, 4 and the admin assigns a subnet-local scope zone id of 100 to interfaces 2 and 4, then 2 and 4 are in the same subnet scope zone and multicast packets received on one of those interfaces can only be sent to the other interface with the same scope zone id. This is discussed in the Scoped Addressing Architecture in the routing section. Brian Rob Austein wrote: I made the mistake of allowing my arm to be twisted into reviewing draft-ietf-ipngwg-addr-arch-v3-10.txt last week, and was sad to find what appears to be an ambiguity in some of text that deals with subnet-scope multicast. Given that this document was already before the IESG at the time I found this, I've been discussing this with our AD, who brought in our WG chairs once he and I agreed that there might be a problem here, but we felt that the discussion of what to do about this really should take place out in the open on the WG mailing list. So, what I said (after some initial clarifying discussion) was: In the absence of a precise definition of the distinction between a link and a subnet, it is unclear what a router should do with a packet addressed to a transient multicast address with subnet-local scope. Excerpting from the draft: 2 link-local scope 3 subnet-local scope 4 admin-local scope ... link-local and site-local multicast scopes span the same topological regions as the corresponding unicast scopes. subnet-local scope is given a different and larger value than link-local to enable possible support for subnets that span multiple links. admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration. So subnet-local is a larger scope than link-local, and may be derived automatically from physical connectivity (in some completely unspecified way!). So what should a router do with that packet? To forward or not to forward, that is the question. One could address this concern by adding text (somewhere) to the effect that, until such time as a standards track document specifies how a router should determine what the subnet-scope boundaries are and what a router should do with an otherwise valid packet addressed to a multicast address with scop set to subnet-local, routers should handle such packets precisely as they would if scop were set to link-local. Or something like that. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt
At 5:01 PM -0400 10/2/02, Rob Austein wrote: I made the mistake of allowing my arm to be twisted into reviewing draft-ietf-ipngwg-addr-arch-v3-10.txt last week, and was sad to find what appears to be an ambiguity in some of text that deals with subnet-scope multicast. Given that this document was already before the IESG at the time I found this, I've been discussing this with our AD, who brought in our WG chairs once he and I agreed that there might be a problem here, but we felt that the discussion of what to do about this really should take place out in the open on the WG mailing list. As part of the AD/chair discussion, I responded to Thomas's report of the issue as follows: To: Thomas Narten [EMAIL PROTECTED] From: Steve Deering [EMAIL PROTECTED] Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt Cc: Bob Hinden [EMAIL PROTECTED], Margaret Wasserman [EMAIL PROTECTED], Rob Austein [EMAIL PROTECTED], Erik Nordmark [EMAIL PROTECTED] At 10:43 AM -0400 10/2/02, Thomas Narten wrote: One last (??) issue on this document has popped up. The issue as I understand it is that with the addition of subnet-local multicast scope, the document leaves out details about how routers are supposed to know what the actual subnet boundaries are. Thomas, Every router (whether IPv4 or IPv6) knows what subnets its own interfaces belong to (or, more accurately, what subnet numbers are assigned to the links to which it has interfaces). That is the most basic configuration info provided to a router -- it is provided with that info in order to do unicast routing and forwarding. To enforce subnet-local scope it is necessary simply to inhibit the forwarding of subnet-local- destined packets between interfaces that do not belong to the same subnet. I would have thought that would be obvious. For those for whom it is not obvious, there is additional detail on the default configuration of scope zone boundaries in the scoped address architecture spec, along with lots of other info required to implement address scoping. More comments in-line below... Rob Austein [EMAIL PROTECTED] writes: ... Excerpting from the draft: 2 link-local scope 3 subnet-local scope 4 admin-local scope ... link-local and site-local multicast scopes span the same topological regions as the corresponding unicast scopes. subnet-local scope is given a different and larger value than link-local to enable possible support for subnets that span multiple links. admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration. Note that the determination of the span of subnet-scope is an example of automatic derivation from...other, non-multicast related configuration, as mentioned in the description of admin-local. Here is a suggestion: 1) change the wording of the subnet-local definition to say something like: subnet-local scope is given a different and larger value than link-local to enable possible support for subnets that span multiple links. By default, routers assume that subnet scope and link-local scope are equivalent. I think that such a change is unwarranted if it will mean even more delay in the approval and publication of the spec. If you can handle it as a Note to the RFC Editor or something like that, then fine. However, I have a few problems with your added sentence above: - it's odd to stick that little implementation note there in the middle of the scope descriptions - it should refer to nodes, not just routers - your statement would not necessarily be true for routers that do support multi-link subnets -- for the them, the default might be *not* to assume that subnet-local and link-local scope are equivalent. Here's an alternative to your sentence which bypasses those problems: In the normal case of a subnet confined to a single link, subnet-scope is equivalent to link-scope. 2) to the admin-local scope, tweak the wording to say something like: admin-local and all larger scopes must be administratively configured, i.e., they are not automatically derived from physical connectivity or other, non-multicast-related configuration. Make sense? I don't object to that changed wording, but neither do I see the necessity of it. Steve In a response to that message, Rob asked me if I had forgotten about unnumbered point-to-point links. I answered as follows: Yes, I did forget about them, but I think it's obvious how to handle them: they are not part of a subnet that exists on any other link, so subnet- scope
Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt
At Wed, 02 Oct 2002 17:35:37 -0400, Brian Haberman wrote: The subnet-scope is delineated in the same manner as the scopes 6,7,8,9... That is, a router maintains a scope zone id per interface. So, if I have a router that has interfaces 1,2,3, 4 and the admin assigns a subnet-local scope zone id of 100 to interfaces 2 and 4, then 2 and 4 are in the same subnet scope zone and multicast packets received on one of those interfaces can only be sent to the other interface with the same scope zone id. The key phrase in your explanation is the admin assigns. The addr-arch doc says admin-local scope is the smallest scope that must be administratively configured. So which is it? IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt
At Wed, 2 Oct 2002 15:07:55 -0700, Steve Deering wrote: In a response to that message, Rob asked me if I had forgotten about unnumbered point-to-point links. I answered as follows: Yes, I did forget about them, but I think it's obvious how to handle them: they are not part of a subnet that exists on any other link, so subnet- scope multicasts would not be forwarded to or from an unnumbered link. Assuming that one suspends disbelief about the whole multi-link subnet thing in the first place, it's far from obvious to me that unnumbered links aren't part of a subnet that exists on other links. The most common use I've seen of proxy ARP in IPv4 has been to extrude small numbers of IP addresses across PPP links. My apologies for not answering the rest of Steve's message right now, but my family is about to break down the door to my office because they want to eat dinner now IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 subnet-local addresses anddraft-ietf-ipngwg-addr-arch-v3-10.txt
At 6:11 PM -0400 10/2/02, Rob Austein wrote: At Wed, 2 Oct 2002 15:07:55 -0700, Steve Deering wrote: In a response to that message, Rob asked me if I had forgotten about unnumbered point-to-point links. I answered as follows: Yes, I did forget about them, but I think it's obvious how to handle them: they are not part of a subnet that exists on any other link, so subnet- scope multicasts would not be forwarded to or from an unnumbered link. Assuming that one suspends disbelief about the whole multi-link subnet thing in the first place, it's far from obvious to me that unnumbered links aren't part of a subnet that exists on other links. So which is it? Either we're talking about the case where multilink subnets are not employed (no need to believe in them), in which case my statement holds. Or we are venturing into the oh-so-scary land of multilink subnets, in which case the routers know (are required to know, in order to make unicast routing work) that they are extending the span of a subnet across more than one link, possibly including point-to-point links, so know which links are part of the same subnet, and can therefore do subnet-scope boundary enforcement as necessary. What am I missing here? The most common use I've seen of proxy ARP in IPv4 has been to extrude small numbers of IP addresses across PPP links. Yes, proxy ARP is an (undocumented) special case of multilink subnetting. Steve IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt
At 6:07 PM -0400 10/2/02, Rob Austein wrote: The key phrase in your explanation is the admin assigns. The addr-arch doc says admin-local scope is the smallest scope that must be administratively configured. So which is it? You omitted the full description: admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration. Subnet-local scope is an example of automatic derivation from other, non-multicast-related configuration. Specifically, you don't directly configure a router to know which subnet-scope boundaries pass through it (as you must do with larger scopes). Rather, you (typically, manually) configure the router with subnet info -- including, perhaps, enabling or disabling multilink-subnet behavior -- as required for unicast routing, and then you automatically derive subnet-scope boundary information from that other, non-multicast-related configuration. Or saying it more concisely: you don't administratively configure subnet scope; you adminstratively configure subnet info for unicast purposes, and then automatically derive subnet scope from that. Steve IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt
At Wed, 2 Oct 2002 16:08:34 -0700, Steve Deering wrote: At 6:07 PM -0400 10/2/02, Rob Austein wrote: The key phrase in your explanation is the admin assigns. The addr-arch doc says admin-local scope is the smallest scope that must be administratively configured. So which is it? You omitted the full description: admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration. Subnet-local scope is an example of automatic derivation from other, non-multicast-related configuration. ^ administrative Specifically, you don't directly configure a router to know which subnet-scope boundaries pass through it (as you must do with larger scopes). Rather, you (typically, manually) configure the router with subnet info -- including, perhaps, enabling or disabling multilink-subnet behavior -- as required for unicast routing, and then you automatically derive subnet-scope boundary information from that other, non-multicast-related configuration. Or saying it more concisely: you don't administratively configure subnet scope; you adminstratively configure subnet info for unicast purposes, and then automatically derive subnet scope from that. Fine, you don't do multicast configuration, you do non-muliticast configuration and automatically derive the multicast configuration of it from the non-multicast configuration. The point, however, if you go back to my original message, is that the text in the draft can also be read as saying that the router is somehow supposed to deduce this bit of configuration from its physical connectivity without any administrative configuration at all, which is sufficiently nebulous that it could logic like oh, I have an ethernet interface and a firewire interface, and I just know that multi-link subnets were invented to make my firewire interface happy, so set the same scope ID on both of these interfaces and forward packets between them. Which (again suspending disbelief) would arguably be ok if there were a specification for multi-link behavior that said to do that, but there isn't, so the draft leaves some ambiguity about whether certain packets should be forwarded or not. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt
Rob Austein wrote: At Wed, 02 Oct 2002 17:35:37 -0400, Brian Haberman wrote: The subnet-scope is delineated in the same manner as the scopes 6,7,8,9... That is, a router maintains a scope zone id per interface. So, if I have a router that has interfaces 1,2,3, 4 and the admin assigns a subnet-local scope zone id of 100 to interfaces 2 and 4, then 2 and 4 are in the same subnet scope zone and multicast packets received on one of those interfaces can only be sent to the other interface with the same scope zone id. The key phrase in your explanation is the admin assigns. The addr-arch doc says admin-local scope is the smallest scope that must be administratively configured. So which is it? Ah, I missed that addition to the text. But, the handling from a forwarding and routing point of view is the same (via the settings of the scope zone id). As for the setting of the scope zone ids. Those can be derived by the prefix configuration on each interface. If the prefixes on interfaces 2 and 4 above are the same, the scope zone id will be the same. And I believe that Steve addressed the issue of unnumbered links in a different message. Regards, Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt
At Wed, 2 Oct 2002 15:07:55 -0700, Steve Deering wrote: Here is a suggestion: 1) change the wording of the subnet-local definition to say something like: subnet-local scope is given a different and larger value than link-local to enable possible support for subnets that span multiple links. By default, routers assume that subnet scope and link-local scope are equivalent. I think that such a change is unwarranted if it will mean even more delay in the approval and publication of the spec. If you can handle it as a Note to the RFC Editor or something like that, then fine. However, I have a few problems with your added sentence above: - it's odd to stick that little implementation note there in the middle of the scope descriptions The current text of that paragraph in the addr-arch document introduces an ambiguity, so it seems like a reasonable place to try to resolve that ambiguity. - it should refer to nodes, not just routers Fair enough. It's the router behavior that I'm worried about, but your proposed change is both harmless and reasonable. - your statement would not necessarily be true for routers that do support multi-link subnets -- for the them, the default might be *not* to assume that subnet-local and link-local scope are equivalent. Since there is as yet no standards track definition of a multi-link subnet, this would amount to adding a normative reference that would block publication of the addr-arch Draft Standard for quite a while. I assume that nobody wants such a thing to happen (I certainly don't). Here's an alternative to your sentence which bypasses those problems: In the normal case of a subnet confined to a single link, subnet-scope is equivalent to link-scope. Same problem: in what case is a subnet not confined to a single link, and how do you describe that case without adding a normative reference? 2) to the admin-local scope, tweak the wording to say something like: admin-local and all larger scopes must be administratively configured, i.e., they are not automatically derived from physical connectivity or other, non-multicast-related configuration. I don't object to that changed wording, but neither do I see the necessity of it. I think the intention here was to remove the (presumably accidental) implication that configuration for anything smaller than admin-local -could- be derived automatically from physical connectivity. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt
At Wed, 2 Oct 2002 15:55:51 -0700, Steve Deering wrote: Either we're talking about the case where multilink subnets are not employed (no need to believe in them), in which case my statement holds. Right. Or we are venturing into the oh-so-scary land of multilink subnets, in which case the routers know (are required to know, in order to make unicast routing work) that they are extending the span of a subnet across more than one link, possibly including point-to-point links, so know which links are part of the same subnet, and can therefore do subnet-scope boundary enforcement as necessary. What am I missing here? A standards track specification for the latter case. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
