Re: Removing features

2003-10-15 Thread Kurt Erik Lindqvist
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Do not flood root servers with reverse lookup queries for private addresses (I want my traceroutes to work on the inside of the network too, so I long ago configured reverse lookup for private addresses on my internal DNS servers). Kurt Erik

RE: Removing features

2003-10-15 Thread Michel Py
Kurtis, Kurt Erik Lindqvist wrote: There are a hell of a lot traceroutes going on then... As pointed out by Keith privately, traceroutes are not the only culprit. Telnet to a host from a private IP, it does a reverse lookup on your IP, etc. Basically everything that triggers a reverse lookup

Re: Removing features

2003-10-15 Thread Keith Moore
On Wed, 15 Oct 2003 00:11:56 -0700 Michel Py [EMAIL PROTECTED] wrote: Kurtis, Kurt Erik Lindqvist wrote: There are a hell of a lot traceroutes going on then... As pointed out by Keith privately, traceroutes are not the only culprit. Telnet to a host from a private IP, it does a reverse

RE: Removing features

2003-10-15 Thread Michel Py
Keith Moore wrote: great. now we'll have NAT boxes intercepting outgoing DNS traffic also. That was not my point. My point was to have a DNS server in the inside configured for reverse lookup of private IPs. What you mention would help though. Michel.

Re: Removing features

2003-10-15 Thread Valdis . Kletnieks
On Wed, 15 Oct 2003 10:26:17 EDT, Keith Moore said: great. now we'll have NAT boxes intercepting outgoing DNS traffic also. The really bad part is that they'll on the average do as good a job of intercepting DNS traffic as they do of filtering outbound 1918-sourced packets in general. After

RE: Removing features

2003-10-15 Thread Jeroen Massar
-BEGIN PGP SIGNED MESSAGE- Michel Py wrote: Keith Moore wrote: great. now we'll have NAT boxes intercepting outgoing DNS traffic also. That was not my point. My point was to have a DNS server in the inside configured for reverse lookup of private IPs. What you mention would

Re: Removing features

2003-10-15 Thread Keith Moore
Keith Moore wrote: great. now we'll have NAT boxes intercepting outgoing DNS traffic also. That was not my point. My point was to have a DNS server in the inside configured for reverse lookup of private IPs. one of the most-frequently cited justifications for NAT is plug-and-play.

Re: IESG proposed statement on the IETF mission

2003-10-15 Thread Valdis . Kletnieks
On Wed, 15 Oct 2003 12:48:37 EDT, Keith Moore said: I certainly don't believe only in rough consensus and running code - I also believe in explicit definition of goals and requirements, careful design by knowledgable experts, analysis, iterative specification, wide public review, etc. Of

Re: Removing features

2003-10-15 Thread John C Klensin
--On Wednesday, 15 October, 2003 11:58 -0400 Keith Moore [EMAIL PROTECTED] wrote: Keith Moore wrote: great. now we'll have NAT boxes intercepting outgoing DNS traffic also. That was not my point. My point was to have a DNS server in the inside configured for reverse lookup of private IPs.

rfc1918 impact

2003-10-15 Thread Leif Johansson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We should keep nice and descriptive subject-lines... Michel Py wrote: snip | etc. Basically everything that triggers a reverse lookup adds to the | pain, but if reverse lookup is configured correctly on the local DNS A lot of the arguments seem to

Re: Removing features

2003-10-15 Thread Keith Moore
Now, whether that interception and diversion of DNS queries is a moral activity is a different question.But, if you believe strongly enough that having a NAT in the first place puts one into a serious state of sin, then the marginal sin of intercepting DNS queries for private

Re: Removing features

2003-10-15 Thread John C Klensin
--On Wednesday, 15 October, 2003 13:45 -0400 Keith Moore [EMAIL PROTECTED] wrote: Now, whether that interception and diversion of DNS queries is a moral activity is a different question.But, if you believe strongly enough that having a NAT in the first place puts one into a serious

rfc1918 impact

2003-10-15 Thread Leif Johansson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 snip | | (2) But the typical plug-and-play NAT, at least the ones I have run | across, is preconfigured with the addresses to be used on the inside | and contains (or is intimately paired with) a DHCP server that gives out | those addresses.

Re: rfc1918 impact

2003-10-15 Thread John C Klensin
--On Wednesday, 15 October, 2003 22:10 +0200 Leif Johansson [EMAIL PROTECTED] wrote: | (2) But the typical plug-and-play NAT, at least the ones I | have run across, is preconfigured with the addresses to be | used on the inside and contains (or is intimately paired | with) a DHCP server that

Re: IESG proposed statement on the IETF mission

2003-10-15 Thread Melinda Shore
It's an interesting document, but it looks to me a bit much like a problem description and I'm not sure how it relates to other existing work (the problem description document in the problem working group, most obviously). I particularly liked the discussion of the IETF mission - it could provide

Re: IESG proposed statement on the IETF mission

2003-10-15 Thread Scott W Brim
On Tue, Oct 14, 2003 11:48:10PM +0200, Harald Tveit Alvestrand allegedly wrote: As part of the discussions about change process within the IETF, the IESG has come to believe that a somewhat longer statement of the IETF's mission and social dynamics might provide useful context for the

Re: IESG proposed statement on the IETF mission

2003-10-15 Thread Keith Moore
overall, I like the document. some comments: However, while Dave Clark's famous saying We do not believe in kings, presidents, or voting. We believe only in rough consensus and running code, is this an accurate quote? I've usually seen it written We reject kings,

Re: draft-ietf-vrrp-ipv6-spec-05.txt lacks IPR clause

2003-10-15 Thread Bob Hinden
Itojun, At 06:43 PM 10/14/2003, [EMAIL PROTECTED] wrote: draft-ietf-vrrp-ipv6-spec-05.txt does not have IPR clause on it, even though cisco claims to have patent related to it. http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-vrrp-ipv6-spec.txt I wasn't aware of this

Re: IESG proposed statement on the IETF mission

2003-10-15 Thread Eric Rosen
The purpose of the IETF is to create high quality, relevant, and timely standards for the Internet. It is important that this is For the Internet, and does not include everything that happens to use IP. IP is being used in a myriad of real-world applications, such as controlling

RE: IESG proposed statement on the IETF mission

2003-10-15 Thread Margaret . Wasserman
Hi Scott, Similarly for almost all of the rest. What's the point? Are you reiterating the problem-statement work? They're doing all right, although perhaps you could help push the work to completion. It would be much more useful for you to reaffirm the fundamental principles that are

Re: IESG proposed statement on the IETF mission

2003-10-15 Thread Keith Moore
One would hope instead that the IETF would want to encourage competition between different views of Internet evolution, as the competition of ideas is the way to make progress. what I would say instead is that the IETF should encourage this competition within the sphere of architectural

Re: IESG proposed statement on the IETF mission

2003-10-15 Thread Scott W Brim
On Wed, Oct 15, 2003 01:01:53PM -0400, [EMAIL PROTECTED] allegedly wrote: Hi Scott, Similarly for almost all of the rest. What's the point? Are you reiterating the problem-statement work? They're doing all right, although perhaps you could help push the work to completion. It would

Re: Removing features

2003-10-15 Thread Iljitsch van Beijnum
On 15 okt 2003, at 19:45, Keith Moore wrote: the marginal sin of intercepting DNS queries for private addresses, to prevent the sort of problems those queries cause, seems to me to be fairly small. I probably agree. But I guess my question is where does it end? It ends when IPv4 ends. That is,

Re: rfc1918 impact

2003-10-15 Thread Leif Johansson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 snip | | Leif, | | I was speaking to the architectural issue, not the deployment one. None | of the three plug and play boxes I have here with NAT capability has any | inside DNS capability (either enabled by default or available to be | turned on).

RE: rfc1918 impact

2003-10-15 Thread Daniel Senie
At 05:24 PM 10/15/2003, Michel Py wrote: Leif / Iljitsch, It does sound like a recommendation to the effect of if you are going to use NAT, or construct a NAT box, then an 'inside DNS' mechanism would be a reasonable idea. And I would assume it would be an even better one if it made clear

Re: rfc1918 impact

2003-10-15 Thread Keith Moore
Keith will not like it, but NAT vendors will take suggestions that will make NAT better. I'd be happy for them to take suggestions from me, or IETF. But there's a big difference between saying if you must do NAT, please do it this way and NATs are good if they are implemented this way

RE: rfc1918 impact

2003-10-15 Thread Michel Py
Daniel / Iljitsch, Daniel Senie wrote: [NAT box acting as a DNS server] It also may be ill-advised, unless a switch is present for disabling it. Of course. While we can argue ISPs should not use RFC 1918 space, there are many using it, including some who use it because their equipment

Re: rfc1918 impact

2003-10-15 Thread Dean Anderson
Remember that Reverse lookups are optional. Many people who start of saying if reverse dns is configured correctly... don't seem to understand that reverse DNS is also properly configured when it is turned off. The abuse, and the numerous security vulnerabilities which have been introduced by the

RE: rfc1918 impact

2003-10-15 Thread Michel Py
Intercept would be nice in the following situations: - When Joe Blow has configured a static IP and static DNS servers that point to the ISP's DNS servers instead of the NAT box. Keith Moore wrote: so the next time Joe Blow is trying to figure out why a particular DNS server isn't