Skip to main content

Application Aspects of IPv6 Transition
draft-ietf-v6ops-application-transition-03

Revision differences

Document history

Date Rev. By Action
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Scott Hollenbeck
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Steven Bellovin
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2004-08-30
03 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-08-27
03 Amy Vezza IESG state changed to Approved-announcement sent
2004-08-27
03 Amy Vezza IESG has approved the document
2004-08-27
03 Amy Vezza Closed "Approve" ballot
2004-08-26
03 David Kessens State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by David Kessens
2004-07-02
03 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2004-07-01
03 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Discuss by Scott Hollenbeck
2004-07-01
03 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin
2004-06-24
03 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-06-24
03 (System) New version available: draft-ietf-v6ops-application-transition-03.txt
2004-06-11
03 (System) Removed from agenda for telechat - 2004-06-10
2004-06-10
03 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2004-06-10
03 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2004-06-10
03 Scott Hollenbeck
[Ballot discuss]
Section 5.1 seems to be in conflict with sections 2.2 and 2.3 of RFC 3513.  A reference to 3513 should be included, …
[Ballot discuss]
Section 5.1 seems to be in conflict with sections 2.2 and 2.3 of RFC 3513.  A reference to 3513 should be included, and if there's something wrong about the formats described there should be text added to explain why those formats won't work.
2004-06-10
03 Scott Hollenbeck
[Ballot discuss]
Section 5.1 seems to be in conflict with sections 2.2 and 2.3 of RFC 3513.  A reference to 3513 should be included, …
[Ballot discuss]
Section 5.1 seems to be in conflict with sections 2.2 and 2.3 of RFC 3513.  A reference to 3513 should be included, and if there's something wrong about the formats described there there should be text added to explain why those formats won't work.
2004-06-10
03 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to Discuss from Undefined by Scott Hollenbeck
2004-06-10
03 Scott Hollenbeck
[Ballot comment]
I don't really buy the assertion that applications are either "IPv4 applications" or "IPv6 applications".  A well designed application will rely on things …
[Ballot comment]
I don't really buy the assertion that applications are either "IPv4 applications" or "IPv6 applications".  A well designed application will rely on things like APIs to lower software layers (as described in section 6) to avoid such low-level dependencies.  I can, however, see user interface issues when there's a need to enter and display IP addresses, for example, but this document doesn't describe UI issues at all.

DNS applications, such as resolvers, are of course another matter.  The document does a good job of explaining the transition issues facing client-side DNS implementations, but the title seems to imply that the scope extends beyond DNS clients.  A title change may make the scope more clear.
2004-06-10
03 Scott Hollenbeck [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-06-10
03 David Kessens [Ballot Position Update] New position, Yes, has been recorded for David Kessens by David Kessens
2004-06-10
03 Bill Fenner [Ballot comment]
No further objection - Steve and Ted cover my concerns.
2004-06-10
03 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2004-06-09
03 Steven Bellovin
[Ballot discuss]
3.2 advocates service names in the DNS.  Is this our official position, as opposed to SRV records?  I thought we wanted to discourage …
[Ballot discuss]
3.2 advocates service names in the DNS.  Is this our official position, as opposed to SRV records?  I thought we wanted to discourage such things.  If SRV records are meant, this should be clarified.

3.3: Does the word "users" mean "people who want to run applications on the local machine", or does it mean "remote clients who want to do something on some machine"?  I confess I'm not sure I believe in the wrappers -- in fact, I'm quite certain I don't believe in them.  Anything that does a getpeername() (or equivalent) can't work properly via a wrapper, because the function will return 127.0.0.1.  Anything that does less will just work, via inetd (or equivalent), and needs no wrapper.  Anything that does complex things with IP addresses, such as FTP, will require a very complex wrapper.  This last point is noted, though without supporting detail.  In short, I'm not convinced that it's feasible to provide the "reasonable logic".  (I note that the problem is even worse on the client side.  That should be discussed in the draft, too.)

The last sentence of the third paragraph of 4.1 is ambiguous and should be reworded -- it sounds like the source code availability prevents misuse, which is clearly not what's intended.

5.4.2 appears to be suggesting application awareness of the results of PMTU discovery.  That's a gross layering violation and can't be our advice.

6.1 does not lead to simpler code -- the application will simply check sock.sa_family instead of the socktype parameter.  Worse yet, it leads to questions about incompatibility between the length passed in the second version versus the length implied by sa_family.

The text alludes to security problems from IPv4-mapped addresses.  Section 8 should explain exactly what the problem is.  The current text just speaks of "difficulty" and "legitimate use" without explaining the threat or the threat environment.
2004-06-09
03 Steven Bellovin [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin
2004-06-09
03 Ted Hardie
[Ballot comment]
Bump in the Stack and bump in the api should be spelled out at first
use.

I think it would be useful to …
[Ballot comment]
Bump in the Stack and bump in the api should be spelled out at first
use.

I think it would be useful to include the DNS resolver explicitly in the diagrams in
Section 2.  Its behavior is important enough to the set that inclusion would be useful
If the authors disagree, however, I will not press the point.

I also believe that this text:


    It is bad practise to add an AAAA record for a node that does not
    support all the services using IPv6 (rather, an AAAA record for the
    specific service name and address should be used). However, the
    application cannot depend on "good practise", and this must be
    handled.

is somewhat confusing.  It might be useful to rephrase this as "system
administrators should associate v6-specific names with v6 interfaces when
nodes having both v4 and v6 interfaces offer some services only over
v6 or v4".
2004-06-09
03 Ted Hardie
[Ballot discuss]
The document gives this advice for v6 literals:

      Prefix/len format should be also considered if surrounding brackets
    are …
[Ballot discuss]
The document gives this advice for v6 literals:

      Prefix/len format should be also considered if surrounding brackets
    are used.  In order to avoid ambiguity, the format, like
    [2001:db8::]/64 is recommended.

As the document notes above, there are some contexts
like URIs where there is an established way to handle
IPv6 literals, and this format actually would introduce
confusion into those.
http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]/128  is a perfectly
legal URI, but the /128 is the resource at that host, not a prefix/len marker.

I believe that this recommendation should be modified to note that the
prefix/len mechanism should be used only when there are sufficient cues available
to ensure that it does not get carried over into a URI (or similar context) without transformation.
2004-06-09
03 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to Discuss from Yes by Ted Hardie
2004-06-09
03 Ted Hardie [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie
2004-06-09
03 Ted Hardie Ballot has been issued by Ted Hardie
2004-06-09
03 Ted Hardie Created "Approve" ballot
2004-06-03
03 David Kessens State Changes to IESG Evaluation from Waiting for Writeup by David Kessens
2004-06-03
03 David Kessens Placed on agenda for telechat - 2004-06-10 by David Kessens
2004-05-24
03 (System) State has been changed to Waiting for Writeup from In Last Call by system
2004-05-13
03 Michelle Cotton IANA Last Call Comments:
We understand this document to have NO IANA Actions.
2004-05-10
03 Amy Vezza Last call sent
2004-05-10
03 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2004-05-01
03 Margaret Cullen [Note]: 'Participant in PROTO Team pilot:
Working Group Chair Followup of DISCUSS Comments
http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-pilot-01.txt' added by Margaret Wasserman
2004-04-20
03 David Kessens Last Call was requested by David Kessens
2004-04-20
03 David Kessens State Changes to Last Call Requested from Publication Requested by David Kessens
2004-04-20
03 (System) Ballot writeup text was added
2004-04-20
03 (System) Last call text was added
2004-04-20
03 (System) Ballot approval text was added
2004-04-01
03 Dinara Suleymanova Draft Added by Dinara Suleymanova
2004-03-31
02 (System) New version available: draft-ietf-v6ops-application-transition-02.txt
2004-02-13
01 (System) New version available: draft-ietf-v6ops-application-transition-01.txt
2003-12-10
00 (System) New version available: draft-ietf-v6ops-application-transition-00.txt