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
that was very useful
thank you.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Wed, 27 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote:
> The following is a summary of discussions about the semantics of
> sin6_scope_id (aka flat 32 vs 4+28 split issue) we have had in
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
I guess I would prefere a combination between B and C.
The thing that I like from (C) is the ability to specify
a scope (top 4 bits) with the unspecified address. This offers
some rather interesting flexibility that would be used in
more advanced applications. I haven't considered the implicati
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
The following is a summary of discussions about the semantics of
sin6_scope_id (aka flat 32 vs 4+28 split issue) we have had in the API
list. Since some of key members of this issue are (accidentally) not
on the list, I think this list is the best place to get a consensus.
Please note that the t
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
I am looking for IPv6 support in the "http://www.awfulhak.org/ppp.html";
user PPP which works on FreeBSD 4.x and OpenBSD 2.x (it seems to be
easy to port any system with a tun interface/device too).
[EMAIL PROTECTED]
IETF IPng W
> 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
> If possible, I'd like to see the next revision of the draft before the
> next IETF meeting in London. So my question is:
>
> does anyone (especially in the authors) try to revise the draft now?
I'd like to see the document finished. But I don't have any cycles
to actually drive the open issu
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
In your previous mail you wrote:
As an IPv6 stack/application programmer, I'd really like to fix the
advanced API. The current situation is really mess, because
rfc2292bis does not provide backward compatibility to the old RFC
2292, and some OSes has already shipped with rfc2292bis
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
48 matches
Mail list logo
