Subject: RE: IPv6 Address Architecture update question

From: "Bound, Jim" <[email-masked]>
Date: Wed, 2 Feb 2005 03:45:16 -0500

> On Tue, 2005-02-01 at 23:25 -0500, Bound, Jim wrote:
> > I am not going to dive in here and increase my responses on this 
> > thread and eat up my limited messages I will bombard this list with 
> > ok, supporting the mail model less mail is better and 
> keeping low on 
> > Rob's messages list each week.
> 
> Better waste less bandwidth with the above and send a bit 
> more messages ;)

OK one more.  This suggestion does not have consenus as Bob stated thus
my last email on this one.

> 
> >   But, besides v4mapped being widely deployed on "vendor" 
> "production" 
> > shipping code bases, used today by applications,
> 
> Please name these 'vendor's and 'applications' I am quite 
> sure if you ask them that they think it should be removed if 
> they have made to try the code run on more than a single platform.

I will not name applications but HP, IBM, Sun, and vendors who
productize Linux and FreeBSD to name a few. V4-mapped addresses are part
of the POSIX standards as stated in the Literature reference below.

> 
> > believe v4mapped is a very useful and elegant solution for 
> application 
> > providers to provide a common binary v4+v6 solution as an option 
> > "technically" and superior to not using it.
> 
> Please look at the Apache2 APR code which demonstrates how 'elegant'
> this solution is because it is not default.

The default is up to the software developer Netscape chose differently.
It is a choice in the standard.

> 
> >   I emphatically disagree
> > with Itojun, cmetz, et al referenced and we had this debate 
> many years 
> > ago, then again had the debate, and that view lost and we 
> should not 
> > revisit it again.
> 
> You mean some people shoved the arguments away without having 
> any background in the subject?

That is a baldface indirect lie, and slander in the form of a question
to the team that worked on this for a long time, and you were not in
those conversations or on the api-list or part of the team, which was
where the in depth technical debate took place.

Now that you have decided to question the honor of the team that worked
on this discussion, and I was part of that team, I suggest you and I
take this offline in person face to face if you happen to be in
Minneapolis around March 6-9.  I will look forward to it unless you can
only dishonor persons behind an indirect email message and don't have
the guts to do it in person?

> 
> > No one has to implement a port to IPv6 or a new application with 
> > v4mapped addresses.  It is merely an option that is available to a 
> > programmer and upto them and it is available on production 
> platforms 
> > today.
> 
> The production platforms mostly use KAME stacks, the other is Windows.

KAME is one version and view of FreeBSD.  I have no response regarding
what Windows supports or does not support.

> Guess what both of these platform don't have, at least turned on per
> default: ipv4-mapped.

That is fine and not the point of this discussion.  The point of this
discussion is to continue to support the ability to use v4-mapped
addresses.  That I believe has consensus.

> 
> Please name the platforms you call 'production'.

Did above your repeating yourself.

> 
> > Mark Andrews point is quite valid and that is the responsibility of 
> > each implementation to document their use of v4mapped, and out of 
> > scope for the IETF as that is an implementation manner.  
> Whether it is 
> > useful to document various behaviors (INFO, BCP) is not clear to me 
> > that is necesary and see UNIX Network Programming Volume I 
> Third Edition.
> 
> Which nicely mentions the use of getaddrinfo() and separately doing ::
> and 0.0.0.0 with IPV6_ONLY sockets because of the inherit 
> issues mentioned by Itojun.

Give me a break Jeroen.  Read pp's 315 and on; the authors presented all
cases and v4-mapped is in the tables and it provides an unbiased view
presenting both solutions, I saw preliminary versions of this section
before it was published from one of the reviewers and I recall then it
was an unbiased version as was the Second Edition (minus the new
IPv6-ONLY option).

The compromise we defined in the API is to support IPv6-ONLY option
there is no problem here at all.

I see no point of further responses to this email it has all been
discussed before, and the bogus accusations like the one you made above
too.

/jim

> Greets,
>  Jeroen

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 02 Feb 2005 10:41:08 +0100

>  > On Tue, 2005-02-01 at 23:25 -0500, Bound, Jim wrote:
<SNIP>
> of the POSIX standards as stated in the Literature reference below.

As mentioned Linux is still the only to support v4-mapped addresses,
that is that it is active per default. There is a toggle to turn it off.
OpenBSD doesn't support it at all and NetBSD and FreeBSD only after
toggling a sysctl setting.

I had actually hoped that you identified the applications that you where
mentioning as then we could ask the developers if they supported more
than one platform or just only on one where they knew what to expect.
Please do an inquiry under the developers you know and ask them about
their experiences with programming IPv6 capable services.

The biggest 'fun' of programming a multi-platform application, good
examples, as mentioned are Apache and Mozilla, is that you never know
what the underlying platform is going to do. A large number of ifdef's
weird cases doesn't make the code easier to develop nor deploy.

It is indeed in POSIX, but why don't admit that it is a mistake to have
it? I though that it was a great idea too, until the Windows
implementation came out that does not and cannot support it due to it's
separate stacks. And there are a number of other platforms who likely
have the same issue, especially if programming in a modular way.

We still have a chance IPv4 mapped to at least _deprecate_, that is what
I mentioned in my other message, the usage of these addresses and to
note that implementors should really be using separate sockets, which is
also what getaddrinfo() tells one to do.

Simply explaining to people, with a small note, that they should not use
it because it will cause them many pains in several coding aspects,
especially when porting it to other platforms. Socket API's 

> It is a choice in the standard.

What has Netscape to do with Apache? Or am I really missing something?
Then again I don't follow corporate takeovers and such, got better
things to do; Netscape do have some influence with Mozilla/Firefox et
al, and they also had a lot of problems with this, they actually almost
refused to do a Windows IPv6 version because they didn't understand the
concept of a separate IPv6 and IPv4 socket. Also see:
https://bugzilla.mozilla.org/show_bug.cgi?id=175340

Apache's APR has the same problem and shows how much work one has to do
when supporting multiple Operating Systems. I just named the above as
that is very common and readable code and most likely used by, hmm jup,
HP, IBM and Sun as they all have some form of repackaged-Apache in their
'products'.

Please do realize that many people do the part that is implemented in
APR on their own, you want to to reinvent all those bugs and have them
get all the trouble over and over?

There are many more examples of code out on the internet that
demonstrate that having the v4-mapped addresses only gives a lot of
issues. You haven't named one application though that does not have it.

> where the in depth technical debate took place.

Thanks for calling it a lie, any arguments to support it ?
You mention yourself that the view was lost. Maybe time to refresh that
view?

Many policies get changed and reformed after they have been put to
ground. Even RFC's get updated. Why is it not possible to do a good
thing and update it now. IPv6 is not *that* deployed yet, there is still
time to get it going in the correct direction.

As some others have mentioned before, if these fundamental things are
not tackled, the people doing IPv7 will soon be here and will be facing
the same issues again, maybe they will get it right?

> the guts to do it in person?

Unfortunately I am doing all of this in my spare time and as an
individual, there are people who actually do this you know, otherwise I
would tell you all of this face to face, but why offline actually, isn't
the IETF a public organization?

Oh, and you might not remember, but I already asked you a somewhat
similar question before, "how many users are actually connected to your
nice Internet2" when you where promoting that in Brussels last year, but
then you didn't have time to answer the question either. I probably was
not important enough for you. Not that I mind, many people have many
other more important things to do and I am just a student with most of
the time a little bit too big mouth stepping on peoples feet.

As for the in person, anyone can easily validate that I wrote this
message, there is a reason I PGP sign my emails. I have nothing to hide
and I do completely stand behind my arguments.

If you have an argument with me, which you do not want to publicly
mention, you know my email address.

> what Windows supports or does not support.

KAME is the IPv6 stack that FreeBSD has, unless I miss something, there
is nothing else. Note that Linux also took a lot of KAME code into the
mainstream kernel by means of the USAGI project.

> addresses.  That I believe has consensus.

If you would count the number of people who sent a message and where in
favor of dropping the support it really is in favor of dropping it.
You cannot simply claim consensus because you would like to.

> Did above your repeating yourself.

In case you would miss out on the question ;)

> Give me a break Jeroen.

<sarcasm>
I don't think I have the financial means to give you a good enough
holiday, sorry, if I had I would give it to you :)
</sarcasm>

>   Read pp's 315 and on; the authors presented all

Which is what I said above, they do discuss it, but they mention that
one should use the IPV6-ONLY option. Thus why is it not possible to
amend the text in a similar way?

> there is no problem here at all.

Then why not simply additionally add "please use IPV6-ONLY as there are
many drawbacks when wanting to stay portable across different
platforms" ?

> discussed before, and the bogus accusations like the one you made above

Thank you again for mentioning that I make 'bogus accusations'.
Ignoring is of course the best option in those cases where you don't
want to make a case for your arguments.

And indeed I mentioned three times or so that simply noting that using
v4-mapped, or better said using getaddrinfo() without IPV6-ONLY causes a
lot of problems. A tiny amendment would solve my argument.

If you think that I am being hostile, then please take the break, you'll
then need it for sure.

Greets,
 Jeroen

---

From: Colm MacCarthaigh <[email-masked]>
Date: Wed, 2 Feb 2005 10:12:42 +0000

> also what getaddrinfo() tells one to do.

RFC3493 solves this by having IPV6_V6ONLY. We just need to wait for
all platforms to implement it :)

> https://bugzilla.mozilla.org/show_bug.cgi?id=175340

Just to clear things up, I wrote a lot of the code that deals with it in
Apache httpd, and apr. And I've never worked for Netscape. I think Jim
may be implying that Netscape took a different (possibly superiour)
approach.  I know not :)

> issues. You haven't named one application though that does not have it.

In fairness, this does not matter. mapped-addresses are useful from
a certain perspective anyway. If there is some in-house trivial
application that only needs to run on Linux, there is no good reason 
why mapped-addresses should not be used as an easy migration.

Whether or not the portability problems outweigh this kind of limited
benefit is a subjective judegment call - and one on which consensus is
unlikely to ever be reached.

RFC3493 encourages vendors to implement the IPV6_V6ONLY option
(something neither 2133 nor 2553 had), so that's the nod that's needed
on this front.

Really the only remaining portability issue is the default behaviour of
bind(::) (without any specific options set). 

So in summary, my mind has been changed a little on mapped-addresses
- in that although I wouldn't use them, they have a use in limited
  circumstances - but some kind of encouragement to vendors to
consolidate a standard behavior for a bind/listen call could be
desirable.

-- 
Colm MacCárthaigh                        Public Key: [email-masked]

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 02 Feb 2005 11:16:25 +0100

<SNIP>

> consolidate a standard behavior for a bind/listen call could be

Full ack.

Greets,
 Jeroen

---

From: Markku Savela <[email-masked]>
Date: Wed, 2 Feb 2005 17:48:13 +0200

> From: Colm MacCarthaigh <[email-masked]>

> bind(::) (without any specific options set). 

In Symbian OS API, see

 http://www.symbian.com/developer/techlib/v70docs/SDL_v7.0/doc_source/reference/cpp/Tcpip/

Bind to "any" (for incoming) has 3 choices

 1) Bind(::) - accept only IPv6
 2) Bind(0.0.0.0) - accept only IPv6
 3) Bind() - accept both IPv4 and IPv6

The case (3) may need some explanation: in Symbian the adddress and
port stored in class named TInetAddr (see the above link). This class
contains the address family, which can be

 (1) KAFInet6 (~ AF_INET6)
 (2) KAFInet  (~ AF_INET)
 (3) 0 ( unspecified)

In Symbian environment, application has really no need to explicitly
specify IPv4 or IPv6, and (3) is the best way to code. But, if someone
insists on doing things the "hard way", they can limit their
applications using either (1) or (2).

Above really has nothing to do with IPv4 mapped addresses. In symbian,
IPv4 address can be stored into TInetAddr either "traditionally" or as
IPv4 mapped format. They are *totally* equivalent, there is no
semantic difference at all. They are just two different formats for
the same thing.

However, IPV4 mapped format is important tool to make it possible to
share code between IPv4 and IPv6. Using IP4 Mapped addresses allows to
write single version of code that works as is for both IPv4 and IPv6.

The Symbian stack is full hybrid IPv4/IPv6 stack. As installed base,
the number of devices is rather large. But, then, they are small and
light. Perhaps it's not as large as kame+unix/linux if you compute
installed base in kilograms.. :-)

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 02 Feb 2005 17:53:24 +0100

>  2) Bind(0.0.0.0) - accept only IPv6

I guess you meant to write IPv4 there ;)

>  3) Bind() - accept both IPv4 and IPv6

Nevertheless, this is not ambiguous, if a coder asks for ::, she will
get IPv6 only, not IPv4. When she asks for nothing she will get ANY of
ANY protocols.

> contains the address family, which can be

This is more an API level construction, just like one can abstract the
getaddrinfo() functions etc and hide them in a Java or C++, just like
the above, API, which would hide the details of any IP at all.

For those cases indeed it can be handy to have mapped addresses, but
handling it completely without knowledge of addresses at all is better
in those cases (IMHO).

The question is more how does the hidden part, inside the API handle it?
Recommended way of doing as mentioned by several people, for and against
deprecation of v4 mapped mention Eva's document, which like Itojun's
document and quite a number of others note the usage of getaddrinfo()
and using sockaddr_storage, which can contain basically anything, IPv4,
IPv6, IPX, Netbios, etc. The respresentation of the addresses can then
by done using inet_ntop()/inet_pton() and these can all be hidden even
further nicely in the API, may that be classes or just functions.
There is thus no need for v4-mapped addresses, one just has to program
it the correct way, and not rely on in6_addr directly, which should not
be in ones code at all. (unless you are doing lowlevel stuff etc... )

Or are the classed mentioned above native-Symbian? (Nice docs btw)

> installed base in kilograms.. :-)

Symbian (7.0+) + owner should match up with the unix/linux list, then
again some huge clusters can amount for quite some weight too ;)

On Wed, 2005-02-02 at 17:24 +0100, Francis Dupont wrote:

> So IMHO the only useful answer we can get from this discussion is about
> this day, i.e., are there used implementations today which don't support
> the "two sockets for a server with IPV6_V6ONLY set when it exists"
> (i.e., #@$* but universal) coding style?

The problem here is that there are a number of older implementations that
don't support the flag and there is no way of turning the v4-mapped support
off unless you downgrade. Then again, upgrading is nowadays quite a normal
cycle, but of course in quite a number of situation with version dependencies
and other weird policies this cannot be achieved in all scenario's.
Though one could argue that if a host needs IPv6 that it should have quite
some new software on it already of course ;)

Most newer implementations should support the above.

Greets,
 Jeroen

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 2 Feb 2005 13:32:25 -0800

Jeroen Massar wrote:
> ...
> separate stacks. 

That separation was a point in time implementation choice that is likely to
change in other versions of the OS. The split stack implementation by itself
does not preclude the right thing from happening through either a shim or
direct binding between the stacks, but by default there is no path. 

None of this or any other individual vendor's implementation choice affects
the value of the idea. The only thing those affect are the implementation
effort required for the app developer. Getting rid of a good idea does not
make the app developer's job any easier; it just ensures that everyone has
to go through the same level of pain. Taking it out is a bad idea.

Tony

---

From: Francis Dupont <[email-masked]>
Date: Thu, 03 Feb 2005 11:27:18 +0100

In your previous mail you wrote:

   
   don't support the flag

=> this does not matter because of conditional compilation.

   and there is no way of turning the v4-mapped support
   off unless you downgrade.

=> there is no need of turning the v4-mapped support off if the
second/to-0.0.0.0 bind() can fail safely.

   Then again, upgrading is nowadays quite a normal cycle...

=> I know but this does not help to get an answer to my question.

Regards

[email-masked]

PS: BTW IMHO the Symbian API implements an abstract "IPv6 is a new version
of the Internet protocol". I have only a little concern because it
implements too "the network protocol is the Internet protocol" (:-)!