Subject: Re: I-D Action: draft-ietf-6man-ipv6only-flag-00.txt

From: 神明達哉 <[email-masked]>
Date: Fri, 1 Jun 2018 11:54:59 -0700

At Thu, 24 May 2018 09:46:17 -0700,
Bob Hinden <[email-masked]> wrote:

> The changes in the new version include:
>
>       *  Changed the file name to draft-ietf-6man-ipv6only-flag to match
>          the current tile and that it is a w.g. draft.
>       *  Added new section that defines what IPv6-Only includes.
>       *  Expanded description of using Layer 2 filter to block IPv4 and ARP traffic.
>       *  Editorial changes.
>
> Please review and comment.

I've read this version.  I'm still not so confident that the problem
is real enough to warrant a new protocol feature, but I won't oppose
to standardizing it just for this.

My another high level comment is that "IPv6-Only" could mean something
broader than "IPv4 is not available".  In a sense I like the new term
since this less sounds like protocol-boundary violation (although it
essentially still asserts conditions on non-IPv6 protocols).  Perhaps
that's reason for changing the name (I've not followed all of the
recent discussions on this draft, so it's quite likely that I missed
that part of the discussion)?  If so, that's fine for me, but we might
want to note that this flag effectively only talks about the
availability of IPv4, and any other protocols are out of scope the
discussion.

And one minor comment on this paragraph in Section 7:

   In all of the above, the flag's value is considered valid for the
   lifetime of the default router concerned, unless a subsequent RA
   delivers a different flag value.  If a default router expires (i.e.,
   no RA is received that refreshes its lifetime), the host must remove
   this router's flag value from consideration.  If the result is that
   all surviving default routers have the flag set to 1, the host SHOULD
   assume that the link is IPv6-Only.  In other words, at any given
   time, the state of the flag as seen by the host is the logical AND of
   the flags sent by all unexpired default IPv6 routers.

I wonder whether this may be a bit unclear about the case where the
state of the flag is once set to "IPv6-only" and then all default
routers expire.  I believe the intended result in this case is the
state of the flag should now be "not (necessarily) IPv6-only" (and I
think that's the right intent), and it may be obvious from the last
sentence, but I somehow felt the above entire paragraph is a bit
ambiguous on this point.

If it's only me, that's fine.  But if we want to polish the text to
address this point, we might:
- explain this specific case, or
- be more formal by introducing a host variable and defining its value
  (at any given time) as 'False || state-of-router1 || ... || state-of-routerN'

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Mon, 25 Jun 2018 11:57:40 -0700

Jinmei-san,

> On Jun 1, 2018, at 11:54 AM, 神明達哉 <[email-masked]> wrote:
> 

We have heard from a large enterprise who is working on moving to IPv6 only that they thought this was useful and I have some private followup.  It’s in the minutes from the last meeting.

> availability of IPv4, and any other protocols are out of scope the

This version of the draft does try to define what IPv6-Only means in Section 4.   Please suggest additional text.   The previous section “Applicability Statements” also sets the context.

> sentence, but I somehow felt the above entire paragraph is a bit

Fair comment.  I does not address this case clearly.

>  (at any given time) as 'False || state-of-router1 || ... || state-of-routerN’

It does attempt say that in words:

   In other words, at any given
   time, the state of the flag as seen by the host is the logical AND of
   the flags sent by all unexpired default IPv6 routers.

We could add something like:

   If there are no valid default routers advertising the flag, then the hosts should
   not assume this is an IPv6-Only link.

Your thoughts?

Thanks,
Bob

---

From: 神明達哉 <[email-masked]>
Date: Tue, 26 Jun 2018 11:30:01 -0700

At Mon, 25 Jun 2018 11:57:40 -0700,
Bob Hinden <[email-masked]> wrote:

> This version of the draft does try to define what IPv6-Only means in
> Section 4.   Please suggest additional text.   The previous section
> “Applicability Statements” also sets the context.

If you're willing to adopt text I may be able to offer something, but
I first really need to understand the intent.

Section 4 states

   IPv6-Only is defined to mean that only IPv6 is running on the link.

This suggests that it means that no other protocol than IPv6 is running,
whether it's IPv4 or AppleTalk or IPv16.

This section also says:

   This includes:
      *  No IPv4 traffic on the Link
      ... (all related to IPv4)

The word "includes" also seems to suggest the same thing, but the fact
that the actual list is only relevant to IPv4 makes me feel that it
might actually only intend to exclude IPv4.

Which one is the intent?

A. "IPv6-Only" means absolutely no other protocols than IPv6 are
   running, whether it's IPv4, AppleTalk, IPX, or any new IPvX (X != 6)
B. Although the term "IPv6-Only" sounds broad, it actually only means
   IPv4 is not running in the link; whether other protocols are
   running is out of scope of this spec.

>    the flags sent by all unexpired default IPv6 routers.

As noted in my comment, I'm aware of this sentence, and I tend to
agree that this may be enough from a purely logical point of view.  I
just thought it might be a bit more reader-friendly to reiterate "the
obvious" at the cost of sounding more verbose.

>    not assume this is an IPv6-Only link.

I'm afraid this wouldn't really address *my* concern.  If I were to
add something, that would be something like this:

    This also means that if all default routers have set the flag,
    thereby setting the flag for the host, and the lifetimes of all
    the routers subsequently expire, then the state of the flag for
    the host becomes cleared.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2018 08:53:41 +1200

Hi,

The scope is intended to be IP, i.e. IPv4 and IPv6. Of course
we can clarify that since it might not be obvious to a reader
in the far future.

    Brian
On 27/06/2018 06:30, 神明達哉 wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 27 Jun 2018 10:59:41 -0700

At Wed, 27 Jun 2018 08:53:41 +1200,

> we can clarify that since it might not be obvious to a reader

Okay.  Then, if I were the author I'd revise section 4, e.g., as
follows:

   IPv6-Only is defined to mean that no other versions of internet
   protocol than IPv6 are running on the link.  Today this effectively
   simply means that IPv4 is not running on the link, and it includes:

      ... same bullet list

   It is expected that on IPv6-Only networks it will be common for
   (no change).

   Note that IPv6-Only has no information about other network
   protocols than IP.  It is out of scope of this specification
   whether those protocols are running on the link.

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Wed, 27 Jun 2018 14:24:43 -0700

Jinmei,

> On Jun 27, 2018, at 10:59 AM, 神明達哉 <[email-masked]> wrote:
> 

Fine for me.  I will include this in the next version.

Bob

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 28 Jun 2018 08:31:40 +0200

Hi Bob,

One question here ...

When you say "no other version of Internet Protocol than IPv6 are running in the link" ... you mean only "natively" ?

I've the same issue when working in draft-palet-v6ops-ipv6-only.

What happens if IPv4 is being tunneled? I think we need a "magic" word (natively ? natively-forwarding ?) so there is not confusion on that.

Note that I understand clearly the intent of your text, but I'm also thinking in other readers (which is the reason I worked in draft-palet-v6ops-ipv6-only, so to make sure nobody misinterpret it).

Regards,

Jordi

-----Mensaje original-----

De: ipv6 <[email-masked]> en nombre de Bob Hinden <[email-masked]>

Fecha: miércoles, 27 de junio de 2018, 23:25

Para: 神明達哉 <[email-masked]>

CC: IPv6 List <[email-masked]>, Bob Hinden <[email-masked]>

Asunto: Re: I-D Action: draft-ietf-6man-ipv6only-flag-00.txt

    Jinmei,

    Bob

    [email-masked]

**********************************************
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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Fred Baker <[email-masked]>
Date: Thu, 28 Jun 2018 07:27:36 -0500

Jordi, I think the key word here is "natively". A tunneled protocol, which could be bisync for all I know, isn't running on the link. It's tunnel is using the link (and is probably unaware of the fact), but the other protocol is using the tunnel.

> On Jun 28, 2018, at 1:31 AM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> Hi Bob,
> 
> One question here ...
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 28 Jun 2018 14:44:48 +0200

Le 27/06/2018 à 23:24, Bob Hinden a écrit :
> [SECURITE : MISE EN QUARANTAINE DES PIECES JOINTES POTENTIELLEMENT DANGEREUSES]
> 
> Ce message contient des pieces jointes potentiellement dangereuses car susceptibles de contenir des virus. Pour lutter contre l'expansion de ce type d'attaque, les documents [null] ont ete retires du message original ci-dessous. Pour les documents Office, le CEA recommande l'usage exclusif des formats plus recents exempts de macros comme DOCX, XLSX, PPTX, merci de le signaler a votre expediteur.
> 
> Pour de plus amples informations ou pour connaitre les mecanismes de mise en quarantaine, vous pouvez vous rapprocher de votre service informatique ou consulter le site USCIpedia - rubrique PureMessage.
> 
> ----------------MESSAGE ORGINAL ci-dessous------------------
> 
> Jinmei,
> 

I agree with it.

'No other version of internet protocol than IPv6 are running on the 
link' is _on the link_.  If I had IPv4 tunnelled on IPv6 the link was 
that tunnel.

So it looks reasonable as proposed.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jun 2018 08:42:11 +1200

Yes, definitely we are only talking about the outermost IP header if
there's any encapsulation. This should be clarified in the draft.

Regards
   Brian