[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-v6ops-application-transition-01.txt (fwd)
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