[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-v6ops-application-transition-01.txt(fwd)
Thanks, Pekka.
I agree on all of your edits and suggestions.
At this time, I'm preparing the revision (-02) of this draft.
After publication (-02), I think this document
will be ready to go to the IESG.
Thanks,
Myung-Ki.
Pekka Savola wrote:
> Hi,
>
> Below are my presonal comments/final edits to the the WG last call of
> the application transition document.
>
> semi-editorial/substantial
> --------------------------
>
> necessary. However, these wrapper applications will actually
> probably have to do more than just perform a DNS lookup or figure
> out the literal IP address given. Thus, they may get complex, and
>
> ==> remove "probably" because this is a fact. :)
>
> There is an another consideration on IPv6 address literals in SMTP
> commands [RFC 2821], i.e., [IPv6: 2001:db8::1].
>
> ==> reword to better flesh this out, e.g.:
>
> One should note that some applications may also represent IPv6 address
> literals differently; for example, SMTP [RFC 2821] uses
> [IPv6:2001:db8::1].
>
> ...
>
> When selecting the destination address, applications usually ask a
> resolver for the destination IP address. The resolver returns a set
> of valid IP addresses from a hostname. Unless applications have a
> specific reason to select any particular destination address, they
> should just try each element in the list until the communication
> succeeds.
>
> ==> it seems that 5.4.1 does not mention the case of app selecting source
> address at all. Add a new paragraph like:
>
> In some cases, the application may need to specify its source
> address. Then the destination address selection process picks the best
> destination for the source address (instead of picking the best source
> address for the chosen destination address). Note that there may
> be an increase in complexity for IP-version independent applications
> which have to specify the source address (especially for client
> applications; fortunately, specifying the source address is not
> typically required), if it is not yet known which protocol will be used
> for communication.
>
> ...
>
> FIXME: Application framing has relations e.g. with Path MTU
> Discovery and application design which need to be analyzed better.
>
> ==> apparently in application layer framing, some considerations are still
> TBD. Flesh these out a bit, by replacing the paragraph with like:
>
> Note that the most optimal ALF depends on dynamic factors such
> as Path MTU or whether IPv4 or IPv6 is being used (due to different
> header sizes, possible IPv6-in-IPv4 tunneling overhead, etc.).
> These have to be taken into consideration when implementing
> application framing.
>
> ...
>
> When possible, applications should store names, such as FQDNs,
> instead of storing addresses.
>
> ==> make this more generic, e.g. by rewording to:
>
> When possible, applications should store names such as FQDNs,
> or other protocol-independent identities instead of storing
> addresses.
>
> ...
>
> Another problem is/has been that IPv6 multicast does not yet have a
> standardized mechanism for traditional Any Source Multicast for
> Interdomain multicast.
>
> ==> this is no longer quite true (and wouldn't be a good way to state
> this in an RFC in any case), so reword slightly:
>
> Another problem has been that IPv6 multicast in Interdomain using
> the traditional Any Source Multicast has not been possible.
>
> ...
>
> IPv4 and IPv6, but it is likely that PIM-SSM will become more
> widely deployed in IPv6 due to its simpler architecture.
>
> ==> s/likely/possible/ -- it's difficult to predict the future! :)
>
> Both are from the basic socket extensions for IPv6. Since these
> functions are not protocol independent, we should write code for
> the different address families.
>
> A more detailed examples are described in appendix A.
>
> Note that inet_ntop()/inet_pton() lose the scope identifier (if
> used e.g. with link-local addresses) in the conversions, contrary
> to the getaddrinfo()/getnameinfo() functions.
>
> ==> As we want to achieve protocol-independence it's IMHO bad practice to
> not be clear what's the recommendation. I would:
>
> 1) describe the first paragraph above better, and possibly also
> 2) move the examples using getaddrinfo/getnameinfo from appendix A here.
>
> Below is my suggestion for the text if we're doing that:
> ======
> 6.2.3 Binary/presentation format conversion
>
> In addition, we should consider the binary and presentation address
> format conversion APIs. The following functions convert network
> address structure in its presentation address format and vice
> versa:
>
> inet_ntop()
> inet_pton()
>
> Both are from the basic socket extensions for IPv6. However, these
> conversion functions are protocol-dependent; instead it is better to
> use getnameinfo()/getaddrinfo() as follows (inet_pton and inet_ntop
> equivalents are described in Appendix A).
>
> Conversion from network address structure to presentation format
> can be written:
>
> struct sockaddr_storage ss;
> char addrStr[INET6_ADDRSTRLEN];
> char servStr[NI_MAXSERV];
> int error;
>
> /* fill ss structure */
>
> error = getnameinfo((struct sockaddr *)&ss, sizeof(ss),
> addrStr, sizeof(addrStr),
> servStr, sizeof(servStr),
> NI_NUMERICHOST);
>
> Conversions from presentation format to network address structure
> can be written as follows:
>
> struct addrinfo hints, *res;
> char addrStr[INET6_ADDRSTRLEN];
> int error;
>
> /* fill addrStr buffer */
>
> memset(&hints, 0, sizeof(hints));
> hints.ai_family = AF_UNSPEC;
>
> error = getaddrinfo(addrStr, NULL, &hints, &res);
> if (error != 0) {
> /* handle getaddrinfo error */
> }
>
> /* res->ai_addr contains the network address structure */
> /* ... */
> freeaddrinfo(res);
> --- -- -- - -- -
>
> Appendix A. Other Binary/Presentation Format Conversions
>
> Section 6.2.3 described the preferred way of performing
> binary/presentation format conversions; these can also be
> done using inet_pton() and inet_ntop() by writing
> protocol-dependent code. This is not recommended, but provided
> here for reference and comparison.
>
> Note that inet_ntop()/inet_pton() lose the scope identifier (if
> used e.g. with link-local addresses) in the conversions, contrary
> to the getaddrinfo()/getnameinfo() functions.
>
> A.1 Binary to Presentation Using inet_ntop()
>
> [[ text from A.1 up until "buffer length." ]]
>
> A.2 Presentation to Binary Using inet_pton()
>
> [[ similar ]]
> ======
>
> Note: in the following examples, the socket() return value error
> handling could be simplied by substituting special checking of
> specific error numbers by always continuing on with the socket
> loop. Whether this is a better idea should be considered in more
> detail.
>
> ==> remote the "Whether" -sentence.
>
> 8. Security considerations
>
> A number of transition mechananisms define ways of constructing
> IPv6 adddresses using IPv4 addresses. There are a number of kinds
> of IPv4 addresses that require careful treatment due to know
> security issues [TRANSEC].
>
> ==> this paragraph seems irrelevant to the application transition, so
> remove (also the reference). Instead, add something like:
>
> There are a number of security considerations with IPv6 transition
> but those are outside the scope of this memo.
>
> To ensure the availability and robustness of the service even when
> transitioning to IPv6, this memo described a number of ways to
> make applications more resistant to failures by cycling through
> addresses until a working one is found. Doing this properly is
> critical to avoid unavailability and loss of service.
>
> ...
>
> One particular point about application transition is how IPv4-
> mapped IPv6-addresses are handled. The use in the API can be seen
> as both a merit (easier application transition) and as a burden
> (difficulty in ensuring whether the use was legimate) [V6MAPPED].
> This may have to be considered in more detail.
>
> ==> s/may have to/should/
> ==> s/detail/detail when designing applications/
>
> 9. Acknowledgements
>
> ==> I think it would be appropriate to acknowledge or refer to other work
> which has been made before or after starting this process; for example,
> [IP-GGF] and [AF-APP] are listed in references, but not referred in the
> body. Those could be good candidates for mentioning here.
>
> editorial
> ---------
>
> Case 1 : IPv4-only applications in a dual-stack node.
> IPv6 protocol is introduced in a node, but
> applications are not yet ported to IPv6.
>
> ==> s/to IPv6/to support IPv6/
>
> 3. Problems with IPv6 application transition
>
> ==> in all of the section headings, use uppercasing except for certain small
> words; like: Problems with IPv6 Application Transition
>
> if a server application does not support IPv6 yet, but runs on a
> dual-stack machine for other IPv6 services, and this is listed with
> an AAAA record in the DNS, the client application will fail to
>
> ==> s/an AAAA/a AAAA/ (three different places)
> ==> s/this is/this host is/
>
> In consequence, the application should request all IP addresses
> without address family constraints and try all the records returned
> from the DNS, in some order, until a working address is found. In
> particular, the application has to be able to handle all IP
> versions returned from the DNS.
>
> ==> here, one should add a reference to [DNSOPV6] which was already added to
> the references; either immediately after this paragraph, or with a statement
> like "This issue is discussed in more detail in [DNSOPV6]."
>
> When [BIA] or [BIS] is used, the problem described in section 3.2
> becomes an issue --the IPv4 client in a [BIS]/[BIA] node trying to
> connect to an IPv4 server in a dual stack system-- arises.
>
> ==> remove "becomes an issue" or move it to replaces "arises" at the end.
>
> [BIS] or [BIA] does not work with all kinds of applications. In
>
> ==> s/does/do/ ?
>
> As we have seen in the previous section, applications should be
> ported to IPv6. The easiest way to port an IPv4 application is to
> substitute the old IPv4 API references with the new IPv6 one-to-one
> API mapping.
>
> ==> s/one-to-one API mapping/APIs with one-to-one mapping/
>
> telnet6). This case is undesirable since maintaining two versions
> of the same source code per application, could be a difficult task.
> In addition, this approach would cause problems for the users when
>
> ==> remove "," before "could"
>
> Most implementations of dual stack allow IPv6-only applications to
> interoperate with both IPv4 and IPv6 nodes. IPv4 packets going to
> IPv6 applications on a dual-stack node, reach their destination
> because their addresses are mapped to IPv6 ones using IPv4-mapped
> IPv6 addresses: the IPv6 address ::FFFF:x.y.z.w represents the IPv4
> address x.y.z.w.
>
> ==> remove "," before "reach"
>
> This
> option could be useful if applications use new IPv6 features, such
> as flowlabel.
>
> ==> s/flowlabel/Flow Label/
>
> The first method is not recommended because of a significant amount
> of problems associated with selecting the right applications.This
> scenario is described in sections 3.2 and 3.3.
>
> ==> s/This scenario is/ These problems are/
>
> regarding IPv4-mapped IPv6 addresses on the wire are legitimate but
> disabling it internally breaks one transition mechanism for server
> apps which were originally written to bind and listen to a single
> socket using a wildcard address. This forces the software developer
>
> ==> s/bind/bind()/
> ==> s/listen/listen()/
> ==> s/apps/applications/
>
> could be removed. Since we have only one version of each
> application, the source code will be typically easy to maintain and
> to modify, and there are no problems managing which application to
> select for which purpose.
>
> ==> s/purpose/communication/
>
> Implementations typically by-default prefer IPv6 if the remote node
> and application support it. However, if IPv6 connections fail,
> dual applications will automatically try IPv4 ones. The resolver
> returns a list of valid addresses for the remote node and
> applications can iterate through all, first trying IPv6 ones, until
> connection succeeds.
>
> ==> s/dual applications/version-independent applications/
> ==> s/, first trying IPv6 ones,/of them/ -- that was already stated.
>
> If the source code is written in a protocol-dependent way, the
> application will suport IPv4 and IPv6 explicitly using 2 separate
>
> ==> s/suport/support/
>
> Note that there are some differences in bind()
> implementation, whether you can first bind to the IPv6 wildcard
> address, and then the IPv4.
>
> ==> reword:
>
> Note that there are some differences in bind()
> implementation, whether you can first bind to the IPv6, and
> then IPv4, wildcard addresses.
>
> ...
>
> - Network information storage: IP address data structures.
> The new structures must contain 128-bit IP addresses. The use of
> generic address structures, which can store any address family,
> is recommended.
> Sometimes special addresses are hard-coded in the application
> source; developers should pay attention to them in order to use
> the new address format. Some of these special IP addresses are:
> wildcard local, loopback and broadcast. IPv6 does not have
> the broadcast addresses, so applications can use multicast
> instead.
>
> ==> add new paragraph before "Sometimes" ?
>
> ==> s/source/source code/.
>
> - Network configuration options.
> They are used when configuring different communication models
> for Input/Output (I/O) operations (blocking/nonblocking, I/O
> multiplexing, etc) and should be translated to the IPv6 ones.
>
> ==> s/etc/etc./
>
> Applications can use 1280 octets as a data length. [RFC 2460]
> specifies an IPv6 requirement that every link in the Internet have
> a Maximum Transmission Unit (MTU) of 1280 octets or greater.
>
> ==> reword to be more fluent:
>
> Applications can use 1280 octets as a data length: every IPv6
> link must have a Maximum Transmission Unit (MTU) of 1280 octets
> or greater [RFC 2460].
>
> ...
>
> - The same node can reach a destination host using different
> IP addresses.
>
> ==> expand this a bit by rewording:
>
> - The same node can reach a destination host using different
> IP addresses, possibly with a different protocol version.
>
> ...
>
> to peer systems with their own rendez-vous and discovery
>
> ==> remove "-".
>
> These can perform hostname/address and service name/port lookups,
> though the features can be turned off if desirable. getaddrinfo()
> can return multiple addresses, as below:
>
> ==> s/get/Get/
>
> As well, it is not preferred to hardcode AF-dependent knowledge
> into the program. The construct like below should be avoided:
>
> ==> s/As well, it/It/
>
> * - no server at all, if getaddrinfo supports IPv6, but the
> * system doesn't, and socket(AF_INET6, ...) exists with an
> * error.
>
> ==> s/exists/exits/
>
> * - an IPv4 connection to the IPv4 destination,
> * - an IPv6 connection to an IPv6 destination,
>
> ==> s/the/an/
>
> In a client code, when multiple addresses are returned from
> getaddrinfo(), we should try all of them until connection succeds.
> When a failure occurs with socket(), connect(), bind(), or some
> other function, go on to try the next address.
>
> ==> s/succeds/succeeds/
> ==> s/go on/the code should go on/
>
> [2893BIS] E. Nordmark, "Transition Mechanisms for IPv6 Hosts and
> Routers," <draft-ietf-v6ops-mech-v2-02.txt>, February 2003,
> Work-in-progress.
>
> ==> move this to Informative, because it's not required reading, and could
> cause blockage as well.
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Myung-Ki Shin | mkshin@pec.etri.re.kr
ETRI/PEC | 161 Kajong-Dong, Yusong-Gu,
| Taejon, 305-350, Korea
| Tel:+82-42-860-4847
| Fax:+82-42-861-5404
| http://pec.etri.re.kr/~mkshin/