Re: Comments on draft-ietf-ipngwg-icmp-v3-02.txt
Date:Fri, 26 Jul 2002 14:33:11 -0400 From:Thomas Narten [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | I'd like to see an ICMPv6 error message value assigned for the case | where a node would need to send a packet from a specific address, | but cannot because that address is anycast (since the other end has | no other good way of knowing this is the case). | | Under what conditions would such a message be sent? I'd suggest any time a packet is received at an address which is correct for the node, but inappropriate to use for the particular packet received. That includes TCP SYN sent to an anycast address (and Randy, I don't believe that any redefinition of how anycast addresses are permitted to be used can ever make TCP to an anycast address reliable). But it might also be useful for other similar functions - perhaps use of an address of a scope that the destination node doesn't want to use (like you sent that SMTP request to my link local address, but I really don't want you to do that). The ICMP message should contain a better address to use, which the source could compare with its list of possible addresses for the destination, and use only if that was one of the addresses it was considering using in the first place (that avoids most spoofing attacks I think). | For many uses, | sending to an anycast address should not trigger an ICMP (the higher | layer in some cases *could* deal with an anycast address). Of course, this would be done only if the anycast addr couldn't be handled. | The above isn't immediately obvious to me. TCP *could* also use the | recieved SYN as an indication that it should send a SYN in the reverse | direction using a proper source address. I don't think that would be a very useful technique. All that's going to do is attempt to open a new connection to something that won't be in LISTEN state (it isn't a case of simultaneous open, as the addresses don't match). That will just elicit a RST. | That SYN might even include a | option connecting it to the anycast address to which the first SYN was | directed. (Clearly details would need to be fleshed out to make this | all work.) Something like that could be done, but this is going to take much work on TCP, which isn't even in the pipeline. Even then, it isn't clear that this would always be appropriate, so there still needs to be a way to indicate that the address used (while valid) isn't the correct one to use. (A new ICMP like this could also be used in place of some current uses of port unreachable). | My point here is it's not immediately obvious to me when an | implementation is supposed to send an ICMP message in response to a | packet sent to an anycast address. If an implementation can't work out when to send it, then it won't. I don't see this as a problem. It would be a bigger problem if it wasn't clear what should happen when such a message is received - that might make it useless. But if any nodes can find a way to decide when to send the message, that's enough from that end - and nodes that want to simply prohibit all TCP sent to anycast addresses would be in that set I'd expect. I support Itojun's request. 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]
I-D ACTION:draft-ietf-ipv6-scope-api-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Scoped Address Extensions to the IPv6 Basic Socket API Author(s) : R. Gilligan et al. Filename: draft-ietf-ipv6-scope-api-00.txt Pages : 5 Date: 26-Jul-02 This document specifies a set of extensions to the basic IPv6 sockets API for the support of scoped addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-scope-api-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-ietf-ipv6-scope-api-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-ietf-ipv6-scope-api-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-ietf-ipv6-scope-api-00.txt
I-D ACTION:draft-ietf-ipngwg-rfc2553bis-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens Filename: draft-ietf-ipngwg-rfc2553bis-06.txt Pages : 31 Date: 26-Jul-02 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-06.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-ietf-ipngwg-rfc2553bis-06.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-ietf-ipngwg-rfc2553bis-06.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-ietf-ipngwg-rfc2553bis-06.txt
Re: DAD vs. DIID
Date:Mon, 29 Jul 2002 12:53:16 +0200 From:Nils Agne Nordbotten [EMAIL PROTECTED] Message-ID: 014001c236ee$24fecd30$8cb9d8c1@nansb | While this is simple in traditional LANs I'm worried about the consequences | in networks like Bluetooth scatternets where devices in power saving modes | will have to be waked up. If the hardware is rational (a topic about which I know nothing at all, it might not be, but perhaps if pressed, it will improve) the devices won't need to wake up. Remember ND (including DAD) is not ARP, packets aren't broadcast, they're multicast, and to a multicast address which will normally only have as members of the same multicast group nodes sharing the same IID.If you're one of the believers of no IID sharing then doing DAD instead of DIIDD won't change that, and usually, there will be no other members of the group than the node which is doing DAD. The DAD packets consume an (insignificant) amount of bandwidth, but when all is working properly, go nowhere at all. | I also imagine there easily will be partitions in | such networks, and that DAD therefore will provide little assurance. If partitions are common (aside: why would anyone use a link where the chances of not being able to talk to any other random node on the link, like the router, or fileserver, ... are not negligible??) then sure, DAD won't provide a lot or protection, but DIID would provide even less, as less probes are done. At least with DAD, you have a better chance of some of your addresses being detected as duplicates, which will start waving the red flags. | Instead address uniqueness could be assured from EUIs. If EUIs are being used to form the addresses, then duplicates should be very very rare, and all DAD really achieves in the usual case is a little bandwidth consumption and a small delay. But it does no harm either. 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: WG Last Call for Basic Sockets API: draft-ietf-ipngwg-rfc2553bis-06.txt
Here is summary of major changes from rfc2553bis-05 to rfc2553bis-06: . Add brief description of the evolution of this API and its relation to the Open Group/IEEE/ISO standards. . More alignments with [3]: - [3] does not contain protocol family definitions (PF_xxx). Replaced PF_INET6 with AF_INET6, or removed as appropriate. . Remove references to the DNS A6 resource record type. . Fix argument names in getnameinfo() prototype to match text. . Add description text for the getnameinfo() salen argument. . Remove scoped addressing support, which will be published in a separate document. . Modified change history to reflect changes from RFC 2553 only. In preparation for publication as new RFC, the change history was modified to show changes from RFC 2553, rather than changes from bis-01 to bis-02, bis-02 to bis-03, etc. - Jack 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]
Scoped Address Extensions to the IPv6 Basic Socket API
I was happy to see this draft, as I've been struggling to understand how applications will work in the presence of limited scope addresses. I've got a few questions and comments regarding the draft. Some of these may be more appropriate for the Scoped Address Architecture draft, especially in the areas surrounding DNS behavior (some of which has already been discussed on the mailing list). Note that most of my confusion surrounds hosts connecting to more than one site-local zone. If this support was omitted from this and the Scoped Address Architecture draft, then many of my questions below would disappear. - I don't see versions of inet_ntop() and inet_pton() which support the proposed address format for limited scope addresses. I would have thought both would be needed. Or are these APIs being deprecated in favor of using getaddrinfo() and getnameinfo() to perform this mapping (both for unicast and multicast addresses)? Either way, I think it would be good to address this within this draft. - I would like to see new APIs to map between a zone index and zone name provided, similar to the if_nametoindex() and if_indextoname() calls. At a minimum, these will be needed for the updated resolver APIs, which becomes important given many platforms port their resolver from the BIND distribution. - getaddrinfo() - What value should sin6_scope_id be set to for limited scope addresses, such as a site-local address? Should it be the scope index for the given zone into which the query is sent? If so, does a resolver need to send the same query into each zone to which it is attached? I find the whole interaction between the resolver, DNS name server, and limited scope addresses is extremely confusing. - If the host name includes a scope ID, should this restrict the zones into which the DNS query is sent? I would assume so, but have questions based on the next bullet. - If the host name includes a scope ID, but the scope ID is not valid at the invoking host, what should be done? Should the query fail? Or should the scope ID be included on the limited scope addresses returned? - If the host name includes a scope ID, but the scope ID is not valid for all the limited scope addresses which need to be returned, what should be done? For instance, if a local hosts file includes both link-local and site-local addresses, but the scope ID is only valid for the site-local addresses, what should occur? Should the call fail, or should only the site-local addresses be returned? - getnameinfo() - If NI_NUMERICSCOPE is not specified and the scope identifier cannot be mapped to a scope zone name, what should this API do? Should the call fail, or should it return the numeric form of the scope identifier? - What should be done if a nonzero scope identifier is included with a global IPv6 address? Should the call fail, or should it return the numeric form of the scope identifier? - If a nonzero scope zone index is included, should it be used to restrict the zone into which the DNS query is sent? For instance, if the address is of site-local scope, should the query only be sent into the zone which is identified by the scope ID? Or should the resolver send the query into (any? all?) zones? - For a limited scope address with a zero scope zone index, into which zones should the resolver send the query? Should it send it into the default zone, any zone, or send the query into zones? Since the host would send a packet using this address/zone index pair into the default zone, it might make sense for the resolver to do the same. - The discussions from the Scoped Address Architecture draft on when to include the scope ID in textual formats should probably be moved into this draft. For instance, the Scoped Address Architecture draft talks about omitting the zone ID for the default zone on textual displays. Roy
Re: DAD vs. DIID - multiple IIDs?
From: Deshpande, Prasad [EMAIL PROTECTED] I have some questions related to multiple IIDs on an interface - When and why would someone configure multiple IIDs on an interface? offhand, perpaps - for a server you might want manually configure nice prefix::1 address in addition to the automaticly generated id (or even many id's you have webserver: id=1, mailserver: id=2, etc.). Now, depening on needs, you can designate any host as server by adding the servers locally-well-known-id to a host (and removing it from another). - privacy draft (3041?) didn't exactly call for generation of id only, but it could be done that way too (just generate random id's to be used). - If multiple IIDs are configured on an interface, does that imply that the interface has multiple link-local addresses, one created from each IID. In my case, yes. 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: DAD vs. DIID - multiple IIDs?
-Original Message- From: Markku Savela [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 6:34 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: DAD vs. DIID - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. - I receive 4th prefix, = I do a DAD for 3 new addresses. Do I do them in parallel or do I have to do them one after another? - I configure a new additional ID = I do a DAD for 4 new addresses. Do I do them in parallel or do I have to do them one after another? Apparently, KAME is not able to configure multiple plain IDs to be combined freely with all announced prefixes? Or can it? I have some questions related to multiple IIDs on an interface - When and why would someone configure multiple IIDs on an interface? - If multiple IIDs are configured on an interface, does that imply that the interface has multiple link-local addresses, one created from each IID. I didn't see any RPC/draft which prevents one from having multiple link-local addresses. On the other hand I couldn't find any statement that says that there must be a link local address for each IID. thanks -prasad 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]
MAGMA WG Last Call for MLDv2: draft-vida-mld-v2-03.txt
All, This is the start of a MAGMA working group last call on the Multicast Listener Discovery - Version 2 specification. http://www.ietf.org/internet-drafts/draft-vida-mld-v2-03.txt The last call period will end on August 13th. Substantive comments should be directed to MAGMA mailing list. Editorial comments should be directed to the authors. Regards, Brian Bill MAGMA co-chairs 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]
per-connection config and destination address selection
draft-ietf-ipv6-default-addr-select-08.txt mentions two per-connection configuration switches for source address selection. One is for home vs care-of addresses, and the other is for temporary vs public addresses. The value of the switches may affect destination address selection, because it depends on the expected source address corresponding to each candidate of destination address. I have a feeling that the current draft is not very clear about the dependency. For example, Section 8 (Implementation Considerations) indicates that the destination address selection algorithm can be implemented inside getaddrinfo(). However, the library function does not always know the value of per-connection switches in advance. An application may even not open a socket for the actual connection when calling getaddrinfo(). This may rather be an implementation issue, so I don't think we need a major revise of the draft just due to this. But I also think it would be good to add some note about the dependency in Section 8 before publishing the draft. JINMEI, Tatuya Communication Platform Lab. Corporate RD Center, Toshiba Corp. [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: Comments on draft-ietf-ipngwg-icmp-v3-02.txt
read draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt for more on this topic. Please elaborate. I don't think the draft discusses this at all. Randy is talking about changing definition of anycast in RFC2460 to definition in draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt section 2.2. is it clear enough? With RFC2460 anycast, you can always assume there is another unicast address of at least same scope assigned on the node. As the node cannot use RFC2460 address as a source address, it will use unicast address. Problem solved(?). i don't quite parse it. itojun 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: DAD vs. DIID
In your previous mail you wrote: i see zero reason for prohibiting the above configuration. = I should say I agree with Itojun... If disabled, perform DAD for every address without any optimizations. = IMHO the worse solution is to get a mix of DAD and DIIDD (as today). DAD had the majority at the meeting and is straightforward to implement so we should fix inconsistencies in current specs (including mobile IPv6 one). Regards [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: DAD vs. DIID
From: [EMAIL PROTECTED] for this reason, i'm not a fan of optimistic DAD. my preference is to run full DAD (will take 1 second or so), for every address assigned to the node. the rule is simple - run it for every address you assign to the node, that's all. Then, I would like to have some consideration on how to behave in the following situation: - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. - I receive 4th prefix, = I do a DAD for 3 new addresses. Do I do them in parallel or do I have to do them one after another? - I configure a new additional ID = I do a DAD for 4 new addresses. Do I do them in parallel or do I have to do them one after another? Apparently, KAME is not able to configure multiple plain IDs to be combined freely with all announced prefixes? Or can 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: DAD vs. DIID
Then, I would like to have some consideration on how to behave in the following situation: - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. - I receive 4th prefix, = I do a DAD for 3 new addresses. Do I do them in parallel or do I have to do them one after another? - I configure a new additional ID = I do a DAD for 4 new addresses. Do I do them in parallel or do I have to do them one after another? you can do them in parallel. itojun 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: DAD vs. DIID
for this reason, i'm not a fan of optimistic DAD. my preference is to run full DAD (will take 1 second or so), for every address assigned to the node. the rule is simple - run it for every address you assign to the node, that's all. While this is simple in traditional LANs I'm worried about the consequences in networks like Bluetooth scatternets where devices in power saving modes will have to be waked up. I also imagine there easily will be partitions in such networks, and that DAD therefore will provide little assurance. Instead address uniqueness could be assured from EUIs. Regards Nils Nordbotten 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: DAD vs. DIID
In your previous mail you wrote: Then, I would like to have some consideration on how to behave in the following situation: - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. = it is uncommon to have 3 ids (usually there are only one or two)... - I receive 4th prefix, = I do a DAD for 3 new addresses. Do I do them in parallel or do I have to do them one after another? = in parallel of course. - I configure a new additional ID = I do a DAD for 4 new addresses. Do I do them in parallel or do I have to do them one after another? = idem. Apparently, KAME is not able to configure multiple plain IDs to be combined freely with all announced prefixes? Or can it? = I believe KAME has a notion of the id of the interface. This should be discussed on the KAME list. [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: Comments on draft-ietf-ipngwg-icmp-v3-02.txt
On Mon, 29 Jul 2002 [EMAIL PROTECTED] wrote: read draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt for more on this topic. Please elaborate. I don't think the draft discusses this at all. Randy is talking about changing definition of anycast in RFC2460 to definition in draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt section 2.2. is it clear enough? No, he isn't. There seem to be some unstated assumptions here. What he is saying is 'if you try to connect anycast address PRFX::/64, the ICMP unreachable (or whatever) message comes back from PRFX::X/64 (unicast address on the node)'. This applies to RFC2460 anycast only, and depending on source address selection, possibly pseudo-anycast. With RFC2460 anycast, you can always assume there is another unicast address of at least same scope assigned on the node. As the node cannot use RFC2460 address as a source address, it will use unicast address. Problem solved(?). i don't quite parse it. See above. There should be no nodes which have only RFC2460 anycast address(es), as they must not use it as a source address. -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords 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: DAD vs. DIID
On Mon, 29 Jul 2002, Robert Elz wrote: | But you agree that the above configuration is very rare, really just a | corner case. Someone _might_ want it though. I don't agree with the first sentence there, I think I'm (a) someone... I'd like to hear what kind of network configuration you have in mind. The problem is that you have to know what is enabled/disabled on every other node on the link as well. So, this would need to be yet another RA parameter (and there'd have to be some rule on what was permitted when there is no router in that case). It really is simpler just to always do DAD. I agree this is a problem :-(. On optimistic DAD - maybe I misunderstood what Erik was suggesting, but I assumed the optimistic wouldn't be irrational .. that is, for optimistic DAD, which I think I'd certainly not object to (though I'm also not sure the actual cost of full DAD is enough for it to matter) I'd assumed the idea would be to send the first DAD NS, and wait for a reply, and if no reply came to that one, assume the address is OK, while simultaneously going on and doing the rest of the DAD procedure (killing the address if it fails). That more or less cuts the DAD delay by 2/3 (but it doesn't eliminate it). My main point is just that one should be able optimize DAD somehow if there are long latencies involved (e.g. serialized full DAD is unacceptable with many addresses). How, that's another issue. Else folks that need to optimize it will do so anyway. -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords 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]
