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

From: [email-masked]
Date: Mon, 10 Nov 2014 21:40:26 -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 Connection of IPv6 Domains via IPv4 Clouds (6to4)
        Authors         : Ole Troan
                          Brian Carpenter
	Filename        : draft-ietf-v6ops-6to4-to-historic-07.txt
	Pages           : 7
	Date            : 2014-11-10

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

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-07

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

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: Tue, 11 Nov 2014 18:44:29 +1300

This is intended to incorporate the result of today's discussion.
Please let the authors know if we got it wrong.

   Brian

On 11/11/2014 18:40, [email-masked] wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: David Farmer <[email-masked]>
Date: Tue, 11 Nov 2014 13:33:57 -0600

> Please let the authors know if we got it wrong.

I wasn't at the IETF Meeting so I don't know if you have the correct 
result from that discussion.  However, I believe the result is 
consistent with my understanding of the consensus on the v6ops list. 
Further, I support deprecation of Anycast 6to4, and the general take of 
the Draft.

But, I feel the Draft should also either update or replace RFC6343. 
Minimally, I think it is important for there to be a metadata linkage 
between RFC6343 and the Draft.  I would suggest a formal update to 
Section 4 of RFC6343 substituting the use of Router 6to4 in place of 
Anycast 6to4.

Regardless, Section 4.5 of RFC6343 recommends the use of 192.88.99.1 as 
the IPv4 source address for Return Relay traffic, this no longer seem 
appropriate with the deprecation of 192.88.99.1, the prefix 
192.88.99.0/24, and Anycast 6to4 in general.  The 6th paragraph of 
Section 4 of the Draft discusses Return Relays and references Section 
4.5 of RFC6343, I believe the intent is that "content providers might 
choose to continue operating such a relay", but I think the 
recommendation regarding the use of 192.88.99.1 as the IPv4 source 
address of such traffic, contained in Section 4.5 of RFC6343 could be 
confusing and is no longer appropriate.

The draft says RFC6890 should be updated to remove "the 6to4 relay 
anycast prefix (192.88.99.0/24)", but RFC6890 doesn't need to be 
updated.  RFC68980 created "Special-Purpose IP Address Registries", no 
update to the RFC is necessary, IANA only needs to update the 
appropriate registry, which is already requested in section 5.  You may 
want to specifically call out the appropriate registry "IPv4 
Special-Purpose Address Registry" in section 5, but there is no need to 
update RFC6890.

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: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Nov 2014 20:21:46 +0000

Hi Brian,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Monday, November 10, 2014 9:44 PM
> To: [email-masked]
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-07.txt
> 

It looks like you are not intending to include a section on candidate 6to4
replacements then (we had some discussion on those on the list). If there
will be a consideration for replacements, I would like to add ip-proto-44
encapsulation to the list, i.e., tunneling over IPv6 Fragment Header. By that,
I mean IPv6-in-IPv6FH-in-IPv4 encapsulation. I talk about this in a new draft
on "AERO Minimal Encapsulation":

https://datatracker.ietf.org/doc/draft-templin-aeromin/

Note that in a "compressed" format not all packets need to include the
IPv6 FH, though. In that case, these "compressed" packets would look just
like ip-proto-41.

Thanks - Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Nov 2014 09:29:22 +1300

Hi David,

Thanks for the comments - see below.

> Section 4 of RFC6343 substituting the use of Router 6to4 in place of

6343 is non-normative, so I'm not sure that we need to formally
update it.  Also I don't agree that we should *encourage* people
to apply the Router 6to4 scenario (which has been essentially
ignored by the market for 13 years). But you are correct that some
of the guidelines in 6343 might be taken as a positive recommendation
to run an anycast relay, so how about adding this:

"The guidelines in Section 4 of [RFC6343] remain valid only for
those who choose to continue operating Anycast 6to4 despite its
deprecation."

> confusing and is no longer appropriate.

Why? Setting 192.88.99.1 as a *source* address is orthogonal to whether
it's filtered by the routing system as a destination. It's pretty much
harmless.

> Special-Purpose Address Registry" in section 5, but there is no need to

Table 10 of 6890 explicitly mentions 192.88.99.0/24, so I think it
does need to be updated. Actually we could do it right here in the
draft by adding "Updates: 6890" and specifying that Table 10 is
deleted. We do need to improve the IANA Considerations wording
on that point, too.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Nov 2014 09:34:31 +1300

On 12/11/2014 09:21, Templin, Fred L wrote:
> replacements then (we had some discussion on those on the list). 

That was the message I got (i.e. discussing alternatives is out of scope for
*this* document).

   Brian

If there

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Nov 2014 20:56:42 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, November 11, 2014 12:35 PM
> To: Templin, Fred L
> Cc: [email-masked]

Maybe we should just put "Obsoletes RFC3056, RFC3068" in the header of AERO?

Thanks - Fred

---

From: James Woodyatt <[email-masked]>
Date: Tue, 11 Nov 2014 12:14:32 -1000

My comment is not an objection to this draft. I am generally supportive of
this draft.

I have only one comment, which I suppose *might* rise to the level of a
"complaint" if it were shared by a significant fraction of other
participants, which is simply this: we are retaining RFC 3056 on the
Standards Track, and we are considering an RFC that advises content
providers that supporting 6to4 users with return relays to 2002::/16, maybe
even new ones that aren't currently there, is consistent with Best Current
Practice, but we are not advising anyone else that maybe new deployment of
return relays to 2002::/16 is an idea worth reviewing. Why not?

Some obvious places to locate a 6to4 return relay spring immediately to
mind, e.g. wherever there is a NAT64 gateway, e.g. in dual-stack customer
edge routers with interfaces numbered with public IPv4 addresses.  Anyplace
where an IPv6-only host might be reachable from a host using RFC 3056 (and
not RFC 3068) to get IPv6 packets into the IPv6-only world from some
benighted place where it's the 21st century and still IPv4 is the only
service available to them.

If I were a content provider (oh wait! I work for one now!), then I might
notice the fact this document singles me out for special attention and
leaves unmolested all the other places where broken 6to4 return relay
service might be just as noticeable to legitimate users of RFC 3056 who are
using manually configured forward relay services. I might think to myself:
hey, why do I need a 6to4 return relay in my network when nobody else has
one, and IETF can't even be bothered to advise them that it's even worth
thinking about?

As I said above, this is not actually a complaint. It's just a comment, and
if nobody pipes up with a "me too" observation, then that's fine. I don't
have any significant objection to publishing this revision of the draft now.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Nov 2014 12:22:39 -1000

But if you're a content provider, your stats would show that 6to4 traffic
is ~ 0.01% of total traffic, and therefore, you might well choose not to
optimize it (even to the extent of not having your own relays and using
third-party relays), as long as it works reasonably well.

On Tue, Nov 11, 2014 at 12:14 PM, James Woodyatt <[email-masked]> wrote:

> As I said above, this is not actually a complaint. It's just a comment,
> and if nobody pipes up with a "me too" observation, then that's fine. I
> don't have any significant objection to publishing this revision of the
> draft now.
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Nov 2014 12:33:25 +1300

James,

> return relays to 2002::/16 is an idea worth reviewing. Why not?

We are not rescinding RFC 6343, which is Informational, and does
suggest some cases where an operator could usefully run a return relay.
But that is a bit different from advocating new deployments in a BCP...

> mind, e.g. wherever there is a NAT64 gateway, 

I tried and tried and couldn't see the direct relevance of a NAT64.
But there is a use case, which is at the boundary between an IPv6-only
network and the IPv4 Internet (which is coincidentally the same place
where you put a NAT64).

> e.g. in dual-stack customer
> edge routers with interfaces numbered with public IPv4 addresses.

That is exactly the classical case described in RFC 3056, which we
are not deprecating.

> Anyplace

Well, yes, the requirement is that there is a route to 2002::/16
that reaches a working return relay. That's why the draft now says
  "Internet service
   providers SHOULD announce the IPv6 prefix 2002::/16 if and only if it
   leads to a correctly operating return relay as described in RFC 6343."

Is it really the job of this draft to suggest where that relay should be?

There is a weakness in RFC 6343. In Section 4.3. "Consumer ISPs, and
Enterprise Networks, That Do Support IPv6" it implicitly assumes that
these are dual-stack networks. It would be better if it also offered
guidelines for IPv6-only networks. There is indeed a case for such
networks to operate a 2002::/16 return relay. But nobody made that point
while 6343 was being developed...

> one, and IETF can't even be bothered to advise them that it's even worth

Content providers presumably have a strong interest in not losing client
sessions. That's the reason they have their own section in 6343. But the
current draft only mentions them once, and the following sentence is a
rather stronger recommendation to ISPs. So I don't quite get your point.

   Brian

> ------------------------------------------------------------------------
>

---

From: Gert Doering <[email-masked]>
Date: Wed, 12 Nov 2014 13:34:53 +0100

Hi,

> Maybe we should just put "Obsoletes RFC3056, RFC3068" in the header of AERO?

No, as it doesn't.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: David Farmer <[email-masked]>
Date: Wed, 12 Nov 2014 14:46:14 -0600

On my first pass I missed the current title "Deprecating Connection of 
IPv6 Domains via IPv4 Clouds (6to4)", this implies more than is intended 
by the current consensus.  So, I'd suggest the title be changed to 
reflect the new scope of the Draft, how about "Deprecating the Anycast 
Prefix for 6to4 Relay Routers".

More responses inline;

On 11/11/14, 14:29 , Brian E Carpenter wrote:
...
> On 12/11/2014 08:33, David Farmer wrote:
...
> those who choose to continue operating Anycast 6to4 despite its

OK, that is probably good enough, but I'd still like to see a metadata 
linkage from RFC 6343 to the Draft such that an update provides even 
though RFC 6343 is non-normative.

> it's filtered by the routing system as a destination. It's pretty much

I guess my issue was that the recommendation that routes for 192.88.99.1 
be filtered will be taken by some operators to also filter traffic to or 
from 192.88.99.1 as well. How about an explicit recommendation against 
filtering traffic to or from 192.88.99.1, then the source address issue 
is orthogonal.  But, if traffic sourced from 192.88.99.1 gets filtered, 
then the issue is not orthogonal.

Also, I'd like to see the recommendation expanded beyond just "Internet 
service providers", how about "All networks, but in particular Internet 
service providers".  I'd also like to see the recommendations regarding 
Return Relays to include similar wording, focusing on, but not limited 
to content providers.

So how about replacing;

    Internet service providers SHOULD filter out routes to 192.88.99.1.

With;

    All networks, but in particular Internet service providers, SHOULD
    filter routes for 192.88.99.1 or the prefix 192.88.99.0/24, yet they
    SHOULD NOT filter traffic sourced from or destine to 192.88.99.1.

> deleted. We do need to improve the IANA Considerations wording

 From RFC 6890;
    2.2.2.  IPv4 Special-Purpose Address Registry Entries

    Tables 1 though 16, below, represent entries with which IANA has
    initially populated the IPv4 Special-Purpose Address Registry.

Table 10, along with tables 1 through 16, are only the initial data to 
go in the registry, the whole point of creating the registry is not to 
have publish summary RFCs or even update an RFC every time something 
changes.  With the execution of RFC 6890 and the creation of the 
registries, then the registries themselves become the authoritative 
references and sources for the information, the information in the 
tables of RFC 6890 are essentially Historical once the registries are 
created.  So, unless the intent was to modify the policy for the 
registry itself I don't see the need to update RFC 6890.

I'll leave it to you, the WG Chairs, and the AD to consult with IANA on 
the best solution, but below is what I was thinking for the IANA 
Considerations section.  There isn't a status field for an entry in the 
registry, so I thought setting the name to "deprecated" with the 
original name in parenthesis seemed a reasonable solution to communicate 
the intended result.  Would we want to add a Termination Date?  Maybe 
like December 2020?

    5.  IANA Considerations

        IANA is requested to update the "IPv4 Special-Purpose Address
        Registry" [IANA.IPv4] for the prefix 192.88.99.0/24 as defined in
        Table 1.  Redelegation of this prefix for any usage requires
        justification via an IETF Standards Action [RFC5226].

        +----------------------+-------------------------------------+
        | Attribute            | Value                               |
        +----------------------+-------------------------------------+
        | Address Block        | 192.88.99.0/24                      |
        | Name                 | Deprecated (6to4 Relay Anycast)     |
        | RFC                  | [draft-ietf-v6ops-6to4-to-historic] |
        | Allocation Date      | June 2001                           |
        | Termination Date     | N/A                                 |
        | Source               | True                                |
        | Destination          | True                                |
        | Forwardable          | True                                |
        | Global               | True                                |
        | Reserved-by-Protocol | False                               |
        +----------------------+-------------------------------------+

                Table 1: 6to4 Relay Anycast

    [IANA.IPv4]  IANA, "IPv4 Special-Purpose Address Registry",
 
<http://www.iana.org/assignments/iana-ipv4-special-registry/>.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Nov 2014 13:04:56 +1300

Yes, we should tweak the title.

Your other points are noted, pending the WGLC.

Thanks
   Brian

---

From: Doug Barton <[email-masked]>
Date: Thu, 13 Nov 2014 00:37:18 -0800

> Prefix for 6to4 Relay Routers".

Am I the only one who thinks that we should chuck the whole thing?

Doug

---

From: Gert Doering <[email-masked]>
Date: Thu, 13 Nov 2014 09:40:29 +0100

Hi,

> Am I the only one who thinks that we should chuck the whole thing?

Seems like it.

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2014 06:05:58 +1300

>> Am I the only one who thinks that we should chuck the whole thing?

The message in the v6ops meeting was pretty clear and that is the
reason for the diffs between -06 and -07. I understand there will
be a WGLC soon so that the chairs can verify consensus on this.

(The comments made so far on -07 are being held until after the
WGLC.)

    Brian

---

From: Doug Barton <[email-masked]>
Date: Thu, 13 Nov 2014 11:10:18 -0800

On 11/13/14 9:05 AM, Brian E Carpenter wrote:
> The message in the v6ops meeting was pretty clear

... and yet, the select few who were in that room are not the WG, which 
is why I asked. :)

I would hate for even a significant minority opinion to get bulldozed 
here because "We decided this in HI." OTOH, if the consensus of the 
entire WG is truly to create this new hybrid thing, I won't object too 
loudly. I think it's a mistake of course ...

> and that is the

As a process step that gives an air of finality to the decision that I 
don't think is fair. "We decided this in HI, now we're having a WGLC, 
you agree, right?" Given that AFAICS the consensus was pretty strong to 
chuck the whole thing going into HI, it's not clear to me what changed, 
or why it changed, or even that the majority of the WG agrees with the 
new plan. Not having any of that discussion until WGLC feels like 
stacking the deck to me, but I'd be happy to be proven wrong on that.

Doug

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 13 Nov 2014 20:43:45 +0100

On 2014-11-13 20:10, Doug Barton wrote:
[..]
> stacking the deck to me, but I'd be happy to be proven wrong on that.

Checking the changes, that are between the -06 the -07 doc:

http://www.ietf.org/rfcdiff?url1=draft-ietf-v6ops-6to4-to-historic-06&url2=draft-ietf-v6ops-6to4-to-historic-07

This just makes the document deprecate the anycast 6to4 relay.

The addition:
8<----------------------
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.
---------------------->8

That sounds sane to me. That allows 6to4 nodes to keep talking to each
other directly, but it stops the burden of the issues that the anycast
relays give. Getting 6to4 out of products will be horrible anyway,
anything from very old Solaris's support it, that effort won't solve
anything.

This is also what has been discussed on the list:
 - deprecate anycast 6to4
 - keep direct 6to4

Hence, in the form of -07, I am in favor of making it so.

But, as Doug notes, if there are any changes that need to be added, it
would be great to see those in the document before doing a WGLC,
especially for the people not sitting in a conference room on a tropical
island (I do hope the folks there got a few days before and after to
enjoy that apparently amazing island!)

Although from reading what Brian Carpenter says those changes are likely
minor editing notes. It would be great to see the final form though.

Greets,
 Jeroen

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Nov 2014 09:52:48 -1000

> ... and yet, the select few who were in that room are not the WG, which is why I asked. :)
> 
> I would hate for even a significant minority opinion to get bulldozed here because "We decided this in HI." OTOH, if the consensus of the entire WG is truly to create this new hybrid thing, I won't object too loudly. I think it's a mistake of course ...
> 
>> and that is the
> As a process step that gives an air of finality to the decision that I don't think is fair. "We decided this in HI, now we're having a WGLC, you agree, right?" Given that AFAICS the consensus was pretty strong to chuck the whole thing going into HI, it's not clear to me what changed, or why it changed, or even that the majority of the WG agrees with the new plan. Not having any of that discussion until WGLC feels like stacking the deck to me, but I'd be happy to be proven wrong on that.

it certainly would be interesting to hear what existing use cases there are for peer to peer mode 6to4 (as in without relays). I also have a hard time understanding the usefulness of keeping any of it.

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Thu, 13 Nov 2014 20:59:58 +0100

Hi,

> it certainly would be interesting to hear what existing use cases there are for peer to peer mode 6to4 (as in without relays). I also have a hard time understanding the usefulness of keeping any of…

Well, access to hosts behind a router with one global IPv4 address and
a 6to4 gateway in it comes to mind - without having to configure explicit
NAT mappings on the router.  I think this is Keith's scenario.

(Client has working global IPv4, Router has working global IPv4, neither
has v6, but peer-to-peer 6to4 enables access to inside LAN with 2002: 
addresses derived from Router's v4 address)

Gert Doering
        -- NetMaster

---

From: Doug Barton <[email-masked]>
Date: Thu, 13 Nov 2014 12:03:19 -0800

> addresses derived from Router's v4 address)

Isn't that the use case that ULAs are meant to cover? Or am I missing 
something here?

I made the point earlier that (for example) OpenWRT already has support 
for PD, it also creates a ULA network on the LAN side, whether you have 
a public prefix (or tunnel) or not. So all of that is doable today, with 
running code.

Doug

---

From: Gert Doering <[email-masked]>
Date: Thu, 13 Nov 2014 21:12:01 +0100

Hi,

> Isn't that the use case that ULAs are meant to cover? Or am I missing 

So how exactly do ULAs help connect to your home network from abroad,
when all you have is IPv4 at the client?

"client" is obviously *outside* "home network"

> a public prefix (or tunnel) or not. So all of that is doable today, with 

That wasn't the question.  Ole was asking "what are use cases for 
peer-to-peer 6to4" (RFC 3056 without 3068).

Gert Doering
        -- NetMaster

---

From: Doug Barton <[email-masked]>
Date: Thu, 13 Nov 2014 12:24:54 -0800

> "client" is obviously *outside* "home network"

Ok, then I misunderstood your point, thanks for clarifying.

> peer-to-peer 6to4" (RFC 3056 without 3068).

Yeah, I have the same question. :)  If users are stuck on an IPv4-only 
ISP, and want IPv6, they have proven alternatives already. IMO it's 
going to be very hard to send a clear message to implementers and 
operators, "Deprecate *this* kind of 6to4, but *not* this other kind."

Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2014 09:44:16 +1300

> operators, "Deprecate *this* kind of 6to4, but *not* this other kind."

Well, yes, it is hard to be clear, because of all the complexities.
Some of them were discussed at length in RFC 3056 and others in
RFC 6343. However, I maintain that the *current* draft is not
particularly complex in what it recommends.

I don't understand what you meant by "create this new hybrid thing".
IMHO the draft *removes* the hybrid thing created by RFC 3068,
apart from a few operational dregs, and leaves the thing created
by RFC 3056 untouched.

To your other earlier comment, a WGLC is not generally an up/down
choice. The authors will do what the WG wants, and a WGLC is a way
to find out what that is.

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Nov 2014 22:19:37 +0100

Le 13/11/2014 20:43, Jeroen Massar a écrit :
[...]
> This is also what has been discussed on the list:

YEs, I agree, and I would like to re-mention the point about software bugs.

There is one particular 6to4 implementation in the wild which has two 
different means to put up a 6to4 tunnel.  One is to just say '6to4' in 
the cli, the other is to be specific and type that IPv4 anycast address.

With the first means - it does not work.  Worse, it gets into a mode 
where packets are output destined to random IPv4 addresses.

Fix the bug.

What does this mean with respect to the deprecation effort?

Do not deprecate the IPv4 anycast address because if so then the entire 
6to4 software on that platform will no longer work.

Do not deprecate until you offer a solution satisfying a number of 
requirements (currently unsatisfied by eg tunnel brokers).

That's my oppinion.

Alex

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 13 Nov 2014 22:43:03 +0100

> where packets are output destined to random IPv4 addresses.

That is a vendor issue. Nothing the IETF can do about.

> What does this mean with respect to the deprecation effort?

That because of the bug that platform already is useless anyway, thus
effectively it is already deprecated... ;)

> 6to4 software on that platform will no longer work.

If that platform (which one btw) is so broken, then they currently have
a broken setup anyway. Hence, nothing to be fixed there.

> requirements (currently unsatisfied by eg tunnel brokers).

Which requirements are these?

Greets,
 Jeroen

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Nov 2014 23:10:50 +0100

Le 13/11/2014 21:03, Doug Barton a écrit :
>>> it certainly would be interesting to hear what existing use cases
>>> there are for peer to peer mode 6to4 (as in without relays). I also
>>> have a hard time understanding the usefulness of keeping any of it.
>>

I agree.  But when confronted to a similar situation I missed a 
description in the ULA RFC which tells how to form an IPv6 prefix out of 
an IPv4 address. (section 3.2.2 code for pseudo-rqndmo globql ID).

Alex

---

From: Doug Barton <[email-masked]>
Date: Thu, 13 Nov 2014 14:17:41 -0800

> where packets are output destined to random IPv4 addresses.

Alexandru,

This is merely a special case of the general proposition, "6to4 does not 
work well, and needs to go away." I think your analysis is correct, but 
your conclusion is the exact opposite of what I think the facts dictate.

Meanwhile, I'm interested in learning more about "a solution satisfying 
a number of requirements (currently unsatisfied by eg tunnel brokers)." 
What are those requirements, and why don't the tunnel brokers meet them?

Doug

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Nov 2014 23:17:48 +0100

> That is a vendor issue. Nothing the IETF can do about.

I agree.

> If that platform (which one btw - sponsor) is so broken, then they currently have

Ones one would have to lay down and agree on before engaging in new work.

For example -1- must allow for reverse DNS ok, -2- must be secureable by 
existing e2e IPsec, -3- to the extent of possible be easy to set up for 
Clients and not involve intervention of another party (like when 
requesting an IPv6 address from an administrator, delayed paper forms, etc).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Nov 2014 23:26:20 +0100

> What are those requirements, and why don't the tunnel brokers meet them?

Requirements or goals whatever one calls them, should be agreed before 
embarking on new work.

What do you think the goals would be?

For example, the current tunnel brokers are very good but (1) are not 
trustful, (2) force into later efforts to renumber when going native, 
(3) require filling in forms.  6to4 has the advantage of not requiring 3.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2014 11:30:44 +1300

> That is a vendor issue. Nothing the IETF can do about.

No, but naming and shaming the implementation might be useful.

> a broken setup anyway. Hence, nothing to be fixed there.

I agree. Definitely not the IETF's problem.

> Which requirements are these?

If anycast 6to4 worked correctly, we wouldn't be deprecating it
at all. But it's broken, we tried to fix it 3 years ago (RFC 6343),
and it's still broken. The idea of deprecating it is to help users
avoid a broken solution. Those ~100k users that Google sees would be
better off with IPv4-only.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2014 11:33:19 +1300

> requesting an IPv6 address from an administrator, delayed paper forms,

Anycast 6to4 meets those requirements afaik ;-)

   Brian

---

From: Doug Barton <[email-masked]>
Date: Thu, 13 Nov 2014 14:39:05 -0800

> Requirements or goals whatever one calls them, should be agreed before

But you're begging the question on the new work in the first place. :)

You're asserting that tunnels cannot do things that you think we should 
be able to do, making sure that a) you're correct, and b) those things 
are worth the cost should be a precursor to any discussion on new work.

For example, in response to Jeroen you asserted that tunnels don't allow 
reverse DNS. At least for HE, that assertion is demonstrably false.

> (3) require filling in forms.  6to4 has the advantage of not requiring 3.

... and yet I would assert that unless we're talking about something 
that is provider managed (such as 6rd) then automatically enabling it 
for the user is a bad idea. It will create more problems than it solves, 
and cause a lot of support calls, which ISPs are not going to like.

I'm also pretty sure that to the extent I understand it, your point 
about renumbering is also invalid.

Doug

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Nov 2014 23:42:31 +0100

> Anycast 6to4 meets those requirements afaik ;-)

Hm yes and no.  IPsec and anycast never married AFAIK.

6to4 is not alowing for reverse DNS either, if I am not terribly wrong.

Alex

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 13 Nov 2014 23:46:08 +0100

[Replies to multiple mails in this thread compressed into one]

On 2014-11-13 23:17, Alexandru Petrescu wrote:
[..]
> For example -1- must allow for reverse DNS ok,

That is a business decision. Most (all?) TBs provide this.

Note that a normal ISP does not do this, hence bit silly to require it
for a free tunnel...

> -2- must be secureable by existing e2e IPsec,

The tunnel or the packets that flow within it?
What is the problem you are trying to solve?

The packets in the tunnel are 1280+ hence, go IPSec away as much as you
want.

For securing the tunnel it would require distributing keying material.

As IPsec is horrible to configure and does not work through NATs happily
(yes, you can patch crap) nobody ever bothered with this.

For AYIYA packets are signed btw, hence, no spoofing of those.
There is no crypto though there either.

>-3- to the extent of possible be easy to set up for
> Clients

TSP (gogoclient) and TIC (AICCU) solve that problem. CPEs incorporate
these tools or have their own implementations (eg Fritz!Box).

How much 'easier' do you want it?

> and not involve intervention of another party (like when

Gogo's "anonymous" TSP tunnels do this. They get a lot of abuse.

Other Tunnel Brokers and Gogo TSP in "authenticated" mode require that
one signs up, just as you would with a IPv4 ISP.

This is a "business" decision though. Nothing a technical thing can solve.

>From another mail:

> For example, the current tunnel brokers are very good but
> (1) are not trustful,

What do you mean with "trustful"?

> (2) force into later efforts to renumber when going native,

Changing ISPs typically require that.

Only way to avoid that is to get your own PI space. At that point you
will be able to arrange your own connectivity too though.

> (3) require filling in forms.  6to4 has the advantage of not requiring 3.

And 6to4 is unreliable as no ISP can 100% support it.

With Tunnel Brokers you are signing up for a service. Signing up
requires forms.

Though those forms are there primarily to limit abuse too and to enable
contacting people when they problems with their tunnel so that it can be
resolved.

> 6to4 is not alowing for reverse DNS either, if I am not terribly wrong.

https://6to4.nro.net

But even then you still do not want 6to4 as it is unreliable ;)

Doug Barton wrote:
> ... and yet I would assert that unless we're talking about
> something that is provider managed (such as 6rd) then automatically
> enabling it for the user is a bad idea. It will create more problems
> than it solves, and cause a lot of support calls, which ISPs are not
going to like.

Exactly.

Greets,
 Jeroen

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Nov 2014 23:48:45 +0100

> But you're begging the question on the new work in the first place. :)

I am begging to give a replacement before deprecating.  If you dont 
deprecate and if vendor fixes bugs then one is fine (except reverse DNS, 
and _any_cast trust matters).

> reverse DNS.

The IPv6-in-IPv4 tunnel does not (I didnt mean IPv6-in-IPv6 tunnel not 
to allow reverse dns - I think it does).

> At least for HE, that assertion is demonstrably false.

Yes.

> about renumbering is also invalid.

Ah no, please, dont plan on renumbering.  I dont even have software to 
renumber all these devices and all these radvd.conf files...

I can give up my 6to4 address space, but just once.  I dont want to do 
it again in 2 years or so. (I already did it once in the past, its painful).

(now I am a particular case and people could discuss theirs, if any).

Alex

---

From: Doug Barton <[email-masked]>
Date: Thu, 13 Nov 2014 14:57:30 -0800

> and _any_cast trust matters).

If you are actually using 6to4 for production purposes I guarantee that 
you will like tunnels better. So your replacement is ready-made for you.

>> At least for HE, that assertion is demonstrably false.

I'm not sure you are understanding me here. I have an HE 6in4 tunnel, I 
can easily get reverse DNS for it if I want to. (I don't, but I can.)

> (now I am a particular case and people could discuss theirs, if any).

I'm sorry to say, renumbering is a fact of life. I'm not trying to be 
insensitive to your pain here, but it sounds like you're asking us to 
delay a major improvement to the IPv6 spec for your organization's 
convenience.

Doug

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 13 Nov 2014 23:58:13 +0100

On 2014-11-13 23:48, Alexandru Petrescu wrote:
[..]
> and _any_cast trust matters).

You'll have to come up with plausible requirements though.

The ones you are giving are satisfied by various means that are able to
provide you with proper connectivity for well over 10 years already.

> to allow reverse dns - I think it does).

The protocol used is irrelevant to the ability to assign reverse DNS.

Unless you are talking about Teredo where it is just too troublesome to
do so.

Please see:
https://www.sixxs.net/faq/connectivity/?faq=comparison

for a list of pro/cons for each protocol. There is also a 'reverse DNS'
column there. All of the protocols have "optional" reverse as it depends
on the provider providing it.

>> At least for HE, that assertion is demonstrably false.

Check:
https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers

for a nice feature comparison.

> (now I am a particular case and people could discuss theirs, if any).

Automating the generation & distribution of those configs helps a lot.

Also, you could have requested a prefix from the three bigger Tunnel
Brokers who have been operating for well over 10 years and you could
have had a static prefix for all that time already...

Greets,
 Jeroen

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Nov 2014 00:03:11 +0100

Le 13/11/2014 23:46, Jeroen Massar a écrit :
> On 2014-11-13 23:17, Alexandru Petrescu wrote: [..]
>>>> Do not deprecate until you offer a solution satisfying a
>>>> number of requirements (currently unsatisfied by eg tunnel
>>>> brokers).
>>>
> Note that a normal ISP does not do this, hence bit silly to require
> it for a free tunnel...

Home ISP may not do it, but business ISP does.

> The tunnel or the packets that flow within it? What is the problem
> you are trying to solve?

I need to trust enough the other endpoint, not send something in the wild.

> The packets in the tunnel are 1280+ hence, go IPSec away as much as
> you want.
>
> As IPsec is horrible to configure and does not work through NATs
> happily (yes, you can patch crap) nobody ever bothered with this.
>
> For AYIYA packets are signed btw, hence, no spoofing of those. There
> is no crypto though there either.

The questions I have about these are numerous but mostly administrative
as such are hard to formulate here in a public forum.  It has to do with
what kind of business is it, etc.

>
>> -3- to the extent of possible be easy to set up for Clients
>

Easy in the sense of as easy as opening a Google account.

> Gogo's "anonymous" TSP tunnels do this. They get a lot of abuse.

For example, do they spy on you?

> Other Tunnel Brokers and Gogo TSP in "authenticated" mode require
> that one signs up, just as you would with a IPv4 ISP.

For example, what kind of private data should I share with them?

> This is a "business" decision though. Nothing a technical thing can

There is no such aspect in 6to4...

>> From another mail:
>
>> For example, the current tunnel brokers are very good but (1) are
>> not trustful,
>

HArd to say, who do _you_ trust?

Trustful in the sense of accountable.  I dont want them to spy my
traffic, at least.  I want them to anwser questions when asked.

> Changing ISPs typically require that.

Whereas we can require the destinationISP to set up routing such that I
keep the same prefix I got from the first.  Or update other databases.

> Only way to avoid that is to get your own PI space.

Another administrative effort?

> At that point you will be able to arrange your own connectivity too
> though.

Only to those ISPs who accept it?

> And 6to4 is unreliable as no ISP can 100% support it.

Its mostly a matter of 6to4 Relays uptime and IP routing finding right 
paths.  Up to now I didnt experience 6to4 Relay not responding.

> With Tunnel Brokers you are signing up for a service. Signing up

Are the Tunnel Brokers ready to fill in forms that I request conceive?

> Though those forms are there primarily to limit abuse too and to
> enable contacting people when they problems with their tunnel so
> that it can be resolved.

What about the potential abuse from the Tunnel Brokers?

>> 6to4 is not alowing for reverse DNS either, if I am not terribly

Thanks, I didnt know that.

Does it require filling in forms for each IP address?  I am easier at 
vi-ing a config file in my local DNS and then DNS takes care of rest.

> But even then you still do not want 6to4 as it is unreliable ;)

:-)

Alex

>> enabling it for the user is a bad idea. It will create more
>> problems than it solves, and cause a lot of support calls, which
>> ISPs are not
> going to like.
>
> Exactly.
>
> Greets, Jeroen
>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2014 12:11:44 +1300

>    SHOULD NOT filter traffic sourced from or destine to 192.88.99.1. 

That doesn't quite work for me. Firstly, an edge network that chooses
(despite our advice) to use 6to4 shouldn't filter it, so I think it really
is a recommendation to ISPs. Secondly, if you're filtering the route, you
will drop packets TO 192.88.99.1 by definition. (I also think that mentioning
the /24 prefix is redundant.)

So my edit buffer now reads:

  Internet service providers SHOULD filter out routes to 192.88.99.1.
  However, 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.

      Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2014 12:29:37 +1300

> 6to4 is not alowing for reverse DNS either, if I am not terribly wrong.

RFC 5158 "6to4 Reverse DNS Delegation Specification"

Regards
   Brian

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 13 Nov 2014 13:33:09 -1000

v6OPS WG,

A natural association to deprecating RFC3068 and the removal of routing 
the 192.88.99.0/24 prefix will be the cessation of RFC6732 operation 
where it's enabled/implemented.  This is expected and a good thing.

Not sure if this should be mentioned specifically in the draft or not.

regards,

Victor K

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2014 12:34:36 +1300

On 14/11/2014 12:03, Alexandru Petrescu wrote:
...
> paths.  Up to now I didnt experience 6to4 Relay not responding.

You have been amazingly lucky then. During the brief period that
I ate this particular version of my own dog food, I had very
intermittent success (both black holes and unfixable MTU/MSS
issues).

   Brian

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 00:34:35 +0100

Setting Subject so that people know that this is clearly not about the
draft anymore and that subject can then be closed.

> Home ISP may not do it, but business ISP does.

Then consider Tunnel Brokers Business ISPs :)

> I need to trust enough the other endpoint, not send something in the wild.

The whole point of the Tunnel Broker model is that there is a fixed IP
and thus likely a stable path to send packets to and get them back from...

> what kind of business is it, etc.

[email-masked] or [email-masked] are there to answer such questions ;)

> Easy in the sense of as easy as opening a Google account.

I am not sure about HE, but for SixXS you don't have to fill in some
extremely unreadable recaptcha thing.

Hence that makes it for those EASIER than opening a Google account.

> For example, do they spy on you?

You might want to define "spy". You will never know what the three
letter agencies of the world do with data flowing around the world.

My advise always: use SSL, or develop your own crypto and stuff packets
in that.

A tunnel does not restrict you from any of that.

> For example, what kind of private data should I share with them?

At most the same as you would signup to a normal ISP:
 Your valid contact details (name, address, phone)

At minimum a random username.

> There is no such aspect in 6to4...

Yes there is. As the providers running the relays can and will shut them
down. That would also be a business decision.

History has shown that this already happened when Hetzner allowed a
customer of theirs to send spoofed 6to4 packets (src-ipv4 their IP,
dst-ipv4 the 6to4-anycast-addr, src-IPv6 spoofed, dst-IPv6 some target).
That caused quite a few 6to4 relays to shut them down as they did not
want to carry that crap traffic.

> HArd to say, who do _you_ trust?

Nobody? :)

> traffic, at least.  I want them to anwser questions when asked.

You will never know if somebody is snooping along with your data.

I can state though that SixXS does not peek along, unless we need to
debug or there is some weird traffic pattern etc.

I have no idea if the ISP providing the PoP peeks, or if some national
agency is doing so though on the fiber level or just tapping away.

As you love 6to4: as your packets go to an anycast you don't even know
which path they will take the next moment... note that the 'anycast' is
in four directions: IPv4 you->6to4-anycast, IPv6 6to4-anycast -> dest,
IPv6 dest -> 6to4-anycast (could be different from original), IPv4
6to4->anycast to you.

Hence, on the return path you won't even see it anyway...

If you are paranoid about this: use Tor.

Though that might not solve those problems either.

There are lots of VPN providers you can pay for a service that might
help you though.

This will never be something that anybody will vouch for though.
(At least, I cannot vouch for it because I don't control all the factors)

> keep the same prefix I got from the first.  Or update other databases.

That does not scale.

Please check the GROW WG for more details.

> Another administrative effort?

Only once.

It seems you want for free what lots of people just do...

> Only to those ISPs who accept it?

Everybody you pay transit (or buy a crate of beer & a sack of onions ;)

These are not technical requirements, but business (read: money/policy)
problems.

> paths.  Up to now I didnt experience 6to4 Relay not responding.

Then you where lucky.

> Are the Tunnel Brokers ready to fill in forms that I request conceive?

I really do not understand that sentence, please rephrase.

> What about the potential abuse from the Tunnel Brokers?

What kind of abuse would the Tunnel Broker cause?

Unless you mean the users. That is simple: depending on the problem
report to authorities and the IPv4 ISP, or just close their account.

> Thanks, I didnt know that.

"There is a RFC for that": http://www.ietf.org/rfc/rfc5158.txt

> vi-ing a config file in my local DNS and then DNS takes care of rest.

Afaik it goes per /48. Hence once per IPv4 address you'll have to fill
something in.

I have never bothered with 6to4 as configured tunnels simply work and do
not have any unreliable properties.

Oh another trip own memory lane: in something like 1997 I had a address
our of 5f04:b000::/32 (rfc1897) thank you Surfnet (Wim Biemolt in
particular) for that tunnel. Thus no, I did not always control the tunnel :)

Greets,
 Jeroen

---

From: James Woodyatt <[email-masked]>
Date: Thu, 13 Nov 2014 13:54:28 -1000

RFC 6732 is obsoleted by this draft, isn't it?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2014 13:01:00 +1300

Well, it isn't right now, but we certainly can do that if Victor
so advises. However, I'm not going to issue a -09 version just for that.

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Nov 2014 02:16:57 +0100

Alex