Subject: [v6ops] new draft: draft-troan-v6ops-6to4-update

From: <[email-masked]>
Date: Thu, 11 Aug 2011 06:55:01 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-troan-v6ops-6to4-update. Please take a look at it and comment.

---

From: "t.petch" <[email-masked]>
Date: Thu, 11 Aug 2011 16:04:40 +0200

I still think that what we want is an applicability statement and so would like
to see that in the title.

Clouds I think wrong, since cloud computing is all the rage and while this use
of the term is technically correct, I think that it will be widely
misunderstood.

eg
Applicability Statement for 6to4; a Last Resort.

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 11, 2011 3:55 PM
Subject: [v6ops] new draft: draft-troan-v6ops-6to4-update

>
> A new draft has been posted, at
http://tools.ietf.org/html/draft-troan-v6ops-6to4-update. Please take a look at
it and comment.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 11 Aug 2011 16:11:14 +0100

>    Implementations capable of acting as 6to4 routers MUST NOT enable
>    6to4 without explicit user configuration.  In particular, enabling
>    IPv6 forwarding on a device, MUST NOT automatically enable 6to4.

Could I suggest that this text explicitly references the definitions in
section 2 of RFC3068, and also that it should note that the guidelines here
apply both to 6to4 routers and also 6to4 relay routers as defined in
rfc3068?  It would be unfortunate to see an implementer reading "6to4
router" as the relay device rather and then effectively ignoring the
recommendations in this document.

>    When performing address selection, connections between an IPv4 source
>    and destination address SHOULD be preferred to connections either
>    between a 6to4 source address and a native v6 destination address, or
>    between a native v6 source address and a 6to4 destination address.

nit: either "v4" and "v6" or preferably "IPv4" and "IPv6".

Nick

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Aug 2011 08:13:02 -0700

Or even just: "6to4 Scenarios (SixthSense)"

Fred

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of t.petch
> Sent: Thursday, August 11, 2011 7:05 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [v6ops] new draft: draft-troan-v6ops-6to4-update
>

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 11 Aug 2011 09:12:51 -0700

> A new draft has been posted, at http://tools.ietf.org/html/draft-troan-v6ops-6to4-update. Please take a look at it and comment.

Is there a need for this to be standards track or even a working group document?

I strongly feel the IETF has spent too much time on this and any more
time is waste of effort.

RFC6343 is good enough.

Cameron

---

From: Rémi Després <[email-masked]>
Date: Thu, 11 Aug 2011 19:00:32 +0200

> I strongly feel the IETF has spent too much time on this and any more

+1

RD

---

From: Keith Moore <[email-masked]>
Date: Thu, 11 Aug 2011 13:11:20 -0400

> I strongly feel the IETF has spent too much time on this and any more

Several people have expressed a strong desire for a document that "updates" RFCs 3056 and 3068.  From a process point-of-view, it's not clear (to me) that such an update has to be a standards-track document.  But having it be standards-track would make it clear to the public that the statement represents (rough) IETF consensus.

From a process POV, this doesn't have to be a v6ops WG document.  It could be treated as an individual submission and given a 4-week community-wide Last Call.    That decision is up to the WG chairs and AD.     But even if it were treated as an individual submission, IESG would certainly ask v6ops participants to comment on it.   

For those who wish to minimize the amount of discussion on the v6ops list, comments to the authors (without cc'ing the v6ops list) are certainly welcome.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Fri, 12 Aug 2011 14:30:36 +0200

In your letter dated Thu, 11 Aug 2011 06:55:01 -0700 (PDT) you wrote:
>A new draft has been posted, at http://tools.ietf.org/html/draft-troan-v6ops-6
>to4-update. Please take a look at it and comment.

I guess it can't hurt to say that 6to4 must be off by default.

Then the draft proceeds to disucss address selection. And that's a bit 
curious. The text there is already covered by 3484bis. But the draft is
strangely silent about whether to prefer an IPv4 connection over a 
connection between two 6to4 addresses. (This is also covered in 3484bis,
so that text should at least refer to 3484bis)

---

From: Tim Chown <[email-masked]>
Date: Fri, 12 Aug 2011 13:57:32 +0100

> I guess it can't hurt to say that 6to4 must be off by default.

Which is already said in -advisory.

> so that text should at least refer to 3484bis)

I noticed that too. This document adds little new, and if anything only adds confusion.

Tim

---

From: Keith Moore <[email-masked]>
Date: Fri, 12 Aug 2011 09:34:59 -0400

> so that text should at least refer to 3484bis)

My impression from what I heard in Quebec City is that 3484-revise might still take a while to get through the 6man WG, and it seems that many people want an RFC that "updates" 6to4 to be issued as quickly as possible.  If 3484-revise were approved before -update is submitted, I agree that an explicit reference to 3484bis in -update would be appropriate. 

Keith

---

From: Philip Homburg <[email-masked]>
Date: Fri, 12 Aug 2011 15:58:13 +0200

In your letter dated Fri, 12 Aug 2011 09:34:59 -0400 you wrote:
>My impression from what I heard in Quebec City is that 3484-revise might >still take a while to get through the 6man WG, and it seems that many >people want an RFC that "updates" 6to4 to be issued as quickly as >possible.  If 3484-revise were approved before -update is submitted, I >agree that an explicit reference to 3484bis in -update would be >appropriate. 

I don't think a non-normative reference to RFC3484-revise would hurt.

It is directed at different products/parts of products anyhow. Keeping 
6to4 off by default applies to routers implementing 6to4 functionality.
(And in theory also hosts with 6to4 functionality).

RFC3484-revise has to be implemented by each an every host even if the host
doesn't do anything with 6to4 because a local router may provide 6to4 to
the host.

---

From: Tim Chown <[email-masked]>
Date: Fri, 12 Aug 2011 15:08:28 +0100

3484-bis should be being last called.   I'll pop Brian and Bob a mail.   The only slight question mark on it was a privacy bit indicator, but that can be resolved in WGLC.

Tim

On 12 Aug 2011, at 14:58, Philip Homburg wrote:

>> My impression from what I heard in Quebec City is that 3484-revise might =
>> still take a while to get through the 6man WG, and it seems that many =
>> people want an RFC that "updates" 6to4 to be issued as quickly as =
>> possible.  If 3484-revise were approved before -update is submitted, I =
>> agree that an explicit reference to 3484bis in -update would be =
>> appropriate.=20
>