Subject: draft-masinter-url-ipv6-01.txt

From: "Larry Masinter" <[email-masked]>
Date: Mon, 14 Sep 1998 13:30:14 PDT

Please comment on this document, "Using IPv6 Addresses in URLs",
which suggests a reserved pseudo top-level domain for hiding
IPv6 raw addresses as if they were DNS entries in order to
shoehorn them into URLs.

Larry
--
http://www.parc.xerox.com/masinter

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 15 Sep 1998 05:23:14 PDT

People use raw IP addresses in cases where DNS isn't available at all.
Some systems allow administrators to access system state and configuration
information using a web interface, and on such occasions, it's useful to
be able to enter http://13.12.17.43/configure or whatever to access it.
The intent for the pseudo-domain ".ipv6" is that implementations that
supported ipv6 'gethostbyname' would actually short-circuit DNS entirely.

It sounds like the document isn't clear about the desired implementation,
since of course it wouldn't involve any name servers at all.

Larry

> -----Original Message-----
> From: Peter Koch [mailto:[email-masked]]
> Sent: Tuesday, September 15, 1998 4:58 AM
> To: Larry Masinter
> Cc: [email-masked]
> Subject: Re: draft-masinter-url-ipv6-01.txt 
> 
> 
> 
> Instead of reserving an additional TLD it's probably easier to
> use a subdomain of "ip6.int", e.g. "u2a.ip6.int", as a suffix.
> If that domain is then served by a set of special purpose nameservers
> (cf. "iddd.tpc.int"), those servers could generate AAAA RRs from the
> input on the fly, so no special treatment of any domain, TLD or other,
> would be needed in the resolvers.
> Maybe this approach has some drawbacks wrt firewall or isolated environments.
> 
> -Peter
>

---

From: Peter Koch <[email-masked]>
Date: Tue, 15 Sep 1998 13:57:37 +0200

-Peter

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 15 Sep 1998 11:23:37 -0500

> Please comment on this document, "Using IPv6 Addresses in URLs",

I'l abstain from the discussion, since I had some participation in
the creation of this admittedly ugly scheme.  But I will provide some
background and clarifying information.

1. It is not proposed to create an actual "ipv6" top level domain.

2. The example in the syntax section has dots in the latter portion
of the address.  There two categories of IPv6 address whose last 32
bits are an IPv4 address, and in such cases the last four bytes may
be written in dotted decimal.

				Matt

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 16 Sep 1998 08:52:36 PDT

> Pseudo domains really are a nuisance, almost any "magic" solution is better
> than something which looks like a domain name, but isn't.
>
> Doing what Peter Koch suggested, and using a real domain, though one in which
> everyone agrees exactly what the mappings should be, so the DNS lookups could
> be short circuited by consenting applications would be much nicer (assuming
> some kind of domain name style string is desireable at all).
>
> The problem is that knowledge of the specialness of the magic name tends to
> spread all over the place.   You see a domain name in a URL, you want to
> contact the site where the page exists, and there's no mail address on the
> web page - so you mail to (try to mail to) [email-masked]
> Then mailers need to understand the magic - just maybe the sender's mailer
> will be able to piggyback off some special magic in the low level name -> addr
> routines (though as mailers do MX lookups rather than A, at least initially,
> there's no guarantee that will actually work), but the receiver's mailer needs
> to understand that this magic domain refers to it, and that one isn't nearly
> so easy.

Is "ip6.int" the right choice? (as in "http://a123-b425-1--f23.2.3.ip6.int")?
What steps are necessary to insure that the 'real domain' becomes real?
Are there any other pseudo-domains with this arrangement?

Larry

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Sep 1998 04:19:00 +1000

Date:        Wed, 16 Sep 1998 08:52:36 PDT
    From:        "Larry Masinter" <[email-masked]>
    Message-ID:  <[email-masked]>

    Is "ip6.int" the right choice?

It would certainly be the initial obvious choice, if this really
is the way to move.

Someone needs to have the thing delegated to servers which are able
to take a lookup request (should it ever be delivered) and conjure
suitable AAAA (or A6 [aside: horroible name, could we not have something
like AD instead]) records and return them.

Not that I am aware of - the IPv4 case is handled by special case code
in every application (aided a little recently by shortcut recognition
in several of the library routines.)

Is there really no way that some special character hack could be used to
flag "IPv6 address follows" just to URL recognisers, followed by something
that looks nothing at all like a domain name (no dots anywhere)?

kre

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 16 Sep 1998 15:21:29 -0400

Jim,

From:  [email-masked] (Jim Gettys)
Date:  Tue, 15 Sep 1998 12:00:33 -0700
Message-Id:  <[email-masked]>
In-Reply-To:  <[email-masked]>

>I repeat:
>
>The ONLY VALID use of IP addresses (either V4 or V6) in URI's is for when 
>the network is broken.  A common network "breakage" is your name servers 
>are mis-configured or not working properly.

By far the most common use I make of numericly expressed IP addresses
is in tracking down spammers.  Frequently they deliberatley use hosts
with no symbolic name but even if they don't, you spend some about of
time extracting the numeric equivalent to feed to the IP registries
lookup mechanisms... [whether the presence of spammers means the
network is broken is left as an exercise for the reader]

>Any solution that would then require a working name server means that
>you could not use any Web tools when the name server is broken.

A solution which happens to use name servers as a supplement so that
old software that does not understand the new syntax will limp better
is not necessarily a solution that will "require" working name
servers.

>This is the circularity we are trying to break, so that you might
>actually be able to use Web based network management tools at times 
>when things, including your name server, may be broken.  More and more
>parts of the network are being configured, debugged and managed via
>Web servers (e.g. Agranat's emweb web server).
>
>To give one concrete example, imagine yourself the manager of a network.  
>You'd like a hyperlink to the web page which allows you to configure 
>(unbreak) your name server. To get to the name server configuration web 
>page, you need to utter the address in the hypertext, rather than the 
>name, since you can't depend on the name service working.

For this purpose you had better use a browser that understands the
syntax and does not try to do a name retrieval.  But I don't see that
as prohibiting having name server(s) so that someone who tries to hit
this link with old software when the name servers are up gets a better
result.

>This is but one of a myriad of possible examples, but is presented
>to demonstrate why solutions that require a working name server to
>function are non-starters.
>
>So you need a syntax that is both fully compatible with URI syntax,
>and distinguishable from other valid URI's, so you know it is an
>address, rather than a name, and can use the address directly without
>a name lookup.  The proposed syntax has both of these properties;
>a hacked resolver or URI access library can "do the right thing" underneath
>the covers of existing software without change.
>				- Jim
>
>--
>Jim Gettys
>Digital Industry Standards and Consortia
>Compaq Computer Corporation
>Visting Scientist, World Wide Web Consortium, M.I.T.
>http://www.w3.org/People/Gettys/
>[email-masked], [email-masked]

Thanks,
Donald

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Sep 1998 15:37:59 -0700 (PDT)

> 1. It is not proposed to create an actual "ipv6" top level domain.

just something that looks, walks, talks, ...  i.e. you are just implementing
it in an unusual way, yes?

randy

---

From: Alan Barrett <[email-masked]>
Date: Tue, 15 Sep 1998 17:13:30 +0000 (GMT)

> IPv6 raw addresses as if they were DNS entries in order to

Why not use something siilar to what RFC822 called a domain literal, and
what draft-ietf-drums-smtpupd-08 calls an address literal? 

	http://[IPv6 ffff::1234:9.8.7.6]/filename.html
	http://user:password@[IPv6 ffff::1234:9.8.7.6]:80/filename.html

Here, the square brackets disambiguate the meaning of the colons.  Add
%hex escapes for the space and colons if necessary.

How important is it to use a format that will not break existing software?
I'd think it might be reasonable to note that the only software that
should ever need to parse an address literal is software that is
directly associated with either a client or a server that wants to use
such address literals.  Then the people who want to use the things will
need to upgrade, but others will be unaffected.

--apb (Alan Barrett)

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 17 Sep 1998 12:58:32 -0700

> %hex escapes for the space and colons if necessary.

yes!

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 15 Sep 1998 14:24:46 -0400

Actually, I think the description in the draft is quite clear and
Peter was suggesting (1) use something under the existing ipv6.int and
(2) have servers there who can provide address records.  (1) is just a
change in suffix but (2) is a real addition.

The problem I see with a special xxx.ipv6.int for some xxx is that it
means a new set of servers with all the operational problems
inherent...  Except for the input pain, seems like maybe it should
just be mandated that the normal ipv6 inverse tree be populated with
AAAA records... Then again, anything that is looking for AAAA should
be clever enough to be able to recognize the syntax and directly
create the IPv6 address in question...

Donald

From:  "Larry Masinter" <[email-masked]>
X-Authentication-Warning:  opsmail.internic.net: majordom set sender to owner-namedro
[email-masked] using -f
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
To:  "Peter Koch" <[email-masked]>
Cc:  <[email-masked]>, "Brian Carpenter" <[email-masked]>,
            "Jim Gettys" <[email-masked]>
Date:  Tue, 15 Sep 1998 05:23:14 PDT
Message-ID:  <[email-masked]>
In-Reply-to:  <[email-masked]>

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 15 Sep 1998 09:36:43 -0700

seems to me that if the ipv6 folks picked a presentation-format syntax
for their addresses which isn't compatible with the web (i.e., reuse of
the colon that URL's use to introduce port numbers) that a pseudodomain
is not the right way to fix it.  either pick a different overall syntax
which doesn't use colons, or pick a mapped syntax like "in a URL, the
ipv6 colon has to be written as a hyphen" (or whatever), or require that
the whole thing be surrounded by some other set of cookies (like in mail,
where dotted quads have to be [bracketed] to be recognized.)

mapping via a trailing token like .ipv6 just pushes the problem toward
our grandchildren -- which is not supposed to be the internet's style any
more.

---

From: [email-masked] (Jim Gettys)
Date: Tue, 15 Sep 1998 12:00:33 -0700

I repeat:

---

From: [email-masked] (Jim Gettys)
Date: Tue, 15 Sep 1998 10:46:44 -0700

> need to upgrade, but others will be unaffected.

The big problem is actually NOT "web software"; not the browsers or servers
per se'.   If this were all that we had to fix, it would be fixable (though
the installed base of software would argue mitigate against such change.)

The hidden problem are the thousands/tens of thousands of scripts that take
URI's in Web forms.  If you go look at Perl, TCL, VB, Python, etc,
about anything you pick for syntax will break large numbers of such scripts.
This is alluded to in the document, and the driving force behind this spec.
   "Even if there were no ambiguity, this syntax is incompatible with a
   many deployed applications that parse (but do not resolve) URLs,
   including many CGI scripts, robots, search engines, and so forth."
   
For example, you may have a web application that periodically monitors
a URI for some change; you'd like to be able to use this application to
tell you when your router is getting ill, (and really want it to work
when the network is broken in some fashion, the only valid reason for
using a IPV6 address in the first place).

The proposed syntax is compatible with existing URI syntax, and
this means that the installed base of software will recognize (and handle)
such URI's correctly; for example, in the mail system I use,
URI's are turned back into hyperlinks when recognised; your two examples
above are NOT recognized by my mailer (or I expect yours, either).
				- Jim

---

From: Robert Elz <[email-masked]>
Date: Wed, 16 Sep 1998 17:46:17 +1000

Date:        Mon, 14 Sep 1998 13:30:14 PDT
    From:        "Larry Masinter" <[email-masked]>
    Message-ID:  <[email-masked]>

Beyond that, whatever the demand for some kind of way of permitting the
use of IP layer level addressing, I really believe that for IPv6 we need to
make that as difficult to do as we possibly can - not as easy.   The sheer
size of the address helps, but I think we need more, make the syntax evil to
use, so that people will only ever use it when it is essential, and not just
because it happens to be convenient right now.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 18 Sep 1998 23:12:38 +1000

Date:        Tue, 15 Sep 1998 12:00:33 -0700
    From:        [email-masked] (Jim Gettys)
    Message-ID:  <[email-masked]>

    So you need a syntax that is both fully compatible with URI syntax,
    and distinguishable from other valid URI's, so you know it is an
    address, rather than a name,

The problem with anything that looks like a domain name (in syntax)
is that you cannot guarantee this last part.   One of the possible
outcomes from the current domain names fight is that all restrictions
on top lvel doamins could vanish - if you're relying upon a "magic" domain
name suffix (kind of thing) there's no way to be 100% certain that
that same suffix won't be used by someone in the future for real domain
names (even just to be malicious) - and right now would not be the time
to be allocating a "reserved" top level domain for something as high
profile as URI's.

Using magic somewhere lower down the tree is more likely to be able to
be kept under control - but nothing can really guarantee that you're
going to be disjoint from the space of valid domain names (even less so
than just using dotted quade for IPv4 is so guaranteed).

I'm also not in the slightest convinced by the "thousands of scripts"
argument - sure I accept that there are lots of URI processing scripts
around now, and that many of them might easily break if some kind of
different syntax is introduced - I'd suspect that many are so fragile
that almost anything will break them, that's the nature of that kind of
script.   What I don't believe is that almost any of those scripts needs
to be able to deal with embedded IPv6 addresses, or that if you could
somehow find a few around the world that might want to be used that way,
that fixing them to deal with any new defined syntax is going to be
such a big problem as to rule out this as a way forward.

kre

---

From: [email-masked]
Date: Sat, 19 Sep 1998 07:20:57 +1000

I agree Robert that we should use something that does not look
	like a hostname.  I like the "[...]" as a *user input* extention
	and that tools that take URLs as user input should take the
	standard address form for which ever addresses space is in use
	betweeen "[]" and appropriately escape it *before* passing it to
	cgi's, writing to disk or putting it on the wire.  i.e. if you edit
	HTML using vi you will need to write the address using escapes,
	but if you use a tool it will do the work for you.

	In other words define the spec to escaped but recommend that
	implementors accept unescaped versions and escape them
	immediately.

	This will reduce the chance to a new form being passed to a old
	cgi script.  As for the browsers I still seem to be updating
	every couple of months.  Something like this should be easy to
	introduce within two release cycles and often by the next.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tom Limoncelli <[email-masked]>
Date: Fri, 18 Sep 1998 18:36:41 -0400

Every sendmail configuration in the planet has special code for .bitnet
because someone decided it was easier to use [email-masked] as a
syntax that means, "Even though BITNET uses no technology even remotely
related to the internet, please route this email to the user USER of the
host HOST on the BITNET network."  Why?  Because it was convenient.

Some sites went as far as to set up fake domains for .BITNET with
wildcard MX's to route things to the nearest BITNET gateway.

Much confusion ensued.  Users wanted to know why they couldn't "telnet
brownvm.bitnet", admins at non-Bitnet sites couldn't figure out why
nslookup didn't work, etc. etc.

I know.  I was there.  Heck, I was at a BITNET-only site for 4 years
with no real internet connectivity.

The notation described in this document (.ipv6) is repeating that
history.  This will be a mistake.  There *will* be user confusion, there
*will* be constant requests for sysadmins to "fix" the problem when
people do nslookup of a.b.c--d.ipv6.net

This problem DOES need a solution.
This is not the right solution.

The right solution will have to:
-- Be recognized by gethostbyname()'s replacement.  People are going to
see this format MORE than they'll see the 1:2:3::4 format.
-- Be simple to type.  http://13.12.17.43/configure is *EXTREMELY*
useful for configuring boxes.  Technicians are going to need something
very easy to type or they will be very unhappy.  (Technicians, in
general, are not good typists)

The right solution does NOT have to be parsed by current web robots,
etc.
-- Every web-related perl script, CGI script, robot, search engine, etc.
wll be modified between now and the day we pull the big switch and turn
on IPv6.

Maybe this is an indicatation that the human-readable format isn't as
optimal as its creators first thought.

--Tom Limoncelli

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 24 Sep 1998 17:46:57 -0400

I also favor using square brackets.  It's always seemed to me to be a
real bug that you not only are not required to use them with a numeric
host in a URL but are prohibited from using them.

Donald

From:  Paul A Vixie <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked], "Brian Carpenter" <[email-masked]>,
            "Jim Gettys" <[email-masked]>
In-reply-to:  Your message of "Tue, 15 Sep 1998 05:23:14 PDT."
	                  <[email-masked]> 
Date:  Tue, 15 Sep 1998 09:36:43 -0700

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Sep 1998 13:00:30 +0100

Of course it's a bug. That's why I'm a reluctant author of the
kludge draft we are discussing. The problem is how to work around
the bug.

    Brian

---

From: [email-masked] (Jim Gettys)
Date: Fri, 25 Sep 1998 13:45:33 -0700

I think Brian's mail sum's up my position exactly.  None of us (the authors) 
like the kludge, it is least sickening kludge we've come up with.  

Larry's and my strong opinion is that lots more breaks in the web if you 
try to introduce such syntax characters than those not familiar with the 
Web think.  We aren't in the situation we're normally in in the IETF where 
we can get just a few key pieces of software to change to "fix" the problem.

As RFC 2396 says:

   Other characters are excluded because gateways and other transport
   agents are known to sometimes modify such characters, or they are
   used as delimiters.

   unwise      = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

   Data corresponding to excluded characters must be escaped in order to
   be properly represented within a URI.

In this case, the gateway is to CGI scripts.  Your suggestion is to
take two delimiters out of this set.  And I can point you to a bunch
of languages that break if supplied "[" | "]", known to be used heavily in CGI
scripts (e.g. TCL, or almost any scripting language you care to name use
brackets for something, or in fact almost any character in the "unwise"
set).  

This problem reflects the large success of the Web; it has had many
more pieces of software and/or CGI scripts written than any other
piece of Internet technology I can think of.  It is this very
large installed base that makes this problem difficult. This is pervasive
in software; for example the mail program I use, which turns URI's detected
back into hyperlinks, does not recognise a URI with brackets in it.

And we all want the IPV6 deployment to be as painless as possible...

I do like the suggestion of being able to have a real domain that will 
resolve the addresses, if it can be arranged; this would allow alot of 
software to just work without hacking resolver libraries.  If a few key 
applications (browsers) can then be modified to be configured to NOT do 
a name translation so the network manager can access what need's fixing, 
then we've solved the problem.
				- Jim

> From: Brian E Carpenter <[email-masked]>
> Date: Fri, 25 Sep 1998 13:00:30 +0100
> To: "Donald E. Eastlake 3rd" <[email-masked]>
> Cc: Paul A Vixie <[email-masked]>, [email-masked],
>         Jim Gettys <[email-masked]>
> -----

---

From: Paul A Vixie <[email-masked]>
Date: Fri, 25 Sep 1998 20:23:28 -0700

as the man who removed _ from the list of valid hostname characters, i am
particularly silenced in my arguments for '[' and ']' by jim's claim
that pre-existing CGI's are expecting these to not be present and that
all hell would break loose if we tried to upgrade the global CGI mesh.

i am however unmoved from my position that a pseudodomain like .IPV6 is
short sighted and that our responsibility to those who will come later
requires that we think of something that will scale.

i can see why a domain-like syntax is good, since it doesn't add any
new escape-worthy characters to the URL syntax.  however, i think that
we should solve the problem in the getaddrinfo() spec rather than here;
that is, whatever pseudo-domain syntax we require be available in URL's
for use in representing IP-layer addresses be allowed *anywhere* an
IPv6 "host name" can appear in the IPv6 presentation-layer model.

.IPV6 may be the right answer.  i think something under .LOCAL would be
better but after all the IHAC nonsense in recent years i no longer enjoy
arguing about names.  someone else should choose the pseudodomain name
and its syntax.  but please make it an IPng thing rather than a WWW thing.

---

From: Randy Bush <[email-masked]>
Date: Sun, 27 Sep 1998 11:59:38 -0700 (PDT)

although i agree with your position on the issue, i am forced to note

> as the man who removed _ from the list of valid hostname characters

nope.  as we have yet to be able to define what a 'hostname' is, you are
actually the man who broke his own software and, thank you, left an option
to allow it to be configured as rfc-compliant.

randy

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 27 Sep 1998 12:46:17 -0700

> to allow it to be configured as rfc-compliant.

Three things.

1. HOSTS.TXT defined what a hostname was.  DNS inherits that definition.
   Arguments to the effect that DNS is just a directory will be met by
   quotes from RFC 103x concerning the nature and purpose of "additional
   data."

2. I had strong backing from CERT and bind-workers for making the change
   I made -- I wasn't acting alone, and it's not "my" software anyway, and
   it's in any case not broken, no matter which way the options are set.

3. The effect of making that change in BIND at the time I made it was to
   make _ unusable, no matter who sets what option.  _ is dead.  If you
   want to start on clarifications++ to bring it back, then let's.  I
   actually liked, and now miss, _.

---

From: Randy Bush <[email-masked]>
Date: Sun, 27 Sep 1998 16:31:35 -0700 (PDT)

> 1. HOSTS.TXT defined what a hostname was.  DNS inherits that definition.

completely agree.  bind should adhere to that in its HOSTS.TXT file.

> 2. I had strong backing from CERT and bind-workers for making the change

nice, but we do the specs at ietf.

>    make _ unusable, no matter who sets what option.

please fix the broken software.

> If you want to start on clarifications++ to bring it back, then let's.  I

no need.  2181 makes it all quite clear.

randy

---

From: [email-masked]
Date: Mon, 28 Sep 1998 08:39:33 -0700 (PDT)

> nice, but we do the specs at ietf.

	This was discussed at length in a preceeding IETF, Toronto
	comes to mind, and Paul was unwilling to make the change until
	after further consultation w/ CERT folks.
>>    make _ unusable, no matter who sets what option.

	And there was a large outreach mailing done to inform folks
	about the changes and its effect.
	
--bill

---

From: Tom Limoncelli <[email-masked]>
Date: Mon, 28 Sep 1998 21:19:23 -0400

Paul's message triggered a round of off topic discussions.  I suggest we
focus on this paragraph, which I think cuts to the core of the issue:

> IPv6 "host name" can appear in the IPv6 presentation-layer model.

Procedural question:  How can we move this to be part of the IPv6 stuff?

--tal

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Sep 1998 04:44:37 -0700 (PDT)

> Procedural question:  How can we move this to be part of the IPv6 stuff?

let me try to summarize

  o the idea of a hack to look like a dns name but not act like one has no
    consensus.  in fact the general consensus is against it.

  o there is a consensus that, if it looks like a duck, it should also
    quack, walk, ...  i.e. paul's argument above.

if so, i think we just toss it back at the author and the ADs with comments
similar to the above.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Sep 1998 13:48:29 +0100

Tom,

The IPv6 socket API is currently an IPNG WG work item so whoever wants
to progress this approach needs to talk urgently to the authors of 
draft-ietf-ipngwg-bsd-api-new-01.txt which will update RFC 2133.

  Brian

---

From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group <[email-masked]>
Date: Tue, 29 Sep 1998 23:19:03 -0400

Hi Folks,

>draft-ietf-ipngwg-bsd-api-new-01.txt which will update RFC 2133.

Brian is right we are just about at last call on the base api.  I am not
clear it affects you all as Brian, but enlighten me?
also we are at draft -02a not 01.

>> Procedural question:  How can we move this to be part of the IPv6 stuff?

First of all we (being the IETF) don't own the getaddrinfo spec we just
regurgitate the getaddrinfo() call per the POSIX WG we can't change it
in the IETF.  We are working on two new APIs getipnodebyname and
getipnodebyaddr.  

Also there is no "presentation layer" in IP let alone in IPv6.  This is
an OSI term we don't really use.

But if you want funny things done for IPv6 the place to put it is in the
Advanced API not the Base API (RFC 2133 now and to be updated).  The
Advanced API is where such parts should go now as the IPv6 base api is
concrete with the finishing touches and the WG will not break binary
compatibility again, which this will not but it should be presented to
the IPng WG for the Advanced API now.

But this discussion is on the wrong list if it involves IPv6 socket
APIs, take it to IPng WG.

Co-Author and present editor of the Base API,
/jim