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
Hello,
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 while some
other OSes still keep RFC 22
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
On Sun, 24 Jun 2001, Francis Dupont wrote:
> In your previous mail you wrote:
>
>> => no, there are some codes which are written without switches.
>
>of course there are. RFC 2553 has been written in order to minimize the
>need for those switches.
>
>> Of course they work only on
On Sun, 24 Jun 2001, Francis Dupont 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 real prob
On Sun, 24 Jun 2001 [EMAIL PROTECTED] wrote:
> >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.
>
> we really need to convince r
On Sun, 24 Jun 2001, Jim Bound wrote:
> What programmers in what organizations are you talking about?
i will not name any software here. for you, it will be enough to say
that i have seen a lot of not-very-well-ported opensource software.
--
Aequam memento rebus in arduis servare mentem...
Ma
> > All of this would be *much* simpler if the advanced API only allowed
> > IPV6_HOPLIMIT to be specified as ancillary data and required the use of
> > IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for setsockopt() and
> > getsockopt() calls.
Strongly agree on this. Keep it simple!
--
> On Tue, 19 Jun 2001 09:32:31 -0400,
> "Roy Brabson" <[EMAIL PROTECTED]> said:
> I actually went back and read the existing RFC2292 - probably
> something I should have done originally - and I think I have
> a handle on this. Based on the current RFC and the -02 draft
> my interpretati
Hi,
I have a doubt regarding the way UDP works in IPv6. It
would be of
great help if someone could throw some light on it.
In IPv6 only the source node and the
Destination handle fragementation of
the packet, if required. No routers on the way fragement as was done in
IPv4.
I g
> On Sun, 10 Jun 2001 15:11:35 -0400,
> "Lori Napoli" <[EMAIL PROTECTED]> said:
> I should have been more specific with my question. I agree the ancillary
> data will override the setsockopt. I was really asking what happens if an
> application does a setsockopt for IPV6_UNICAST_HOPS a
39 matches
Mail list logo
