Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt

From: [email-masked]
Date: Sun, 04 Jan 2015 11:04:16 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : Deprecating Anycast Prefix for 6to4 Relay Routers
        Authors         : Ole Troan
                          Brian Carpenter
	Filename        : draft-ietf-v6ops-6to4-to-historic-10.txt
	Pages           : 7
	Date            : 2015-01-04

Abstract:
   Experience with the "Connection of IPv6 Domains via IPv4 Clouds
   (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that
   when used in its anycast mode, the mechanism is unsuitable for
   widespread deployment and use in the Internet.  This document
   therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay
   Routers", be made obsolete and moved to historic status.  It also
   obsoletes RFC 6732 "6to4 Provider Managed Tunnels".  It recommends
   that future products should not support 6to4 anycast and that
   existing deployments should be reviewed.  This complements the
   guidelines in RFC 6343.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Jan 2015 08:10:29 +1300

This version is intended to respond to Keith Moore's comments before
the holidays, with a number of clarifications and simplifications.
There is not intended to be any change to the actual recommendations.

   Brian
On 05/01/2015 08:04, [email-masked] wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 04 Jan 2015 21:47:49 +0000

> There is not intended to be any change to the actual recommendations.

Brian,

from a future historical point of view, it's a little disappointing to see
the specific operational problems disappearing from the draft.  Having said
that, it's more important at this stage to get the deprecation out the door
rather than having another round of tyre-kicking.  You can count this as
support for draft -10.

Nick

---

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 05 Jan 2015 11:51:36 -0600

> rather than having another round of tyre-kicking.  You can count this as

I think the references to rfc6343 do adequately capture some amount of
the operational problems that have led to this draft, and as a whole -10
looks good.

Dale

---

From: David Farmer <[email-masked]>
Date: Fri, 09 Jan 2015 15:44:40 -0600

> There is not intended to be any change to the actual recommendations.

I think the new draft is an improvement, I did a detailed review and 
have a list of several items for you to consider;

1. In section 3, the second sentence of the first paragraph and the 
first sentence of the second paragraph seem to say virtually the same thing.

I suggest leaving the first paragraph as-is, deleting the first sentence 
of the second paragraph, and slightly rewriting the remainder of the 
second paragraph, maybe as follows;

    In the forward direction a 6to4 node will send native IPv6 traffic
    to a 6to4 relay router, that is connected both to the 6to4 cloud and
    to native IPv6.  In the reverse direction a 2002::/16 route is
    injected into the native IPv6 routing domain to attract traffic from
    native IPv6 nodes to a 6to4 relay router.  It is expected that
    traffic will use different relays in the forward and reverse
    direction.

2. The last paragraph of section 3 says;

    Peer-to-peer usage of the 6to4 mechanism, not depending on the
    anycast mechanism, might exist in the Internet, largely unknown to
    operators.  This is harmless to third parties and the current
    document is not intended to prevent such traffic continuing.

This could be taken by some to imply that the document intends to 
prevent anycast 6to4 traffic from continuing, more than simply 
deprecating anycast 6to4, I'd suggest rewriting the paragraph, maybe as 
follows;

    Peer-to-peer usage of the 6to4 mechanism exists in the Internet,
    likely unknown to many operators.  This usage is harmless to third
    parties and is not dependent on the anycast 6to4 mechanism that this
    document deprecates.

3. In section 4, first paragraph, I believe anycast 6to4 needs to be 
default disabled in any new 6to4 implementation.  Maybe add the 
following to the paragraph;

    However, if included in any new implementations, the anycast 6to4
    mechanism MUST NOT be enabled by default.

4. Section 4, fourth paragraph, is confusing me. It says;

    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.

As written the first sentences seems to be repeating the last sentence 
of third paragraph, just above it.  I think maybe it was meant to say;

    Implementations capable of acting as IPv6 routers MUST NOT enable...

5. In previous discussions of the text in section 4, sixth paragraph, 
the issue of uRPF came up.  I think something about uRPF, BCP38, and 
BCP84 should get added to this paragraph.  Maybe something like this;

    This includes ensuring that traffic from a local 6to4 return relay
    with a source address of 192.88.99.1 is allowed through
    Anti-spoofing filters such as those described in [BCP38] and [BCP84]
    or through Unicast Reverse-Path-Forwarding (uRPF) checks.

6. On the more general question of filtering and the intended affect of 
deprecation, I would like to see the issue more strongly addressed with 
something like the following added;

    This deprecation does not constitute a recommendation for the
    generalized filtering of traffic or routes for 6to4 or even anycast
    6to4.  Both the basic 6to4 and anycast 6to4 mechanisms remain valid
    traffic to be carried on the Internet.  In general terms this
    document simply recommends against further deployment of the anycast
    6to4 mechanism, calls for current 6to4 deployments to evaluate the
    efficacy of continued use of the anycast 6to4 mechanism, and makes
    recommendations intended to prevent any use of 6to4 from hampering
    broader deployment and use of native IPv6 on the Internet as a
    whole.

7. We should have recommendations applicable to operators of the hosts, 
something like the following;

    All hosts using 6to4 SHOULD support the IPv6 address selection
    policy described in [RFC6724] or be manually configured with an
    address selection policy preferring IPv4 over a 6to4 source
    address.  Further, 6to4 hosts SHOULD support "Happy Eyeballs"
    [RFC6555] or use a browser supporting "Happy Eyeballs".  Any hosts
    not meeting these requirements SHOULD NOT use, or continue to use,
    the deprecated anycast 6to4 mechanism.

9. On a higher level, section 4 seem to be a bit of a hodgepodge of 
issues and ideas;  I'm thinking split out the recommendations into a 
separate section.  Maybe even split the recommendations into separate 
operational and implementation sections or sub-sections if you prefer.

Taking this into account, including the issues for section 4 from above 
and taking editorial license to rearrange and rewrite a few things, I 
suggest something like the following;

---

4.  Deprecation

    This document formally deprecates the anycast 6to4 transition
    mechanism defined in [RFC3068] and the associated anycast IPv4
    address 192.88.99.1. It is no longer considered to be a useful
    service of last resort.

    The prefix 192.88.99.0/24 MUST NOT be reassigned for other use except
    by a future IETF standards action.

    The guidelines in Section 4 of [RFC6343] remain valid for those who
    choose to continue operating Anycast 6to4 despite its deprecation.
    However, 6to4 Provider Managed Tunnels [RFC6732] will no longer be
    necessary, so they are also deprecated by this document.

    The basic unicast 6to4 mechanism defined in [RFC3056] and the
    associated 6to4 IPv6 prefix 2002::/16 are not deprecated.  The
    default address selection rules specified in [RFC6724] are not
    modified.

    This deprecation does not constitute a recommendation for the
    generalized filtering of traffic or routes for 6to4 or even anycast
    6to4.  Both the basic 6to4 and anycast 6to4 mechanisms remain valid
    traffic to be carried on the Internet.  In general terms this
    document simply recommends against further deployment of the anycast
    6to4 mechanism, calls for current 6to4 deployments to evaluate the
    efficacy of continued use of the anycast 6to4 mechanism, and makes
    recommendations intended to prevent the use of 6to4 from hampering
    broader deployment and use of native IPv6 on the Internet as a
    whole.

    Incidental references to 6to4 should be reviewed and possibly removed
    from other IETF documents if and when they are updated.  These
    documents include RFC3162, RFC3178, RFC3790, RFC4191, RFC4213,
    RFC4389, RFC4779, RFC4852, RFC4891, RFC4903, RFC5157, RFC5245,
    RFC5375, RFC5971, RFC6071 and RFC6890.

5. Implementation Recommendations

    Implementations MUST NOT enable the basic unicast 6to4 mechanism
    defined in [RFC3056] without explicit user configuration.  Further,
    it is NOT RECOMMENDED to include the anycast 6to4 mechanism defined
    in [RFC3068] in any new implementations.  However, if included in
    any new implementations, the anycast 6to4 mechanism MUST NOT be
    enabled by default.

    All implementations that include 6to4 SHOULD also include "Happy
    Eyeballs" [RFC6555] and the default address selection rules
    specified in [RFC6724].

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

6. Operational Recommendations

    All hosts using 6to4 SHOULD support the default address selection
    rules specified in [RFC6724] or be manually configured with an
    address selection rule preferring IPv4 over a 6to4 source
    address.  Further, 6to4 hosts SHOULD support "Happy Eyeballs"
    [RFC6555] or use a browser supporting "Happy Eyeballs".  Any hosts
    not meeting these requirements SHOULD NOT use, or continue to use,
    the deprecated anycast 6to4 mechanism.

    Current operators of an anycast 6to4 relay with the IPv4 address
    192.88.99.1 SHOULD review the information in [RFC6343] and the
    present document, and then consider carefully whether the anycast
    relay can be discontinued as traffic diminishes.  Internet service
    providers that do not operate an anycast relay but do provide their
    customers with a route to 192.88.99.1 SHOULD verify that it does in
    fact lead to an operational anycast relay, as discussed in
    Section 4.2.1 of [RFC6343].  Furthermore, Internet service providers
    and other network providers MUST NOT originate a route to
    192.88.99.1, unless they actively operate and monitor an anycast 6to4
    relay service as detailed in Section 4.2.1 of [RFC6343].

    Operators of a 6to4 return relay responding to the IPv6 prefix
    2002::/16 SHOULD review the information in [RFC6343] and the present
    document, and then consider carefully whether the return relay can be
    discontinued as traffic diminishes.  To avoid confusion, note that
    nothing in the design of 6to4 assumes or requires that return packets
    are handled by the same relay as outbound packets.  As discussed in
    Section 4.5 of RFC 6343, content providers might choose to continue
    operating a return relay for the benefit of their own residual 6to4
    clients.  Internet service providers SHOULD announce the IPv6 prefix
    2002::/16 to their own customers if and only if it leads to a
    correctly operating return relay as described in RFC 6343.  IPv6-only
    service providers, including those operating a NAT64 service
    [RFC6146], are advised that their own customers need a route to such
    a relay in case a residual 6to4 user served by a different service
    provider attempts to communicate with them.

    Networks SHOULD NOT filter out packets whose source address is
    192.88.99.1, because this is normal 6to4 traffic from a 6to4 return
    relay somewhere in the Internet.  This includes ensuring that traffic
    from a local 6to4 return relay with a source address of 192.88.99.1
    is allowed through Anti-spoofing filters such as those described in
    [BCP38] and [BCP84] or through Unicast Reverse-Path-Forwarding
    (uRPF) checks.

Thanks

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jan 2015 11:04:34 +1300

Hi,

Since we are already post-WG Last Call, the authors will wait for
direction from the WG Chairs before making any further changes.

Regards
   Brian

On 10/01/2015 10:44, David Farmer wrote:
> I think the new draft is an improvement, I did a detailed review and have a list of several items for you to consider;
> 
> 1. In section 3, the second sentence of the first paragraph and the first sentence of the second paragraph seem to say virtually
> the same thing.
> 
> I suggest leaving the first paragraph as-is, deleting the first sentence of the second paragraph, and slightly rewriting the
> remainder of the second paragraph, maybe as follows;
> 
> This could be taken by some to imply that the document intends to prevent anycast 6to4 traffic from continuing, more than simply
> deprecating anycast 6to4, I'd suggest rewriting the paragraph, maybe as follows;
> 
> 3. In section 4, first paragraph, I believe anycast 6to4 needs to be default disabled in any new 6to4 implementation.  Maybe add
> the following to the paragraph;
> 
> As written the first sentences seems to be repeating the last sentence of third paragraph, just above it.  I think maybe it was
> meant to say;
> 
> 5. In previous discussions of the text in section 4, sixth paragraph, the issue of uRPF came up.  I think something about uRPF,
> BCP38, and BCP84 should get added to this paragraph.  Maybe something like this;
> 
> 6. On the more general question of filtering and the intended affect of deprecation, I would like to see the issue more strongly
> addressed with something like the following added;
> 
> 7. We should have recommendations applicable to operators of the hosts, something like the following;
> 
> 9. On a higher level, section 4 seem to be a bit of a hodgepodge of issues and ideas;  I'm thinking split out the
> recommendations into a separate section.  Maybe even split the recommendations into separate operational and implementation
> sections or sub-sections if you prefer.
> 
> Taking this into account, including the issues for section 4 from above and taking editorial license to rearrange and rewrite a
> few things, I suggest something like the following;
> 
> ---
> 
> 4.  Deprecation
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 10 Jan 2015 22:55:01 +0000

> On Jan 9, 2015, at 2:04 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Well, two weeks from January 4 is actually January 18 - or, as I try to do these on NZ time, from 8:00 January 5 at the dateline two weeks gets me 8:00 January 19. It’s under the wire.

On the other hand, I don’t know that the fact that a comment was made makes it one that has to be acted on in accordance with its author; it is part of the working group conversation, nothing more and nothing less. With the preponderance of opinion in 2011 one way and 3-4 opinions the other in 2011, and with the preponderance of opinion one way and two opinions the other in 2014, I ruled the dissent to be “in the rough”. We (you) have bent over backwards to address the issues raised, and a month ago Keith said that he would accept -10 when it was filed. From my perspective, as a process manager, I’m hard pressed to say that we don’t have consensus.

Here’s my suggestion. Would you kindly respond to Dave’s email, answering the question “is this a friendly amendment” point by point? If they are friendly amendments, let’s incorporate them, but if they are raising new issues, the issues will need support from other working group participants.

Reading his suggestions, I think they are in fact friendly amendments. In essence, the change from 08 to 09 removed the recommendation to filter 192.88.99.1 and generally block anycast service. Dave is saying that if we are no longer recommending that, there are some other sections that become slightly ambiguous, and would like to see that cleaned up. He would also like to see the general set of recommendations separated into operational and implementation recommendations, and suggests text.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jan 2015 13:52:11 +1300

Hi Fred

> Well, two weeks from January 4 is actually January 18 - or, as I try to do these on NZ time, from 8:00 January 5 at the dateline two weeks gets me 8:00 January 19. It’s under the wire.

I'm a bit confused because I thought that the WGLC started with your message
on November 16, and that we were now in the process of tidying up WGLC comments,
mainly Keith's.

That said, I will comment on David's points in a separate message.

fyi I will be mainly off-line Jan 17-25.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jan 2015 14:09:48 +1300

David,

>    traffic will use different relays in the forward and reverse

Agreed.

>    parties and is not dependent on the anycast 6to4 mechanism that this

Agreed.

>    mechanism MUST NOT be enabled by default.

Yes, that is certainly intended and I'm surprised that it isn't already
there.

>    Implementations capable of acting as IPv6 routers MUST NOT enable...

Yes.

>    or through Unicast Reverse-Path-Forwarding (uRPF) checks.

Agreed.

>    broader deployment and use of native IPv6 on the Internet as a

I suspect that would be controversial because of the "remains valid"
phrase, so I would delete that sentence.

>    the deprecated anycast 6to4 mechanism.

I agree with the sentiments. But I'd like to hear a positive echo from
the WG, because this seems like a substantive addition.

> sections or sub-sections if you prefer.

It's true that this section has grown a bit organically. I think I agree
with your proposal, but I'll only find out for sure when I get my
editing fingers going. That seems unlikely to happen for the next couple
of weeks.

Regards
    Brian

---

From: David Farmer <[email-masked]>
Date: Sat, 10 Jan 2015 19:18:42 -0600

> On Jan 10, 2015, at 16:55, Fred Baker (fred) <[email-masked]> wrote:
> ...

Thanks Fred,

I at least intended them all as friendly amendments or friendly suggestions.  I view several of the suggestions as mostly editorial in nature.  

The host recommendations are somewhat new, however they follow directly from comments in the introduction regarding "happy eyeballs" and source address selection.  I feel we should be explicit and recommend their use with any host continuing to use 6to4 and especially any continued use of anycast 6to4.

I do support the consensus regarding not filtering, but with its removal I feel we shouldn't just not say anything about filtering, there needs to be a clear statement that filtering is not recommended and beyond that what the affect of deprecation is intended to be.  I did make a comment saying we needed to say more about filtering following version 9, it probably got lost in the conversation with Keith, and it wasn't anywhere near as clear and specific as my current comment regarding this issue.  

I look forward to Brian's response.

Thanks again

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota    
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: David Farmer <[email-masked]>
Date: Sat, 10 Jan 2015 19:58:40 -0600

> On Jan 10, 2015, at 19:09, Brian E Carpenter <[email-masked]> wrote:
>> ...

I'm fine with that, you are right, the "remains valid" bit might be a half a step to far.  As long as we clarify that deprecation isn't a recommendation to filter and we say what we intend the affect of deprecation to be, then I'm fine.  

> the WG, because this seems like a substantive addition

Yes, it would be helpful if others chime in on this.  But I'll add, it is virtually a direct conclusion from comments in the introduction, I just think we just never got around to saying it as recommendation.

> editing fingers going. That seems unlikely to happen for the next couple

Happy to leave it with your capable editing fingers, I'm very happy with them so far.

Thanks

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 11 Jan 2015 12:18:15 +0000

> the WG, because this seems like a substantive addition.

This paragraph doesn't belong in this document:

1. v6ops-6to4-to-historic can't fix all the world's ills.  End user common
sense needs to be exercised.

2. RFC6555 is standards track and already wraps up its requirements in
MUST, which will trump a BCP "SHOULD".

3. any o/s which enables 6to4 is likely to be older, so won't pay attention
to this document anyway.  If it's newer or the end user has explicitly
enabled 6to4, then see the comment on common sense above.

Nick

---

From: James Woodyatt <[email-masked]>
Date: Mon, 12 Jan 2015 11:38:56 -0800

> the WG, because this seems like a substantive addition.

Consider this another negative reaction.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 13 Jan 2015 11:54:33 +0900

>    the deprecated anycast 6to4 mechanism.

I disagree that implementations should support happy eyeballs. Happy
eyeballs is a hack that came into being to avoid broken IPv6
implementations. (I know, because I was there; and before anyone argues
with me - were you?) It adds application complexity and makes debugging
harder in order to overcome problems that would not exist if the network
were properly configured, and it encourages misconfiguration to persist
because it masks the effects of misconfiguration. We should not perpetuate
it; we should instead be moving beyond it.

Just because Happy Eyeballs is a standards track RFC doesn't mean that
hosts have to implement it.

---

From: George Michaelson <[email-masked]>
Date: Tue, 13 Jan 2015 13:06:09 +1000

I agree with Lorenzo. I believe based on the measurement stuff we do, that
HE has not got a net-positive effect, and was in hindsight not a good idea.

Its not consistently implemented, because its not consistently understood

It interacts badly with multiply addressed resources

It has a proscriptive model of the 'best' connection which doesn't suit all
circumstances

It has begun differentiating between client level behaviours, OS behaviours
and mediating device behaviours all of which interact in the V4/V6 path

I think its inevitable that at some future point, HE will be deprecated.

-G

---

From: David Farmer <[email-masked]>
Date: Mon, 12 Jan 2015 21:17:40 -0600

> On Jan 12, 2015, at 20:54, Lorenzo Colitti <[email-masked]> wrote:
> 
> I disagree that implementations should support happy eyeballs. Happy eyeballs is a hack that came into being to avoid broken IPv6 implementations. (I know, because I was there; and before anyone argues with me - were you?) It adds application complexity and makes debugging harder in order to overcome problems that would not exist if the network were properly configured, and it encourages misconfiguration to persist because it masks the effects of misconfiguration. We should not perpetuate it; we should instead be moving beyond it.
> 
> Just because Happy Eyeballs is a standards track RFC doesn't mean that hosts have to implement it.

Ok, I'm fine without Happy Eyeballs, it is most defiantly a hack, like I said it seemed to jump out of the Introduction as a conclusion.  What about the other half?  If you going to continue to use anycast 6to4 should there be a requirement or recommendation to support RFC6724 or be manually configured with an address selection policy preferring IPv4 over a 6to4 source address?

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jan 2015 16:20:31 +1300

In terms of the current draft, I'm hearing that we should not
include the paragraph in question.

If people want to debate HE as such, may I politely request
that y'all change the subject line?

Regards
   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 13 Jan 2015 12:27:38 +0900

I do not object to saying that implementations SHOULD support the rules in
RFC6724.

On Tue, Jan 13, 2015 at 12:17 PM, David Farmer <[email-masked]> wrote:

> Ok, I'm fine without Happy Eyeballs, it is most defiantly a hack, like I
> said it seemed to jump out of the Introduction as a conclusion.  What about
> the other half?  If you going to continue to use anycast 6to4 should there
> be a requirement or recommendation to support RFC6724 or be manually
> configured with an address selection policy preferring IPv4 over a 6to4
> source address?
>
> --

---

From: <[email-masked]>
Date: Tue, 13 Jan 2015 08:27:10 +0100

Good observation regarding HE, I fully agree.

However I would like to see the recommendation regarding SAS in 6to4 (“6to4 SHOULD support the IPv6 address selection  policy described in [RFC6724] …”)

Olaf

From: v6ops [mailto:[email-masked]] On Behalf Of George Michaelson
Sent: Dienstag, 13. Januar 2015 04:06
To: [email-masked] WG
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-10.txt

I agree with Lorenzo. I believe based on the measurement stuff we do, that HE has not got a net-positive effect, and was in hindsight not a good idea.

It has a proscriptive model of the 'best' connection which doesn't suit all circumstances

It has begun differentiating between client level behaviours, OS behaviours and mediating device behaviours all of which interact in the V4/V6 path

-G

On Tue, Jan 13, 2015 at 12:54 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
On Sat, Jan 10, 2015 at 6:44 AM, David Farmer <[email-masked]<mailto:[email-masked]>> wrote:
   All hosts using 6to4 SHOULD support the IPv6 address selection
   policy described in [RFC6724] or be manually configured with an
   address selection policy preferring IPv4 over a 6to4 source
   address.  Further, 6to4 hosts SHOULD support "Happy Eyeballs"
   [RFC6555] or use a browser supporting "Happy Eyeballs".  Any hosts
   not meeting these requirements SHOULD NOT use, or continue to use,
   the deprecated anycast 6to4 mechanism.

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Owen DeLong <[email-masked]>
Date: Tue, 13 Jan 2015 00:19:23 -0800

HE probably won’t get deprecated, it will probably simply become obsolete as IPv4 is phased out.

I agree HE wasn’t a good idea. I thought so at the time, but I do understand why people pushed for it. In any case, hindsight is 20/20 and it doesn’t matter why so much as how we cope with where we are today.

I support Olaf’s recommendation, if we’re updating 6to4 language. However, I thought we were basically moving 6to4 to historic status, in which case, I’m not sure suggesting a new SAS strategy as a should is relevant/necessary/consistent with this move.

Owen

> On Jan 12, 2015, at 23:27 , <[email-masked]> <[email-masked]> wrote:
> 
> From: v6ops [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of George Michaelson
> To: [email-masked] <mailto:[email-masked]> WG
> On Tue, Jan 13, 2015 at 12:54 PM, Lorenzo Colitti <[email-masked] <mailto:[email-masked]>> wrote:
> On Sat, Jan 10, 2015 at 6:44 AM, David Farmer <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>

---

From: Tim Chown <[email-masked]>
Date: Tue, 13 Jan 2015 09:39:21 +0000

Hi,

> On 13 Jan 2015, at 03:27, Lorenzo Colitti <[email-masked]> wrote:
> 
> I do not object to saying that implementations SHOULD support the rules in RFC6724.

Yes, definitely.

HE was a necessary hack at the time, and it made perfect sense if Google were doing v6 for World IPv6 Day in 2011 that they could implement something HE-like and say their browser would be resilient to the 20+ second delays we saw otherwise back at that time. I think I even stayed on Chrome after that day, so the ploy worked ;)

I think an interesting approach is as described in draft-ietf-mif-mpvd-arch-08, which blends many considerations including multiple interfaces, providers and protocols. But for this draft, RFC6724 should be the go to reference.

Tim

> On Tue, Jan 13, 2015 at 12:17 PM, David Farmer <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Jan 12, 2015, at 20:54, Lorenzo Colitti <[email-masked] <mailto:[email-masked]>> wrote:
> 
> David Farmer                          Email: [email-masked] <mailto:[email-masked]>
> 2218 University Ave SE         Phone: +1-612-626-0815 <tel:%2B1-612-626-0815>
> Minneapolis, MN 55414-3029   Cell: +1-612-812-9952 <tel:%2B1-612-812-9952>

---

From: James Woodyatt <[email-masked]>
Date: Tue, 13 Jan 2015 10:19:44 -0800

Everyone—

I would object to the recommendation for a manual configuration option. We
are already telling host implementations that enabling and configuring 6to4
cannot be automatic. It must be manual. It's redundant and unnecessary to
say that a separate manual configuration is also necessary for enabling the
associated address selection policy. Why would we do that?

The draft as currently written seems adequate to me, and I don't see a
burning need to revise it so that RFC 6724 is expressly RECOMMENDED with a
keyword.  If that recommendation could be added easily and without further
delay, then I would not object to that.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jan 2015 08:35:10 +1300

> delay, then I would not object to that.

The text already says "The default address selection rules specified in [RFC6724]
are not modified." Since it looks as if the draft needs to be updated one more
time, we can update that sentence with a SHOULD easily enough. (RFC 6724 is
already a standard anyway, so strictly speaking this is redundant, but it won't
waste much ink.)

    Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Jan 2015 10:36:10 -0500

> the WG, because this seems like a substantive addition.

I think this goes too far.   Happy Eyeballs is of very limited 
applicability; and there's way too much assumption here that using a web 
browser is the purpose of using IPv6 or maybe even the Internet.

Keith

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 14 Jan 2015 16:02:26 +0000

> On Jan 14, 2015, at 7:36 AM, Keith Moore <[email-masked]> wrote:
> 
> I think this goes too far.   Happy Eyeballs is of very limited applicability; and there's way too much assumption here that using a web browser is the purpose of using IPv6 or maybe even the Internet.

</chair>

IMHO, HE is stated in terms of a simple use case (a client web browser, and the issue is selecting among a set of two addresses, IPv4 and IPv6), but embodies a more general principle. The principle is that if a host is multihomed (as in, has more than one address, dual stack being but one example of that), the addresses each represent a path, and paths may have different characteristics in terms of whether they work at all, end to end delay, loss, yada yada yada. If both ends are multihomed, it gets more complex.

The principle is "if one choice isn't giving you the results you want, try a different one, in a timely fashion."

My only problem with making a recommendation about "the host" in this context is that "the host" is properly its OS, and due to the stupidity of the socket API design, this is relegated to the application. So we have to change each application individually - whack-a-mole. It's not like someone can make a simple fix to Linux/MacOSX/Windows and suddenly every application is IPv6-capable, or implements Happy Eyeballs.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Jan 2015 08:47:30 +1300

Comment at the end...

On 15/01/2015 08:31, David Farmer wrote:
> On 1/13/15 13:35 , Brian E Carpenter wrote:
> First, I think any recommendation regarding HE is a dead issue for this draft.  With that out of the way; I think there are
> three distinct issues for this draft regarding RFC6724;
> 
> 1. The deprecation of anycast 6to4 doesn't change the IPv6 address selection rules described in RFC6724.  If anything it
> reinforces the need for the rules as the are in RFC6724.
> 
> 2. A requirement that if any new implementations include anycast 6to4 support, it MUST NOT be enabled by default and MUST
> support RFC6724.  I suggest the following text in a separate implementation recommendations section;
> 
>    it is NOT RECOMMENDED to include the deprecated anycast 6to4
>    mechanism defined in [RFC3068] in any new implementations.  However,
>    if included in any new implementations, the anycast 6to4 mechanism
>    MUST NOT be enabled by default and the default address selection
>    rules specified in [RFC6724] MUST be supported.
> 
> 3. Make an operational recommendation that hosts continuing to use the deprecated anycast mechanism 6to4 SHOULD either support
> RFC6724 or be manually configured to prefer IPv4 over a 6to4.
> 
> If we are not going to provide a operational recommendation to filtering the anycast 6to4 route, then I think a we should
> consider telling people what it takes to use it safely.  Which I think means preferring IPv4 to 6to4 either by using a newer
> implementations that support RFC6724 or manually configuring such a rule in older implementations if possible.
> 
> I suggest the following text in a separate operational recommendations section;
> 
>    Any host using or continuing to use the deprecated anycast 6to4
>    mechanism SHOULD support the default address selection rules
>    specified in [RFC6724] or be manually configured with an address
>    selection rule preferring IPv4 over a 6to4 source address.
> 
> I think there is support for the first two points, there may not be support for the third, but I wanted to clarify what I was
> suggesting and why before giving up on the issue.

There's a section in RFC 6343 called "Vendor Issues" which is
specifically addressed to implemementers, including this statement:

   4.  6to4 implementations should adopt updated IETF recommendations on
       address selection [RFC3484-REVISE]

So, there is nothing new here. It's a WG choice whether to make this
a formal recommendation. We already endorse RFC 6343 as a whole
in any case.

   Brian

---

From: David Farmer <[email-masked]>
Date: Wed, 14 Jan 2015 13:31:38 -0600

> already a standard anyway, so strictly speaking this is redundant, but it won't

First, I think any recommendation regarding HE is a dead issue for this 
draft.  With that out of the way; I think there are three distinct 
issues for this draft regarding RFC6724;

1. The deprecation of anycast 6to4 doesn't change the IPv6 address 
selection rules described in RFC6724.  If anything it reinforces the 
need for the rules as the are in RFC6724.

2. A requirement that if any new implementations include anycast 6to4 
support, it MUST NOT be enabled by default and MUST support RFC6724.  I 
suggest the following text in a separate implementation recommendations 
section;

3. Make an operational recommendation that hosts continuing to use the 
deprecated anycast mechanism 6to4 SHOULD either support RFC6724 or be 
manually configured to prefer IPv4 over a 6to4.

If we are not going to provide a operational recommendation to filtering 
the anycast 6to4 route, then I think a we should consider telling people 
what it takes to use it safely.  Which I think means preferring IPv4 to 
6to4 either by using a newer implementations that support RFC6724 or 
manually configuring such a rule in older implementations if possible.

I suggest the following text in a separate operational recommendations 
section;

I think there is support for the first two points, there may not be 
support for the third, but I wanted to clarify what I was suggesting and 
why before giving up on the issue.

Thanks

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Jan 2015 10:49:26 +1100

In message <[email-masked]>, "Fred Baker (fred)
" writes:
> > I think this goes too far.   Happy Eyeballs is of very limited applicabilit
> y; and there's way too much assumption here that using a web browser is the p
> urpose of using IPv6 or maybe even the Internet.
> 
> </chair>
> 
> IMHO, HE is stated in terms of a simple use case (a client web browser, and t
> he issue is selecting among a set of two addresses, IPv4 and IPv6), but embod
> ies a more general principle. The principle is that if a host is multihomed (
> as in, has more than one address, dual stack being but one example of that), 
> the addresses each represent a path, and paths may have different characteris
> tics in terms of whether they work at all, end to end delay, loss, yada yada 
> yada. If both ends are multihomed, it gets more complex.
> 
> My only problem with making a recommendation about "the host" in this context
>  is that "the host" is properly its OS, and due to the stupidity of the socke
> t API design, this is relegated to the application. So we have to change each
>  application individually - whack-a-mole. It's not like someone can make a si
> mple fix to Linux/MacOSX/Windows and suddenly every application is IPv6-capab
> le, or implements Happy Eyeballs.

But 90+% of applications just need to follow a simple framework.

Simple examples are here and just take the output of getaddrinfo:

	http://users.isc.org/~marka/poll-connect.c
	http://users.isc.org/~marka/select-connect.c
	http://users.isc.org/~marka/thread-connect.c

These leave the source address selection to the stack which has
access to the routing.  It could try multiple source addresses for
the given destination address in preference order.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Jan 2015 13:09:18 +1300

> the given destination address in preference order.

There is no preference order in the general case. In terms of
best user experience, trying everything in parallel is more
desirable, even though HE is apparently not the best way of
doing that. I look forward to a draft that describes experience
and measurements with HE...

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Jan 2015 12:10:29 +1100

In message <[email-masked]>, Brian E Carpenter writes:
> >>> On Jan 14, 2015, at 7:36 AM, Keith Moore <[email-masked]> wro
> te
> >> :
> >>>
> >> The principle is "if one choice isn't giving you the results you want, try
>  a 
> >> different one, in a timely fashion."
> >>

We have address selection rules which give us the remote addresses
in preference order.  For each of those addresses we do have selection
rules for the source address to use.

i.e. if the remote has a local ULA address (one of our /48's) that
sorts to the top.  When we attempt to connect to that address the
source address rules puts our addresses in that /48 as higher
preference source addresses.  We currently only use the highest
preference address.

Extending getaddrinfo to return both source / destination pairs
would be one way to address this.  Yes, getaddrinfo was designed
to be extended so this should be possible.

Mark

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Jan 2015 13:03:43 -0500

On 01/14/2015 08:10 PM, Mark Andrews wrote:
> sorts to the top.

I'm not sure who you mean when you say "we", but I'll point out that any 
assumptions made about preference of ULAs in general is pretty dubious.

> to be extended so this should be possible.

getaddrinfo() is a hideous mess.   I've seen so many bogus things done 
by getaddrinfo implementations (including doing SRV lookup, LLMNR 
lookup, and consulting other sources of non-DNS information), that 
coupled with the lack of an asych lookup capability, I'm strongly of the 
opinion that it should be deprecated.   I didn't think it was possible 
to do worse than gethostname(), but I was proven wrong.

Keith.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Jan 2015 15:37:03 -0300

On 01/14/2015 01:02 PM, Fred Baker (fred) wrote:
> 
> IMHO, HE is stated in terms of a simple use case (a client web
> browser, and the issue is selecting among a set of two addresses,
> IPv4 and IPv6), but embodies a more general principle. The principle
> is that if a host is multihomed (as in, has more than one address,
> dual stack being but one example of that), the addresses each
> represent a path, and paths may have different characteristics in
> terms of whether they work at all, end to end delay, loss, yada yada
> The principle is "if one choice isn't giving you the results you
> want, try a different one, in a timely fashion."

Fully agreed. While HE was triggered by IPv6-related stuff, reality is
that work in this area was already needed.

> My only problem with making a recommendation about "the host" in this
> context is that "the host" is properly its OS, and due to the
> stupidity of the socket API design, this is relegated to the
> application. So we have to change each application individually -
> whack-a-mole. It's not like someone can make a simple fix to
> Linux/MacOSX/Windows and suddenly every application is IPv6-capable,
> or implements Happy Eyeballs. 

Maybe this is an indication that it's time to do the right thing and
produce a higher level give_me_a_bloody_connection_to_this_service()
sort of thing?  (I personally don't buy the "we don't specify APIs".
Firstly, because we've done so. Secondly, because if we don't, we pay
the price).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Jan 2015 13:54:50 -0500

If only the Internet architecture provided us with reliable host or service names.  Sadly, it doesn't.  IP addresses are the best we have.

Sent from my iPhone

> On Jan 15, 2015, at 1:37 PM, Fernando Gont <[email-masked]> wrote:
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 15 Jan 2015 19:07:07 +0000

Thanks, guys, for changing the subject line. I think this is getting pretty far afield from the 6to4 question...

> On Jan 15, 2015, at 10:54 AM, Keith Moore <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 16 Jan 2015 16:24:56 +0900

> I agree with Lorenzo. I believe based on the measurement stuff we do,
> that HE has not got a net-positive effect, and was in hindsight not a
> good idea.

and why are we discussing a list of hack to make 6to4 'better' when the
intent is supposed to be just turning this broken dren off?

randy

---

From: David Farmer <[email-masked]>
Date: Fri, 16 Jan 2015 09:55:32 -0600

> intent is supposed to be just turning this broken dren off?

Because we are not turning off 6to4, we're not even turning off anycast 6to4, we are beginning a long slow, probably painful, deprecation process and will have to live with 6to4 and even anycast 6to4 for a long time.  This is the affect of removing the idea of any filtering of 192.88.99.1. 

We don't seem to have consensus for anything resembling turning off anycast 6to4, which in my opinion would at least include a "networks MAY filter 192.88.99.1".

---

From: Owen DeLong <[email-masked]>
Date: Fri, 16 Jan 2015 08:37:33 -0800

> On Jan 16, 2015, at 07:55 , David Farmer <[email-masked]> wrote:
> 
> 
> We don't seem to have consensus for anything resembling turning off anycast 6to4, which in my opinion would at least include a "networks MAY filter 192.88.99.1”.

If the we honestly believe that a statement one way or the other from the IETF about whether a network can filter 192.88.99.1 will have any real world impact, then I believe we are delusional.

People who want to kill anycast 6to4 will filter 192.88.99.1 regardless of any advice from IETF.

People who want to save anycast 6to4 (if there are any such people) for whatever reason will rail against such filters.

IETF advice in this regard is likely to be even less well implemented than BCP-38.

As such, I would suggest we focus on the areas where we can provide effective and useful advice and not waste document space tilting at windmills.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Jan 2015 08:24:50 +1300

> As such, I would suggest we focus on the areas where we can provide effective and useful advice and not waste document space tilting at windmills.

Document editor hat off: +1

Document editor hat on: I will be out for the next week or so. After that
I will edit in the comments from David that appear to be non-controversial,
and hopefully that will be the final draft that Fred can ship to the AD.

    Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 16 Jan 2015 20:23:52 +0000

> On Jan 16, 2015, at 11:24 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> I will be out for the next week or so. After that

<chair>

++