Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-03.txt

From: George Michaelson <[email-masked]>
Date: Mon, 13 Nov 2017 15:19:34 +0800

If there is a functional barrier to any PDU which is IPv4 directly
encoded, being forwarded: If there is a barrier to other non-IP
packets such as ARP being forwarded, then in that sense, the link
layer cannot and does not forward IPv4 and its an IPv6 only network.

If the administrative decision has been made not to proffer ARP
responses, DHCP, or any other mechanism to bootstrap IPv4 but no
barrier is placed on its use, then I can stand up an IPv4 endpoint,
and hand-configure it to talk to another on the layer 2 fabric and it
works. I don't consider this to be an IPv6 only network, because bad
actors can send functional IPv4 between themselves. If you forward
broadcast packet types its even easier.

If I tunnel IPv4 over IPv6 PDUs  then its still an IPv6 only network.
Encapsulation is not the same as raw forwarding.

-G

On Mon, Oct 30, 2017 at 11:44 PM, JORDI PALET MARTINEZ
<[email-masked]> wrote:
> Hi all,
>
> I just posted a new version for this document.
>
> https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/
>
> Comments welcome!
>
> Regards,
> Jordi
>
>
>
> -----Mensaje original-----
> De: <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: lunes, 30 de octubre de 2017, 16:42
> Para: Jordi Palet Martinez <[email-masked]>, Jordi Martinez <[email-masked]>
> Asunto: New Version Notification for draft-palet-v6ops-ipv6-only-03.txt
>
>
>     A new version of I-D, draft-palet-v6ops-ipv6-only-03.txt
>     has been successfully submitted by Jordi Palet Martinez and posted to the
>     IETF repository.
>
>     Name:               draft-palet-v6ops-ipv6-only
>     Revision:   03
>     Title:              IPv6-only Terminology Definition
>     Document date:      2017-10-30
>     Group:              Individual Submission
>     Pages:              5
>     URL:            https://www.ietf.org/internet-drafts/draft-palet-v6ops-ipv6-only-03.txt
>     Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/
>     Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-03
>     Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6ops-ipv6-only-03
>     Diff:           https://www.ietf.org/rfcdiff?url2=draft-palet-v6ops-ipv6-only-03
>
>     Abstract:
>        This document defines the terminology regarding the usage of
>        expressions such as "IPv6-only", in order to avoid confusions when
>        using them in IETF and other documents, in reference to what is the
>        actual functionalities being used (not the actual protocol support).
>
>
>
>
>     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.
>
>     The IETF Secretariat
>
>
>
>
>
> **********************************************
> 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.
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Nov 2017 15:41:15 +0800

Hi George,

I think we mostly agree … may be the way I’m saying it in the document is not the best … but this is my thinking on this.

If we have an IPv6-only access link, even if there is no any “filtering” that avoids IPv4 traffic, because the ISP side will not forward it, even if the user CE sends IPv4 traffic natively, will not “work”. If that traffic is encapsulated or translated via IPv6, then is still “from the perspective” of the network operator, an IPv6-only access link.

Regards,
Jordi

-----Mensaje original-----
De: George Michaelson <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 13 de noviembre de 2017, 15:19
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: "<[email-masked]>" <[email-masked]>
Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-03.txt

    

    -G

---

From: George Michaelson <[email-masked]>
Date: Wed, 15 Nov 2017 15:59:11 +0800

so you reply in the positive, about encap. I think yes, we agree.

But what I don't think you've captured, is that a 'network' has a mix
of L3 and L2 active and passive parts. if the L2 fabric is prepared to
forward broadcast frames with ARP, and/or DHCP, and if two stations
cooperate either using this, or hand-installed mapping of IP to MAC,
then the network cannot be called IPv6 only, even if the network
administrator says so: Its functionally passing IPv4 first class.

To me, an IPv6 only network is one which does *not* forward frames
which encode IPv4 protocol objects directly. Indirect (encapsulated)
IPv4 is different, and it can still be IPv6 only, if these flow.

Carrier networks, mobile networks, which can elect not to forward IPv4
PDUs inside the carrier system first class, can be IPv6 only.

A managed switch, which does some kind of frame content check and
drops V4 on entry on a port, can be IPv6 only,

A PPP link which refuses V4 PPP encoded packets can be IPv6 only.

An unmanged switch, or any broadcast medium which is willing to let
edge stations assert IPv4, even without the network managers
engagement, is not IPv6 only. And, calling it IPv6 only invites the
inverse of the rogue-RA problem: Anyone can stand up a DHCP server,
proffer default route and DNS services, and capture packets from your
clients without you.

-G

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Nov 2017 16:31:00 +0800

[Jordi] I see that case mainly for the definition of an IPv6-only LAN. In the case of a WAN, even if the customer CE is sending IPv4 ARP/DHCP (even if by mistake), the operator side, will ignore that, and from the perspective of the terminology definition I’m trying to do, that’s what matters to an operator for a given network (or network part): I’m using or speaking or responding to IPv4 packets even in L2? If not, from the “usage perspective” of the that network(part) is IPv6-only.

    

[Jordi] I see the point, I think what I need to fix here in the terminology, if that’s a problem or not for other hosts, in the case of a broadcast medium.
    
    -G