Messages | Bytes| Who
+--++--+
22.22% |6 | 19.06% |34978 | [EMAIL PROTECTED]
11.11% |3 | 8.03% |14738 | [EMAIL PROTECTED]
11.11% |3 | 8.03% |14733 | [EMAIL PROTECTED]
7.41% |2 | 8.35% |153
Messages | Bytes| Who
+--++--+
8.49% | 18 | 9.53% | 112843 | [EMAIL PROTECTED]
8.96% | 19 | 8.70% | 102993 | [EMAIL PROTECTED]
4.25% |9 | 5.37% |63594 | [EMAIL PROTECTED]
5.19% | 11 | 4.18% |495
Messages | Bytes| Who
+--++--+
25.16% | 40 | 25.68% | 216885 | [EMAIL PROTECTED]
12.58% | 20 | 14.43% | 121847 | [EMAIL PROTECTED]
12.58% | 20 | 11.50% |97109 | [EMAIL PROTECTED]
4.40% |7 | 5.06% |427
Messages | Bytes| Who
+--++--+
18.52% | 20 | 17.85% |96111 | [EMAIL PROTECTED]
12.96% | 14 | 12.25% |65968 | [EMAIL PROTECTED]
8.33% |9 | 7.70% |41466 | [EMAIL PROTECTED]
4.63% |5 | 6.11% |328
At Mon, 04 Aug 2003 11:06:55 -0700, Bob Hinden wrote:
>
> Please respond to the list with your preference
Sigh. A.
["But where are the clowns? There ought to be clowns.
Well, maybe next year." -- Stephen Sondheim]
IETF IPn
At Thu, 07 Aug 2003 14:25:18 +1000, Andrew White wrote:
> Keith Moore wrote:
>
> > it's far easier to filter global addresses than to filter local ones.
>
> *boggle* Am I the only one that finds this claim nonsensical?
I wouldn't phrase it as Keith did, but I think that I end up in the
same pla
What Brian C., Margaret, Brian H., Pekka, Mike, Jim, Alain, Ralph,
Keith, and Mark said, but not what Brian Z. said :).
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP a
At Wed, 30 Oct 2002 22:14:44 -0800, Tony Hain wrote:
>
> ...I think I have simply been focused on defending a discussion
> settled so long ago that most of the interested parties have assumed
> it is done and they don't need to stay engaged.
Since a check of the mailing list archive shows that th
At Wed, 30 Oct 2002 19:46:22 -0800, Michel Py wrote:
>
> There's been a lot of noise here lately, without real reasons, and it
> has not produced much results either.
You can call a concrete proposal to eliminate a chunk of unnecessary
router complexity "noise" if you like, but I'll have to disag
What Ole said.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMA
At Thu, 31 Oct 2002 10:59:45 +1100, Mark Andrews wrote:
>
> I'm talking about 1 name with multiple addresses being
> returned in multiple scopes. I'm taking about having
> getaddrinfo() then filter out the inappropriate addresses
> using local knowledge and setting sin6_sc
At Thu, 31 Oct 2002 09:20:54 +1100, Mark Andrews wrote:
>
> This is tunnel vision. The only reason that no one expects
> them in the DNS is that we havn't added support for them
> in the DNS.
>
> I think LL (and SL) should be in the DNS. Doing this actually
> simpl
I've heard this argument that site-local addresses somehow make the
site border router filtering problem easier, and I don't get it. As
far as I can tell, they don't help at all, and in fact just make the
problem a little worse. I have to filter all the kinds of addresess
that shouldn't be crossi
At Mon, 28 Oct 2002 22:21:47 -0500, Margaret Wasserman wrote:
>
> Well, I've certainly heard it, and it looks much better, to me,
> than the "two-faced" DNS hack I've heard described in the past.
>
> I'd love to hear what the other DNS folks think, because maybe
> this would be a promising approa
At Mon, 28 Oct 2002 15:52:14 -0500 (EST), Dan Lanciani wrote:
>
> Any language that reduces site-local addresses to second-class citizens (or,
> worse, implies that they should not be used concurrent with global addresses)
> will give stack and application vendors an excuse to fail to support such
At Mon, 28 Oct 2002 10:31:58 -0500, Keith Moore wrote:
>
> Distributed applications depend on consistent results from DNS,
> regardless of where the query came from.
Yep. RFC 2826 discusses this in some detail.
> and what compelling purpose does all of this complexity serve?
> none that I can
I think that Margaret's proposal on site-local addresses makes a lot
of sense, and I think it's the best suggestion I've heard to date for
how we should move forward from where we are now on this issue.
IETF IPng Working Group Mai
At Mon, 21 Oct 2002 21:50:49 +0300 (EEST), Pekka Savola wrote:
>
> Can you elaborate, which discussion? I did a few searches in the mail
> archive but didn't find anything relevant.
Postings dating back to March of this year, including the following.
--- Begin Message ---
At Tue, 14 May 2002
At Mon, 21 Oct 2002 15:36:37 +0300 (EEST), Pekka Savola wrote:
>
> Using DNS, we could specify very simple mechanisms for service discovery
> (note: those services, unlike to DNS, are not really required for all
> notes. Stuff like NTP should be on every node, of course, but world
> doesn't end i
An additional (and separate) comment on the DNS discovery draft.
Temporarily suspending my disbelief in the mechanism described in this
document for purposes of discussion, there's a terminology problem:
the draft talks about finding DNS resolvers, which is not really right
and which some readers
At Sat, 12 Oct 2002 09:37:32 -0400, Brian Haberman wrote:
>
> What if we applied the principles that Erik and I propose in
> draft-haberman-ipv6-anycast-rr-00.txt? That would allow for the
> resolver to bind an address for the server.
If the WG were to go ahead with this DNS discovery mechanism
At Fri, 11 Oct 2002 14:13:45 -0700, Bob Hinden wrote:
>
> This is a IPv6 working group last call for comments on advancing the
> following document as a Proposed Standard:
>
> Title: Well known site local unicast addresses for DNS resolver
I have written about this document at some length befor
Both Robert's approach and Brian's approach seem workable. Of the
two, I think Brian's approach is better, because it collects the
scoped address stuff in one place, which seems good on several counts.
IETF IPng Working Group Ma
At Tue, 08 Oct 2002 12:19:44 -0400, Margaret Wasserman wrote:
>
> In other words, I think that routers should default to the
> single-link subnet case, unless mutli-link subnetting has been
> explicitly configured.
I agree.
IET
What KRE said.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EM
At Wed, 2 Oct 2002 15:55:51 -0700, Steve Deering wrote:
>
> Either we're talking about the case where multilink subnets are not
> employed (no need to believe in them), in which case my statement
> holds.
Right.
> Or we are venturing into the oh-so-scary land of multilink subnets,
> in which ca
At Wed, 2 Oct 2002 15:07:55 -0700, Steve Deering wrote:
>
> >>Here is a suggestion:
> >>
> >>1) change the wording of the subnet-local definition to say something
> >> like:
> >>
> >> subnet-local scope is given a different and larger value
> >> than link-local to enab
At Wed, 2 Oct 2002 16:08:34 -0700, Steve Deering wrote:
>
> At 6:07 PM -0400 10/2/02, Rob Austein wrote:
> >The key phrase in your explanation is "the admin assigns". The
> >addr-arch doc says "admin-local scope is the smallest scope that must
> >be admini
At Wed, 2 Oct 2002 15:07:55 -0700, Steve Deering wrote:
>
> In a response to that message, Rob asked me if I had forgotten about
> unnumbered point-to-point links. I answered as follows:
>
> >Yes, I did forget about them, but I think it's obvious how to handle them:
> >they are not part of a su
At Wed, 02 Oct 2002 17:35:37 -0400, Brian Haberman wrote:
>
> The subnet-scope is delineated in the same manner as the scopes
> 6,7,8,9... That is, a router maintains a scope zone id per interface.
> So, if I have a router that has interfaces 1,2,3, & 4 and the admin
> assigns a subnet-loca
I made the mistake of allowing my arm to be twisted into reviewing
draft-ietf-ipngwg-addr-arch-v3-10.txt last week, and was sad to find
what appears to be an ambiguity in some of text that deals with
subnet-scope multicast. Given that this document was already before
the IESG at the time I found
At Thu, 11 Jul 2002 10:59:27 +0200, Brian E Carpenter wrote:
>
> All of which tells me that if we define a requirement for the flow label
> allocation process to survive reboots, it will be a SHOULD not a MUST.
> A toaster would provide a compelling argument for overriding the SHOULD.
Precisely
At Wed, 10 Jul 2002 11:58:38 -0700, Bob Hinden wrote:
>
> I think something with similar properties to TCP's initial sequence number
> selection would be about right. A toaster-class device will have to deal
> with that as well.
I agree that the constraints seem similar. ISN selection is ano
At Wed, 10 Jul 2002 16:21:54 +0300 (EEST), Pekka Savola wrote:
>
> This is especially important if the implementation should keep track of
> flow labels across reboots. I see no good way of doing this except
> writing the labels in some kind persistent storage. And consider
> operating system c
At Fri, 31 May 2002 19:54:03 +0900, Jun-ichiro itojun Hagino wrote:
>
> then we will have two separate set of IPv6 nodes - without mobile-ipv6
> and with mobile-ipv6, and they cannot even ping each other.
> do you feel it acceptable?
I'll leave the specific issue (whether MIPv6
At Tue, 14 May 2002 20:19:32 -0400, Steve Bellovin wrote:
>
> >So how can we understand the threat model for DNS discovery?
> >
> That takes work... A good starting point would be Derek Atkins' and
> Rob Austein's DNS threat analysis document
> (draft-ietf-dnsext-dns-threats-01.txt) I haven't ha
At Fri, 3 May 2002 09:49:45 -0700, Steve Deering wrote:
>
> It's not the routing system "deciding" the choice of servers, it's the
> human who causes the host routes to be injected into the routing system.
> Instead of a human putting three DNS server addresses into a DHCP
> database, a human con
At Thu, 02 May 2002 14:44:52 -0700, Bob Hinden wrote:
>
> The reliance on the routing system for a host route IMHO isn't any
> different from having a host on a subnet. The router had to be configured
> to advertise a route to the subnet. It didn't happen automatically. The
> only differenc
At Tue, 30 Apr 2002 14:47:20 -0700, Bob Hinden wrote:
>
> The first set of sections (1-8) does not specify the use anycast or
> multicast, only unicast using three well know addresses.
Yes, but
>From the client's point of view, the practical difference between a
well-known unicast address
At Tue, 30 Apr 2002 16:36:11 -0700, Bob Hinden wrote:
>
> I think you mentioned in an earlier email about the need for NTP in order
> to use DNSSEC.
More precisely, in order to verify DNSSEC signatures, but yes.
> From the discussion on the list it sounds like the timing requirement for
> DNS
At Tue, 30 Apr 2002 15:56:12 +0200, Hesham Soliman wrote:
>
> Which boxes does it add? I really don't see any more boxes
> here. Note, I'm not advocating this particular approach (injecting
> routes from the DNS) but I don't agree with your claim above, and I
> think it can work.
This approach w
So now we're back to changing the DNS protocol and every IPv6-capable
DNS client in the world to support triangular wheels.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
At Tue, 30 Apr 2002 08:07:14 -0400, Brian Haberman wrote:
>
> Actually that is an incorrect statement. The IPv6 addressing
> architecture forbids the use of an anycast address as the source
> address. So, the response back from the anycast member will have
> one of its unicast addresses as the
At Mon, 29 Apr 2002 12:54:51 -0700, Steve Deering wrote:
>
> No more so than the use of DHCP relays does. We're talking about the
> IGP within a site, and taking advantage of what it already can do.
Nope, you're storing new information in the IGP that wasn't there
before. But back up and take
At Mon, 29 Apr 2002 19:45:51 +0200, Hesham Soliman wrote:
>
>> b) What's the security model by which the router decides whether to
>>accept routing updates from the DNS server?
>
> The same model that is used between routers in the network.
Right, so this approach adds a whole new set of bo
At Mon, 29 Apr 2002 18:53:00 +0200, Hesham Soliman wrote:
>
> 1. The DNS can inject a route. Do you see problems
>with this?
Well, "the DNS" doesn't do routes, but I assume you meant the DNS
server. Yes, there are issues:
a) DNS server now has to implement one or more routing protocols,
At Mon, 29 Apr 2002 18:14:59 +0200, Hesham Soliman wrote:
>
> How does anycast have this problem? Specifically, how does the DNS
> discovery draft have this problem?
Server location via anycast means that one is using the routing system
to keep track of the location of the DNS server. That is,
At Fri, 26 Apr 2002 15:38:35 -0700, Bob Hinden wrote:
>
> There are issues raised in solutions like this to insure that the
> co-located services are adequately tied together. For example in case of a
> "DHCP server in the DNS server" the processes need to be tied together in a
> manner that
At Mon, 22 Apr 2002 13:57:02 -0700, Bob Hinden wrote:
>
> Could you comment on the definition I used for server-less? There
> was more than just the use of the word.
I think that Ralph already addressed the main point, I doubt that I
can improve much on his comments, and I implore you to read w
Well, I don't think it's worth getting into a discussion about whether
NAT-PT is required to have per-flow state or SIIT is forbidden from
having per-flow state, so I'll just observe that, unless there's also
port mapping going on, NAT-PT mostly just deals with addresses. There
is an address mapp
Er, NAT-PT is basicly a supserset of SIIT, so anything one needs to do
for SIIT one also needs to do for NAT-PT.
Or am I misunderstanding something?
IETF IPng Working Group Mailing List
IPng Home Page: http:
At Fri, 19 Apr 2002 09:50:01 -0700, Bob Hinden wrote:
>
> I suspect that most people can tell the difference.
No, Bob, that's exactly the point. You see a difference. I see a
difference. But is the difference you see the same as the difference
I see? Maybe, maybe not.
I understand that you'
I think the statement would be clearer if rewritten without ever using
the word "server", since the newly coined term "server-less" strongly
suggests that we are still using that word in multiple ways that
conflict with each other.
Accepting the confusing terminology temporarily for purposes of
d
At Wed, 17 Apr 2002 11:52:52 +0200, Hesham Soliman wrote:
>
>> Well, entities performing the server role of DHCP only answer
>> Inform requests when (they think) they have something useful to
>> say. The specific mechanism by which multiple entities could act
>> in the DHCP server role on a sing
At Tue, 16 Apr 2002 22:27:45 -0700, jonne soininen wrote:
>
> Maybe I was not totally clear what I was trying to say. What I was
> trying to say was that the dns discovery draft does not (though the
> name would indicate so) talk about discovery, or configuration -
> just what would be the well k
At Tue, 16 Apr 2002 18:13:04 -0700, jonne soininen wrote:
>
> I may be wrong but Rob's and Hesham's discussion about configuration
> of the node (at this point) is to my opinion a bit off-tack from the
> original discussion.
I think it's the same discussion. YMMV.
--
At Tue, 16 Apr 2002 17:48:10 +0200, Hesham Soliman wrote:
>
> Ok, I should say that the functionality I'd like to see is the
> ability to discover a DNS without relying on functional entities
> other than the DNS. (not necessarily the entire node, but the server
> itself, I think the term server
At Tue, 16 Apr 2002 11:47:58 +0900, Jun-ichiro itojun Hagino wrote:
>
> this "Information-Request" behavior happens only when O bit is set in
> router advertisement packet (see RFC2461 page 19). the problem
> "stateless DNS discovery" draft is trying to address is, how to
>
At Mon, 15 Apr 2002 12:24:36 +0200, Hesham Soliman wrote:
>
> OK, but we still have two options in IPv6 for address
> autoconfiguration: Stateless and Stateful. I don't understand
> why we shouldn't allow the option for _real_ stateless
> autoconfig in IPv6. By 'real' I mean, we can't claim true
Somewhat late reply, but the topic doesn't seem to have gotten much
discussion.
At Thu, 4 Apr 2002 17:36:39 +0200, Hesham Soliman wrote:
>
> During the last meeting a question was raised on whether the
> scenarios for which the stateless DNS discovery draft can be used,
> were clear to everyone.
The level 1 compliance stuff is only simple in the case of a single
subnet. As soon as you have routers between the client and the
server, you have to do something to get the packets across the router.
I suppose we could have a discussion about whether magic unicast
addresses (which are really a
At Sat, 9 Mar 2002 03:27:36 +0100, Hesham Soliman wrote:
>
> I don't have a great knowledge of DHCP but wouldn't this simply
> message still require a relay agent?
That's one way to do it. Another would be clever use of multicast.
[Replies intentionally redirected to mailing list by author -- I get
way too much mail and really don't need duplicate copies from a list
that generates as much traffic as this one. Thanks.]
At Thu, 07 Mar 2002 12:26:09 -0500, Ralph Droms wrote:
>
> I do disagree with the DT conclusion - as d
> Allocations on non-nibble boundaries are possible of course.. it could
> just mean about 8 different almost identical delegations in the worst
> case.
Right. Which should trivially easy to automate for any organization
big enough to need to worry about it.
> Or are you referring to "Class-les
The basic problem is that neither the IPv6 community nor the DNS
community has reached a clear consensus on whether the extra features
of A6 over are worth the extra cost. That's not a euphemism for
"have decided that they're not", I really mean that we have people
advocating each side in ea
Date: Wed, 06 Jun 2001 20:40:26 -0700
From: Ravikanth Samprathi <[EMAIL PROTECTED]>
My question is the following:- Is it possible that the dns servers
for both ipv4 and ipv6 to run in the same border gateway as the
NAT-PT? Or in other words, Can we run, NAT-PT, ipv4-dns-server and
Date: Mon, 26 Mar 2001 15:14:52 -0500
From: Bill Sommerfeld <[EMAIL PROTECTED]>
This proposal does not formally define equivalence of and A6.
Right. There's still a bit of an open issue about what to do with
in the long run, perhaps declare it to be a form of meta query
for s
67 matches
Mail list logo
