[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <3C8ED938-D4F9-4167-BC02-575265B7A56A@oracle.com>
Date: Thu, 10 Dec 2009 13:19:08 -0500
From: Chuck Lever <chuck.lever@...cle.com>
To: Brian Haley <brian.haley@...com>
Cc: Jeff Layton <jlayton@...hat.com>,
Linux Network Developers <netdev@...r.kernel.org>
Subject: Re: IPv6: presentation format for zero scope ID
On Dec 9, 2009, at 5:50 PM, Brian Haley wrote:
> Hi Chuck,
>
> Chuck Lever wrote:
>>> So this means that addresses with those prefixes should be treated
>>> like
>>> any other address, right? If so, then I think the rpc_ntop6
>>> shouldn't be
>>> affixing scopeid's to site local addresses.
>>
>> As a final detail, we're trying to understand what is the correct
>> treatment for site-local addresses. I've looked at RFC 3879. In
>> late-model Linux kernels, is Jeff's interpretation correct, for
>> application layer protocols like RPC?
>
> Not sure if this answers the question, but recent Linux kernels only
> look
> at the scope ID for link-local addresses.
OK, I'll drop the support in net/sunrpc/addr.c for SITELOCAL.
One other thing. This is a rather more broad question, but still IPv6-
related.
I'm considering mapping the scope ID to a device name in rpc_ntop6(),
but it looks like network device names are part of a net namespace,
and these presentation address strings are shared. This address
string might appear in /proc/mounts, for example, but can also be used
to send messages to user space service daemons like statd or gssd. We
try to do the conversion once when certain objects are created (like
an RPC client data structure) and then save the string.
Is it OK to leave just the scope ID (for link-local only, of course),
or might the scope IDs also vary depending on the namespace? I
wouldn't think that they would.
Thanks for your advice so far.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists