Subject: Updates to RFC6434

From: Timothy Winters <[email-masked]>
Date: Mon, 30 Oct 2017 09:42:43 -0400

We have posted an updated version of 6434bis, with the following changes
since Prague:

   - Text on EH processing
   - Noted that RFC4191 is a MUST, but a SHOULD for Type C node
   - Updated RFC references (8200, 8201, 8221, 8247)
   - Added note on RFC 7772 for power consumption
   - Added ‘Why /64?’ reference; RFC 7421
   - Removed jumbogram text
   - Added reference to draft-ietf-v6ops-unique-ipv6-prefix-per-host
   - For 3GPP, added ‘snapshot’ comment on RFC7066
   - Added RFC8028 as a SHOULD (for Section 5.5 from RFC 6724)
   - Removed ATM over IPv6
   - Added reference to RFC8064
   - Added MUST for BCP 198, and ref to draft-ietf-v6ops-ipv6rtr-reqs
   - Added text on avoiding 1280 MTU for UDP (inc. DNS) traffic

We'll be sending some additional questions to the list later this week to
hopefully get this document ready for working group last call.

~Tim, Tim and John

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Oct 30, 2017 at 9:36 AM
Subject: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt
To: [email-masked]
Cc: [email-masked]

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

        Title           : IPv6 Node Requirements
        Authors         : Tim Chown
                          John Loughney
                          Timothy Winters
        Filename        : draft-ietf-6man-rfc6434-bis-02.txt
        Pages           : 40
        Date            : 2017-10-30

Abstract:
   This document defines requirements for IPv6 nodes.  It is expected
   that IPv6 will be deployed in a wide range of devices and situations.
   Specifying the requirements for IPv6 nodes allows IPv6 to function
   well and interoperate in a large number of situations and
   deployments.

   This document obsoletes RFC 6434, and in turn RFC 4294.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6434-bis-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6434-bis-02

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/

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

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 30 Oct 2017 13:58:50 +0000

Hi Guys,

   How should readers of 6434bis reconcile the following two statements from section 5.4 ?

   Neighbor Discovery is defined in [RFC4861]; the definition was
   updated by [RFC5942].  Neighbor Discovery SHOULD be supported.

--
   All nodes MUST support the sending and receiving of Neighbor
   Solicitation (NS) and Neighbor Advertisement (NA) messages.  NS and
   NA messages are required for Duplicate Address Detection (DAD).

Thanks,
Randy

From: ipv6 [mailto:[email-masked]] On Behalf Of Timothy Winters
Sent: Monday, October 30, 2017 9:43 AM
To: 6man WG <[email-masked]>
Subject: Updates to RFC6434

We have posted an updated version of 6434bis, with the following changes since Prague:

  *   Text on EH processing
  *   Noted that RFC4191 is a MUST, but a SHOULD for Type C node
  *   Updated RFC references (8200, 8201, 8221, 8247)
  *   Added note on RFC 7772 for power consumption
  *   Added ‘Why /64?’ reference; RFC 7421
  *   Removed jumbogram text
  *   Added reference to draft-ietf-v6ops-unique-ipv6-prefix-per-host
  *   For 3GPP, added ‘snapshot’ comment on RFC7066
  *   Added RFC8028 as a SHOULD (for Section 5.5 from RFC 6724)
  *   Removed ATM over IPv6
  *   Added reference to RFC8064
  *   Added MUST for BCP 198, and ref to draft-ietf-v6ops-ipv6rtr-reqs
  *   Added text on avoiding 1280 MTU for UDP (inc. DNS) traffic
We'll be sending some additional questions to the list later this week to hopefully get this document ready for working group last call.

~Tim, Tim and John

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Oct 30, 2017 at 9:36 AM
Subject: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

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

Abstract:

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<http://tools.ietf.org>.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--

Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: Timothy Winters <[email-masked]>
Date: Mon, 30 Oct 2017 10:06:16 -0400

Hi Randy,

The original RFC 6434 has this same text.   In this case it's calling out
for the purpose of DAD that you have to support sending NA and NS as
defined in RFC 4861.   The rest of the 4861 (Router Discovery, Address
Resolution, etc...) are covered under the SHOULD at the top of the Section
5.4.

~Tim

On Mon, Oct 30, 2017 at 9:58 AM, Turner, Randy <[email-masked]>
wrote:

> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *Timothy Winters
> *Sent:* Monday, October 30, 2017 9:43 AM
> *To:* 6man WG <[email-masked]>
> *Subject:* Updates to RFC6434
>
>
>
> Now offering testing for SDN applications and controllers in our SDN
> switch test bed. Learn more today http://bit.ly/SDN_IOLPR
>

--

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Oct 2017 19:37:11 +0000

We talked about adding an informative reference to RFC1122. Can
you please add that?

Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Timothy Winters
Sent: Monday, October 30, 2017 6:43 AM
To: 6man WG <[email-masked]>
Subject: Updates to RFC6434

  *   Text on EH processing

~Tim, Tim and John

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Oct 30, 2017 at 9:36 AM
Subject: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

--

---

From: Timothy Winters <[email-masked]>
Date: Mon, 30 Oct 2017 15:46:06 -0400

Hi Fred,

I thought we decided we didn't want to point to the historic IPv4 text in
that.  Can you remind me were you wanted that text?

~Tim

On Mon, Oct 30, 2017 at 3:37 PM, Templin, Fred L <[email-masked]>
wrote:

> *Sent:* Monday, October 30, 2017 6:43 AM

--

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Oct 2017 20:06:26 +0000

Hi Tim,

I am referring to Tim Chown’s proposed resolution to my original comment:

https://www.ietf.org/mail-archive/web/ipv6/current/msg28394.html

Tim’s proposal was to cite RFC1122 in the intro, which I agree would be
appropriate.

Thanks - Fred

From: Timothy Winters [mailto:[email-masked]]
Sent: Monday, October 30, 2017 12:46 PM
To: Templin, Fred L <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: Updates to RFC6434

Hi Fred,

I thought we decided we didn't want to point to the historic IPv4 text in that.  Can you remind me were you wanted that text?

~Tim

On Mon, Oct 30, 2017 at 3:37 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
We talked about adding an informative reference to RFC1122. Can
you please add that?

Fred

From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Timothy Winters
Sent: Monday, October 30, 2017 6:43 AM
To: 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: Updates to RFC6434

  *   Text on EH processing

~Tim, Tim and John

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Oct 30, 2017 at 9:36 AM
Subject: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

--

--

---

From: Tim Chown <[email-masked]>
Date: Mon, 30 Oct 2017 20:27:40 +0000

That was a ‘could’; I think we subsequently agreed it wasn’t necessary, for the reason Tim mentioned?

Tim

> On 30 Oct 2017, at 20:06, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Tim,
>  
> On Mon, Oct 30, 2017 at 3:37 PM, Templin, Fred L <[email-masked]> wrote:
> 	• Text on EH processing 
> 	• Noted that RFC4191 is a MUST, but a SHOULD for Type C node
> 	• Updated RFC references (8200, 8201, 8221, 8247)
> 	• Added note on RFC 7772 for power consumption
> 	• Added ‘Why /64?’ reference; RFC 7421
> 	• Removed jumbogram text 
> 	• Added reference to draft-ietf-v6ops-unique-ipv6-prefix-per-host
> 	• For 3GPP, added ‘snapshot’ comment on RFC7066
> 	• Added RFC8028 as a SHOULD (for Section 5.5 from RFC 6724)
> 	• Removed ATM over IPv6
> 	• Added reference to RFC8064
> 	• Added MUST for BCP 198, and ref to draft-ietf-v6ops-ipv6rtr-reqs
> 	• Added text on avoiding 1280 MTU for UDP (inc. DNS) traffic

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Oct 2017 20:46:31 +0000

Hi Tim,

I believe it should be cited in the introduction in the same way as
RFC8200 cites RFC791.

Fred

> -----Original Message-----
> From: Tim Chown [mailto:[email-masked]]
> Sent: Monday, October 30, 2017 1:28 PM
> Cc: Timothy Winters <[email-masked]>; 6man WG <[email-masked]>

---

From: Tim Chown <[email-masked]>
Date: Mon, 30 Oct 2017 23:32:03 +0000

Hi Fred,

We can add this topic to the list of things to be raised in the Singapore meeting.

If anyone else has strong view on this, please do shout now though.

Tim 

> On 30 Oct 2017, at 20:46, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Tim,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Oct 2017 23:46:15 +0000

Tim,

Consider also as a second example that RFC4861, section 3.1 gives
a "Comparison with IPv4", including citations of RFC826 and other
relevant IPv4 RFCs.

Whereas RFC8200 and RFC4861 have multiple paragraphs, however,
I think rfc6434(bis) can make do with s single sentence near the
beginning as for RFC8200.

Thanks - Fred

> Sent: Monday, October 30, 2017 4:32 PM

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Oct 2017 20:01:25 -0400

Tim, Tim and John, thanks again for taking on 6434bis.

Let me open a can of worms, now that the draft deadline has just passed :-)

We argued lots in producing RFC8200 that one solution for inserting headers
mid-way was to add an IPIP header.   If we really think that this is
operationally possible(*), then I think we need to write text in 6434bis to make
it true.

For some uses of IPIP-based header insertion there can be clearly a node (a
router probably) which could then remove the newly inserted header, and the
IPIP header added can be addressed to that node (%).   This is an IPIP tunnel.  I
believe that LISP does something like this, and many of us are familiar with
IPsec tunnel mode as well.

For many other uses, the only obvious target for the IPIP header is the same
destination address as what was originally there, and so a packet like:
            IP{src:A, dst: B} ULP

becomes
            IP{src:D, dst: B} IP{src:A, dst: B} ULP

And I think that most host stacks discard such things unless configured to
expect a tunnel from D.

What to do?

I'd like to make it clear that the above construct is valid and that hosts
SHOULD process it to remove the first IPIP hader and then process the packet
as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then discard)

There are also implications for security devices, but in most respects I
don't think that they are different than for extension headers.

As an aside, it would also be nice if we could say that an IPsec AH header
with an unknown SPI should be skipped as if it wasn't even there (including
any subsequent IP header as above..)  This is essentially a similar
situation.  I suspect that this statement is even more controversial.

(*)- I think it's operationally possible, and draft-ietf-roll-useofrplinfo
     explains how to do it within the controlled environment of an LLN.
     I spent half the morning putting final touches to that...

(%)- for the cases where an "exit" node is easy to identify, and the traffic
     is guarantee to get to, doing a non-IPIP header insertion is even easier
     to argue for.  Any arguments that the packet might "escape" being
     un-molested are arguments for why 6434bis has to deal with IPIP headers.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Oct 2017 14:08:14 +1300

Hi Michael,

I think this is an interesting topic but I'd really rather
seprate it from 6434bis, because we need 6434bis as soon
as reasonably possible, and this will take a while.

We've got ourselves into trouble at least twice with
automatic tunnels. I'm referring to 6to4 (where I share the
blame) and Teredo. They were both IPv6inIPv4 but I think
some of the same risks will arise with IPv6inIPv6. There may
be contexts where automatic decapsulation is safe and makes
sense. There may be others where it generates either operational
black holes or enticing security loopholes.

So I think this needs to be worked as a separate topic, and
I look forward to your draft... :-)

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Oct 2017 21:23:28 -0400

> as reasonably possible, and this will take a while.

Well, I tried to raise this while doing 8200, and was told that I should wait
until we got to host requirements.

I'm inclined to file an errata against 8200 if 6463bis proceeds without
dealing with the issue.

    > I look forward to your draft... :-)

I can write a draft.
I will write it to update 6463.

---

From: Mark Smith <[email-masked]>
Date: Tue, 31 Oct 2017 19:13:36 +1100

On 31 Oct. 2017 11:02, "Michael Richardson" <[email-masked]> wrote:

We argued lots in producing RFC8200 that one solution for inserting headers
mid-way was to add an IPIP header.   If we really think that this is
operationally possible(*), then I think we need to write text in 6434bis to
make
it true.

IPIP header added can be addressed to that node (%).   This is an IPIP
tunnel.  I

becomes

What to do?

I'd like to make it clear that the above construct is valid and that hosts
SHOULD process it to remove the first IPIP hader and then process the packet
as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then
discard)

I don't think this decapsulation is forwarding. Forwarding is really just
what to do when receiving a packet with a DA that doesn't match the
device's address(es). Hosts drop them, routers see what the forwarding
table says to do with them.

The processing you're describing is passing the payload, post
decapsulation, to the payload processing module indicated by the payload
type field in the previous header.

In the case of IPinIP, the host supports the payload type of IPinIP or
protocol 4, and knows that a payload of that type gets submitted to the
IPv4 packet processing module. If the DA of the payload IP packet matches
the host's, then it should be processed the same way as the former outer
packet was. IPinIPinIP should be processed the same way as IPinIP.

Regards,
Mark.

(%)- for the cases where an "exit" node is easy to identify, and the traffic
     is guarantee to get to, doing a non-IPIP header insertion is even
easier
     to argue for.  Any arguments that the packet might "escape" being
     un-molested are arguments for why 6434bis has to deal with IPIP
headers.

---

From: Ole Troan <[email-masked]>
Date: Tue, 31 Oct 2017 09:30:03 +0100

Michael,

Without having thought very much about it... I do think requiring a host to accept tunnelled packets to itself by default or not, requires further considerations.

I am aware of no implementation that would support this. I would also be worried about this opening the door for "alternate" paths into the host stack.
I think you would have to write a draft.

Another aspect of IP in IP is that with the recent troubles we have with doing path MTU discovery and fragmentation at the Internet layer, that might not be the optimal encapsulation for tunnelling anymore.

Best regards,
Ole

> On 31 Oct 2017, at 02:23, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Erik Kline <[email-masked]>
Date: Tue, 31 Oct 2017 18:15:03 +0900

This would certainly complicate tracking ingress interface and
applying rules that require ingress interface information to apply
correctly.

Blech.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Oct 2017 15:02:39 -0400

Ole Troan <[email-masked]> wrote:
    > Without having thought very much about it... I do think requiring a
    > host to accept tunnelled packets to itself by default or not, requires
    > further considerations.

I agree: it requires further consideration.

    > I am aware of no implementation that would support this. I would also
    > be worried about this opening the door for "alternate" paths into the
    > host stack.

I agree. Nobody does it this way.
Yet 8200 (and 2460 before it) says that this is the way to insert headers.

One of 6463 or 2460/8200 must be wrong.

Essentially 8200 says to do something that doesn't work.
Should we be at all surprised that there is was much push to do it a different way?

If we don't fix 6434 to make it work, then our hard fought compromise in 8200
is moot.

ps: I'm not advocating for changing 8200.

---

From: Mark Smith <[email-masked]>
Date: Wed, 1 Nov 2017 12:29:22 +1100

On 1 Nov. 2017 06:03, "Michael Richardson" <[email-masked]> wrote:

I think we need to be clear about what is "inserting" is. To me, the word
"inserting" means inserting to into something that already exists and has
previously been created - cut apart, insert, glue back together.

IPinIP in the network is not doing insertion. It is adding by encapsulating
with a new IP header. That's the way we add information at all other layers
of the stack.

IPinIP in a host is, for some reason or other, not encoding all of the
information in the first IP header, so it adds another one to carry it.
IPsec tunnel mode would be an example.

IPsec transport mode isn't "inserting" either. The host sending the IPsec
transport mode packet builds the entire thing, and adds the AH/ESP header
at the appropriate time during the encapsulation process as the IPsec
packet is built before being put on the wire.

So truly "inserting" (cut, insert, glue) into an existing packet is not
something that has been part of any IETF protocol as far as I'm aware.

Regards,
Mark.

Essentially 8200 says to do something that doesn't work.
Should we be at all surprised that there is was much push to do it a
different way?

If we don't fix 6434 to make it work, then our hard fought compromise in
8200
is moot.