Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling"

Discussion:

Mark Smith

2017-07-13 08:41:01 UTC

Hi,

I've been thinking about this for a while and finally put together a
draft. It's partly the next step on from a draft I wrote a few years
ago ("Enhancing Virtual Network Encapsulation with IPv6") and also in
response to the recent inserting EH's proposals.

As mentioned, not expecting any discussion at IETF99.

Skinny IPv6 in IPv6 Tunnelling
draft-smith-skinny-ipv6-in-ipv6-tunnelling-02

Abstract

This memo proposes a method of tunnelling IPv6 packets inside IPv6
packets with a reduced tunnelling overhead.

http://www.users.on.net/~markachy/draft-smith-skinny-ipv6-in-ipv6-tunnelling.txt

Comments and suggestions most welcome.

Thanks,
Mark.

JORDI PALET MARTINEZ

2017-07-13 09:29:45 UTC

Permalink

The link doesn’t work for me, even can’t traceroute to the server …

Isn’t in the IETF repository?

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <ipv6-***@ietf.org> en nombre de Mark Smith <***@gmail.com>
Responder a: <***@gmail.com>
Fecha: jueves, 13 de julio de 2017, 10:41
Para: 6man WG <***@ietf.org>
Asunto: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling"

Hi,

I've been thinking about this for a while and finally put together a
draft. It's partly the next step on from a draft I wrote a few years
ago ("Enhancing Virtual Network Encapsulation with IPv6") and also in
response to the recent inserting EH's proposals.

As mentioned, not expecting any discussion at IETF99.

Skinny IPv6 in IPv6 Tunnelling
draft-smith-skinny-ipv6-in-ipv6-tunnelling-02

Abstract

This memo proposes a method of tunnelling IPv6 packets inside IPv6
packets with a reduced tunnelling overhead.

http://www.users.on.net/~markachy/draft-smith-skinny-ipv6-in-ipv6-tunnelling.txt

Comments and suggestions most welcome.

Thanks,
Mark.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
***@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Mark Smith

2017-07-13 09:45:02 UTC

Permalink

On 13 July 2017 at 19:29, JORDI PALET MARTINEZ

Post by JORDI PALET MARTINEZ
The link doesn’t work for me, even can’t traceroute to the server …

Strange. I can access it, however I'm downstream of it. A few of those
"is it up" websites are showing it is reachable.

I'll email you a copy off list.

Post by JORDI PALET MARTINEZ
Isn’t in the IETF repository?

Repository closed for submissions leading up to IETF99, opens again on
the 16th and I got a little impatient because I finished it :-)

Regards,
Mark.

Post by JORDI PALET MARTINEZ
Regards,
Jordi
-----Mensaje original-----
Fecha: jueves, 13 de julio de 2017, 10:41
Asunto: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling"
Hi,
I've been thinking about this for a while and finally put together a
draft. It's partly the next step on from a draft I wrote a few years
ago ("Enhancing Virtual Network Encapsulation with IPv6") and also in
response to the recent inserting EH's proposals.
As mentioned, not expecting any discussion at IETF99.
Skinny IPv6 in IPv6 Tunnelling
draft-smith-skinny-ipv6-in-ipv6-tunnelling-02
Abstract
This memo proposes a method of tunnelling IPv6 packets inside IPv6
packets with a reduced tunnelling overhead.
http://www.users.on.net/~markachy/draft-smith-skinny-ipv6-in-ipv6-tunnelling.txt
Comments and suggestions most welcome.
Thanks,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Templin, Fred L

2017-07-13 14:45:54 UTC

Permalink

I was able to access it. It is an interesting draft - have you thought about how
it would interact with header compression and whole message compression?

Thanks - Fred

-----Original Message-----
Sent: Thursday, July 13, 2017 2:45 AM
Subject: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling"
On 13 July 2017 at 19:29, JORDI PALET MARTINEZ

Post by JORDI PALET MARTINEZ
The link doesn’t work for me, even can’t traceroute to the server …

Strange. I can access it, however I'm downstream of it. A few of those
"is it up" websites are showing it is reachable.
I'll email you a copy off list.

Post by JORDI PALET MARTINEZ
Isn’t in the IETF repository?

Repository closed for submissions leading up to IETF99, opens again on
the 16th and I got a little impatient because I finished it :-)
Regards,
Mark.

of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of
the contents of this information, including attached files, is prohibited.

Post by JORDI PALET MARTINEZ
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Job Snijders

2017-07-13 15:13:36 UTC

Permalink

On Thu, Jul 13, 2017 at 11:29 AM, JORDI PALET MARTINEZ

Post by JORDI PALET MARTINEZ
The link doesn’t work for me, even can’t traceroute to the server …

The problem might be that the server is not reachable over IPv6

Kind regards,

Job

Nick Hilliard

2017-07-13 15:20:14 UTC

Permalink

Post by Job Snijders
On Thu, Jul 13, 2017 at 11:29 AM, JORDI PALET MARTINEZ

Post by JORDI PALET MARTINEZ
The link doesn’t work for me, even can’t traceroute to the server …

The problem might be that the server is not reachable over IPv6

to clarify, the web server host is only available on ipv4. No doubt
this is a dns oversight which will be rectified asap.

Nick

JORDI PALET MARTINEZ

2017-07-13 16:31:52 UTC

Permalink

Not really, it is some IPv4 routing problema.

Saludos,
Jordi

-----Mensaje original-----
De: Job Snijders <***@instituut.net>
Responder a: <***@instituut.net>
Fecha: jueves, 13 de julio de 2017, 17:13
Para: <***@consulintel.es>
CC: 6man WG <***@ietf.org>
Asunto: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling"

On Thu, Jul 13, 2017 at 11:29 AM, JORDI PALET MARTINEZ

Post by JORDI PALET MARTINEZ
The link doesn’t work for me, even can’t traceroute to the server …

The problem might be that the server is not reachable over IPv6

Kind regards,

Job

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Tom Herbert

2017-07-13 21:19:22 UTC

Permalink

Post by Mark Smith
Hi,
I've been thinking about this for a while and finally put together a
draft. It's partly the next step on from a draft I wrote a few years
ago ("Enhancing Virtual Network Encapsulation with IPv6") and also in
response to the recent inserting EH's proposals.

Mark,

In section "9.1. Skinny IPv6-in-IPv6 EH Construction" I think you need
to consider the checksum for protocols that include a pseudo header.
Since the IP addresses are being changed in the packet the TCP or UDP
checksum should be updated to reflect that in the encap/decap
procedures. However, I think the the bigger problem is that when the
original addresses are moved to an extension header they would no
longer be included in any checksum and so corruption of the EH could
ultimately lead to misdelivery. Maybe the EH should include a
checksum?

Tom

Post by Mark Smith
As mentioned, not expecting any discussion at IETF99.
Skinny IPv6 in IPv6 Tunnelling
draft-smith-skinny-ipv6-in-ipv6-tunnelling-02
Abstract
This memo proposes a method of tunnelling IPv6 packets inside IPv6
packets with a reduced tunnelling overhead.
http://www.users.on.net/~markachy/draft-smith-skinny-ipv6-in-ipv6-tunnelling.txt
Comments and suggestions most welcome.
Thanks,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Mark Smith

2017-07-13 23:07:59 UTC

Permalink

Hi Tom,

Thanks very much for having a look and providing feedback.

Post by Tom Herbert

I don't think they need to be, as the TCP or UDP checksum isn't
evaluated by any device while the inner packet is being carried over
the Skinny IPv6-in-IPv6 tunnel.

When the reconstructed inner packet arrives at the final destination
where the TCP or UDP checksum is evaluated, it will be post Skinny
IPv6-in-IPv6 decapsulation, and therefore any Skinny IPv6-in-IPv6
related addressing changes that would have caused the TCP or UDP
checksum to be invalid should have been completely reversed.

Post by Tom Herbert
However, I think the the bigger problem is that when the
original addresses are moved to an extension header they would no
longer be included in any checksum and so corruption of the EH could
ultimately lead to misdelivery. Maybe the EH should include a
checksum?

I think that same risk exists with vanilla IPv6 packets, since there
is no IPv6 Header Checksum, as there was in IPv4.

Post by Tom Herbert
From memory, I understand from Christian's "IPv6 - The New Internet

Protocol" book (really good for lots of the reasons why IPv6 is the
way it is), that it was decided the risks of delivery to the wrong
node were worth it compared to the performance gains of not evaluating
a per-hop IPv6 header checksum. Protection against corruption over a
link is provided by a link-layer checksum, and as this was the reason
why the UDP checksum became mandatory, end-to-end TCP, UDP etc.
checksums protect against corruption inside devices like routers.

So delivery to the wrong node is possible, however that node will
ignore it because TCP, UDP etc. checksum will fail.

Skinny IPv6-in-IPv6 is using IPv6 as a virtual link-layer, so it could
be argued this should have a link-layer checksum, however there will
be real link-layers underneath with checksums, so a checksum in Skinny
IPv6-in-IPv6 is probably not necessary.

I'm not against including a checksum if useful and know that GRE does
have that option. I'm not sure how often the GRE checksum option is
used, although I haven't heard of it being used and I'm around people
who might. A search for "GRE checksum" only finds one link on the
first page of the search results that is related to operationally
enabling it, and the person answering the question also says in their
experience it isn't commonly used.

I'll look to include some of the above comments in the draft as they
sound like they could be common queries.

Thanks again for having a look.

Regards,
Mark.

Mark Smith

2017-07-14 00:46:03 UTC

Permalink

Hi Tom,

Post by Tom Herbert

I've just realised that you might have been talking about middleboxes
validating the TCP or UDP checksum while the inner packet is Skinny
IPv6-in-IPv6 encapsulated. Yes, that would fail.

My expectation of the common use case for Skinny IPv6-in-IPv6 is
limited to within middle box free closed networks e.g., the SPRING
situation rather than over the Internet where middle boxes might be
encountered.

EHs seem to be being commonly dropped on the Internet anyway, so a new
one like a Skinny IPv6-in-IPv6 EH is unlikely to be very usable over
the Internet. I'll put some text in about that limitation and propose
the use of am optional UDP header in front of the Skinny IPv6-in-IPv6
EH to trick middle boxes into letting it through.

Shame to do that because of the additional UDP overhead. At least the
inner packet IID entropy in the outer packet SA and DA would still be
a benefit in that case where existing IPv6 routers don't use Flow
Labels for load balancing.

Thanks,
Mark.

Tom Herbert

2017-07-14 16:01:22 UTC

Permalink

Post by Mark Smith
Hi Tom,

Post by Tom Herbert

Every NIC performs checksum offload, if a host is both an outer and
inner destination then there's a pretty good chance we lose that and
so the cost is much greater compared to processing an eight byte UDP
header. Also, there's a good chance we lose GSO. This is why UDP
encapsulation is so popular, it can be used to make an encapsulation
work transparently with any encapsulation format. That being said,
defining Skinny as an extension header should work out fine in this
respect. This would be amenable for use with GUE which gives the UDP
encapsulation, a checksum that could cover the Skinny IP addresses,
remote checksum offload, etc.

With regards to SPRING, it would be good to have a better description
of the problem their facing. AFAICT, the SPRING EH use could be quite
large anyway so the need to jump through these hoops to just save a
few bytes of an additional IP header isn't obvious to me.

Tom