All of lore.kernel.org
 help / color / mirror / Atom feed
* IPv6 address printf format specifier
@ 2009-03-16 16:24 Chuck Lever
  2009-03-16 17:13 ` Vlad Yasevich
  0 siblings, 1 reply; 6+ messages in thread
From: Chuck Lever @ 2009-03-16 16:24 UTC (permalink / raw)
  To: netdev

The NFS and RPC code in the kernel now uses the new printf format  
specifier for IPv6 addresses.  In some cases, the generated address  
string is sent out of the kernel (for example, it is used to build a  
universal address for RPCB_SET requests, and used as the mon_name in  
some SM_MON upcalls to our rpc.statd).

The problem is that outside the kernel, applications generally use  
getnameinfo(3) or inet_ntop(3) to do this conversion.  The library  
follows the RFC suggestion of shortening these address strings by  
replacing the longest series of zeroes in the IPv6 address with "::".

Since the kernel doesn't do that, string comparisons don't work when  
comparing address strings that came from our kernel.  Since these  
address strings appear to other hosts (via the rpcbind registry) this  
is, or could become, an interoperability issue for Linux.

How should I fix this?

1.  Copy glibc's code to the printf logic for %pI6

2.  Copy glibc's code to a special function used only by SM_MON and  
RPCB_SET

3.  Other suggestions or preferences?

Glibc's implementation is Paul Vixie's free version.

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: IPv6 address printf format specifier
  2009-03-16 16:24 IPv6 address printf format specifier Chuck Lever
@ 2009-03-16 17:13 ` Vlad Yasevich
  2009-03-19  1:58   ` David Miller
  0 siblings, 1 reply; 6+ messages in thread
From: Vlad Yasevich @ 2009-03-16 17:13 UTC (permalink / raw)
  To: Chuck Lever; +Cc: netdev

Chuck Lever wrote:
> The NFS and RPC code in the kernel now uses the new printf format
> specifier for IPv6 addresses.  In some cases, the generated address
> string is sent out of the kernel (for example, it is used to build a
> universal address for RPCB_SET requests, and used as the mon_name in
> some SM_MON upcalls to our rpc.statd).
> 
> The problem is that outside the kernel, applications generally use
> getnameinfo(3) or inet_ntop(3) to do this conversion.  The library
> follows the RFC suggestion of shortening these address strings by
> replacing the longest series of zeroes in the IPv6 address with "::".
> 
> Since the kernel doesn't do that, string comparisons don't work when
> comparing address strings that came from our kernel.  Since these
> address strings appear to other hosts (via the rpcbind registry) this
> is, or could become, an interoperability issue for Linux.
> 
> How should I fix this?
> 
> 1.  Copy glibc's code to the printf logic for %pI6

I think this is the optimum solution.  This normalizes kernel output
with that of user-space thus creating a uniform format.

My $0.02
-vlad

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: IPv6 address printf format specifier
  2009-03-16 17:13 ` Vlad Yasevich
@ 2009-03-19  1:58   ` David Miller
  2009-03-19  2:26     ` Vlad Yasevich
  0 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2009-03-19  1:58 UTC (permalink / raw)
  To: vladislav.yasevich; +Cc: chuck.lever, netdev

From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Mon, 16 Mar 2009 13:13:00 -0400

> Chuck Lever wrote:
> > The NFS and RPC code in the kernel now uses the new printf format
> > specifier for IPv6 addresses.  In some cases, the generated address
> > string is sent out of the kernel (for example, it is used to build a
> > universal address for RPCB_SET requests, and used as the mon_name in
> > some SM_MON upcalls to our rpc.statd).
> > 
> > The problem is that outside the kernel, applications generally use
> > getnameinfo(3) or inet_ntop(3) to do this conversion.  The library
> > follows the RFC suggestion of shortening these address strings by
> > replacing the longest series of zeroes in the IPv6 address with "::".
> > 
> > Since the kernel doesn't do that, string comparisons don't work when
> > comparing address strings that came from our kernel.  Since these
> > address strings appear to other hosts (via the rpcbind registry) this
> > is, or could become, an interoperability issue for Linux.
> > 
> > How should I fix this?
> > 
> > 1.  Copy glibc's code to the printf logic for %pI6
> 
> I think this is the optimum solution.  This normalizes kernel output
> with that of user-space thus creating a uniform format.
> 
> My $0.02

Then you'll break cases where this string is output via
some /proc/ file or whatever and it expects the existing
behavior.

I don't think we can do this.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: IPv6 address printf format specifier
  2009-03-19  1:58   ` David Miller
@ 2009-03-19  2:26     ` Vlad Yasevich
  2009-03-19  5:30       ` David Miller
  0 siblings, 1 reply; 6+ messages in thread
From: Vlad Yasevich @ 2009-03-19  2:26 UTC (permalink / raw)
  To: David Miller; +Cc: chuck.lever, netdev

David Miller wrote:
> From: Vlad Yasevich <vladislav.yasevich@hp.com>
> Date: Mon, 16 Mar 2009 13:13:00 -0400
> 
>> Chuck Lever wrote:
>>> The NFS and RPC code in the kernel now uses the new printf format
>>> specifier for IPv6 addresses.  In some cases, the generated address
>>> string is sent out of the kernel (for example, it is used to build a
>>> universal address for RPCB_SET requests, and used as the mon_name in
>>> some SM_MON upcalls to our rpc.statd).
>>>
>>> The problem is that outside the kernel, applications generally use
>>> getnameinfo(3) or inet_ntop(3) to do this conversion.  The library
>>> follows the RFC suggestion of shortening these address strings by
>>> replacing the longest series of zeroes in the IPv6 address with "::".
>>>
>>> Since the kernel doesn't do that, string comparisons don't work when
>>> comparing address strings that came from our kernel.  Since these
>>> address strings appear to other hosts (via the rpcbind registry) this
>>> is, or could become, an interoperability issue for Linux.
>>>
>>> How should I fix this?
>>>
>>> 1.  Copy glibc's code to the printf logic for %pI6
>> I think this is the optimum solution.  This normalizes kernel output
>> with that of user-space thus creating a uniform format.
>>
>> My $0.02
> 
> Then you'll break cases where this string is output via
> some /proc/ file or whatever and it expects the existing
> behavior.
> 
> I don't think we can do this.
> 

Ugh... you are right.  Changing the formating across the board is a non-starter,
as much as I would still like to see it.

Upon rereading Chunk's text and re-reading RFC 2732 and RFC 4291, I've come
to the conclusion that any application that attempts to compare textual
representations of IPv6 addresses is misguided at best.

There are multiple different forms of presenting addresses, all of which
are valid and non of which will provide for sting equality.  Regardless of
how we represent our IPv6 addresses, there is a chance that it will cause
interoperability issues and the only way to truly solve it is to change
applications to compare addresses in their true numerical representation.

-vlad

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: IPv6 address printf format specifier
  2009-03-19  2:26     ` Vlad Yasevich
@ 2009-03-19  5:30       ` David Miller
  2009-03-19 16:11         ` Chuck Lever
  0 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2009-03-19  5:30 UTC (permalink / raw)
  To: vladislav.yasevich; +Cc: chuck.lever, netdev

From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Wed, 18 Mar 2009 22:26:30 -0400

> There are multiple different forms of presenting addresses, all of
> which are valid and non of which will provide for sting equality.
> Regardless of how we represent our IPv6 addresses, there is a chance
> that it will cause interoperability issues and the only way to truly
> solve it is to change applications to compare addresses in their
> true numerical representation.

Or to, they themselves, canonicalize the text representation before
comparison.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: IPv6 address printf format specifier
  2009-03-19  5:30       ` David Miller
@ 2009-03-19 16:11         ` Chuck Lever
  0 siblings, 0 replies; 6+ messages in thread
From: Chuck Lever @ 2009-03-19 16:11 UTC (permalink / raw)
  To: David Miller, vladislav.yasevich; +Cc: netdev

On Mar 19, 2009, at Mar 19, 2009, 1:30 AM, David Miller wrote:
> From: Vlad Yasevich <vladislav.yasevich@hp.com>
> Date: Wed, 18 Mar 2009 22:26:30 -0400
>
>> There are multiple different forms of presenting addresses, all of
>> which are valid and non of which will provide for sting equality.
>> Regardless of how we represent our IPv6 addresses, there is a chance
>> that it will cause interoperability issues and the only way to truly
>> solve it is to change applications to compare addresses in their
>> true numerical representation.
>
> Or to, they themselves, canonicalize the text representation before
> comparison.

Thanks, this was helpful.

We had considered converting the string address to a sockaddr and back  
in user space, and that sounds like a good way to ensure we get the  
same presentation address for comparison.

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-03-19 16:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-16 16:24 IPv6 address printf format specifier Chuck Lever
2009-03-16 17:13 ` Vlad Yasevich
2009-03-19  1:58   ` David Miller
2009-03-19  2:26     ` Vlad Yasevich
2009-03-19  5:30       ` David Miller
2009-03-19 16:11         ` Chuck Lever

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.