From: Brian Haley <brian.haley@hp.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Linux Network Developers <netdev@vger.kernel.org>,
Jeff Layton <jlayton@redhat.com>
Subject: Re: IPv6: presentation format for zero scope ID
Date: Mon, 07 Dec 2009 22:27:16 -0500 [thread overview]
Message-ID: <4B1DC794.5020406@hp.com> (raw)
In-Reply-To: <EA6985CB-3B58-4982-85FE-94C951D2FE5E@oracle.com>
Chuck Lever wrote:
> I recently added some functions to sunrpc.ko that behave like
> getnameinfo(AI_NUMERICHOST) does in user space.
>
> One of the functions, rpc_ntop6(), sticks a scope ID on the end of link-
> and site-local IPv6 addresses. It does not try to map the scope ID to a
> device name.
Site-local addresses have been deprecated...
> It has been pointed out, however, that glibc's getnameinfo(3) skips
> appending a device name if the scope ID is zero. Should rpc_ntop6()
> display or ignore zero scope IDs?
A zero scope id implies it's not set, so I would ignore it. Things like
*bind() and *connect() already do this.
> Would it be better if it also
> converted scope IDs to device names?
*nix typically uses %eth0, Windows uses %1, so I guess if it's for
display purposes I'd do the same thing all the tools use - %name.
This isn't being put in a packet, is it?
> I'm not familiar enough with the IETF mandates regarding presentation
> address format, or the idiosyncrasies of the Linux IPv6 implementation,
> to know what is the desired behavior here. Any guidance appreciated.
The URI spec (RFC 3986) doesn't cover scope id's, so it winds-up being
implementor's choice.
-Brian
next prev parent reply other threads:[~2009-12-08 3:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-07 21:45 IPv6: presentation format for zero scope ID Chuck Lever
2009-12-08 3:27 ` Brian Haley [this message]
2009-12-08 13:03 ` Jeff Layton
2009-12-08 15:57 ` Chuck Lever
2009-12-09 19:57 ` Chuck Lever
2009-12-09 22:50 ` Brian Haley
2009-12-10 18:19 ` Chuck Lever
2009-12-10 19:32 ` Brian Haley
2009-12-08 16:08 ` Chuck Lever
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B1DC794.5020406@hp.com \
--to=brian.haley@hp.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@redhat.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.