In your previous mail you wrote:
I believe that your comments are based on a host model that does not
entirely cover reality.
=> but this model has many implementations, including routers or
multi-homed hosts.
An IP address, v4 or v6, designates an
interface, not a host. A host can
uro Tortonesi
> Cc: Jim Bound; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: RFC 2553 bind semantics harms the way to AF independence
>
> In your previous mail you wrote:
>
>> With V6ONLY you should be able to bind 0.0.0.0, 23 and bind
In your previous mail you wrote:
> >> => you can use it with the V6ONLY stuff.
> >yes, but on rfc2553-compliant system you cannot have both an AF_INET
> >and an AF_INET6 socket listening on the same port.
>
>(just a picky comment) RFC2553 does not talk about the behavior
>
In your previous mail you wrote:
> With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one
> using AF_INET and the other AF_INET6.
RFC2553 does not state this behaviour.
=> I disagree.
in fact many implementations do not allow to do this.
=> fix them!
can
In your previous mail you wrote:
>From my reading of 2553bis, there seem to be at least two ways this
can be implemented (not counting the semantic changes being proposed):
=> yes, you can have merged or split port space. Both are commonly
implemented and the 2553 bis document accepts
> > => you can use it with the V6ONLY stuff.
> yes, but on rfc2553-compliant system you cannot have both an AF_INET
> and an AF_INET6 socket listening on the same port.
>=> you can do it with the V6ONLY stuff. (again)
again, there's no explicit text about this issue. i believe you
On Sun, 1 Jul 2001, Francis Dupont wrote:
> In your previous mail you wrote:
>
>> => you can use it with the V6ONLY stuff.
>
>yes, but on rfc2553-compliant system you cannot have both an AF_INET
>and an AF_INET6 socket listening on the same port.
>
> => you can do it with the V6ONLY
In your previous mail you wrote:
it seems that there are many people in favor of changing the behaviour
of AF_INET6 sockets: itojun, pekka, me, horape, brian, erik.
=> but there are more people in favor of keeping the behaviour of
AF_INET6 sockets, they are only too bored by this discussi
In your previous mail you wrote:
we have only to keep the discussion within boundaries (i don't like
flame wars).
=> this discussion already occured without any result (no flame war too
but only because we kept it within boundaries). It is just too late
and to get a RFC 2553 bis publis
In your previous mail you wrote:
> => you can use it with the V6ONLY stuff.
yes, but on rfc2553-compliant system you cannot have both an AF_INET
and an AF_INET6 socket listening on the same port.
=> you can do it with the V6ONLY stuff. (again)
> => this is the standard way b
>> > With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one
>> > using AF_INET and the other AF_INET6.
>> RFC2553 does not state this behaviour. in fact many implementations do
>> not allow to do this.
>That is unfortuneate. I will make sure this is added to the IPv6 test
>suites a
Hi Mauro,
Sorry for late response. Also I could be out of it till July 16th going
on the road to do edu, evangelize, and meet offline with seriously
deploying IPv6 enterprises for a few weeks for Ipv6 Forum and U.S.
customer of IPv6. But will try to check mail. Don't wait for me to keep
talkin
On Tue, Jun 26, 2001 at 11:50:33PM -0400, Jim Bound wrote:
> I was directly speaking of implementations that make billions of dollars.
> That is not Linux or BSD.
With all due respect, when you're talking about implementor eyeballs,
a huge percentage of unix server implementors learn based on wha
On Wed, 27 Jun 2001, Jim Bound wrote:
> > > => you can use it with the V6ONLY stuff.
> >
> > yes, but on rfc2553-compliant system you cannot have both an AF_INET
> > and an AF_INET6 socket listening on the same port.
>
> Sure you can. By using V6ONLY. Thats the point of the option. It is
> jus
On Wed, 27 Jun 2001, Jim Bound wrote:
> and it should not but an implementation that does not permit this is not
> optimal. we cannot force this behavior on implementors either. thats why
> it is not in 2553.
can't RFC2553 say something like "a good implementation SHOULD allow
binding of AF_IN
On Wed, 27 Jun 2001, Jun-ichiro itojun Hagino wrote:
>
> >> => you can use it with the V6ONLY stuff.
> >yes, but on rfc2553-compliant system you cannot have both an AF_INET
> >and an AF_INET6 socket listening on the same port.
>
> (just a picky comment) RFC2553 does not talk about the beha
This is not a problem just a solution .
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Wed, 27 Jun 2001, Erik Nordmark wrote:
> > Jim Bound:
> > > we did suggest that there be no default for v6only (in fact I
> > suggested
> > > it) and no one on either side wanted that. think
I think having an appendix with issues and documenting them makes sense
too.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Wed, 27 Jun 2001, Pekka Savola wrote:
> On Wed, 27 Jun 2001, Jim Bound wrote:
> > and it should not but an implementation that does not permit this is not
> >
Erik Nordmark wrote:
> > Actually I suggested it as well, so I wouldn't have a problem with
no
> > default. Anyone who wants portable apps would just always set the
> > option, no problem.
>
> The benefit of changing the default would be that applications using
> getaddrinfo could be more addres
In seems to me that all this discussion about what the default
behavior should be when binding to a wildcarded AF_INET6 socket
doesn't address the issue: deterministic behavior for portable
application across multiple operating systems.
And just to lay my cards on the table, I support the current
>1. Protocol independance is an extremely rare ideal (I
>would not call it a myth precisely). Having ported a bunch
>of simple and complex application, I can say now that only
>about 5% of them were really protocol independent. Most
>apps do all sorts of loging, setting socket options, etc...
>
>
> With regard to the IPV6_V6ONLY option, it made and makes little difference to
> me what value the option defaults to. No matter which we choose code will
> break. We have also had this discussion before. I see that Erik and Brian
> are for changing the default value to true.
I didn't say
> Umm, then I may have misunderstood a former discussion about itojun's
> very 1st bindtest questionnaire (around August 2000). Perhaps I
> misunderstood the fact that Solaris supported separate port space for
> IPv4 and IPv6. Sorry, I should've been more careful when talking
> about others' im
> Jim Bound:
> > we did suggest that there be no default for v6only (in fact I
> suggested
> > it) and no one on either side wanted that. thinking was even if one
> did
> > not get their choice then its better to have default for the users.
>
> Actually I suggested it as well, so I wouldn't have
I tried to resist jumping in here, but I guess it's time...
1. Protocol independance is an extremely rare ideal (I
would not call it a myth precisely). Having ported a bunch
of simple and complex application, I can say now that only
about 5% of them were really protocol independent. Most
apps
>From my reading of 2553bis, there seem to be at least two ways this
can be implemented (not counting the semantic changes being proposed):
- The IPv4 address space is part of (a subset of, actually) the IPv6
address space. With this approach, 0.0.0.0 can be thought of as a
more specific ad
> On Tue, 26 Jun 2001 10:27:16 +0200,
> Francis Dupont <[EMAIL PROTECTED]> said:
>Just to make it sure, if you mean "accepting IPv4 packets on an
>AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in
>2553", Solaris does not follow the model, AFAIK. Also, NetBSD d
> On Tue, 26 Jun 2001 14:30:05 +0200 (CEST),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> Just to make it sure, if you mean "accepting IPv4 packets on an
>> AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in
>> 2553", Solaris does not follow the model, AFAIK. Also, NetBSD d
On Wed, 27 Jun 2001, Jim Bound wrote:
> and it should not but an implementation that does not permit this is not
> optimal. we cannot force this behavior on implementors either. thats why
> it is not in 2553.
The API is informational document anyway. It would be nice is this kind
of implementa
I "think" this is supported now.but I need to check..
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Tue, 26 Jun 2001, Mauro Tortonesi wrote:
> On Mon, 25 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote:
>
> > > On Fri, 22 Jun 2001 16:51:25 -0300,
> >
and it should not but an implementation that does not permit this is not
optimal. we cannot force this behavior on implementors either. thats why
it is not in 2553.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Wed, 27 Jun 2001, Jun-ichiro itojun Hagino wrote:
>
> >> => you can
> > => you can use it with the V6ONLY stuff.
>
> yes, but on rfc2553-compliant system you cannot have both an AF_INET
> and an AF_INET6 socket listening on the same port.
Sure you can. By using V6ONLY. Thats the point of the option. It is
just you must set it via setsocopt.
With V6ONLY you s
Maruo,
OK I will do solicit equal numbers who want it to stay the same.
And no one said that it was a good idea.
I think being late to the party does not give one more rights than those
that took the risk either. Add the two other authors on 2553 in favor and
I will go get 10 other implementors
this api was always based on bsd and still is.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Tue, 26 Jun 2001, Mauro Tortonesi wrote:
> On Mon, 25 Jun 2001, Jim Bound wrote:
>
> > As far as the default it is you will get v4mapped on AF_INET6 unless you
> > set v6only sockopt.
>
Yep I am still with you on this one but if it ever happen we have to
permit a transition.
I think the argument was now. why do this to the programmer cause we
could not pick a default.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Tue, 26 Jun 2001, Dave Thaler wrote:
> Jim Bound
> Jinmei,
>
> > Just to make it sure, if you mean "accepting IPv4 packets on an
> > AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in
> > 2553", Solaris does not follow the model, AFAIK. Also, NetBSD disable
> > the model by default.
>
> What aspect of this do you believe is not
We have passed the point of no return as far as real products are
concerned. A patch will not work on the OS's. Nor is it justified.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Tue, 26 Jun 2001, Pekka Savola wrote:
> On Tue, 26 Jun 2001, Erik Nordmark wrote:
>
> > > >Depreca
I was directly speaking of implementations that make billions of dollars.
That is not Linux or BSD.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Tue, 26 Jun 2001, Pekka Savola wrote:
> On Mon, 25 Jun 2001, Jim Bound wrote:
> > we do not document product platform differences in th
>then why bothering to write RFC2553? if any ISV can do what he
wants it
>has been only a useless effort.
There is a strong case to be made that the IETF should limit itself to
the definition of protocols, i.e. the bits that flow on the wire, and
should not be concerned with APIs. APIs ar
On Tue, 26 Jun 2001, Brian Zill wrote:
> >From: Erik Nordmark [mailto:[EMAIL PROTECTED]]
> >> >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option
> >> >
> >> > Then the IPv6 sockets would have to be explicitly
> >> > allowed to accept IPv4 connections. So the programs
> >> > that use the
>> => you can use it with the V6ONLY stuff.
>yes, but on rfc2553-compliant system you cannot have both an AF_INET
>and an AF_INET6 socket listening on the same port.
(just a picky comment) RFC2553 does not talk about the behavior
when try to bind(2) to both :: and 0.0.0.0 on the
On Tue, 26 Jun 2001, Francis Dupont wrote:
> => you can use it with the V6ONLY stuff.
yes, but on rfc2553-compliant system you cannot have both an AF_INET
and an AF_INET6 socket listening on the same port.
> => this is the standard way but with the V6ONLY way you can use the
> single socket (my
On Tue, 26 Jun 2001, Francis Dupont wrote:
> In your previous mail you wrote:
>
>On Mon, 25 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote:
>
>> ...however, those corrections do not affect the main stream of this
>> discussion. We've fully, fully discussed this (in the
> From [EMAIL PROTECTED] Tue Jun 26 01:50:32 2001
> Received: from roll.mentat.com (roll [192.88.122.129])
> by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id BAA23124
> for ; Tue, 26 Jun 2001 01:50:32 -0700 (PDT)
> Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
> b
On Tue, 26 Jun 2001, Erik Nordmark wrote:
> > >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option
> > >
> > > Then the IPv6 sockets would have to be explicitly allowed to accept
> > > IPv4 connections. So the programs that use the IPv6 centric way have
> > > to be modified a bit, but the
Jim Bound:
> we did suggest that there be no default for v6only (in fact I
suggested
> it) and no one on either side wanted that. thinking was even if one
did
> not get their choice then its better to have default for the users.
Actually I suggested it as well, so I wouldn't have a problem with
On Tue, 26 Jun 2001, Pekka Savola wrote:
> On Mon, 25 Jun 2001, Jim Bound wrote:
> > AF_INET6 will always permit the catch only model because its been a method
> > for over 6 years and customers have ported to that model. We are not
> > getting rid of it now. That is not going to happen. The m
On Mon, 25 Jun 2001, Jim Bound wrote:
> As far as the default it is you will get v4mapped on AF_INET6 unless you
> set v6only sockopt.
ok, but a good working of v6only sockopt can be obtained only if bind
and getaddrinfo behave like on *BSD. that's the point.
--
Aequam memento rebus in arduis
On Mon, 25 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote:
> > On Fri, 22 Jun 2001 16:51:25 -0300,
> > [EMAIL PROTECTED] said:
>
> >> >> for example: on linux system, if you would like to turn IPV6_V6ONLY
> >> >> option on, you can only accept IPv6 traffic wi
>From: Erik Nordmark [mailto:[EMAIL PROTECTED]]
>> >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option
>> >
>> > Then the IPv6 sockets would have to be explicitly
>> > allowed to accept IPv4 connections. So the programs
>> > that use the IPv6 centric way have to be modified a
>> > bit
> they raise fundamental portability issues when you implement more
> complex applications like BIND9 (see BIND9 doc/misc/ipv6).
>=> we introduce the V6ONLY stuff in order to fix this. Are you
>saying there are still issues if:
> - the implementation is RFC 2553 bis compliant
> - the i
In your previous mail you wrote:
they raise fundamental portability issues when you implement more
complex applications like BIND9 (see BIND9 doc/misc/ipv6).
=> we introduce the V6ONLY stuff in order to fix this. Are you
saying there are still issues if:
- the implementation is
On Tue, 26 Jun 2001, Erik Nordmark wrote:
> > >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option
> > >
> > > Then the IPv6 sockets would have to be explicitly allowed to accept
> > > IPv4 connections. So the programs that use the IPv6 centric way have
> > > to be modified a bit, but the
Jinmei,
> Just to make it sure, if you mean "accepting IPv4 packets on an
> AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in
> 2553", Solaris does not follow the model, AFAIK. Also, NetBSD disable
> the model by default.
What aspect of this do you believe is not there is Solaris
> >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option
> >
> > Then the IPv6 sockets would have to be explicitly allowed to accept
> > IPv4 connections. So the programs that use the IPv6 centric way have
> > to be modified a bit, but the buggy implementations and the unworkable
> > one c
I just want to inject another viewpoint to this Unix-centric
discussion. I'm trying to specify how the IPv6 affects the socket API
in EPOC OS, and this is how it works (to bind a server socket):
RSocketServ iSS; // Socket server handle (EPOC specific)
RSocket iSocket; // Socket (roughly sa
In your previous mail you wrote:
>I get the impression you are doing mostly 2).
> => more than 2), the IPv6 support is not togglable!
In the "real world" you cannot say that. People will want to disable IPv6
for a long time.
=> if you believe this you should spend mor
In your previous mail you wrote:
When we get IPv10, will you prefer to change all your INET6 for INET10,
or just let the AF independent code do that by itself?
=> I can't see a problem before IPv16 (:-)
[EMAIL PROTECTED]
PS: (silly?) suggession: remove AF_INET6 and use AF_INET for IP
In your previous mail you wrote:
The problem is that not forgeting them means the same amount of
work that doing the port in the AF independent way. So the benefits of
the IPv4-mapped addresses (easy porting) get lost.
=> be serious, not all applications need access control (at leas
On Tue, 26 Jun 2001, Francis Dupont wrote:
> In your previous mail you wrote:
>
>> we really need to convince random book authors to update their
>> programming examples, from gethostbyname() to getnameinfo()...
>
>how can you expect them do so, when there's so much difference betwe
In your previous mail you wrote:
On Mon, 25 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote:
> ...however, those corrections do not affect the main stream of this
> discussion. We've fully, fully discussed this (in the apifolks list),
> and have seen so many differe
In your previous mail you wrote:
>we really need to convince random book authors to update their
>programming examples, from gethostbyname() to getnameinfo()...
how can you expect them do so, when there's so much difference between
the behaviour of the various TCP/IPv6 st
In your previous mail you wrote:
> PS: (again) IPv6 is not a new protocol, IPv6 is the new version of IP.
> If you believe in this (stronger than IPv6 itself) then you can really
> understand the dual stack model (the integrated dual version model).
right. but this is not the rea
On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote:
> ¡Hola!
>
> > > for(n = 0; (n < MAX_AF) && res ; res = res->ai_next) {
> > > listenfds[n] = socket(res->ai_family, res->ai_socktype,
> > > res->ai_protocol);
> > > if(listenfds[n] < 0)
> > > continue; /*
On Mon, 25 Jun 2001, Jun-ichiro itojun Hagino wrote:
> >>we really need to convince random book authors to update their
> >>programming examples, from gethostbyname() to getnameinfo()...
> >how can you expect them do so, when there's so much difference between
> >the behaviour of the vari
On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote:
> > in fact, as far as i understand, there's no good standard document
> > on bind(2) interaction between two IPv4 sockets. so defining it
> > for IPv4/v6 interaction would be a big task.
>
> Maybe we should start writing that document? (a
On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote:
> ¡Hola!
>
> > however, it's not so simple. in this way we have two indipendent protocol
> > families AF_INET and AF_INET6 (i would define them orthogonal), so
> > we should modify the behaviour of getaddrinfo.
>
> No change to getaddrinfo is needed.
In your previous mail you wrote:
Just to make it sure, if you mean "accepting IPv4 packets on an
AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in
2553", Solaris does not follow the model, AFAIK. Also, NetBSD disable
the model by default.
=> I agree with the def
In your previous mail you wrote:
> => I don't want to replace IPv4 by IPv6 next month, I want to get
> dual stacks as default ASAP. RFC 2553 is for dual stacks and
> dual stack is the main transition tool.
On dual stacks, user can usually disable ipv6. Examples of this are Linux
Date:Mon, 25 Jun 2001 13:26:17 -0300
From:[EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| The question is "Will IPv6 work forever?", if the answer is yes, then there
| is nothing to talk about, if the answer is no (and I think that way) then
| we should try
On Mon, 25 Jun 2001, Jim Bound wrote:
> we do not document product platform differences in the IETF.
>
> but here is how the market will work.
>
> the market picks a market leader. today that market leader for most of IP
> stuff for "Servers" is Sun Microsystems (not all but most if you look at
>
On Mon, 25 Jun 2001, Jim Bound wrote:
> AF_INET6 will always permit the catch only model because its been a method
> for over 6 years and customers have ported to that model. We are not
> getting rid of it now. That is not going to happen. The market has
> spoken and the early adopter deploymen
ack...
yes this needs to be fixed soon... sorry I missed that.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Tue, 26 Jun 2001, Jun-ichiro itojun Hagino wrote:
>
> >we do not document product platform differences in the IETF.
>
> just to be clear:
> i was sug
>we do not document product platform differences in the IETF.
just to be clear:
i was suggesting to convince *book authors* to write more examples
that use newer APIs, like getaddrinfo(3). otherwise university
students will learn about gethostbyname(3) forever.
h
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
> >we did suggest that there be no default for v6only (in fact I suggested
> >it) and no one on either side wanted that. thinking was even if one did
> >not get their choice then its better to have default for the users.
>
>
I know the ip stack inside and out. if we have to go to IPv10 it will be
a new IP layer protocol and by definition a completely new AF type.
This is not the case for IPv4 and IPv6.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote:
> ¡Hola!
>> Main problem with RFC2553 is that it is too ambiguous. Different
>> implementations of the same standard are a Bad Thing, and vague standards
>> are so a Bad Thing too. RFC 2553 should be made clearer, not vaguer.
>Clarity is mandatory. What text exactly is not clear?
at least the fo
>we did suggest that there be no default for v6only (in fact I suggested
>it) and no one on either side wanted that. thinking was even if one did
>not get their choice then its better to have default for the users.
sorry to be picky. is it correct that "no one on either side wanted
we did suggest that there be no default for v6only (in fact I suggested
it) and no one on either side wanted that. thinking was even if one did
not get their choice then its better to have default for the users.
also this is not a holy war. that was a mis-characterization.
in fact it was about
IPv6 is not optional for 3GGP and I hope soon 3GGP2 and that is both sides
of the wireless coin requiring initial steps to IPv6. If any vendor don't
have IPv6 running in their products this year they will not be permitted
to bid on a large business opportunities.
/jim
"Shout it out G.L.O.R.I.
Clarity is mandatory. What text exactly is not clear?
thanks
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote:
> ¡Hola!
>
> > Compaq implements it the same way.
>
> > But as one author NO this should not go in the spec. It is implementati
mapped addreses permit very large ISVs to treat all addresses as IPv6 and
one code AF. IPv6. And large ISVs tell their suppliers what they want
not the other way around. So if database vendor X (who causes customers
to use computers for their business) tells sun, compaq, ibm, and hp and
others
With all due respect I don't care about peoples grandchildren. I have
been doing this for 25 years. 10 years is tops anything lasts of this
nature. So I don't care about after 10 years.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote:
>
we do not document product platform differences in the IETF.
but here is how the market will work.
the market picks a market leader. today that market leader for most of IP
stuff for "Servers" is Sun Microsystems (not all but most if you look at
market share). For the client its Microsoft.
If
This api is not going to standards track it is in informational RFC ONLY.
The real standard for the API will be done by the IEEE 1003 committee and
we are trying to get them to work with the IETF experts here.
They have adopted 2553-bis-03.txt style. Its a done deal.
What is open for discussion
AF_INET6 will always permit the catch only model because its been a method
for over 6 years and customers have ported to that model. We are not
getting rid of it now. That is not going to happen. The market has
spoken and the early adopter deployment customers will not have their code
broken.
And I have seen a lot of well written code that uses the API as is and
testing in various research centers.
We cannot change the base api for IPv6 every six months because new
programmers want new features. what we need to do is take what we have
now and see what IEEE did with the latest rev the
¡Hola!
> Compaq implements it the same way.
> But as one author NO this should not go in the spec. It is implementation
> defined. The only way to force this is to discuss porting assumptions of
> the market place. That is at best an art and not a science at this point
> with IPv6. If someon
¡Hola!
>i have seen that many programmers find difficult the process of porting
>their apps to ipv6. i think that we should write a small informational
>document that explains how to write good ipv6-compliant code.
>itojun's "Implementing AF-indipendent apps" is a very good docume
¡Hola!
>I get the impression you are doing mostly 2).
> => more than 2), the IPv6 support is not togglable!
In the "real world" you cannot say that. People will want to disable IPv6
for a long time.
>As said, I don't think this works yet in real life (consider: OS
>distributions),
> On Mon, 25 Jun 2001 16:05:34 +0200 (CEST),
> Mauro Tortonesi <[EMAIL PROTECTED]> said:
>> ...however, those corrections do not affect the main stream of this
>> discussion. We've fully, fully discussed this (in the apifolks list),
>> and have seen so many different views, and, as a co
¡Hola!
> >IMHO, draft-ietf-ipngwg-rfc2553bis-03.txt should specify what is the
> >correct behaviour for bind(2). i vote for the *BSD one: by having two
> >different sockets binding indipendently one from the other, we can
> >get rid of all the problems given by IPv4-mapped IPv6 address, and
> >ha
¡Hola!
>All of these have existing, _working_ IPv4 network implementation. No one
>is going to just completely replace ipv4 with ipv6 one nice afternoon.
>
> => I don't want to replace IPv4 by IPv6 next month, I want to get
> dual stacks as default ASAP. RFC 2553 is for dual stacks and
¡Hola!
> however, it's not so simple. in this way we have two indipendent protocol
> families AF_INET and AF_INET6 (i would define them orthogonal), so
> we should modify the behaviour of getaddrinfo.
No change to getaddrinfo is needed.
> in fact, when called with AI_PASSIVE flag set and AF_UNS
¡Hola!
> i have seen that many programmers find difficult the process of porting
> their apps to ipv6. i think that we should write a small informational
> document that explains how to write good ipv6-compliant code.
> itojun's "Implementing AF-indipendent apps" is a very good document.
> howeve
¡Hola!
> > for(n = 0; (n < MAX_AF) && res ; res = res->ai_next) {
> > listenfds[n] = socket(res->ai_family, res->ai_socktype,
> > res->ai_protocol);
> > if(listenfds[n] < 0)
> > continue; /* libc supports protocols that kernel don't */
> >
> > if(
¡Hola!
>duplication of code is (and - if we're not gonna change the API draft in a
>significant way - will always be) inevitable. there are MANY problems in
>handling both ipv6 and ipv4 (or better, ipv4-mapped) traffic with a single
>AF_INET6 socket, and most of them are related t
¡Hola!
> If you want to port in an IPv4 and IPv6 independent manner you will use
> the tools as currently specified. There is not protocol that will matter
> besides IPv4 and IPv6 for at least the next 10 years.
10 years? If we're thinking so short-term something is bad. And if in 10
years ther
>> we really need to convince random book authors to update their
>> programming examples, from gethostbyname() to getnameinfo()...
>how can you expect them do so, when there's so much difference between
>the behaviour of the various TCP/IPv6 stacks?
yes, that is the issue. i w
On Mon, 25 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote:
> ...however, those corrections do not affect the main stream of this
> discussion. We've fully, fully discussed this (in the apifolks list),
> and have seen so many different views, and, as a consequence, could
> not reach
1 - 100 of 134 matches
Mail list logo
