On Wed, Sep 19, 2007 at 11:29:34PM +0100, Jeroen Massar wrote:
Stephane Bortzmeyer wrote:
On Wed, Sep 19, 2007 at 12:50:44AM +,
Paul Vixie [EMAIL PROTECTED] wrote
a message of 32 lines which said:
in the IETF, the naysayers pretty much kick the consenting adults'
asses every
But this is just an instance of the general case that some
source-destination address pairs work better than others.
Address selection heuristics don't do a good job solving this
problem - to solve this problem the network actually needs to tell
the host which source-destination address
Paul Hoffman wrote:
Why the IETF? Why not ISOC, an organization that has expertise and
experience is asking such questions? ISOC already has local chapters
throughout the world, ISOC has a friendly membership policy, and ISOC
has good relations with the IETF for discussing proposed
Keith Moore wrote:
In my vision the /48s being given out as PI today can be used for the
ID portion, while every transit will give a location /48 to the site
that needs it. Over the DFZ the src/dst will be in DFZ/location style,
but when it arrives at the endsite it will be in PI mode again.
Iljitsch van Beijnum wrote:
On 19-sep-2007, at 0:10, Keith Moore wrote:
What bugs me is that I think that the existence of mini-cores (or more
generally, a large number of private interconnections between networks
using ULA prefixes) leads to a world where it becomes important to have
a
On 19-sep-2007, at 0:10, Keith Moore wrote:
What bugs me is that I think that the existence of mini-cores (or more
generally, a large number of private interconnections between networks
using ULA prefixes) leads to a world where it becomes important to
have
a particular kind of source
And if the addresses used at the host are unique, it gets rid of many
of the problems caused by overlapping use of RFC 1918 addresses in IPv4.
There's still some issues related to traceability of traffic over the
network, but maybe those are manageable.
The source and destination
On 20-sep-2007, at 14:32, Keith Moore wrote:
If applications don't want to worry about addressing issues, the only
solution is that applications don't get to see addresses in the first
place.
If you can find a good way to let hosts and network stacks sort out
those addressing issues, then
If you can find a good way to let hosts and network stacks sort out
those addressing issues, then fewer applications will bother to manage
those addresses themselves. But absent such a way to do that (and
trial-and-error is not a good way, nor is IPv6 address selection) then
more
On 20-sep-2007, at 14:52, Keith Moore wrote:
Well, a start would be a connectbyname() API call that takes
care of
name-to-address mapping and trying different addresses until one
works.
Most IPv6-capable apps seem to implement that logic now. And in my
experience, it sucks. Really hard.
Downloading over IPv6 is still almost always slower than over
IPv4, but for day-to-day stuff the performance difference
isn't an issue with native IPv6 connectivity (for me). 6to4
is a crapshoot, it can be reasonable or it can completely
fail, with everything in between.
That will
As mentioned above PI blocks can be used for this. As such organizations
who can convince all ISPs in the DFZ that they are important enough to have
their own routing slot can cough up the dough and be there, others will just
have to do with this mechanism to get around.
by what method do you
As the original blog poster, let me answer and expand a bit:
Jeroen Massar wrote:
What is defined as an 'end-user'?
You, me, the rest of the people, are all end-users IMHO.
From those one billion Internet users, there are several millions IT
professionals who do not participate in the IETF
Well, a start would be a connectbyname() API call that takes care of
name-to-address mapping and trying different addresses until one works.
Most IPv6-capable apps seem to implement that logic now. And in my
experience, it sucks. Really hard. The app can take a very long time
to
Well, a start would be a connectbyname() API call that takes care
of name-to-address mapping and trying different addresses until one
works.
Something like WSAConnectByName?
From http://msdn2.microsoft.com/en-us/library/ms741557.aspx: The
WSAConnectByName function establishes a connection to
Over the last ten years, I explained a zillion times to my
management, workmates, etc. why e-mail addresses cannot
contain accented characters, only to be asked when the IT
department of the organization is going to fix it. This is
the archetypical example of an issue that has been known
On 20-sep-2007, at 16:52, Keith Moore wrote:
6to4 is a crapshoot, it can be
reasonable or it can completely fail, with everything in between. But
it's never going to be better than native IPv4, obviously.
No, not obviously - because if the application has a need to do
address
referral then
Daniel Senie wrote:
At 04:18 AM 9/20/2007, you wrote:
Interesting discussion.
I am envolved in two groups develloping around OpenWRT.
One group (some 2000 members) is trying to TORify a dollar 150 router
the other group (some 30 members) is trying to IPv6 that very same
software. I dont
Daniel Senie wrote:
At 04:18 AM 9/20/2007, you wrote:
Interesting discussion.
I am envolved in two groups develloping around OpenWRT.
One group (some 2000 members) is trying to TORify a dollar 150 router
the other group (some 30 members) is trying to IPv6 that very same
software. I dont
On Sep 20, 2007, at 6:29 PM, Peter Dambier wrote:
Daniel Senie wrote:
At 04:18 AM 9/20/2007, you wrote:
Interesting discussion.
I am envolved in two groups develloping around OpenWRT.
One group (some 2000 members) is trying to TORify a dollar 150
router
the other group (some 30 members)
At 4:24 PM +0200 9/20/07, Patrick Vande Walle wrote:
My proposal for the IETF would be to ask the actual users, large and
small, through different mechanisms to be defined, what are the issues
that limit their use of the Internet, see what is relevant to the IETF
work and assign priorities to
Thus spake Paul Vixie [EMAIL PROTECTED]
As mentioned above PI blocks can be used for this. As such
organizations
who can convince all ISPs in the DFZ that they are important enough to
have
their own routing slot can cough up the dough and be there, others will
just
have to do with this
absent such a method, the network operators who dominate the bottom-up RIR
policy process are almost certainly going to make PI hard to qualify for.
In the ARIN region, one can qualify for PI today with as few as 256 hosts,
and there was a recent proposal that would have indirectly dropped
6to4 is a crapshoot, it can be reasonable or it can completely fail,
with everything in between. But it's never going to be better than
native IPv4, obviously.
No, not obviously - because if the application has a need to do
address referral then there are conditions in which the 6to4 address
On Thu, Sep 20, 2007 at 04:13:01PM +0100,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote
a message of 49 lines which said:
In fact, it may be necessary to attach a language tag (defined in
RFC 4646 and 4647) to these addresses in order to make this fully
possible.
That would be a very bad idea.
How about
http://xn--8pru44h.xn--55qx5d/
and their email can be found:
; DiG 9.4.0b4 -t any xn--8pru44h.xn--55qx5d @ns5.ce.net.cn.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 59227
;; flags: qr aa rd; QUERY: 1, ANSWER: 4,
Thus spake Keith Moore [EMAIL PROTECTED]
Well, a start would be a connectbyname() API call that takes
care of name-to-address mapping and trying different
addresses until one works.
Most IPv6-capable apps seem to implement that logic now. And
in my experience, it sucks. Really hard. The
Paul Vixie wrote:
without a consensus on what it means to harm, we're sort of stuck. ULA-G
(and therefore ULA-C) would allow consenting adults to exchange routes using
the whois and in-addr infrastructure that has historically been reserved for
public networking.
Without going into debate
On Wed, Sep 19, 2007 at 12:50:44AM +,
Paul Vixie [EMAIL PROTECTED] wrote
a message of 32 lines which said:
in the IETF, the naysayers pretty much kick the consenting adults'
asses every day and twice on sunday. and that's the real problem
here, i finally think.
Time to have a formal
At 10:11 PM +0200 9/19/07, Stephane Bortzmeyer wrote:
Time to have a formal representation of end-users at the IETF?
http://patrick.vande-walle.eu/internet/how-can-the-engineering-community-and-the-users-meet/
(My personal worry about this proposal is that there is zero
organisation of
Stephane Bortzmeyer wrote:
On Wed, Sep 19, 2007 at 12:50:44AM +,
Paul Vixie [EMAIL PROTECTED] wrote
a message of 32 lines which said:
in the IETF, the naysayers pretty much kick the consenting adults'
asses every day and twice on sunday. and that's the real problem
here, i finally
Without going into debate about consenting adults, and while I might
disagree with Paul in certain fine points, I'd suggest that we consider the
ULA-G proposal within the IETF and ask that Paul submit it as an I-D. ULA-G
could have broad application if in fact we solve the multihoming problem
I think this largely depends on what is defined as an end-user. The
reason the ALAC is failure is that there is a complete mismatch
between the stuff ICANN does and what these end users THINK ICANN
does or should be doing.
The ALAC members are largely made up of civil society or political
Paul Vixie wrote:
Without going into debate about consenting adults, and while I might
disagree with Paul in certain fine points, I'd suggest that we consider the
ULA-G proposal within the IETF and ask that Paul submit it as an I-D. ULA-G
could have broad application if in fact we solve the
I'd be careful about using the ICANN/ALAC example as proving much of
anything other than if a group wishes to set up some window-dressing so it
can say users are consulted, and ensures that the users have no particular
influence in the group's activities (compared to every other represented
My very first contribution to this mailing list - pardon me, I am
nervous :-) .
I agree with suggestion that it would make more sense to improve
linkages to the OPERATOR community (e.g.NANOG) as opposed to the end-user.
I follow the discussions on this forum but admit that although
In my vision the /48s being given out as PI today can be used for the
ID portion, while every transit will give a location /48 to the site
that needs it. Over the DFZ the src/dst will be in DFZ/location style,
but when it arrives at the endsite it will be in PI mode again. NAT
(that evil
Paul Vixie wrote:
i realized in that moment, that ULA-G (and therefore ULA-C) is not an
end run around PI space, it's an end run around the DFZ. some day, the
people who are then responsible for global address policy and global
internet operations, will end the tyranny of the core by which we
Mumble. It's hard for me to buy the idea of there not being a core
portion of the Internet from which all public addresses are reachable.
i was going to say, but these addresses aren't public, but then i saw the
larger problem, which is that the internet's architecture has guardians who
are
Paul Vixie wrote:
Mumble. It's hard for me to buy the idea of there not being a core
portion of the Internet from which all public addresses are reachable.
i was going to say, but these addresses aren't public, but then i saw the
larger problem, which is that the internet's
it certainly is a problem. and yet failure to provide direction seems
to cause even more problems.
providing leadership is different from providing direction. it includes
things like unsolicited positive vision and innovation, and willingness toward
constructive criticism and guidance when
41 matches
Mail list logo
