Dave CROCKER wrote:
1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic
upgrade to the IPv4 header, with more address bits, an extensibility
mechanisms for adding fields later, and removal of some bits that
weren't needed.
That is an option because, with port restricted
Not having any luck connecting - seems to be an issue near the server:
$ traceroute6 www.ietf.org
traceroute6 to www.ietf.org (2001:1890:1112:1::20) from
2001:630:d0:f103:216:cbff:fe8b:752e, 64 hops max, 12 byte packets
1 2001:630:d0:f103::2 0.529 ms 0.299 ms 0.321 ms
2
Le 8 oct. 2010 à 19:02, james woodyatt a écrit :
everyone--
IPv6 may have been born with a developmental disability, but we're not
dealing with a corpse yet. The patient is still alive, getting better, and
with a bit of love and proper care, might yet grow up to make better and
Le 8 oct. 2010 à 19:06, Phillip Hallam-Baker a écrit :
What if the key to IPv6 deployment is the realization that IPv6 can only be
deployed after we have solved the IPv4 address exhaustion problem?
IPv6 HAS ALREADY BEEN deployed where there was absolutely no address exhaustion
problem.
RFC
On 10/10/2010 2:51 PM, Steve Crocker wrote:
A compatible solution would have been better, but I don't think IPv4... --
were designed in a way that permitted a compatible extension.
Oh?
Perhaps:
1. Adopt an IPv6 as Steve Deering originally designed it[1]: A basic
upgrade to the IPv4
On 10/10/2010 3:44 PM, Steve Crocker wrote:
Mebbe. I confess I didn't study the details of the competing proposals at
the time because I was confident the people who were heavily involved surely
had things under control.
Alas...
Along with the imposition of ASN.1's complexities as the MIB
Le 9 oct. 2010 à 02:50, Fred Baker a écrit :
That's not limited to Germany. Would that dtag.de would use 172.16/12 rather
than 10/8 or 192.168/16, as the latter two seem to find their way into so
many home configurations.
Having the same prefix on each side of the residential NAT could be
-- isn't it a bit unseemly to be arguing over how we went so wrong with
IPv6--
100% agreement
It's time to use all what already works.
That is, use IPv4 with or without port restrictions.
It's also time to complete what already works with pieces that
miss to quickly extend IPv6 use to
Hello IETF Community...
Just a reminder that, if you have a problem you want solved, you'll get much
faster action by sending email to the secretariat. You will get many MORE
responses if you send to this list... but while I've been informed that that
is often much more therapeutic, it may not
Le 9 oct. 2010 à 02:23, Brian E Carpenter a écrit :
The transition model in 1995 was based on the assumption that vendors
and ISPs would support dual stack globally well *before* IPv4 exhaustion.
The fact that this did not happen is the problem.
Agreed.
Yet, the IETF has been IMHO, and to
Without getting into the question of whether your suggestion would have
helped anything in terms of transition and interoperability, it shares
one major flaw with the path we did adopt.
There is no incentive to spend resources to get there.
No matter how elegant it is technically, without a
Le 9 oct. 2010 à 04:47, Martin Rex a écrit :
Fred Baker wrote:
On Oct 8, 2010, at 3:42 PM, Martin Rex wrote:
Huh? Hardly anyone support IPv6 these days.
Well, the hardly anyone seems to include all Windows, Macosx,
50% of windows is on WindowsXP where IPv6 is off by default.
On
On 10/11/2010 8:25 AM, Joel M. Halpern wrote:
Without getting into the question of whether your suggestion would have helped
anything in terms of transition and interoperability, it shares one major flaw
with the path we did adopt.
There is no incentive to spend resources to get there.
This statement provides guidance from the IESG on selection of a
Document Shepherd for documents from IETF working groups and documents
from individuals.
RFC 4858 defines the role of the Document Shepherd for documents from
IETF working groups, and it also says:
The Document Shepherd is
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-zeilenga-ldap-dontusecopy-08
The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter Base Protocol'
draft-ietf-dime-rfc3588bis-25.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter Base Protocol'
draft-ietf-dime-rfc3588bis-25.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
This statement provides guidance from the IESG on selection of a
Document Shepherd for documents from IETF working groups and documents
from individuals.
RFC 4858 defines the role of the Document Shepherd for documents from
IETF working groups, and it also says:
The Document Shepherd is
The IESG has no problem with the publication of 'Comcast's Web
Notification System Design' draft-livingood-web-notification-09.txt as
an Informational RFC.
The IESG would also like the RFC-Editor to review the comments in
the datatracker
The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Dynamic Host Configuration Protocol Options for Coordinate-based
Location Configuration Information'
draft-ietf-geopriv-rfc3825bis-12.txt as a Proposed Standard
The IESG
20 matches
Mail list logo
