In message alpine.bsf.2.00.1107042329060.89...@joyce.lan, John R. Levine wri
tes:
The naive approach of reversing the address, converting to nibbles
and appending a suffix won't scale.
For IPv6 if you did the reverse of /48, /52, /56, /60 and /64
prefixes, which matches delegation
John R. Levine jo...@iecc.com wrote:
DNSBLs already set the min pretty low, e.g. 150 sec for Spamhaus. Doesn't
really matter how low it is if you have so many entries that they force out
the useful ones.
The really important records are the delegation chain NS records. It is
not so necessary
Mark Andrews ma...@isc.org wrote:
DNS[WB]L's have never been a good fit to the DNS, rather they have
not been a bad enough fit to require something better to be done.
Oh come off it, they are just as good a fit to the DNS as reverse DNS is.
The naive approach of reversing the address,
Keith Moore mo...@network-heretics.com wrote:
Yes, but rDNS PTR lookups always have been pretty much meaningless
anyway, and will only get worse in IPv4 due to LSN.
Reverse DNS for an LSN is just as informative as automatically populated
reverse DNS (and much more convenient than a whois
On Jul 5, 2011, at 6:58 AM, Tony Finch wrote:
Keith Moore mo...@network-heretics.com wrote:
Yes, but rDNS PTR lookups always have been pretty much meaningless
anyway, and will only get worse in IPv4 due to LSN.
Reverse DNS for an LSN is just as informative as automatically populated
From: Ronald Bonica rbon...@juniper.net
I think that I get it. There is no IETF consensus regarding the
compromise proposed below. ...
But there is no rough consensus to do that either.
That is the claim of an appeal on the table. Let's run the appeal
process and
On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote:
- In order for the new draft to be published, it must achieve both V6OPS WG
and IETF consensus
If anyone objects to this course of action, please speak up soon.
Great, back to square one.
Is the reasoning behind the
Very well said Lorenzo.
+1
Unless Ron describes exactly one by one real reasons to give up on
draft-ietf-v6ops-6to4-to-historic and majority of v6ops WG agrees with
those reasons IMHO the document should proceed as is.
It will say that if 6-to-4 is implemented, it must be turned
off by
Hi Keith,
I personally don't have any objection to the notion that 6to4 should
be off by default and should require explicit configuration to enable
it.
Is there any feature (perhaps other then netboot) on commercial or open
source routers which is not off by default and which would require
In your letter dated Sat, 2 Jul 2011 16:02:47 -0400 you wrote:
Is the reasoning behind the decision explained somewhere? My reading of the
threads on the subject in v6ops was that the opposition to 6to4-historic was a
small but vocal minority, and I thought that qualified as rough consensus.
If anyone objects to this course of action, please speak up soon.
i object. as measured on the real internet, not the ietf bar, 6to4
sucks caterpillar snot. it is damaging to the users and to the users'
view of ipv6.
Great, back to square one.
Is the reasoning behind the decision
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
We know it can operate correctly and reliably if it
is configured correctly.
... and in networks where there are public IP addresses and no firewalling,
and... etc. etc.
But we already had
All,
Perhaps declaring 6to4 deprecated rather than historic would have a
better chance of consensus.
Pardon my ignorance, but where is the document describing the
implications of historic{,al} vs deprecated?
This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:
A
On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore mo...@network-heretics.comwrote:
Is the reasoning behind the decision explained somewhere? My reading of
the threads on the subject in v6ops was that the opposition to 6to4-historic
was a small but vocal minority, and I thought that qualified as
And who says that rough consensus of the entire IETF community is
that this draft should not be published? Were there public discussions
to that effect that came to this conclusion?
that is usually determined when the iesg last calls the document after
the wg has passed it to the iesg.
the
Perhaps declaring 6to4 deprecated rather than historic would have a
better chance of consensus.
Pardon my ignorance, but where is the document describing the
implications of historic{,al} vs deprecated?
This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:
A
Yes, the Linksys E2000, E3000, E4200, WRT610N, and a small batch of Apple
Airports had 6to4 on by default, but the latest firmware versions turn that
off.
Frank
-Original Message-
From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of
Keith Moore
Sent: Saturday, July
1) as measured on the real internet, not the ietf bar, 6to4 sucks
caterpillar snot
2) perhaps that minority was also vocal in the back room
3) yes, but that will be a year from now. in the ietf, delay is one form of
death
Responses follow:
1) While not stated so colorfully,
On Sun, Jul 3, 2011 at 5:05 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote:
I think there is pretty much complete consensus that i) 6to4 doesn't work
in several very common environments (behind a NAT, etc, etc), and that
therefore, ii) at the very least, it should be disabled by default (and
On Sun, Jul 3, 2011 at 5:11 AM, Keith Moore mo...@network-heretics.comwrote:
And who says that rough consensus of the entire IETF community is that
this draft should not be published? Were there public discussions to that
effect that came to this conclusion?
There's clearly a lack of
On Sun, Jul 3, 2011 at 5:49 AM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
Declaring 6to4 to be historic might encourage native IPv6 deployment,
but I think it will also make trialing IPv6 much harder.
We don't need to trial the IPv6 protocol. There are hundreds of
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith
i...@69706e6720323030352d30312d31340a.nosense.org wrote:
I don't object to what has been proposed, yet I object to
6to4-historic because I'm an extremely happy anycast 6to4 user
It works for me, so there's obviously no problem. When you think of
Subject:
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
From:
Keith Moore mo...@network-heretics.com
Date:
Sat, 2 Jul 2011 23:10:47 -0400
To:
Cameron Byrne cb.li...@gmail.com
CC:
v6...@ietf.org v6...@ietf.org, IETF Discussion ietf@ietf.org
Precedence:
list
MIME-Version:
1.0 (Apple Message
Nope. The v6ops chairs saw consensus in v6ops to support it. Can you
point to significant strength of opinion of the wider IETF community,
but not in v6ops, that has reason to oppose it?
That's not how it works. You have to get consensus in IETF, not in
v6ops.
when it is last called. and
On Jul 3, 2011, at 1:47 AM, Keith Moore wrote:
Some of them were posted to the IETF list. IESG may have received others
privately. That is permitted by our process.
This is a frustrating conversation. Everybody who supported the consensus in
v6ops is an IETF participant, and their wishes
Keith Moore wrote:
On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote:
IMHO Right now, we need services with native IPv6 based interfaces, with
equivalent performance and equivalent features and equivalent price that we
have today with IPv4. Anything that detracts from the roll out of native
Discussion isn't evidence, as people usually don't post any data to
support their assertions.
And yet, they did.
This whole thing is getting silly, and I'm tired of repeating myself. I
think Lorenzo did a great job of explaining some more of the downsides
of 6to4 and I don't have
Hi,
On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote:
There's clearly a lack of consensus to support it.
There's two very vocal persons opposing it and a much larger number of
people that support it, but have not the time to write a similarily
large amount of e-mails. For me, this
In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote:
Unfortunately, in the 20% of the time that it's not working, Google has no
idea that the user has a 2002::/16 address. Google only knows, after the
fact, that the user suffered a 20 or 75-second timeout and was not happy. So
it would
And b.
And probably it is too much effort for something that will go away
(probably sooner that we expect) with the exhaustion of IPv4 addresses for each
ISP's customer (6to4 does not work with NATs, and they are here).
-as
On 3 Jul 2011, at 11:40, Keith Moore wrote:
I
Hannes,
None of the current OAuth WG document address discovery in any way, so clearly
there will be no use of XRD. But the OAuth community predating the IETF had
multiple proposals for it. In addition, multiple times on the IETF OAuth WG
list, people have suggested using host-meta and XRD for
FYI there is a form of discovery for OAuth defined in
http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-02 which uses LINK
headers.
From: Eran Hammer-Lahav e...@hueniverse.com
To: Hannes Tschofenig hannes.tschofe...@gmx.net; Mark Nottingham
And b.
And probably it is too much effort for something that will go away
(probably sooner that we expect) with the exhaustion of IPv4 addresses for
each ISP's customer (6to4 does not work with NATs, and they are here).
It's clearly inappropriate for operators to be
This is the Third call for Volunteers for the 2011-12 Nomcom. We are
almost through the volunteer period so if you are considering
volunteering, please do so very soon.
We have had a very good response to the initial call for volunteers and
I am pleased to report that we have 84 volunteers thus
The OpenID Connect folks have been using Simple Web Discovery, which is
as I understand it a rough translation of XRD into JSON, with a couple
of simplifying changes. (Mike, want to throw your hat in on this one?)
http://tools.ietf.org/html/draft-jones-simple-web-discovery-00
-- Justin
On Mon,
I've reviewed this document as part of the transport area directorate's ongoing
effort to review key IETF documents. These comments were written primarily for
the
transport area directors, but are copied to the document's authors for their
information and to allow them to address any issues
FWIW, the Dynamic OAuth Client Registration proposal made by the User-Managed
Access folks:
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00
...makes use of XRD, hostmeta, and discovery, as does the OAuth-based UMA
protocol itself:
On Sat, 2 Jul 2011 20:54:50 +0200
Lorenzo Colitti lore...@google.com wrote:
On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote:
- In order for the new draft to be published, it must achieve both V6OPS WG
and IETF consensus
If anyone objects to this course of
On Sat, 2 Jul 2011 12:21:36 -0700
Cameron Byrne cb.li...@gmail.com wrote:
On Jul 2, 2011 11:55 AM, Lorenzo Colitti lore...@google.com wrote:
On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net wrote:
- In order for the new draft to be published, it must achieve both V6OPS
On Sun, 3 Jul 2011 10:10:03 +0900
Erik Kline e...@google.com wrote:
All,
Perhaps declaring 6to4 deprecated rather than historic would have a
better chance of consensus.
Pardon my ignorance, but where is the document describing the
implications of historic{,al} vs deprecated?
This
On Sat, 02 Jul 2011 19:44:24 -0700
Doug Barton do...@dougbarton.us wrote:
On 07/02/2011 18:50, Mark Smith wrote:
Where is the evidence that 6to4 is holding back native IPv6
deployment?
It's been discussed ad nauseum in numerous fora.
Discussion isn't evidence, as people usually don't
On Sat, 2 Jul 2011 21:02:02 -0700
Cameron Byrne cb.li...@gmail.com wrote:
snip
In the meantime, i null route the 6to4 anycast address because it
creates half open state in my CGN. Been doing that for at least 5
years.
So, to be clear, you're not making an observation that 6to4 is broken,
On Sat, 2 Jul 2011 21:59:24 -0700
Joel Jaeggli joe...@bogus.com wrote:
This line of discussion is not productive...
Between them the 4 largest north american wireless carriers need ~18 /8s to
assign public ipv4 addresses to their wireless cpe...
they don't have that and there's no-where
Totally agree.
Regardless of my position on this specific draft, if it has been declared
no consensus, now it not wise to go forward, declare consensus and
accept the appeal.
Credibility is first.
Regards,
Jordi
-Mensaje original-
De: Noel Chiappa j...@mercury.lcs.mit.edu
The naive approach of reversing the address, converting to nibbles
and appending a suffix won't scale.
I don't understand why the setup is OK for reverse DNS but not blacklists.
One obvious reason is that the most widely used DNSBL server doesn't
return NODATA vs. NXDOMAIN according to
Noel,
I didn't say that I was going to push draft-ietf-v6ops-6to4-to-historic through
without running the process. I said that draft-ietf-v6ops-6to4-to-historic has
made it all the way past IESG approval. There is an appeal on the table (at the
WG level) questioning whether
On 7/5/2011 3:56 AM, Tony Finch wrote:
Mark Andrewsma...@isc.org wrote:
DNS[WB]L's have never been a good fit to the DNS, rather they have
not been a bad enough fit to require something better to be done.
Oh come off it, they are just as good a fit to the DNS as reverse DNS is.
The naive
For an application that is likely to encounter a different IP address for
essentially every query, across a very large number of queries, the only
solution I see available is to use a different cache.
Seems reasonable. I gather that there are already caches with the
ability to partition
On 7/5/2011 10:31 AM, John Levine wrote:
For an application that is likely to encounter a different IP address for
essentially every query, across a very large number of queries, the only
solution I see available is to use a different cache.
Seems reasonable. I gather that there are already
Dave CROCKER d...@dcrocker.net wrote:
For an application that is likely to encounter a different IP address for
essentially every query, across a very large number of queries, the only
solution I see available is to use a different cache.
This has been operational common sense for many years.
On 7/5/2011 10:59 AM, Tony Finch wrote:
Dave CROCKERd...@dcrocker.net wrote:
For an application that is likely to encounter a different IP address for
essentially every query, across a very large number of queries, the only
solution I see available is to use a different cache.
This has
I believe that the solution is to have the applications, themselves,
distinguish the cache they are using (or the containing library). A
blocklist app needs to use a different library/cache than a web
browser.
You could do it either way. Either you could adjust the MTAs to have
a new parameter
I shudder to think that this is a prerequisite for declaring something Historic.
If some RFC meant to solve some problem turns out not only to be a bad idea but
also shows that the problem itself is essentially intractable, I don't think
it's practical at all to require a replacement before
I think this draft specifies a very useful protocol, which we have used at our
site and which has been a valuable multicast debugging tool.
The specification and implementations have evolved over maybe 5-6 years or so.
The implementations we've used have been of various stages of the
I found that I have an extra reservation at the IETF rate
($229/night)for Sunday to Friday at the Hilton.
If anyone is interested I can transfer the reservation.
geoff
___
Ietf mailing list
Ietf@ietf.org
On 7/5/2011 2:10 PM, Tim Chown wrote:
I think this draft specifies a very useful protocol, which we have used at our
site and which has been a valuable multicast debugging tool.
The specification and implementations have evolved over maybe 5-6 years or so.
The implementations we've used have
Hi, all,
This doc also claims that:
The SRV record allows
DNS resolvers to search for particular applications and underlying
transports (for example, HTTP running over TLS, see [RFC2818]) and to
learn the domain name and port where that service resides in a given
administrative
Gert Doering wrote:
On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote:
There's clearly a lack of consensus to support it.
There's two very vocal persons opposing it
There were more than two clearly opposing, and there is no need to
further fuel the heated discussion by everyone
On 7/5/2011 3:12 PM, Joe Touch wrote:
The SRV record allows
DNS resolvers to search for particular applications and underlying
transports (for example, HTTP running over TLS, see [RFC2818]) and to
learn the domain name and port where that service resides in a given
administrative domain.
Greetings,
I note that draft-ietf-v6ops-6to4-advisory-02, now approved for
publication and in the RFC Editor's queue, has a minor dependency on
draft-ietf-v6ops-6to4-to-historic, specifically at the end of
Section 1 (bottom of p. 3):
A companion document [I-D.ietf-v6ops-6to4-to-historic]
The IESG has received a request from the DNS-based Authentication of
Named Entities WG (dane) to consider the following document:
- 'Use Cases and Requirements for DNS-based Authentication of Named
Entities (DANE)'
draft-ietf-dane-use-cases-04.txt as an Informational RFC
The IESG plans to
The IESG has approved the following document:
- 'Addition of the Camellia Cipher Suites to Transport Layer Security
(TLS)'
(draft-kanno-tls-camellia-03.txt) as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact
A new IETF working group has been proposed in the Internet Area. The
IESG has not made any determination as yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list (i...@ietf.org) by Tuesday,
July 12,
A modified charter has been submitted for the Protocol Independent
Multicast (pim) working group in the Routing Area of the IETF. The IESG
has not made any determination as yet. The modified charter is provided
below for informational purposes only. Please send your comments to the
IESG
A new Request for Comments is now available in online RFC libraries.
RFC 6274
Title: Security Assessment of the Internet
Protocol Version 4
Author: F. Gont
Status: Informational
Stream: IETF
Date:
The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document:
- 'Mtrace Version 2: Traceroute Facility for IP Multicast'
draft-ietf-mboned-mtrace-v2-08.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has received a request from the Multicast Security WG (msec) to
consider the following document:
- 'The Group Domain of Interpretation'
draft-ietf-msec-gdoi-update-09.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
67 matches
Mail list logo
