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
Jeroen Massar wrote:
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?? :)
Keith Moore wrote:
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 actually think it's commendable
that
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
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 statements, bugtracker entries...
Seems
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 every
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 building an ad hoc,
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.
I do, however, also remember a discussion on one of the IPv6 mailing
lists about this,
% 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
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, but this isn't
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 'speed things up' (go figure).
perfectly reasonable
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
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 'speed things up' (go figure).
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,
(i) RFC 2821 can be read (and was intended to be read)
to prohibit the use of an address literal in a HELO or
EHLO command unless the relevant host has no DNS name.
(sections 3.6, 4.1.1.1, 4.1.4)
these days it's sort of odd to think that a host has a distinguished DNS
of course it is possible to write apps that do not use DNS, but this is
rarely done.
why not just embed the ip addresses in the data payloads? death to
nats! :-)
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 ambiguous, routing will assure
Stephen Sprunk wrote:
I've dealt with many companies interconnecting where both use RFC1918
space -- NAT is the first thing discussed. You forget, these people are
connecting for a _business reason_ and there is real money to be lost if
they mess up.
And how much real money do they lose by
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; ...
heck, TCP breaks if you change an address out from under it, so it's
hardly surprising that apps using TCP break under similar conditions.
...
hosts could advertise static loopback addresses. Bind TCP to the
static loopback address.
we do this. however, it only works inside a routing
% 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,
on 3/31/2003 11:01 AM Bill Manning wrote:
Is may be worth noting that RIRs have -NEVER- made presumptions
on routability of the delegations they make.
Probably more accurate to say that they have never guaranteed routability.
They make all kinds of presumptions about routability.
--On tirsdag, april 01, 2003 11:33:46 -0800 Bill Manning [EMAIL PROTECTED]
wrote:
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
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
Tony,
I've been trying to get my mind around the various issues here,
and I keep getting back to the same place, so I think I need to
embarrass myself by making a proposal that I find frightening.
Let's assume, as I think you have suggested, that SL is all
about local addresses and filtering,
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
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 emphatically *NOT* what application developers do. They
do not just observe that it does not work, they
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
Keith Moore wrote:
site locals do not provide a well known flag because an application has
no idea about the site boundary,
Or boundaries: consider a private LAN where one part is firewalled from
other parts of the same site. The single flag this address is
site-local cannot mark that
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
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.
Indeed, correctly
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
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 ambiguous, routing will assure that
--On Monday, March 31, 2003 12:17:44 -0800 Eliot Lear [EMAIL PROTECTED]
wrote:
Since the address block is ambiguous, routing will assure that if you
reach a node it is the correct one. This FUD needs to stop!
Right up till the point where two companies start communicating with one
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.
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 you are using hardcoded IP's.
The only case you
On Mon, 31 Mar 2003 15:43:38 -0600
Matt Crawford [EMAIL PROTECTED] wrote:
All things SL is claimed to solve are solveable with unique
addresses too, as long as you've got enough of them. The rest is
just simple (perhaps tedious) work that every operations-aware
person I know of would
On Mon, 31 Mar 2003 15:49:03 -0600
Matt Crawford [EMAIL PROTECTED] 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
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
On Mon, 31 Mar 2003 16:12:51 -0600
Matt Crawford [EMAIL PROTECTED] wrote:
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
This has nothing to do with sitelocal but more with the
fact that a host can have multiple paths from A to B: internet ;)
multiple paths does not imply multiple addresses.
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)
Did anybody consider just handing out a /48 (or a bit smaller)
automagically with each DNS registration?
--On Friday, March 28, 2003 10:36 AM -0800 Tony Hain [EMAIL PROTECTED]
wrote:
John C Klensin wrote:
Tony,
I've been trying to get my mind around the various issues here,
and I keep getting
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,
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, the
IETF and NANOG will quite certainly jointly
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
Tony is right -- any registration process costs resources.
agreed, though the cost of registering a domain name should serve as a useful
upper bound. at least with address blocks you don't have to worry about I18N,
trademark infringement, etc.
But, if these addresses are assumed to be not
% 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
What is not
fixable is the fact that apps will break if you change an address out
from under them.
heck, TCP breaks if you change an address out from under it, so it's
hardly surprising that apps using TCP break under similar conditions.
the TCP/IP architecture simply was not designed to
Keith;
I disagree with your assessment. I will continue this technical discussion
on the WG list after the minutes are published.
Rich
At 06:26 PM 3/27/03 -0500, Keith Moore wrote:
I second Tony's key point. SL's are just 1 form of IPv6 addresses
with a limited scope. As soon as
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.
] On
Behalf Of Eliot Lear
Sent: Wednesday, March 26, 2003 12:59 PM
To: [EMAIL PROTECTED]
Cc: 'The IETF'
Subject: Re: Fw: Welcome to the InterNAT...
Tony Hain wrote:
Trying to use SL for routing between sites is what is broken.
But that's not all...
The space
identified in RFC 1918
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
Pekka Savola wrote:
Who said the addresses are *completely* revokated when the network
connectivity is intermittent?
More likely than not, those address advertisements have a
lifetime longer than the duration of the downtime (both
preferred and valid in RFC2461
terms!) -- and whoops,
On Thu, 27 Mar 2003, Tony Hain wrote:
Pekka Savola wrote:
Who said the addresses are *completely* revokated when the network
connectivity is intermittent?
More likely than not, those address advertisements have a
lifetime longer than the duration of the downtime (both
preferred
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,
Pekka Savola wrote:
Not so. (If you build your system in an optimal fashion --
which really
does need a bit fleshing out, though.)
So the intent is to dictate to everyone how they build their networks?
Such prefixes would then reach valid lifetime=x, preferred
lifetime=0, be set
1 - 100 of 159 matches
Mail list logo
