Date:Wed, 26 Jun 2002 17:16:03 -0700
From:"Michel Py" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| Tony and I are
| proposing schemes that are aggregatable and that are not tied to a
| provider.
Unfortunately, they have just as many drawbacks - just d
>> Michel Py wrote:
>> It is a terrible responsibility to embed everyone-gets-one
>> PI-address in the addressing architecture.
> Keith Moore wrote:
> why do you think it's not an equally terrible responsible
> to say "nobody gets a global address prefix unless it's
> tied to a provider"?
I don
> > Tony Hain wrote:
> > Maybe the way to solve this is to take the 'must be 0' bits and
> > define them as 'locally administered'
>
> That is what we were talking about: site IDs in SL addresses.
>
> > with a clear note that FE00::/8 will be blocked on the
> > public net.
>
> How can you guar
> And if the point is to end up with global addresses, we already have a
> mechanism for those, so modifying SL to make them globally unique does
> nothing.
where in the world do you get the idea that all interconnection
between IP networks is done using the public Internet?
Keith
Tony,
> Tony Hain wrote:
> Maybe the way to solve this is to take the 'must be 0' bits and
> define them as 'locally administered'
That is what we were talking about: site IDs in SL addresses.
> with a clear note that FE00::/8 will be blocked on the
> public net.
How can you guarantee this? I
> > first we would need a naming system that is fast and reliable.
>
> and referrals of addresses trades off reliability for a little speed.
when you're trying to complete a phone call, or trying to coordiate
between hundreds of processes in a distributed computation, a 10
second delay in your
> The statement I was responding to was "the idea that a prefix can be
> changed at a whim is just a fantasy.". The point is that arbitrary &
> random prefix changes are reality and believing it doesn't happen is the
> fantasy.
Okay, let me rephrase that:
The idea that a prefix can be changed a
Keith Moore wrote:
> > > ...
> > > mainly I want a solution to the problem. apps need to be
> able to do
> > > address referrals and right now the algorithm for selecting
> > > which address
> > > to use is little better than a guess. anything we can do to
> > > make this
> > > faster or more re
On Tue, Jun 25, 2002 at 04:43:46PM +0530, Anjaneyulu wrote:
> Hi All,
> The ND RFC 2461 specifies that the Hop Limit in the IPv6 Header be set
> to 255 for Router Advertisement.
>
> But as far as i understand the router Advertisement should not be
> propagated out of the Link by a router.
"s
> > ...
> > mainly I want a solution to the problem. apps need to be able to do
> > address referrals and right now the algorithm for selecting
> > which address
> > to use is little better than a guess. anything we can do to
> > make this
> > faster or more reliable is a good thing, and SLs wit
Keith Moore wrote:
> > > I don't think stability is the issue. global addrs need to
> > > be reasonably
> > > stable (which is to say, on the order of MTBFs for
> reliable machines)
> > > whether or not the prefix is provider-based, topology-based, or
> > > assigned to the site. the idea that a
Keith Moore wrote:
> ...
> mainly I want a solution to the problem. apps need to be able to do
> address referrals and right now the algorithm for selecting
> which address
> to use is little better than a guess. anything we can do to
> make this
> faster or more reliable is a good thing, and SL
> > I don't think stability is the issue. global addrs need to
> > be reasonably
> > stable (which is to say, on the order of MTBFs for reliable machines)
> > whether or not the prefix is provider-based, topology-based, or
> > assigned to the site. the idea that a prefix can be changed
> > at a
Robert Elz wrote:
> Date:Sun, 23 Jun 2002 17:44:17 -0400
> From:Ralph Droms <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> | I agree 100% with Micehls' point - assigning unique IDs
> to sites for use in
> | site-local addresses moves the site-local addre
Ralph Droms wrote:
> I agree 100% with Micehls' point - assigning unique IDs to
> sites for use in
> site-local addresses moves the site-local addresses into a globally
> routable address space, with the additional feature that
> those addresses
> are provider independent. The result would be an
> Clearly you still live in the fantasy land where pleanty of addresses
> were handed out 20 years ago, the birds sing, the air is always clean,
> and the sun always shines.
is your point sufficiently weak that you need to spout this ?
Keith Moore wrote:
> ...
> I don't think stability is the issue. global addrs need to
> be reasonably
> stable (which is to say, on the order of MTBFs for reliable machines)
> whether or not the prefix is provider-based, topology-based, or
> assigned to the site. the idea that a prefix can be c
> Vendors have long learned how to integrate different name services:
> DNS, NIS, NIS+, LDAP, Flat files
and users are still having fun debugging the resulting behavior.
"was it a funny dns result, an error in the hosts file, yellow
plague, ...? there goes 10-30 minutes "
--
Thomas Narten wrote:
> ...
> 2) The document doesn't specify security issues around RFC 3041
> temporary addresses and how they can be ameliorated. But queries for
> names and addresses can be used to discover the relationship between
> more permanent DNS names and IP addresses and the temporary
> Vendors have long learned how to integrate different name services:
> DNS, NIS, NIS+, LDAP, Flat files
I think that should be 'vendors have long attempted to integrate
different name services'. Unfortunately, they still haven't learned
NOT to do it - and this applies equally to NIS* and WI
On Wed, 26 Jun 2002, Alain Durand wrote:
> On Wednesday, June 26, 2002, at 11:38 AM, Thomas Narten wrote:
>
> > The IESG has reviewed this document and has a number of concerns.
> >
> >
> > The IESG believes that the name space as provided by the DNS should
> > not be mixed or "contaminated" with
On Wednesday, June 26, 2002, at 11:38 AM, Thomas Narten wrote:
> The IESG has reviewed this document and has a number of concerns.
>
>
> The IESG believes that the name space as provided by the DNS should
> not be mixed or "contaminated" with name resolutions performed using
> the ICMP mechanism
On Thu, 27 Jun 2002 [EMAIL PROTECTED] wrote:
> In my understanding, the threat imposed by malicious responses to
> ICMPv6 node information query (Qtype = node name) is equal to
> setting up DNS PTR records without forward zone administrators'
> knowing. For instance, anyon
Let me clarify...
[EMAIL PROTECTED] writes:
> >More detailed comments from various reviewers:
> >
> >Many application implementations do a reverse DNS lookup on an IP
> >address to learn the DNS Name of the connecting system. This name is
> >then used to make access control decisions. Some may b
>3) This protocol is a bit loaded with options and features. It
>supports a number of different queries, leaves a fair amount of
>flexibility in how such information is obtained (e.g., proxies are
>supported) and is rather easily extensible, including in proprietary
>ways. The IANA Considerations
The IESG has reviewed this document and has a number of concerns.
General concerns:
1) The applicability statement limits the scope to diagnostic and
debugging and states that the mechanism is for name lookups
independent of the the DNS. However, there are still places in the
document where the
On Tuesday, June 25, 2002, at 02:56 PM, Bob Hinden wrote:
>
> Other views on this?
>
> Bob
There has been a very long discussion on the fate of Site Local addresses
in the wg. There are still two opposite views of what to do about them:
a) Do not require apps to support multi-sited nodes now,
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : Requirements for IPv6 prefix delegation
Author(s) : S. Miyakawa
Filename: draft-miyakawa-ipv6-prefix-delegation-
requirement-00.txt
28 matches
Mail list logo
