Issues with Dual Stack IPv6 on by Default
draft-ietf-v6ops-v6onbydefault-03

This document is dependant on: draft-ietf-v6ops-onlinkassumption which
is not ready yet and in fact a decision needs to be made whether not
to publish that draft and/or make major changes. We will wait with
this draft until we have a decision made on: draft-ietf-v6ops-onlinkassumption.

[Ballot discuss]
The status of the proposed solutions in this document is unclear.

There are at least two choices about what to do about this:

(1) Get the proposed solutions reviewed by the appropriate groups (Transport/TCPM, IPv6 WG, etc.) and reflect their feedback and action plans into this document.
(2) Remove the solutions discussions from this document and just describe the problem.

[Ballot comment]
destination as reachable if the lookup succeeds.  The Neighbor
  Discovery on-link assumption mentioned in Section 2.2 makes this
  method somewhat irrelevant, however, as an implementation of the
  assumption could simply be to insert an IPv6 default on-link route
  into the system's forwarding table when the default router list is
  empty.  The side-effect is that the rule would always determine that
  all IPv6 destinations are reachable.  Therefore, this rule will not
  necessarily prefer one destination over the other.

IMO, this is a misreading of the spec. Even if everything is considered
to be  on-link, a separate NCE will be created with NUD, etc. Thus,
individual entries may well say "unreachable"


  A similar problem could exist for virtual private network (VPN)
  software.  A VPN could protect all IPv4 packets but transmit all
  others onto the local subnet unprotected.  At least one widely used
  VPN behaves this way.  This is problematic on a dual stack host that

Should this be qualified?

I.e., s/one widely used VPN/one known VPN implementation/

[Ballot discuss]
This document really needs an "applicability" paragraph or two at the
beginning saying something like:

  This document discusses in detail some issues related to .... The
  IPv6 WG has addressed these (or is addressing?) them in the
  following way... The suggestions in this document are just possible
  approaches for discussion and are not recommended solutions; see the
  other relevant documents for the recommended approaches."

Or something like that. I don't have an issue with publishing the
contents of the document essentially as is, but I think it would be
good to include context about what the IETF is doing about these
problems. Readers should not be misled into thinking they should
implement the recommendations in the document.

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

Issues found in review:

- I'm a little confused about why 2.3.1.1 talks about aborting TCP
connections that are in SYN-RECEIVED state. The problem statement said
"no IPv6 router" - how did the SYN get to the host in the first place?
The discussion makes perfect sense to me if it's limited to SYN-SENT.

- Section 2.1 talks about "rules" out of the blue, with no reference
given explicitly. I THINK it's referring to the rules from Section 6
of [ADDRSEL], but that's not obvious to the semi-initiated.

- No reference is given for the assertion that "Many TCP
implementations behave this way" in 2.3.1.1, or for the "work in
progress" described at the end of 2.3.3.

So, you ask, is fixing these items enough?

I sympathize with the authors, but they are being forced to handwave
on firewalling and NATing because we don't have BCPs on how to
firewall, and this doesn't help them to be clear or complete.

That's not a problem the authors can fix in this document. But from
one end of the document to the other, this problem complicates life -
3.3 talks about firewalls that don't enforce the same policy for IPv4
and IPv6, but where do we set the expectation that firewalls should,
or don't have to, enforce the same policy?

We do have RFC 2979, but it's Informational, does not contain the
ASCII string "v6", and talks about what firewalls do, not how to
operate firewalled networks. Sigh.

But maybe this document will be good enough for an Informational RFC.
Sigh.

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

Issues found in review:

- I'm a little confused about why 2.3.1.1 talks about aborting TCP
connections that are in SYN-RECEIVED state. The problem statement said
"no IPv6 router" - how did the SYN get to the host in the first place?
The discussion makes perfect sense to me if it's limited to SYN-SENT.

- Section 2.1 talks about "rules" out of the blue, with no reference
given explicitly. I THINK it's referring to the rules from Section 6
of [ADDRSEL], but that's not obvious to the semi-initiated.

- No reference is given for the assertion that "Many TCP
implementations behave this way" in 2.3.1.1, or for the "work in
progress" described at the end of 2.3.3.

So, you ask, is fixing these items enough?

I sympathize with the authors, but they are being forced to handwave
on firewalling and NATing because we don't have BCPs on how to
firewall, and this doesn't help them to be clear or complete.

That's not a problem the authors can fix in this document. But from
one end of the document to the other, this problem complicates life -
3.3 talks about firewalls that don't enforce the same policy for IPv4
and IPv6, but where do we set the expectation that firewalls should,
or don't have to, enforce the same policy?

We do have RFC 2979, but it's Informational, does not contain the
ASCII string "v6", and talks about what firewalls do, not how to
operate firewalled networks. Sigh.

But maybe this document will be good enough for an Informational RFC.
Sigh.

[Ballot discuss]
2.3.1.1 is inconsistent in its view of Host Requirements.  In particular, though it cites 1122, it ignores 1123.  Section 2.3 of the latter says that applications "SHOULD be preparted to try multiple addresses from the [preference-ordered] list".  This ties in quite closely with the discussion in this draft, and contradicts the assumption that since most applications then only tried one address, that the concept of multi-homed hosts wasn't considered in those RFCs.