John Stracke wrote:
Jeroen Massar wrote:
Ad-hoc networks are another similar case, where two machines
are connected via ad-hoc wireless, bluetooth, firewire,
or similar.
In any other way do you like remembering and typing over 128bit
addresses?? :)
:: is your friend. If you're
In message [EMAIL PROTECTED], Keith Moore writes:
Then there's the problem that when a 800-pound gorilla ships code,
that code largely defines expectations for what will and will not
work in practice- often moreso than the standards themselves.
Strange as I feel defending Microsoft, I
Steve I can't get upset about Microsoft declining to ship poorly-tested
Steve code. Given how many security holes are due to buggy, poorly-tested
Steve programs, I applaud anyone who takes that seriously.
Well, suppose they were to ship IPv6 without IPsec, on the grounds that they
didn't
On 2 Apr 2003 at 18:10, Keith Moore wrote:
The lack of IPv6 literal address support in the version of wininet.dll
that shipped with Windows XP was for reasons of engineering
expediency,
in other words, MS deliberately shipped a broken product.
Oh, look, release notes, known issue
Michael Richardson wrote:
-BEGIN PGP SIGNED MESSAGE-
Bill == Bill Manning [EMAIL PROTECTED] writes:
Bill Are the apps for which IPv6 is enabled that -can not-
Bill use address literals? If so, then Steve is wrong and
yes.
Both IPv4 and IPv6 web browsers
Hi, Jeroen,
Are you talking about
ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)?
My quick read of this RFC is that it says don't use IPv6
literals without enclosing them in brackets, as in
host = hostname | IPv4address | IPv6reference
ipv6reference = [ IPv6address ]
Spencer Dawkins wrote:
Hi, Jeroen,
Are you talking about
ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)?
My quick read of this RFC is that it says don't use IPv6
literals without enclosing them in brackets, as in
host = hostname | IPv4address | IPv6reference
Jeroen Massar wrote:
... That's also why IE in XP doesn't support it.
Making claims that you know nothing about, only exposes your lack of
clue.
Tony
At 10:18 AM 4/2/2003, Jeroen Massar wrote:
Spencer Dawkins wrote:
Hi, Jeroen,
Are you talking about
ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)?
My quick read of this RFC is that it says don't use IPv6
literals without enclosing them in brackets, as in
host =
Tony Hain [mailto:[EMAIL PROTECTED] wrote:
Jeroen Massar wrote:
... That's also why IE in XP doesn't support it.
Making claims that you know nothing about, only exposes your lack of
clue.
Fortunatly I don't have to resolve to personal accusations
to get my point across. I cc:'d the
Jeroen Massar wrote:
Tony Hain [mailto:[EMAIL PROTECTED] wrote:
Jeroen Massar wrote:
... That's also why IE in XP doesn't support it.
Making claims that you know nothing about, only exposes
your lack of
clue.
Fortunatly I don't have to resolve to personal accusations
to get
% Are the apps for which IPv6 is enabled that -can not-
% use address literals? If so, then Steve is wrong and
% the DNS has become critical infrastructure to the working
% of the Internet.
%
% anyone who believes that the DNS is not critical infrastructure for just
% about
Keith Moore [mailto:[EMAIL PROTECTED] wrote:
There was some discussion about this deprecation as the
Techpreviews (Win2k/NT4) did support literal url's.
The XP version and up though won't support it to overcome
one major 'problem': website 'designers' embedding IP's
inside websites to
Keith Moore wrote:
Sounds like you both are arguing that the DNS has become
embedded and the applications that use IP are unusable
without a working DNS.
as a practical matter, this was true even in IPv4. yes, you can
often use address literals in either v4 or v6 apps,
From: Keith Moore [EMAIL PROTECTED]
actually it's bad to force all apps to use DNS names - which are often
less reliable, slower, less correct, and more ambiguous than IP
addresses.
This is like saying it's bad to force people to use cars/busses/whatever
because they
From: [EMAIL PROTECTED]
Effectively this could be resolved by having one globally
unique identifier per node.
Paging Noel Chiappa Paging Noel Chiappa ;)
Ah, one moment, if I may:
his books, he always said, contained the teachings of his master,
Socrates; ...
% Let's assume that there is a FooBar server in SiteA. If
% another node in SiteA (NodeA) is communicating via a
% multi-party application to a node in SiteB (NodeB), and wants
% to refer NodeB to the FooBar server in SiteA, what does it do?
%
% Send a name.
%
% Not all addresses
--On Monday, 31 March, 2003 09:01 -0800 Bill Manning
[EMAIL PROTECTED] wrote:
Is may be worth noting that RIRs have -NEVER- made
presumptionson routability of the delegations they make.
I believe that, although I remember some arguments within ARIN
back when I was on the AC about
-BEGIN PGP SIGNED MESSAGE-
Bill == Bill Manning [EMAIL PROTECTED] writes:
Bill Are the apps for which IPv6 is enabled that -can not-
Bill use address literals? If so, then Steve is wrong and
yes.
Both IPv4 and IPv6 web browsers behave differently if you do,
David,
let's not mix the problem with provider independent addressspace with
the SL issue. The first needs to be solved anyway, and SLs are not the
answer.
Best regards,
- kurtis -
What happens when you change providers?
Rgds,
-drc
On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie
Keith Moore wrote:
On Thu, 27 Mar 2003 15:31:23 -0500
John Stracke [EMAIL PROTECTED] wrote:
Besides, we have three such prefixes, given RFC-1918 and 6to4:
2002:A00::/24, 2002:AC10::/28, and 2002:C0A8::/32.
the same problems exist for these as for SLs.
Right.
we should deprecate these
Hi John,
But suppose we really do have enough address space (independent of routing
issues). In that context, is site local just a shortcut to avoid dealing
with a more general problem? Should we have a address allocation policy
that updates the policies of the 70s but ignores the
Bill Manning wrote:
Is may be worth noting that RIRs have -NEVER- made presumptions
on routability of the delegations they make.
Did you just say 69/8 ? :)
If an ISP chooses not to make a specific prefix reachable
it is there 'problem'/policy, not much to do about it.
Also
Which actually poses an interesting question: when should an application
just give up? IMHO, there is only one clear-cut case, i.e. when the
application actually contacted the peer and obtained an explicit
statement that the planned exchange should not take place -- the
equivalent of a 4XX or
Christian Huitema wrote:
Well, that is emphatically *NOT* what application developers
do. They do not just observe that it does not work, they try
to work around, e.g. routing messages to a different address,
at a different time, through a third party, or through a
different protocol.
From: Christian Huitema [EMAIL PROTECTED]
...
Well, that is emphatically *NOT* what application developers do.
Speak for yourself.
Which actually poses an interesting question: when should an application
just give up? IMHO, there is only one clear-cut case, i.e. when the
application
On Mon, 31 Mar 2003 12:17:44 PST, Eliot Lear said:
Right up till the point where two companies start communicating with one
another directly with site-locals. Even if there is a router frob to
keep the scopes scoped, you can bet it won't be used until someone
realizes that the above
Hi Tony,
At 11:51 AM 3/31/2003 -0800, Tony Hain wrote:
Margaret Wasserman wrote:
Of course, in the case of site-local addresses, you don't
know for sure that you reached the _correct_ peer, unless you
know for sure that the node you want to reach is in your
site.
Since the address block is
Let's assume that there is a FooBar server in SiteA. If another
node in SiteA (NodeA) is communicating via a multi-party application
to a node in SiteB (NodeB), and wants to refer NodeB to the FooBar
server in SiteA, what does it do?
I thought we agreed, completely outside of IPv6 concerns,
Eliot Lear wrote:
Right up till the point where two companies start communicating
with one another directly with site-locals.
No, no, no. That's exactly what we don't want site-locals to do.
Site-locals are not to communicate outside their own site, period.
Michel.
Margaret Wasserman wrote:
I believe that you have misunderstood my point... I'll try
to explain further, although our friends in the applications
area may be able to give better examples.
Let's assume that there is a FooBar server in SiteA. If
another node in SiteA (NodeA) is
On Tue, 01 Apr 2003 00:23:15 +0200, Jeroen Massar said:
Effectively this could be resolved by having one globally
unique identifier per node. The underlying protocols should
Paging Noel Chiappa Paging Noel Chiappa ;)
pgp0.pgp
Description: PGP signature
Tony Hain wrote:
Margaret Wasserman wrote:
I believe that you have misunderstood my point... I'll try
to explain further, although our friends in the applications
area may be able to give better examples.
Let's assume that there is a FooBar server in SiteA. If
another node in
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote:
On Tue, 01 Apr 2003 00:23:15 +0200, Jeroen Massar said:
Effectively this could be resolved by having one globally
unique identifier per node. The underlying protocols should
Paging Noel Chiappa Paging Noel Chiappa ;)
Based on
On Monday, March 31, 2003, at 05:30 PM, Tony Hain wrote:
Let's assume that there is a FooBar server in SiteA. If
another node in SiteA (NodeA) is communicating via a
multi-party application to a node in SiteB (NodeB), and wants
to refer NodeB to the FooBar server in SiteA, what does it do?
Send
Margaret,
Margaret Wasserman wrote:
(2) Institutionalizing the need for split DNS. I understand
that some network administrators choose to use split DNS
today, but that doesn't meant that we want to build a
requirement for split DNS it into the IPv6 architecture.
I don't think
Margaret Wasserman wrote:
Of course, in the case of site-local addresses, you don't
know for sure that you reached the _correct_ peer, unless you
know for sure that the node you want to reach is in your
site.
Since the address block is ambiguous, routing will assure that if you
reach a
Thus spake Eliot Lear [EMAIL PROTECTED]
Right up till the point where two companies start communicating with
one another directly with site-locals. Even if there is a router frob to
keep the scopes scoped, you can bet it won't be used until someone
realizes that the above problem occurred.
Keith Moore wrote:
Well, that is emphatically *NOT* what application developers
do. They do not just observe that it does not work, they try
to work around, e.g. routing messages to a different address,
at a different time, through a third party, or through a
different protocol.
All right, how do you make internal site communications completely
oblivious to a change in your externally-visible routing prefix?
You declare that any app that keeps connections around for more than
some time period T (say for 30 days) have a mechanism for
detecting and recovering from
Keith Moore [mailto:[EMAIL PROTECTED] wrote:
Indeed, correctly coded applications will use a getaddrinfo()
and then a connect() in a loop until succesful.
it's perfectly reasonable to connect to an address without first
doing a DNS lookup.
I think nobody can't help you if
Applications will have to deal with that, yet there is no hint
unless we provide a well-known flag.
applications cannot be expected to deal with filters in any way other
than
to report that the communication is prohibited. the well known flag
exists and is called ICMP.
Well, that is
Eliot,
Eliot Lear wrote:
What you say is possible, and has happened. But dumb
things happen. Those dumb things could happen with non
site-local addresses as well.
More limited, that's the point. Not perfect, but better than unregulated
anarchy. However, between a network design that does not
On Thu, Mar 27, 2003 at 05:48:44PM -0800, Christian Huitema wrote:
My Windows-XP laptop currently has 14 IPv6 addresses, and 2 IPv4
addresses. The sky is not falling.
Except of those 14 some seven(?) are RFC3041 addresses, which break a
number of applications... so there are some clouds in
I suspect that most people there, who voted for
the elimination ...
At my first IETF meeting I received a T-Shirt, courtesy of Marshall
Rose, I believe, that said We reject kings, presidents and voting...
The real tragicomedy of this situation is that someone considered it
fitting and proper
Margaret Wasserman wrote:
As you know, I was in favor of setting aside a prefix (FECO::, in fact)
for use as private address space (either on disconnected networks, or
behind NATs), but the consensus of the folks in the IPv6 WG meeting
was to deprecate that prefix altogether. There were several
On Thu, Mar 27, 2003 at 06:46:10PM -0500, Keith Moore wrote:
No, it's more than that. SLs impose burdens on hosts and apps.
SLs break the separation of function between apps and the network that
is inherent in the end-to-end principle.
Is it safe to assume that the arguments (on either side)
On Fri, 28 Mar 2003 14:00:31 EST, David R. Oran said:
Did anybody consider just handing out a /48 (or a bit smaller)
automagically with each DNS registration?
Routing Table Bloat. If you can figure out how to do this in a CIDR
aggregation context, or otherwise work around the table problem,
layers above it and a dangerous blow to the hour glass model.
Looking at what is going on in the IETF, I think we are talking about
first aid rather than trying to prevent the blow as such. That happened
along time ago...:-(
But yes, we need to protect the architectural model or discuss a new
Because such thing does not exist, it's called PI and is not available
to IPv6 end-sites. And if it ever is, it will cost money or other
annoyances to obtain.
SLs won't come for free either. Architecture aside, I prefer people
that use a service to pay for it rather than the community as such.
To echo the favorable review of Steve's presentation: It's at
http://www.ietf.org/proceedings/01aug/slides/plenary-1/index.html,
and is well worth the few minutes it takes to read/re-read...
Spencer
--- Kurt Erik Lindqvist [EMAIL PROTECTED] wrote:
Steve Deering made a wonderful presentation
David R. Oran wrote:
Did anybody consider just handing out a /48 (or a bit smaller)
automagically with each DNS registration?
I proposed a couple of times a /32 from which /48 can be requested
for 'private' (never to be connected to the internet) purposes.
I think some others have proposed a
John C Klensin wrote:
(ii) ISPs impose restrictions on their customers all the time
and often even enforce them. Many of us consider some of these
to be desirable (e.g., terms and conditions prohibiting
spamming) and others less so (e.g., prohibitions against running
server or peer-peer
John C Klensin wrote:
... but I am unconvinced that we should make special
architectural provisions to make it easier to be in the ISP
business while being clueless.
Isn't that just what we did with MPLS?? ;)
or does that just prove your point? ;))
My arguments are more about
John,
John C Klensin wrote:
We, or more specifically, the upstream ISP or an RIR, can
tell the ISP that things will go badly for them if they
permit un-routable addresses to leak into the public
Internet. The only difference I can see between what I
think is your SL address preference and
John, mixed bag of nasties here. Routing, addressing, and (of course)
the DNS. More fun than should be legal on a friday afternoon.
Routing: there is a varient here. Think about routing table slots.
If I get one, does it matter what the length of the prefix that I
put in it? There are
% David R. Oran wrote:
%
% Did anybody consider just handing out a /48 (or a bit smaller)
% automagically with each DNS registration?
%
% I proposed a couple of times a /32 from which /48 can be requested
% for 'private' (never to be connected to the internet) purposes.
% I think some others
Bill Manning [mailto:[EMAIL PROTECTED] wrote:
% David R. Oran wrote:
%
% Did anybody consider just handing out a /48 (or a bit smaller)
% automagically with each DNS registration?
%
% I proposed a couple of times a /32 from which /48 can be requested
% for 'private' (never to be
On Thu, 27 Mar 2003 18:29:22 -0600
John Kristoff [EMAIL PROTECTED] wrote:
On Thu, Mar 27, 2003 at 06:46:10PM -0500, Keith Moore wrote:
No, it's more than that. SLs impose burdens on hosts and apps.
SLs break the separation of function between apps and the network
that is inherent in the
Daniel Senie wrote:
SNIP
No. It does not imply NAT. It implies traffic to hosts which
are used for purposes which do not communicate to the public
network.
Could we PLEASE leave NAT out of the equation? Not all hosts
in the world want or need to be connected outside of the
corporate
Could we PLEASE leave NAT out of the equation? Not all hosts in the
world want or need to be connected outside of the corporate network
they belong to.
true. but they still need unique addresses.
Its not that 'we don't want to change because its to much work'. Its
that the Internet architecture assured us that the hour glass model
applied, that the network topology would remain abstracted within what
to us is an opaque address space. One of the number one reasons its so
easy for new
Yes, there was mention of site local as a license to NAT, but
there where many other arguments: leakage through IP, DNS or
application; the lack of practicality of several restrictive models
for site locals; the possibility or not to use other solutions for
isolated sites; and the complexity
This is so typical of the modern IETF -- 102 people were persuaded
by handwaving arguments that something bad might happen if a new
and useful technique were deployed, and they are being allowed to
overwhelm the 20 who were willing to dig in and find and solve any
real problems.
Well Matt,
On Thu, Mar 27, 2003 at 06:51:01PM -0500, Keith Moore wrote:
I suspect that most people there, who voted for
the elimination of site-locals, would still be
favor of enabling the features that site-locals
were intended to offer. Perhaps the majority
position could be paraphrased as
At 03:49 PM 3/27/2003 -0800, Tony Hain wrote:
Margaret Wasserman wrote:
No active IPv6 WG participant (whether or not he attends IETF
meetings) could credibly claim that he was unaware that this
discussion was taking place,
The discussion has been about potential usage limitation, or BCP's
Margaret Wasserman wrote:
There have been people calling for the complete removal of
site-local addressing all along.
And, elimination/deprecation was quite clearly raised as an
option in Atlanta. At that time, we called for opinions on
the following
options: elimination, limited,
Hi Tony,
I am not sure what your point is exactly, or why you want to make
this point on the full IETF list...
Are you suggesting that the options open to the IPv6 WG should
be constrained by the drafts that Bob and I list on the agenda?
By Thursday, the agenda had actually changed to a joint
Ted,
Ted Hardie wrote:
I think we then to consider whether the current need
is for: non-routed globally unique space or for
something else. If the answer is non-routed globally
unique space, then the follow-on question is Why not
get globally unique space and simply decide not to
route
Michel,
What you say is possible, and has happened. But dumb things happen.
Those dumb things could happen with non site-local addresses as well.
But look. Ultimately I think we as a community do need to own up to
better tooling, which can lead to better expectations. Also, I don't
see any
This is so typical of the modern IETF -- 102 people were persuaded
by handwaving arguments that something bad might happen if a new
and useful technique were deployed, and they are being allowed to
overwhelm the 20 who were willing to dig in and find and solve any
real problems.
uh, no. 102
Hello folks,
I was there, and it wasn't so black and white.
It's not fair to characterize it so.
I suspect that most people there, who voted for
the elimination of site-locals, would still be
favor of enabling the features that site-locals
were intended to offer. Perhaps the majority
position
You are mixing cause and effect. In IPv4 the vast majority of nodes
are limited to a single address at a time.
Well, I don't know about windows boxes, but real operating systems have
supported virtual hosting in IPv4 for many years. Having multiple
addresses on a node, even a node with a
You are mixing cause and effect. In IPv4 the vast majority of nodes
are limited to a single address at a time.
Well, I don't know about windows boxes, but real operating systems
have
supported virtual hosting in IPv4 for many years. Having multiple
addresses on a node, even a node with
And in Atlanta we all agreed to take elimination off the list, and it
has not been discussed since.
what's changed is that we had a chance to look at various ways of limiting
usage of SL, and found that none of them would make SLs tolerable.
As a side-note, a fifth SL option was presented out of the blue in SFO,
namely exclusive SL/global addressing (one or the other only), which,
because it was rather a broken idea, I think perhaps added to the room
sentiment that site-locals are broken (rightly or wrongly :)
well, it was
Ted Hardie wrote:
There is a long and interesting history here, but it isn't
directly
relevant
to this discussion. I think it would be valuable to focus the
discussion on Site Local,
rather than on RFC 1918 space.
The reason for bring 1918 into the discussion is that prior to NAT,
On Wed, 2003-03-26 at 16:38, Tony Hain wrote:
Ted Hardie wrote:
I think you may underestimate how much trouble this might cause in
applications.
As Dave Crocker noted in response to Margaret Wasserman's
presentation to the APPs Open Area meeting, applications have
been designed so
At 1:38 PM -0800 3/26/03, Tony Hain wrote:
I am not arguing that every app need to know about topology. If this is
such a big deal, we should simply fix the API so that by default it only
returns global scope addresses, then add a new function for those apps
that are interested in the limited
Michael Mealling wrote:
Its not that 'we don't want to change because its to much
work'. Its that the Internet architecture assured us that the
hour glass model applied, that the network topology would
remain abstracted within what to us is an opaque address
space. One of the number one
On Wednesday, March 26, 2003, at 01:38 PM, Tony Hain wrote:
Ted Hardie wrote:
There is a long and interesting history here, but it isn't
directly
relevant
to this discussion. I think it would be valuable to focus the
discussion on Site Local,
rather than on RFC 1918 space.
The reason for bring
Ted Hardie wrote:
I think we then to consider whether the current need
is for: non-routed globally unique space or for
something else. If the answer is non-routed globally
unique space, then the follow-on question is Why not
get globally unique space and simply decide not to
route it?.
Michel,
I don't think something needs to be provider independent
to fit this bill. Getting a slice of the global address space from
some provider and choosing not route a portion of it (even
if that portion is 100%) seems to me to create non-routed
globally unique space. Are you concerned that
Ted,
What happens when you change providers?
Rgds,
-drc
On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote:
Michel,
I don't think something needs to be provider independent
to fit this bill. Getting a slice of the global address space from
some provider and choosing not route a
Hi David,
Provider of what? Note that if a provider of address space is not
routing the addresses involved, they have few or no performance
responsibilities in the arena. They don't even need to polish and
regrind
the digits periodically; they just go. It seems unlikely to me
personally that
John C Klensin wrote:
...
For most of the cut section, consider that while 'good practice' says to
use names, reality is that too many apps still grab the address for
random reasons.
But, obviously, I'm not understanding something. Could you
explain?
There is a lot of noise about treating
On Wednesday, March 26, 2003, at 05:40 PM, David Conrad wrote:
Ted,
On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote:
If you were using some of an allocated portion as routable addresses
and some as unrouted addresses, you might be forced to change the
unrouted addresses as a
Or what if there is no provider (as in default addresses used by a
software vendor)?
-andy
David Conrad wrote:
Ted,
What happens when you change providers?
Rgds,
-drc
On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote:
Michel,
I don't think something needs to be provider
From the reading of the draft, it would appear that much of the pain
for applications with SL is caused because the apps violated the contract.
Actually, its a wonder any of these would work in v6 at all given the
description of the problem (address leaks).
-andy
Michael Mealling wrote:
Its
At 08:40 PM 3/26/2003, David Conrad wrote:
Ted,
On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote:
If you were using some of an allocated portion as routable addresses
and some as unrouted addresses, you might be forced to change the
unrouted addresses as a consequences of
Tony,
The specifics of the site local issue should be debated on the IPv6 WG
list, not on the global IETF list. Let me however respond to your point
regarding the quality of the debate, as I was the note taker during that
session.
My notes record that 22 separate speakers took part to this
Thus spake Christian Huitema [EMAIL PROTECTED]
The specifics of the site local issue should be debated on the IPv6 WG
list, not on the global IETF list. Let me however respond to your point
regarding the quality of the debate, as I was the note taker during that
session.
Issues most often
--On onsdag, mars 26, 2003 17:40:23 -0800 David Conrad
[EMAIL PROTECTED] wrote:
Ted,
On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote:
If you were using some of an allocated portion as routable addresses
and some as unrouted addresses, you might be forced to change the
The reason for bring 1918 into the discussion is that prior to NAT,
there was a market demand for private address space.
sometimes the market is misled by vendors who want to sell planned
obsolesence. NAT is the perfect example.
since it is in fact the violation of
the layering by the apps that has created some of the mobility and
renumbering challenges.
uh, no. DNS is not a layer. it is a naming service. it's not the
only way that an app can get an IP address, and never has been.
Ignoring the format of addresses has worked well for 1918 addresses
(loathsome as they might be) because the assumption is that filtering
(so that they don't leak onto the public network) is the
responsibility of anything that connects a 1918 network to the public
Internet.
but this assumption
There is a lot of noise about treating SL special, but as you note an
application can ignore that a 1918 address is somehow different from
any
other address. If an application were to do the same and just use a SL
as any other address, it will work just fine until one of the
participants is on
97 matches
Mail list logo
