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

From: Mark Smith <[email-masked]>
Date: Thu, 13 Jul 2017 18:41:01 +1000

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.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Jul 2017 11:29:45 +0200

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 <[email-masked]> en nombre de Mark Smith <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 13 de julio de 2017, 10:41
Para: 6man WG <[email-masked]>
Asunto: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling"

    Hi,

    
    Abstract

    
    Thanks,
    Mark.
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked]
    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.

---

From: Mark Smith <[email-masked]>
Date: Thu, 13 Jul 2017 19:45:02 +1000

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

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 13 Jul 2017 14:45:54 +0000

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-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith
> Sent: Thursday, July 13, 2017 2:45 AM
> To: [email-masked]
> Cc: 6man WG <[email-masked]>
> Subject: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling"
> 
> > 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.
> >
> >
> >

---

From: Job Snijders <[email-masked]>
Date: Thu, 13 Jul 2017 17:13:36 +0200

> 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

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 13 Jul 2017 16:20:14 +0100

> 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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Jul 2017 18:31:52 +0200

Not really, it is some IPv4 routing problema.

Saludos,
Jordi

-----Mensaje original-----
De: Job Snijders <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 13 de julio de 2017, 17:13
Para: <[email-masked]>
CC: 6man WG <[email-masked]>
Asunto: Re: Not for formal discussion at IETF99 - "Skinny IPv6 in IPv6 Tunnelling"

    
    Kind regards,
    
    Job

---

From: Tom Herbert <[email-masked]>
Date: Thu, 13 Jul 2017 14:19:22 -0700

> 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

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Jul 2017 09:07:59 +1000

Hi Tom,

Thanks very much for having a look and providing feedback.

On 14 July 2017 at 07:19, Tom Herbert <[email-masked]> wrote:
> procedures.

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.

>However, I think the the bigger problem is that when the

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

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

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Jul 2017 10:46:03 +1000

Hi Tom,

> checksum should be updated to reflect that in the encap/decap

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.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 14 Jul 2017 09:01:22 -0700

> situation rather than over the Internet where middle boxes might be
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