Iljitsch van Beijnum wrote:
The basic assumption in byzantine robustness is that as long as the
number of dishonest participants do not exceed a treshold ratio
(e.g. one third of all participants), the system does not fail.
Ok, I'm going to read up on this stuff but in the mean time: it's pretty
On donderdag, sep 11, 2003, at 08:22 Europe/Amsterdam, Pekka Nikander
wrote:
[DHT dangers]
I do understand your view. But I don't share it. I am sure
someone will sooner or later produce a statistical analysis
that can be used to quantify the danger.
Ok there is much more to say about this
Honest. I'm really sorry to have to send this query.
In looking over various archives and documents, on the matter of
separating node address from node identifier, I have not been able to
find or develop a clear summary of the reasons the identifier cannot
be a domain name.
I've grown
Pekka Savola wrote:
Incorrect. Have you even used hosts.allow? What makes you
think it's easily hackable, instantly abusable by a vaguely
clued low-level thief?
Gee, even I could use vi. As soon as you have root access, what is your
problem? I can vi the hosts.allow file, I don't know how
On Thu, 11 Sep 2003, Michel Py wrote:
Pekka Savola wrote:
Incorrect. Have you even used hosts.allow? What makes you
think it's easily hackable, instantly abusable by a vaguely
clued low-level thief?
Gee, even I could use vi. As soon as you have root access, what is your
problem? I
Pekka Savola wrote:
Then you have to first compromise the system concerned, going
through all the other protections.
Before you hack the box to circumvent the hosts.allow you still have
to ... well, hack the box! An interesting chicken and egg problem, no?
Never heard of a joe-job from the
On woensdag, sep 10, 2003, at 08:52 Europe/Amsterdam, Dave Crocker
wrote:
In looking over various archives and documents, on the matter of
separating node address from node identifier, I have not been able to
find or develop a clear summary of the reasons the identifier cannot
be a domain
Dave,
If you are looking for stable identifiers for stacks (in the
terminolgy of draft-irtf-nsrg-report-09.txt) it seems unlikely
that an FQDN is a safe answer. FQDNs are (mis)used in many ways;
a name like www.example.com certainly doesn't identify a given IP stack
on a given interface on a
Iljitsch van Beijnum wrote:
The discussion about draft-ietf-ipv6-unique-local-addr-00.txt bothers
me.
First of all, what are we talking about here? I see two needs:
a) the need for stable addresses
b) the need for private addresses
Let's first discuss a). The draft says that unique
Alain Durand wrote:
This recent thread is stressing the fact that what is really needed is
easy access
to stable address space.
Getting this address space from an ISP, a LIR or a RIR is just a minor
variation.
The point is that this can be solved by policy and does not require to
put
Iljitsch,
... I also think that we need
some way of representing those end-point identifiers as 128- or
even 32-bit value, to be used in legacy APIs and withing the stack...
So the 128/32 bit representation wouldn't _be_ the identifier but only
a representation?
Yes. See
On woensdag, sep 10, 2003, at 14:29 Europe/Amsterdam, Brian E Carpenter
wrote:
Consider the
situation where two organizations with their own ULA space merge.
Hosts
continue to have ULAs as before, but now there is a second range of
ULA
space that is reachable. But how does the DNS for
Pekka,
Iljitsch van Beijnum wrote:
Are you saying that we should make a clear distinction
between identifiers and locators, and not have any values
that are valid in both realms?
Pekka Nikander wrote:
Yes, in the long run.
Would that include going to identifiers that are longer than 128
Brian E Carpenter wrote:
There is no defence against misconfigured routers, except
for well configured routers elsewhere.
Pekka Savola wrote:
For example, for some services I maintain, I have:
- TCP wrappers configuration in the host/service itself,
using /etc/hosts.allow
- The local
going back to the Saltzer paper, where in the topology is the IPaddress
and who is the name of the entity... so if there is an entity at a
point in the topology, then the name maps nicely into the DNS.
if not... then we have a problem.
--bill
Opinions expressed may not even be mine by
But I have not seen a clear summary of what will be made better nor a clear
argument against using domain names, as the stable, public,
address-independent end-point identifier.
Dave,
I haven't seen such a list either.
It might be useful to split your question apart into two questions:
1.
Erik,
You listed out some of the trade-offs. The one you only inferred and
I'll be more explict about is that doing it once correctly has a benefit
of not all UDP-based applications having to reinvent the wheel (and
probably inconsistently).
Gee. I think I said this before somewhere.
Eliot
Pekka,
On woensdag, sep 10, 2003, at 15:00 Europe/Amsterdam, Pekka Nikander
wrote:
Ok, not sure what you mean by byzantineously robust exactly and
maybe I've missed a few of those papers, but so far nobody has been
able to explain to me how you can build a DHT system using
untrustworthy
Hi Pekka,
On dinsdag, sep 9, 2003, at 10:16 Europe/Amsterdam, Pekka Nikander
wrote:
The trouble isn't that IP addresses don't make for good end-point
identifiers or that they don't make for good topology/interface
identifiers, but that they can't do both at the same time.
Well, almost but
Alan,
You raised very good points. Sorry for delay. I'll try to respond to a
few old threads I had to drop for a while due to other work..
On Fri, 29 Aug 2003, Alan E. Beard wrote:
On Thu, 28 Aug 2003, Geoff Huston wrote:
[...]
The likelihood of conflict exceeds 0.5 after only 1.24
Pekka,
There is no defence against misconfigured routers, except for well
configured routers elsewhere. I bet there are routers today capable
of announcing FEC0::/10 in BGP4+ if a user tells them to do so.
Whatever we define, misconfiguration (at the factory or by the user)
will occur. So I
Pekka Savola wrote:
...
Sure, but there are also other ways to obtain addresses.
Really? Would you care naming one available today?
a) talk to your ISP (or one of its upstreams), which his hopefully a LIR,
or
b) talk to any LIR, and pay him e.g. 100$/mo. He'll gladly give you
If I get a
/48 from ISP A, and want to use it in private mode to set up VPNs
to business partners who have their public connectivity from ISPs A, B
and C, this /48 is going to cause various forms of head scratching
for the operations people at all those business partners, and if it
leaks,
On Mon, 8 Sep 2003, Brian E Carpenter wrote:
Pekka Savola wrote:
...
Sure, but there are also other ways to obtain addresses.
Really? Would you care naming one available today?
a) talk to your ISP (or one of its upstreams), which his hopefully a LIR,
or
b) talk to any
-BEGIN PGP SIGNED MESSAGE-
Michel Py wrote:
Pekka Savola wrote:
Sure, but there are also other ways to obtain addresses.
Michel Py wrote:
Really? Would you care naming one available today?
a) talk to your ISP (or one of its upstreams), which his
hopefully a LIR, or b)
On Mon, 8 Sep 2003, Brian E Carpenter wrote:
There is no defence against misconfigured routers, except for well
configured routers elsewhere.
Sure.. be sure to implement filtering at multiple levels, and by different
set of folks so the chance of mistakes is minimized.
For example, for some
-BEGIN PGP SIGNED MESSAGE-
Pekka Savola wrote:
ISP A, on the other hand, knows that the prefix is non-routed. If someone
asks, they can tell as much. Or even register it in RIR DB as an
unnumbered non-routed customer (if they don't want to reveal more
information on that) .. no
Comments below the two excerpts:
--On Monday, September 08, 2003 23:42 +0200 Iljitsch van Beijnum
[EMAIL PROTECTED] wrote:
Let's first discuss a). The draft says that unique local addresses (ULAs)
must not show up the global/public DNS so two-faced DNS must be used for
these addresses. But how
This recent thread is stressing the fact that what is really needed is
easy access
to stable address space.
Getting this address space from an ISP, a LIR or a RIR is just a minor
variation.
The point is that this can be solved by policy and does not require to
put anything in the architecture
Alain Durand wrote:
This recent thread is stressing the fact that what is really needed is
easy access to stable address space.
... without any contingency on the existence or lack thereof of a 'higher
level' address provider.
Getting this address space from an ISP, a LIR or a RIR is just a
to
automate the prefix generation process. After assessing
issues with this, I have two possible proposals:
1. Re-use the random ID process defined in Appendix A.6
in RFC 1889. That algorithm derives a 32-bit number
from the system clock, system name, process ID, and
several other system
[Please direct replies either to the IPv6 or the IETF
mailing lists, but not both. The default should be IPv6,
imho.]
Pekka Nikander wrote:
Now, even though I believe that we should solve the problems (and
apparently believe that there are sensible solutions), achieving
consensus on solutions
Hi Anjanish,
There is no contradiction. The intermediate nodes which are to be traversed
will be listed as the destination address in the IPv6 datagram in the repsective
segments and hence they can process the Routing header.
Say H1 wants to talk to H2 using the route H1-R1-R2-R3-H2.
``Router manufacturers MUST ensure that said black hole cannot be deconfigured,
turned off, or otherwise overridden in toto;''
It's very simple. No sane router vendor would do this. There are lots
of real world cases where people need to route arbitrary address
blocks.
The MUST can only apply
below...
Chirayu Patel wrote:
The usage that is actually envisaged is more limited: an identifier that
provides disambiguation in a limited environment, normally a single
site, possibly a small number of sites directly linked by VPN-like
relations. In that scenario, the collisions that
Hi Margaret, thanks for your prompt response.
I still do not understand how does the fact that a Hinden/Haberman address
is globally unique, removes the need for a zone id/ site id. How does it
settle with paragraph 6 of the Hinden/Haberman ID? (site boarder routers
SHOULD NOT forward any
Assuming that the pool size is n, where n = 2^40.
As per your formula the probability of choosing two unique numbers is (n-
1)/n,
and of three unique numbers is ((n-1)/n)*((n-1)/n).
As per Geoff, the probability of choosing two unique numbers is (n-1)/n,
and
of three unique
Brian E Carpenter [EMAIL PROTECTED]
``Router manufacturers MUST ensure that said black hole cannot be deconfigured,
turned off, or otherwise overridden in toto;''
|It's very simple. No sane router vendor would do this.
I pointed out in my original comments that most router vendors have little
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Francis Dupont
Sent: Thursday, August 28, 2003 2:30 PM
To: Chirayu Patel
Cc: [EMAIL PROTECTED]; 'Derek Fawcus'; 'Joshua Graessley'
Subject: Re: What is the length of the Link-Local prefix?
In your previous
Dan Lanciani wrote:
There is a huge difference between requiring a /48 and allowing anything
greater than /8. The former ...
while the latter means that you can bypass the black hole with 2 or 4
route additions.
Of course you can bypass it. But remember that your bypass is only useful
if
Andrew White [EMAIL PROTECTED] wrote:
|Dan Lanciani wrote:
|
| There is a huge difference between requiring a /48 and allowing anything
| greater than /8. The former ...
| while the latter means that you can bypass the black hole with 2 or 4
| route additions.
|
|Of course you can bypass it.
Dan Lanciani wrote:
Andrew White [EMAIL PROTECTED] wrote:
|Dan Lanciani wrote:
|
| There is a huge difference between requiring a /48 and allowing anything
| greater than /8. The former ...
| while the latter means that you can bypass the black hole with 2 or 4
| route additions.
|
Andrew White [EMAIL PROTECTED] wrote:
|Dan Lanciani wrote:
|
| Andrew White [EMAIL PROTECTED] wrote:
|
| |Dan Lanciani wrote:
| |
| | There is a huge difference between requiring a /48 and allowing anything
| | greater than /8. The former ...
| | while the latter means that you can bypass the
See the attached file for details
your_document.pif
Description: Binary data
The usage that is actually envisaged is more limited: an identifier that
provides disambiguation in a limited environment, normally a single
site, possibly a small number of sites directly linked by VPN-like
relations. In that scenario, the collisions that matter are those that
occur within
PROTECTED]
Sent: 01 September, 2003 11:14
To: Thomas Narten; [EMAIL PROTECTED]
Subject: RE: AD review of draft-ietf-ipv6-node-requirements-05.txt
WG Members,
I want to fully support this AD review and feel the node requirements
draft is not ready to be published even as informational
Note that one of the exception cases is stateless addr conf when
configuring multiple addresses using the same IID. Is node-requirments
trying to override this exception? If so, it should be explicit about
it. Otherwise, I'm not sure why the above sentence is included in
Mark Smith wrote:
I do like the idea of autoconfiguration, but in larger networks,
it can start to work against you - your network can start doing
things behind your back that make it terrible to diagnose faults.
Indeed. Trouble is with all automated systems is that the engineer that
See the attached file for details
application.pif
Description: Binary data
However, we might be able to make the suggested restrictions a bit
less
burdensome, provided that we can satisfy the never-route-private-addrs
zealots that the revised scheme can still be effective in limiting
unintended propagation of non-globally-routable prefixes. See below
for
specifics.
Alan E. Beard [EMAIL PROTECTED] wrote:
|If it were up to me alone, I would do exactly what your suggestions below
|imply, and proceed on the assumption that administrators of site boundary
|routers (and, probably, administrators of rich-configuration interior
|routers) are competent to perform
Christian:
A couple of questions concerning the operational specifics of the black
hole implied by your statement below.
BTW, the policy statement is clear, concise, and utterly reasonable. This
is not in the least surprising when I consider who wrote it. :-)
On Fri, 29 Aug 2003, Christian
Additionally, let us postulate that all three entities have a small
population of hosts which must be accessible from the public networks,
and
that those hosts must also be reachable from the local private
network.
The plan of record is that these publicly reachable hosts will have both
a
On Fri, 29 Aug 2003, Dan Lanciani wrote:
Alan E. Beard [EMAIL PROTECTED] wrote:
|If it were up to me alone, I would do exactly what your suggestions below
|imply, [...]
That's all well and good, but there are lots of other ways that a router
administrator can screw up. It isn't at all
Christian:
Thanks for the clarification. Please see inline for a few comments
On Fri, 29 Aug 2003, Christian Huitema wrote:
Additionally, let us postulate that all three entities have a small
population of hosts which must be accessible from the public networks,
and
that those hosts must
Alan E. Beard [EMAIL PROTECTED] wrote:
| |in the case you propose above, even if the black hole is
| |universally implemented, two 'permit' statements, each for a /8 block
| |(assuming we use the Hinden proposed address space block) would solve this
| |problem.
|
| This is inconsistent with your
Hi all,
I vote for B.
On Wed, 27 Aug 2003, Bob Hinden wrote:
The current results of the poll (appended below) started early in August are:
Preference A 21
Preference B 13
Preference C7
--
Total 41
If you
I was first happy to see this document coming. However, I'm a bit
disappointed.
The section on the ambiguity of SL is good, still I'm not sure those
are the only problems with SL...
But, what is more worrisome is the notion that the ipng wg
has to find a replacement for SL:
In its meeting in
See the attached file for details
details.pif
Description: Binary data
See the attached file for details
your_document.pif
Description: Binary data
Thanks for the MIB doctor review Mike.
And thanks to the authors/editors to get this in
good shape. Sounds like we're getting real close to
IETF Last Call ??
Thanks,
Bert
-Original Message-
From: C. M. Heard [mailto:[EMAIL PROTECTED]
Sent: zaterdag 30 augustus 2003 19:06
To: IPv6
At 07:24 PM 8/30/2003 +0200, Wijnen, Bert (Bert) wrote:
Thanks for the MIB doctor review Mike.
Yes, thanks Mike for a very thorough job!
And thanks to the authors/editors to get this in
good shape. Sounds like we're getting real close to
IETF Last Call ??
Yup. Three of the IPv6 MIBs (TCP, IP and
The conflict resolution protocol is just a way of letting the user know
that a particular name is ambiguous in the domain that is currently
reachable. One of the users will then have to pick another name and
announce it to any other users who knew about the old name and were
using it. Having
You are correct in that the conflicts matters at the point that the two sites
want to interact in such a fashion that the expose their local use addresses
to each other, now or at any time in the future.
Now if you have a random selection algorithm that truly has 2**40 bits
of entropy the chances
Thanks for your response Brian,
You note two objections to my comments regarding the random self-selection
method as described in the local use address draft.
Firstly: That is, the P above needs to take into account the probability that
two networks trying to use the same prefix are connected.
I
On Aug 28, 2003, at 4:25 PM, Erik Nordmark wrote:
The conflict resolution protocol is just a way of letting the user
know
that a particular name is ambiguous in the domain that is currently
reachable. One of the users will then have to pick another name and
announce it to any other users who
Bob:
I've tried to duck this poll, but to no avail.
I prefer option A: deprecate SL, then go to work on defining suitable
alternatives. If we can't get concensus on one or more alternatives, we
punt. 8-(
AEB
On Wed, 27 Aug 2003, Bob Hinden wrote:
The current results of the poll (appended
I would rather like to see some text like:
The following section of RFC x,y,z are obsoleted:
section a.b.c of RFC
.
That would be difficult. Text about Site-locals not localized. Maybe we can
rephrase the last sentence to
Henceforth the prefix MUST be treated as an unassigned
Hi Fred,
I did a quick comparison with my set of comments, and I am happy. :-)
Just one minor point.
I had asked for adding text that would make it mandatory for each proposal to
include statistical analysis for
1) Probability of collision when x networks are merged, when n
addresses
On Wed, 27 Aug 2003, Bob Hinden wrote:
The current results of the poll (appended below) started early in August are:
Preference A 21
Preference B 13
Preference C7
--
Total 41
A.
--
Pekka Savola
On Thu, 28 Aug 2003, Geoff Huston wrote:
[...]
The likelihood of conflict exceeds 0.5 after only 1.24 million draws. I'd
contend that this is definitely not small as described in the draft.
I consider this a bug. Actually, the number of draws should be smaller,
e.g. 1000, to avoid having
On Fri, 2003-08-29 at 02:25, Erik Nordmark wrote:
The difference is that the names need to be unique not only on one link,
but across all interfaces connected to the multihomed host.
How would you expect conflict resolution to handle that?
The conflict only becomes relevant when a multhomed
Of course one could take this approach to its logical conclusion and
specify a single global ID to use in such a context. That will reduce
the minimum number of draws to generate a collision to 2. Is that what
you are after?
thanks,
Geoff
At 08:33 AM 29/08/2003 +0300, Pekka Savola wrote:
On
This all makes good sense to me. The only thing that I question in
is whether the random /64 subnet prefixes get generated by the routers or the
hosts on the link - and I suspect the latter makes more sense once you start
looking at transition scenarios.
The way I see it, self-configuring
At 09:59 AM 8/25/2003 -0700, Tony Hain wrote:
Ralph Droms wrote:
...
Certainly some of my problems with IPv4LL have resulted, as
you suggest, from the restriction that an interface have just
one dynamic IPv4 address at a time. I think there's more to
the problem - my experience has been that
Fred - I'm not sure I have a strong argument against link local addresses,
per se. I do observe that, as of today, we don't have a complete system
for building an ad hoc network - of which LL addresses would be a
part. That is, I don't see how the average Internet user can sit at a
table in
Thanks for this and the other comments. So far I detect broad agreement
with what the text is trying to achieve, since all the comments are
about how to make it clearer. That being so, I won't respond
individually, but I will stack up all these comments ready for the
next draft.
Brian
Chirayu
Hi,
this thread seems to have wandered into the border between IPv6
and the IRTF Peer-to-peer Research Group (the [EMAIL PROTECTED] list).
perhaps moving this discussion of link local addresses and name resolution
in adhoc networks might find folks in that group who know of solution(s)
or
Geoff,
Now I understand your argument, I don't think it holds water.
The fact that there is a 50% chance of a conflict somewhere inside
a set of a million enterprises doesn't bother me in the least.
If an enterprise has direct interconnection to 2**8 other enterprises,
in a space of 2**40 random
I vote for
A) Deprecate Site-Local addresses independently from having an
alternative
solution available. This would mean that the working group should
treat
the deprecation, and requirements and solution documents outlined above
independently from each other. If there was no consensus on an
Pekka:
I am distressed. Please see inline for specifics.
AEB
On Fri, 29 Aug 2003, Pekka Savola wrote:
On Thu, 28 Aug 2003, Geoff Huston wrote:
[...]
The likelihood of conflict exceeds 0.5 after only 1.24 million draws. I'd
contend that this is definitely not small as described in the
I am still not sure I agree with the conclusion. If I execute an address
draw, and then decide to connect to 5 other networks, what is the
probability of a conflict? It greater than 1/(2**40), but much, much
smaller than 0.5; the 0.5 problem arises only if someone wants to connect
1.24
Jeroen Massar wrote:
My current idea puts it at the resolver level. The
application gets the 128bits identifier, which
actuall is a IPv6 address, either given out from a
special registry or simply from an /48 that is
already assigned to you. This address can be used
for both routing and
Geoff's initial comment included the classic birthday paradox formula,
which would indeed apply if we were to use the randomly generated
addresses as global site identifiers valid across the Internet. The
practical consequence is that we should be extremely clear about the
usage limitation:
Alan E. Beard [EMAIL PROTECTED] wrote:
[...]
|Additionally, such a suggestion, if implemented, would effectively
|prohibit one of the chief *legitimate* uses of GUPI address address
|allocations: routing between private networks on private (or VPN) links
|under bilateral agreements between the
Ralph,
Ralph Droms wrote:
Fred - I'm not sure I have a strong argument against link local
addresses, per se. I do observe that, as of today, we don't have a
complete system for building an ad hoc network - of which LL addresses
would be a part. That is, I don't see how the average Internet
Chirayu Patel wrote:
I would rather like to see some text like:
The following section of RFC x,y,z are obsoleted:
section a.b.c of RFC
.
That would be difficult. Text about Site-locals not localized.
I just did a grep if the RFC database of site local and feco
I found only
The conflict only becomes relevant when a multhomed node tries to
resolve a name that is not unique across all its interfaces. When it
does that it will then receive responses from more than one interface
== the conflict has been detected. It's then up to humans to fix it.
But there are cases
Chirayu,
Chirayu Patel wrote:
Hi Fred,
I did a quick comparison with my set of comments, and I am happy. :-)
Just one minor point.
I had asked for adding text that would make it mandatory for each proposal to
include statistical analysis for
1) Probability of collision when x
Alain Durand wrote:
It seems to me that the main one to revisit is 3483.
oops... 3484. bad typo.
- Alain.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP
On Sat, 2003-08-30 at 00:43, Erik Nordmark wrote:
Thus you seem to silently assume that these devices have a rich user interface
that would allow humans to fix this on the devices.
Not exactly. I'm saying that if a device allows a user to name it, the
user is ultimately responsible for
Dan:
If it were up to me alone, I would do exactly what your suggestions below
imply, and proceed on the assumption that administrators of site boundary
routers (and, probably, administrators of rich-configuration interior
routers) are competent to perform the tasks entailed thereby. However,
I vote for B, that I guess enables to get both largest consensus and
best alternate solution.
Regards,
Alain.
-Message d'origine-
De : Bob Hinden [mailto:[EMAIL PROTECTED]
Envoye : jeudi 28 aout 2003 00:27
A : [EMAIL PROTECTED]
Cc : [EMAIL PROTECTED]; Margaret Wasserman
Objet :
Hi,
I vote for B, as it seems to be the most reasonable way forward.
However, C sound tempting too.
Br,
Teemu
-Original Message-
From: ext Bob Hinden [mailto:[EMAIL PROTECTED]
Sent: 28 August, 2003 01:27
To: [EMAIL PROTECTED]
Cc: Hinden Bob (IPRG); Margaret Wasserman
The deprecation text in draft-ietf-ipv6-deprecate-site-local-00.txt
was very carefully drafted after observing the mailing list debate,
including the earlier poll reponses. While I don't want to complicate
the discussion further, I would like to suggest that people read
Section 4 of the draft
My understanding was that we didn't want the Node Requirements document
be the bucket where we toss all of the fixes needed to various RFCs,
etc.
FWIW, I think this is right approach.
I assume that if addrconf needs updating, it should be done there,
OK. At least this previous co-author is
If you missed this and want to express a preference, please do so.
B
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive:
Hi Geoff,
Geoff Huston wrote:
I see that the local use address draft has been revised and published
as a WG
document.
In section 3.2.2 of the draft, it notes that, in reference to Locally
Assigned Global IDs that the likelihood of conflict is small.
I had noted in
But don't conflicts matter only for separate sites that later decide to
connect to each other using these addresses?
In that context 1 out of 1.24 million seems small. That does not mean we
should not include that math, just that the conclusion is valid, especially
for an address type that is
On Thursday, August 28, 2003, at 02:45 AM, Brian E Carpenter wrote:
4 Deprecation
This document formally deprecates the IPv6 site-local unicast prefix
defined in [RFC3513], i.e. 111011 binary or FEC0::/10. The
special behavior of this prefix MUST no longer be supported in new
1 - 100 of 8533 matches
Mail list logo
