IPv6: presentation format for zero scope ID

IPv6: presentation format for zero scope ID

[Chuck Lever]

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.

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?  Would it be better if it also  
converted scope IDs to device names?

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.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: IPv6: presentation format for zero scope ID

[Brian Haley]

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

Re: IPv6: presentation format for zero scope ID

[Jeff Layton]

On Mon, 07 Dec 2009 22:27:16 -0500
Brian Haley <brian.haley@hp.com> wrote:

> 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...
> 

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.

-- 
Jeff Layton <jlayton@redhat.com>

Re: IPv6: presentation format for zero scope ID

[Chuck Lever]

On Dec 8, 2009, at 8:03 AM, Jeff Layton wrote:

> On Mon, 07 Dec 2009 22:27:16 -0500
> Brian Haley <brian.haley@hp.com> wrote:
>
>> 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...
>
> 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.

Another way to interpret "deprecated" would be that their original  
meaning is unchanged, but their use is discouraged.  That's what  
"deprecated" means for APIs like gethostbyaddr(3).

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: IPv6: presentation format for zero scope ID

[Chuck Lever]

Brian-

On Dec 8, 2009, at 8:03 AM, Jeff Layton wrote:

> On Mon, 07 Dec 2009 22:27:16 -0500
> Brian Haley <brian.haley@hp.com> wrote:
>
>> 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...
>>
>
> 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?

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: IPv6: presentation format for zero scope ID

[Brian Haley]

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.

-Brian

Re: IPv6: presentation format for zero scope ID

[Chuck Lever]

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

Re: IPv6: presentation format for zero scope ID

[Brian Haley]

Chuck Lever wrote:
> 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.

Devices can be renamed, I'm not sure how common it is after boot though.
If you're not printing it that often the overhead of dev_get_by_index()
probably isn't that high, especially since it now uses RCU.

> 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.

Are you asking if a given numeric scope ID could map to a different interface
depending on the namespace?  I don't think so, the ifindex is unique for every
device, but a given network namespace might not contain the device that
matches a certain ifindex.

-Brian

Re: IPv6: presentation format for zero scope ID

[Chuck Lever]

On Dec 7, 2009, at 10:27 PM, Brian Haley wrote:
> 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?

RPC uses presentation format addresses for lots of things.  Such a  
presentation address will go on the wire in the form of a universal  
address.  uaddrs were around before scope IDs were invented, so they  
don't support or use the %n or %dev notation.  Naturally the scope ID  
doesn't have meaning for other systems anyway.

Such an address can also be used for RPC cache upcalls to user space  
daemons.  A scope ID would potentially have meaning in that case.

So it sounds like it would be reasonable to:

a) squelch appending "%n" if n is zero, and

b) append a device name instead of an integer scope ID

>> 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

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com