On 13 Jun 2011, at 16:28, Noel Chiappa wrote:
If 6to4 has problems, fine, write a document that says something like '6to4
won't work for a host behind a NAT box because the host won't know it's true
IPv4 global-scope address - so you should also not turn 6to4 on by default'
and
Through confusion, I have perpetrated a major screw-up regarding this
document and its companion, draft-ietf-pcn-sm-edge-behaviour. Somewhere
around Christmas I received a number of comments on the two documents. I
have fixed all of them except the comment requesting sections on
operations and
On Fri, Jun 10, 2011 at 9:18 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote:
Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure
rate when connecting to dual-stack servers than Mac OS 10.6.5 - and
the
only change is to not use 6to4 by default.
...
So
On Fri, Jun 10, 2011 at 10:15 AM, james woodyatt j...@apple.com wrote:
I don't want anybody to be misled by this statement. I think what Lorenzo
meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the
policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source
On Jun 10, 2011, at 09:38 , Lorenzo Colitti wrote:
I fundamentally disagree. I really don't think that 6to4 is used by lots of
people for applications that wouldn't just use (more reliable) IPv4 if 6to4
wasn't there.
The same is often said about IPv6 in general.
That's not meant to be
Michel,
making 6to4 historic does not affect 6rd. I think the draft says that much too.
I don't think we are saying that native necessarily is better than tunnels.
we are saying unmanaged tunnels crossing the Internet is bad.
6rd is managed and contained within a single SP's network.
cheers,
Ole
On Jun 14, 2011, at 1:43 PM, Ole Troan wrote:
making 6to4 historic does not affect 6rd. I think the draft says that much
too.
I don't think we are saying that native necessarily is better than tunnels.
we are saying unmanaged tunnels crossing the Internet is bad.
I think this misses the
Keith is correct, and the further issue is that the *-only-* reason the
'poorly managed' relays are in the path is that the content providers are
refusing to deploy the matching 6to4 router that would take a direct
connection from the customer.
6to4 direct between the content and consumer is
On Jun 14, 2011, at 2:16 PM, Tony Hain wrote:
Keith is correct, and the further issue is that the *-only-* reason the
'poorly managed' relays are in the path is that the content providers are
refusing to deploy the matching 6to4 router that would take a direct
connection from the customer.
On Jun 14, 2011, at 11:16 AM, Tony Hain wrote:
Keith is correct, and the further issue is that the *-only-* reason the
'poorly managed' relays are in the path is that the content providers are
refusing to deploy the matching 6to4 router that would take a direct
connection from the customer.
On Jun 14, 2011, at 2:36 PM, Joel Jaeggli wrote:
On Jun 14, 2011, at 11:16 AM, Tony Hain wrote:
Keith is correct, and the further issue is that the *-only-* reason the
'poorly managed' relays are in the path is that the content providers are
refusing to deploy the matching 6to4 router that
On Jun 14, 2011, at 11:46 AM, Keith Moore wrote:
On Jun 14, 2011, at 2:36 PM, Joel Jaeggli wrote:
On Jun 14, 2011, at 11:16 AM, Tony Hain wrote:
Keith is correct, and the further issue is that the *-only-* reason the
'poorly managed' relays are in the path is that the content providers
On Jun 14, 2011, at 2:52 PM, Joel Jaeggli wrote:
Keith is correct, and the further issue is that the *-only-* reason the
'poorly managed' relays are in the path is that the content providers are
refusing to deploy the matching 6to4 router that would take a direct
connection from the customer.
Hi Violeta,
I am fine with the latest version of the document.
Thank you,
Yaron
On 06/14/2011 09:41 PM, Cakulev, Violeta (Violeta) wrote:
Hi Yaron,
Thanks for the suggestions.
Please see inline.
-Violeta
-Original Message-
I did not say deploy you own relay ... that is braindead and doesn't even
come close to understanding how the technology works. A 6to4 router at the
content end is not a relay because it is strictly dealing with 2002:: on
both sides. The only time a relay is required is to transit between the
Resending, apologies if you see it twice.
On 06/14/2011 11:18 PM, Yaron Sheffer wrote:
Hi Violeta,
I am fine with the latest version of the document.
Thank you,
Yaron
On 06/14/2011 09:41 PM, Cakulev, Violeta (Violeta) wrote:
Hi Yaron,
Thanks for the suggestions.
Please see inline.
From: Keith Moore mo...@network-heretics.com
As I understand it, the breakage mostly happens when the traffic
doesn't take exactly the same path as IPv4 would, but rather when the
traffic moves between the IPv4 world and the IPv6 world (or vice versa)
via a relay router
In message 20110615022008.0816818c...@mercury.lcs.mit.edu, Noel Chiappa write
s:
From: Keith Moore mo...@network-heretics.com
As I understand it, the breakage mostly happens when the traffic
doesn't take exactly the same path as IPv4 would, but rather when the
traffic
A new IETF working group has been proposed in the Transport 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,
June 21,
A new IETF working group has been formed in the Operations and
Management Area. For additional information, please contact the Area
Directors or the WG Chairs.
IPv6 Site Renumbering (6renum)
---
Current Status: Active Working Group
Chair:
Tim Chown
A new IETF working group has been formed in the Applications Area. For
additional information, please contact the Area Directors or the WG
Chairs.
Protocol to Access White Space Databases (paws)
Current Status: Active Working Group
Chairs:
The Web Authorization Protocol Working Group (oauth) in the Security
Area of the IETF has been rechartered. For additional information,
please contact the Area Directors or the working group Chairs.
Web Authorization Protocol Working Group (oauth)
---
Current Status: Active
The IESG has approved the following document:
- 'The A+P Approach to the IPv4 Address Shortage'
(draft-ymbk-aplusp-10.txt) as an Experimental RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Ron Bonica.
A URL of this
The IESG has approved the following document:
- 'SIP (Session Initiation Protocol) Usage of the Offer/Answer Model'
(draft-ietf-sipping-sip-offeranswer-18.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 non-working group email list has been created.
List address: weba...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/webapps/
To subscribe: https://www.ietf.org/mailman/listinfo/webapps
Description: Post-IETF-80 discussion of the impact of .js, HTML5 and related
work on
the
The IESG has received a request from the FEC Framework WG (fecframe) to
consider the following document:
- 'Forward Error Correction (FEC) Framework'
draft-ietf-fecframe-framework-15.txt as a Proposed Standard
The IESG reviewed this draft and requested substantial changes. This
is a second
The Virtual Router Redundancy Protocol (vrrp) working group in the
Routing Area has concluded. The IESG contact persons are Adrian Farrel
and Stewart Bryant.
The mailing list will remain active.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
27 matches
Mail list logo
