Subject: Re: [v6ops] draft-steffann-tunnels-00.txt

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 Mar 2013 17:36:40 +0100

On 15 feb 2013, at 9:44, Iljitsch van Beijnum <[email-masked]> wrote:

> Three of us were asked by the Dutch academic network Surfnet to write an overview of IPv6-in-IPv4 tunneling mechanisms. To benefit the wider community, we did so in the form of a draft, that we intend to submit to the RFC Editor as an independent submission.

> However, we would very much appreciate reviews and comments from within the IETF.

We have submitted version -01 which addresses remarks from reviewers. The new version can be found here:

https://datatracker.ietf.org/doc/draft-steffann-tunnels/

We plan on submitting the draft to the RFC Editor at the end of the week.

Iljitsch

---

From: Tina TSOU <[email-masked]>
Date: Tue, 19 Mar 2013 19:13:38 +0000

Dear Iljitsch,
Thanks for letting us know.

Section 3,
When it mentions DS-Lite and MAP, I think a more complete picture could be mentioned in the folloiwng way.

  Dual-Stack Lite [RFC6333] (Full stateful), LW4o6 [I-D.cui-softwire-b4-translated-ds-lite] (Binding), MAP [I-D.ietf-softwire-map] (Full Stateless), refered in section 4 of Unified CPE [I-D.ietf-softwire-unified-cpe], all developed by the IETF Softwire working group, often come up in
   discussions about IPv6 tunneling.  However, they are _not_ IPv6-in-
   IPv4 tunnel mechanisms.  They are IPv4-in-IPv6 mechanisms for
   providing IPv4 connectivity over an IPv6 infrastructure.

P.s. LW4o6 [I-D.cui-softwire-b4-translated-ds-lite] may become WG draft by April 2, after the confirming the adoption in the list besides the strong support for adoption in the room. Then you may need to update the reference name later.

Thank you,
Tina

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Iljitsch van Beijnum
> Sent: 2013年3月19日 9:37
> To: IPv6 Ops WG
> Cc: [email-masked]
> Subject: Re: [v6ops] draft-steffann-tunnels-00.txt
> 
> > Three of us were asked by the Dutch academic network Surfnet to write
> an overview of IPv6-in-IPv4 tunneling mechanisms. To benefit the wider
> community, we did so in the form of a draft, that we intend to submit to
> the RFC Editor as an independent submission.
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 20 Mar 2013 11:36:09 +0100

Hi Tina,

> When it mentions DS-Lite and MAP, I think a more complete picture could be mentioned in the folloiwng way.

Yes, this has the advantage of being more complete.

However, because we discuss so many mechanisms in the document, we ended up with more than 5 pages of references, which we feel would overwhelm readers, especially ones less familiar with the IETF.

So we've tried to limit references to only the most relevant ones. Considering that, we believe that just the RFC 6333 reference for the Softwire work, which is explicitly out of scope, is sufficient.

Thanks,

Iljitsch

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 Mar 2013 10:43:15 +0000

> So we've tried to limit references to only the most relevant ones. Considering that, we believe that just the RFC 6333 reference for the Softwire work, which is explicitly out of scope, is sufficie…

Hi,

I think this is a great document - well done to the authors.  

I agree the level of references is fine as is.

Tim

---

From: Arturo Servin <[email-masked]>
Date: Wed, 20 Mar 2013 09:01:18 -0300

I haven't read it all but it looks like a great document.

	You mentioned that you are planning to do an independent submission
(for the dates perhaps you have done it), however I would see a lot of
value for v6ops if you change your mind.

Regards,
/as

On 15/02/2013 06:44, Iljitsch van Beijnum wrote:
> Hi all,
> However, we would very much appreciate reviews and comments from within the IETF. These are the mechanisms we discuss:
> 
> 3.  Tunnel Mechanisms  . . . . . . . . . . . . . . . . . . . . . .  5
>      3.1.  Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . .  6
>      3.2.  Automatic Tunneling  . . . . . . . . . . . . . . . . . . .  7
>      3.3.  IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . .  8
>      3.4.  Generic Routing Encapsulation (GRE)  . . . . . . . . . . .  9
>      3.5.  Connection of IPv6 Domains via IPv4 Clouds (6to4)  . . . .  9
>      3.6.  Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 10
>      3.7.  Intra-site Automatic Tunnel Addressing (ISATAP)  . . . . . 11
>      3.8.  Tunneling IPv6 over UDP through NATs (Teredo)  . . . . . . 12
>      3.9.  IPv6 Rapid Deployment (6rd)  . . . . . . . . . . . . . . . 13
>      3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 14
>      3.11. Peer-to-Peer IPv6 on Any Internetwork (6bed4)  . . . . . . 15
>      3.12. The Locator/ID Separation Protocol (LISP)  . . . . . . . . 16
>    4.  Related Protocols  . . . . . . . . . . . . . . . . . . . . . . 17
>      4.1.  Tunnel Information and Control protocol (TIC)  . . . . . . 17
>      4.2.  Tunnel Setup Protocol (TSP)  . . . . . . . . . . . . . . . 18
>      4.3.  Dual-Stack Lite (Softwire) . . . . . . . . . . . . . . . . 19
> 
> Thanks!
> 
> Iljitsch
> 
> 
> Begin forwarded message:
> 
>> From: [email-masked]
>> Subject: I-D Action: draft-steffann-tunnels-00.txt
>> Date: 15 februari 2013 9:34:07 CET
>> To: [email-masked]
>> Reply-To: [email-masked]
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>> 	Title           : A comparison of IPv6 tunneling mechanisms
>> 	Author(s)       : S.J.M. Steffann
>>                          Iljitsch van Beijnum
>>                          Rick van Rein
>> 	Filename        : draft-steffann-tunnels-00.txt
>> 	Pages           : 37
>> 	Date            : 2013-02-15
>>
>> Abstract:
>>   This document provides an overview of various ways to to tunnel IPv6
>>   packets over IPv4 networks.  It covers mechanisms in contemporary
>>   use, touches on several mechanisms that are now only of historic
>>   interest, and discusses some newer tunneling mechanisms that are not
>>   (yet) widely used at the time of publication.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-steffann-tunnels
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-steffann-tunnels-00
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 20 Mar 2013 17:28:26 +0100

> 	I haven't read it all but it looks like a great document.

Thanks. (And Tim, too.)

> value for v6ops if you change your mind.

What would be the benefit of publication as an IETF document?

Iljitsch

---

From: Arturo Servin <[email-masked]>
Date: Wed, 20 Mar 2013 17:09:54 -0300

Peer review and a nice and shiny RFC number.

Regards
as

---

From: John Mann <[email-masked]>
Date: Fri, 22 Mar 2013 15:21:00 +1100

Hi,

Since you discuss LISP which among other things can tunnel IPv6 in IPv4,
why not also discuss SEAL (and its friends VET, RANGER, IRON)

References
    http://tools.ietf.org/html/rfc5320
    or http://tools.ietf.org/html/draft-templin-intarea-seal-52
    http://www.isatap.org/
Tunneling Mechanism Feature Comparison (v0.1)
    http://isatap.com/comparison.pdf

Thanks,
    John

On 20 March 2013 03:36, Iljitsch van Beijnum <[email-masked]> wrote:

> > Three of us were asked by the Dutch academic network Surfnet to write an
> overview of IPv6-in-IPv4 tunneling mechanisms. To benefit the wider

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 22 Mar 2013 09:08:34 +0100

> why not also discuss SEAL (and its friends VET, RANGER, IRON)

We were unaware of RANGER and IRON, but decided against including SEAL and VET. Like LISP, those protocols are not really meant to be IPv6-in-IPv4 tunneling mechanisms, but we have information that LISP is actually used as such by at least a few people.

Iljitsch

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 22 Mar 2013 15:19:06 +0000

We use SEAL and VET internally within Boeing, and have IRON
as a proposed network mobility solution for civil aviation
(among many other uses). The first editions of these documents
were published as RFC5320, RFC5558 and RFC6179. The second
editions are now in the RFC Editor queue:

https://datatracker.ietf.org/doc/draft-templin-intarea-seal/
https://datatracker.ietf.org/doc/draft-templin-intarea-vet/
https://datatracker.ietf.org/doc/draft-templin-ironbis/

Like AYIYA, these mechanisms are for encapsulation of any
IP-in-IP versions, including IPv6-in-IPv4. I will eventually
get around to creating a second edition of RANGER, but for
now the references are RFC5720 and RFC6139.

Thanks - Fred
[email-masked]

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Iljitsch van Beijnum
> Sent: Friday, March 22, 2013 1:09 AM
> To: John Mann
> Cc: IPv6 Ops WG; [email-masked]
> We were unaware of RANGER and IRON, but decided against including SEAL and
> VET. Like LISP, those protocols are not really meant to be IPv6-in-IPv4
> tunneling mechanisms, but we have information that LISP is actually used
> as such by at least a few people.
> 
> Iljitsch

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 22 Mar 2013 11:24:45 -0400

Hi Iljitsch,
  Thanks for writing this draft. I believe that it is very useful. I
just had a couple of minor comments (on draft -01) that you may want to
address.

* Section 3.5

I think a short summary of 6to4 Provider Managed Tunnels (RFC6732) would
be useful here for completeness.

* Section 3.8

"Teredo is specified in [RFC4380] and a few updates"

I think the security updates in RFC5991 are probably worth mentioning here.

"This process is not sufficiently reliable; Teredo fails in about 37%
[TERTST] of its attempts to connect to native IPv6 destinations."

In this context it is probably useful to say that there are some
extensions to Teredo that significantly decrease the failure rate.
Please see RFC6081.

* Section 6.2

As mentioned in Section 3.5, the table needs to be updated to include
ISP in the 6to4 row (RFC6732)

Cheers
Suresh

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 24 Mar 2013 22:17:23 +0100

Hi Suresh,

I'll reply to the rest of your message later. But:

> be useful here for completeness.

I'm surprised this was published as an RFC without a big fat IAB/IESG warning. Or at all, really. This obviously isn't "informational", but experimental in disguise.

Besides being a very bad idea on many levels, I don't even think this can work.

What if node A, which has real 6to4 at 2002:1000:1::/48 wants to communicate with node B, which has fake 6to4 prefix 2002:6440:1::/48 which maps to 2001:db8:6400:1::/64?

B sends a packet to A, bypassing the relay/translator, as A and B both share the "directly connected" subnet 2002::/16. As such, B's prefix isn't translated, and A sends back an encapsulated IPv6 packet to 100.64.0.1, which of course never makes it because that address is not globally unique.

Iljitsch

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 25 Mar 2013 10:41:09 +0900

On Mon, Mar 25, 2013 at 6:17 AM, Iljitsch van Beijnum <[email-masked]>wrote:

> I'm surprised this was published as an RFC without a big fat IAB/IESG
> warning. Or at all, really. This obviously isn't "informational", but
> experimental in disguise.
>

RFC 6732 is an independent submission. It was taken to v6ops, but there was
significant opposition to it, and the authors went the individual
submission route. I agree it should not be cited by any v6ops document.

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 24 Mar 2013 22:41:59 +0100

>experimental in disguise.

6to4-PMT has been in production for over two years and about 1.5 years
before it was published - ISE stream not working group (as noted by
Lorenzo). 

>Besides being a very bad idea on many levels, I don't even think this can

It's been successful and has significantly reduced 6to4 issues in our
network. Basic premise in the beginning was

Native IPv6 <better then> tunnelled IPv6 <better then> PMT <better then>
Broken IPv6 (so when broken/poor IPv6 was the alternative, then PMT is
better then that). 

In general I dislike NATs, but NATs are better then broken IP connectivity
(at least, that's what the customers seem to think- they don't seem to
care much on how we un-break them).

>
>What if node A, which has real 6to4 at 2002:1000:1::/48 wants to
>communicate with node B, which has fake 6to4 prefix 2002:6440:1::/48
>which maps to 2001:db8:6400:1::/64?
>
>B sends a packet to A, bypassing the relay/translator, as A and B both
>share the "directly connected" subnet 2002::/16. As such, B's prefix
>isn't translated, and A sends back an encapsulated IPv6 packet to
>100.64.0.1, which of course never makes it because that address is not
>globally unique.

The case above is based on using IPv4 space for endpiont addressing which
is not globally routed (includes RFC6598 and any squat or un-routed
non-RFC1918 space).

In such a case, the PMT function would be co-located with the CGN (since
you need that for global connectivity anyway).  So if node b sends packet
to node a, it would be prefix translated.

You are correct that if node A sends a packet to node b's 6to4 address
(based on RFC6598 in that case), it's broken. But it was broken before
anyway.

I am by no means attempting to have draft-steffann-tunnels include PMT - I
really don't care.  PMT is in production, works and will be there until
6to4 issues are gone.  There will be some corner cases which are not
fixed, but remember this was about making something that was broken work
again (not make something good - that's what native IPv6 is for).

As for the draft text, I think the warning part of section 3.5 (6to4)
should include not just RFC6598, but also IPv4 space which may be used
that is not routed (squat or otherwise).

Regards,

Victor K

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 25 Mar 2013 12:30:30 +0900

On Mon, Mar 25, 2013 at 6:41 AM, Victor Kuarsingh <[email-masked]> wrote:

> PMT is in production, works and will be there until 6to4 issues are gone.
>  There will be some corner cases which are not fixed, but remember this
> was about making something that was broken work again (not make something
> good - that's what native IPv6 is for).
>

Out of curiosity, do you have usage stats from your production deployment?
What percentage of users actually uses this, and has that percentage been
rising or falling? I'd be very interesting in seeing those numbers.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Mar 2013 08:22:30 +0000

Iljistch,

Did you read the "Status of This Memo" section? I don't see
why the IESG would have added anything more.

I was the reviewer for the Independent Series Editor for this document.
fyi, I have attached my review - some changes were made as a result.
But basically this is like any other Independent Submission describing
running code that is not a candidate for IETF publication.

Regards
   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 25 Mar 2013 13:29:51 +0100

On 25 mrt 2013, at 9:22, Brian E Carpenter <[email-masked]> wrote:

> Did you read the "Status of This Memo" section?

I don't really read those, they're boilerplate. And I believe that the text in this instance is identical to that of other independent submissions, which takes any bite that it may have had out of it.

> I don't see why the IESG would have added anything more.

Something similar to here:

http://tools.ietf.org/html/rfc5572

"This work was considered in the IETF but rejected"

Remember that most people don't appreciate details such as IETF/independent or standards track/experimental/informational, an RFC number conveys a lot of authority. As such, a very explicit warning would have been appropriate.

> running code that is not a candidate for IETF publication.

Other than the obvious issue, I find it troublesome that this RFC doesn't cover the case of communication between a host behind a PMT and a regular 6to4 host. This can easily be solved by intercepting all protocol 41 packets in the CGN, but for some reason this issue is left out of the document, making this "solution" even worse than in needs to be, and also withholding vital information from the readers of the document.

And a better solution for the "who left the 6to4 on" problem would be to run a gateway that returns network unreachables, which should make hosts retry over IPv4.

Iljitsch

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Mar 2013 12:48:58 +0000

On 25 Mar 2013, at 12:29, Iljitsch van Beijnum <[email-masked]> wrote:
> 
> Remember that most people don't appreciate details such as IETF/independent or standards track/experimental/informational, an RFC number conveys a lot of authority.

Indeed.

> As such, a very explicit warning would have been appropriate.

Well, that is down to the author, unless the individual submission boilerplates are changed to include a 'health warning'.

The key point here though is that draft-steffann-tunnels says the right thing, which I think it does, without PMT.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Mar 2013 13:16:24 +0000

>> Remember that most people don't appreciate details such as IETF/independent or standards track/experimental/informational, an RFC number conveys a lot of authority.

To be blunt, "I don't read the boilerplate" is not an excuse for
not reading the boilerplate.

>> As such, a very explicit warning would have been appropriate.

Which is why the boilerplate says what it does.

> Well, that is down to the author, unless the individual submission boilerplates are changed to include a 'health warning'.

The IESG can and sometimes does add extra warnings to independent
submissions when they decide it's necessary.

Iljitsch has pointed out a failure scenario (client behind provider-managed
6to4 contacts host behind standard 6to4). I'm guessing that would break
BitTorrent? It sounds like a case for http://www.rfc-editor.org/errata.php

> The key point here though is that draft-steffann-tunnels says the right thing, which I think it does, without PMT.

Agreed.

   Brian

---

From: Sander Steffann <[email-masked]>
Date: Mon, 25 Mar 2013 17:42:34 +0400

Hi,

>> The key point here though is that draft-steffann-tunnels says the right thing, which I think it does, without PMT.

Thank you all for your feedback on this!
Sander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 25 Mar 2013 14:43:19 +0100

On 25 mrt 2013, at 14:16, Brian E Carpenter <[email-masked]> wrote:

> BitTorrent?

That's an interesting question. An outgoing session from the PMT user to the 6to4 user wouldn't work, because the PMT user's 6to4 addresses are not globally unique and aren't seen by the prefix translator. However, the PMT user can still receive incoming sessions through the PMT prefix, but only if the 6to4 user somehow learns that address. And the PMT user probably doesn't know that address themselves unless the application uses STUN or something, which it probably won't do for IPv6...

Of course everything will still work as long as there is at least one non-6to4/non-PMT user that can receive incoming sessions participating in the file transfer.

> It sounds like a case for http://www.rfc-editor.org/errata.php

I'll see what I can do.

Iljitsch

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 25 Mar 2013 10:55:53 -0400

Hi Iljitsch,

> I'm surprised this was published as an RFC without a big fat IAB/IESG warning. Or at all, really. This obviously isn't "informational", but experimental in disguise.

Since this draft provides an overview of existing tunneling methods, I
suggested RFC6732 for *completeness*. Agree with you fully about the
broken cases.

Thanks
Suresh

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 25 Mar 2013 17:15:28 +0100

> I think the security updates in RFC5991 are probably worth mentioning here.

We feel this is too detailed to warrant inclusion.

> extensions to Teredo that significantly decrease the failure rate.

Interesting!

Do you know if these mechanisms are implemented?

> ISP in the 6to4 row (RFC6732)

Done.

Thanks for the review.

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 25 Mar 2013 17:18:20 +0100

> that is not routed (squat or otherwise).

Do you have a reference that we can cite about this issue?

Thanks,

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 25 Mar 2013 17:25:39 +0100

> be useful here for completeness.

Let me explain why we decided not to include this. (We decided this together but the reasons below are mine and not necessarily those of my co-authors.)

One reason is to avoid endorsing NAT in IPv6. Another is length/scope: discussing all the issues with prefix translation, which currently don't come up, would require a significant amount of extra text.

Apart from that, this is not a mechanism that a user can decide to run on their own. Rather, it's something the ISP does that changes the 6to4 that the user has enabled (or more likely, was enabled out of the box).

Finally, although I could be mistaken, it looks like the mechanism isn't in very wide use.

Iljitsch

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 25 Mar 2013 13:45:49 -0400

Ilijitsch,

I will look for some more, but rfc6319 has some text..

regards,

Victor K

---

From: james woodyatt <[email-masked]>
Date: Mon, 25 Mar 2013 11:06:09 -0700

> B sends a packet to A, bypassing the relay/translator, as A and B both share the "directly connected" subnet 2002::/16. As such, B's prefix isn't translated, and A sends back an encapsulated IPv6 p…

This is why the very next release of AirPort and Time Capsule firmware Apple released after the publication of the 6to4-PMT draft made the 100.64/10 address space ineligible for use as outer IPv4 addresses in its "Automatic IPv6 Tunnel Router" feature.

One hopes that other vendors of home gateway appliances, which implement similar features, will either remove the feature entirely or, at the very least, deploy defensive measures similar to what Apple did to prevent service providers from inflicting RFC 6732 on their innocent subscribers.  Only *you* can prevent wild fires.

--
james woodyatt <[email-masked]>
core os networking

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 Mar 2013 13:56:32 +0400

Hi James,

> This is why the very next release of AirPort and Time Capsule firmware Apple released after the publication of the 6to4-PMT draft made the 100.64/10 address space ineligible for use as outer IPv4 a…

Good to hear that. Thanks!
Sander