From nobody Wed Mar 4 19:23:55 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F15E3A0A57 for ; Wed, 4 Mar 2020 19:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON8mYmR1ptu8 for ; Wed, 4 Mar 2020 19:23:45 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8880A3A0A6B for ; Wed, 4 Mar 2020 19:23:45 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id f5so2042630pfk.9 for ; Wed, 04 Mar 2020 19:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sBeLTNX/OsYEbWWAooppREmYhNmKM69+2ry8L72frJg=; b=td83LzoXDro+OzLqnIgiO4kx1MZTFrQl1DeSrOqJmtu8iQsU7oVWw0DdgELLpqfyel /ACnlWNaNbkEGyZI/p26rsAWxUriwV9NO1OnLhW3FQpvzGE1k/QMbgLsZCeCSi3MSBv5 5myNr2WVctXO7KLiiunkhPv5mGVRoFxStti9VVAU0fQTd5+MO/guBmh+nZaPIbgWeLdW Ixmm1qIJesQp89Si30YBf0RNo++QWR2SjX+GPygqn68v+ju7qkECH8lJ9R3DXfF4CvNt 3+HvNIuRjXeDes43JbDM7yah3G8fmfTRHVngBpSNdKW3R5YFJ8TkLYFKdRpF9JF67LRI sNTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sBeLTNX/OsYEbWWAooppREmYhNmKM69+2ry8L72frJg=; b=gs2+2xGTsZOaBF5u8OMoftUAkVOxg/FyWKOi/bMR3xcO+gQNGL9neC5augzTCn+kI4 wMtRUBd7m1nEQUK0EA8AyP2gfHuzZUpuvgXhzM2U7WPcrfQrA1BuKFjLJgKlToRVLqSx 2wv3LHidFP4s3IGHluZCKrrlj1YcPpHtuUTEG6Ngu2/wq6Jxn3PpEd1uDH92U1PkuXbT CeGeRFG4sZl81lq8dfgLrFeVKT1yYYM8QGfHu59zxQ7dCNr/AGYNvBgDHBpwfg4v7ntc 4EX48HgiW11jyasKjq+LOcQqaVXpZ9z7w3ww1QGwPGzDHx2+3WrDIYtZH24N8w7QD/iC yWUA== X-Gm-Message-State: ANhLgQ03bQQvvwiE9w61X7rwyluHqYSLYkRzRrXO4LWWJHF4bi56L9d5 +vTa15k4eq5t2CCR4ebl2/qQBRCU X-Google-Smtp-Source: ADFU+vtIBBRzXiV01jDoc5i4JRgGUZBbOG25LByHws31JzrfibUWaFADxoELhTewM7DZjnCN3dGszA== X-Received: by 2002:a62:1cb:: with SMTP id 194mr6305116pfb.31.1583378624653; Wed, 04 Mar 2020 19:23:44 -0800 (PST) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id y23sm10494648pfb.76.2020.03.04.19.23.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2020 19:23:43 -0800 (PST) To: IPv6 Operations References: <158221426253.12488.10534535019260467764@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3a34e55b-4d53-7cd2-783f-d11ce7ff2a86@gmail.com> Date: Thu, 5 Mar 2020 16:23:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <158221426253.12488.10534535019260467764@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-slaac-renum-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 03:23:53 -0000 I'm all for advancing this draft ASAP (and its 6man companion). Regards Brian Carpenter On 21-Feb-20 04:57, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events > Authors : Fernando Gont > Jan Zorz > Richard Patterson > Filename : draft-gont-v6ops-slaac-renum-02.txt > Pages : 12 > Date : 2020-02-20 > > Abstract: > In scenarios where network configuration information related to IPv6 > prefixes becomes invalid without any explicit signaling of that > condition (such as when a CPE crashes and reboots without knowledge > of the previously-employed prefixes), nodes on the local network will > continue using stale prefixes for an unacceptably long period of > time, thus resulting in connectivity problems. This document > documents this problem, and discusses operational workarounds that > may help to improve network robustness. Additionally, it highlights > areas where further work may be needed. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-gont-v6ops-slaac-renum/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum-02 > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-slaac-renum-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-slaac-renum-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Wed Mar 4 19:30:53 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7573A0A63 for ; Wed, 4 Mar 2020 19:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7veGjpIiGMvM for ; Wed, 4 Mar 2020 19:30:48 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88953A0A5C for ; Wed, 4 Mar 2020 19:30:48 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id h3so4891260ioj.6 for ; Wed, 04 Mar 2020 19:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f1pb0XnVzAO6YItibyKrK8PsLwI5OaJAp4R9OYJVN/Q=; b=qk12HVaqFWCG0tSSRvblCnKJ8o6umgzm+u5XuMHYT+0+bjPJjjAhd2sr2htJJeR2GD 1H3cgsYikuLVoqnjKlrvbwBjpMoZTOz1i+Wrxmjp1K9jsrlcA/3hICWrh/eYrzXl2hZb EABwi7W+hDWLkGgdIsgwyWExx2a/8+Xvg+hvFdpJtkP8jyNfIv9I5b9Mk+fpoaNaAz1W 2MwqzpbYg1EkhxIOYTmjICaEsPqVp/FfHT4sIheNpl6IHigqXFF5t9fMWpZ3W2KabDuB A10MZg1JxRNfbEvNFkymQfeliShs1DD4P6GOslRfSCnKpJ0uT8H4+Qvs+rgszA1RmnwV tphg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f1pb0XnVzAO6YItibyKrK8PsLwI5OaJAp4R9OYJVN/Q=; b=AvDZiR5Qj/KpklE6lkQT4OEJUrxW6yxqvK4n2SdAhwzKXnqCcHGeXmnnqS4hnitnG9 OXSORSOxCoEyBsNNJRur0ut0IB5Ds8tFaK/JWAroNTillqNCGgD8E58OAyg/LiBAORqS SPsn36w3cieGV27jDw4y+x0V3uGH73SneGFpEyb2cpS1UT/gW4Prpu4+HOr4V08VB/68 54yf4NhaV6fHR6Rj228xY0lt3YXv0LPYlXyLTLvuWvxqXodBCNsyY3lw9zI7MX8+BaC2 u/IBjqV2mr0wqm6PO7lRqHqwipFWqQdJQflcj0fwSWsIkLPsz7q3skNPnsNREuPSRggL eA2Q== X-Gm-Message-State: ANhLgQ1FJyrwqR75zvYzfXlEfwymL9Qd+1ENVhXKgXKVQbzvHovlhwYs hqM/4PJjQbH74fEPO/1vPhLU0Kn4z0084h9QIFmvGPxf X-Google-Smtp-Source: ADFU+vsrht8/siyb4NrPZ8xnpIcGuPhCGSJa4rkYKVG1PDC1K2GCScaYrOaWqFuwLXpBLF7ea7jeWwcbfDJx5B/U+H0= X-Received: by 2002:a5d:9442:: with SMTP id x2mr4385602ior.276.1583379047907; Wed, 04 Mar 2020 19:30:47 -0800 (PST) MIME-Version: 1.0 References: <158221426253.12488.10534535019260467764@ietfa.amsl.com> <3a34e55b-4d53-7cd2-783f-d11ce7ff2a86@gmail.com> In-Reply-To: <3a34e55b-4d53-7cd2-783f-d11ce7ff2a86@gmail.com> From: Gyan Mishra Date: Wed, 4 Mar 2020 22:30:12 -0500 Message-ID: To: Brian E Carpenter Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000b206d205a0132968" Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-slaac-renum-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 03:30:51 -0000 --000000000000b206d205a0132968 Content-Type: text/plain; charset="UTF-8" I support advancing. Kind regards Gyan On Wed, Mar 4, 2020 at 10:24 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I'm all for advancing this draft ASAP (and its 6man companion). > > Regards > Brian Carpenter > > On 21-Feb-20 04:57, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Reaction of Stateless Address > Autoconfiguration (SLAAC) to Flash- Renumbering Events > > Authors : Fernando Gont > > Jan Zorz > > Richard Patterson > > Filename : draft-gont-v6ops-slaac-renum-02.txt > > Pages : 12 > > Date : 2020-02-20 > > > > Abstract: > > In scenarios where network configuration information related to IPv6 > > prefixes becomes invalid without any explicit signaling of that > > condition (such as when a CPE crashes and reboots without knowledge > > of the previously-employed prefixes), nodes on the local network will > > continue using stale prefixes for an unacceptably long period of > > time, thus resulting in connectivity problems. This document > > documents this problem, and discusses operational workarounds that > > may help to improve network robustness. Additionally, it highlights > > areas where further work may be needed. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-gont-v6ops-slaac-renum/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum-02 > > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-slaac-renum-02 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-slaac-renum-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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --000000000000b206d205a0132968 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support advancing.

Kind regards
=

Gyan

On Wed, Mar 4, 2020 at 10:24 PM Brian E Carpe= nter <brian.e.carpenter@g= mail.com> wrote:
I'm all for advancing this draft ASAP (and its 6man companion).=

Regards
=C2=A0 =C2=A0Brian Carpenter

On 21-Feb-20 04:57, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Reaction of Stateless Address Autoconfiguration (SLAAC) to Flas= h- Renumbering Events
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Fernando Gont
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Jan Zorz
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Richard Patterson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= gont-v6ops-slaac-renum-02.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 12
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2020-02-20
>
> Abstract:
>=C2=A0 =C2=A0 In scenarios where network configuration information rela= ted to IPv6
>=C2=A0 =C2=A0 prefixes becomes invalid without any explicit signaling o= f that
>=C2=A0 =C2=A0 condition (such as when a CPE crashes and reboots without= knowledge
>=C2=A0 =C2=A0 of the previously-employed prefixes), nodes on the local = network will
>=C2=A0 =C2=A0 continue using stale prefixes for an unacceptably long pe= riod of
>=C2=A0 =C2=A0 time, thus resulting in connectivity problems.=C2=A0 This= document
>=C2=A0 =C2=A0 documents this problem, and discusses operational workaro= unds that
>=C2=A0 =C2=A0 may help to improve network robustness.=C2=A0 Additionall= y, it highlights
>=C2=A0 =C2=A0 areas where further work may be needed.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/= draft-gont-v6ops-slaac-renum/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-go= nt-v6ops-slaac-renum-02
> https://datatracker.ietf.o= rg/doc/html/draft-gont-v6ops-slaac-renum-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff= ?url2=3Ddraft-gont-v6ops-slaac-renum-02
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--

Gyan=C2=A0 Mi= shra

Network Engineering & Technology=C2=A0

Verizon=C2=A0

Silver Spring, MD 20904=

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com



--000000000000b206d205a0132968-- From nobody Thu Mar 5 00:56:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23DE3A107C for ; Thu, 5 Mar 2020 00:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhGxDIM0nZUC for ; Thu, 5 Mar 2020 00:56:36 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE8B3A107B for ; Thu, 5 Mar 2020 00:56:34 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id 0258uQrl089327 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2020 08:56:28 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Brian E Carpenter Cc: IPv6 Operations References: <158221426253.12488.10534535019260467764@ietfa.amsl.com> <3a34e55b-4d53-7cd2-783f-d11ce7ff2a86@gmail.com> From: Nick Hilliard Message-ID: Date: Thu, 5 Mar 2020 08:56:25 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.12 MIME-Version: 1.0 In-Reply-To: <3a34e55b-4d53-7cd2-783f-d11ce7ff2a86@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-slaac-renum-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 08:56:38 -0000 WG adoption would be good. The draft looks useful. Nick Brian E Carpenter wrote on 05/03/2020 03:23: > I'm all for advancing this draft ASAP (and its 6man companion). > > Regards > Brian Carpenter > > On 21-Feb-20 04:57, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events >> Authors : Fernando Gont >> Jan Zorz >> Richard Patterson >> Filename : draft-gont-v6ops-slaac-renum-02.txt >> Pages : 12 >> Date : 2020-02-20 >> >> Abstract: >> In scenarios where network configuration information related to IPv6 >> prefixes becomes invalid without any explicit signaling of that >> condition (such as when a CPE crashes and reboots without knowledge >> of the previously-employed prefixes), nodes on the local network will >> continue using stale prefixes for an unacceptably long period of >> time, thus resulting in connectivity problems. This document >> documents this problem, and discusses operational workarounds that >> may help to improve network robustness. Additionally, it highlights >> areas where further work may be needed. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-gont-v6ops-slaac-renum/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum-02 >> https://datatracker.ietf.org/doc/html/draft-gont-v6ops-slaac-renum-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-slaac-renum-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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Mar 5 04:13:11 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4853A135D for ; Thu, 5 Mar 2020 04:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vKpnTICVj2E for ; Thu, 5 Mar 2020 04:13:08 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7886B3A1360 for ; Thu, 5 Mar 2020 04:13:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 025CD6xk015360 for ; Thu, 5 Mar 2020 13:13:06 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 88B2020395A for ; Thu, 5 Mar 2020 13:13:06 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7E265203C4C for ; Thu, 5 Mar 2020 13:13:06 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 025CD6lK029911 for ; Thu, 5 Mar 2020 13:13:06 +0100 From: Alexandre Petrescu To: "v6ops@ietf.org" References: Message-ID: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> Date: Thu, 5 Mar 2020 13:13:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 12:13:10 -0000 I learned from an IPv6 old timer at an ITU meeting about this "Request for Comments on Updated Guidance for Completing the Transition to the Next Generation Internet Protocol, Internet Protocol Version 6 (IPv6)" https://www.federalregister.gov/documents/2020/03/02/2020-04202/request-for-comments-on-updated-guidance-for-completing-the-transition-to-the-next-generation It mainly concerns organisations in the United States of America, but they seek 'public' comment in 30 days, which amounts to about everyone, I think. One comment that I would like to make is to better explain what IPv6-only is. To distinguish from the IPv6-only claimed in some cases, at mobile operators, which is carried by IPv4 in fact. And to comment that I hope that Request for Comments' hope of transition to IPv6 is pure IPv6 not carried by IPv4. I could send that comment to the indicated email address "OFCIO@omb.eop.gov" but I suppose there might be some risk of that message getting lost. Alex From nobody Thu Mar 5 04:25:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D21C3A13B7 for ; Thu, 5 Mar 2020 04:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gcShMOjpcvK for ; Thu, 5 Mar 2020 04:25:44 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E153A13B5 for ; Thu, 5 Mar 2020 04:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1583411141; x=1584015941; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=zPynW04U b7RSdS2OlJ0wXD+AjKsI2QfIj28BR0xI4F0=; b=voG7A6h05HpPVoj0X5TTpvk5 optNTBWluCbEM7vWCHvMxpVc9L8ObMgGntP3M0OLuG4DUMaNvXOyBz6GmrptsDJP 7TGEqIU/6NaiHp7wTJTyn48WKclC7ZqM4c5VeiFbbcLNxRIZRTI2a7zoyidDEUUT CZDvoJWqZztuTk43nOs= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 05 Mar 2020 13:25:41 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 05 Mar 2020 13:25:41 +0100 Received: from [192.168.11.230] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000081152.msg for ; Thu, 05 Mar 2020 13:25:41 +0100 X-MDRemoteIP: 2001:4288:1301:610:b07a:fd37:3fe0:635a X-MDHelo: [192.168.11.230] X-MDArrival-Date: Thu, 05 Mar 2020 13:25:41 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1333cdedec=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.22.0.200209 Date: Thu, 05 Mar 2020 13:25:38 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> In-Reply-To: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 12:25:49 -0000 This is why I've insisted several times in having a document describing wha= t is IPv6-only ... I can update it again if the WG is interested ... https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-04 =20 =EF=BB=BFEl 5/3/20 13:13, "v6ops en nombre de Alexandre Petrescu" escribi=C3=B3: =20 I learned from an IPv6 old timer at an ITU meeting about this "Request for Comments on Updated Guidance for Completing the Transition to the Next Generation Internet Protocol, Internet Protocol Version 6 (IPv6)" =20 https://www.federalregister.gov/documents/2020/03/02/2020-04202/request= -for-comments-on-updated-guidance-for-completing-the-transition-to-the-next= -generation =20 It mainly concerns organisations in the United States of America, but they seek 'public' comment in 30 days, which amounts to about everyone, I think. =20 One comment that I would like to make is to better explain what IPv6-only is. To distinguish from the IPv6-only claimed in some cases, at mobile operators, which is carried by IPv4 in fact. And to comment that I hope that Request for Comments' hope of transition to IPv6 is pure IPv6 not carried by IPv4. =20 I could send that comment to the indicated email address "OFCIO@omb.eop.gov" but I suppose there might be some risk of that message getting lost. =20 Alex =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Mar 5 05:07:57 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C7C3A1452 for ; Thu, 5 Mar 2020 05:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYl7vwSR7ttv for ; Thu, 5 Mar 2020 05:07:53 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57ACC3A144E for ; Thu, 5 Mar 2020 05:07:53 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 025D7pTx047563 for ; Thu, 5 Mar 2020 14:07:51 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4BB03203C95 for ; Thu, 5 Mar 2020 14:07:51 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 420AE203C6E for ; Thu, 5 Mar 2020 14:07:51 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 025D7pPG001035 for ; Thu, 5 Mar 2020 14:07:51 +0100 To: v6ops@ietf.org References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Thu, 5 Mar 2020 14:07:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 13:07:56 -0000 Le 05/03/2020 à 13:25, JORDI PALET MARTINEZ a écrit : > This is why I've insisted several times in having a document describing what is IPv6-only ... > > I can update it again if the WG is interested ... > > https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-04 To me it might make sense to start from there. At this time, although I can click on the URL, it leads to a phrase "The attached draft memorandum prepared by the Office of Management and Budget, in collaboration with the Federal Chief Information Officers Council and Federal Chief Information Security Officers Council, supports the Administration’s goals for modernizing Federal Information Technology". I can not find that 'draft memorandum'. I can not find precisely what are the questions to comment on. Or there might be no precise question, just an overall indication of ambition. Alex > > > El 5/3/20 13:13, "v6ops en nombre de Alexandre Petrescu" escribió: > > > I learned from an IPv6 old timer at an ITU meeting about this "Request > for Comments on Updated Guidance for Completing the Transition to the > Next Generation Internet Protocol, Internet Protocol Version 6 (IPv6)" > > https://www.federalregister.gov/documents/2020/03/02/2020-04202/request-for-comments-on-updated-guidance-for-completing-the-transition-to-the-next-generation > > It mainly concerns organisations in the United States of America, but > they seek 'public' comment in 30 days, which amounts to about everyone, > I think. > > One comment that I would like to make is to better explain what > IPv6-only is. To distinguish from the IPv6-only claimed in some cases, > at mobile operators, which is carried by IPv4 in fact. And to comment > that I hope that Request for Comments' hope of transition to IPv6 is > pure IPv6 not carried by IPv4. > > I could send that comment to the indicated email address > "OFCIO@omb.eop.gov" but I suppose there might be some risk of that > message getting lost. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > 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 > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Mar 5 05:33:32 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56C23A14A1 for ; Thu, 5 Mar 2020 05:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=irs.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zosW3X-NL27X for ; Thu, 5 Mar 2020 05:33:29 -0800 (PST) Received: from EMG5.irs.gov (emg5.irs.gov [IPv6:2610:30:4000:25::92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446D03A14A7 for ; Thu, 5 Mar 2020 05:33:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,518,1574139600"; d="scan'208";a="278790428" Received: from unknown (HELO mem0200img1.tcc.irs.gov) ([10.207.120.253]) by mtb0120emg5.mcc.irs.gov with ESMTP; 05 Mar 2020 08:33:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irs.gov; l=2050; q=dns/txt; s=irs-20171230; t=1583415207; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20Morizot=20Timothy=20S=20|To:=20"v6ops@ietf.org"=20|Subject:=20 RE:=20[v6ops]=20About=20Req=20for=20Comments=20-=20"Trans ition=20to=20IPv6"|Date:=20Thu,=205=20Mar=202020=2013:33: 26=20+0000|Message-ID:=20<52b6b9a4f46a49598eccee1b35e5efc 5@irs.gov>|References:=20=0D=0A=20<7eb4dc25-28a6-4927-2356-846e200 681d2@gmail.com>=0D=0A=20<0791D4B0-8390-48D7-AF0A-CE004EC 3224C@consulintel.es>=0D=0A=20|In-Reply-To:=20|Content-Transfer-Encoding: =20base64|MIME-Version:=201.0; bh=BJLiy9IU0sSXYw+cweOGbDUUNqhEfXKGWhEbvBaaf+M=; b=evGTZuywgDXaENgTG96FdCOA4IDEm4KMesAkbvTMmLQpSJi956BF/VMJ qYRn2eP4rsrfCr4oBhuJKZpvWtr5jInffHVfxZhrT3HqNlu08/+E6QwSW K/RFkqp5xQe42lSKpVEjuYWNAdelnS1Q/PMGIpSLs6d8X0oOEnjJzmQup azIO6InX87j/dqCRs57KGmYgquTVnzGMbuQF8TdsUzEMIaJNpim4ai3t0 wT33PkaC+iRfKpoymZ1e7RelduV3KIZXUkXnvCrp0818DaP+x1iSlOM04 IGwgloyu1SSQtx3rO+ds1jUeWik3WHeerkLXbpM5TzUOJYi54GxcRK0qG w==; Received: from mtb0120ppexh040.ds.irsnet.gov ([10.207.136.82]) by mem0200img1.tcc.irs.gov with ESMTP/TLS/AES256-GCM-SHA384; 05 Mar 2020 13:33:27 +0000 Received: from MTB0120PPEXH050.ds.irsnet.gov (10.207.136.83) by MTB0120PPEXH040.ds.irsnet.gov (10.207.136.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 5 Mar 2020 08:33:26 -0500 Received: from MTB0120PPEXH050.ds.irsnet.gov ([fe80::9de0:134:e3b8:a42d]) by MTB0120PPEXH050.ds.irsnet.gov ([fe80::9de0:134:e3b8:a42d%15]) with mapi id 15.01.1913.005; Thu, 5 Mar 2020 08:33:26 -0500 From: Morizot Timothy S To: "v6ops@ietf.org" Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" Thread-Index: AQHV8ueeLLu0nvB3gUGLJcW18YOjU6g6QF0AgAALy4D//7FKwA== Date: Thu, 5 Mar 2020 13:33:26 +0000 Message-ID: <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.207.132.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 13:33:31 -0000 U2luY2UgdGhlIGZvcm1hbCByZXF1ZXN0IGZvciBjb21tZW50IGhhcyBiZWVuIHB1Ymxpc2hlZCBv biB0aGUgZmVkZXJhbCByZWdpc3RlciwgYSBkaXJlY3QgbGluayB0byB0aGUgZHJhZnQgYXMgcHVi bGlzaGVkIG9uIHRoZSBGZWRlcmFsIENJTyB3ZWJzaXRlICh3aXRoaW4gT01CKSBtaWdodCBmYWNp bGl0YXRlIHJldmlldyBhbmQgY29tbWVudC4gSSBzZWUgc29tZSBjb25mdXNpb24gYWJvdXQgaG93 IHRvIHJlYWQgdGhlIGRyYWZ0IG1lbW9yYW5kdW0gaXRzZWxmLg0KDQpodHRwczovL3d3dy5jaW8u Z292L2Fzc2V0cy9yZXNvdXJjZXMvaW50ZXJuZXQtcHJvdG9jb2wtdmVyc2lvbjYtZHJhZnQucGRm DQoNCkhUSCwNCg0KU2NvdHQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2 b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQWxleGFuZHJlIFBldHJl c2N1DQpTZW50OiBUaHVyc2RheSwgTWFyY2ggNSwgMjAyMCA3OjA4IEFNDQpUbzogdjZvcHNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEFib3V0IFJlcSBmb3IgQ29tbWVudHMgLSAiVHJh bnNpdGlvbiB0byBJUHY2Ig0KDQoNCg0KTGUgMDUvMDMvMjAyMCDDoCAxMzoyNSwgSk9SREkgUEFM RVQgTUFSVElORVogYSDDqWNyaXTCoDoNCj4gVGhpcyBpcyB3aHkgSSd2ZSBpbnNpc3RlZCBzZXZl cmFsIHRpbWVzIGluIGhhdmluZyBhIGRvY3VtZW50IGRlc2NyaWJpbmcgd2hhdCBpcyBJUHY2LW9u bHkgLi4uDQo+IA0KPiBJIGNhbiB1cGRhdGUgaXQgYWdhaW4gaWYgdGhlIFdHIGlzIGludGVyZXN0 ZWQgLi4uDQo+IA0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFsZXQtdjZv cHMtaXB2Ni1vbmx5LTA0DQoNClRvIG1lIGl0IG1pZ2h0IG1ha2Ugc2Vuc2UgdG8gc3RhcnQgZnJv bSB0aGVyZS4NCg0KQXQgdGhpcyB0aW1lLCBhbHRob3VnaCBJIGNhbiBjbGljayBvbiB0aGUgVVJM LCBpdCBsZWFkcyB0byBhIHBocmFzZSAiVGhlIA0KYXR0YWNoZWQgZHJhZnQgbWVtb3JhbmR1bSBw cmVwYXJlZCBieSB0aGUgT2ZmaWNlIG9mIE1hbmFnZW1lbnQgYW5kIA0KQnVkZ2V0LCBpbiBjb2xs YWJvcmF0aW9uIHdpdGggdGhlIEZlZGVyYWwgQ2hpZWYgSW5mb3JtYXRpb24gT2ZmaWNlcnMgDQpD b3VuY2lsIGFuZCBGZWRlcmFsIENoaWVmIEluZm9ybWF0aW9uIFNlY3VyaXR5IE9mZmljZXJzIENv dW5jaWwsIA0Kc3VwcG9ydHMgdGhlIEFkbWluaXN0cmF0aW9u4oCZcyBnb2FscyBmb3IgbW9kZXJu aXppbmcgRmVkZXJhbCBJbmZvcm1hdGlvbiANClRlY2hub2xvZ3kiLiAgSSBjYW4gbm90IGZpbmQg dGhhdCAnZHJhZnQgbWVtb3JhbmR1bScuDQoNCkkgY2FuIG5vdCBmaW5kIHByZWNpc2VseSB3aGF0 IGFyZSB0aGUgcXVlc3Rpb25zIHRvIGNvbW1lbnQgb24uICBPciB0aGVyZSANCm1pZ2h0IGJlIG5v IHByZWNpc2UgcXVlc3Rpb24sIGp1c3QgYW4gb3ZlcmFsbCBpbmRpY2F0aW9uIG9mIGFtYml0aW9u Lg0KDQpBbGV4DQoNCg== From nobody Thu Mar 5 06:02:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8493A1522 for ; Thu, 5 Mar 2020 06:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZntoeL4daf9Q for ; Thu, 5 Mar 2020 06:02:45 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D28E3A1521 for ; Thu, 5 Mar 2020 06:02:45 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 025E2hHw010461 for ; Thu, 5 Mar 2020 15:02:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6450A203D5E for ; Thu, 5 Mar 2020 15:02:43 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5087E203AB8 for ; Thu, 5 Mar 2020 15:02:43 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 025E2hPD005870 for ; Thu, 5 Mar 2020 15:02:43 +0100 To: v6ops@ietf.org References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> From: Alexandre Petrescu Message-ID: <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> Date: Thu, 5 Mar 2020 15:02:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 14:02:47 -0000 Thank you very much for the pointer. In it I could spot the following footnote: "[4] IPv6-Only refers to network environments in which use of the IPv4 protocol has been eliminated." In my humble opinion, I think, if I am not wrong, that there are no such networks in which IPv4 protocol has been eliminated. On one hand, a network is made of computers, and IPv4 stacks are still present in almost all computers. On another hand, there might be some ptp links (not networks, but individual links) that run IPv6 only. That is why it is hard to agree on the assumption of IPv4 being eliminated somewhere. Worse, it makes look as if the goal of that 'IPv6-only' is to arrive at that same situation which in fact does use IPv4. There is a draft at IETF in this v6ops WG, about the term 'IPv6-only'. We could improve that draft. We could refer to it as well. Further, in this Req for Comments 'Transition to IPv6' this text makes me think they set the wrong goal: > In fact, many of these organizations have migrated, or are planning > to migrate, to “IPv6-only”4 infrastructures to reduce operational > concerns associated with maintaining two distinct network > infrastructures. The intent of this updated memorandum is to > communicate the requirements for completing the operational > deployment of IPv6 across all Federal information systems and > services, and help agencies overcome barriers that prevent them from > migrating to IPv6-only systems. Going forward, the Federal > government plans to deliver its information services, operate its > networks, and access the services of others using only IPv6. The guidance would, better, make think about the removal of the IPv4 stack. For example, uncheck the IPv4 box in Windows ethernet interface properties, or remove 127.0.0.1 from /etc/hosts, remove A entries from DNS, or similar. These are criteria easily checked by more people. In my humble opinion. Alex Le 05/03/2020 à 14:33, Morizot Timothy S a écrit : > Since the formal request for comment has been published on the > federal register, a direct link to the draft as published on the > Federal CIO website (within OMB) might facilitate review and comment. > I see some confusion about how to read the draft memorandum itself. > > https://www.cio.gov/assets/resources/internet-protocol-version6-draft.pdf > > > > HTH, > > Scott > > -----Original Message----- From: v6ops On > Behalf Of Alexandre Petrescu Sent: Thursday, March 5, 2020 7:08 AM > To: v6ops@ietf.org Subject: Re: [v6ops] About Req for Comments - > "Transition to IPv6" > > > > Le 05/03/2020 à 13:25, JORDI PALET MARTINEZ a écrit : >> This is why I've insisted several times in having a document >> describing what is IPv6-only ... >> >> I can update it again if the WG is interested ... >> >> https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-04 > > To me it might make sense to start from there. > > At this time, although I can click on the URL, it leads to a phrase > "The attached draft memorandum prepared by the Office of Management > and Budget, in collaboration with the Federal Chief Information > Officers Council and Federal Chief Information Security Officers > Council, supports the Administration’s goals for modernizing Federal > Information Technology". I can not find that 'draft memorandum'. > > I can not find precisely what are the questions to comment on. Or > there might be no precise question, just an overall indication of > ambition. > > Alex > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Mar 5 08:38:22 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8293A17B4 for ; Thu, 5 Mar 2020 08:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51C3Hnmx5WM1 for ; Thu, 5 Mar 2020 08:38:18 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357893A17B2 for ; Thu, 5 Mar 2020 08:38:18 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id a22so6549172oid.13 for ; Thu, 05 Mar 2020 08:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qVMyHAr9r8AqkkQv4h8OMevLXTnvG2gNM91ahJzPKJI=; b=LLlGmMOY2Ct3gGtTfJHm7e1Llj38kFcG1jJGlnV02Dl6zEYRBam7clhHXu/VdoiCX5 ljXWp2SLAe/Y/DXi7zqcQiDz0p7IlBgHvv38CkQbMYCy6RlfwAowBQmEksKCMweh+M2n jt1AnXmaD9Mtq/GiJ77q2N2OjqUDTin6bdX/WDzisR+jDcfvT2iJFSLPUASudHBtjlDs dDM9O164U9m0ZjxUDKXwdW4sG6H8GMESGl7Ddxg1/liD0DIXUYVs8A6jR4J//2qCRs04 hA8XSOloH/aRm24uv5SisKUYzzOtzjnhjHr0SANikTES5ch3obAOACdwqhVoyIsj1RuZ lr5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qVMyHAr9r8AqkkQv4h8OMevLXTnvG2gNM91ahJzPKJI=; b=cW3TMe5sj6NI8WOc01lwhAQh3Ha2FPzYLmFvcSBrcFBYg3IBtD2j7aafXllbWCcQHJ DlOip1ckb3Mdw+V0VafwRkOR4PCvW4vrnAIEYjATZ4ENwN2LvXwaROGUYR0BDPS2Gv1k 8uxUHzB8y14u9fiO75YT6/Swjo2A0Czs/b7nYWqgE5FuAyEpNez+WsT0sfB3zi90CLdU /d33J/CjkAZEhaEDB/pqyQ51ICtxPBTGDhjg1LKpwo8C4RP9ZcsR0sj1vS0ppKjg+/mo HbXfCckQ8e/VjAgvOWhWc3+aFIXkpJ3h70mMCFfhFSCSpL+4/nxf5yfB1m9sePPKtdCg RuWA== X-Gm-Message-State: ANhLgQ008asD72JjgIav3izaBxiv16A0g9JUoRWdF9JUHIuEsKWNKTrl TpKhhe9qKOCU575fGYJkveBkg+94qakHFadgvjQ= X-Google-Smtp-Source: ADFU+vst25P8WLpEWgzzZ+ShL1gYlNipefKbe5s3drp9uKHrcKcEk656HWdyU6CnxoI9zDQUw/ng/AmnrZTKj2NVnos= X-Received: by 2002:aca:4f8e:: with SMTP id d136mr6353846oib.77.1583426297491; Thu, 05 Mar 2020 08:38:17 -0800 (PST) MIME-Version: 1.0 References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> In-Reply-To: <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> From: Erik Kline Date: Thu, 5 Mar 2020 08:38:06 -0800 Message-ID: To: Alexandre Petrescu Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000fd748d05a01e291c" Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 16:38:21 -0000 --000000000000fd748d05a01e291c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eliminating IPv4 implies eliminating the use of IPv4. Eliminating the *use* of IPv4 does not imply eliminating IPv4. I don't see any real problem here. Maybe they *want* the vagueness (i.e. absence of over-specificity) to have some grey area to support NAT64/DNS64 (or maybe even 464xlat). On Thu, Mar 5, 2020 at 6:03 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Thank you very much for the pointer. In it I could spot > the following footnote: "[4] IPv6-Only refers to network environments in > which use of the IPv4 protocol has been eliminated." > > In my humble opinion, > > I think, if I am not wrong, that there are no such networks in which > IPv4 protocol has been eliminated. On one hand, a network is made of > computers, and IPv4 stacks are still present in almost all computers. > On another hand, there might be some ptp links (not networks, but > individual links) that run IPv6 only. > > That is why it is hard to agree on the assumption of IPv4 being > eliminated somewhere. Worse, it makes look as if the goal of that > 'IPv6-only' is to arrive at that same situation which in fact does use > IPv4. > > There is a draft at IETF in this v6ops WG, about the term 'IPv6-only'. > We could improve that draft. We could refer to it as well. > > Further, in this Req for Comments 'Transition to IPv6' this text makes > me think they set the wrong goal: > > In fact, many of these organizations have migrated, or are planning > > to migrate, to =E2=80=9CIPv6-only=E2=80=9D4 infrastructures to reduce o= perational > > concerns associated with maintaining two distinct network > > infrastructures. The intent of this updated memorandum is to > > communicate the requirements for completing the operational > > deployment of IPv6 across all Federal information systems and > > services, and help agencies overcome barriers that prevent them from > > migrating to IPv6-only systems. Going forward, the Federal > > government plans to deliver its information services, operate its > > networks, and access the services of others using only IPv6. > > The guidance would, better, make think about the removal of the IPv4 > stack. For example, uncheck the IPv4 box in Windows ethernet interface > properties, or remove 127.0.0.1 from /etc/hosts, remove A entries from > DNS, or similar. These are criteria easily checked by more people. > > In my humble opinion. > > Alex > > > Le 05/03/2020 =C3=A0 14:33, Morizot Timothy S a =C3=A9crit : > > Since the formal request for comment has been published on the > > federal register, a direct link to the draft as published on the > > Federal CIO website (within OMB) might facilitate review and comment. > > I see some confusion about how to read the draft memorandum itself. > > > > > https://www.cio.gov/assets/resources/internet-protocol-version6-draft.pdf > > > > > > > > > HTH, > > > > Scott > > > > -----Original Message----- From: v6ops On > > Behalf Of Alexandre Petrescu Sent: Thursday, March 5, 2020 7:08 AM > > To: v6ops@ietf.org Subject: Re: [v6ops] About Req for Comments - > > "Transition to IPv6" > > > > > > > > Le 05/03/2020 =C3=A0 13:25, JORDI PALET MARTINEZ a =C3=A9crit : > >> This is why I've insisted several times in having a document > >> describing what is IPv6-only ... > >> > >> I can update it again if the WG is interested ... > >> > >> https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-04 > > > > To me it might make sense to start from there. > > > > At this time, although I can click on the URL, it leads to a phrase > > "The attached draft memorandum prepared by the Office of Management > > and Budget, in collaboration with the Federal Chief Information > > Officers Council and Federal Chief Information Security Officers > > Council, supports the Administration=E2=80=99s goals for modernizing Fe= deral > > Information Technology". I can not find that 'draft memorandum'. > > > > I can not find precisely what are the questions to comment on. Or > > there might be no precise question, just an overall indication of > > ambition. > > > > Alex > > > > _______________________________________________ v6ops mailing list > > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000fd748d05a01e291c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eliminating IPv4 implies eliminating the use of IPv4.
=
Eliminating the *use* of IPv4 does not imply eliminating IPv= 4.

I don't see any real problem here.=C2=A0 Ma= ybe they *want* the vagueness (i.e. absence of over-specificity) to have so= me grey area to support NAT64/DNS64 (or maybe even 464xlat).
On Thu, M= ar 5, 2020 at 6:03 AM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Thank you very much for the p= ointer.=C2=A0 In it I could spot
the following footnote: "[4] IPv6-Only refers to network environments = in
which use of the IPv4 protocol has been eliminated."

In my humble opinion,

I think, if I am not wrong, that there are no such networks in which
IPv4 protocol has been eliminated.=C2=A0 On one hand, a network is made of<= br> computers, and IPv4 stacks are still present in almost all computers.
On another hand, there might be some ptp links (not networks, but
individual links) that run IPv6 only.

That is why it is hard to agree on the assumption of IPv4 being
eliminated somewhere.=C2=A0 Worse, it makes look as if the goal of that 'IPv6-only' is to arrive at that same situation which in fact does = use IPv4.

There is a draft at IETF in this v6ops WG, about the term 'IPv6-only= 9;.
We could improve that draft.=C2=A0 We could refer to it as well.

Further, in this Req for Comments 'Transition to IPv6' this text ma= kes
me think they set the wrong goal:
> In fact, many of these organizations have migrated, or are planning > to migrate, to =E2=80=9CIPv6-only=E2=80=9D4 infrastructures to reduce = operational
> concerns associated with maintaining two distinct network
> infrastructures. The intent of this updated memorandum is to
> communicate the requirements for completing the operational
> deployment of IPv6 across all Federal information systems and
> services, and help agencies overcome barriers that prevent them from <= br> > migrating to IPv6-only systems. Going forward, the Federal
> government plans to deliver its information services, operate its
> networks, and access the services of others using only IPv6.

The guidance would, better, make think about the removal of the IPv4
stack.=C2=A0 For example, uncheck the IPv4 box in Windows ethernet interfac= e
properties, or remove 127.0.0.1 from /etc/hosts, remove A entries from
DNS, or similar.=C2=A0 These are criteria easily checked by more people.
In my humble opinion.

Alex


Le 05/03/2020 =C3=A0 14:33, Morizot Timothy S a =C3=A9crit :
> Since the formal request for comment has been published on the
> federal register, a direct link to the draft as published on the
> Federal CIO website (within OMB) might facilitate review and comment.<= br> > I see some confusion about how to read the draft memorandum itself. >
> https://www.cio.gov/as= sets/resources/internet-protocol-version6-draft.pdf
>
>
>
>
HTH,
>
> Scott
>
> -----Original Message----- From: v6ops <v6ops-bounces@ietf.org> On
> Behalf Of Alexandre Petrescu Sent: Thursday, March 5, 2020 7:08 AM > To: v6ops@ietf.org= Subject: Re: [v6ops] About Req for Comments -
> "Transition to IPv6"
>
>
>
> Le 05/03/2020 =C3=A0 13:25, JORDI PALET MARTINEZ a =C3=A9crit :
>> This is why I've insisted several times in having a document <= br> >> describing what is IPv6-only ...
>>
>> I can update it again if the WG is interested ...
>>
>> https://tools.ietf.org/html/draft= -palet-v6ops-ipv6-only-04
>
> To me it might make sense to start from there.
>
> At this time, although I can click on the URL, it leads to a phrase > "The attached draft memorandum prepared by the Office of Manageme= nt
> and Budget, in collaboration with the Federal Chief Information
> Officers Council and Federal Chief Information Security Officers
> Council, supports the Administration=E2=80=99s goals for modernizing F= ederal
>=C2=A0 Information Technology".=C2=A0 I can not find that 'dra= ft memorandum'.
>
> I can not find precisely what are the questions to comment on.=C2=A0 O= r
> there might be no precise question, just an overall indication of
> ambition.
>
> Alex
>
> _______________________________________________ v6ops mailing list > v6ops@ietf.org= https://www.ietf.org/mailman/listinfo/v6ops
>

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000fd748d05a01e291c-- From nobody Thu Mar 5 08:46:10 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C553A0064 for ; Thu, 5 Mar 2020 08:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0haOF8bNyJxY for ; Thu, 5 Mar 2020 08:46:06 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDDF3A0043 for ; Thu, 5 Mar 2020 08:46:06 -0800 (PST) Received: from [IPv6:2001:470:f325:501:a8:e3c9:6773:ee9a] ([IPv6:2001:470:f325:501:a8:e3c9:6773:ee9a]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 025Gk3Rn2843292 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Mar 2020 08:46:04 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> Date: Thu, 5 Mar 2020 08:46:03 -0800 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Thu, 05 Mar 2020 08:46:04 -0800 (PST) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 16:46:08 -0000 > On Mar 5, 2020, at 6:02 AM, Alexandre Petrescu = wrote: >=20 > Thank you very much for the pointer. In it I could spot > the following footnote: "[4] IPv6-Only refers to network environments = in > which use of the IPv4 protocol has been eliminated.=E2=80=9D No. IPv6-Only refers to network environments which are not using IPv4. That = could be a network where IPv4 has been eliminated (rare at this time, = though Facebook is a significant example) or it could be a greenfield = deployment where IPv4 was never deployed. >=20 > In my humble opinion, >=20 > I think, if I am not wrong, that there are no such networks in which > IPv4 protocol has been eliminated. On one hand, a network is made of > computers, and IPv4 stacks are still present in almost all computers. > On another hand, there might be some ptp links (not networks, but > individual links) that run IPv6 only. You are wrong=E2=80=A6 There are examples at various levels of IPv6-only = networks. Many mobile carriers are IPv6-only in the US, though they do = provide some apparent IPv4 capability to the end user through mechanisms = such as 464XLAT and/or NAT64. Another significant example is Facebook where they are essentially = IPv6-only throughout their network and provide minimal IPv4 translation = shim at the edge to cope with end users that lack IPv6 capability. > That is why it is hard to agree on the assumption of IPv4 being = eliminated somewhere. Worse, it makes look as if the goal of that = 'IPv6-only' is to arrive at that same situation which in fact does use = IPv4. As a general rule, once IPv6 is ubiquitously deployed in a network, the = preservation of IPv4 in the majority of that network becomes an = unnecessary cost factor and a security risk (increased attack surface, = if nothing else). As such, I think you will see an increasing number of = organizations follow on to the way Facebook has managed their transition = and start eliminating IPv4 wherever possible and replacing it with = translation shims as far out towards the border as practical. Owen From nobody Thu Mar 5 08:48:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D861E3A0403 for ; Thu, 5 Mar 2020 08:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY6WCOXeUESM for ; Thu, 5 Mar 2020 08:48:35 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA9B3A03F7 for ; Thu, 5 Mar 2020 08:48:28 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 025GmP76022481; Thu, 5 Mar 2020 17:48:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3F8C7207841; Thu, 5 Mar 2020 17:48:25 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3203A20782F; Thu, 5 Mar 2020 17:48:25 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 025GmPvQ017925; Thu, 5 Mar 2020 17:48:25 +0100 To: Erik Kline Cc: v6ops@ietf.org References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 5 Mar 2020 17:48:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 16:48:37 -0000 Le 05/03/2020 à 17:38, Erik Kline a écrit : > Eliminating IPv4 implies eliminating the use of IPv4. > > Eliminating the *use* of IPv4 does not imply eliminating IPv4. > > I don't see any real problem here. Maybe they *want* the vagueness > (i.e. absence of over-specificity) Indeed. It might be better to progress along the lines of that 'IPv6 only' even though that might mean some IPv4 too, than to not progress. I agree. > to have some grey area to support NAT64/DNS64 (or maybe even > 464xlat). I bet that if they wrote 'NAT64' themselves then they'd wonder about the presence of '4'. So, I guess we might ask them whether they understand that 'IPv6-only' requires NAT64 which requires 4 which is IPv4. Alex > > On Thu, Mar 5, 2020 at 6:03 AM Alexandre Petrescu > > > wrote: > > Thank you very much for the pointer. In it I could spot the > following footnote: "[4] IPv6-Only refers to network environments in > which use of the IPv4 protocol has been eliminated." > > In my humble opinion, > > I think, if I am not wrong, that there are no such networks in which > IPv4 protocol has been eliminated. On one hand, a network is made > of computers, and IPv4 stacks are still present in almost all > computers. On another hand, there might be some ptp links (not > networks, but individual links) that run IPv6 only. > > That is why it is hard to agree on the assumption of IPv4 being > eliminated somewhere. Worse, it makes look as if the goal of that > 'IPv6-only' is to arrive at that same situation which in fact does > use IPv4. > > There is a draft at IETF in this v6ops WG, about the term > 'IPv6-only'. We could improve that draft. We could refer to it as > well. > > Further, in this Req for Comments 'Transition to IPv6' this text > makes me think they set the wrong goal: >> In fact, many of these organizations have migrated, or are >> planning to migrate, to “IPv6-only”4 infrastructures to reduce >> operational concerns associated with maintaining two distinct >> network infrastructures. The intent of this updated memorandum is >> to communicate the requirements for completing the operational >> deployment of IPv6 across all Federal information systems and >> services, and help agencies overcome barriers that prevent them >> from migrating to IPv6-only systems. Going forward, the Federal >> government plans to deliver its information services, operate its >> networks, and access the services of others using only IPv6. > > The guidance would, better, make think about the removal of the IPv4 > stack. For example, uncheck the IPv4 box in Windows ethernet > interface properties, or remove 127.0.0.1 from /etc/hosts, remove A > entries from DNS, or similar. These are criteria easily checked by > more people. > > In my humble opinion. > > Alex > > > Le 05/03/2020 à 14:33, Morizot Timothy S a écrit : >> Since the formal request for comment has been published on the >> federal register, a direct link to the draft as published on the >> Federal CIO website (within OMB) might facilitate review and >> comment. I see some confusion about how to read the draft >> memorandum itself. >> >> > https://www.cio.gov/assets/resources/internet-protocol-version6-draft.pdf > > > >> >> >> > HTH, >> >> Scott >> >> -----Original Message----- From: v6ops > On >> Behalf Of Alexandre Petrescu Sent: Thursday, March 5, 2020 7:08 AM >> To: v6ops@ietf.org Subject: Re: [v6ops] > About Req for Comments - >> "Transition to IPv6" >> >> >> >> Le 05/03/2020 à 13:25, JORDI PALET MARTINEZ a écrit : >>> This is why I've insisted several times in having a document >>> describing what is IPv6-only ... >>> >>> I can update it again if the WG is interested ... >>> >>> https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-04 >> >> To me it might make sense to start from there. >> >> At this time, although I can click on the URL, it leads to a >> phrase "The attached draft memorandum prepared by the Office of >> Management and Budget, in collaboration with the Federal Chief >> Information Officers Council and Federal Chief Information Security >> Officers Council, supports the Administration’s goals for >> modernizing Federal Information Technology". I can not find that >> 'draft memorandum'. >> >> I can not find precisely what are the questions to comment on. Or >> there might be no precise question, just an overall indication of >> ambition. >> >> Alex >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Mar 5 08:51:34 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1B23A05AC for ; Thu, 5 Mar 2020 08:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.668 X-Spam-Level: X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9hUrD6feczK for ; Thu, 5 Mar 2020 08:51:31 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F243A046E for ; Thu, 5 Mar 2020 08:51:31 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 025GpNJ8023943; Thu, 5 Mar 2020 17:51:23 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A8278207819; Thu, 5 Mar 2020 17:51:23 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9F0C4203AAC; Thu, 5 Mar 2020 17:51:23 +0100 (CET) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 025GpNHl019455; Thu, 5 Mar 2020 17:51:23 +0100 To: Owen DeLong Cc: v6ops@ietf.org References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> From: Alexandre Petrescu Message-ID: Date: Thu, 5 Mar 2020 17:51:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 16:51:33 -0000 Le 05/03/2020 à 17:46, Owen DeLong a écrit : > > >> On Mar 5, 2020, at 6:02 AM, Alexandre Petrescu >> wrote: >> >> Thank you very much for the pointer. In it I could spot the >> following footnote: "[4] IPv6-Only refers to network environments >> in which use of the IPv4 protocol has been eliminated.” > > No. > > IPv6-Only refers to network environments which are not using IPv4. > That could be a network where IPv4 has been eliminated (rare at this > time, though Facebook is a significant example) Is facebook a network? I thought of it like a server farm. or it could be a > greenfield deployment where IPv4 was never deployed. > >> >> In my humble opinion, >> >> I think, if I am not wrong, that there are no such networks in >> which IPv4 protocol has been eliminated. On one hand, a network is >> made of computers, and IPv4 stacks are still present in almost all >> computers. On another hand, there might be some ptp links (not >> networks, but individual links) that run IPv6 only. > > You are wrong… There are examples at various levels of IPv6-only > networks. Many mobile carriers are IPv6-only in the US, The IPv6-only of mobile carriers in the US - is it carried in IPv4? The last packet dump I saw was IPv6 carried in IPv4. I stop here thank you. Alex From nobody Thu Mar 5 09:49:11 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1842D3A084C for ; Thu, 5 Mar 2020 09:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=irs.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7l9qQiquIRf for ; Thu, 5 Mar 2020 09:49:07 -0800 (PST) Received: from EMG4.irs.gov (emg4.irs.gov [IPv6:2610:30:2000:25::91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954073A0854 for ; Thu, 5 Mar 2020 09:49:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.70,518,1574143200"; d="scan'208";a="271418131" Received: from unknown (HELO mtb0120img1.mcc.irs.gov) ([10.219.201.80]) by mem0200emg4.tcc.irs.gov with ESMTP; 05 Mar 2020 11:49:00 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irs.gov; l=2662; q=dns/txt; s=irs-20171230; t=1583430540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20Morizot=20Timothy=20S=20|To:=20Alexandre=20Petrescu=20,=20Owen=20DeLong=0D=0A=09|CC:=20" v6ops@ietf.org"=20|Subject:=20RE:=20[v6op s]=20About=20Req=20for=20Comments=20-=20"Transition=20to =20IPv6"|Date:=20Thu,=205=20Mar=202020=2017:48:59=20+0000 |Message-ID:=20<789c762695404546bbfd50ea1a75935a@irs.gov> |References:=20=0D=0A=20<7eb4dc25-28a6-4927-2356-846e200681d2@gmai l.com>=0D=0A=20<0791D4B0-8390-48D7-AF0A-CE004EC3224C@cons ulintel.es>=0D=0A=20=0D=0A=20<52b6b9a4f46a49598eccee1b35e5efc5@irs .gov>=0D=0A=20<89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail .com>=0D=0A=20<43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delon g.com>=0D=0A=20|In-Reply-To:=20|Content-Transfer-Encoding:=20base64 |MIME-Version:=201.0; bh=MIHbBVvz93ckZESRhtTnaJfnnY7eu0PmLip631d96/0=; b=XYnz3ahI/cqXeUGWAw5eKGORkHBaIvEpYkjlaDawiiu/NI5rLnjQ4r11 PC9pFll/IOC9/mx4tRjZI2fBjblMgMSEXy6BgVDxFQSOjnRqbFzIIDvdY 7LgdTRYM1RlokkDcWlkKoO0Z4P/ODVro+fTcU2Xwc+HNzLkrF3hnFUNFl 4xfqzOEh6SCkK1qmGLXVhyaGMI3dQq9OmPJzdFB1cS10L7xEVj25hJxH9 mbEMAGMgAFHJHBLpEW4BKIIodB4RSd85Pekb5CGxMuM8oZ6312IdJpBMV T0LIXqS2ibyRz2tnAjkF0K45rwSfp3nG4p2P726w+KXX31wt/N4nTWuAh Q==; Received: from mtb0120ppexh010.ds.irsnet.gov ([10.207.136.79]) by mtb0120img1.mcc.irs.gov with ESMTP/TLS/AES256-GCM-SHA384; 05 Mar 2020 17:49:00 +0000 Received: from MTB0120PPEXH050.ds.irsnet.gov (10.207.136.83) by MTB0120PPEXH010.ds.irsnet.gov (10.207.136.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 5 Mar 2020 12:48:59 -0500 Received: from MTB0120PPEXH050.ds.irsnet.gov ([fe80::9de0:134:e3b8:a42d]) by MTB0120PPEXH050.ds.irsnet.gov ([fe80::9de0:134:e3b8:a42d%15]) with mapi id 15.01.1913.005; Thu, 5 Mar 2020 12:48:59 -0500 From: Morizot Timothy S To: Alexandre Petrescu , Owen DeLong CC: "v6ops@ietf.org" Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" Thread-Index: AQHV8ueeLLu0nvB3gUGLJcW18YOjU6g6QF0AgAALy4D//7FKwIAAXguAgAAtooCAAAF+gP//tAvg Date: Thu, 5 Mar 2020 17:48:59 +0000 Message-ID: <789c762695404546bbfd50ea1a75935a@irs.gov> References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.207.132.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 17:49:09 -0000 RmFjZWJvb2sgb3BlcmF0ZXMgYSBtYXNzaXZlIGdsb2JhbCBuZXR3b3JrLiBBbmQgeWVzLCB0aGV5 IGFyZSBJUHY2IG9ubHkgZXZlcnl3aGVyZSBleGNlcHQgdGhlaXIgZWRnZSBuZXR3b3JrIHdoZXJl IGluY29taW5nIGNvbm5lY3Rpb25zIGFyZSB0ZXJtaW5hdGVkLiBJIGRvbid0IGJlbGlldmUgdGhl IHdheSB0aGVpciBuZXR3b3JrIG9wZXJhdGVzIHRvZGF5IHdvdWxkIGZ1bmN0aW9uIG92ZXIgSVB2 NC4gTWljcm9zb2Z0IGlzIHdvcmtpbmcgdG93YXJkIHRoYXQgZ29hbCBmb3IgdGhlaXIgZW50ZXJw cmlzZSBuZXR3b3JrLiBJJ20gbm90IHN1cmUgd2hlcmUgdGhleSBhcmUgZm9yIHRoZWlyIGNvbnRl bnQgbmV0d29ya3MuIExpbmtlZEluIGlzIGVzdGFibGlzaGluZyBhbGwgbmV3IGRhdGEgY2VudGVy cyBhcyBJUHY2IG9ubHkuIENpc2NvIGhhcyBvbmUgb2YgdGhlaXIgY29ycG9yYXRlIHNpdGUgbmV0 d29ya3MgdG8gSVB2NiBvbmx5IGlmIEkgcmVjYWxsIGNvcnJlY3RseSBhbmQgYXJlIGNvbnRpbnVp bmcgdG8gd29yayB0b3dhcmQgdGhhdCBnb2FsLiBUaGUgbGlzdCBpcyBsYXJnZSBhbmQgZ3Jvd2lu Zy4NCg0KVGhlcmUgYXJlIGEgZmV3IHBvaW50cyBhYm91dCB0aGUgbGFuZ3VhZ2UgdGhhdCBtYXkg aGVscCB0aG9zZSB3aG8gYXJlIGxlc3MgZmFtaWxpYXIgd2l0aCB0aGUgd29ya2luZ3Mgb2YgZ292 ZXJubWVudCBib2RpZXMsIHRob3VnaCwgZXNwZWNpYWxseSBmb3IgcGVvcGxlIG91dHNpZGUgdGhl IFVTLiBGaXJzdCwgdGhpcyBpcyBhIHBvbGljeSBkb2N1bWVudCBub3QgZGV0YWlsZWQgdGVjaG5p Y2FsIGltcGxlbWVudGF0aW9uIGd1aWRhbmNlLiBJdCdzIG5vdCBnb2luZyB0byBkcmlsbCBkb3du IHRvIGRldmljZSBzcGVjaWZpYyBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gZGV0YWlscy4gSXQgZXN0 YWJsaXNoZXMgcmVwb3J0aW5nIHJlcXVpcmVtZW50cyBhbmQgY29tcGxpYW5jZSBtZXRyaWNzIHdo aWNoIG1lYW5zIHRoYXQgaXQgbXVzdCBiZSBwb3NzaWJsZSB0byBjb3VudCB3aGF0ZXZlciBpcyBi ZWluZyByZXBvcnRlZC4gIklQLWVuYWJsZWQgYXNzZXRzIiBzaG91bGQgYmUgaW50ZXJwcmV0ZWQg aW4gdGhlIHNhbWUgYnJvYWQgc2Vuc2UgdGhhdCBhcHBsaWVzIGluIHRoZSBmZWRlcmFsIGFjcXVp c2l0aW9uIGd1aWRlbGluZXMuIEJhc2ljYWxseSwgaXQgbWVhbnMgYW55IGFzc2V0IHRoYXQgY29u bmVjdHMgdG8gYSBuZXR3b3JrIHVzaW5nIElQLiBUaGF0IGNvdWxkIGJlIGFuIGVuZCB1c2VyIGNs aWVudCBzeXN0ZW0sIHNlcnZlciwgYW55IG5ldHdvcmsgZGV2aWNlLCBhcHBsaWFuY2VzLCBJT1Qg ZGV2aWNlcyAoc2Vuc29ycywgY2FtZXJhcywgbGlnaHRzLCBldGMuKSwgZXRjLiBJZiBpdCBjb25u ZWN0cyB0byBhIG5ldHdvcmsgYXQgbGF5ZXIgMywgaW5jbHVkaW5nIGFsbCB0aGUgZGV2aWNlcyBw cm92aWRpbmcgdGhhdCBuZXR3b3JrIHNlcnZpY2UsIGl0IHNob3VsZCBiZSBjb25zaWRlcmVkIGFu IElQLWVuYWJsZWQgYXNzZXQuIElmIHRoZXJlJ3MgYW4gSVAgY29uZmlndXJlZCBhbnl3aGVyZSBv biBpdCwgaXQncyBhbiBJUCBlbmFibGVkIGFzc2V0LiBBIGRldmljZSBwcm92aWRpbmcgTkFUNjQg d291bGQgc3RpbGwgaGF2ZSBJUHY0IGNvbmZpZ3VyZWQgb24gaXQuIEEgZGV2aWNlIGVuY2Fwc3Vs YXRpbmcgSVB2NiBpbiBJUHY0IHdvdWxkIHN0aWxsIGhhdmUgSVB2NCBjb25maWd1cmVkIG9uIGl0 LiBQZXJoYXBzIHRoYXQgaGVscHMgaW50ZXJwcmV0IHRoZSBzY29wZSBhbmQgaW50ZW50IG9mIHRo ZSBkcmFmdCBwb2xpY3k/IElQdjYtb25seSBpcyB1c2VkIGluIGNvbnRyYXN0IHRvIGR1YWwtc3Rh Y2tlZCBvciBvdGhlciB0cmFuc2l0aW9uIG1lY2hhbmlzbXMuIFRoZSBwb2xpY3kgZHJhZnQgbGFu Z3VhZ2UgcHJvdmlkZXMgbm8gZXhlbXB0aW9ucyBvciBleGNlcHRpb25zLg0KDQpIVEgsDQoNClNj b3R0DQo= From nobody Thu Mar 5 10:12:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD953A08FF for ; Thu, 5 Mar 2020 10:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0c6zoqgEcpW7 for ; Thu, 5 Mar 2020 10:12:46 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097503A08FC for ; Thu, 5 Mar 2020 10:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1583431963; x=1584036763; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=IcrQb2OE lZOBuCQQVZamEajEI050rCnIx2CLmw9Dxrg=; b=D5T1c4CwGHS6rLp+80WwS04z IiRb2R47vQNyvileVvsjNn6rClJkgvTZFVudUNYfouJ7kahiv7M5KnhOTbRjgQKx 6w7cILAXM639nUCeMZqtOky/wnX1gOo1Hz5p9MVgASrAMNtjs6aa66eMvrebSA7l q6hMw8mv3KWnJh634cQ= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 05 Mar 2020 19:12:43 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 05 Mar 2020 19:12:42 +0100 Received: from [10.192.2.52] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000081506.msg for ; Thu, 05 Mar 2020 19:12:42 +0100 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.192.2.52] X-MDArrival-Date: Thu, 05 Mar 2020 19:12:42 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1333cdedec=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.22.0.200209 Date: Thu, 05 Mar 2020 19:12:39 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> In-Reply-To: <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 18:12:48 -0000 If you read my draft, my opinion is different: Definition of IPv6-only Consequently, considering the context described in the section above, if we want to be precise and avoid confusing others, we can not use the terminology "IPv6-only" in a generic way, and we need to define what part of the network we are referring to. From that perspective, we define the "IPv6-only" status in a given part(s) of a network, depending on if there is actual native forwarding of IPv4, so IPv4 is not configured neither managed. So IPv4 may be not configured, or not used natively, but there is no way to= prevent that "is there" by means of tunneling of translation. *unless* you make sure that any encapsulation or translation is filtered, w= hich is close to impossible. Because we disagree, it seems clear that this document is needed. So if anyone has inputs, I will consider them in a new version during the w= eekend. Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 5/3/20 17:46, "v6ops en nombre de Owen DeLong" escribi=C3=B3: =20 =20 > On Mar 5, 2020, at 6:02 AM, Alexandre Petrescu wrote: >=20 > Thank you very much for the pointer. In it I could spot > the following footnote: "[4] IPv6-Only refers to network environments= in > which use of the IPv4 protocol has been eliminated.=E2=80=9D =20 No. =20 IPv6-Only refers to network environments which are not using IPv4. That= could be a network where IPv4 has been eliminated (rare at this time, thou= gh Facebook is a significant example) or it could be a greenfield deploymen= t where IPv4 was never deployed. =20 >=20 > In my humble opinion, >=20 > I think, if I am not wrong, that there are no such networks in which > IPv4 protocol has been eliminated. On one hand, a network is made of > computers, and IPv4 stacks are still present in almost all computers. > On another hand, there might be some ptp links (not networks, but > individual links) that run IPv6 only. =20 You are wrong=E2=80=A6 There are examples at various levels of IPv6-onl= y networks. Many mobile carriers are IPv6-only in the US, though they do pr= ovide some apparent IPv4 capability to the end user through mechanisms such= as 464XLAT and/or NAT64. =20 Another significant example is Facebook where they are essentially IPv6= -only throughout their network and provide minimal IPv4 translation shim at= the edge to cope with end users that lack IPv6 capability. =20 > That is why it is hard to agree on the assumption of IPv4 being elimi= nated somewhere. Worse, it makes look as if the goal of that 'IPv6-only' i= s to arrive at that same situation which in fact does use IPv4. =20 As a general rule, once IPv6 is ubiquitously deployed in a network, the= preservation of IPv4 in the majority of that network becomes an unnecessar= y cost factor and a security risk (increased attack surface, if nothing els= e). As such, I think you will see an increasing number of organizations fol= low on to the way Facebook has managed their transition and start eliminati= ng IPv4 wherever possible and replacing it with translation shims as far ou= t towards the border as practical. =20 Owen =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Mar 6 11:54:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871AE3A0906 for ; Fri, 6 Mar 2020 11:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Vipamvakj0S for ; Fri, 6 Mar 2020 11:54:04 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF723A0902 for ; Fri, 6 Mar 2020 11:54:04 -0800 (PST) Received: from [10.128.136.81] ([12.157.195.98]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 026Jrwav3407678 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Mar 2020 11:53:59 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Owen DeLong In-Reply-To: Date: Fri, 6 Mar 2020 11:53:58 -0800 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.104.8) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 06 Mar 2020 11:53:59 -0800 (PST) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 19:54:06 -0000 > On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 05/03/2020 =C3=A0 17:46, Owen DeLong a =C3=A9crit : >>> On Mar 5, 2020, at 6:02 AM, Alexandre Petrescu >>> wrote: >>> Thank you very much for the pointer. In it I could spot the >>> following footnote: "[4] IPv6-Only refers to network environments >>> in which use of the IPv4 protocol has been eliminated.=E2=80=9D >> No. >> IPv6-Only refers to network environments which are not using IPv4. >> That could be a network where IPv4 has been eliminated (rare at this >> time, though Facebook is a significant example)=20 >=20 > Is facebook a network? I thought of it like a server farm. How does one run a distributed server farm throughout the world without = connecting it with a network? Am I missing something? > or it could be a >> greenfield deployment where IPv4 was never deployed. >>> In my humble opinion, >>> I think, if I am not wrong, that there are no such networks in >>> which IPv4 protocol has been eliminated. On one hand, a network is >>> made of computers, and IPv4 stacks are still present in almost all >>> computers. On another hand, there might be some ptp links (not >>> networks, but individual links) that run IPv6 only. >> You are wrong=E2=80=A6 There are examples at various levels of = IPv6-only >> networks. Many mobile carriers are IPv6-only in the US, >=20 > The IPv6-only of mobile carriers in the US - is it carried in IPv4? = The last packet dump I saw was IPv6 carried in IPv4. At least on T-Mo, it appears to be native IPv6 from what I can see. = However, if it=E2=80=99s tunneled in v4 somewhere, that would likely be = entirely transparent and I=E2=80=99d have no way to tell. Owen From nobody Sun Mar 8 03:30:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0DF3A08F6 for ; Sun, 8 Mar 2020 03:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amOSpNvNlWiR for ; Sun, 8 Mar 2020 03:30:00 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3363A08F0 for ; Sun, 8 Mar 2020 03:29:58 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.218:54544.922809572 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-123.122.152.17?logid-D6F45B0AF6FA400AA5B6E3476D43D24A (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id DFA6528008B; Sun, 8 Mar 2020 18:29:49 +0800 (CST) X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn Received: from ([172.18.0.218]) by App0025 with ESMTP id D6F45B0AF6FA400AA5B6E3476D43D24A for jordi.palet=40consulintel.es@dmarc.ietf.org; Sun Mar 8 18:29:51 2020 X-Transaction-ID: D6F45B0AF6FA400AA5B6E3476D43D24A X-filter-score: filter<0> X-Real-From: xiechf@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Date: Sun, 8 Mar 2020 18:29:48 +0800 From: "xiechf@chinatelecom.cn" To: "JORDI PALET MARTINEZ" , v6ops References: , <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com>, <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es>, , <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov>, <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com>, <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.14.409[cn] Mime-Version: 1.0 Message-ID: <2020030818294834486735@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart151453433236_=----" Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 10:30:06 -0000 This is a multi-part message in MIME format. ------=_001_NextPart151453433236_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIEpvcmRpLCANCkZpcnN0ICwgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoZSBkZWZpbml0aW9u IG9mIElQdjYtb25seSBuZWVkcyB0byBjb25zaWRlciB0aGUgd2hhdCBwYXJ0IG9mIHRoZSBuZXR3 b3JrIHdlIGFyZSByZWZlcnJpbmcgdG8sIGZvciBleGFtcGxlLCBJU1AgbmV0d29yaywgSURDLCBD bG91ZCBwbGF0Zm9ybSBhbmQgU2VydmljZSBzeXN0ZW0gc2hvdWxkIGhhdmUgdGhlaXIgb3duIHNw ZWNpZmljIGRlZmluaXRpb24gb2YgSVB2Ni1vbmx5LiAgSSBob3BlIHRoaXMgZHJhZnQgY2FuIGdv IG9uLg0KU2Vjb25kbHkuIGZvciBJU1AgbmV0d29yaywgdGhlIGRlZmluaXRpb24gb2YgSVB2NiBz aG91bGQgYmUgYmFzZWQgb24gd2hldGhlciBpdCBjYW4gYWxsb2NhdGVzIG9ubHkgSVB2NiBhZGRy ZXNzZXMgdG8gbW9zdCBvZiBpdHMgY3VzdG9tZXJzIGZvciBzZXJ2aWNlIHByb3Zpc2lvbmluZywg aWYgeWVzLCBpdCBjYW4gYmUgY29uc2lkZXIgYXMgSVB2Ni1vbmx5LiBJZiBpdCBhbGxvY2F0ZXMg SVB2NCBhZGRyZXNzIHRvIG1vc3Qgb2YgaXRzIGN1c3RvbWVycywgdGhlbiBpdCBpcyBub3QgSVB2 Ni1vbmx5LiBNeSBwZXJzb25hbCBvcGlvbmlvbiBpcyB0aGF0IHRoZSBkZWZpbml0aW9uIHNob3Vs ZCBub3QgYmUgYmFzZWQgb24gd2hldGhlciB0byBlbGltaW5hdGUgSVB2NCBwcm90b2NvbCBpbiB0 aGUgbmV0d29yay4gIEF0IHByZXNlbnQgc3RhZ2UsIGl0IGlzIHVucmVhbGlzdGljIHRvIGVsaW1p bmF0ZSBJUHY0IHByb3RvY29sIGluIG1vc3QgbmV0d29ya3MsIGZvciB0aGUgbmV0d29ya3Mgc3Rp bGwgbmVlZCB0byBwcm92aWRlIGFjY2VzcyBzZXJ2aWNlIHRvIHNvbWUgY3VzdG9tZXJzIHdobyBk byBub3Qgc3VwcG9ydCBJUHY2LW9ubHkgZHVlIHRvIHRoZWlyIHBvb3ItY2FwYWJpbGl0eSBDUEUg b3IgdGVybWluYWxzLiBNb3JlZXZlciwgc29tZSBuZXR3b3JrcyBzdGlsbCBuZWVkIHRvIHVzZSBJ UHY0IGZvciBuZXR3b3JrIG1hbmFnZW1lbnQgLiBJZiB0aGUgZGVmaW5pdGlvbiBpdCB0b28gc3Ry aWN0LCBJIGd1ZXNzIG5vbmUgb2YgdGhlIG5ldHdvcmsgY2FuIG1lZXQgdGhlIHN0YW5kYXJkLCBp bmNsdWRpbmcgdGhvc2Ugd2hvIGhhdmUgZGVwbHllZCA0NjRYTEFULiBJbiBhZGRpdGlvbiwgYW4g SVB2Ni1vbmx5IG5ldHdvcmsgc2hvdWxkIGJlIG9wZW4gYW5kIGludGVyY29ubmVjdGVkIHdpdGgg T1RUcyBhbmQgb3RoZXIgSVNQcywgc29tZSBjbG9zZWQgc3lzdGVtLCBzdWNoIGFzIFZvTFRFIGlu IG1vYmlsZSBuZXR3b3JrLCBzaG91bGQgbm90IGJlIGNvbnNpZGVyIGFzIElQdjYtb25seSwgZXZl biB0aG91Z2ggaXQgb25seSBhbGxvY2F0ZXMgSVB2NiBhZGRyZXNzZXMgdG8gaXQgY3VzdG9tZXIu DQoNCkJlc3QgcmVnYXJkcw0KQ2hvbmdmZW5nIA0KDQpGcm9tOiBKT1JESSBQQUxFVCBNQVJUSU5F Wg0KRGF0ZTogMjAyMC0wMy0wNiAwMjoxMg0KVG86IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW3Y2b3BzXSBBYm91dCBSZXEgZm9yIENvbW1lbnRzIC0gIlRyYW5zaXRpb24gdG8gSVB2NiIN CklmIHlvdSByZWFkIG15IGRyYWZ0LCBteSBvcGluaW9uIGlzIGRpZmZlcmVudDoNCiANCiAgRGVm aW5pdGlvbiBvZiBJUHY2LW9ubHkNCiANCiAgIENvbnNlcXVlbnRseSwgY29uc2lkZXJpbmcgdGhl IGNvbnRleHQgZGVzY3JpYmVkIGluIHRoZSBzZWN0aW9uIGFib3ZlLA0KICAgaWYgd2Ugd2FudCB0 byBiZSBwcmVjaXNlIGFuZCBhdm9pZCBjb25mdXNpbmcgb3RoZXJzLCB3ZSBjYW4gbm90IHVzZQ0K ICAgdGhlIHRlcm1pbm9sb2d5ICJJUHY2LW9ubHkiIGluIGEgZ2VuZXJpYyB3YXksIGFuZCB3ZSBu ZWVkIHRvIGRlZmluZQ0KICAgd2hhdCBwYXJ0IG9mIHRoZSBuZXR3b3JrIHdlIGFyZSByZWZlcnJp bmcgdG8uDQogDQogICBGcm9tIHRoYXQgcGVyc3BlY3RpdmUsIHdlIGRlZmluZSB0aGUgIklQdjYt b25seSIgc3RhdHVzIGluIGEgZ2l2ZW4NCiAgIHBhcnQocykgb2YgYSBuZXR3b3JrLCBkZXBlbmRp bmcgb24gaWYgdGhlcmUgaXMgYWN0dWFsIG5hdGl2ZQ0KICAgZm9yd2FyZGluZyBvZiBJUHY0LCBz byBJUHY0IGlzIG5vdCBjb25maWd1cmVkIG5laXRoZXIgbWFuYWdlZC4NCiANClNvIElQdjQgbWF5 IGJlIG5vdCBjb25maWd1cmVkLCBvciBub3QgdXNlZCBuYXRpdmVseSwgYnV0IHRoZXJlIGlzIG5v IHdheSB0byBwcmV2ZW50IHRoYXQgImlzIHRoZXJlIiBieSBtZWFucyBvZiB0dW5uZWxpbmcgb2Yg dHJhbnNsYXRpb24uDQogDQoqdW5sZXNzKiB5b3UgbWFrZSBzdXJlIHRoYXQgYW55IGVuY2Fwc3Vs YXRpb24gb3IgdHJhbnNsYXRpb24gaXMgZmlsdGVyZWQsIHdoaWNoIGlzIGNsb3NlIHRvIGltcG9z c2libGUuDQogDQpCZWNhdXNlIHdlIGRpc2FncmVlLCBpdCBzZWVtcyBjbGVhciB0aGF0IHRoaXMg ZG9jdW1lbnQgaXMgbmVlZGVkLg0KIA0KU28gaWYgYW55b25lIGhhcyBpbnB1dHMsIEkgd2lsbCBj b25zaWRlciB0aGVtIGluIGEgbmV3IHZlcnNpb24gZHVyaW5nIHRoZSB3ZWVrZW5kLg0KIA0KUmVn YXJkcywNCkpvcmRpDQpAam9yZGlwYWxldA0KIA0K77u/RWwgNS8zLzIwIDE3OjQ2LCAidjZvcHMg ZW4gbm9tYnJlIGRlIE93ZW4gRGVMb25nIiA8djZvcHMtYm91bmNlc0BpZXRmLm9yZyBlbiBub21i cmUgZGUgb3dlbkBkZWxvbmcuY29tPiBlc2NyaWJpw7M6DQogDQogICAgDQogICAgDQogICAgPiBP biBNYXIgNSwgMjAyMCwgYXQgNjowMiBBTSwgQWxleGFuZHJlIFBldHJlc2N1IDxhbGV4YW5kcmUu cGV0cmVzY3VAZ21haWwuY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gVGhhbmsgeW91IHZlcnkg bXVjaCBmb3IgdGhlIHBvaW50ZXIuICBJbiBpdCBJIGNvdWxkIHNwb3QNCiAgICA+IHRoZSBmb2xs b3dpbmcgZm9vdG5vdGU6ICJbNF0gSVB2Ni1Pbmx5IHJlZmVycyB0byBuZXR3b3JrIGVudmlyb25t ZW50cyBpbg0KICAgID4gd2hpY2ggdXNlIG9mIHRoZSBJUHY0IHByb3RvY29sIGhhcyBiZWVuIGVs aW1pbmF0ZWQu4oCdDQogICAgDQogICAgTm8uDQogICAgDQogICAgSVB2Ni1Pbmx5IHJlZmVycyB0 byBuZXR3b3JrIGVudmlyb25tZW50cyB3aGljaCBhcmUgbm90IHVzaW5nIElQdjQuIFRoYXQgY291 bGQgYmUgYSBuZXR3b3JrIHdoZXJlIElQdjQgaGFzIGJlZW4gZWxpbWluYXRlZCAocmFyZSBhdCB0 aGlzIHRpbWUsIHRob3VnaCBGYWNlYm9vayBpcyBhIHNpZ25pZmljYW50IGV4YW1wbGUpIG9yIGl0 IGNvdWxkIGJlIGEgZ3JlZW5maWVsZCBkZXBsb3ltZW50IHdoZXJlIElQdjQgd2FzIG5ldmVyIGRl cGxveWVkLg0KICAgIA0KICAgID4gDQogICAgPiBJbiBteSBodW1ibGUgb3BpbmlvbiwNCiAgICA+ IA0KICAgID4gSSB0aGluaywgaWYgSSBhbSBub3Qgd3JvbmcsIHRoYXQgdGhlcmUgYXJlIG5vIHN1 Y2ggbmV0d29ya3MgaW4gd2hpY2gNCiAgICA+IElQdjQgcHJvdG9jb2wgaGFzIGJlZW4gZWxpbWlu YXRlZC4gIE9uIG9uZSBoYW5kLCBhIG5ldHdvcmsgaXMgbWFkZSBvZg0KICAgID4gY29tcHV0ZXJz LCBhbmQgSVB2NCBzdGFja3MgYXJlIHN0aWxsIHByZXNlbnQgaW4gYWxtb3N0IGFsbCBjb21wdXRl cnMuDQogICAgPiBPbiBhbm90aGVyIGhhbmQsIHRoZXJlIG1pZ2h0IGJlIHNvbWUgcHRwIGxpbmtz IChub3QgbmV0d29ya3MsIGJ1dA0KICAgID4gaW5kaXZpZHVhbCBsaW5rcykgdGhhdCBydW4gSVB2 NiBvbmx5Lg0KICAgIA0KICAgIFlvdSBhcmUgd3JvbmfigKYgVGhlcmUgYXJlIGV4YW1wbGVzIGF0 IHZhcmlvdXMgbGV2ZWxzIG9mIElQdjYtb25seSBuZXR3b3Jrcy4gTWFueSBtb2JpbGUgY2Fycmll cnMgYXJlIElQdjYtb25seSBpbiB0aGUgVVMsIHRob3VnaCB0aGV5IGRvIHByb3ZpZGUgc29tZSBh cHBhcmVudCBJUHY0IGNhcGFiaWxpdHkgdG8gdGhlIGVuZCB1c2VyIHRocm91Z2ggbWVjaGFuaXNt cyBzdWNoIGFzIDQ2NFhMQVQgYW5kL29yIE5BVDY0Lg0KICAgIA0KICAgIEFub3RoZXIgc2lnbmlm aWNhbnQgZXhhbXBsZSBpcyBGYWNlYm9vayB3aGVyZSB0aGV5IGFyZSBlc3NlbnRpYWxseSBJUHY2 LW9ubHkgdGhyb3VnaG91dCB0aGVpciBuZXR3b3JrIGFuZCBwcm92aWRlIG1pbmltYWwgSVB2NCB0 cmFuc2xhdGlvbiBzaGltIGF0IHRoZSBlZGdlIHRvIGNvcGUgd2l0aCBlbmQgdXNlcnMgdGhhdCBs YWNrIElQdjYgY2FwYWJpbGl0eS4NCiAgICANCiAgICA+IFRoYXQgaXMgd2h5IGl0IGlzIGhhcmQg dG8gYWdyZWUgb24gdGhlIGFzc3VtcHRpb24gb2YgSVB2NCBiZWluZyBlbGltaW5hdGVkIHNvbWV3 aGVyZS4gIFdvcnNlLCBpdCBtYWtlcyBsb29rIGFzIGlmIHRoZSBnb2FsIG9mIHRoYXQgJ0lQdjYt b25seScgaXMgdG8gYXJyaXZlIGF0IHRoYXQgc2FtZSBzaXR1YXRpb24gd2hpY2ggaW4gZmFjdCBk b2VzIHVzZSBJUHY0Lg0KICAgIA0KICAgIEFzIGEgZ2VuZXJhbCBydWxlLCBvbmNlIElQdjYgaXMg dWJpcXVpdG91c2x5IGRlcGxveWVkIGluIGEgbmV0d29yaywgdGhlIHByZXNlcnZhdGlvbiBvZiBJ UHY0IGluIHRoZSBtYWpvcml0eSBvZiB0aGF0IG5ldHdvcmsgYmVjb21lcyBhbiB1bm5lY2Vzc2Fy eSBjb3N0IGZhY3RvciBhbmQgYSBzZWN1cml0eSByaXNrIChpbmNyZWFzZWQgYXR0YWNrIHN1cmZh Y2UsIGlmIG5vdGhpbmcgZWxzZSkuIEFzIHN1Y2gsIEkgdGhpbmsgeW91IHdpbGwgc2VlIGFuIGlu Y3JlYXNpbmcgbnVtYmVyIG9mIG9yZ2FuaXphdGlvbnMgZm9sbG93IG9uIHRvIHRoZSB3YXkgRmFj ZWJvb2sgaGFzIG1hbmFnZWQgdGhlaXIgdHJhbnNpdGlvbiBhbmQgc3RhcnQgZWxpbWluYXRpbmcg SVB2NCB3aGVyZXZlciBwb3NzaWJsZSBhbmQgcmVwbGFjaW5nIGl0IHdpdGggdHJhbnNsYXRpb24g c2hpbXMgYXMgZmFyIG91dCB0b3dhcmRzIHRoZSBib3JkZXIgYXMgcHJhY3RpY2FsLg0KICAgIA0K ICAgIE93ZW4NCiAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KICAgIHY2b3BzQGlldGYu b3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KICAg IA0KIA0KIA0KIA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KSVB2NCBpcyBvdmVyDQpBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCmh0 dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tDQpUaGUgSVB2NiBDb21wYW55DQogDQpUaGlzIGVs ZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmls ZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBm b3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5k IGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nLCBk aXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBl dmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Ns b3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRo aXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmls ZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFs IG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8gaW5m b3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KIA0KIA0KIA0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxp bmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCg== ------=_001_NextPart151453433236_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Chongfeng,

 

Thanks for your i= nputs!

 

Below, in-line =E2=80=A6

 

 =

 

El 8/3/20 11:31, "v6ops en = nombre de xiechf@chinatelecom.cn<= /a>" <v6ops-bounces@ietf.= org en nombre de xiechf@china= telecom.cn> escribi=C3=B3:

 

<= div style=3D'margin-left:7.5pt;margin-top:7.5pt;margin-right:7.5pt;margin-b= ottom:7.5pt'>

Hi, Jordi, 

=

First , I agree with you that the definition of IPv6-only needs to = consider the what part of the network we are referring to, for example= , ISP network, IDC, Cloud platform and Service system should have their own= specific definition of IPv6-only.  I hope this draft can go on.

Secondly. for ISP network, the definitio= n of IPv6 should be based on whether it can allocates only IPv6 =

 

[Jord= i] I don=E2=80=99t agree on this point. An ISP may have different parts of = its network with or without IPv6/IPv4, even different services, so I don=E2= =80=99t think it can be split that way.

 

addresses to most o= f its customers for service provisioning, if yes, it can be consider as IPv= 6-only. If it

 

[Jordi] Now, the part you mention as if it is allocating only IPv6 address= es, is also not valid, in my opinion. Because in some of the IPv6-only with= IPv4aaS, the ISP allocate private IPv4 addresses.

 

allocate= s IPv4 address to most of its customers, then it is not IPv6-only. <= span style=3D'font-size:12.0pt'>My personal opionion is that the definition= should not be based on whether to eliminate IPv4 protocol in the network. =  At present stage, it is unrealistic to eliminate IPv4 protocol in mos= t networks, for the networks still need to provide access service to some c= ustomers who do not support IPv6-only due to their poor-capability CPE or terminals.

 

[Jordi] I agree is unrealistic to disable IPv4 in most of t= he customer LANs, but not in the access network. Until 90-99% of the home d= evices of an ISP customers have IPv6 in their LAN devices, an IPv6 with IPv= 4aaS is needed.

 =

Moreever, some networks still need to use = IPv4 for network management . = If the definition it too strict, I guess none of the network can meet the s= tandard, including those who have deplyed 464XLAT. In addition, an IPv6-onl= y network should be open and interconnected with OTTs and other ISPs, some = closed system, such as VoLTE in mobile network, should not be consider as I= Pv6-only, even though it only allocates IPv6 addresses to it customer.

 

[Jordi] If IPv4 is used for management in the access networ= k and provides native IPv4 to the CE (for example), then it is not IPv6-onl= y. We could say in that case: This access network is IPv6-only for the cust= omer service, but still IPv4-only or dual-stack for the management.

 

[Jordi] So I still believe that the =E2=80=9Cnatu= re=E2=80=9D of the definition should be based in if IPv4 is used natively i= n a specific part of a network (then it is IPv6-only) or otherwise is IPv4-= only or dual-stack. What do you think?

 

 

 

Best regard= s

Chongfeng =

 

From: <= a href=3D"mailto:jordi.palet=3D40consulintel.es@dmarc.ietf.org">JORDI PALET= MARTINEZ

Date: 2020-03-= 06 02:12

=

Su= bject: Re: [v6ops] About Req for Comments - "Transiti= on to IPv6"

If you read my draft, my opinion is different:

 

<= /div>

  Definiti= on of IPv6-only

 

   Consequently, considering the context = described in the section above,

   if we want to be precise and a= void confusing others, we can not use

   the terminology "IP= v6-only" in a generic way, and we need to define

<= div>

   what par= t of the network we are referring to.

 

   From that perspec= tive, we define the "IPv6-only" status in a given

<= /div>

   pa= rt(s) of a network, depending on if there is actual native

   for= warding of IPv4, so IPv4 is not configured neither managed.

<= /div>

 

So IPv4 = may be not configured, or not used natively, but there is no way to prevent= that "is there" by means of tunneling of translation.=

 

*un= less* you make sure that any encapsulation or translation is filtered, whic= h is close to impossible.

 

Because we disagree, it seems clear that t= his document is needed.

 

So if anyone has inputs, I will consider the= m in a new version during the weekend.

 

Regards,

=

Jordi

=

@jordipalet

&n= bsp;

=EF=BB=BFEl 5/3/20 17:46, "v6ops en nombre de Owen DeLong" &= lt;v6ops-bounces@ietf.org en nombre de owen@delong.com> escribi=C3=B3:

&= nbsp;

   

   

    > On Ma= r 5, 2020, at 6:02 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com&= gt; wrote:

    >

    > Thank you very = much for the pointer.  In it I could spot

    > the = following footnote: "[4] IPv6-Only refers to network environments in

&= nbsp;   > which use of the IPv4 protocol has been eliminated.=E2=80=9D

   

 &nb= sp;  No.

   

    IPv6-Only refers to ne= twork environments which are not using IPv4. That could be a network where = IPv4 has been eliminated (rare at this time, though Facebook is a significa= nt example) or it could be a greenfield deployment where IPv4 was never dep= loyed.

   

    >

    >= In my humble opinion,

    >

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>    > I = think, if I am not wrong, that there are no such networks in which

 &n= bsp;  > IPv4 protocol has been eliminated.  On one hand, a net= work is made of

    > computers, and IPv4 stacks are stil= l present in almost all computers.

    > On another hand,= there might be some ptp links (not networks, but

=

    > i= ndividual links) that run IPv6 only.

   

   = You are wrong=E2=80=A6 There are examples at various levels of IPv6-only n= etworks. Many mobile carriers are IPv6-only in the US, though they do provi= de some apparent IPv4 capability to the end user through mechanisms such as= 464XLAT and/or NAT64.

   

    Another sign= ificant example is Facebook where they are essentially IPv6-only throughout= their network and provide minimal IPv4 translation shim at the edge to cop= e with end users that lack IPv6 capability.

    <= /p>

  = ;  > That is why it is hard to agree on the assumption of IPv4 bein= g eliminated somewhere.  Worse, it makes look as if the goal of that '= IPv6-only' is to arrive at that same situation which in fact does use IPv4.=

   

    As a general rule, once IPv6 is ubi= quitously deployed in a network, the preservation of IPv4 in the majority o= f that network becomes an unnecessary cost factor and a security risk (incr= eased attack surface, if nothing else). As such, I think you will see an in= creasing number of organizations follow on to the way Facebook has managed = their transition and start eliminating IPv4 wherever possible and replacing= it with translation shims as far out towards the border as practical.=

&nbs= p;  

    Owen

   

  &= nbsp;

=     _______________________________________________

 &n= bsp;  v6ops mailing list

    v6ops@ietf.org<= /p>

  = ;  https://www.ietf.org/mailman/listinfo/v6ops

   

&nb= sp;

 

 

**********************************************=

IPv4 is ov= er

Are you ready for the new Internet ?

http://www.theipv6company.com

The= IPv6 Company

 

This electronic message contains information which may= be privileged or confidential. The information is intended to be for the e= xclusive use of the individual(s) named above and further non-explicilty au= thorized disclosure, copying, distribution or use of the contents of this i= nformation, even if partially, including attached files, is strictly prohib= ited and will be considered a criminal offense.. If you are not the intende= d recipient be aware that any disclosure, copying, distribution or use of t= he contents of this information, even if partially, including attached file= s, is strictly prohibited, will be considered a criminal offense, so you mu= st reply to the original sender to inform about this communication and dele= te it.

 

 

 

_______________________________________________=

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6= ops

_______________________________________________ v6ops mai= ling list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops <= /o:p>


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3666591146_285153632-- From nobody Mon Mar 9 01:42:39 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A7C3A0A50 for ; Mon, 9 Mar 2020 01:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rREf0AZv6UjP for ; Mon, 9 Mar 2020 01:42:34 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348E83A0874 for ; Mon, 9 Mar 2020 01:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1583743352; x=1584348152; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=XF1SfO1T6U39aheq8t5jCd9JwO7bl0psbF njhdTTOBw=; b=ULCvuZ+rOsEgZ969aqFz8l7tQXsKqhzjoXuDlIVOmQwU32gmPc 8vpDVHHWgD/QRE1sHnrJyQhK9oeK1jgDId1ev+pVBDOy1BTItyY2o82MNxeijsw3 3kFiUdLOOha3Im4HzkKA3N891eGR05KrLMijrndN6umBBuuWdP4u8w4+0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 09 Mar 2020 09:42:32 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 09 Mar 2020 09:42:30 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000084636.msg for ; Mon, 09 Mar 2020 09:42:30 +0100 X-MDRemoteIP: 2001:470:1f09:495:6d01:1905:b4f1:26f8 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Mon, 09 Mar 2020 09:42:30 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=13370d17de=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.22.0.200209 Date: Mon, 09 Mar 2020 09:42:29 +0100 From: JORDI PALET MARTINEZ To: v6ops Message-ID: Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <2020030818294834486735@chinatelecom.cn> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3666591749_2013598949" Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 08:42:37 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3666591749_2013598949 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Clark, =20 El 8/3/20 12:38, "v6ops en nombre de Clark Gaylord" escribi=C3=B3: =20 It seems to me the context of the OMB guidance is relevant to the question = of "IPv6-only". The draft memo is reasonably good at this, but succinctly s= omething like "agency internal networks use single-stack IPv6 with any=20 =20 [Jordi] I don=E2=80=99t think is so clear. Footnote 4 =E2=80=9CIPv6-Only re= fers to network environments in which use of the IPv4 protocol has been eli= minated=E2=80=9D will be much clear if it says =E2=80=9CIPv6-Only refers to= network environments in which use of the *native* IPv4 protocol has been e= liminated=E2=80=9D. =20 If a Federal office decides to have its DC with IPv6-only, then IPv4-only u= sers will not be able to access it. In that case the DC must use, for examp= le SIIT-DC. That will mean that the DC (internally) is IPv6-only, but the D= C-to-Internet is dual-stack, in order to be able to use SIIT-DC. =20 Furthermore, footnote 5, =E2=80=9CNote that for public Internet services, m= aintaining viable IPv4 interfaces and transition mechanisms at the edge of = service infrastructure may be necessary for additional time, but this does = not preclude operating the backend infrastructure as IPv6-only.=E2=80=9D Is= precisely saying that. =20 It may happen that some of the LANs in the Federal office itself, are dual-= stack still. Otherwise, employees will not be able to use Internet resource= s that don=E2=80=99t work well with NAT64+DNS64, for example, web sites or = apps that use literal IPv4-addresses and are out of the control of the Fede= ral office. So, in this case they still need to use IPv4aaS. =20 =20 =20 =20 external connectivity supporting IPv6. External connectivity that requires = connectivity to legacy Internet hosts can be accomplished via appropriate g= ateway technologies such as NAT64". A provision for "specific applications = where IPv6 is not supportable may be able to use internal gateway technolog= ies such as 464XLAT with a plan for migration to support IPv6 natively." Th= ese aren't exact quotes, just my suggested ideas, but this seems to capture= the spirit of the initiative. =20 On Sun, Mar 8, 2020 at 6:30 AM xiechf@chinatelecom.cn wrote: Hi, Jordi,=20 First , I agree with you that the definition of IPv6-only needs to consider= the what part of the network we are referring to, for example, ISP network= , IDC, Cloud platform and Service system should have their own specific def= inition of IPv6-only. I hope this draft can go on. Secondly. for ISP network, the definition of IPv6 should be based on whethe= r it can allocates only IPv6 addresses to most of its customers for service= provisioning, if yes, it can be consider as IPv6-only. If it allocates IPv= 4 address to most of its customers, then it is not IPv6-only. My personal o= pionion is that the definition should not be based on whether to eliminate = IPv4 protocol in the network. At present stage, it is unrealistic to elimi= nate IPv4 protocol in most networks, for the networks still need to provide= access service to some customers who do not support IPv6-only due to their= poor-capability CPE or terminals. Moreever, some networks still need to us= e IPv4 for network management . If the definition it too strict, I guess no= ne of the network can meet the standard, including those who have deplyed 4= 64XLAT. In addition, an IPv6-only network should be open and interconnected= with OTTs and other ISPs, some closed system, such as VoLTE in mobile netw= ork, should not be consider as IPv6-only, even though it only allocates IPv= 6 addresses to it customer. =20 Best regards Chongfeng=20 =20 From: JORDI PALET MARTINEZ Date: 2020-03-06 02:12 To: v6ops@ietf.org Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" If you read my draft, my opinion is different: =20 Definition of IPv6-only =20 Consequently, considering the context described in the section above, if we want to be precise and avoid confusing others, we can not use the terminology "IPv6-only" in a generic way, and we need to define what part of the network we are referring to. =20 From that perspective, we define the "IPv6-only" status in a given part(s) of a network, depending on if there is actual native forwarding of IPv4, so IPv4 is not configured neither managed. =20 So IPv4 may be not configured, or not used natively, but there is no way to= prevent that "is there" by means of tunneling of translation. =20 *unless* you make sure that any encapsulation or translation is filtered, w= hich is close to impossible. =20 Because we disagree, it seems clear that this document is needed. =20 So if anyone has inputs, I will consider them in a new version during the w= eekend. =20 Regards, Jordi @jordipalet =20 =EF=BB=BFEl 5/3/20 17:46, "v6ops en nombre de Owen DeLong" escribi=C3=B3: =20 =20 =20 > On Mar 5, 2020, at 6:02 AM, Alexandre Petrescu wrote: >=20 > Thank you very much for the pointer. In it I could spot > the following footnote: "[4] IPv6-Only refers to network environments= in > which use of the IPv4 protocol has been eliminated.=E2=80=9D =20 No. =20 IPv6-Only refers to network environments which are not using IPv4. That= could be a network where IPv4 has been eliminated (rare at this time, thou= gh Facebook is a significant example) or it could be a greenfield deploymen= t where IPv4 was never deployed. =20 >=20 > In my humble opinion, >=20 > I think, if I am not wrong, that there are no such networks in which > IPv4 protocol has been eliminated. On one hand, a network is made of > computers, and IPv4 stacks are still present in almost all computers. > On another hand, there might be some ptp links (not networks, but > individual links) that run IPv6 only. =20 You are wrong=E2=80=A6 There are examples at various levels of IPv6-onl= y networks. Many mobile carriers are IPv6-only in the US, though they do pr= ovide some apparent IPv4 capability to the end user through mechanisms such= as 464XLAT and/or NAT64. =20 Another significant example is Facebook where they are essentially IPv6= -only throughout their network and provide minimal IPv4 translation shim at= the edge to cope with end users that lack IPv6 capability. =20 > That is why it is hard to agree on the assumption of IPv4 being elimi= nated somewhere. Worse, it makes look as if the goal of that 'IPv6-only' i= s to arrive at that same situation which in fact does use IPv4. =20 As a general rule, once IPv6 is ubiquitously deployed in a network, the= preservation of IPv4 in the majority of that network becomes an unnecessar= y cost factor and a security risk (increased attack surface, if nothing els= e). As such, I think you will see an increasing number of organizations fol= low on to the way Facebook has managed their transition and start eliminati= ng IPv4 wherever possible and replacing it with translation shims as far ou= t towards the border as practical. =20 Owen =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www..theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense.. If you are not the intended recipient be aware = that any disclosure, copying, distribution or use of the contents of this i= nformation, even if partially, including attached files, is strictly prohib= ited, will be considered a criminal offense, so you must reply to the origi= nal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 --=20 Clark Gaylord cgaylord@vt.edu _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3666591749_2013598949 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Clark,

 

El 8/3/20 12:38, "v6ops en nombre de Clark Gaylord&= quot; <v6ops-bounces@ietf.org<= /a> en nombre de cgaylord@vt.edu>= escribi=C3=B3:

 

It seems to me the context of the OMB guidan= ce is relevant to the question of "IPv6-only". The draft memo is = reasonably good at this, but succinctly something like "agency interna= l networks use single-stack IPv6 with any

 

[Jordi] I don=E2=80= =99t think is so clear. Footnote 4 =E2=80=9CIPv6-= Only refers to network environments in which use of the IPv4 protocol has b= een eliminated=E2=80=9D will be much clear if it says =E2=80=9CIPv6-Only re= fers to network environments in which use of the *native* IPv4 protocol has= been eliminated=E2=80=9D.

 

If a Federal office decides to have its DC with IPv6-only, then IPv4-= only users will not be able to access it. In that case the DC must use, for= example SIIT-DC. That will mean that the DC (internally) is IPv6-only, but= the DC-to-Internet is dual-stack, in order to be able to use SIIT-DC.=

 <= /span>

Furthermore, footnote 5, = =E2=80=9CNote that for public Internet services, maintaining viable IPv4 in= terfaces and transition mechanisms at the edge of service infrastructure ma= y be necessary for additional time, but this does not preclude operating th= e backend infrastructure as IPv6-only.=E2=80=9D Is precisely saying that.

 

It may happen that som= e of the LANs in the Federal office itself, are dual-stack still. Otherwise= , employees will not be able to use Internet resources that don=E2=80=99t w= ork well with NAT64+DNS64, for example, web sites or apps that use literal = IPv4-addresses and are out of the control of the Federal office. So, in thi= s case they still need to use IPv4aaS.

 

<= span lang=3DEN-US style=3D'font-size:12.0pt'> 

 = ;

 

external connectivity supporting IPv6. External connectivity that requires connectivity to legacy Internet host= s can be accomplished via appropriate gateway technologies such as NAT64&qu= ot;. A provision for "specific applications where IPv6 is not supporta= ble may be able to use internal gateway technologies such as 464XLAT with a= plan for migration to support IPv6 natively." These aren't exact quot= es, just my suggested ideas, but this seems to capture the spirit of the in= itiative.

 

On Sun, Mar 8, 2020 at 6:30 AM xiechf@chinatelecom.cn <xiechf@chinatelecom.cn> wrote:

Hi, Jordi, 

First , I agree with you that the definition of IPv6-only needs to cons= ider the what part of the network we are referring to, for example, IS= P network, IDC, Cloud platform and Service system should have their own spe= cific definition of IPv6-only.  I hope this draft can go on.

Secondly. for ISP network, the definition of= IPv6 should be based on whether it can allocates only IPv6 addresses to mo= st of its customers for service provisioning, if yes, it can be consider as= IPv6-only. If it allocates IPv4 address to most of its customers, then it = is not IPv6-only. My personal opionion is that the definition should not be= based on whether to eliminate IPv4 protocol in the network.  At prese= nt stage, it is unrealistic to eliminate IPv4 protocol in most networks, fo= r the networks still need to provide access service to some customers who d= o not support IPv6-only due to their poor-capability CPE or terminals. More= ever, some networks still need to use IPv4 for network management . If= the definition it too strict, I guess none of the network can meet the sta= ndard, including those who have deplyed 464XLAT. In addition, an IPv6-only = network should be open and interconnected with OTTs and other ISPs, some cl= osed system, such as VoLTE in mobile network, should not be consider as IPv= 6-only, even though it only allocates IPv6 addresses to it customer.=

 

Best regards

=

Chongfeng 

=  

Date: 2020-03-06&nb= sp;02:12

Subject: Re: [v6ops] About Req for Comments - &= quot;Transition to IPv6"

<= div>

If you read my draft,= my opinion is different:

 

  Definition of IPv6-only

&nbs= p;

   Consequently, considering the context described in the sect= ion above,

   if we want to be precise and avoid confusing others= , we can not use

   the terminology "IPv6-only" in a ge= neric way, and we need to define

   what part of the network we a= re referring to.

 

   From that perspective, we define the &= quot;IPv6-only" status in a given

   part(s) of a network, d= epending on if there is actual native

   forwarding of IPv4, so I= Pv4 is not configured neither managed.

 

So IPv4 may be not configured= , or not used natively, but there is no way to prevent that "is there&= quot; by means of tunneling of translation.

 

*unless* you make sure t= hat any encapsulation or translation is filtered, which is close to impossi= ble.

 

Because we disagree, it seems clear that this document is neede= d.

 

So if anyone has inputs, I will consider them in a new version du= ring the weekend.

 

Regards,

Jordi

@jordipalet

<= div>

 

=

=EF=BB=BFEl 5/= 3/20 17:46, "v6ops en nombre de Owen DeLong" <v6ops-bounces@ietf.org en n= ombre de owen@delong.c= om> escribi=C3=B3:

 

   

   

&n= bsp;   > On Mar 5, 2020, at 6:02 AM, Alexandre Petrescu <alexandre.p= etrescu@gmail.com> wrote:

    >

   = ; > Thank you very much for the pointer.  In it I could spot

 =    > the following footnote: "[4] IPv6-Only refers to net= work environments in

    > which use of the IPv4 protocol= has been eliminated.=E2=80=9D

   

    No.

   

    IPv6-Only r= efers to network environments which are not using IPv4. That could be a net= work where IPv4 has been eliminated (rare at this time, though Facebook is = a significant example) or it could be a greenfield deployment where IPv4 wa= s never deployed.

   

    >

  =   > In my humble opinion,

    >

  &nbs= p; > I think, if I am not wrong, that there are no such networks in whic= h

    > IPv4 protocol has been eliminated.  On one h= and, a network is made of

    > computers, and IPv4 stack= s are still present in almost all computers.

    > On ano= ther hand, there might be some ptp links (not networks, but

<= /div>

  &nb= sp; > individual links) that run IPv6 only.

   

 &n= bsp;  You are wrong=E2=80=A6 There are examples at various levels of I= Pv6-only networks. Many mobile carriers are IPv6-only in the US, though the= y do provide some apparent IPv4 capability to the end user through mechanis= ms such as 464XLAT and/or NAT64.

   

    Ano= ther significant example is Facebook where they are essentially IPv6-only t= hroughout their network and provide minimal IPv4 translation shim at the ed= ge to cope with end users that lack IPv6 capability.

   

&n= bsp;   > That is why it is hard to agree on the assumption of = IPv4 being eliminated somewhere.  Worse, it makes look as if the goal = of that 'IPv6-only' is to arrive at that same situation which in fact does = use IPv4.

   

    As a general rule, once IP= v6 is ubiquitously deployed in a network, the preservation of IPv4 in the m= ajority of that network becomes an unnecessary cost factor and a security r= isk (increased attack surface, if nothing else). As such, I think you will = see an increasing number of organizations follow on to the way Facebook has= managed their transition and start eliminating IPv4 wherever possible and = replacing it with translation shims as far out towards the border as practi= cal.

   

    Owen

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>   

 =   

    _______________________________________________

    v6ops mailing list

    v6ops@ietf.org<= /p>

=

    <= o:p>

=  

 

 

**********************************************

IPv4 is= over

Are you ready for the new Internet ?

The IPv6 Com= pany

 

This electronic message contains information which may be privi= leged 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 informatio= n, even if partially, including attached files, is strictly prohibited and = will be considered a criminal offense.. If you are not the intended recipie= nt be aware that any disclosure, copying, distribution or use of the conten= ts of this information, even if partially, including attached files, is str= ictly prohibited, will be considered a criminal offense, so you must reply = to the original sender to inform about this communication and delete it.

&n= bsp;

 

 

_______________________________________________

v6ops ma= iling list

<= /div>

_= ______________________________________________
v6ops mailing list
v6ops@ietf.org
https= ://www.ietf.org/mailman/listinfo/v6ops


 

--

Clark Gaylord

_______________________________________________ = v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6o= ps


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3666591749_2013598949-- From nobody Mon Mar 9 11:48:23 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281D83A0E67 for ; Mon, 9 Mar 2020 11:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9VtlkIlVTYa for ; Mon, 9 Mar 2020 11:48:04 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9C23A155F for ; Mon, 9 Mar 2020 11:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1583779672; x=1584384472; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=u2Asb6nlmXzA+sppA3dtb akPEvp8XMT3L6t9X1xoRjw=; b=UlcGvlYZSOOe3FabrxCqNciP5RFhBYKqM8xEd /zuI73rBBIJkh2tIT3xu2yF8ePtvZdZEA+NRl66tqOFlIEwbtc4xglGzMkZLRnmm XVvq+0bQJIOdTVkWqhlrnYx0hlnkknvQ7h8E67Kyosy6VS5Bvd1ZvufSmcf5NjEJ XAwLRE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 09 Mar 2020 19:47:52 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 09 Mar 2020 19:47:51 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000085271.msg for ; Mon, 09 Mar 2020 19:47:51 +0100 X-MDRemoteIP: 2001:470:1f09:495:ddbf:25b5:4c7e:c3ae X-MDHelo: [10.10.10.144] X-MDArrival-Date: Mon, 09 Mar 2020 19:47:51 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=13370d17de=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.22.0.200209 Date: Mon, 09 Mar 2020 19:47:46 +0100 From: JORDI PALET MARTINEZ To: Message-ID: <4A886236-7D17-41F2-8291-0BC1B49F7A59@consulintel.es> Thread-Topic: IPv6-only Terminology Definition Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [v6ops] IPv6-only Terminology Definition X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 18:48:21 -0000 Hi all, After the recent discussion, I've posted a new version (minor changes) for this document: https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/?include_text=1 Comments welcome! Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com 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 nobody Mon Mar 9 14:34:26 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E64DA3A17C7; Mon, 9 Mar 2020 14:34:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <158378965285.5665.8546898344272554865@ietfa.amsl.com> Date: Mon, 09 Mar 2020 14:34:12 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-slaac-renum-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 21:34:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events Authors : Fernando Gont Jan Zorz Richard Patterson Filename : draft-ietf-v6ops-slaac-renum-01.txt Pages : 12 Date : 2020-03-09 Abstract: In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a CPE crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document documents this problem, and discusses operational workarounds that may help to improve network robustness. Additionally, it highlights areas where further work may be needed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-slaac-renum-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-slaac-renum-01 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/ From nobody Mon Mar 9 15:03:22 2020 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7304D3A07A9; Mon, 9 Mar 2020 15:03:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <158379138938.5532.4442616793800114566@ietfa.amsl.com> Date: Mon, 09 Mar 2020 15:03:09 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-cpe-slaac-renum-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 22:03:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Improving the Reaction of Customer Edge Routers to Renumbering Events Authors : Fernando Gont Jan Zorz Richard Patterson Filename : draft-ietf-v6ops-cpe-slaac-renum-01.txt Pages : 6 Date : 2020-03-09 Abstract: In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a Customer Edge Router crashes and reboots without knowledge of the previously-employed prefixes), hosts on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document specifies improvements to Customer Edge Routers that help mitigate the aforementioned problem for typical residential and small office scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-slaac-renum-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-cpe-slaac-renum-01 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/ From nobody Mon Mar 9 17:29:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48613A0ACA; Mon, 9 Mar 2020 17:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcOFXwrop8DG; Mon, 9 Mar 2020 17:29:47 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94E13A0ACC; Mon, 9 Mar 2020 17:29:46 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id e11so11134065qkg.9; Mon, 09 Mar 2020 17:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=R00dZixcRloG6LSzrOeAIibZAzbG8FKi3CVOLsNTqCI=; b=D84oXGCrkYIt9azYlfASU1snsEnFtL4qGcDdjqvxfaoddHxDwqw6x5ABGvlNnU6wBR unf+I452HS0CbPPV/H/T5TjNfYVxDBov/mYumIA47JjCJ/9PLihxzSBfA1/w+AdG1N+0 TwITqm9VjUXCTzvdsUKite4w0uJgxSjeC9jPDfkUsFwwJAN7mdy8AnLeu3AkfQgscPAd h3hhJn42X0SKnLlI+erHMyULY1aTR0+ehDsUOuRzq2J2nPfoXNzl+asOiNsihSvc1b/u k9Yu2/uMa394JfcvbFtLdkjlyX8/o3CvtCR6D8xxsUtCyJThPKCyAah5/4vj2odFNfD1 RyDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=R00dZixcRloG6LSzrOeAIibZAzbG8FKi3CVOLsNTqCI=; b=iXcwp6uHrD7/YgH0cQgL85EoTWMS5aLAEBQPGMt+9QJR+NbMGPi9m/t9nb24AdRpmh 5HSPBbafe+p73ntYaKcAkPS8D1zraiJ1RpWH1dCdadtIxZ7hsgOOcu7mL0tUYtcUrGjM cVBj/I7BKb8t2MrFrVzoVzoDRzYVnFSJFRlNfLvY7G/PulkDEGJiYw4LSANjZoBW7Lnv aV8Tdke6QanEysXQey25UierJxvtlC6dozDVX6N7TwkAX5+8NDIIKm1SgD13yhRgknDd SVuzdH3wcEtWHsA+04dXK//bjle5ezQ4o9d+dTmEAPc+6n9abEo/c5YC6Zp7o0V+4BDN SM+Q== X-Gm-Message-State: ANhLgQ3XU09SPP5o4cEzQJlxmOmbA61Nc4bT6pnJxo5atE8JUp61mVm0 +QanH6+hFPhIrTfr5Pav/o+zHO5BYCuvqqzmVtU3Xkxk X-Google-Smtp-Source: ADFU+vulLKUTy1pcSVOWJMN5LfreQQCV+nktMakixWRUxNkvaNp66OP2wCtjTQQrgfnWtHTvBUyV8G2nOqhiqgRCrSk= X-Received: by 2002:a37:92c4:: with SMTP id u187mr16593372qkd.466.1583800185608; Mon, 09 Mar 2020 17:29:45 -0700 (PDT) MIME-Version: 1.0 References: <158378573009.5683.15353289977617206017@ietfa.amsl.com> In-Reply-To: <158378573009.5683.15353289977617206017@ietfa.amsl.com> From: Jen Linkova Date: Tue, 10 Mar 2020 11:29:34 +1100 Message-ID: To: dhcwg@ietf.org, V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] Fwd: [dhcwg] I-D Action: draft-ietf-dhc-v6only-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 00:29:49 -0000 Hello, -00 version of the DHC WG document has been submitted, following the successful adoption call. The main changes: - the draft now suggests that the server SHOULD respond with '0.0.0.0' and MAY respond with the real address from the pool. - Section discussing interoperability with RFC2563 is added; - Section is added to discuss why the proposed mechanism implies NAT64. - Terminology clarified. In particular, as per Mohamed's suggestion: -- IPv4-as-a-Service has been replaced with 'IPv4-on-demand' to avoid confusion with the existing use of that term in ISP environments. -- 'host' behaviour vs 'dhcp client' behaviour is made more clear. - Some text added to explain that using DHCP option to signal IPv6-only capability is better than delaying DHCP process - Option type is now called Option code - MIN_V6ONLY_WAIT constant = 300 secs added instead of hardcoding 300 secs. Comments and suggestions are highly appreciated. Also, if you feel your name is mistakenly missing from the Acknowledgement section it's not because I'm unappreciative of your valuable contribution, it's because I might lose track of comments ;( Please do not hesitate to drop me an email! ---------- Forwarded message --------- From: Date: Tue, Mar 10, 2020 at 7:28 AM Subject: [dhcwg] I-D Action: draft-ietf-dhc-v6only-00.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration WG of the IETF. Title : IPv6-Only-Preferred Option for DHCP Authors : Lorenzo Colitti Jen Linkova Michael C. Richardson Tomek Mrugalski Filename : draft-ietf-dhc-v6only-00.txt Pages : 12 Date : 2020-03-09 Abstract: This document specifies a DHCP option to indicate that a host supports an IPv6-only mode and willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-v6only/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dhc-v6only-00 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-v6only-00 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/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- SY, Jen Linkova aka Furry From nobody Tue Mar 10 11:03:01 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A1F3A05A4 for ; Tue, 10 Mar 2020 11:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV2f14kj6iTY for ; Tue, 10 Mar 2020 11:02:54 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4413A0780 for ; Tue, 10 Mar 2020 11:02:53 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02AI2oGT1138855 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 11:02:50 -0700 From: Owen DeLong Message-Id: <073925C4-5355-4C51-84A4-4D9545013552@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_106B6709-0511-4FF2-9520-2091FDFFED82" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 10 Mar 2020 11:02:50 -0700 In-Reply-To: Cc: v6ops To: JORDI PALET MARTINEZ References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <2020030818294834486735@chinatelecom.cn> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Tue, 10 Mar 2020 11:02:51 -0700 (PDT) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 18:03:00 -0000 --Apple-Mail=_106B6709-0511-4FF2-9520-2091FDFFED82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 9, 2020, at 01:42 , JORDI PALET MARTINEZ = wrote: >=20 > Hi Clark, > =20 > El 8/3/20 12:38, "v6ops en nombre de Clark Gaylord" = en nombre de = cgaylord@vt.edu > escribi=C3=B3: > =20 > It seems to me the context of the OMB guidance is relevant to the = question of "IPv6-only". The draft memo is reasonably good at this, but = succinctly something like "agency internal networks use single-stack = IPv6 with any=20 > =20 > [Jordi] I don=E2=80=99t think is so clear. Footnote 4 =E2=80=9CIPv6-Only= refers to network environments in which use of the IPv4 protocol has = been eliminated=E2=80=9D will be much clear if it says =E2=80=9CIPv6-Only = refers to network environments in which use of the *native* IPv4 = protocol has been eliminated=E2=80=9D. I don=E2=80=99t believe that what you propose is the intent in the memo. I believe they intend to eliminate the use of ALL IPv4, not just native = IPv4 on government networks. =20 > If a Federal office decides to have its DC with IPv6-only, then = IPv4-only users will not be able to access it. In that case the DC must = use, for example SIIT-DC. That will mean that the DC (internally) is = IPv6-only, but the DC-to-Internet is dual-stack, in order to be able to = use SIIT-DC. I believe that _IS_ the intent (no support for SIIT/NAT64/etc.). Remember, this is referring to the INTERNAL networks of the federal = government agencies=E2=80=A6 Not the public-facing networks. Unless I misread the memo, the intent is to preserve dual-stack = functionality on public-facing services, but ensure that there are no = remaining IPv4 dependencies in providing those services over IPv6. =20 > Furthermore, footnote 5, =E2=80=9CNote that for public Internet = services, maintaining viable IPv4 interfaces and transition mechanisms = at the edge of service infrastructure may be necessary for additional = time, but this does not preclude operating the backend infrastructure as = IPv6-only.=E2=80=9D Is precisely saying that. Correct. =20 > It may happen that some of the LANs in the Federal office itself, are = dual-stack still. Otherwise, employees will not be able to use Internet = resources that don=E2=80=99t work well with NAT64+DNS64, for example, = web sites or apps that use literal IPv4-addresses and are out of the = control of the Federal office. So, in this case they still need to use = IPv4aaS. That=E2=80=99s not the desired outcome in this process. Indeed, my impression is that the government is, through this memo, = intending to put suppliers and web sites on notice that if they do not = have IPv6 accessibility they are likely to lose their government = customers. I see that as a good thing. =20 > external connectivity supporting IPv6. External connectivity that = requires connectivity to legacy Internet hosts can be accomplished via = appropriate gateway technologies such as NAT64". A provision for = "specific applications where IPv6 is not supportable may be able to use = internal gateway technologies such as 464XLAT with a plan for migration = to support IPv6 natively." These aren't exact quotes, just my suggested = ideas, but this seems to capture the spirit of the initiative. I don=E2=80=99t think that=E2=80=99s the actual spirit of the = initiative=E2=80=A6 See above. Owen --Apple-Mail=_106B6709-0511-4FF2-9520-2091FDFFED82 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 9, 2020, at 01:42 , JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> = wrote:

Hi Clark,
 
El 8/3/20 12:38, "v6ops en nombre de = Clark Gaylord" <v6ops-bounces@ietf.org en nombre de cgaylord@vt.edu> escribi=C3=B3:
 
It seems to me the = context of the OMB guidance is relevant to the question of "IPv6-only". = The draft memo is reasonably good at this, but succinctly something like = "agency internal networks use single-stack IPv6 with any 
 
[Jordi] I don=E2=80=99t think is so clear. Footnote 4 =E2=80=9CIPv6-Only refers to network environments in which = use of the IPv4 protocol has been eliminated=E2=80=9D will be much clear = if it says =E2=80=9CIPv6-Only refers to network environments in which = use of the *native* IPv4 protocol has been = eliminated=E2=80=9D.

I don=E2=80=99t believe that what you propose is the = intent in the memo.

I believe they = intend to eliminate the use of ALL IPv4, not just native IPv4 on = government networks.
 
If a Federal office decides = to have its DC with IPv6-only, then IPv4-only users will not be able to = access it. In that case the DC must use, for example SIIT-DC. That will = mean that the DC (internally) is IPv6-only, but the DC-to-Internet is = dual-stack, in order to be able to use = SIIT-DC.

I = believe that _IS_ the intent (no support for = SIIT/NAT64/etc.).

Remember, this is = referring to the INTERNAL networks of the federal government agencies=E2=80= =A6 Not the public-facing networks.

Unless I misread the memo, the intent is to = preserve dual-stack functionality on public-facing services, but ensure = that there are no remaining IPv4 dependencies in providing those = services over IPv6.
 
Furthermore, footnote 5, =E2=80=9CNote that for public = Internet services, maintaining viable IPv4 interfaces and transition = mechanisms at the edge of service infrastructure may be necessary for = additional time, but this does not preclude operating the backend = infrastructure as IPv6-only.=E2=80=9D Is precisely saying = that.

Correct.
 
It may happen that some of = the LANs in the Federal office itself, are dual-stack still. Otherwise, = employees will not be able to use Internet resources that don=E2=80=99t = work well with NAT64+DNS64, for example, web sites or apps that use = literal IPv4-addresses and are out of the control of the Federal office. = So, in this case they still need to use = IPv4aaS.

That=E2=80=99s not the desired outcome in this = process.

Indeed, my impression is = that the government is, through this memo, intending to put suppliers = and web sites on notice that if they do not have IPv6 accessibility they = are likely to lose their government customers.

I see that as a good thing.
 
external connectivity supporting IPv6. External = connectivity that requires connectivity to legacy Internet hosts can be = accomplished via appropriate gateway technologies such as NAT64". A = provision for "specific applications where IPv6 is not supportable may = be able to use internal gateway technologies such as 464XLAT with a plan = for migration to support IPv6 natively." These aren't exact quotes, just = my suggested ideas, but this seems to capture the spirit of the = initiative.

I = don=E2=80=99t think that=E2=80=99s the actual spirit of the = initiative=E2=80=A6

See = above.

Owen

= --Apple-Mail=_106B6709-0511-4FF2-9520-2091FDFFED82-- From nobody Tue Mar 10 11:25:44 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B513A07E7 for ; Tue, 10 Mar 2020 11:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcT8P5Sx3TD0 for ; Tue, 10 Mar 2020 11:25:39 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD4C3A07F0 for ; Tue, 10 Mar 2020 11:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1583864734; x=1584469534; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=aDwFMPMNEFp7/+bqWyoKpBDZCYSBelbt9e nd/FpLQ5s=; b=r3D8XD769o9naaJHCQdLRiRpbmkZlTSDdpded+YW+BP3PkD3nv 9/7U5CF7eGOEVWewcCO3oPrAbo7xWHu4Dg3rPOnruuUYG2uGx1QwHHFToRsKR3Cr eTZpFptjZaeVO/yLYTN6z2GvFnoOyuoRN+VF81Bu84ThzlUbvMP8akxHg= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 10 Mar 2020 19:25:34 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 10 Mar 2020 19:25:33 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000086628.msg for ; Tue, 10 Mar 2020 19:25:32 +0100 X-MDRemoteIP: 2001:470:1f09:495:d5e4:ce9:969f:1214 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Tue, 10 Mar 2020 19:25:32 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=133801c307=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Tue, 10 Mar 2020 19:25:31 +0100 From: JORDI PALET MARTINEZ To: v6ops Message-ID: <4A5BDEE6-2B9E-4338-94C1-3BE9D6E37516@consulintel.es> Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <2020030818294834486735@chinatelecom.cn> <073925C4-5355-4C51-84A4-4D9545013552@delong.com> In-Reply-To: <073925C4-5355-4C51-84A4-4D9545013552@delong.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3666713132_1854623504" Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 18:25:42 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3666713132_1854623504 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Owen, =20 Responses below with ***. =20 El 10/3/20 19:03, "v6ops en nombre de Owen DeLong" escribi=C3=B3: =20 =20 On Mar 9, 2020, at 01:42 , JORDI PALET MARTINEZ wrote: =20 Hi Clark, =20 El 8/3/20 12:38, "v6ops en nombre de Clark Gaylord" escribi=C3=B3: =20 It seems to me the context of the OMB guidance is relevant to the question = of "IPv6-only". The draft memo is reasonably good at this, but succinctly s= omething like "agency internal networks use single-stack IPv6 with any=20 =20 [Jordi] I don=E2=80=99t think is so clear. Footnote 4 =E2=80=9CIPv6-Only re= fers to network environments in which use of the IPv4 protocol has been eli= minated=E2=80=9D will be much clear if it says =E2=80=9CIPv6-Only refers to= network environments in which use of the *native* IPv4 protocol has been e= liminated=E2=80=9D. =20 I don=E2=80=99t believe that what you propose is the intent in the memo. =20 I believe they intend to eliminate the use of ALL IPv4, not just native IPv= 4 on government networks. =20 *** Then there is a problem. If they really want to have ALL the way thru o= nly IPv6 in the LANs, the federal employees will not be able to use *ANY* a= pplication that uses literal addresses (even a simple web page that is doin= g that). Because there is NO transition mechanism that allows that. They ar= e able to force all their internal apps to use only IPv6, fine, but they ha= ve no control over the rest of the Internet. If they are thinking that NAT6= 4+DNS64 resolves that, they lost this =E2=80=9Csmall=E2=80=9D bit in their = thinking. I=E2=80=99ve already reported them to the site that is asking for= comments, hopefully they really pay attention to the inputs. =20 If a Federal office decides to have its DC with IPv6-only, then IPv4-only u= sers will not be able to access it. In that case the DC must use, for examp= le SIIT-DC. That will mean that the DC (internally) is IPv6-only, but the D= C-to-Internet is dual-stack, in order to be able to use SIIT-DC. =20 I believe that _IS_ the intent (no support for SIIT/NAT64/etc.). =20 Remember, this is referring to the INTERNAL networks of the federal governm= ent agencies=E2=80=A6 Not the public-facing networks. =20 Unless I misread the memo, the intent is to preserve dual-stack functionali= ty on public-facing services, but ensure that there are no remaining IPv4 d= ependencies in providing those services over IPv6. =20 Furthermore, footnote 5, =E2=80=9CNote that for public Internet services, m= aintaining viable IPv4 interfaces and transition mechanisms at the edge of = service infrastructure may be necessary for additional time, but this does = not preclude operating the backend infrastructure as IPv6-only.=E2=80=9D Is= precisely saying that. =20 Correct. =20 It may happen that some of the LANs in the Federal office itself, are dual-= stack still. Otherwise, employees will not be able to use Internet resource= s that don=E2=80=99t work well with NAT64+DNS64, for example, web sites or = apps that use literal IPv4-addresses and are out of the control of the Fede= ral office. So, in this case they still need to use IPv4aaS. =20 That=E2=80=99s not the desired outcome in this process. =20 Indeed, my impression is that the government is, through this memo, intendi= ng to put suppliers and web sites on notice that if they do not have IPv6 a= ccessibility they are likely to lose their government customers. =20 I see that as a good thing. =20 *** I will be glad if they can send this memo to every small web site in th= e world, because even if one of them is missing it, and need to be accessed= by the employees, will not work! external connectivity supporting IPv6. External connectivity that requires = connectivity to legacy Internet hosts can be accomplished via appropriate g= ateway technologies such as NAT64". A provision for "specific applications = where IPv6 is not supportable may be able to use internal gateway technolog= ies such as 464XLAT with a plan for migration to support IPv6 natively." Th= ese aren't exact quotes, just my suggested ideas, but this seems to capture= the spirit of the initiative. =20 I don=E2=80=99t think that=E2=80=99s the actual spirit of the initiative=E2= =80=A6 =20 See above. =20 Owen =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3666713132_1854623504 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Owen,

 

Responses below with **= *.

 

El 10/3/20 19:03, &= quot;v6ops en nombre de Owen DeLong" <v6ops-bounces@ietf.org en nombre de owen@delong.com> escribi=C3=B3:

 =

 



<= /o:p>

On Mar 9, 2020, at 01:42 , = JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:=

 

Hi Clark,=

 

=

El 8/3/20 12:38, "v6ops en nombre de Clark Gaylord"= <v6ops-bounces@ietf.org en nombre de cgaylor= d@vt.edu> escribi=C3=B3:

 

=

It seems to me the contex= t of the OMB guidance is relevant to the question of "IPv6-only".= The draft memo is reasonably good at this, but succinctly something like &= quot;agency internal networks use single-stack IPv6 with any 

 <= /span>

[Jordi] I don=E2=80=99= t think is so clear. Footnote 4 =E2=80=9CIPv6-Only refers to network environ= ments in which use of the IPv4 protocol has been eliminated=E2=80=9D will b= e much clear if it says =E2=80=9CIPv6-Only refers to network environments i= n which use of the *native* IPv4 protocol has been eliminated=E2=80=9D.

 

I don=E2=80=99t believe that what you propos= e is the intent in the memo.

 

I believe they intend to eliminate the = use of ALL IPv4, not just native IPv4 on government networks.

 

= *** Then there is a problem. If they really want to have ALL the way thru o= nly IPv6 in the LANs, the federal employees will not be able to use *ANY= * application that uses literal addresses (even a simple web page that = is doing that). Because there is NO transition mechanism that allows that. They are able to= force all their internal apps to use only IPv6, fine, but they have no con= trol over the rest of the Internet. If they are thinking that NAT64+DNS64 r= esolves that, they lost this =E2=80=9Csmall=E2=80=9D bit in their thinking.= I=E2=80=99ve already reported them to the site that is asking for comments= , hopefully they really pay attention to the inputs.

<= /div>

 

If a Federal office decides to have its DC with= IPv6-only, then IPv4-only users will not be able to access it. In that cas= e the DC must use, for example SIIT-DC. That will mean that the DC (interna= lly) is IPv6-only, but the DC-to-Internet is dual-stack, in order to be abl= e to use SIIT-DC.

 

I believe that _IS_ the inten= t (no support for SIIT/NAT64/etc.).

 

Remember, this is referring to t= he INTERNAL networks of the federal government agencies=E2=80=A6 Not the pu= blic-facing networks.

 

Unless I misread the memo, the intent is to = preserve dual-stack functionality on public-facing services, but ensure tha= t there are no remaining IPv4 dependencies in providing those services over= IPv6.

 

Furthermore, footnote 5, =E2=80=9CNote that for = public Internet services, maintaining viable IPv4 interfaces and transition= mechanisms at the edge of service infrastructure may be necessary for addi= tional time, but this does not preclude operating the backend infrastructur= e as IPv6-only.=E2=80=9D Is precisely saying that.

 

Correct.

 

It may happen that some of the LANs in the Fe= deral office itself, are dual-stack still. Otherwise, employees will not be= able to use Internet resources that don=E2=80=99t work well with NAT64+DNS= 64, for example, web sites or apps that use literal IPv4-addresses and are = out of the control of the Federal office. So, in this case they still need = to use IPv4aaS.

 

That=E2=80=99s not the desired = outcome in this process.

 

Indeed, my impression is that the governmen= t is, through this memo, intending to put suppliers and web sites on notice= that if they do not have IPv6 accessibility they are likely to lose their = government customers.

 

I see that as a good thing.

 

*** I will be glad if they can send this memo to every small web site in the world, bec= ause even if one of them is missing it, and need to be accessed by the empl= oyees, will not work!



external connectivity supporting IPv6. External connectivity that requires connectivit= y to legacy Internet hosts can be accomplished via appropriate gateway tech= nologies such as NAT64". A provision for "specific applications w= here IPv6 is not supportable may be able to use internal gateway technologi= es such as 464XLAT with a plan for migration to support IPv6 natively."= ; These aren't exact quotes, just my suggested ideas, but this seems to cap= ture the spirit of the initiative.

<= div>

 

=

I don=E2=80=99t thi= nk that=E2=80=99s the actual spirit of the initiative=E2=80=A6

 <= /o:p>

See a= bove.

 

Owen

 

_______________________________________________ v6ops m= ailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3666713132_1854623504-- From nobody Tue Mar 10 12:27:34 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C8E3A095E for ; Tue, 10 Mar 2020 12:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=irs.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnzNyzI1XW9a for ; Tue, 10 Mar 2020 12:27:24 -0700 (PDT) Received: from EMG4.irs.gov (emg4.irs.gov [IPv6:2610:30:2000:25::91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1C23A099D for ; Tue, 10 Mar 2020 12:27:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.70,538,1574143200"; d="scan'208";a="272221388" Received: from unknown (HELO mem0200img1.tcc.irs.gov) ([10.219.201.80]) by mem0200emg4.tcc.irs.gov with ESMTP; 10 Mar 2020 14:27:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irs.gov; l=4312; q=dns/txt; s=irs-20171230; t=1583868442; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20Morizot=20Timothy=20S=20|To:=20v6ops=20|Subject:=20RE:=20[v6op s]=20About=20Req=20for=20Comments=20-=20"Transition=20to =20IPv6"|Date:=20Tue,=2010=20Mar=202020=2019:27:21=20+000 0|Message-ID:=20<5c7debd563a04421be62d9e8f6c74cd1@irs.gov >|References:=20=0D=0A=20<7eb4dc25-28a6-4927-2356-846e200681d2@gma il.com>=0D=0A=20<0791D4B0-8390-48D7-AF0A-CE004EC3224C@con sulintel.es>=0D=0A=20=0D=0A=20<52b6b9a4f46a49598eccee1b35e5efc5@ir s.gov>=0D=0A=20<89127c25-9c51-c4bb-97ae-3567e80a4c52@gmai l.com>=0D=0A=20<43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delo ng.com>=0D=0A=20=0D=0A=20<2020030818294834486735@chinatelecom .cn>=0D=0A=20=0D=0A=20=0D=0A=20<073925C4-5 355-4C51-84A4-4D9545013552@delong.com>=0D=0A=20<4A5BDEE6- 2B9E-4338-94C1-3BE9D6E37516@consulintel.es>|In-Reply-To: =20<4A5BDEE6-2B9E-4338-94C1-3BE9D6E37516@consulintel.es> |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0; bh=pFXHSgLU7meWr0pMtVQV05x2hgRs/CYGTEZLOvc7tbc=; b=TFmNx82enqpzN+kCmf1IpjjnfKBMXjC5DbV15rWSx0dJ9USHgZc6SRN7 e1KxNSy1e1CmzWxuLeK4Jy4dPjucJy+TQoNc8ebIihlI0HAZp2idp9R6U RxjdGk27p/B+tIer9uUsbhe2CvmaNyDOPcx6Lk5At2s60P8hGqvlc+Hdc uXDYjjqzmBUVNx9lAqZFezUM0M/Rme6EDluZqLFvWxa0LmbgQnOyfOGPz M8KSh9G7B434IeYrTGzyIjM3U0QHvFihkNbGCsR6Bmf4gNLed/nTQNwrx pXV4awNm9SYP0R7Ul7cT8DEiYFqLnIt4EG/WMOn1n87XjxC8B8WlqQh5K Q==; Received: from mtb0120ppexh030.ds.irsnet.gov ([10.207.136.81]) by mem0200img1.tcc.irs.gov with ESMTP/TLS/AES256-GCM-SHA384; 10 Mar 2020 19:27:22 +0000 Received: from MTB0120PPEXH050.ds.irsnet.gov (10.207.136.83) by MTB0120PPEXH030.ds.irsnet.gov (10.207.136.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 10 Mar 2020 15:27:21 -0400 Received: from MTB0120PPEXH050.ds.irsnet.gov ([fe80::9de0:134:e3b8:a42d]) by MTB0120PPEXH050.ds.irsnet.gov ([fe80::9de0:134:e3b8:a42d%15]) with mapi id 15.01.1913.005; Tue, 10 Mar 2020 15:27:21 -0400 From: Morizot Timothy S To: v6ops Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" Thread-Index: AQHV8ueeLLu0nvB3gUGLJcW18YOjU6g6QF0AgAALy4D//7FKwIAAXguAgAAtooCAABgygIAD4mNKgABVLgCAAWGygIACLuQAgAAGVoD//8XNgA== Date: Tue, 10 Mar 2020 19:27:21 +0000 Message-ID: <5c7debd563a04421be62d9e8f6c74cd1@irs.gov> References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <2020030818294834486735@chinatelecom.cn> <073925C4-5355-4C51-84A4-4D9545013552@delong.com> <4A5BDEE6-2B9E-4338-94C1-3BE9D6E37516@consulintel.es> In-Reply-To: <4A5BDEE6-2B9E-4338-94C1-3BE9D6E37516@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.207.132.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 19:27:33 -0000 DQpKT1JESSBQQUxFVCBNQVJUSU5FWiB3cm90ZToNCj4qKiogVGhlbiB0aGVyZSBpcyBhIHByb2Js ZW0uIElmIHRoZXkgcmVhbGx5IHdhbnQgdG8gaGF2ZSBBTEwgdGhlIHdheSB0aHJ1IG9ubHkgSVB2 NiBpbiB0aGUgTEFOcywgdGhlIGZlZGVyYWwgZW1wbG95ZWVzDQo+d2lsbCBub3QgYmUgYWJsZSB0 byB1c2UgKkFOWSogYXBwbGljYXRpb24gdGhhdCB1c2VzIGxpdGVyYWwgYWRkcmVzc2VzIChldmVu IGEgc2ltcGxlIHdlYiBwYWdlIHRoYXQgaXMgZG9pbmcgdGhhdCkuDQo+QmVjYXVzZSB0aGVyZSBp cyBOTyB0cmFuc2l0aW9uIG1lY2hhbmlzbSB0aGF0IGFsbG93cyB0aGF0LiBUaGV5IGFyZSBhYmxl IHRvIGZvcmNlIGFsbCB0aGVpciBpbnRlcm5hbCBhcHBzIHRvIHVzZSBvbmx5DQo+SVB2NiwgZmlu ZSwgYnV0IHRoZXkgaGF2ZSBubyBjb250cm9sIG92ZXIgdGhlIHJlc3Qgb2YgdGhlIEludGVybmV0 LiBJZiB0aGV5IGFyZSB0aGlua2luZyB0aGF0IE5BVDY0K0ROUzY0IHJlc29sdmVzDQo+dGhhdCwg dGhleSBsb3N0IHRoaXMg4oCcc21hbGzigJ0gYml0IGluIHRoZWlyIHRoaW5raW5nLiBJ4oCZdmUg YWxyZWFkeSByZXBvcnRlZCB0aGVtIHRvIHRoZSBzaXRlIHRoYXQgaXMgYXNraW5nIGZvciBjb21t ZW50cywNCj5ob3BlZnVsbHkgdGhleSByZWFsbHkgcGF5IGF0dGVudGlvbiB0byB0aGUgaW5wdXRz Lg0KDQpJJ20gaW50cmlndWVkIHRoYXQgeW91IGJlbGlldmUgdGhhdCdzIGluaGVyZW50bHkgYSBw cm9ibGVtLiBQZXJoYXBzIHlvdSdyZSBub3QgYXdhcmUgaG93IHJlc3RyaWN0aXZlDQpVUyBmZWRl cmFsIGdvdmVybm1lbnQgbmV0d29ya3Mgb2Z0ZW4gYXJlPyBUaGVyZSBhcmUgYSBncmVhdCBtYW55 IHRoaW5ncyBvbiB0aGUgSW50ZXJuZXQgSSBjYW5ub3QNCmFjY2VzcyBmcm9tIG15IHdvcmsgY29t cHV0ZXIsIGV2ZW4gZm9yIG9mZmljaWFsIHdvcmsgcHVycG9zZXMuIEZvciBleGFtcGxlLCBJIGFt IHRoZSBkZXNpZ25hdGVkIHJlcHJlc2VudGF0aXZlDQpmb3IgbXkgb3JnYW5pemF0aW9uIHdpdGgg QVJJTi4gQnV0IGR1cmluZyByZW1vdGUgcGFydGljaXBhdGlvbiwgSSBjb3VsZCBub3QgYWNjZXNz IGphYmJlciBhbmQNCmNhbm5vdCBhY2Nlc3Mgc2xhY2sgZnJvbSBteSB3b3JrIGNvbXB1dGVyLiBJ IGNhbm5vdCBhY2Nlc3MgYW55IGNvbmZlcmVuY2luZyBwbGF0Zm9ybSBmcm9tDQpteSB3b3JrIGNv bXB1dGVyIGV2ZW4gZm9yIG9mZmljaWFsLCBhcHByb3ZlZCBwdXJwb3Nlcy4gVGhlcmUgYXJlIG11 bHRpcGxlIGxldmVscyBvZiBmaXJld2FsbHMgd2hlbg0KSSBhbSBjb25uZWN0ZWQgdG8gdGhlIGVu dGVycHJpc2UgbmV0d29yaywgYWxsIG9wZXJhdGluZyBpbiBkZWZhdWx0IGRlbnkgbW9kZS4gTXkg d29yayBjb21wdXRlcg0KcHJlc2VudGx5IGhhcyBubyBkaXJlY3QgYWNjZXNzIHRvIGFueSBlbmRw b2ludCBvbiB0aGUgSW50ZXJuZXQuIEV2ZXJ5IHNlcnZpY2UgYWxsb3dlZCBpcyBwcm94aWVkLg0K QW5kIGlmIHRoaW5ncyBvbiB0aGUgSW50ZXJuZXQgZG8gbm90IHdvcmsgd2l0aGluIG91ciByZXF1 aXJlbWVudHMsIHdlIGRvbid0IHVzZSB0aGVtLg0KTm93LCByZW1vdmluZyBldmVuIHRoZSBwZXJp bWV0ZXIgc2VydmljZSBwcm94aWVzIHRvIHRoZSBwdWJsaWMgSVB2NCBJbnRlcm5ldCB3b3VsZCBm YWxsDQppbnRvIHRoYXQgbGFzdCAyMCUgdGhhdCBkb2VzIG5vdCB5ZXQgaGF2ZSBhIHNwZWNpZmlj YWxseSBtYW5kYXRlZCBkYXRlLiBUaGUgZW1waGFzaXMsDQp0aG91Z2gsIHNob3VsZCBsaWtlbHkg YmUgb24gKnlldCouIEkga25vdyBtYW55IG9mIHRoZSBwZW9wbGUgd2hvIGNvbnRyaWJ1dGVkIHRv DQp0aGUgZHJhZnQuIEkgZG9uJ3QgdGhpbmsgdGhleSAibG9zdCIgYW55dGhpbmcgaW4gdGhlaXIg dGhpbmtpbmcuDQrCoA0KPioqKiBJIHdpbGwgYmUgZ2xhZCBpZiB0aGV5IGNhbiBzZW5kIHRoaXMg bWVtbyB0byBldmVyeSBzbWFsbCB3ZWIgc2l0ZSBpbiB0aGUgd29ybGQsDQo+YmVjYXVzZSBldmVu IGlmIG9uZSBvZiB0aGVtIGlzIG1pc3NpbmcgaXQsIGFuZCBuZWVkIHRvIGJlIGFjY2Vzc2VkIGJ5 DQo+dGhlIGVtcGxveWVlcywgd2lsbCBub3Qgd29yayENCg0KSXQncyBwdWJsaXNoZWQgaW4gdGhl IEZlZGVyYWwgUmVnaXN0ZXIuIFRob3NlIGludGVyZXN0ZWQgaW4gYWR2YW5jZSB3YXJuaW5nIGFi b3V0IHRoZQ0Kc3RlcHMgdGhlIFVTIGdvdmVybm1lbnQgaXMgcGxhbm5pbmcgdG8gdGFrZSBvbiB0 aGVpciBvd24gbmV0d29ya3MgaGF2ZSBpdCBhdmFpbGFibGUuDQpJdCB3aWxsIHJlbWFpbiBwdWJs aXNoZWQgYnkgT01CIHdoZW4gZm9ybWFsbHkgcmVsZWFzZWQuIEhvd2V2ZXIsIHJlc3RyaWN0aW5n IGFjY2Vzcw0KZm9yIGZlZGVyYWwgZW1wbG95ZWVzIGlzIHBlcmZlY3RseSBub3JtYWwgYW5kIG9j Y3VycyB0b2RheSBmb3IgYWxsIHNvcnRzIG9mDQpyZWFzb25zLiBPdXIgbmV0d29ya3MgZG8gbm90 IG9wZXJhdGUgdW5kZXIgdGhlIHByZW1pc2UgdGhhdCBhbnkgc3lzdGVtDQpvbiBvdXIgbmV0d29y ayBtdXN0IGJlIGFibGUgdG8gYWNjZXNzIGFueSBhcmJpdHJhcnkgc3lzdGVtLCBzZXJ2aWNlLA0K c2l0ZSwgb3IgYXBwbGljYXRpb24gb24gdGhlIEludGVybmV0LiBJbiBmYWN0LCBtb3JlIHRoZSBv cHBvc2l0ZSBhcHBsaWVzLg0KDQpJIGJlbGlldmUgT3dlbiBjYXB0dXJlZCBtb3JlIHRoZSBzcGly aXQgYW5kIGludGVudCBvZiB0aGlzIG5leHQgc3RlcCBpbg0KdGhlIHByb2dyZXNzaW9uIG9mIHRo ZSBVUyBmZWRlcmFsIGdvdmVybm1lbnQgSVB2NiB0cmFuc2l0aW9uLiBEZXNwaXRlDQp0aGUgbWFu ZGF0ZWQgZGF0ZXMsIHByb2dyZXNzIHdpbGwgYWxtb3N0IGNlcnRhaW5seSBjb250aW51ZSB0byBi ZSB1bmV2ZW4gYWNyb3NzIGFnZW5jaWVzLg0KQnV0IHRoZSByZXBvcnRpbmcgcmVxdWlyZW1lbnRz IGFyZSBzb21ldGhpbmcgb2YgYSBzdGljay4gQ29tcGxpYW5jZSB3aXRoDQpyZWd1bGF0aW9ucyBh bmQgb3RoZXIgcmVxdWlyZW1lbnRzIHRlbmRzIHRvIGJlIG9uZSBvZiB0aGUgZHJpdmVycw0KaW4g Z292ZXJubWVudCBkZWNpc2lvbi1tYWtpbmcsIGVzcGVjaWFsbHkgc2luY2UgcHJvZml0IGlzIG5v dCBub3JtYWxseQ0KdGhlIGZhY3RvciBpdCBpcyBpbiBjb21tZXJjaWFsIGRlY2lzaW9uLW1ha2lu Zy4NCg0KU2NvdHQNCg0K From nobody Tue Mar 10 13:47:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB963A0D21 for ; Tue, 10 Mar 2020 13:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ea28IBn3E1y for ; Tue, 10 Mar 2020 13:47:25 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id CC9C93A0D11 for ; Tue, 10 Mar 2020 13:47:24 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02AKlMUu1181753 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 13:47:22 -0700 From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CC342DE7-F32F-4597-A001-967E58039C4B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 10 Mar 2020 13:47:22 -0700 In-Reply-To: <4A5BDEE6-2B9E-4338-94C1-3BE9D6E37516@consulintel.es> Cc: v6ops To: JORDI PALET MARTINEZ References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <2020030818294834486735@chinatelecom.cn> <073925C4-5355-4C51-84A4-4D9545013552@delong.com> <4A5BDEE6-2B9E-4338-94C1-3BE9D6E37516@consulintel.es> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Tue, 10 Mar 2020 13:47:22 -0700 (PDT) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 20:47:37 -0000 --Apple-Mail=_CC342DE7-F32F-4597-A001-967E58039C4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 10, 2020, at 11:25 , JORDI PALET MARTINEZ = wrote: >=20 > Hi Owen, > =20 > Responses below with ***. > =20 > El 10/3/20 19:03, "v6ops en nombre de Owen DeLong" = en nombre de = owen@delong.com > escribi=C3=B3: > =20 > =20 >=20 >=20 >> On Mar 9, 2020, at 01:42 , JORDI PALET MARTINEZ = > wrote: >> =20 >> Hi Clark, >> =20 >> El 8/3/20 12:38, "v6ops en nombre de Clark Gaylord" = en nombre de = cgaylord@vt.edu > escribi=C3=B3: >> =20 >> It seems to me the context of the OMB guidance is relevant to the = question of "IPv6-only". The draft memo is reasonably good at this, but = succinctly something like "agency internal networks use single-stack = IPv6 with any=20 >> =20 >> [Jordi] I don=E2=80=99t think is so clear. Footnote 4 =E2=80=9CIPv6-Onl= y refers to network environments in which use of the IPv4 protocol has = been eliminated=E2=80=9D will be much clear if it says =E2=80=9CIPv6-Only = refers to network environments in which use of the *native* IPv4 = protocol has been eliminated=E2=80=9D. > =20 > I don=E2=80=99t believe that what you propose is the intent in the = memo. > =20 > I believe they intend to eliminate the use of ALL IPv4, not just = native IPv4 on government networks. > =20 > *** Then there is a problem. If they really want to have ALL the way = thru only IPv6 in the LANs, the federal employees will not be able to = use *ANY* application that uses literal addresses (even a simple web = page that is doing that). Because there is NO transition mechanism that = allows that. They are able to force all their internal apps to use only = IPv6, fine, but they have no control over the rest of the Internet. If = they are thinking that NAT64+DNS64 resolves that, they lost this = =E2=80=9Csmall=E2=80=9D bit in their thinking. I=E2=80=99ve already = reported them to the site that is asking for comments, hopefully they = really pay attention to the inputs. I don=E2=80=99t see that as a problem=E2=80=A6 I see that as a benefit. I think that the US Federal government is one of the few organizations = in a position to actually put the kind of pressure that will be = necessary to effectuate this change. So, personally, I don=E2=80=99t see it so much as =E2=80=9Cthey lost = this in their thinking=E2=80=9D as in they are choosing to stop = supporting certain =E2=80=9Cbroken by design=E2=80=9D ways of thinking. I hope that they stick to their guns and do not soften their position. > =20 >=20 >> If a Federal office decides to have its DC with IPv6-only, then = IPv4-only users will not be able to access it. In that case the DC must = use, for example SIIT-DC. That will mean that the DC (internally) is = IPv6-only, but the DC-to-Internet is dual-stack, in order to be able to = use SIIT-DC. > =20 > I believe that _IS_ the intent (no support for SIIT/NAT64/etc.). > =20 > Remember, this is referring to the INTERNAL networks of the federal = government agencies=E2=80=A6 Not the public-facing networks. > =20 > Unless I misread the memo, the intent is to preserve dual-stack = functionality on public-facing services, but ensure that there are no = remaining IPv4 dependencies in providing those services over IPv6. > =20 >> Furthermore, footnote 5, =E2=80=9CNote that for public Internet = services, maintaining viable IPv4 interfaces and transition mechanisms = at the edge of service infrastructure may be necessary for additional = time, but this does not preclude operating the backend infrastructure as = IPv6-only.=E2=80=9D Is precisely saying that. > =20 > Correct. > =20 >=20 >> It may happen that some of the LANs in the Federal office itself, are = dual-stack still. Otherwise, employees will not be able to use Internet = resources that don=E2=80=99t work well with NAT64+DNS64, for example, = web sites or apps that use literal IPv4-addresses and are out of the = control of the Federal office. So, in this case they still need to use = IPv4aaS. > =20 > That=E2=80=99s not the desired outcome in this process. > =20 > Indeed, my impression is that the government is, through this memo, = intending to put suppliers and web sites on notice that if they do not = have IPv6 accessibility they are likely to lose their government = customers. > =20 > I see that as a good thing. > =20 > *** I will be glad if they can send this memo to every small web site = in the world, because even if one of them is missing it, and need to be = accessed by the employees, will not work! I=E2=80=99m pretty sure that the employees that encounter difficulty = will make it known to the web sites in question. In reality, in terms of actual job-related usage, the federal government = is unlikely to need access to every small web site in the world. As a = general rule, every small web site in the world has no ability to = support things at the scale of US Government usage. If some employe can=E2=80=99t surf their favorite mom-and-pop cat video = site while they are supposed to be working for their taxpayer supported = salary, I won=E2=80=99t actually be upset. So from my perspective, this memo puts government contractors on notice = that their network-based systems providing services to the federal = government damn well better fully support IPv6 in the next few years, or = they=E2=80=99re going to experience an increasing level of disconnect = followed by a very likely contract termination. I see this as a good = thing. Owen --Apple-Mail=_CC342DE7-F32F-4597-A001-967E58039C4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 10, 2020, at 11:25 , JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> = wrote:

Hi Owen,
 
Responses below with ***.
 
El 10/3/20 19:03, "v6ops en nombre de = Owen DeLong" <v6ops-bounces@ietf.org en nombre de owen@delong.com> escribi=C3=B3:
 
 


On Mar 9, 2020, at 01:42 , JORDI PALET = MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> = wrote:
 
Hi Clark,
 
El 8/3/20 12:38, = "v6ops en nombre de Clark Gaylord" <v6ops-bounces@ietf.org en nombre de cgaylord@vt.edu> escribi=C3=B3:
 
It seems to me the context of the OMB = guidance is relevant to the question of "IPv6-only". The draft memo is = reasonably good at this, but succinctly something like "agency internal = networks use single-stack IPv6 with any 
 
[Jordi] I don=E2=80=99t think is so clear. Footnote 4 =E2=80=9CIPv6-Only refers to network environments in which = use of the IPv4 protocol has been eliminated=E2=80=9D will be much clear = if it says =E2=80=9CIPv6-Only refers to network environments in which = use of the *native* IPv4 protocol has been eliminated=E2=80=9D.
 
I don=E2=80=99t believe that what you propose is the intent = in the memo.
 
I believe they intend to eliminate the use of = ALL IPv4, not just native IPv4 on government networks.
 
*** = Then there is a problem. If they really want to have ALL the way thru = only IPv6 in the LANs, the federal employees will not be able to use *ANY* application that uses literal addresses (even a = simple web page that is doing that). Because there is NO transition = mechanism that allows that. They are able to force all their internal = apps to use only IPv6, fine, but they have no control over the rest of = the Internet. If they are thinking that NAT64+DNS64 resolves that, they = lost this =E2=80=9Csmall=E2=80=9D bit in their thinking. I=E2=80=99ve = already reported them to the site that is asking for comments, hopefully = they really pay attention to the = inputs.

I don=E2=80=99t see that as a problem=E2=80=A6 I see = that as a benefit.

I think that the = US Federal government is one of the few organizations in a position to = actually put the kind of pressure that will be necessary to effectuate = this change.

So, personally, I = don=E2=80=99t see it so much as =E2=80=9Cthey lost this in their = thinking=E2=80=9D as in they are choosing to stop supporting certain = =E2=80=9Cbroken by design=E2=80=9D ways of thinking.

I hope that they stick to their guns and do not = soften their position.

 

If a Federal office decides = to have its DC with IPv6-only, then IPv4-only users will not be able to = access it. In that case the DC must use, for example SIIT-DC. That will = mean that the DC (internally) is IPv6-only, but the DC-to-Internet is = dual-stack, in order to be able to use SIIT-DC.
 
I believe that _IS_ the intent (no support for = SIIT/NAT64/etc.).
 
Remember, this is referring to the INTERNAL = networks of the federal government agencies=E2=80=A6 Not the = public-facing networks.
 
Unless I misread the memo, the intent is to = preserve dual-stack functionality on public-facing services, but ensure = that there are no remaining IPv4 dependencies in providing those = services over IPv6.
 
Furthermore, footnote 5, = =E2=80=9CNote that for public Internet services, maintaining viable IPv4 = interfaces and transition mechanisms at the edge of service = infrastructure may be necessary for additional time, but this does not = preclude operating the backend infrastructure as IPv6-only.=E2=80=9D Is = precisely saying that.
 
Correct.
 

It may = happen that some of the LANs in the Federal office itself, are = dual-stack still. Otherwise, employees will not be able to use Internet = resources that don=E2=80=99t work well with NAT64+DNS64, for example, = web sites or apps that use literal IPv4-addresses and are out of the = control of the Federal office. So, in this case they still need to use = IPv4aaS.
 
That=E2=80=99s not the desired outcome in this process.
 
Indeed, my impression is that the = government is, through this memo, intending to put suppliers and web = sites on notice that if they do not have IPv6 accessibility they are = likely to lose their government customers.
 
I see that as a good thing.
 
*** I will be glad = if they can send this memo to every small web site in the world, because = even if one of them is missing it, and need to be accessed by the = employees, will not = work!

I=E2=80=99m pretty sure that the employees that = encounter difficulty will make it known to the web sites in = question.

In reality, in terms of = actual job-related usage, the federal government is unlikely to need = access to every small web site in the world. As a general rule, every = small web site in the world has no ability to support things at the = scale of US Government usage.

If = some employe can=E2=80=99t surf their favorite mom-and-pop cat video = site while they are supposed to be working for their taxpayer supported = salary, I won=E2=80=99t actually be upset.

So from my perspective, this memo puts government = contractors on notice that their network-based systems providing = services to the federal government damn well better fully support IPv6 = in the next few years, or they=E2=80=99re going to experience an = increasing level of disconnect followed by a very likely contract = termination. I see this as a good thing.

Owen

= --Apple-Mail=_CC342DE7-F32F-4597-A001-967E58039C4B-- From nobody Tue Mar 10 13:49:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930473A0DB6 for ; Tue, 10 Mar 2020 13:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lob3hdbE50nW for ; Tue, 10 Mar 2020 13:48:58 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87403A0D9B for ; Tue, 10 Mar 2020 13:48:56 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id 25so2947006wmk.3 for ; Tue, 10 Mar 2020 13:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=hfNhga4dC8KGGWknE3QeV1WoFt8lUYkaeEjXRwRFBpY=; b=Mb+JqH5oe+CFjGl5891N9FrkXp0XhGeB20mhmEh5e/3rX7P+FU3L+bdNL629Hu/j5F +5dq+ulCrQ/RBXOMeewnvDh0/Gv5I3zIkjoEDVBfiyaf1zv/ekdQdWKnVnvzDIDofFo4 AbrPAVKIYli4UfI70gHFWOu3a7/ZOwaKcamPonsVuaF5gKhg4L3R70oUDBROF8Tp/VVS GUeAvHRdH2FgA1udFSRmxcLDheDksEndgdrJpvhq5sTmwCmF0V7i6GNF3CzlcfSIn6Ij i6JuFtopLz2j6k2ycSsIwYbJURmratbj9kk2v3VmOaLk1eO41U0pe6yGcbHnQaLh4ugb uvlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=hfNhga4dC8KGGWknE3QeV1WoFt8lUYkaeEjXRwRFBpY=; b=M9bKkrawJuZXkSJzTC/xQYRpgxggREH0DJ6euIshO+yvlTbAhyiSp2P81vMQZ8pUUt bnOv/MN9Zll1KZhoU/o/NTQ2R+kWbbW7tk5GK02di5TYNFW/1/cA6ZLwUSNlsLQZs6vB DuJYKz+oyqD7p6IPKOde7uN9MXDkTEXkWBmL8ClMWFxFTEqpZ6i60K+HCG1ukCjclAEf /vqFjeaIBjTgWCFFd6mFEaDgBTkk3RBkuDCx1XVhEenAn9jlQ6IPyt0zU7AzJEiXTya7 2gQmd+QwccqoXQEykUb4cO4WtHBjFqPPNYYTyfQyLHCTesp8sAEmiufUI63/qIH860tr fjrQ== X-Gm-Message-State: ANhLgQ2zNplOlEgiw1Y1q5DT9t8f+qF2f486rZA4D7fkfw7LBKFSJna7 4QkykUPyHtxrFv/zuFYlgUB47s6x X-Google-Smtp-Source: ADFU+vsWUbZGGIr8iYSB5EK+kUX0u3jrEyb02INHCUih3K8hnjf9w0mrdSa4XJ8u5ZDNJ8k46wwquA== X-Received: by 2002:a1c:2856:: with SMTP id o83mr3755718wmo.157.1583873334789; Tue, 10 Mar 2020 13:48:54 -0700 (PDT) Received: from ?IPv6:2600:8802:5900:13c4::1030? ([2600:8802:5900:13c4::1030]) by smtp.gmail.com with ESMTPSA id c124sm5771977wma.10.2020.03.10.13.48.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2020 13:48:53 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_03A77828-E0B6-4A2B-B4E1-6382118D7553"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.1\)) Message-Id: References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> To: "v6ops@ietf.org list" Date: Tue, 10 Mar 2020 13:48:51 -0700 X-Mailer: Apple Mail (2.3608.80.23.2.1) Archived-At: Subject: [v6ops] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 20:49:06 -0000 --Apple-Mail=_03A77828-E0B6-4A2B-B4E1-6382118D7553 Content-Type: multipart/mixed; boundary="Apple-Mail=_B1C16E81-F5D0-4422-9EAD-8B286DA1308B" --Apple-Mail=_B1C16E81-F5D0-4422-9EAD-8B286DA1308B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For those of you who haven't yet seen this, cancel your flights to = Vancouver and your hotel rooms. Stay tuned for information regarding = refunding of registrations (watch IETF-Announce) Ron and I plan to discuss the agenda for the in-person meeting (which = won't happen) tomorrow. Let me ask a question - one that I have not = discussed with him yet. In liu of a virtual meeting, what would you think about doing last calls = on the list for - draft-ietf-v6ops-464xlat-optimization-00.txt - draft-ietf-v6ops-cpe-slaac-renum-01.txt - draft-ietf-v6ops-nd-cache-init-01.txt - draft-ietf-v6ops-slaac-renum-01.txt - draft-ietf-dhc-v6only-00.txt These would each be two weeks long, starting March 30, and ask basically = two questions - "what further edits do you think are required", and "is = it ready to get sent in? We would likely follow those by asking for comments on = draft-palet-v6ops-ipv6-only, which is a draft Jordi kicked around last = year and has recently reposted with minor changes = (https://tools.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops-ipv6-only-05.txt)= . draft-ietf-dhc-v6only-00.txt is actually a DHC draft, but Jen and the = DHC chairs would like v6ops commentary. > Begin forwarded message: >=20 > From: The IESG > Subject: IETF 107 Vancouver In-Person Meeting Cancelled > Date: March 10, 2020 at 12:10:27 PM PDT > To: "IETF Announcement List" > Cc: irtf-announce@irtf.org, ietf@ietf.org, 107all@ietf.org > Reply-To: iesg@ietf.org >=20 > The IESG and the IRTF Chair have decided to cancel the in-person IETF = 107 Vancouver meeting. This decision is based on input we gathered from = Working Group (WG) and Research Group (RG) chairs about our ability to = hold productive WG and RG sessions at IETF 107. Our assessment of this = feedback is that a majority of sessions would not be viable if we were = to hold the in-person IETF meeting. On this basis, we believe we cannot = hold an effective in-person meeting. >=20 > As a result of this cancellation, the in-person Hackathon, Code = Sprint, all other in-person events planned for the weekend of March = 21-22, the chairs training scheduled for March 20, and all other = in-person sessions during the week are cancelled. >=20 > The IESG is working on an alternative all-virtual agenda for the week = of March 21-27 with a limited schedule adapted to accommodate the time = zones of as many participants as possible. We are also planning to = support an increased volume of virtual interim meetings during the weeks = that follow. We will send another update to the community soon with more = information about these plans. The Hackathon organizers are also = considering plans for virtual Hackathon support. >=20 > We have re-opened Internet-Draft submissions, which had been closed on = March 9 in anticipation of the in-person meeting. Internet-Drafts may be = submitted at . >=20 > A separate announcement from the IETF Executive Director will follow = with details about registration cancellations and refunds. >=20 > These are unusual times given the circumstances created by the spread = of COVID-19. We hope that everyone remains safe and healthy. >=20 > Regards, > The IESG and the IRTF Chair >=20 --Apple-Mail=_B1C16E81-F5D0-4422-9EAD-8B286DA1308B Content-Disposition: attachment; filename=raw-agenda-data-v6ops.html Content-Type: text/html; x-unix-mode=0644; name="raw-agenda-data-v6ops.html" Content-Transfer-Encoding: 7bit IETF Working Group Agenda Analysis

This document describes the drafts associated with this group. It describes their current state as seen by the RFC Editor, IESG/AD, and the working or research group. For working group drafts and individual submissions, it also indicates whether the draft has been updated since the previous IETF meeting. Drafts that are new or have been updated are "current"; other drafts are "old".

On each draft, there are three or four links:

  • the relevant datatracker link,
  • a pointer to the HTML version of the draft in the tools directory,
  • a pointer to the email archived on IETF mailing lists related to the draft, and
  • a pointer to RFCDIFF against the previous version, if there was one.

WG: Updated WG Document

Individual Submission: Unupdated

Individual Submission: Updated

The charter for this group is at https://datatracker.ietf.org/group/v6ops/about/

Tue Mar 10 08:56:46 2020

--Apple-Mail=_B1C16E81-F5D0-4422-9EAD-8B286DA1308B-- --Apple-Mail=_03A77828-E0B6-4A2B-B4E1-6382118D7553 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl5n/TMACgkQEhdRnd2G P+BnrBAApeyAf/sZvWRBzHs8XmI9N69X7u9ioaRxh/DVELZdvONViR/RF7NmiIdO 7sUnCzNibFgSmH3xtDckrw83P8ULUtZFWouRKC9HUD23FIiCYmoqJFDfvEmfxjWj /50d2XM305M8avPDDyX+h/X+55ow6yi5XR5dGu1qwOyJbqRYEzFkZViQDWfyRbNK avCxT6e7j5090aiIMyFp5FhqzPYCnVVzcvpb1BkHQSxxFQlaBJ1Xx5CP5Bs/HGI2 NTaVAQLdJ2gHAYv5Z7Ijp/kQNxN19COpSzG/A21nZchMPgxR/ganM6nlSsCNuBro 3RqwlfCpZ7T1czOaRPpiI7QdeTX0gEgelQt4CGUv0D5ypRZChfljG5d2wkWtjGN3 VAtwkGuQ4fxIDmcjMSYdPoomkEn+PXoplbbTXFx60HcFdubjB5Or3+6w414wny9O dOq1J/u7kLF1vfyeOjHtatDHGCStrTJiHyytLtvyD34HiEXJNzz7qjoXaj+n/fr8 bhEt6s79cYSIkorbU/jcq6gejyjqtoHU4hPLmUypzcODT5pWHyAdVqZHG27LKJw7 A+lDAyxBIISnk3S/cO0dXbhU2MPndIgQz3IJleJ5uP9AZT5n8CKB73eb11HPMEaw kaju/s6BzSnc8FlRpAXvjc1uDDSLSVEj79ZW20HVbcE9BJLakLQ= =HrJD -----END PGP SIGNATURE----- --Apple-Mail=_03A77828-E0B6-4A2B-B4E1-6382118D7553-- From nobody Tue Mar 10 18:03:54 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AD43A0D36 for ; Tue, 10 Mar 2020 18:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1XTk-6yfcrO for ; Tue, 10 Mar 2020 18:03:48 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id 82CC13A0A8E for ; Tue, 10 Mar 2020 18:03:46 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:38952.1959139601 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-123.119.46.237?logid-CE56A36FA61F438BA08C7334CDCCF3F1 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id 64202280145; Wed, 11 Mar 2020 09:03:42 +0800 (CST) X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id CE56A36FA61F438BA08C7334CDCCF3F1 for jordi.palet=40consulintel.es@dmarc.ietf.org; Wed Mar 11 09:03:45 2020 X-Transaction-ID: CE56A36FA61F438BA08C7334CDCCF3F1 X-filter-score: filter<0> X-Real-From: xiechf@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Date: Wed, 11 Mar 2020 09:03:40 +0800 From: "xiechf@chinatelecom.cn" To: "JORDI PALET MARTINEZ" , v6ops References: , <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com>, <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es>, , <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov>, <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com>, <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com>, , <2020030818294834486735@chinatelecom.cn>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.14.409[cn] Mime-Version: 1.0 Message-ID: <2020031109031648115517@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart577658781173_=----" Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 01:03:52 -0000 This is a multi-part message in MIME format. ------=_001_NextPart577658781173_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIEpvcmRpLA0KVGhhbmsgeW91IGZvciB5b3VyIGNvbnNpZGVyYXRpb24gb2YgbXkgY29tbWVu dHMuIFBsZWFzZSBmaW5kIG15IG5ldyBub3RlcyBpbi1saW5lIGJlbG93Lg0KIA0KRnJvbTogSk9S REkgUEFMRVQgTUFSVElORVoNCkRhdGU6IDIwMjAtMDMtMDkgMTY6MzINClRvOiB2Nm9wcw0KU3Vi amVjdDogUmU6IFt2Nm9wc10gQWJvdXQgUmVxIGZvciBDb21tZW50cyAtICJUcmFuc2l0aW9uIHRv IElQdjYiDQpIaSBDaG9uZ2ZlbmcsDQogDQpUaGFua3MgZm9yIHlvdXIgaW5wdXRzIQ0KIA0KQmVs b3csIGluLWxpbmUg4oCmDQogDQogDQogDQpFbCA4LzMvMjAgMTE6MzEsICJ2Nm9wcyBlbiBub21i cmUgZGUgeGllY2hmQGNoaW5hdGVsZWNvbS5jbiIgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgZW4g bm9tYnJlIGRlIHhpZWNoZkBjaGluYXRlbGVjb20uY24+IGVzY3JpYmnDszoNCiANCkhpLCBKb3Jk aSwgDQpGaXJzdCAsIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgZGVmaW5pdGlvbiBvZiBJUHY2 LW9ubHkgbmVlZHMgdG8gY29uc2lkZXIgdGhlIHdoYXQgcGFydCBvZiB0aGUgbmV0d29yayB3ZSBh cmUgcmVmZXJyaW5nIHRvLCBmb3IgZXhhbXBsZSwgSVNQIG5ldHdvcmssIElEQywgQ2xvdWQgcGxh dGZvcm0gYW5kIFNlcnZpY2Ugc3lzdGVtIHNob3VsZCBoYXZlIHRoZWlyIG93biBzcGVjaWZpYyBk ZWZpbml0aW9uIG9mIElQdjYtb25seS4gIEkgaG9wZSB0aGlzIGRyYWZ0IGNhbiBnbyBvbi4NClNl Y29uZGx5LiBmb3IgSVNQIG5ldHdvcmssIHRoZSBkZWZpbml0aW9uIG9mIElQdjYgc2hvdWxkIGJl IGJhc2VkIG9uIHdoZXRoZXIgaXQgY2FuIGFsbG9jYXRlcyBvbmx5IElQdjYgDQogDQpbSm9yZGld IEkgZG9u4oCZdCBhZ3JlZSBvbiB0aGlzIHBvaW50LiBBbiBJU1AgbWF5IGhhdmUgZGlmZmVyZW50 IHBhcnRzIG9mIGl0cyBuZXR3b3JrIHdpdGggb3Igd2l0aG91dCBJUHY2L0lQdjQsIGV2ZW4gZGlm ZmVyZW50IHNlcnZpY2VzLCBzbyBJIGRvbuKAmXQgdGhpbmsgaXQgY2FuIGJlIHNwbGl0IHRoYXQg d2F5Lg0KIA0KYWRkcmVzc2VzIHRvIG1vc3Qgb2YgaXRzIGN1c3RvbWVycyBmb3Igc2VydmljZSBw cm92aXNpb25pbmcsIGlmIHllcywgaXQgY2FuIGJlIGNvbnNpZGVyIGFzIElQdjYtb25seS4gSWYg aXQNCiANCltKb3JkaV0gTm93LCB0aGUgcGFydCB5b3UgbWVudGlvbiBhcyBpZiBpdCBpcyBhbGxv Y2F0aW5nIG9ubHkgSVB2NiBhZGRyZXNzZXMsIGlzIGFsc28gbm90IHZhbGlkLCBpbiBteSBvcGlu aW9uLiBCZWNhdXNlIGluIHNvbWUgb2YgdGhlIElQdjYtb25seSB3aXRoIElQdjRhYVMsIHRoZSBJ U1AgYWxsb2NhdGUgcHJpdmF0ZSBJUHY0IGFkZHJlc3Nlcy4NCg0KW0Nob25nZmVuZ10gSWYgSVNQ IGFsbG9jYXRlcyBJUHY0IHByaXZhdGUgYWRkcmVzcyB0byAgbGFyZ2UgcXVhdGl0eSBvZiBpdHMg Y3VzdG9tZXJzLCBpdCBzaG91bGQgbm90IGJlIGNvbnNpZGVyZWQgYXMgSVB2Ni1vbmx5LCB0aGlz IHNob3VsZCBiZSB0aGUgYm90dG9tIGxpbmUuDQogDQphbGxvY2F0ZXMgSVB2NCBhZGRyZXNzIHRv IG1vc3Qgb2YgaXRzIGN1c3RvbWVycywgdGhlbiBpdCBpcyBub3QgSVB2Ni1vbmx5LiBNeSBwZXJz b25hbCBvcGlvbmlvbiBpcyB0aGF0IHRoZSBkZWZpbml0aW9uIHNob3VsZCBub3QgYmUgYmFzZWQg b24gd2hldGhlciB0byBlbGltaW5hdGUgSVB2NCBwcm90b2NvbCBpbiB0aGUgbmV0d29yay4gIEF0 IHByZXNlbnQgc3RhZ2UsIGl0IGlzIHVucmVhbGlzdGljIHRvIGVsaW1pbmF0ZSBJUHY0IHByb3Rv Y29sIGluIG1vc3QgbmV0d29ya3MsIGZvciB0aGUgbmV0d29ya3Mgc3RpbGwgbmVlZCB0byBwcm92 aWRlIGFjY2VzcyBzZXJ2aWNlIHRvIHNvbWUgY3VzdG9tZXJzIHdobyBkbyBub3Qgc3VwcG9ydCBJ UHY2LW9ubHkgZHVlIHRvIHRoZWlyIHBvb3ItY2FwYWJpbGl0eSBDUEUgb3IgdGVybWluYWxzLg0K IA0KW0pvcmRpXSBJIGFncmVlIGlzIHVucmVhbGlzdGljIHRvIGRpc2FibGUgSVB2NCBpbiBtb3N0 IG9mIHRoZSBjdXN0b21lciBMQU5zLCBidXQgbm90IGluIHRoZSBhY2Nlc3MgbmV0d29yay4gVW50 aWwgOTAtOTklIG9mIHRoZSBob21lIGRldmljZXMgb2YgYW4gSVNQIGN1c3RvbWVycyBoYXZlIElQ djYgaW4gdGhlaXIgTEFOIGRldmljZXMsIGFuIElQdjYgd2l0aCBJUHY0YWFTIGlzIG5lZWRlZC4N CltDaG9uZ2ZlbmddICBJbiBDaGluYSwgYWNjZXNzIG5ldHdvcmsgYWRvcHRzICBsYXllci10d28g YXBwcm9hY2gsIGl0IGlzIGluZGVwZW5kZW50IHRvIGxheWVyLXRocmVlIHByb2NvdG9scy4gSXQg c2VlbXMgdG8gbXVjaCBtb3JlIGRpZmZpY3VsdCAgdG8gbWFrZSB0cmFuc2l0aW9uIHRvIElQdjYg aW4gd2lyZWxpbmUgYnJvYWRiYW5kIG5ldHdvcmssIGR1ZSB0byB0aGUgc2xvdyB1cGdyYWRhdGlv biBvZiBob21lIHJvdXRlcnMuDQogDQpNb3JlZXZlciwgc29tZSBuZXR3b3JrcyBzdGlsbCBuZWVk IHRvIHVzZSBJUHY0IGZvciBuZXR3b3JrIG1hbmFnZW1lbnQgLiBJZiB0aGUgZGVmaW5pdGlvbiBp dCB0b28gc3RyaWN0LCBJIGd1ZXNzIG5vbmUgb2YgdGhlIG5ldHdvcmsgY2FuIG1lZXQgdGhlIHN0 YW5kYXJkLCBpbmNsdWRpbmcgdGhvc2Ugd2hvIGhhdmUgZGVwbHllZCA0NjRYTEFULiBJbiBhZGRp dGlvbiwgYW4gSVB2Ni1vbmx5IG5ldHdvcmsgc2hvdWxkIGJlIG9wZW4gYW5kIGludGVyY29ubmVj dGVkIHdpdGggT1RUcyBhbmQgb3RoZXIgSVNQcywgc29tZSBjbG9zZWQgc3lzdGVtLCBzdWNoIGFz IFZvTFRFIGluIG1vYmlsZSBuZXR3b3JrLCBzaG91bGQgbm90IGJlIGNvbnNpZGVyIGFzIElQdjYt b25seSwgZXZlbiB0aG91Z2ggaXQgb25seSBhbGxvY2F0ZXMgSVB2NiBhZGRyZXNzZXMgdG8gaXQg Y3VzdG9tZXIuDQogDQpbSm9yZGldIElmIElQdjQgaXMgdXNlZCBmb3IgbWFuYWdlbWVudCBpbiB0 aGUgYWNjZXNzIG5ldHdvcmsgYW5kIHByb3ZpZGVzIG5hdGl2ZSBJUHY0IHRvIHRoZSBDRSAoZm9y IGV4YW1wbGUpLCB0aGVuIGl0IGlzIG5vdCBJUHY2LW9ubHkuIFdlIGNvdWxkIHNheSBpbiB0aGF0 IGNhc2U6IFRoaXMgYWNjZXNzIG5ldHdvcmsgaXMgSVB2Ni1vbmx5IGZvciB0aGUgY3VzdG9tZXIg c2VydmljZSwgYnV0IHN0aWxsIElQdjQtb25seSBvciBkdWFsLXN0YWNrIGZvciB0aGUgbWFuYWdl bWVudC4NCiANCltKb3JkaV0gU28gSSBzdGlsbCBiZWxpZXZlIHRoYXQgdGhlIOKAnG5hdHVyZeKA nSBvZiB0aGUgZGVmaW5pdGlvbiBzaG91bGQgYmUgYmFzZWQgaW4gaWYgSVB2NCBpcyB1c2VkIG5h dGl2ZWx5IGluIGEgc3BlY2lmaWMgcGFydCBvZiBhIG5ldHdvcmsgKHRoZW4gaXQgaXMgSVB2Ni1v bmx5KSBvciBvdGhlcndpc2UgaXMgSVB2NC1vbmx5IG9yIGR1YWwtc3RhY2suIFdoYXQgZG8geW91 IHRoaW5rPw0KIFtDaG9uZ2ZlbmddIEluIGdlbmVyYWwsIEkgYWdyZWUgd2l0aCB0aGlzIHBvaW50 Lg0KIA0KIA0KQmVzdCByZWdhcmRzDQpDaG9uZ2ZlbmcgDQogDQpGcm9tOiBKT1JESSBQQUxFVCBN QVJUSU5FWg0KRGF0ZTogMjAyMC0wMy0wNiAwMjoxMg0KVG86IHY2b3BzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3Y2b3BzXSBBYm91dCBSZXEgZm9yIENvbW1lbnRzIC0gIlRyYW5zaXRpb24gdG8g SVB2NiINCklmIHlvdSByZWFkIG15IGRyYWZ0LCBteSBvcGluaW9uIGlzIGRpZmZlcmVudDoNCiAN CiAgRGVmaW5pdGlvbiBvZiBJUHY2LW9ubHkNCiANCiAgIENvbnNlcXVlbnRseSwgY29uc2lkZXJp bmcgdGhlIGNvbnRleHQgZGVzY3JpYmVkIGluIHRoZSBzZWN0aW9uIGFib3ZlLA0KICAgaWYgd2Ug d2FudCB0byBiZSBwcmVjaXNlIGFuZCBhdm9pZCBjb25mdXNpbmcgb3RoZXJzLCB3ZSBjYW4gbm90 IHVzZQ0KICAgdGhlIHRlcm1pbm9sb2d5ICJJUHY2LW9ubHkiIGluIGEgZ2VuZXJpYyB3YXksIGFu ZCB3ZSBuZWVkIHRvIGRlZmluZQ0KICAgd2hhdCBwYXJ0IG9mIHRoZSBuZXR3b3JrIHdlIGFyZSBy ZWZlcnJpbmcgdG8uDQogDQogICBGcm9tIHRoYXQgcGVyc3BlY3RpdmUsIHdlIGRlZmluZSB0aGUg IklQdjYtb25seSIgc3RhdHVzIGluIGEgZ2l2ZW4NCiAgIHBhcnQocykgb2YgYSBuZXR3b3JrLCBk ZXBlbmRpbmcgb24gaWYgdGhlcmUgaXMgYWN0dWFsIG5hdGl2ZQ0KICAgZm9yd2FyZGluZyBvZiBJ UHY0LCBzbyBJUHY0IGlzIG5vdCBjb25maWd1cmVkIG5laXRoZXIgbWFuYWdlZC4NCiANClNvIElQ djQgbWF5IGJlIG5vdCBjb25maWd1cmVkLCBvciBub3QgdXNlZCBuYXRpdmVseSwgYnV0IHRoZXJl IGlzIG5vIHdheSB0byBwcmV2ZW50IHRoYXQgImlzIHRoZXJlIiBieSBtZWFucyBvZiB0dW5uZWxp bmcgb2YgdHJhbnNsYXRpb24uDQogDQoqdW5sZXNzKiB5b3UgbWFrZSBzdXJlIHRoYXQgYW55IGVu Y2Fwc3VsYXRpb24gb3IgdHJhbnNsYXRpb24gaXMgZmlsdGVyZWQsIHdoaWNoIGlzIGNsb3NlIHRv IGltcG9zc2libGUuDQogDQpCZWNhdXNlIHdlIGRpc2FncmVlLCBpdCBzZWVtcyBjbGVhciB0aGF0 IHRoaXMgZG9jdW1lbnQgaXMgbmVlZGVkLg0KIA0KU28gaWYgYW55b25lIGhhcyBpbnB1dHMsIEkg d2lsbCBjb25zaWRlciB0aGVtIGluIGEgbmV3IHZlcnNpb24gZHVyaW5nIHRoZSB3ZWVrZW5kLg0K IA0KUmVnYXJkcywNCkpvcmRpDQpAam9yZGlwYWxldA0KIA0K77u/RWwgNS8zLzIwIDE3OjQ2LCAi djZvcHMgZW4gbm9tYnJlIGRlIE93ZW4gRGVMb25nIiA8djZvcHMtYm91bmNlc0BpZXRmLm9yZyBl biBub21icmUgZGUgb3dlbkBkZWxvbmcuY29tPiBlc2NyaWJpw7M6DQogDQogICAgDQogICAgDQog ICAgPiBPbiBNYXIgNSwgMjAyMCwgYXQgNjowMiBBTSwgQWxleGFuZHJlIFBldHJlc2N1IDxhbGV4 YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gVGhhbmsgeW91 IHZlcnkgbXVjaCBmb3IgdGhlIHBvaW50ZXIuICBJbiBpdCBJIGNvdWxkIHNwb3QNCiAgICA+IHRo ZSBmb2xsb3dpbmcgZm9vdG5vdGU6ICJbNF0gSVB2Ni1Pbmx5IHJlZmVycyB0byBuZXR3b3JrIGVu dmlyb25tZW50cyBpbg0KICAgID4gd2hpY2ggdXNlIG9mIHRoZSBJUHY0IHByb3RvY29sIGhhcyBi ZWVuIGVsaW1pbmF0ZWQu4oCdDQogICAgDQogICAgTm8uDQogICAgDQogICAgSVB2Ni1Pbmx5IHJl ZmVycyB0byBuZXR3b3JrIGVudmlyb25tZW50cyB3aGljaCBhcmUgbm90IHVzaW5nIElQdjQuIFRo YXQgY291bGQgYmUgYSBuZXR3b3JrIHdoZXJlIElQdjQgaGFzIGJlZW4gZWxpbWluYXRlZCAocmFy ZSBhdCB0aGlzIHRpbWUsIHRob3VnaCBGYWNlYm9vayBpcyBhIHNpZ25pZmljYW50IGV4YW1wbGUp IG9yIGl0IGNvdWxkIGJlIGEgZ3JlZW5maWVsZCBkZXBsb3ltZW50IHdoZXJlIElQdjQgd2FzIG5l dmVyIGRlcGxveWVkLg0KICAgIA0KICAgID4gDQogICAgPiBJbiBteSBodW1ibGUgb3BpbmlvbiwN CiAgICA+IA0KICAgID4gSSB0aGluaywgaWYgSSBhbSBub3Qgd3JvbmcsIHRoYXQgdGhlcmUgYXJl IG5vIHN1Y2ggbmV0d29ya3MgaW4gd2hpY2gNCiAgICA+IElQdjQgcHJvdG9jb2wgaGFzIGJlZW4g ZWxpbWluYXRlZC4gIE9uIG9uZSBoYW5kLCBhIG5ldHdvcmsgaXMgbWFkZSBvZg0KICAgID4gY29t cHV0ZXJzLCBhbmQgSVB2NCBzdGFja3MgYXJlIHN0aWxsIHByZXNlbnQgaW4gYWxtb3N0IGFsbCBj b21wdXRlcnMuDQogICAgPiBPbiBhbm90aGVyIGhhbmQsIHRoZXJlIG1pZ2h0IGJlIHNvbWUgcHRw IGxpbmtzIChub3QgbmV0d29ya3MsIGJ1dA0KICAgID4gaW5kaXZpZHVhbCBsaW5rcykgdGhhdCBy dW4gSVB2NiBvbmx5Lg0KICAgIA0KICAgIFlvdSBhcmUgd3JvbmfigKYgVGhlcmUgYXJlIGV4YW1w bGVzIGF0IHZhcmlvdXMgbGV2ZWxzIG9mIElQdjYtb25seSBuZXR3b3Jrcy4gTWFueSBtb2JpbGUg Y2FycmllcnMgYXJlIElQdjYtb25seSBpbiB0aGUgVVMsIHRob3VnaCB0aGV5IGRvIHByb3ZpZGUg c29tZSBhcHBhcmVudCBJUHY0IGNhcGFiaWxpdHkgdG8gdGhlIGVuZCB1c2VyIHRocm91Z2ggbWVj aGFuaXNtcyBzdWNoIGFzIDQ2NFhMQVQgYW5kL29yIE5BVDY0Lg0KICAgIA0KICAgIEFub3RoZXIg c2lnbmlmaWNhbnQgZXhhbXBsZSBpcyBGYWNlYm9vayB3aGVyZSB0aGV5IGFyZSBlc3NlbnRpYWxs eSBJUHY2LW9ubHkgdGhyb3VnaG91dCB0aGVpciBuZXR3b3JrIGFuZCBwcm92aWRlIG1pbmltYWwg SVB2NCB0cmFuc2xhdGlvbiBzaGltIGF0IHRoZSBlZGdlIHRvIGNvcGUgd2l0aCBlbmQgdXNlcnMg dGhhdCBsYWNrIElQdjYgY2FwYWJpbGl0eS4NCiAgICANCiAgICA+IFRoYXQgaXMgd2h5IGl0IGlz IGhhcmQgdG8gYWdyZWUgb24gdGhlIGFzc3VtcHRpb24gb2YgSVB2NCBiZWluZyBlbGltaW5hdGVk IHNvbWV3aGVyZS4gIFdvcnNlLCBpdCBtYWtlcyBsb29rIGFzIGlmIHRoZSBnb2FsIG9mIHRoYXQg J0lQdjYtb25seScgaXMgdG8gYXJyaXZlIGF0IHRoYXQgc2FtZSBzaXR1YXRpb24gd2hpY2ggaW4g ZmFjdCBkb2VzIHVzZSBJUHY0Lg0KICAgIA0KICAgIEFzIGEgZ2VuZXJhbCBydWxlLCBvbmNlIElQ djYgaXMgdWJpcXVpdG91c2x5IGRlcGxveWVkIGluIGEgbmV0d29yaywgdGhlIHByZXNlcnZhdGlv biBvZiBJUHY0IGluIHRoZSBtYWpvcml0eSBvZiB0aGF0IG5ldHdvcmsgYmVjb21lcyBhbiB1bm5l Y2Vzc2FyeSBjb3N0IGZhY3RvciBhbmQgYSBzZWN1cml0eSByaXNrIChpbmNyZWFzZWQgYXR0YWNr IHN1cmZhY2UsIGlmIG5vdGhpbmcgZWxzZSkuIEFzIHN1Y2gsIEkgdGhpbmsgeW91IHdpbGwgc2Vl IGFuIGluY3JlYXNpbmcgbnVtYmVyIG9mIG9yZ2FuaXphdGlvbnMgZm9sbG93IG9uIHRvIHRoZSB3 YXkgRmFjZWJvb2sgaGFzIG1hbmFnZWQgdGhlaXIgdHJhbnNpdGlvbiBhbmQgc3RhcnQgZWxpbWlu YXRpbmcgSVB2NCB3aGVyZXZlciBwb3NzaWJsZSBhbmQgcmVwbGFjaW5nIGl0IHdpdGggdHJhbnNs YXRpb24gc2hpbXMgYXMgZmFyIG91dCB0b3dhcmRzIHRoZSBib3JkZXIgYXMgcHJhY3RpY2FsLg0K ICAgIA0KICAgIE93ZW4NCiAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KICAgIHY2b3Bz QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0KICAgIA0KIA0KIA0KIA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KSVB2NCBpcyBvdmVyDQpBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0 ID8NCmh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tDQpUaGUgSVB2NiBDb21wYW55DQogDQpU aGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUg cHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0 byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJv dmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5 aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0 aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNl Li4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFu eSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50 cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFj aGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBj cmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVy IHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCiANCiAN CiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9w cyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyB2Nm9wcyBtYWlsaW5nIGxpc3QgdjZvcHNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyANCg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0KSVB2NCBpcyBvdmVyDQpBcmUgeW91IHJlYWR5IGZv ciB0aGUgbmV3IEludGVybmV0ID8NCmh0dHA6Ly93d3cudGhlaXB2NmNvbXBhbnkuY29tDQpUaGUg SVB2NiBDb21wYW55DQoNClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0 aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0 aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVk IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRz IG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNo ZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZCBh IGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg YmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVz ZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHks IGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2lsbCBi ZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhl IG9yaWdpbmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBk ZWxldGUgaXQuDQoNCg== ------=_001_NextPart577658781173_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Hi, Jordi,
Thank you for yo= ur consideration of my comments. Please find my new notes in-line below.
 
=
Date: 2020-03-09 16:32
To: v6ops
Subject: Re: = [v6ops] About Req for Comments - "Transition to IPv6"
=0A

Hi Chongfeng,

 <= /p>

Thanks for your inputs!

 

Below, in-line =E2=80=A6

 

&= nbsp;

 =

El 8/3/20 11:31, "v6ops en nombre= de xiechf@chinatelecom.cn" <= v6ops-bounces@ietf.org en nombre de xiechf@chinatel= ecom.cn> escribi=C3=B3:

 

Hi, Jordi, 

First , I agree with you that the definition of IPv6-only ne= eds to consider the what part of the network we are referring to, for= example, ISP network, IDC, Cloud platform and Service system should have = their own specific definition of IPv6-only.  I hope this draft can go= on.

Secondly. for ISP network, the definition of IPv6 s= hould be based on whether it can allocates only IPv6

 

[Jordi] I don=E2=80=99t agree on this point. An ISP may ha= ve different parts of its network with or without IPv6/IPv4, even differen= t services, so I don=E2=80=99t think it can be split that way.<= /span>

 

addresses to most of its customers= for service provisioning, if yes, it can be consider as IPv6-only. If it<= o:p>

 

[Jordi] Now, the part y= ou mention as if it is allocating only IPv6 addresses, is also not valid, = in my opinion. Because in some of the IPv6-only with IPv4aaS, the ISP allo= cate private IPv4 addresses.


[Chongfeng] If ISP allocates IPv4 private address to&n= bsp; large quatity of=  its customers, it should not= be considered as IPv6-only, this should be the bottom line.

 

allocates IPv4 address to most of its custo= mers, then it is not IPv6-only. My= personal opionion is that the definition should not be based on whether t= o eliminate IPv4 protocol in the network.  At present stage, it is un= realistic to eliminate IPv4 protocol in most networks, for the networks st= ill need to provide access service to some customers who do not support IP= v6-only due to their poor-capability CPE or terminals.

 <= /o:p>

[Jordi] I agree is unrealistic to disable IPv4 in most of= the customer LANs, but not in the access network. Until 90-99% of the hom= e devices of an ISP customers have IPv6 in their LAN devices, an IPv6 with= IPv4aaS is needed.

[Chon= gfeng]  In China, access network adopts  layer-two approach, it = is independent to layer-three procotols. It seems to much more difficult &= nbsp;to make transition to IPv6 in wireline broadband network, due to the = slow upgradation of home routers.

 <= /span>

Moreever, some networks still need to use IPv4 for network man= agement . If the definition i= t too strict, I guess none of the network can meet the standard, including= those who have deplyed 464XLAT. In addition, an IPv6-only network should = be open and interconnected with OTTs and other ISPs, some closed system, s= uch as VoLTE in mobile network, should not be consider as IPv6-only, even = though it only allocates IPv6 addresses to it customer.<= /p>

 

[Jordi] If = IPv4 is used for management in the access network and provides native IPv4= to the CE (for example), then it is not IPv6-only. We could say in that c= ase: This access network is IPv6-only for the customer service, but still = IPv4-only or dual-stack for the management.

&= nbsp;

[Jordi] So I still believe that the =E2=80=9Cnature= =E2=80=9D of the definition should be based in if IPv4 is used natively in= a specific part of a network (then it is IPv6-only) or otherwise is IPv4-= only or dual-stack. What do you think?

 [Chongfeng] In general, I agree w= ith this point.

 

 

Best regards

Chongfeng 

 

<= p class=3D"MsoNormal" style=3D"margin: 0px 0cm; font-size: 11pt; font-fami= ly: Calibri, sans-serif; background: rgb(239, 239, 239);">From: JORDI PALET MARTINEZ

Date: 2020-03-06 02:12

Subject: Re: [v6ops] Ab= out Req for Comments - "Transition to IPv6"

If you read my draft, my opi= nion is different:

&= nbsp;

  Definitio= n of IPv6-only

 <= o:p>

   Consequen= tly, considering the context described in the section above,

   if we want to be preci= se and avoid confusing others, we can not use

   the terminology "IPv6-only" in a gene= ric way, and we need to define

   what part of the network we are referring to.

 

<= div>

   From that perspective, we defi= ne the "IPv6-only" status in a given

   part(s) of a network, depending on if there is= actual native

 &= nbsp; forwarding of IPv4, so IPv4 is not configured neither managed.<= /o:p>

 

=

So IPv4 may be not configured, or not used= natively, but there is no way to prevent that "is there" by means of tunn= eling of translation.

=  

*unless* you ma= ke sure that any encapsulation or translation is filtered, which is close = to impossible.

 <= o:p>

Because we disagree, i= t seems clear that this document is needed.

 

So if anyone has inputs, I will consider them in a new version duri= ng the weekend.

 =

Regards,

Jordi

@jordipalet

 

= =EF=BB=BFEl 5/3/20 17:46, "v6ops en nombre de Owen DeLong" <v6ops-bounc= es@ietf.org en nombre de owen@delong.com> escribi=C3=B3:

=

 

   

   

    > On Mar 5, 2020, at 6:02 AM, Ale= xandre Petrescu <alexandre.petrescu@gmail.com> wrote:

=

    > <= /p>

    > Thank you= very much for the pointer.  In it I could spot

<= div>

    > the following footn= ote: "[4] IPv6-Only refers to network environments in

=

    > which use of the I= Pv4 protocol has been eliminated.=E2=80=9D

   

    No.

   

    IPv6-Only refers to network environm= ents which are not using IPv4. That could be a network where IPv4 has been= eliminated (rare at this time, though Facebook is a significant example) = or it could be a greenfield deployment where IPv4 was never deployed.=

   

    >

    > I= n my humble opinion,

&= nbsp;   >

&= nbsp;   > IPv4 protocol has been eliminated.  On one han= d, a network is made of

=     > On another hand, there might be some ptp links (no= t networks, but

 =    > individual links) that run IPv6 only.

   

=

    You are wrong=E2=80=A6 = There are examples at various levels of IPv6-only networks. Many mobile ca= rriers are IPv6-only in the US, though they do provide some apparent IPv4 = capability to the end user through mechanisms such as 464XLAT and/or NAT64= .

    <= o:p>

    Ano= ther significant example is Facebook where they are essentially IPv6-only = throughout their network and provide minimal IPv4 translation shim at the = edge to cope with end users that lack IPv6 capability.

   

<= div>

    > That is why it is h= ard to agree on the assumption of IPv4 being eliminated somewhere.  W= orse, it makes look as if the goal of that 'IPv6-only' is to arrive at tha= t same situation which in fact does use IPv4.

   

    As a general rule, once IPv6 is u= biquitously deployed in a network, the preservation of IPv4 in the majorit= y of that network becomes an unnecessary cost factor and a security risk (= increased attack surface, if nothing else). As such, I think you will see = an increasing number of organizations follow on to the way Facebook has ma= naged their transition and start eliminating IPv4 wherever possible and re= placing it with translation shims as far out towards the border as practic= al.

   =

    O= wen

   =

    <= o:p>

    ___= ____________________________________________

    v6ops mailing list

    v6ops@ietf.org

    http= s://www.ietf.org/mailman/listinfo/v6ops

   

 

 

 =

**************************= ********************

I= Pv4 is over

Are you re= ady for the new Internet ?

http://www.theipv6company.com

The IPv6 Company

 

This el= ectronic message contains information which may be privileged or confident= ial. The information is intended to be for the exclusive use of the indivi= dual(s) named above and further non-explicilty authorized disclosure, copy= ing, distribution or use of the contents of this information, even if part= ially, including attached files, is strictly prohibited and will be consid= ered a criminal offense.. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this i= nformation, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the ori= ginal sender to inform about this communication and delete it.<= /p>

 

<= p class=3D"MsoNormal" style=3D"margin: 0px 0cm; font-size: 11pt; font-fami= ly: Calibri, sans-serif;"> 

 

____= ___________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops

__________________________= _____________________ v6ops mailing list v6ops@ietf.org https://www.ietf.o= rg/mailman/listinfo/v6ops


***********************= ***********************
=0AIPv4 is over
=0AAre you ready for the new= Internet ?
=0Ahttp://www.theipv6company.com
=0AThe IPv6 Company
= =0A
=0AThis electronic message contains information which may be privil= eged 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 informat= ion, even if partially, including attached files, is strictly prohibited a= nd will be considered a criminal offense. If you are not the intended reci= pient be aware that any disclosure, copying, distribution or use of the co= ntents of this information, even if partially, including attached files, i= s strictly prohibited, will be considered a criminal offense, so you must = reply to the original sender to inform about this communication and delete= it.
=0A
=0A
=0A ------=_001_NextPart577658781173_=------ From nobody Wed Mar 11 17:01:20 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8473A0CD2; Wed, 11 Mar 2020 17:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AulutmwzBuub; Wed, 11 Mar 2020 17:00:22 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B3B3A0CF5; Wed, 11 Mar 2020 17:00:21 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 89121548049; Thu, 12 Mar 2020 01:00:16 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 80E02440040; Thu, 12 Mar 2020 01:00:16 +0100 (CET) Date: Thu, 12 Mar 2020 01:00:16 +0100 From: Toerless Eckert To: 6man@ietf.org, v6ops@ietf.org Message-ID: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 00:00:24 -0000 Sorry for cross posting, but this is both ops and arch questions. I was trying to find any generic description that/if link-local IPv6 traffic MUST/SHOULD use Hop-count 1, but could not find one in rfc8200 or rfc4291 and its updates. Instead, text like MUST set Hop-limit to 1 is repeated in various RFCs using link-local IPv6 traffic. Am i overlooking something ? Or is this intentional in the IPv6 architecture ? If intentional, i guess it means: Any RFC introducing some type of link-local traffic can specify Hop-limit requirements for its traffic. As in "our WG likes 42 as the Hop-limit" (silly to me, but should be fine with IPv6 architecture then, right ?). In one of my draft document reviews using such link-local IPv6 traffic, EricV brought up the Q if that traffic shouldn't use RFC5082 instead of Hop-Count 1 too. But given how we do not seem to have architectural recommendations for TTL=1 (unless, quite likely i overlook something), and given how i am not aware of any actual use of GTSM, i am quite weary to go down that route. Aka: Would like learn of actual uses of GTSM with IPv6. There is an additional set of consideration re. link-local traffic when trying to use it as a HW accelerated tunneling mechanism across links, a use we both have in ANIMA, and maybe get the same in BIER (probably other WGs too, not sure). In implementations, i have seen quite a range of issues with accelerated forwarding planes across link-local addressed tunnels, and when using non-link-local addresses (loopback addresses), the HW plane forwarding might have issues doing HW forwarding, because usually TTL=1 is only used for control plane traffic. Of course, this is not a good architectural argument, but if given architectural leeway to even choose 42, maybe GTSM/255 is easier to be supported across various HW accelerated forwarding planes than 1. Opinions and experiences welcome! Thanks! Toerless From nobody Wed Mar 11 17:34:12 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3793A09C5; Wed, 11 Mar 2020 17:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRPpqfIrKHRI; Wed, 11 Mar 2020 17:34:05 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40643A09A4; Wed, 11 Mar 2020 17:33:49 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id d22so3095217qtn.0; Wed, 11 Mar 2020 17:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dIyaa8t3gKEoC+477Xp4r3We6qoEzSi/aiKeQTh9xWY=; b=eKAQnecTeBN9pu6+FLjH9ulWOms4ogmPp6grVDKMaqO0KQ9s8JYlOC9/aC/PhsE/AV JFaCA7kT3OzD1dfXUuUOtDaOLZ27Wmos/tXfvUH0JECKUp70iDLW5Ic9FX+cHJMkkttD XA0NI+V8jvgWhw8o7c76NfwXgJLlML2A6fc7c3pHj95IKIS86TFgd1bCZiADI4+ogWhU rSUVuqjj2GQXMaaE3tpTcgcTwhThUNt+O39K6Z+Br87QBVeubr591PCE8L5wXZ2V8gK7 nsGxgcgHqkSP7mgG8y1u8r+vKzPIkoLg0MmMTlLdjX+Dmatvj26beB82ZfYWFPmn2EK3 sgGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dIyaa8t3gKEoC+477Xp4r3We6qoEzSi/aiKeQTh9xWY=; b=jyFwjlH0tPH07Wot/buhN0vfkmUSYnW31xVvw/nM4IWHEO5HtvuKnX92odWyZN50Pd 0NzoTD5/23DI/ZEyO2K3Fh1ZiujrVNMXRKjxyRADtzCjy0McCFkJz8MdJBmUdqIpkpJg sA9LWGlJD2uIvet3pTifBOZINwhCmMGQy88qjyAoRyvVPyAhXdO4xuIxS8BV6QTrnXEs TSo/Ghh1v2HKwkqu4ZLQsp072xp2B/GUomYXrGev0DuC6ZDMhiIAyZxAmSk1pzVr2yxF opVC8ybM5cDWzWHO50247AFQUDD5P4sKNiMtEWmRstsRyL4cPFo0iy0DuoK5ejV6tQ1Z 9SAg== X-Gm-Message-State: ANhLgQ1hp0aK24VqhJGYniPhEYq7/hfMrFisC/IGT23wUMV+vFWdJ1yu rhFpNoGHrVUmch8+yBOAR5AnpGjmLP5TQU605Tw= X-Google-Smtp-Source: ADFU+vuUizjGFkocdrcIBfjaLVUaOpvi+cN4IJPaQeos+02CPGIn9SwXPoEPTdEpgyQ6eQ4GeMvisHds2F/GveYd2FU= X-Received: by 2002:ac8:a8b:: with SMTP id d11mr4940031qti.94.1583973228094; Wed, 11 Mar 2020 17:33:48 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> From: Jen Linkova Date: Thu, 12 Mar 2020 11:33:37 +1100 Message-ID: To: Toerless Eckert Cc: 6man <6man@ietf.org>, V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 00:34:07 -0000 On Thu, Mar 12, 2020 at 11:01 AM Toerless Eckert wrote: > > Sorry for cross posting, but this is both ops and arch questions. > > I was trying to find any generic description that/if link-local IPv6 > traffic MUST/SHOULD use Hop-count 1, but could not find one in > rfc8200 or rfc4291 and its updates. Instead, text like > MUST set Hop-limit to 1 is repeated in various RFCs using link-local > IPv6 traffic. I believe it depends what you are trying to achieve. If you want to make sure that the traffic never leaves the network - then hop limit = 1 helps. But using link-local sources/destinations would help even better if the routers comply with RFC4291 Section 2.5.6 If you want to make sure those packets are not sent by a malicious party from outside - hop limit shall be 255. For example, see RFC4861 Section 3.1 > Am i overlooking something ? Or is this intentional in the IPv6 architecture ? > > If intentional, i guess it means: Any RFC introducing some type of link-local > traffic can specify Hop-limit requirements for its traffic. As in > "our WG likes 42 as the Hop-limit" (silly to me, but should be fine with > IPv6 architecture then, right ?). > > In one of my draft document reviews using such link-local IPv6 traffic, > EricV brought up the Q if that traffic shouldn't use RFC5082 instead > of Hop-Count 1 too. But given how we do not seem to have architectural > recommendations for TTL=1 (unless, quite likely i overlook something), > and given how i am not aware of any actual use of GTSM, i am quite > weary to go down that route. Aka: Would like learn of actual uses of > GTSM with IPv6. Neighbor Discovery. > There is an additional set of consideration re. link-local traffic > when trying to use it as a HW accelerated tunneling mechanism across links, > a use we both have in ANIMA, and maybe get the same in BIER (probably > other WGs too, not sure). > > In implementations, i have seen quite a range of issues with > accelerated forwarding planes across link-local addressed tunnels, > and when using non-link-local addresses (loopback addresses), > the HW plane forwarding might have issues doing HW forwarding, because > usually TTL=1 is only used for control plane traffic. Of course, > this is not a good architectural argument, but if given architectural > leeway to even choose 42, maybe GTSM/255 is easier to be supported > across various HW accelerated forwarding planes than 1. > > Opinions and experiences welcome! If you control the router I'd say 'link-local source/destination, HL=255 AND RFC4291 would be the best option. I did see a few devices somewhere far away sending me ICMPv6 (packet too big) from their link-local addresses but it was not very common case. -- SY, Jen Linkova aka Furry From nobody Wed Mar 11 18:19:02 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A193A0FA9; Wed, 11 Mar 2020 18:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mer6b-qTe9du; Wed, 11 Mar 2020 18:18:59 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8324C3A0FBA; Wed, 11 Mar 2020 18:18:59 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id 66so4308834otd.9; Wed, 11 Mar 2020 18:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R77eur8EFUJNuVVPcFlHYbjcYMuIu0X0oS+I/+iuGQ0=; b=XlezY51zTEuORcA6fjaGxW6vdQ/7EoFnsGROvbZ/+lYMDX80232SScHLyu7vGM5Nlu dVnd1MuQKa73pUecKcGWD03xnfFUXeGz8djLC1+TVktoRoeATJkPduOOeo3atQnWWq3H FGqBNVAjMI3+gs0hzv7BQq7gPrv5rNf+tzwPWJxLt34+VFZ/McFaMUr9+yc3M17jLaNN Le8J55uLZJcT87ZtWFSDqJ+NedQu56m/PCGG088yQPi3pqnn9RtJAqH5zg69qpmMnP7t Eu4QmdiWES65M86rcVFmrcZX82D4ifNIbh1Jw0S2c671+OmyGvkv9qU2/kueGLoZCPN6 NV0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R77eur8EFUJNuVVPcFlHYbjcYMuIu0X0oS+I/+iuGQ0=; b=MM3Ey9bhZJ7eTvfXQTPuPPmsism9++FX0XzfRRvI/yMv2k3dZHxSMsa+K1/0uiQNoV aXHMX4eV7rYKQNv4i+CpXXmBGKjD7VJar6CL6bsBenKm2vErPVnbCkBuj+mIeDXPjbwn gRscyuTcMyDWgbNTF57TM0ft4E/q06kB9VOVrGouTdDX9HrJ82EvsigUphCF20sQqzko kvPrNsC/B7+8nTbE5BOT9e1ONVqBloqbjzwZvaaS9x+1Sxjd0OvxjCJXYgM8AsfO1hsh PMSInK5g6UQ0xNRsNp1AatV0pbl+fX2fOrXwCw/6gKHY+CrYTkPtqRShghiuObRRzlv9 HZzw== X-Gm-Message-State: ANhLgQ0JtQ+2Gp54Li/mcykIYgSO9Oisk8WrO82VL4lJdNU9FMmIKUQi Jpi+wnpK/AXncTOaRsGnaE3bJnAZNXzBorK8A+dANYBg X-Google-Smtp-Source: ADFU+vsacyxf7FZOGP3Er/TlU3S/f6ed8ZdMdOn7iUEvpEJYQ8zS0njm0MwlUZeHztHtZkFIdfpZVWBtlO4Muf3QJ7Y= X-Received: by 2002:a9d:4807:: with SMTP id c7mr4720678otf.74.1583975938492; Wed, 11 Mar 2020 18:18:58 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> From: Mark Smith Date: Thu, 12 Mar 2020 12:18:32 +1100 Message-ID: To: Toerless Eckert Cc: 6MAN <6man@ietf.org>, v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 01:19:01 -0000 Hi Toerless, On Thu, 12 Mar 2020 at 11:01, Toerless Eckert wrote: > > Sorry for cross posting, but this is both ops and arch questions. > > I was trying to find any generic description that/if link-local IPv6 > traffic MUST/SHOULD use Hop-count 1, but could not find one in > rfc8200 or rfc4291 and its updates. Instead, text like > MUST set Hop-limit to 1 is repeated in various RFCs using link-local > IPv6 traffic. > RFC4007 allows packets with link-local destinations to be forwarded by a router, but only back onto the same link: "Thus, if a router receives a packet with a link-local destination address that is not one of the router's own link-local addresses on the arrival link, the router is expected to try to forward the packet to the destination on that link (subject to successful determination of the destination's link-layer address via the Neighbor Discovery protocol [9]). The forwarded packet may be transmitted back through the arrival interface, or through any other interface attached to the same link." I think in theory that could also mean forwarded to another router on the link that then forwards back again onto the link etc., so it is valid for a packet with a link-local destination address to have an initial Hop Count value that allows it to be forwarded by multiple routers, all limited to being forwarded within the same link. This draft might be useful, as it collects together and summarises information about using Link-Local Addresses (and is something I've been meaning to get back to updating, suggestions welcome): How to use IPv6 Link-Local Addresses in Applications https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00 Regards, Mark. > Am i overlooking something ? Or is this intentional in the IPv6 architecture ? > > If intentional, i guess it means: Any RFC introducing some type of link-local > traffic can specify Hop-limit requirements for its traffic. As in > "our WG likes 42 as the Hop-limit" (silly to me, but should be fine with > IPv6 architecture then, right ?). > > In one of my draft document reviews using such link-local IPv6 traffic, > EricV brought up the Q if that traffic shouldn't use RFC5082 instead > of Hop-Count 1 too. But given how we do not seem to have architectural > recommendations for TTL=1 (unless, quite likely i overlook something), > and given how i am not aware of any actual use of GTSM, i am quite > weary to go down that route. Aka: Would like learn of actual uses of > GTSM with IPv6. > > There is an additional set of consideration re. link-local traffic > when trying to use it as a HW accelerated tunneling mechanism across links, > a use we both have in ANIMA, and maybe get the same in BIER (probably > other WGs too, not sure). > > In implementations, i have seen quite a range of issues with > accelerated forwarding planes across link-local addressed tunnels, > and when using non-link-local addresses (loopback addresses), > the HW plane forwarding might have issues doing HW forwarding, because > usually TTL=1 is only used for control plane traffic. Of course, > this is not a good architectural argument, but if given architectural > leeway to even choose 42, maybe GTSM/255 is easier to be supported > across various HW accelerated forwarding planes than 1. > > Opinions and experiences welcome! > > Thanks! > Toerless > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Mar 11 19:06:51 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5C53A1138 for ; Wed, 11 Mar 2020 19:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB9ZBh-VWxFl for ; Wed, 11 Mar 2020 19:06:48 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A8C3A1135 for ; Wed, 11 Mar 2020 19:06:47 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id s14so5364236wrt.8 for ; Wed, 11 Mar 2020 19:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lQcL4zeqxL7WwcZ4KMbE+VJlva/lg8h1Bv3IHEzU1hM=; b=svFokEBlfyohqtpt+xA3qstCglUXyjNGlVyGqOvbsLQidPhkVHKs9aJ0F/pW92lolR Dmtj8SlM9nXARb4e5KN26cEHxSffV7AaBP5GF5Pb8uTGsbB2LaNNirk9lI+p9h4LsjnS B8rF6LXDIlL03sBwSydkCD4wcmY4sts06KVIfSkXPcwT/36j02z9qjqFyUbNQs2X0i94 TwwOZgZmKi4BJFEvO9PGhDUMCguagS5KXJO2oeDdN5pZlkGsj0RdXS9hB4h51alXYNUv YJ5Ww6G2ggl6jARKkNO3HxIG5nkmk8o4jgKPs0ZrYYNg/KVe6Bi08D09/mx9WPsYz93O 5cPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lQcL4zeqxL7WwcZ4KMbE+VJlva/lg8h1Bv3IHEzU1hM=; b=DJcoxDX70TLLEY4PNl2ghmjOJgCaSxSp52oqi0sTBJiod0WEkqbE+HH+dg+TfiweY5 nycWepvRmDPGrJvEt+T9PBn1szgPoS0lrCCNGIbHaguSN0am1mpSimxpZMyMGaCprvR7 vlxll/LzNB04JPpShz0VtCrbaU1on2TJkrurrDsC3sue6GGjArNuv9KT9mroFI/SyrvW vkm9NTHmlq32IPDq+jWnqLZtx5Z8M9q/0gvoZZ1mGfVFozc3ohBPC8ezOYdxwF7s30A/ spVpeSH27t5sblvB3RqpipUkgFqD1yADjcOmWvPHh2lRMO78pKADMRTNwnFbSuQAn6R0 n0dA== X-Gm-Message-State: ANhLgQ3vj5RtyUb/8Nbm9zEDH4hthJh48cETR2P6NGTmAuKQP8Gnfkhm +Dgjzc0jJZXHeVueGAZgfrc= X-Google-Smtp-Source: ADFU+vuwnL/dVImc1EkNc1qSUh1x/BjOkryBRqMCYz8+IWAP4fu84/8GbSbKDpsM4JaSfsFwnL9//g== X-Received: by 2002:adf:eece:: with SMTP id a14mr7835198wrp.334.1583978806109; Wed, 11 Mar 2020 19:06:46 -0700 (PDT) Received: from ?IPv6:2600:8802:5900:13c4::1041? ([2600:8802:5900:13c4::1041]) by smtp.gmail.com with ESMTPSA id m2sm10643757wml.24.2020.03.11.19.06.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2020 19:06:44 -0700 (PDT) From: Fred Baker Message-Id: <3567F570-BC40-470E-971B-2368E1ACD80C@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CD54D11C-7E34-4EE6-B5C0-1303E5E784DB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 11 Mar 2020 19:06:41 -0700 In-Reply-To: <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> Cc: Alexandre Petrescu , v6ops@ietf.org To: Owen DeLong References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 02:06:50 -0000 --Apple-Mail=_CD54D11C-7E34-4EE6-B5C0-1303E5E784DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 5, 2020, at 8:46 AM, Owen DeLong wrote: >=20 >> Thank you very much for the pointer. In it I could spot >> the following footnote: "[4] IPv6-Only refers to network environments = in >> which use of the IPv4 protocol has been eliminated.=E2=80=9D >=20 > IPv6-Only refers to network environments which are not using IPv4. = That could be a network where IPv4 has been eliminated (rare at this = time, though Facebook is a significant example) or it could be a = greenfield deployment where IPv4 was never deployed. This, I think, is where the v6ops discussion has travelled in circles = forever. To me, I would drop the word "network" and say that it is a = specified environment. If I say that a system is IPv6-only, it is not = using IPv6 internally or externally. It might or might not have IPv4 = code in it, but it's not using it. If I say that a LAN, building, etc is = IPv6-only, it is not to say that it couldn't have IPv4 in it if a DHCP = server started handing out such addresses, but that it *doesn't*. If it = is an Autonomous System, it means that only IPv6 is in use in that = domain. As soon as we get into the "but it could" or "was it translated from = something else" or whatever rathole, we're into a discussion of angels, = pins, and heads of pins. It will not end, because it can't. Someone will = forever come up with a "what if" scenario to stir the pot. Speaking for myself, I would have the user of the term identify the = environment s/he is talking about, and say that *within*that*domain* = communication is entirely accomplished using IPv6. And STOP. --Apple-Mail=_CD54D11C-7E34-4EE6-B5C0-1303E5E784DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl5pmTEACgkQEhdRnd2G P+C3Tg//WgbDc60cJQIFFz87GNKwJPCy43pnqH/0KC1rUL58VxUl4ZDKUTr33BBK eTSzqzap6vx49VmaXpyAfEU7hP4EOMeXUcnmz1R8puGcHCK4JxtAgtOB7oHEKW9A BlXCI40x4ZidYfV0CrPqGppB/aa8Lesy2SCT877+y1qPVddwkCHa93AlosobsnzP lbyEE7hz8/N0OL6L4zn2eIoi+G5sc8W0IV92K7aOLcOKAVZVd2FBrB65NoLcnD9v da9b1SQtmCq7xtNS1SUz62pfioZD2x5r3oRjB0toYeSaTTg4fur7Zsv5fhR0iIfX bh8mLAwgFmpOpLfNwqrP/v3sCyc9kysFb2JCGhDQZBsXUEJpWRBEuF8imuPFWvXl 93Y9ACp0qiJmRFxb6FkTwdL5yrbe+TcHrDDKdo5M8yE9CYAj9D9oLsA1bYdqO+dd fVdCPipsgAh53yOJTjdNMSGJmnLwN1ToDE55h1JV7rlh7zoRvKIrfpi4d9vpoVHl 7mTlB+DhoT63fYR+nZPDOE9krROtFalUDKPid2/Xvb9AWXvlLxlfY5Xa26gmdELD 1WSo3wN6m3vyeavYDi50nkZL4DM4WF30u6Bh2pOdUXfZLbal18UNatB/S7qElty9 xnuRF9NFnSFuKKi/jYvd+kaC+2cZw29kPCTciCNyvFSFt520H1Q= =uvbf -----END PGP SIGNATURE----- --Apple-Mail=_CD54D11C-7E34-4EE6-B5C0-1303E5E784DB-- From nobody Wed Mar 11 23:57:30 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD5D3A11C6 for ; Wed, 11 Mar 2020 23:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJEEBfCM9Szi for ; Wed, 11 Mar 2020 23:57:26 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1944A3A11C1 for ; Wed, 11 Mar 2020 23:57:26 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id f7so4962760wml.4 for ; Wed, 11 Mar 2020 23:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HmJhQZ20Iq/Hy7IOS4FWm8pKDIYYs9JBmtcyzIp6cHw=; b=nCoO8M/SdRRvxmpkmI/I2wAKxYeauhllsuH9+CPnZl6oDR/b4QIF26H++tmUml8wqE Sq0LqxBLItKD5AE7XlpiNZZOrGlzn9qc1mUcSp1dFFRr1WWX8SuVPPQuKSzMgi2sS7Ij fotIcCtPIbRbpHGmmicPtnwBKvxDAM2UAoTs59LrA5Z/cDWuosAedlHG4XXub+R7ZcHJ 9xd0AekuOVHhmdHP7pXTbLY1osjsL4w50d21c0TsXHsjT0nbwqXHngHEu4jyZZ8vZF9k 1b2k2xqtMmiJoHIq504Cl9QPtWuhLBOEcf2vXHzCRF3TdMA6OKQmzy6X0wPsIJwH5g1f V1Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HmJhQZ20Iq/Hy7IOS4FWm8pKDIYYs9JBmtcyzIp6cHw=; b=KDZff/Qu8FjXpm0YdFB4fmtW6fmdwH9YdHVPfotQzw9wpBXn6JrtPcfhWnkvilh/xX S8FMJc5EGKOWYL1tAB8o1HTY4B18P0d6h2/vkFh7oTtVsGNLf64ATf3Wyi8ct6bnj6t6 tg01XDsxmErfIlQGhHUW+79Q6rBFQezumku5FUTb/cYt54P7OZ6JzK2tJawQQ4Skjzcq TLCWNPIie9d1xKenRron56STkGBobYTujRrHpcq25bk/UzLkQ+Dx5dDp2xeAY6BBzQzj NkXw60mrFoJKJc1Xz+0ZanmUjvWSyARLHwgow3R3qMZWS9nKVOvxuelMYcXfIMIpXWZa 9zSw== X-Gm-Message-State: ANhLgQ2Z/DzN9BpEkVjYLDJsUf98sCWfVPDQkKplIjL2AKlxX88swP5i 3gq/PUu6WlA/bWUSMnETaQOW6lmx X-Google-Smtp-Source: ADFU+vuHzGzJXftOYGBBvjY0rNxKGQzF2LIObbsZePtHWW5Y4Kl/slN6Tw56gtjxi+tpiQEs9s0tpQ== X-Received: by 2002:a1c:b7c2:: with SMTP id h185mr3174047wmf.67.1583996244578; Wed, 11 Mar 2020 23:57:24 -0700 (PDT) Received: from ?IPv6:2600:8802:5900:13c4::1043? ([2600:8802:5900:13c4::1043]) by smtp.gmail.com with ESMTPSA id f4sm18230387wrt.24.2020.03.11.23.57.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2020 23:57:23 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_243E2D34-6B45-4825-84AF-BF766DEF9B80"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 11 Mar 2020 23:57:20 -0700 In-Reply-To: <4A886236-7D17-41F2-8291-0BC1B49F7A59@consulintel.es> Cc: v6ops@ietf.org To: JORDI PALET MARTINEZ References: <4A886236-7D17-41F2-8291-0BC1B49F7A59@consulintel.es> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] IPv6-only Terminology Definition X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 06:57:28 -0000 --Apple-Mail=_243E2D34-6B45-4825-84AF-BF766DEF9B80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Section 2, fourth paragraph. However, the "end-networks", in general, need to continue supporting IPv4, as there are many devices or apps, in both corporate and end- user networks (smartTV, IP cameras, etc.), which are IPv4-only and it is not always feasible to update or replace them. Also if customer devices in a LAN are IPv6-only, they will not be able to access IPv6-only services, so this means that IPv6-only services can't be deployed unless it is done in such way that some transition mechanism solves that problem as well (example an IPv6-only Data Center, requires SIIT-DC) I don't understand why an IPv6-only device would not be able to access = an IPv6-only services. I can understand IPv4-only devices not being able = to access IPv6-only services, but that's not the statement. This = paragraph seems to not follow. > On Mar 9, 2020, at 11:47 AM, JORDI PALET MARTINEZ = wrote: >=20 > Hi all, >=20 > After the recent discussion, I've posted a new version (minor changes) = for this document: >=20 > = https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/?include_text= =3D1 >=20 > Comments welcome! >=20 > Regards, > Jordi > @jordipalet >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > 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. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_243E2D34-6B45-4825-84AF-BF766DEF9B80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl5p3VAACgkQEhdRnd2G P+DalA//YqdiQua10pCOzWH+3iou++xNCAe6fWUGM/+X5a/711IhI2N8oyD0ucwC 3vKLZz3NRMt0xYgObzcxXMf2fMC/w0TRoKytxvMaCBxdwXlAA0XauIl20uScNa8E n/buqVoDx5OPu9ozItd5wNpEv2aN4GTDJuzYCL7ZWzcqpKCGXWAmsqIZKRHwuS2y F7IXWBYdH/Px3WwxQHagpBgx54wXUZXC1P42e6p6inYoctLqIngGdwnUh211sd+H Ibc92qJ1POk4q+8TroRrWFuk+b7EXPkhZiadFlRfVwAONYHFuGG0LVn4ZZR4JIT6 2PAkCUjHU5RpaSvVwOSCa5m+y2U9cgBA80QCtHjtN2xM+W8EeN1K4pelylGEyrpj 2HrfND4/8ZHK+/y11fYGh0RRQu0R19P/sTleXLGzX8hxJPX6cE7RUV6DiWHaGJvB sQlyBMYj1iuYWj2bZGN0q1WOSU7AIulQrmYN2hhbbwk3ih3s2HcCSW5IIo4O9pUQ ErKLboom/FRGZpnZIojgcM9SSomsH4XOSsRGL+7yZNDRMXVlXLQdbz2i9IeFds5Y PnA7AHWA24uQ+ktlUMxi3lZ5MLw59xKQEdlnO/QNYofes/0CWl32b4YoBBmc+b4J g97W25O4XMO9fz8r/n7WRLqIzWmW6mk5OmEwdA+uaPJ7pBZjs6Y= =pcmM -----END PGP SIGNATURE----- --Apple-Mail=_243E2D34-6B45-4825-84AF-BF766DEF9B80-- From nobody Thu Mar 12 01:20:29 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D043A12FB for ; Thu, 12 Mar 2020 01:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmbS8DtoBPZV for ; Thu, 12 Mar 2020 01:20:22 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B7BAF3A12F1 for ; Thu, 12 Mar 2020 01:20:21 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02C8KJZE1850713 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Mar 2020 01:20:19 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <3567F570-BC40-470E-971B-2368E1ACD80C@gmail.com> Date: Thu, 12 Mar 2020 01:20:19 -0700 Cc: Alexandre Petrescu , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1FC68A89-A5E2-4FF3-836C-5AEC3D295299@delong.com> References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <3567F570-BC40-470E-971B-2368E1ACD80C@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Thu, 12 Mar 2020 01:20:19 -0700 (PDT) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 08:20:27 -0000 > On Mar 11, 2020, at 19:06 , Fred Baker = wrote: >=20 >=20 >=20 >> On Mar 5, 2020, at 8:46 AM, Owen DeLong wrote: >>=20 >>> Thank you very much for the pointer. In it I could spot >>> the following footnote: "[4] IPv6-Only refers to network = environments in >>> which use of the IPv4 protocol has been eliminated.=E2=80=9D >>=20 >> IPv6-Only refers to network environments which are not using IPv4. = That could be a network where IPv4 has been eliminated (rare at this = time, though Facebook is a significant example) or it could be a = greenfield deployment where IPv4 was never deployed. >=20 > >=20 > This, I think, is where the v6ops discussion has travelled in circles = forever. To me, I would drop the word "network" and say that it is a = specified environment. If I say that a system is IPv6-only, it is not = using IPv6 internally or externally. It might or might not have IPv4 = code in it, but it's not using it. If I say that a LAN, building, etc is = IPv6-only, it is not to say that it couldn't have IPv4 in it if a DHCP = server started handing out such addresses, but that it *doesn't*. If it = is an Autonomous System, it means that only IPv6 is in use in that = domain. >=20 > As soon as we get into the "but it could" or "was it translated from = something else" or whatever rathole, we're into a discussion of angels, = pins, and heads of pins. It will not end, because it can't. Someone will = forever come up with a "what if" scenario to stir the pot. >=20 > Speaking for myself, I would have the user of the term identify the = environment s/he is talking about, and say that *within*that*domain* = communication is entirely accomplished using IPv6. >=20 > And STOP. It seems to me that you are saying essentially the same thing I intended = to say, Fred. My key point was that IPv6-only could mean either of: + Any environment where IPv4 usage has been discontinued = and IPv6 is the sole remaining active protocol OR + Any environment where IPv4 was never deployed and IPv6 = is the only protocol ever deployed It was in response to a statement that IPv6-only could only mean an = environment where IPv4 once existed and had been removed. Owen From nobody Thu Mar 12 02:23:08 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2216A3A00C1 for ; Thu, 12 Mar 2020 02:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWB3b-HktRWk for ; Thu, 12 Mar 2020 02:23:04 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E323A0042 for ; Thu, 12 Mar 2020 02:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1584004981; x=1584609781; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=EoKc1Q2uwhrQGqMgkLJOZQdjxPKLqY4kKQ mbkghCHqs=; b=wmwF3fsqd4KMJ5SVczWhz5qfj0Wn0vwoLVduLworqSFBkpsQhI dOopZICBtM+hHzdyqMZRwlXIGu9mfBQBlPC6D1AaWqaQ/zZCdmx83VokJmDe+mPS hqE24ROue8AFXIuRY6ALI0UwjuSX1HJgFd5xww3Hv7i840s2L7+F8TSCM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 12 Mar 2020 10:23:01 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 12 Mar 2020 10:22:59 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000088903.msg for ; Thu, 12 Mar 2020 10:22:58 +0100 X-MDRemoteIP: 2001:470:1f09:495:e0a6:81ab:ea8d:1a06 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 12 Mar 2020 10:22:58 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1340af7d02=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Thu, 12 Mar 2020 10:22:55 +0100 From: JORDI PALET MARTINEZ To: v6ops Message-ID: <3854B1F6-0DB8-4753-BBDD-30AAD391C4DC@consulintel.es> Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <2020030818294834486735@chinatelecom.cn> <073925C4-5355-4C51-84A4-4D9545013552@delong.com> <4A5BDEE6-2B9E-4338-94C1-3BE9D6E37516@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3666853375_1296374745" Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 09:23:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3666853375_1296374745 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Owen, Using +++ below =E2=80=A6 =20 =20 El 10/3/20 21:49, "v6ops en nombre de Owen DeLong" escribi=C3=B3: =20 =20 On Mar 10, 2020, at 11:25 , JORDI PALET MARTINEZ wrote: =20 Hi Owen, =20 Responses below with ***. =20 El 10/3/20 19:03, "v6ops en nombre de Owen DeLong" escribi=C3=B3: =20 =20 On Mar 9, 2020, at 01:42 , JORDI PALET MARTINEZ wrote: =20 Hi Clark, =20 El 8/3/20 12:38, "v6ops en nombre de Clark Gaylord" escribi=C3=B3: =20 It seems to me the context of the OMB guidance is relevant to the question = of "IPv6-only". The draft memo is reasonably good at this, but succinctly s= omething like "agency internal networks use single-stack IPv6 with any=20 =20 [Jordi] I don=E2=80=99t think is so clear. Footnote 4 =E2=80=9CIPv6-Only re= fers to network environments in which use of the IPv4 protocol has been eli= minated=E2=80=9D will be much clear if it says =E2=80=9CIPv6-Only refers to= network environments in which use of the *native* IPv4 protocol has been e= liminated=E2=80=9D. =20 I don=E2=80=99t believe that what you propose is the intent in the memo. =20 I believe they intend to eliminate the use of ALL IPv4, not just native IPv= 4 on government networks. =20 *** Then there is a problem. If they really want to have ALL the way thru o= nly IPv6 in the LANs, the federal employees will not be able to use *ANY* a= pplication that uses literal addresses (even a simple web page that is doin= g that). Because there is NO transition mechanism that allows that. They ar= e able to force all their internal apps to use only IPv6, fine, but they ha= ve no control over the rest of the Internet. If they are thinking that NAT6= 4+DNS64 resolves that, they lost this =E2=80=9Csmall=E2=80=9D bit in their = thinking. I=E2=80=99ve already reported them to the site that is asking for= comments, hopefully they really pay attention to the inputs. =20 I don=E2=80=99t see that as a problem=E2=80=A6 I see that as a benefit. =20 I think that the US Federal government is one of the few organizations in a= position to actually put the kind of pressure that will be necessary to ef= fectuate this change. =20 So, personally, I don=E2=80=99t see it so much as =E2=80=9Cthey lost this i= n their thinking=E2=80=9D as in they are choosing to stop supporting certai= n =E2=80=9Cbroken by design=E2=80=9D ways of thinking. =20 I hope that they stick to their guns and do not soften their position. =20 +++ Somehow, I agree, is not a =E2=80=9Cproblem=E2=80=9D, depending on how = you see it. As moving on to a real IPv6-only world, it is good. But we are = interpreting the document as they really want that. They don=E2=80=99t say = explicitly, so we don=E2=80=99t know. If they want that effect, I think it = will be much better message to say =E2=80=9Cwe know this will create this p= roblem for people still using literal IPv4 addresses in web sites, but they= should react if they want to work with us=E2=80=9D or whatever. =20 If a Federal office decides to have its DC with IPv6-only, then IPv4-only u= sers will not be able to access it. In that case the DC must use, for examp= le SIIT-DC. That will mean that the DC (internally) is IPv6-only, but the D= C-to-Internet is dual-stack, in order to be able to use SIIT-DC. =20 I believe that _IS_ the intent (no support for SIIT/NAT64/etc.). =20 Remember, this is referring to the INTERNAL networks of the federal governm= ent agencies=E2=80=A6 Not the public-facing networks. =20 Unless I misread the memo, the intent is to preserve dual-stack functionali= ty on public-facing services, but ensure that there are no remaining IPv4 d= ependencies in providing those services over IPv6. =20 Furthermore, footnote 5, =E2=80=9CNote that for public Internet services, m= aintaining viable IPv4 interfaces and transition mechanisms at the edge of = service infrastructure may be necessary for additional time, but this does = not preclude operating the backend infrastructure as IPv6-only.=E2=80=9D Is= precisely saying that. =20 Correct. =20 It may happen that some of the LANs in the Federal office itself, are dual-= stack still. Otherwise, employees will not be able to use Internet resource= s that don=E2=80=99t work well with NAT64+DNS64, for example, web sites or = apps that use literal IPv4-addresses and are out of the control of the Fede= ral office. So, in this case they still need to use IPv4aaS. =20 That=E2=80=99s not the desired outcome in this process. =20 Indeed, my impression is that the government is, through this memo, intendi= ng to put suppliers and web sites on notice that if they do not have IPv6 a= ccessibility they are likely to lose their government customers. =20 I see that as a good thing. =20 *** I will be glad if they can send this memo to every small web site in th= e world, because even if one of them is missing it, and need to be accessed= by the employees, will not work! =20 I=E2=80=99m pretty sure that the employees that encounter difficulty will m= ake it known to the web sites in question. =20 +++ Not sure, it may get ignored, as they ignore problems in their deployme= nt. Last time I tried to fill in the ESTA for traveling to US, it was not w= orking in some of the final steps. I did some debugging and realized that t= hey were dual stack, but filtering PTB, so because the MTU at some point in= the network, it never worked until I disabled IPv6 to complete the form an= d pay the fee. I tried to tell them. I recall there was even a thread about= that in NANOG (talking from the top of my head, it may be in a different l= ist). They never responded or resolved it. I=E2=80=99m not sure if now the = problem is still there. =20 In reality, in terms of actual job-related usage, the federal government is= unlikely to need access to every small web site in the world. As a general= rule, every small web site in the world has no ability to support things a= t the scale of US Government usage. =20 +++ Sometimes this happens even in bigger sites =E2=80=A6 so yes and not. =20 If some employe can=E2=80=99t surf their favorite mom-and-pop cat video sit= e while they are supposed to be working for their taxpayer supported salary= , I won=E2=80=99t actually be upset. =20 +++ =C2=A0Fully agree! =20 So from my perspective, this memo puts government contractors on notice tha= t their network-based systems providing services to the federal government = damn well better fully support IPv6 in the next few years, or they=E2=80=99= re going to experience an increasing level of disconnect followed by a very= likely contract termination. I see this as a good thing. =20 +++ =C2=A0Fully agree! But some text could make it more clear, so nobody be= lieves =E2=80=9Cthey didn=E2=80=99t though about this issue=E2=80=9D as I d= id. =20 Owen =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3666853375_1296374745 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Owe= n,

Using +++ below =E2=80=A6=

 

 

El 10/3/20 21:49, "v6ops en nombre de Owen DeLong&qu= ot; <v6ops-bounces@ietf.org en nombre de owen@delong.com> e= scribi=C3=B3:

 

 



On Mar 10, 2020, at 11:25 , JORDI PALET MARTINEZ <jordi.palet=3D40cons= ulintel.es@dmarc.ietf.org> wrote:

 

Hi Owen,

=  

Responses below= with ***.

 

El 10/3/20 19:03, "v6ops en = nombre de Owen DeLong" <v= 6ops-bounces@ietf.org e= n nombre de owen@delong.com> escribi=C3=B3:

 

&= nbsp;




=

O= n Mar 9, 2020, at 01:42 , JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dma= rc.ietf.org> wrote:

 

Hi Clark,

 

=

El 8/3/20 12:38, "v6= ops en nombre de Clark Gaylord" <v6ops-bounces@ietf.org = ;en nombre de cgaylord@vt.edu> escribi=C3=B3:

 

It seems to me th= e context of the OMB guidance is relevant to the question of "IPv6-onl= y". The draft memo is reasonably good at this, but succinctly somethin= g like "agency internal networks use single-stack IPv6 with any 

<= div style=3D'margin-left:35.4pt'>

 

=

[Jordi] I= don=E2=80=99t think is so clear. Footnote 4 =E2=80=9CIPv6-Only refers to ne= twork environments in which use of the IPv4 protocol has been eliminated=E2= =80=9D will be much clear if it says =E2=80=9CIPv6-Only refers to network e= nvironments in which use of the *native* IPv4 protocol has been eliminated= =E2=80=9D.

<= div style=3D'margin-left:35.4pt'>

 

=

I don=E2=80=99t believe t= hat what you propose is the intent in the memo.

<= div>

 

I believe they = intend to eliminate the use of ALL IPv4, not just native IPv4 on government= networks.

 

*** Then there is a problem. If they really wa= nt to have ALL the way thru only IPv6 in the LANs, the federal employees wi= ll not be able to use *ANY* application that uses literal addresses = (even a simple web page that is doing that). Because there is NO transition= mechanism that allows that. They are able to force all their internal apps= to use only IPv6, fine, but they have no control over the rest of the Inte= rnet. If they are thinking that NAT64+DNS64 resolves that, they lost this = =E2=80=9Csmall=E2=80=9D bit in their thinking. I=E2=80=99ve already reporte= d them to the site that is asking for comments, hopefully they really pay a= ttention to the inputs.

 

I don=E2=80=99t s= ee that as a problem=E2=80=A6 I see that as a benefit.

=

 

I think that = the US Federal government is one of the few organizations in a position to = actually put the kind of pressure that will be necessary to effectuate this= change.

 

So, personally, I don=E2=80=99t see it so much as =E2=80=9C= they lost this in their thinking=E2=80=9D as in they are choosing to stop s= upporting certain =E2=80=9Cbroken by design=E2=80=9D ways of thinking.=

 

I hope that they stick to their guns and do not soften their position.

 

+++ Somehow, I a= gree, is not a =E2=80=9Cproblem=E2=80=9D, depending on how you see it. As moving on to a real IPv6-only world, it is good. B= ut we are interpreting the document as they really want that. They don=E2= =80=99t say explicitly, so we don=E2=80=99t know. If they want that effect,= I think it will be much better message to say =E2=80=9Cwe know this will c= reate this problem for people still using literal IPv4 addresses in web sit= es, but they should react if they want to work with us=E2=80=9D or whatever= .

 

If a Federal office decides to = have its DC with IPv6-only, then IPv4-only users will not be able to access= it. In that case the DC must use, for example SIIT-DC. That will mean that= the DC (internally) is IPv6-only, but the DC-to-Internet is dual-stack, in= order to be able to use SIIT-DC.

 

I believ= e that _IS_ the intent (no support for SIIT/NAT64/etc.).

 

Reme= mber, this is referring to the INTERNAL networks of the federal government = agencies=E2=80=A6 Not the public-facing networks.

 

Unless I misr= ead the memo, the intent is to preserve dual-stack functionality on public-= facing services, but ensure that there are no remaining IPv4 dependencies i= n providing those services over IPv6.

 

Furthermore,= footnote 5, =E2=80=9CNote that for public Internet services, maintaining v= iable IPv4 interfaces and transition mechanisms at the edge of service infr= astructure may be necessary for additional time, but this does not preclude= operating the backend infrastructure as IPv6-only.=E2=80=9D Is precisely s= aying that.

 

Correct.

<= /div>

 


It may happen that some of the LANs in the Federal office itself, are = dual-stack still. Otherwise, employees will not be able to use Internet res= ources that don=E2=80=99t work well with NAT64+DNS64, for example, web site= s or apps that use literal IPv4-addresses and are out of the control of the= Federal office. So, in this case they still need to use IPv4aaS.

 <= /p>

That=E2=80=99s not the desired outcome in this proc= ess.

 

Indeed, my impression is that the government i= s, through this memo, intending to put suppliers and web sites on notice th= at if they do not have IPv6 accessibility they are likely to lose their gov= ernment customers.

 

I see that as a good thing.

 =

*** I will be glad if they can se= nd this memo to every small web site in the world, because even if one of t= hem is missing it, and need to be accessed by the employees, will not work!=

 

I=E2=80=99m pretty sure that the employe= es that encounter difficulty will make it known to the web sites in questio= n.

 

+++ Not sure, it may get ignored, as they ignore problems i= n their deployment. Last time I tried to fill in the ESTA for traveling to = US, it was not working in some of the final steps. I did some debugging and= realized that they were dual stack, but filtering PTB, so because the MTU = at some point in the network, it never worked until I disabled IPv6 to comp= lete the form and pay the fee. I tried to tell them. I recall there was eve= n a thread about that in NANOG (talking from the top of my head, it may be = in a different list). They never responded or resolved it. I=E2=80=99m not = sure if now the problem is still there.

 

In reali= ty, in terms of actual job-related usage, the federal government is unlikel= y to need access to every small web site in the world. As a general rule, e= very small web site in the world has no ability to support things at the sc= ale of US Government usage.

<= o:p> 

+++ Sometimes this happens even in bigger sites =E2=80=A6 so ye= s and not.

 

If some employe can=E2=80=99t surf th= eir favorite mom-and-pop cat video site while they are supposed to be worki= ng for their taxpayer supported salary, I won=E2=80=99t actually be upset.<= o:p>

=  

= +++ =C2=A0Fully agree!

 

So from my perspective, this memo puts= government contractors on notice that their network-based systems providin= g services to the federal government damn well better fully support IPv6 in= the next few years, or they=E2=80=99re going to experience an increasing l= evel of disconnect followed by a very likely contract termination. I see th= is as a good thing.

 

+++ =C2=A0Fully agree! But some text= could make it more clear, so nobody believes =E2=80=9Cthey didn=E2=80=99t = though about this issue=E2=80=9D as I did.

 

O= wen

 

_______________________________________________ v6ops mailing list v6= ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3666853375_1296374745-- From nobody Thu Mar 12 02:32:42 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EAE3A03F5 for ; Thu, 12 Mar 2020 02:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWt_3NIDwrxi for ; Thu, 12 Mar 2020 02:32:35 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096F63A0437 for ; Thu, 12 Mar 2020 02:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1584005539; x=1584610339; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=iuN4JCET rbEhNG1h7Nrj/hEn130Rsrmn/Mu2+T2xdCg=; b=N0GDDW5L5swMg8fAELLi8ELN jRaALrdh12nhXcWaQ0DdIFvqPpHcn6HRqFRGWpUAHWEiEBvRb6tLSKrZ1n47tMtQ DWY1H29W7qcl8bVPlMZaCk70sSgCIqKuDKKuCS8/Ua6SqLVWYzyzzPdAb+XnKrqS pgh73JLNh9Z+BTNlMU8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 12 Mar 2020 10:32:19 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 12 Mar 2020 10:32:19 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000088917.msg for ; Thu, 12 Mar 2020 10:32:18 +0100 X-MDRemoteIP: 2001:470:1f09:495:e0a6:81ab:ea8d:1a06 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 12 Mar 2020 10:32:18 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1340af7d02=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Thu, 12 Mar 2020 10:32:15 +0100 From: JORDI PALET MARTINEZ To: v6ops Message-ID: Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <2020030818294834486735@chinatelecom.cn> <073925C4-5355-4C51-84A4-4D9545013552@delong.com> <4A5BDEE6-2B9E-4338-94C1-3BE9D6E37516@consulintel.es> <5c7debd563a04421be62d9e8f6c74cd1@irs.gov> In-Reply-To: <5c7debd563a04421be62d9e8f6c74cd1@irs.gov> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 09:32:41 -0000 Hi Scott, I worked for the equivalent Spanish government network (SARA) in the IPv6 d= eployment, so I understand how restritive is it. I think my responses to Owen also cover your points, to avoid repetition. I= can agree that they probably knew about the "issues", but as said, I think= is better the clearly say it "yes we know, we don't care, is up to you, if= you want to offer services to us". I just wrote them again, asking to read this discussion, in case they aren'= t already following it and considering including an explicit note about "ye= s, we know ... is your problem". =EF=BB=BFEl 10/3/20 20:29, "v6ops en nombre de Morizot Timothy S" e= scribi=C3=B3: =20 JORDI PALET MARTINEZ wrote: >*** Then there is a problem. If they really want to have ALL the way t= hru only IPv6 in the LANs, the federal employees >will not be able to use *ANY* application that uses literal addresses = (even a simple web page that is doing that). >Because there is NO transition mechanism that allows that. They are ab= le to force all their internal apps to use only >IPv6, fine, but they have no control over the rest of the Internet. If= they are thinking that NAT64+DNS64 resolves >that, they lost this =E2=80=9Csmall=E2=80=9D bit in their thinking. I= =E2=80=99ve already reported them to the site that is asking for comments, >hopefully they really pay attention to the inputs. =20 I'm intrigued that you believe that's inherently a problem. Perhaps you= 're not aware how restrictive US federal government networks often are? There are a great many things= on the Internet I cannot access from my work computer, even for official work purposes. For exam= ple, I am the designated representative for my organization with ARIN. But during remote participation, I could= not access jabber and cannot access slack from my work computer. I cannot access any conferen= cing platform from my work computer even for official, approved purposes. There are multip= le levels of firewalls when I am connected to the enterprise network, all operating in default deny= mode. My work computer presently has no direct access to any endpoint on the Internet. Every s= ervice allowed is proxied. And if things on the Internet do not work within our requirements, we d= on't use them. Now, removing even the perimeter service proxies to the public IPv4 Int= ernet would fall into that last 20% that does not yet have a specifically mandated date.= The emphasis, though, should likely be on *yet*. I know many of the people who contri= buted to the draft. I don't think they "lost" anything in their thinking. =20 >*** I will be glad if they can send this memo to every small web site = in the world, >because even if one of them is missing it, and need to be accessed by >the employees, will not work! =20 It's published in the Federal Register. Those interested in advance war= ning about the steps the US government is planning to take on their own networks have = it available. It will remain published by OMB when formally released. However, restri= cting access for federal employees is perfectly normal and occurs today for all sort= s of reasons. Our networks do not operate under the premise that any system on our network must be able to access any arbitrary system, service, site, or application on the Internet. In fact, more the opposite applie= s. =20 I believe Owen captured more the spirit and intent of this next step in the progression of the US federal government IPv6 transition. Despite the mandated dates, progress will almost certainly continue to be uneve= n across agencies. But the reporting requirements are something of a stick. Compliance wit= h regulations and other requirements tends to be one of the drivers in government decision-making, especially since profit is not normally the factor it is in commercial decision-making. =20 Scott =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Mar 12 03:23:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BD93A098A for ; Thu, 12 Mar 2020 03:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.999, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUCBxRq_Ix8C for ; Thu, 12 Mar 2020 03:23:46 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D840E3A094E for ; Thu, 12 Mar 2020 03:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1584008621; x=1584613421; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=2NEndHR80ku8I/EZssOVI4BO5nHRJqPpKd tbSt6w0So=; b=YEz6jneFhsdJWG8NKL0tJQi6MYHOL0SJU+h5u6wJeUdQVZxmrs 0aWbd5dU5mwS6egtUXnBmlOiuykX3ogiEZEpG6WrmEUsU7zOTkg3Cpiu4SjdaIZb sPerRuVCPOoKAD0g+TEFT72AEFN4dN/xh/sQ9OB+3OgF8G8Y+r3NrarAY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 12 Mar 2020 11:23:41 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 12 Mar 2020 11:23:40 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000088983.msg for ; Thu, 12 Mar 2020 11:23:39 +0100 X-MDRemoteIP: 2001:470:1f09:495:e0a6:81ab:ea8d:1a06 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 12 Mar 2020 11:23:39 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1340af7d02=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Thu, 12 Mar 2020 11:23:35 +0100 From: JORDI PALET MARTINEZ To: v6ops Message-ID: Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <2020030818294834486735@chinatelecom.cn> <2020031109031648115517@chinatelecom.cn> In-Reply-To: <2020031109031648115517@chinatelecom.cn> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3666857015_1265593401" Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 10:23:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3666857015_1265593401 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Chongfeng, =20 I think we basically agree then. =20 I=E2=80=99ve only one question. You said the access network is layer 2, rig= ht, this is common in many places, but on top of the layer 2, there is eith= er IPv6 only to the CE. If that=E2=80=99s the case, then my definition is s= till good (the CE may be running CLAT or whatever so IPv4 is somehow transp= orted on top of IPv6). Right? =20 Regards, Jordi @jordipalet =20 =20 =20 El 11/3/20 2:04, "v6ops en nombre de xiechf@chinatelecom.cn" escribi=C3=B3: =20 Hi, Jordi, Thank you for your consideration of my comments. Please find my new notes i= n-line below. =20 From: JORDI PALET MARTINEZ Date: 2020-03-09 16:32 To: v6ops Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" Hi Chongfeng, =20 Thanks for your inputs! =20 Below, in-line =E2=80=A6 =20 =20 =20 El 8/3/20 11:31, "v6ops en nombre de xiechf@chinatelecom.cn" escribi=C3=B3: =20 Hi, Jordi,=20 First , I agree with you that the definition of IPv6-only needs to consider= the what part of the network we are referring to, for example, ISP network= , IDC, Cloud platform and Service system should have their own specific def= inition of IPv6-only. I hope this draft can go on. Secondly. for ISP network, the definition of IPv6 should be based on whethe= r it can allocates only IPv6=20 =20 [Jordi] I don=E2=80=99t agree on this point. An ISP may have different part= s of its network with or without IPv6/IPv4, even different services, so I d= on=E2=80=99t think it can be split that way. =20 addresses to most of its customers for service provisioning, if yes, it can= be consider as IPv6-only. If it =20 [Jordi] Now, the part you mention as if it is allocating only IPv6 addresse= s, is also not valid, in my opinion. Because in some of the IPv6-only with = IPv4aaS, the ISP allocate private IPv4 addresses. =20 [Chongfeng] If ISP allocates IPv4 private address to large quatity of its = customers, it should not be considered as IPv6-only, this should be the bot= tom line. =20 allocates IPv4 address to most of its customers, then it is not IPv6-only. = My personal opionion is that the definition should not be based on whether = to eliminate IPv4 protocol in the network. At present stage, it is unreali= stic to eliminate IPv4 protocol in most networks, for the networks still ne= ed to provide access service to some customers who do not support IPv6-only= due to their poor-capability CPE or terminals. =20 [Jordi] I agree is unrealistic to disable IPv4 in most of the customer LANs= , but not in the access network. Until 90-99% of the home devices of an ISP= customers have IPv6 in their LAN devices, an IPv6 with IPv4aaS is needed. [Chongfeng] In China, access network adopts layer-two approach, it is ind= ependent to layer-three procotols. It seems to much more difficult to make= transition to IPv6 in wireline broadband network, due to the slow upgradat= ion of home routers. =20 Moreever, some networks still need to use IPv4 for network management . If = the definition it too strict, I guess none of the network can meet the stan= dard, including those who have deplyed 464XLAT. In addition, an IPv6-only n= etwork should be open and interconnected with OTTs and other ISPs, some clo= sed system, such as VoLTE in mobile network, should not be consider as IPv6= -only, even though it only allocates IPv6 addresses to it customer. =20 [Jordi] If IPv4 is used for management in the access network and provides n= ative IPv4 to the CE (for example), then it is not IPv6-only. We could say = in that case: This access network is IPv6-only for the customer service, bu= t still IPv4-only or dual-stack for the management. =20 [Jordi] So I still believe that the =E2=80=9Cnature=E2=80=9D of the definit= ion should be based in if IPv4 is used natively in a specific part of a net= work (then it is IPv6-only) or otherwise is IPv4-only or dual-stack. What d= o you think? [Chongfeng] In general, I agree with this point. =20 =20 Best regards Chongfeng=20 =20 From: JORDI PALET MARTINEZ Date: 2020-03-06 02:12 To: v6ops@ietf.org Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" If you read my draft, my opinion is different: =20 Definition of IPv6-only =20 Consequently, considering the context described in the section above, if we want to be precise and avoid confusing others, we can not use the terminology "IPv6-only" in a generic way, and we need to define what part of the network we are referring to. =20 From that perspective, we define the "IPv6-only" status in a given part(s) of a network, depending on if there is actual native forwarding of IPv4, so IPv4 is not configured neither managed. =20 So IPv4 may be not configured, or not used natively, but there is no way to= prevent that "is there" by means of tunneling of translation. =20 *unless* you make sure that any encapsulation or translation is filtered, w= hich is close to impossible. =20 Because we disagree, it seems clear that this document is needed. =20 So if anyone has inputs, I will consider them in a new version during the w= eekend. =20 Regards, Jordi @jordipalet =20 =EF=BB=BFEl 5/3/20 17:46, "v6ops en nombre de Owen DeLong" escribi=C3=B3: =20 =20 =20 > On Mar 5, 2020, at 6:02 AM, Alexandre Petrescu wrote: >=20 > Thank you very much for the pointer. In it I could spot > the following footnote: "[4] IPv6-Only refers to network environments= in > which use of the IPv4 protocol has been eliminated.=E2=80=9D =20 No. =20 IPv6-Only refers to network environments which are not using IPv4. That= could be a network where IPv4 has been eliminated (rare at this time, thou= gh Facebook is a significant example) or it could be a greenfield deploymen= t where IPv4 was never deployed. =20 >=20 > In my humble opinion, >=20 > I think, if I am not wrong, that there are no such networks in which > IPv4 protocol has been eliminated. On one hand, a network is made of > computers, and IPv4 stacks are still present in almost all computers. > On another hand, there might be some ptp links (not networks, but > individual links) that run IPv6 only. =20 You are wrong=E2=80=A6 There are examples at various levels of IPv6-onl= y networks. Many mobile carriers are IPv6-only in the US, though they do pr= ovide some apparent IPv4 capability to the end user through mechanisms such= as 464XLAT and/or NAT64.. =20 Another significant example is Facebook where they are essentially IPv6= -only throughout their network and provide minimal IPv4 translation shim at= the edge to cope with end users that lack IPv6 capability. =20 > That is why it is hard to agree on the assumption of IPv4 being elimi= nated somewhere. Worse, it makes look as if the goal of that 'IPv6-only' i= s to arrive at that same situation which in fact does use IPv4. =20 As a general rule, once IPv6 is ubiquitously deployed in a network, the= preservation of IPv4 in the majority of that network becomes an unnecessar= y cost factor and a security risk (increased attack surface, if nothing els= e). As such, I think you will see an increasing number of organizations fol= low on to the way Facebook has managed their transition and start eliminati= ng IPv4 wherever possible and replacing it with translation shims as far ou= t towards the border as practical. =20 Owen =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense.. If you are not the intended recipient be aware = that any disclosure, copying, distribution or use of the contents of this i= nformation, even if partially, including attached files, is strictly prohib= ited, will be considered a criminal offense, so you must reply to the origi= nal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3666857015_1265593401 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Chongfeng,

 

I think we basica= lly agree then.

 

I=E2=80=99ve only one question. You said the ac= cess network is layer 2, right, this is common in many places, but on top o= f the layer 2, there is either IPv6 only to the CE. If that=E2=80=99s the c= ase, then my definition is still good (the CE may be running CLAT or whatev= er so IPv4 is somehow transported on top of IPv6). Right?=

 

Regards,

=

Jordi

@jordipalet

 

<= o:p> 

 

<= div>

El 11/3/20 2:04,= "v6ops en nombre de xiechf@= chinatelecom.cn" <v6o= ps-bounces@ietf.org en nombre de xiechf@chinatelecom.cn> escribi=C3=B3:

 

Hi, Jordi,

<= span style=3D'font-family:"Microsoft YaHei UI",sans-serif'>Thank you for yo= ur consideration of my comments. Please find my new notes in-line below.

 

Date: 2020= -03-09 16:32

To: v6ops

Subje= ct: Re: [v6ops] About Req for Comments - "Trans= ition to IPv6"

Hi Chongfeng,

 <= /p>

Thanks for your inputs!<= /span>

 =

Below= , in-line =E2=80=A6

 

 

 

El 8/3/20 11:31, "v6ops en nombre de xiechf@chinatelecom.cn" <= v6ops-bounces@ietf.org en nom= bre de xiechf@chinatelecom.cn= > escribi=C3=B3:

 

Hi, Jordi, 

First ,= I agree with you that the definition of IPv6-only needs to consider the&nb= sp;what part of the network we are referring to, for example, ISP network, = IDC, Cloud platform and Service system should have their own specific defin= ition of IPv6-only.  I hope this draft can go on.

Secondly. for ISP network, the definition of IPv6 sho= uld be based on whether it can allocates only IPv6

 

[Jordi] I don=E2=80= =99t agree on this point. An ISP may have different parts of its network wi= th or without IPv6/IPv4, even different services, so I don=E2=80=99t think = it can be split that way.

 = ;

addresses to most of its custom= ers for service provisioning, if yes, it can be consider as IPv6-only. If i= t

 

[Jordi] Now, the part you mention as if it is allocating = only IPv6 addresses, is also not valid, in my opinion. Because in some of t= he IPv6-only with IPv4aaS, the ISP allocate private IPv4 addresses.<= o:p>

 =

[Chongfeng] If ISP allocat= es IPv4 private address to  large quatity of its customers, it should not b= e considered as IPv6-only, this should be the bottom line.

 

allocates IPv4 address to most of its customers, then it is not IPv6-only.= My personal opionion is that the d= efinition should not be based on whether to eliminate IPv4 protocol in the = network.  At present stage, it is unrealistic to eliminate IPv4 protoc= ol in most networks, for the networks still need to provide access service = to some customers who do not support IPv6-only due to their poor-capability= CPE or terminals.

 

[Jordi] I agree is unrealistic to disable IPv4 in mos= t of the customer LANs, but not in the access network. Until 90-99% of the = home devices of an ISP customers have IPv6 in their LAN devices, an IPv6 wi= th IPv4aaS is needed.

[Chongfeng]  In China, access network adopts  layer-two appr= oach, it is independent to layer-three procotols. It seems to much more dif= ficult  to make transition to IPv6 in wireline broadband network, due = to the slow upgradation of home routers.

 

Moreever, som= e networks still need to use IPv4 for network management . If the definition it too strict, I guess none = of the network can meet the standard, including those who have deplyed 464X= LAT. In addition, an IPv6-only network should be open and interconnected wi= th OTTs and other ISPs, some closed system, such as VoLTE in mobile network= , should not be consider as IPv6-only, even though it only allocates IPv6 a= ddresses to it customer.

 

[= Jordi] If IPv4 is used for management in the access network and provides na= tive IPv4 to the CE (for example), then it is not IPv6-only. We could say i= n that case: This access network is IPv6-only for the customer service, but= still IPv4-only or dual-stack for the management.

 

[Jordi] So I still believe that the= =E2=80=9Cnature=E2=80=9D of the definition should be based in if IPv4 is u= sed natively in a specific part of a network (then it is IPv6-only) or othe= rwise is IPv4-only or dual-stack. What do you think?

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'> [Chongfeng] In general, I agree with this point.

 

 

Best regards<= /o:p>

Chongfeng 

 

Date: 2= 020-03-06 02:12

To: v6ops@ietf.org

Subject: Re: [v6ops] About Req for Comments - "T= ransition to IPv6"

If you read my draft, my op= inion is different:

 

  Definition of IPv6-only

 =

 &nbs= p; Consequently, considering the context described in the section above,

&n= bsp;  if we want to be precise and avoid confusing others, we can not = use

   the terminology "IPv6-only" in a generic way, an= d we need to define

   what part of the network we are referring = to.

 

   From that perspective, we define the "IPv6-onl= y" status in a given

   part(s) of a network, depending on i= f there is actual native

   forwarding of IPv4, so IPv4 is not co= nfigured neither managed.

 

So IPv4 may be not configured, or not used= natively, but there is no way to prevent that "is there" by mean= s of tunneling of translation.

 

*unless* you make sure that any encap= sulation or translation is filtered, which is close to impossible.

 

B= ecause we disagree, it seems clear that this document is needed.=

 

So = if anyone has inputs, I will consider them in a new version during the week= end.

 

Regards,

Jordi

@jordipalet

 

=EF=BB=BFEl 5/3/20 17:46, "v6ops en nombre de= Owen DeLong" <v6ops-bounces@ietf.org en nombre de owen@delong.com&= gt; escribi=C3=B3:

 

   

   

 &nb= sp;  > On Mar 5, 2020, at 6:02 AM, Alexandre Petrescu <alexandre= .petrescu@gmail.com> wrote:

    >

    = > Thank you very much for the pointer.  In it I could spot

 &n= bsp;  > the following footnote: "[4] IPv6-Only refers to netwo= rk environments in

    > which use of the IPv4 protocol h= as been eliminated.=E2=80=9D

   

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>    No.

&nb= sp;  

    IPv6-Only refers to network environment= s which are not using IPv4. That could be a network where IPv4 has been eli= minated (rare at this time, though Facebook is a significant example) or it= could be a greenfield deployment where IPv4 was never deployed.=

 &nbs= p; 

    >

    > In my humble opi= nion,

    >

    > I think, if I am not= wrong, that there are no such networks in which

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>    > IP= v4 protocol has been eliminated.  On one hand, a network is made of

&n= bsp;   > computers, and IPv4 stacks are still present in almos= t all computers.

    > On another hand, there might be so= me ptp links (not networks, but

    > individual links) t= hat run IPv6 only.

   

    You are wrong=E2= =80=A6 There are examples at various levels of IPv6-only networks. Many mob= ile carriers are IPv6-only in the US, though they do provide some apparent = IPv4 capability to the end user through mechanisms such as 464XLAT and/or N= AT64..

   

    Another significant example i= s Facebook where they are essentially IPv6-only throughout their network an= d provide minimal IPv4 translation shim at the edge to cope with end users = that lack IPv6 capability.

   

    > That is why it is hard to agree on= the assumption of IPv4 being eliminated somewhere.  Worse, it makes l= ook as if the goal of that 'IPv6-only' is to arrive at that same situation = which in fact does use IPv4.

   

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>    As a ge= neral rule, once IPv6 is ubiquitously deployed in a network, the preservati= on of IPv4 in the majority of that network becomes an unnecessary cost fact= or and a security risk (increased attack surface, if nothing else). As such= , I think you will see an increasing number of organizations follow on to t= he way Facebook has managed their transition and start eliminating IPv4 whe= rever possible and replacing it with translation shims as far out towards t= he border as practical.

   

    Owen

 &= nbsp; 

   

    _______________________= ________________________

    v6ops mailing list

  =   v6ops@ietf.org

    https://www.ietf.org/mailman/lis= tinfo/v6ops

   

 

 

 

**********************= ************************

IPv4 is over

Are you ready for the new Internet ?<= o:p>

= http://www.theipv6company.com

The IPv6 Company

 

<= div>

This electronic messa= ge contains information which may be privileged or confidential. The inform= ation is intended to be for the exclusive use of the individual(s) named ab= ove and further non-explicilty authorized disclosure, copying, distribution= or use of the contents of this information, even if partially, including a= ttached files, is strictly prohibited and will be considered a criminal off= ense.. If you are not the intended recipient be aware that any disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited, will be conside= red a criminal offense, so you must reply to the original sender to inform = about this communication and delete it.

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'> 

 

____________= ___________________________________

v6ops mailing list

=

v6ops@ietf.org<= /o:p>

https://www.= ietf.org/mailman/listinfo/v6ops

_____________________________= __________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/m= ailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you= ready for the new Internet ?
http://www.theipv6company.com
The IPv6 = Company

This electronic message contains information which may be pr= ivileged or confidential. The information is intended to be for the exclusi= ve use of the individual(s) named above and further non-explicilty authoriz= ed disclosure, copying, distribution or use of the contents of this informa= tion, even if partially, including attached files, is strictly prohibited a= nd will be considered a criminal offense. If you are not the intended recip= ient be aware that any disclosure, copying, distribution or use of the cont= ents of this information, even if partially, including attached files, is s= trictly prohibited, will be considered a criminal offense, so you must repl= y to the original sender to inform about this communication and delete it.<= o:p>

_______________________________________________ v6ops mailing= list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3666857015_1265593401-- From nobody Thu Mar 12 03:33:21 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001A83A09CD for ; Thu, 12 Mar 2020 03:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFDXCqkgsoZU for ; Thu, 12 Mar 2020 03:33:18 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7869A3A09D2 for ; Thu, 12 Mar 2020 03:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1584009195; x=1584613995; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=qU0YxIRa MRNEQ7VRXfTFVlRPU9cIqVRQxUwlxatEw7Y=; b=s36gBBWOJ9Cyl4IxKOpbad3O 628q1wfVYdWrR7hkaERhaKbb1Q1x8xIALWVdMSICd1JMS6tS+1Hhfi1KP5P3AUtP ORxMwLS1ffw61I6lcakNHqjQb0sMppFLU44YydvmtOeS6c18k4MUHQrKoOHTZc2P DuY2Fa+USLVjSVzOS7s= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 12 Mar 2020 11:33:15 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 12 Mar 2020 11:33:15 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000088993.msg for ; Thu, 12 Mar 2020 11:33:14 +0100 X-MDRemoteIP: 2001:470:1f09:495:e0a6:81ab:ea8d:1a06 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 12 Mar 2020 11:33:14 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1340af7d02=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Thu, 12 Mar 2020 11:33:11 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <3567F570-BC40-470E-971B-2368E1ACD80C@gmail.com> In-Reply-To: <3567F570-BC40-470E-971B-2368E1ACD80C@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 10:33:20 -0000 Hi Fred, In my document, instead of network, I try to explain that "what part of the= network" should be explicited. If you use IPv6-only network, then we mean "the complete network". If you want to say in the WAN/access network, this is clear as well. I think using scenario will present the same problem. If we call scenario a= given network, we are talking about the full network. If we say WAN-scenar= io, is the same as WAN-network, we are just expliciting that is not the ful= l network, but only that specific part. I know that you are talking here about the OMB document, but I will like to= understad if you think (hat-off) the way the document try to work on this = terminology is good enough, or you suggest any changes. Thanks! =EF=BB=BFEl 12/3/20 3:07, "v6ops en nombre de Fred Baker" escribi=C3=B3: =20 =20 > On Mar 5, 2020, at 8:46 AM, Owen DeLong wrote: >=20 >> Thank you very much for the pointer. In it I could spot >> the following footnote: "[4] IPv6-Only refers to network environment= s in >> which use of the IPv4 protocol has been eliminated.=E2=80=9D >=20 > IPv6-Only refers to network environments which are not using IPv4. Th= at could be a network where IPv4 has been eliminated (rare at this time, th= ough Facebook is a significant example) or it could be a greenfield deploym= ent where IPv4 was never deployed. =20 =20 This, I think, is where the v6ops discussion has travelled in circles f= orever. To me, I would drop the word "network" and say that it is a specifi= ed environment. If I say that a system is IPv6-only, it is not using IPv6 i= nternally or externally. It might or might not have IPv4 code in it, but it= 's not using it. If I say that a LAN, building, etc is IPv6-only, it is not= to say that it couldn't have IPv4 in it if a DHCP server started handing o= ut such addresses, but that it *doesn't*. If it is an Autonomous System, it= means that only IPv6 is in use in that domain. =20 As soon as we get into the "but it could" or "was it translated from so= mething else" or whatever rathole, we're into a discussion of angels, pins,= and heads of pins. It will not end, because it can't. Someone will forever= come up with a "what if" scenario to stir the pot. =20 Speaking for myself, I would have the user of the term identify the env= ironment s/he is talking about, and say that *within*that*domain* communica= tion is entirely accomplished using IPv6. =20 And STOP. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Mar 12 03:44:51 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801B63A0A7E for ; Thu, 12 Mar 2020 03:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35R55-vC00-7 for ; Thu, 12 Mar 2020 03:44:48 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745B53A0A53 for ; Thu, 12 Mar 2020 03:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1584009885; x=1584614685; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=8hTmHJFm 1k2uS60GL6VwUkXNszSz3RlS9C2LuR/49UM=; b=KiMtvOEvg2gPgi5yqaoaauPm 30k7DrtK/TEIuowiHxsQsT2uOR2kjWB2nNq46DWtP3r+9hyo4Ym0KSxmqUtijmYx aIUymBjTLRLHL+r9DA55pbANQlhU5jsVwfqbH0r7IEfnESwFy7jS/vMYob/ztJmy dak5BDCiB3VClTmwxbU= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 12 Mar 2020 11:44:45 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 12 Mar 2020 11:44:44 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000089001.msg for ; Thu, 12 Mar 2020 11:44:44 +0100 X-MDRemoteIP: 2001:470:1f09:495:e0a6:81ab:ea8d:1a06 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 12 Mar 2020 11:44:44 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1340af7d02=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Thu, 12 Mar 2020 11:44:43 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] IPv6-only Terminology Definition References: <4A886236-7D17-41F2-8291-0BC1B49F7A59@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6-only Terminology Definition X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 10:44:50 -0000 Yes, sorry, there is a typo there. However, the "end-networks", in general, need to continue supporting IPv4, as there are many devices or apps, in both corporate and end- user networks (smartTV, IP cameras, etc.), which are IPv4-only and i= t is not always feasible to update or replace them. Also if customer devices in a LAN are ***IPv4-only***, they will not be able to acces= s IPv6-only services, so this means that IPv6-only services can't be deployed unless it is done in such way that some transition mechanis= m solves that problem as well (example an IPv6-only Data Center, requires SIIT-DC) I've corrected in my internal draft v-06, but will wait for more inputs bef= ore publishing it. Or maybe we could even consider a call for WG adoption? Thanks for spotting it! =EF=BB=BFEl 12/3/20 7:58, "v6ops en nombre de Fred Baker" escribi=C3=B3: Section 2, fourth paragraph. =20 However, the "end-networks", in general, need to continue supporting IPv4, as there are many devices or apps, in both corporate and end- user networks (smartTV, IP cameras, etc.), which are IPv4-only and i= t is not always feasible to update or replace them. Also if customer devices in a LAN are IPv6-only, they will not be able to access IPv6-only services, so this means that IPv6-only services can't be deployed unless it is done in such way that some transition mechanis= m solves that problem as well (example an IPv6-only Data Center, requires SIIT-DC) =20 I don't understand why an IPv6-only device would not be able to access = an IPv6-only services. I can understand IPv4-only devices not being able to= access IPv6-only services, but that's not the statement. This paragraph se= ems to not follow. =20 > On Mar 9, 2020, at 11:47 AM, JORDI PALET MARTINEZ wrote: >=20 > Hi all, >=20 > After the recent discussion, I've posted a new version (minor changes= ) for this document: >=20 > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/?include= _text=3D1 >=20 > Comments welcome! >=20 > Regards, > Jordi > @jordipalet >=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > 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 disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Mar 12 04:04:58 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0AB3A0D38 for ; Thu, 12 Mar 2020 04:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm8Bb9gi80uA for ; Thu, 12 Mar 2020 04:04:48 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EEE43A0CE7 for ; Thu, 12 Mar 2020 04:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1584011085; x=1584615885; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=XU758j8z 5qeYH4JWs+OtsImaVkKMs8oN2APkPZjatSQ=; b=rIH8Pkm5lDcI46nUibYiIPkh E3UD3u/izorf3r2k5JVCZNPZMyFnb4gmqcTrXAk6LfSsEBJMDi210PMDMljtKqkr yjMX7+2VXxg1PYOUO5V0l85gqFHX9LkIqAff+V1tDr6X9caxktC+HnQI1rRtX4PF UpA59B6M7uHSg93RQN0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 12 Mar 2020 12:04:45 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 12 Mar 2020 12:04:45 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000089019.msg for ; Thu, 12 Mar 2020 12:04:45 +0100 X-MDRemoteIP: 2001:470:1f09:495:e0a6:81ab:ea8d:1a06 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 12 Mar 2020 12:04:45 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1340af7d02=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Thu, 12 Mar 2020 12:04:44 +0100 From: JORDI PALET MARTINEZ To: Message-ID: <1C8D1394-B226-4727-9E01-853A6CEA35AF@consulintel.es> Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <3567F570-BC40-470E-971B-2368E1ACD80C@gmail.com> <1FC68A89-A5E2-4FF3-836C-5AEC3D295299@delong.com> In-Reply-To: <1FC68A89-A5E2-4FF3-836C-5AEC3D295299@delong.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 11:04:57 -0000 + Any environment where IPv4 usage has been discontinued and IPv6 is the sole remaining active protocol OR + Any environment where IPv4 was never deployed and IPv6 is the only protocol ever deployed It was in response to a statement that IPv6-only could only mean an environment where IPv4 once existed and had been removed. [Jordi] I think we agree in that, if at the same time we don't exclude that this scenario may have (end-to-end) some form of IPv4-transport or tunnel on top of IPv6, unless it is specifically "filtered" or "avoided" by the network (obvious security reasons). So, in those cases, I think it should be stated as well, to make it clear. Is the same as if you have a lot of security filtering in the firewall, but you allow an employee to setup a VPN ... I think I could include something about that in the next version, to make it clear. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com 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 nobody Thu Mar 12 04:18:01 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B833A0C82 for ; Thu, 12 Mar 2020 04:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bevvyT3weore for ; Thu, 12 Mar 2020 04:17:58 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4106D3A0C69 for ; Thu, 12 Mar 2020 04:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1584011875; x=1584616675; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=jkA370X2 K0AI/7VrtpirSi1/G3cGMLOsJa11ywUTapw=; b=Zlq9IyIGLo3UlCjaRcfihybH YugG3GsRwW8HbRI79jiYhsKk9rDdxIVktC0aRi+VYByTCwV1pQO68s2g15ntioc3 yFB6yw8QKZB9Dr51NWjuBqMCY28juMV6dBUQAdkJCkWU8eF0Ln9KxtVlODtWI/vH /4VUSCM2RPpLjiqr4jg= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 12 Mar 2020 12:17:55 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 12 Mar 2020 12:17:55 +0100 Received: from [10.10.10.144] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000089056.msg for ; Thu, 12 Mar 2020 12:17:55 +0100 X-MDRemoteIP: 2001:470:1f09:495:e0a6:81ab:ea8d:1a06 X-MDHelo: [10.10.10.144] X-MDArrival-Date: Thu, 12 Mar 2020 12:17:55 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1340af7d02=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Thu, 12 Mar 2020 12:17:50 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <3567F570-BC40-470E-971B-2368E1ACD80C@gmail.com> <1FC68A89-A5E2-4FF3-836C-5AEC3D295299@delong.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 11:18:00 -0000 Would this work? 12. IPv4 Exclusion If an IPv6-only network or part of it, has strict filtering rules to avoid IPv4 to be transported on top of IPv6, this should be explicitly cited. For example, and enterprise LAN, where employees can't use VPNs, tunnels, or even translations, could be named as "IPv6-only LAN with IPv4 Exclusion". =20 =EF=BB=BFEl 12/3/20 12:04, "JORDI PALET MARTINEZ" escribi=C3=B3: + Any environment where IPv4 usage has been discontinued and IPv6 = is the sole remaining active protocol OR + Any environment where IPv4 was never deployed and IPv6 is the on= ly protocol ever deployed =20 It was in response to a statement that IPv6-only could only mean an= environment where IPv4 once existed and had been removed. =20 =20 [Jordi] I think we agree in that, if at the same time we don't exclude = that this scenario may have (end-to-end) some form of IPv4-transport or tun= nel on top of IPv6, unless it is specifically "filtered" or "avoided" by th= e network (obvious security reasons). =20 So, in those cases, I think it should be stated as well, to make it cle= ar. =20 Is the same as if you have a lot of security filtering in the firewall,= but you allow an employee to setup a VPN ... =20 I think I could include something about that in the next version, to ma= ke it clear. =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Mar 12 04:59:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6753A0E6A for ; Thu, 12 Mar 2020 04:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OYDPRGs5uGH for ; Thu, 12 Mar 2020 04:59:47 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716B63A0E79 for ; Thu, 12 Mar 2020 04:59:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02CBxiAU031017 for ; Thu, 12 Mar 2020 12:59:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 458A1201461 for ; Thu, 12 Mar 2020 12:59:44 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3B74B205A49 for ; Thu, 12 Mar 2020 12:59:44 +0100 (CET) Received: from [10.11.240.10] ([10.11.240.10]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02CBxhXX010337 for ; Thu, 12 Mar 2020 12:59:43 +0100 To: v6ops@ietf.org References: <4A886236-7D17-41F2-8291-0BC1B49F7A59@consulintel.es> From: Alexandre Petrescu Message-ID: <21fea5fa-9cd4-6180-25fd-96db910c974b@gmail.com> Date: Thu, 12 Mar 2020 12:59:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6-only Terminology Definition X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 11:59:49 -0000 Le 12/03/2020 à 11:44, JORDI PALET MARTINEZ a écrit : > Yes, sorry, there is a typo there. > > However, the "end-networks", in general, need to continue supporting > IPv4, as there are many devices or apps, in both corporate and end- > user networks (smartTV, IP cameras, etc.), which are IPv4-only and it > is not always feasible to update or replace them. Also if customer > devices in a LAN are ***IPv4-only***, they will not be able to access > IPv6-only services, so this means that IPv6-only services can't be > deployed unless it is done in such way that some transition mechanism > solves that problem as well (example an IPv6-only Data Center, > requires SIIT-DC) > > > I've corrected in my internal draft v-06, but will wait for more inputs before publishing it. > > Or maybe we could even consider a call for WG adoption? If call for adoption there is, I will be supportive. As usual, I will suggest to say somewhere in an appendix or so, that a possible definition of IPv6-only is "no IPv4 stack in linux kernel, unchecked IPv4 in Windows interface properties, no A entry in DNS and no 127.0.0.1 in /etc/hosts". I would also suggest the use of the term IPv4-only, in a similar mannner. Or maybe one wants to be silent about IPv4-only. Finally, from an earlier conversation I remember the term "double stack" which would be clearer than the existing but ambiguous "dual stack". Alex > > Thanks for spotting it! > > > El 12/3/20 7:58, "v6ops en nombre de Fred Baker" escribió: > > Section 2, fourth paragraph. > > However, the "end-networks", in general, need to continue supporting > IPv4, as there are many devices or apps, in both corporate and end- > user networks (smartTV, IP cameras, etc.), which are IPv4-only and it > is not always feasible to update or replace them. Also if customer > devices in a LAN are IPv6-only, they will not be able to access > IPv6-only services, so this means that IPv6-only services can't be > deployed unless it is done in such way that some transition mechanism > solves that problem as well (example an IPv6-only Data Center, > requires SIIT-DC) > > I don't understand why an IPv6-only device would not be able to access an IPv6-only services. I can understand IPv4-only devices not being able to access IPv6-only services, but that's not the statement. This paragraph seems to not follow. > > > On Mar 9, 2020, at 11:47 AM, JORDI PALET MARTINEZ wrote: > > > > Hi all, > > > > After the recent discussion, I've posted a new version (minor changes) for this document: > > > > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/?include_text=1 > > > > Comments welcome! > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > 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 > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > 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 > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Mar 12 14:10:15 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7813A0973; Thu, 12 Mar 2020 14:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8GLY2E2-ET4; Thu, 12 Mar 2020 14:09:59 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764D03A096E; Thu, 12 Mar 2020 14:09:59 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6A78454842E; Thu, 12 Mar 2020 22:09:54 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 63E52440040; Thu, 12 Mar 2020 22:09:54 +0100 (CET) Date: Thu, 12 Mar 2020 22:09:54 +0100 From: Toerless Eckert To: Jen Linkova Cc: 6man <6man@ietf.org>, V6 Ops List , bier@ietf.org Message-ID: <20200312210954.GA34894@faui48f.informatik.uni-erlangen.de> References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 21:10:01 -0000 On Thu, Mar 12, 2020 at 11:33:37AM +1100, Jen Linkova wrote: > I believe it depends what you are trying to achieve. If you want to > make sure that the traffic never leaves the network - then hop limit = > 1 helps. But using link-local sources/destinations would help even > better if the routers comply with RFC4291 Section 2.5.6 Yes, i am assuming 2.5.6 is mandatory given how this is standards track and how abence of RFC2119 langauge does not render "must" into a non standard requirement. > If you want to make sure those packets are not sent by a malicious > party from outside - hop limit shall be 255. > For example, see RFC4861 Section 3.1 > Neighbor Discovery. Ah, nice. I never looked into all those encoding details. Thanks. Preceeding RFC5082 and hence not referring to it, and neither does RFC5082 refer to RFC4861, thats why i couldn't easily find it by sea4rching. > > There is an additional set of consideration re. link-local traffic > > when trying to use it as a HW accelerated tunneling mechanism across links, > > a use we both have in ANIMA, and maybe get the same in BIER (probably > > other WGs too, not sure). > > > > In implementations, i have seen quite a range of issues with > > accelerated forwarding planes across link-local addressed tunnels, > > and when using non-link-local addresses (loopback addresses), > > the HW plane forwarding might have issues doing HW forwarding, because > > usually TTL=1 is only used for control plane traffic. Of course, > > this is not a good architectural argument, but if given architectural > > leeway to even choose 42, maybe GTSM/255 is easier to be supported > > across various HW accelerated forwarding planes than 1. > > > > Opinions and experiences welcome! > > If you control the router I'd say 'link-local source/destination, > HL=255 AND RFC4291 would be the best option. RFC4291 seems redundant given how its mandatory anyhow, but of course helpfull to remind readers of new specs. Given how 4291 is widely deployed it certainly qualifies well as sufficient proof of the mechanism widely deployed - for control plane. So, effectively, architcturally, the sending TTL is a choice of the application, and for control plane apps, we evolved choosing from 1 first and now BCP is 255. Coming from multicast, i kinda grew up with the belief there is a MUST use TTL=1 somewhere for a long time (when using link-local addresses), but never verified that belief. Still hesitant of prescribing 255 for hardware accelerated forwarding plane use case, but given how link-local tunnels aren't really a thing it would be hard to find prior evidence of successful wide deployment. Given how i tinkered with them, i've seen all type of troubles, including TTL ones. > I did see a few devices somewhere far away sending me ICMPv6 (packet > too big) from their link-local addresses but it was not very common > case. Agree. same here. Thanks & Cheers Toerless > > -- > SY, Jen Linkova aka Furry -- --- tte@cs.fau.de From nobody Thu Mar 12 14:21:00 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF4E3A0033; Thu, 12 Mar 2020 14:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_P6KTtTWiLP; Thu, 12 Mar 2020 14:20:30 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C85D3A0031; Thu, 12 Mar 2020 14:20:30 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id 23so3906021pfj.1; Thu, 12 Mar 2020 14:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :cc:to; bh=oesEDjQgV3rwtOj9y+6hKLrleKLG/qkJczgPKG8ag90=; b=hNQGc0QtGquz5m8JOtY2ZI6UPQn8puvA8KEoTZCHpUZGMr0bMiyrpc3vRd5AjXHSjz PyxpM7Axf+/D0t7GCypw0tmpk13/g1SlevBDdzPFVbNllGqGw5+rWSPe7R4uyXp995tK HiDvkEBMy/XdcZ7dGSsvnI9GJi7MZ2bT/LRQ9OD2eX2UMpr0bPULXxaGb+8PtsAv4Qtu mhaHL4BptXjRSyVMXbaDBfZtCOKXyWB6jMHLvnkepWshRBYyAabc9NaTaRvE3NxOGRzl 27jgnB9NWlhQdFEpas0jyESyQ14slJKsSa5KEIUyivPSHvduAJ9j/0rgC4niaP/glSgm ahtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:cc:to; bh=oesEDjQgV3rwtOj9y+6hKLrleKLG/qkJczgPKG8ag90=; b=XD1se4tlN9SXs2V6kpRjxueLaXb4PhTCBH+nD0Mj2MKcj9i7ypfir0iTrjeH0EuDpW aCKcGodvUZnYXuVGgHVC7t2P2TxGZZssiZwzK5ssZiCFiP84fkMBYvThMfywRLytCxvx 2YXd+4TT/JnXgcdRYkZZfv0aUGwGMHdkI6jnwBTpoko3PtpCl4YjYp1n33njid3Ta7Cj cS+CJBMWJO4T3P7J62WQ1YNVZ9ka9oAMFDOwSWnUlLptWHy+teXJ1Bd5r7fVfD7Aou6T EPBblBXnl6UVfAlTYitmo/Yv5PwfOD2j2iD+Ox0dbPY6pZDjhSAcYQeKL5QKOv9SwOQL QATw== X-Gm-Message-State: ANhLgQ1+EfKLXb71aGdd4Cs3U3Jk7iei1Cfoa+NzqJVaTx4i4LgEYU9b 7aoeJ3NavfPq6Qxi3838Wyd/szYw X-Google-Smtp-Source: ADFU+vvuD/Rib/h4J31FsqqjpmOG1QnzsM9mwiUyxfQrp8DZz1r5mSl4iC3Yr6a9nuDhXtTJxjyaKg== X-Received: by 2002:a63:f447:: with SMTP id p7mr9670427pgk.326.1584048029686; Thu, 12 Mar 2020 14:20:29 -0700 (PDT) Received: from ?IPv6:2607:fb90:56a9:911:546c:d2b0:8660:64d0? ([2607:fb90:56a9:911:546c:d2b0:8660:64d0]) by smtp.gmail.com with ESMTPSA id 13sm55478620pfi.78.2020.03.12.14.20.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2020 14:20:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Fred Baker Mime-Version: 1.0 (1.0) Date: Thu, 12 Mar 2020 14:20:27 -0700 Message-Id: <27D9F4C1-C338-45AE-9C6E-D1B97AD8D0A2@gmail.com> Cc: V6Ops Chairs , Warren Kumari To: "v6ops@ietf.org list" X-Mailer: iPhone Mail (17D50) Archived-At: Subject: [v6ops] Current plans for V6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 21:20:32 -0000 Early planning for V6ops 107... Alissa will be circulating a email regardingvIETF plans. I won=E2=80=99t ste= al her thunder (watch for her email), but the way it affects us is that ther= e will be virtual meetings when and where appropriate, but working groups li= ke ours will need to decide how much we need that and how much we can do in e= mail. Ron and are of the opinion that we usually follow IETF meetings with focused= list discussion, and in this case can probably get by with list discussion.= We have five drafts that are either ready for working group last call or c= lose enough that we can surface remaining issues in a WGLC context. So, thro= ugh April and May we plan to literally do that. Watch for Ron=E2=80=99s =E2=80= =9Cyour comment solicited=E2=80=9D notes. We=E2=80=99re also looking hard at the =E2=80=9Cwe Doing something with IPv6= , perhaps IPv6-only=E2=80=9D talks we have been having. Our perception is th= at they have been well received. We have four or five parties that want to b= e on the list right now, and I expect there will be more. My solicitation: I= =E2=80=99d like to hear more, especially from Enterprise. Volunteers? Along those lines, we have had a suggestion that we schedule a batch of them= at IETF 108 in Madrid. Would that be interesting? Responses may be public or to V6ops-chairs@ietf.org, at your discretion. Also soliciting drafts on new topics. As usual, it need to be an Internet dr= aft and have supportive commentary on the list. Sent using a machine that autocorrects in interesting ways...= From nobody Thu Mar 12 14:36:20 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9697D3A053F; Thu, 12 Mar 2020 14:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEfVGlj5rS7R; Thu, 12 Mar 2020 14:36:08 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857DA3A04BB; Thu, 12 Mar 2020 14:36:07 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id CADD954842F; Thu, 12 Mar 2020 22:36:01 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C41F0440040; Thu, 12 Mar 2020 22:36:01 +0100 (CET) Date: Thu, 12 Mar 2020 22:36:01 +0100 From: Toerless Eckert To: Mark Smith Cc: 6MAN <6man@ietf.org>, v6ops list , bier@ietf.org Message-ID: <20200312213601.GB34894@faui48f.informatik.uni-erlangen.de> References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 21:36:10 -0000 On Thu, Mar 12, 2020 at 12:18:32PM +1100, Mark Smith wrote: > RFC4007 allows packets with link-local destinations to be forwarded > by a router, but only back onto the same link: Oh, my favourite coffin nail RFC. > "Thus, if a > router receives a packet with a link-local destination address that > is not one of the router's own link-local addresses on the arrival > link, the router is expected to try to forward the packet to the > destination on that link (subject to successful determination of the > destination's link-layer address via the Neighbor Discovery protocol > [9]). The forwarded packet may be transmitted back through the > arrival interface, or through any other interface attached to the > same link." > > > I think in theory that could also mean forwarded to another router on > the link that then forwards back again onto the link etc., so it is > valid for a packet with a link-local destination address to have an > initial Hop Count value that allows it to be forwarded by multiple > routers, all limited to being forwarded within the same link. So this behavior breaks both TTL=1 and RFC5082 packets. Nice. This RFC is getting better every time i learn more of it. > This draft might be useful, as it collects together and summarises > information about using Link-Local Addresses (and is something I've > been meaning to get back to updating, suggestions welcome): > > How to use IPv6 Link-Local Addresses in Applications > https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00 Nice. Let me split that off. cheers Toerless From nobody Thu Mar 12 16:32:05 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18503A0888 for ; Thu, 12 Mar 2020 16:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZGF4xRxeWsR for ; Thu, 12 Mar 2020 16:32:00 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0E53A0885 for ; Thu, 12 Mar 2020 16:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1584055917; x=1584660717; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=MWHF1qIP MfyrleR1M+t49+W6JWrOCIUNZMqXQFzqR6k=; b=wpb/2S3l8uIFchRLl/rcz5/B NDtQAZKtMsL8R3ZiqdHmZ9SRksgPkxvwadU36Og+YhorkxfaJEHaeHu6F6qnb33B VKFL2dVLKiUc6TOqRZoQyFDNjVPIn0ywpkBTFze/HuE+JIM0oqbDM3DGlFbXrKXQ LBFK2dielto7qXo19sk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 13 Mar 2020 00:31:57 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 13 Mar 2020 00:31:57 +0100 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000089720.msg for ; Fri, 13 Mar 2020 00:31:56 +0100 X-MDRemoteIP: 2001:470:1f09:495:3843:cce2:1d3a:4541 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Fri, 13 Mar 2020 00:31:56 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1340af7d02=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Fri, 13 Mar 2020 00:31:53 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: <5C68E7EA-7BE9-4CE2-896E-21DC9D62527A@consulintel.es> Thread-Topic: [v6ops] Current plans for V6ops References: <27D9F4C1-C338-45AE-9C6E-D1B97AD8D0A2@gmail.com> In-Reply-To: <27D9F4C1-C338-45AE-9C6E-D1B97AD8D0A2@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Current plans for V6ops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 23:32:04 -0000 Hi Fred, I could offer a talk about 25 million subscribers with 464XLAT (DSL, GPON a= nd cellular), I can't yet disclose the details, but it should be possible f= or Madrid IETF108. Probably also a couple of IPv6-only enterprise networks (ministries of a gi= ven country). Regards, Jordi @jordipalet =20 =20 =EF=BB=BFEl 12/3/20 22:21, "v6ops en nombre de Fred Baker" escribi=C3=B3: Early planning for V6ops 107... =20 Alissa will be circulating a email regardingvIETF plans. I won=E2=80=99= t steal her thunder (watch for her email), but the way it affects us is tha= t there will be virtual meetings when and where appropriate, but working gr= oups like ours will need to decide how much we need that and how much we ca= n do in email. =20 Ron and are of the opinion that we usually follow IETF meetings with fo= cused list discussion, and in this case can probably get by with list discu= ssion. We have five drafts that are either ready for working group last cal= l or close enough that we can surface remaining issues in a WGLC context. = So, through April and May we plan to literally do that. Watch for Ron=E2=80= =99s =E2=80=9Cyour comment solicited=E2=80=9D notes. =20 We=E2=80=99re also looking hard at the =E2=80=9Cwe Doing something with= IPv6, perhaps IPv6-only=E2=80=9D talks we have been having. Our perception= is that they have been well received. We have four or five parties that wa= nt to be on the list right now, and I expect there will be more. My solicit= ation: I=E2=80=99d like to hear more, especially from Enterprise. Volunteer= s? =20 Along those lines, we have had a suggestion that we schedule a batch of= them at IETF 108 in Madrid. Would that be interesting? =20 Responses may be public or to V6ops-chairs@ietf.org, at your discretion= . =20 Also soliciting drafts on new topics. As usual, it need to be an Intern= et draft and have supportive commentary on the list. =20 Sent using a machine that autocorrects in interesting ways... _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Mar 12 16:50:04 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D891A3A097C; Thu, 12 Mar 2020 16:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQrBKjXWtNKs; Thu, 12 Mar 2020 16:49:50 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82D53A0970; Thu, 12 Mar 2020 16:49:50 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id d63so7477219oig.6; Thu, 12 Mar 2020 16:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XU0LdsXsBe6uodzGKHWtmCd2ewttHvmU2WvJECZKEbg=; b=oXSck3Nl19Z25g3sHi84B57PEzNpFxjdNr49sZ0GRcHcIRumTkniox9pctblQlUTrD aNzLCS8P1+Li+DNQdFRnuhsW25cxdecdo6NdU/+E1v0jLa0eBYGz+p6CwE7mWbAgSP0w 3EdyF5pCX127u6Hh6iHhCeeJEc0e+WhLu2SBbFvrxx8nPK9GnItQ/aLLBeX6yyBAVOWp vonXbCYWQNpdNLjnOKH6f/boejatJ6qZ/6jiCBdIavcFGiOho45RMs2uFKgjM//6lf5F FsMaAQqyHEwn+Y+oHV86n9DvSg1mNN3+WWGKs2mIkx/DDRRyZ4WU1hNbYKxHr0MaeZcl XErg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XU0LdsXsBe6uodzGKHWtmCd2ewttHvmU2WvJECZKEbg=; b=b38nug5j5m9+YmnJIsJhGJadr5ebOcPq5oYFzhihQVl3x00gxBQgOt1oZfhM2HDhl+ 2kx3b84KpopQRSNn76B8Ru2BO15ciiLwm7Xef0la4Yj219J9SWAubePyxGHVdpNThQvu LE/fnAa9lt4kOXcxUDWvriSgKPIy95SdR81NN4dgl/8377sx64OU/sO29vZLAN5CMNZP DtuwNy4wlt4dzCx1azV8JLKr9UzjL/H/ka+bIZFF3p+XsUXb9+Lwr/mwz8cGxoYnSUZg ZkMsAiXZhN42Z88f1XfgdoStGynFFxZw2eY8t9YHtzsmPQBH/qFoLEwt3VEOEeUL/QCJ +ZMg== X-Gm-Message-State: ANhLgQ19nYTvgJF5wWfqiFwMv58kSnBwTM3Uf+OW4OhjPeBaBlghd9mz DiB2YLYtEr9yCRy1tf7onJlLxIlczESzfV4/izI= X-Google-Smtp-Source: ADFU+vvz9pF2+dcxDgS/hYDcoesmJsHPZwBF2UNiEu0KUfFvVbmVa6RGDqzmPeH5zFRvr07OCOBwP3umHnIf6VRC0Pc= X-Received: by 2002:aca:3196:: with SMTP id x144mr421758oix.77.1584056990108; Thu, 12 Mar 2020 16:49:50 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <20200312213601.GB34894@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200312213601.GB34894@faui48f.informatik.uni-erlangen.de> From: Erik Kline Date: Thu, 12 Mar 2020 16:49:39 -0700 Message-ID: To: Toerless Eckert Cc: Mark Smith , bier@ietf.org, v6ops list , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000330f7605a0b102eb" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 23:49:55 -0000 --000000000000330f7605a0b102eb Content-Type: text/plain; charset="UTF-8" On Thu, Mar 12, 2020 at 2:36 PM Toerless Eckert wrote: > On Thu, Mar 12, 2020 at 12:18:32PM +1100, Mark Smith wrote: > > RFC4007 allows packets with link-local destinations to be forwarded > > by a router, but only back onto the same link: > > Oh, my favourite coffin nail RFC. > > > "Thus, if a > > router receives a packet with a link-local destination address that > > is not one of the router's own link-local addresses on the arrival > > link, the router is expected to try to forward the packet to the > > destination on that link (subject to successful determination of the > > destination's link-layer address via the Neighbor Discovery protocol > > [9]). The forwarded packet may be transmitted back through the > > arrival interface, or through any other interface attached to the > > same link." > > > > > > I think in theory that could also mean forwarded to another router on > > the link that then forwards back again onto the link etc., so it is > > valid for a packet with a link-local destination address to have an > > initial Hop Count value that allows it to be forwarded by multiple > > routers, all limited to being forwarded within the same link. > > So this behavior breaks both TTL=1 and RFC5082 packets. > > Nice. This RFC is getting better every time i learn more of it. > My personal experience is that 255 is standard for link-local unicast communications, and 1 is commonly used for link-local multicast. > This draft might be useful, as it collects together and summarises > > information about using Link-Local Addresses (and is something I've > > been meaning to get back to updating, suggestions welcome): > > > > How to use IPv6 Link-Local Addresses in Applications > > https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00 > > Nice. > > Let me split that off. > > cheers > Toerless > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000330f7605a0b102eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 12, 2020 at 2:36 PM Toerl= ess Eckert <tte@cs.fau.de> wrote= :
On Thu, Mar 12= , 2020 at 12:18:32PM +1100, Mark Smith wrote:
> RFC4007=C2=A0 allows packets with link-local destinations to be forwar= ded
> by a router, but only back onto the same link:

Oh, my favourite coffin nail RFC.

> "Thus, if a
>=C2=A0 =C2=A0 router receives a packet with a link-local destination ad= dress that
>=C2=A0 =C2=A0 is not one of the router's own link-local addresses o= n the arrival
>=C2=A0 =C2=A0 link, the router is expected to try to forward the packet= to the
>=C2=A0 =C2=A0 destination on that link (subject to successful determina= tion of the
>=C2=A0 =C2=A0 destination's link-layer address via the Neighbor Dis= covery protocol
>=C2=A0 =C2=A0 [9]).=C2=A0 The forwarded packet may be transmitted back = through the
>=C2=A0 =C2=A0 arrival interface, or through any other interface attache= d to the
>=C2=A0 =C2=A0 same link."
>
>
> I think in theory that could also mean forwarded to another router on<= br> > the link that then forwards back again onto the link etc., so it is > valid for a packet with a link-local destination address to have an > initial Hop Count value that allows it to be forwarded by multiple
> routers, all limited to being forwarded within the same link.

So this behavior breaks both TTL=3D1 and RFC5082 packets.

Nice. This RFC is getting better every time i learn more of it.

My personal experience is that 255 is standard for= link-local unicast communications, and 1 is commonly used for link-local m= ulticast.

> This draft might be useful, as it collects together and summarises
> information about using Link-Local Addresses (and is something I'v= e
> been meaning to get back to updating, suggestions welcome):
>
> How to use IPv6 Link-Local Addresses in Applications
> https://tools.ietf.org/html/dra= ft-smith-ipv6-link-locals-apps-00

Nice.

Let me split that off.

cheers
=C2=A0 =C2=A0 Toerless

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--000000000000330f7605a0b102eb-- From nobody Thu Mar 12 17:06:48 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21643A09D4; Thu, 12 Mar 2020 17:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu_GK0CJwFCa; Thu, 12 Mar 2020 17:06:35 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D163A09D2; Thu, 12 Mar 2020 17:06:35 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id a14so7242588ilk.6; Thu, 12 Mar 2020 17:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7/l0evnKDVFmClRi56IAYcO/sSQgdv6ZZlgMVrJHA10=; b=ZWu5Om56UaFrLg4gbo5opUGJ4N4XUE8UzUO8KkVYrQ3j21+i69Olqgbh3RhOnFJg3S eNMRHaYu1izYaQybgDqetmE6y8UGDfDi3gIRB7B9Ng09lFUyOf83n5qORMJPzPNuIotv tDTmJN7HBA1K8NFfE5Oa/uqo/4r3edMZper1wzlzR67zb00nnfuPlVRdTWk6+uXdwr0E xkYvAiqay6e3fb/Risw+znbx7ZZm17fHJNZDb7vZhvmUa9KIY3rYWj6S5Zw5KIxTgxk/ gSW1lIjrrc7CimDIt2mf9x6sW1z3FxNx8/EnaGtyiV+CXOrbwIun+EP6hodEChpKs/zN jlqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7/l0evnKDVFmClRi56IAYcO/sSQgdv6ZZlgMVrJHA10=; b=b1X9LyJAUWhzAoc3VRdC/HmhUrf+5u/Lf1lfEyLLWT7vEozLoUVVtMe74CzUDu2a5S i7UhnwCwWsYU6o7xM/DFycnNw71vwCLTyoitYbFwphg0ay5qehVVxj/kalYm1vym0URD CLmCTZKNuuflGPIPc9HwlpfFZFl55v8XvEzow8WBa6XnK89XuTiaJfqj0TJCIL5i+DF9 jkavhcbT3sIH0skjTsDk1iQM0CF3vEhyGgnPenR2MLNCrmPofPTrvhi3GZh6HF8Nw7vf 6HSMgClKiv8Y1qkFaPZ/I94QqZWyY81AE5YJLsFRR8Xsd0jiNjjcRumuu9rIbAOI2UCC 101g== X-Gm-Message-State: ANhLgQ2cSXil76Cvw755m6h/WXh97gMoLLGXndqK9k/cXuI1bLLwB6Go 6tlpBjkD3dfbeTnZRoP2JsHsWu2yErhcEEBkkS8eDNby X-Google-Smtp-Source: ADFU+vsTfFQYcdMKYMzN7wKvyqLhI8+sf0PPf9mKNtU2ZhIsPAW8GrB/Ey7AwP/hSOlpP1owOejgmhkUc/fJQjGHnQ0= X-Received: by 2002:a92:ce04:: with SMTP id b4mr5190593ilo.269.1584057995059; Thu, 12 Mar 2020 17:06:35 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <20200312213601.GB34894@faui48f.informatik.uni-erlangen.de> In-Reply-To: From: Tony Przygienda Date: Thu, 12 Mar 2020 17:05:01 -0700 Message-ID: To: Erik Kline Cc: Toerless Eckert , 6MAN <6man@ietf.org>, v6ops list , BIER WG , Mark Smith Content-Type: multipart/alternative; boundary="000000000000196a4b05a0b13e18" Archived-At: Subject: Re: [v6ops] [Bier] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 00:06:38 -0000 --000000000000196a4b05a0b13e18 Content-Type: text/plain; charset="UTF-8" interesting exchange and Erik's last observation (ttl=1 and LL for multicast) puts it on the point, we are talking here a suggestion for BIER control plane where the contained packet is multicast. I would hate to see a multicast packet due to TTL > 1 end up in funky place and replicated there. Another interesting question is what if the LL source and destination are the same and TTL>1 but AFAIK that cannot happen since LL is generated using EUI-64 (albeit to my surprise I saw enough customers running same LL address on all links of a device & this is valid :-/ That aside, as I mentioned to Toerless that LL with TTL=1 is usual stuff since long time, we are talking here either something like BFD router to router or now in case of BIER it's suggested to be used as "implicit one hop tunnel" basically carrying BIER frame router-to-router instead of ether encaps (since BIER is L2.5, strictly speaking "abusing" v6 as transport is bit rich but it satisfies things like HOMENET which need mutlicast very nicely where the silicon doesn't need to process BIER but processes naive v6 easily, after v6 decaps it can go to slow path since HOMENET doesn't need any serious mcast throughtput [but nothing special AFAIS if the silicon chooses to process it after the decaps when demand arises or when used e.g. in core]) thanks --- tony On Thu, Mar 12, 2020 at 4:50 PM Erik Kline wrote: > > > On Thu, Mar 12, 2020 at 2:36 PM Toerless Eckert wrote: > >> On Thu, Mar 12, 2020 at 12:18:32PM +1100, Mark Smith wrote: >> > RFC4007 allows packets with link-local destinations to be forwarded >> > by a router, but only back onto the same link: >> >> Oh, my favourite coffin nail RFC. >> >> > "Thus, if a >> > router receives a packet with a link-local destination address that >> > is not one of the router's own link-local addresses on the arrival >> > link, the router is expected to try to forward the packet to the >> > destination on that link (subject to successful determination of the >> > destination's link-layer address via the Neighbor Discovery protocol >> > [9]). The forwarded packet may be transmitted back through the >> > arrival interface, or through any other interface attached to the >> > same link." >> > >> > >> > I think in theory that could also mean forwarded to another router on >> > the link that then forwards back again onto the link etc., so it is >> > valid for a packet with a link-local destination address to have an >> > initial Hop Count value that allows it to be forwarded by multiple >> > routers, all limited to being forwarded within the same link. >> >> So this behavior breaks both TTL=1 and RFC5082 packets. >> >> Nice. This RFC is getting better every time i learn more of it. >> > > My personal experience is that 255 is standard for link-local unicast > communications, and 1 is commonly used for link-local multicast. > > > This draft might be useful, as it collects together and summarises >> > information about using Link-Local Addresses (and is something I've >> > been meaning to get back to updating, suggestions welcome): >> > >> > How to use IPv6 Link-Local Addresses in Applications >> > https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00 >> >> Nice. >> >> Let me split that off. >> >> cheers >> Toerless >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --000000000000196a4b05a0b13e18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
interesting exchange and Erik's last observation = (ttl=3D1 and LL for multicast) puts it on the point, we are talking here a = suggestion for BIER control plane where the contained packet is multicast. = I would hate to see a multicast packet due to TTL > 1 end up in funky pl= ace and replicated there.

Another interesting= question is what if the LL source and destination are the same and TTL>= 1 but AFAIK that cannot happen since LL is generated using EUI-64 (albeit t= o my surprise I saw enough customers running same LL address on all links o= f a device & this is valid :-/

That aside,= as I mentioned to Toerless that LL with TTL=3D1 is usual stuff since long = time, we are talking here either something like BFD router to router or now= in case of BIER it's suggested to be used as "implicit one hop tu= nnel" basically carrying BIER frame router-to-router instead of ether = encaps (since BIER is L2.5, strictly speaking "abusing" v6 as tra= nsport is bit rich but it satisfies things like HOMENET which need mutlicas= t very nicely where the silicon doesn't need to process BIER but proces= ses naive v6 easily, after v6 decaps it can go to slow path since HOMENET d= oesn't need any serious mcast throughtput [but nothing special AFAIS if= the silicon chooses to process it after the decaps when demand arises or w= hen used e.g. in core])

thanks

--- tony



=
On Thu, Ma= r 12, 2020 at 4:50 PM Erik Kline <e= k.ietf@gmail.com> wrote:


On Thu, Mar 12, 2020= at 2:36 PM Toerless Eckert <tte@cs.fau.de> wrote:
On Thu, Mar 12, 2020 at 12:18:32PM +1100, Mark Smith w= rote:
> RFC4007=C2=A0 allows packets with link-local destinations to be forwar= ded
> by a router, but only back onto the same link:

Oh, my favourite coffin nail RFC.

> "Thus, if a
>=C2=A0 =C2=A0 router receives a packet with a link-local destination ad= dress that
>=C2=A0 =C2=A0 is not one of the router's own link-local addresses o= n the arrival
>=C2=A0 =C2=A0 link, the router is expected to try to forward the packet= to the
>=C2=A0 =C2=A0 destination on that link (subject to successful determina= tion of the
>=C2=A0 =C2=A0 destination's link-layer address via the Neighbor Dis= covery protocol
>=C2=A0 =C2=A0 [9]).=C2=A0 The forwarded packet may be transmitted back = through the
>=C2=A0 =C2=A0 arrival interface, or through any other interface attache= d to the
>=C2=A0 =C2=A0 same link."
>
>
> I think in theory that could also mean forwarded to another router on<= br> > the link that then forwards back again onto the link etc., so it is > valid for a packet with a link-local destination address to have an > initial Hop Count value that allows it to be forwarded by multiple
> routers, all limited to being forwarded within the same link.

So this behavior breaks both TTL=3D1 and RFC5082 packets.

Nice. This RFC is getting better every time i learn more of it.

My personal experience is that 255 is standard for= link-local unicast communications, and 1 is commonly used for link-local m= ulticast.

> This draft might be useful, as it collects together and summarises
> information about using Link-Local Addresses (and is something I'v= e
> been meaning to get back to updating, suggestions welcome):
>
> How to use IPv6 Link-Local Addresses in Applications
> https://tools.ietf.org/html/dra= ft-smith-ipv6-link-locals-apps-00

Nice.

Let me split that off.

cheers
=C2=A0 =C2=A0 Toerless

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier
--000000000000196a4b05a0b13e18-- From nobody Thu Mar 12 17:48:23 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F07C3A0B22 for ; Thu, 12 Mar 2020 17:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_9w3_45EtRZ for ; Thu, 12 Mar 2020 17:48:18 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51FF3A0B1C for ; Thu, 12 Mar 2020 17:48:18 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id m5so3949305pgg.0 for ; Thu, 12 Mar 2020 17:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=dfjX5AQCqNNFQWlauvvxBx+gtIsfSp/SawE6fYNhBwc=; b=qipji60k9kYhpDXsRdbJPcgb35dqXGs5oUf8Zs1YdHmFZz6icFj/5WdOQXAtDLaQIJ jX39sIAXqQawDJBAa5oWOoJqE5MCsjYCpWxWip5buDbNs33xiPHbeBOjm8m65abdyKYq 9c6ZeXxUQ/4YPg6Yw+SKm4ev612y3is8GgBsSDFgG8nKuOG4aMT74yolz/vavpu9OYkn ihFDOgANeyMJuxGCdCryNyBM1ddfPo32FSr3bf2CdKlBiWZDkhwnYdZ+QBuzpGE/DDzV NZ51V3iMCAW4XP7PBYz4cVmYku7p6flavWvgWnDDM1NlfeKAmB5caYMc7sDnItOpFQLm p3Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=dfjX5AQCqNNFQWlauvvxBx+gtIsfSp/SawE6fYNhBwc=; b=oxYSZ7lt5l7dTNLYnXBete6lYxHLLCT5Y0yXGtCjEvm1xieTVPJ81OZ7CMs3fTRRaF TzZ6eI28xtg2Ax6JIkYRLmd0cxz7TywG+lM8ZSURS+bMQcvLwNX86fLJtVBQIJs6CKhb OiyIbTDnZ3DXDgu27U8SdqAUXABr+/I/zUcWzqRjQPBxWLbtttgYA58dGox6GCQ7XIz8 Utg9eOEWRtIrvhG19dXBgumcXnYsXoJHCwASBEwlsHCU4hqlOpCJCvUKgkeHOLEM6JbW 2y6pIeTs3hl6cXcSivpltXycYjAPGfgC74YzEnMBj6c9U1GFxZTdnOEm+PuiUoLdxuSR Q6+g== X-Gm-Message-State: ANhLgQ25bmt2Ay8Ev68NStG+z1t+AWBSgfkNxlFUH3mEu23ZBKY9g1+/ bTBrf2rWVtqPPIrX7IExKPk= X-Google-Smtp-Source: ADFU+vtM2bKcEpdoPLCXfSVfgChSF6xqm2dsq34KqikuXB53zU0yUC2/NAgbJe4ijzlYviSdSLEfLA== X-Received: by 2002:a63:741c:: with SMTP id p28mr9421359pgc.402.1584060498050; Thu, 12 Mar 2020 17:48:18 -0700 (PDT) Received: from ?IPv6:2600:8802:5900:13c4::101f? ([2600:8802:5900:13c4::101f]) by smtp.gmail.com with ESMTPSA id n5sm3864571pfq.35.2020.03.12.17.48.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2020 17:48:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Fred Baker In-Reply-To: Date: Thu, 12 Mar 2020 17:48:16 -0700 Cc: v6ops@ietf.org Message-Id: <9F85B373-6A38-43CD-9CC0-A31A128AB94C@gmail.com> References: To: JORDI PALET MARTINEZ X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [v6ops] IPv6-only Terminology Definition X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 00:48:21 -0000 Right now, as always, I=E2=80=99m looking for supportive working group comme= ntary. Sent using a machine that autocorrects in interesting ways... > On Mar 12, 2020, at 3:45 AM, JORDI PALET MARTINEZ wrote: >=20 > =EF=BB=BFYes, sorry, there is a typo there. >=20 > However, the "end-networks", in general, need to continue supporting= > IPv4, as there are many devices or apps, in both corporate and end- > user networks (smartTV, IP cameras, etc.), which are IPv4-only and i= t > is not always feasible to update or replace them. Also if customer > devices in a LAN are ***IPv4-only***, they will not be able to acces= s > IPv6-only services, so this means that IPv6-only services can't be > deployed unless it is done in such way that some transition mechanis= m > solves that problem as well (example an IPv6-only Data Center, > requires SIIT-DC) >=20 >=20 > I've corrected in my internal draft v-06, but will wait for more inputs be= fore publishing it. >=20 > Or maybe we could even consider a call for WG adoption? >=20 > Thanks for spotting it! >=20 >=20 > =EF=BB=BFEl 12/3/20 7:58, "v6ops en nombre de Fred Baker" escribi=C3=B3: >=20 > Section 2, fourth paragraph. >=20 > However, the "end-networks", in general, need to continue supporting= > IPv4, as there are many devices or apps, in both corporate and end- > user networks (smartTV, IP cameras, etc.), which are IPv4-only and i= t > is not always feasible to update or replace them. Also if customer > devices in a LAN are IPv6-only, they will not be able to access > IPv6-only services, so this means that IPv6-only services can't be > deployed unless it is done in such way that some transition mechanis= m > solves that problem as well (example an IPv6-only Data Center, > requires SIIT-DC) >=20 > I don't understand why an IPv6-only device would not be able to access a= n IPv6-only services. I can understand IPv4-only devices not being able to a= ccess IPv6-only services, but that's not the statement. This paragraph seems= to not follow. >=20 >> On Mar 9, 2020, at 11:47 AM, JORDI PALET MARTINEZ wrote: >>=20 >> Hi all, >>=20 >> After the recent discussion, I've posted a new version (minor changes) fo= r this document: >>=20 >> https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/?include_tex= t=3D1 >>=20 >> Comments welcome! >>=20 >> Regards, >> Jordi >> @jordipalet >>=20 >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged or co= nfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Mar 12 19:01:04 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A203A0D6C; Thu, 12 Mar 2020 19:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxj5E7DYLjmz; Thu, 12 Mar 2020 19:00:49 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9255A3A0D68; Thu, 12 Mar 2020 19:00:49 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2EC8C54842E; Fri, 13 Mar 2020 03:00:43 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 26CF7440040; Fri, 13 Mar 2020 03:00:43 +0100 (CET) Date: Fri, 13 Mar 2020 03:00:43 +0100 From: Toerless Eckert To: Tony Przygienda Cc: Erik Kline , 6MAN <6man@ietf.org>, v6ops list , BIER WG , Mark Smith Message-ID: <20200313020043.GA59538@faui48f.informatik.uni-erlangen.de> References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <20200312213601.GB34894@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] [Bier] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 02:00:53 -0000 Tony: On Thu, Mar 12, 2020 at 05:05:01PM -0700, Tony Przygienda wrote: > interesting exchange and Erik's last observation (ttl=1 and LL for > multicast) puts it on the point, we are talking here a suggestion for BIER > control plane where the contained packet is multicast. I would hate to see > a multicast packet due to TTL > 1 end up in funky place and replicated > there. I was actually talking about the "TTL=1" (*) requirement in section 2 of draft-zhang-bier-bierin6, and that is an IPv6 unicast data plane packet, not a multicast packet. It just carries a mlticast packet. Which packet where you talking about ? But your point about possible undesirable replication if TTL>1 for link-local multicast packets is interesting. I had actually not thought about that, and can not remember an example. Do you have one ? RFC5082 for once does not mention the words multicast or unicast, si it's anybody's guess how it feels its recommendation should be applied (usually mentioning nothing means unicast only, so in that sense it could be argued to not be intended to apply to multicast). > Another interesting question is what if the LL source and destination are > the same and TTL>1 but AFAIK that cannot happen since LL is generated using > EUI-64 (albeit to my surprise I saw enough customers running same LL > address on all links of a device & this is valid :-/ Probably not an issue for the v6 encap layer, but the multicast layer: RPF failure, or bit-reset in BIER for multicast payloads. > That aside, as I mentioned to Toerless that LL with TTL=1 is usual stuff > since long time, we are talking here either something like BFD router to > router Yes, has been forever for IPv4 multicast link-local and all the IPv6 link-local i know (e.g.: OSPF). But i just learned from this thread that IPv6 Neighbor Discovery multicast packets use 255 (predating RFC5082). I was also interested i there are any rules which HC to use, but seemingly it is a free choice of the application, so we (BIER in IPv6) can decide as we please, we just may need to beat up the 1 vs 255 argument from their technical proc/cons. > or now in case of BIER it's suggested to be used as "implicit one > hop tunnel" basically carrying BIER frame router-to-router instead of ether > encaps (since BIER is L2.5, strictly speaking "abusing" v6 as transport is > bit rich but it satisfies things like HOMENET which need mutlicast very > nicely where the silicon doesn't need to process BIER but processes naive > v6 easily, after v6 decaps it can go to slow path since HOMENET doesn't > need any serious mcast throughtput [but nothing special AFAIS if the > silicon chooses to process it after the decaps when demand arises or when > used e.g. in core]) May sales pitch would be : Putting something new over L2 can be harder for wide-ranging adoption, and you need to start thinking about possible L2 differences. Being able tto run it over link-local IPv6 is a nice way to avoid those issues. I dor for example also have a draft in ANIMA doing exactly the same thing (not for multicast). Thanks Toerless > > thanks > > --- tony > (*) standard disclaimer: Yes, i do complain to authors using IPv4 terms for equivalent IPv6 functions, but i complain even more to IPv6 for the gratuitous renaming of perfect names in IPv6. From nobody Fri Mar 13 15:16:49 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F3F3A1127 for ; Fri, 13 Mar 2020 15:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hY0vpIqjGU_E for ; Fri, 13 Mar 2020 15:16:46 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 69ED23A1128 for ; Fri, 13 Mar 2020 15:16:46 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02DMGgDP2850594 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Mar 2020 15:16:42 -0700 From: Owen DeLong Message-Id: <28EEE40B-D558-45FD-9C30-5AB7593A29B2@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9BBDD850-85FF-40C4-B9F7-21FF2E5E061B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 13 Mar 2020 15:16:41 -0700 In-Reply-To: <3854B1F6-0DB8-4753-BBDD-30AAD391C4DC@consulintel.es> Cc: v6ops To: JORDI PALET MARTINEZ References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <2020030818294834486735@chinatelecom.cn> <073925C4-5355-4C51-84A4-4D9545013552@delong.com> <4A5BDEE6-2B9E-4338-94C1-3BE9D6E37516@consulintel.es> <3854B1F6-0DB8-4753-BBDD-30AAD391C4DC@consulintel.es> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 13 Mar 2020 15:16:42 -0700 (PDT) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 22:16:48 -0000 --Apple-Mail=_9BBDD850-85FF-40C4-B9F7-21FF2E5E061B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 12, 2020, at 02:22 , JORDI PALET MARTINEZ = wrote: >=20 > Hi Owen, >=20 > Using +++ below =E2=80=A6 >=20 I have to again restate that it would be vastly preferable if you got an = MUA that actually worked. > =20 > =20 > El 10/3/20 21:49, "v6ops en nombre de Owen DeLong" = en nombre de = owen@delong.com > escribi=C3=B3: > =20 > =20 >=20 >=20 >> On Mar 10, 2020, at 11:25 , JORDI PALET MARTINEZ = > wrote: >> =20 >> Hi Owen, >> =20 >> Responses below with ***. >> =20 >> El 10/3/20 19:03, "v6ops en nombre de Owen DeLong" = en nombre de = owen@delong.com > escribi=C3=B3: >> =20 >> =20 >>=20 >>=20 >>=20 >>> On Mar 9, 2020, at 01:42 , JORDI PALET MARTINEZ = > wrote: >>> =20 >>> Hi Clark, >>> =20 >>> El 8/3/20 12:38, "v6ops en nombre de Clark Gaylord" = en nombre de = cgaylord@vt.edu > escribi=C3=B3: >>> =20 >>> It seems to me the context of the OMB guidance is relevant to the = question of "IPv6-only". The draft memo is reasonably good at this, but = succinctly something like "agency internal networks use single-stack = IPv6 with any=20 >>> =20 >>> [Jordi] I don=E2=80=99t think is so clear. Footnote 4 =E2=80=9CIPv6-On= ly refers to network environments in which use of the IPv4 protocol has = been eliminated=E2=80=9D will be much clear if it says =E2=80=9CIPv6-Only = refers to network environments in which use of the *native* IPv4 = protocol has been eliminated=E2=80=9D. >> =20 >> I don=E2=80=99t believe that what you propose is the intent in the = memo. >> =20 >> I believe they intend to eliminate the use of ALL IPv4, not just = native IPv4 on government networks. >> =20 >> *** Then there is a problem. If they really want to have ALL the way = thru only IPv6 in the LANs, the federal employees will not be able to = use *ANY* application that uses literal addresses (even a simple web = page that is doing that). Because there is NO transition mechanism that = allows that. They are able to force all their internal apps to use only = IPv6, fine, but they have no control over the rest of the Internet. If = they are thinking that NAT64+DNS64 resolves that, they lost this = =E2=80=9Csmall=E2=80=9D bit in their thinking. I=E2=80=99ve already = reported them to the site that is asking for comments, hopefully they = really pay attention to the inputs. > =20 > I don=E2=80=99t see that as a problem=E2=80=A6 I see that as a = benefit. > =20 > I think that the US Federal government is one of the few organizations = in a position to actually put the kind of pressure that will be = necessary to effectuate this change. > =20 > So, personally, I don=E2=80=99t see it so much as =E2=80=9Cthey lost = this in their thinking=E2=80=9D as in they are choosing to stop = supporting certain =E2=80=9Cbroken by design=E2=80=9D ways of thinking. > =20 > I hope that they stick to their guns and do not soften their position. > =20 > +++ Somehow, I agree, is not a =E2=80=9Cproblem=E2=80=9D, depending on = how you see it. As moving on to a real IPv6-only world, it is good. But = we are interpreting the document as they really want that. They don=E2=80=99= t say explicitly, so we don=E2=80=99t know. If they want that effect, I = think it will be much better message to say =E2=80=9Cwe know this will = create this problem for people still using literal IPv4 addresses in web = sites, but they should react if they want to work with us=E2=80=9D or = whatever.. I know many of the people involved. I suspect that the authors of the = document do, in fact, intend that. What you propose would be the customer friendly way for a business to = approach it. It isn=E2=80=99t culturally typical of the US Government to = approach anything in a customer friendly manner. >> =20 >> *** I will be glad if they can send this memo to every small web site = in the world, because even if one of them is missing it, and need to be = accessed by the employees, will not work! > =20 > I=E2=80=99m pretty sure that the employees that encounter difficulty = will make it known to the web sites in question. > =20 > +++ Not sure, it may get ignored, as they ignore problems in their = deployment. Last time I tried to fill in the ESTA for traveling to US, = it was not working in some of the final steps. I did some debugging and = realized that they were dual stack, but filtering PTB, so because the = MTU at some point in the network, it never worked until I disabled IPv6 = to complete the form and pay the fee. I tried to tell them. I recall = there was even a thread about that in NANOG (talking from the top of my = head, it may be in a different list). They never responded or resolved = it. I=E2=80=99m not sure if now the problem is still there. We=E2=80=99re talking about two different things here=E2=80=A6 In your case, you were trying to get the government to fix something = they broke. The government is very good at ignoring such feedback. In this case, we=E2=80=99re talking about government employees informing = web sites they are trying to visit that they are no longer accessible = from US Government networks. That=E2=80=99s not something web sites are = nearly as likely to ignore. =20 > In reality, in terms of actual job-related usage, the federal = government is unlikely to need access to every small web site in the = world. As a general rule, every small web site in the world has no = ability to support things at the scale of US Government usage. > =20 > +++ Sometimes this happens even in bigger sites =E2=80=A6 so yes and = not. I=E2=80=99m quite certain the bigger sites will get the memo somehow. If = they don=E2=80=99t get it before this starts taking hold of their USG = customers, they will certainly learn about it and quickly mitigate it = afterwards. ;-) > +++ Fully agree! But some text could make it more clear, so nobody = believes =E2=80=9Cthey didn=E2=80=99t though about this issue=E2=80=9D = as I did. I=E2=80=99m not sure how much experience you have with the USG, but if = you think clarity is their strong suit, I suggest you read 14CFR121 and = get back to me. Owen --Apple-Mail=_9BBDD850-85FF-40C4-B9F7-21FF2E5E061B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 12, 2020, at 02:22 , JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> = wrote:

Hi Owen,

Using +++ below = =E2=80=A6

I have to again = restate that it would be vastly preferable if you got an MUA that = actually worked.

 
 
El 10/3/20 21:49, = "v6ops en nombre de Owen DeLong" <v6ops-bounces@ietf.org en nombre de owen@delong.com> escribi=C3=B3:
 
 


On Mar 10, 2020, at 11:25 , JORDI PALET = MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> = wrote:
 
Hi Owen,
 
Responses below with = ***.
 
El 10/3/20 19:03, = "v6ops en nombre de Owen DeLong" <v6ops-bounces@ietf.org en nombre de owen@delong.com> escribi=C3=B3:
 
 



On Mar 9, 2020, at 01:42 , JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> = wrote:
 
Hi = Clark,
 
El 8/3/20 12:38, "v6ops en nombre de = Clark Gaylord" <v6ops-bounces@ietf.org en nombre de cgaylord@vt.edu> escribi=C3=B3:
 
It seems = to me the context of the OMB guidance is relevant to the question of = "IPv6-only". The draft memo is reasonably good at this, but succinctly = something like "agency internal networks use single-stack IPv6 with = any 
 
[Jordi] I don=E2=80=99t think is so clear. Footnote 4 =E2=80=9CIPv6-Only refers to network environments in which = use of the IPv4 protocol has been eliminated=E2=80=9D will be much clear = if it says =E2=80=9CIPv6-Only refers to network environments in which = use of the *native* IPv4 protocol has been eliminated=E2=80=9D.
 
I don=E2=80=99t = believe that what you propose is the intent in the memo.
 
I believe they intend to eliminate the = use of ALL IPv4, not just native IPv4 on government networks.
 
*** = Then there is a problem. If they really want to have ALL the way thru = only IPv6 in the LANs, the federal employees will not be able to use *ANY* application that uses literal addresses (even a = simple web page that is doing that). Because there is NO transition = mechanism that allows that. They are able to force all their internal = apps to use only IPv6, fine, but they have no control over the rest of = the Internet. If they are thinking that NAT64+DNS64 resolves that, they = lost this =E2=80=9Csmall=E2=80=9D bit in their thinking. I=E2=80=99ve = already reported them to the site that is asking for comments, hopefully = they really pay attention to the inputs.
 
I don=E2=80=99t see that as a problem=E2=80=A6 I see that as = a benefit.
 
I think that the US Federal government is one of = the few organizations in a position to actually put the kind of pressure = that will be necessary to effectuate this change.
 
So, personally, I don=E2=80=99t see it = so much as =E2=80=9Cthey lost this in their thinking=E2=80=9D as in they = are choosing to stop supporting certain =E2=80=9Cbroken by design=E2=80=9D= ways of thinking.
 
I hope that they stick to their guns and do not = soften their position.
 
+++ Somehow, I = agree, is not a =E2=80=9Cproblem=E2=80=9D, depending on how you see it. = As moving on to a real IPv6-only world, it is good. But we are = interpreting the document as they really want that. They don=E2=80=99t = say explicitly, so we don=E2=80=99t know. If they want that effect, I = think it will be much better message to say =E2=80=9Cwe know this will = create this problem for people still using literal IPv4 addresses in web = sites, but they should react if they want to work with us=E2=80=9D or = whatever..

I know many = of the people involved. I suspect that the authors of the document do, = in fact, intend that.

What you propose would = be the customer friendly way for a business to approach it. It isn=E2=80=99= t culturally typical of the US Government to approach anything in a = customer friendly manner.

 
*** I will be glad if they can = send this memo to every small web site in the world, because even if one = of them is missing it, and need to be accessed by the employees, will = not work!
 
I=E2=80=99m pretty sure that the employees that encounter = difficulty will make it known to the web sites in question.
 
+++ = Not sure, it may get ignored, as they ignore problems in their = deployment. Last time I tried to fill in the ESTA for traveling to US, = it was not working in some of the final steps. I did some debugging and = realized that they were dual stack, but filtering PTB, so because the = MTU at some point in the network, it never worked until I disabled IPv6 = to complete the form and pay the fee. I tried to tell them. I recall = there was even a thread about that in NANOG (talking from the top of my = head, it may be in a different list). They never responded or resolved = it. I=E2=80=99m not sure if now the problem is still there.

We=E2=80=99re= talking about two different things here=E2=80=A6

In your case, you were =  trying to get the government to fix something they broke. = The government is very good at ignoring such = feedback.
In this case, we=E2=80=99re talking about government = employees informing web sites they are trying to visit that they are no = longer accessible from US Government networks. That=E2=80=99s not = something web sites are nearly as likely to = ignore.
 
In = reality, in terms of actual job-related usage, the federal government is = unlikely to need access to every small web site in the world. As a = general rule, every small web site in the world has no ability to = support things at the scale of US Government usage.
 
+++ = Sometimes this happens even in bigger sites =E2=80=A6 so yes and = not.

I=E2=80=99m quite certain the = bigger sites will get the memo somehow. If they don=E2=80=99t get it = before this starts taking hold of their USG customers, they = will certainly learn about it and quickly mitigate it afterwards. = ;-)

+++  Fully agree! But some = text could make it more clear, so nobody believes =E2=80=9Cthey didn=E2=80= =99t though about this issue=E2=80=9D as I = did.

I=E2=80= =99m not sure how much experience you have with the USG, but if you = think clarity is their strong suit, I suggest you read 14CFR121 and get = back to me.

Owen

= --Apple-Mail=_9BBDD850-85FF-40C4-B9F7-21FF2E5E061B-- From nobody Fri Mar 13 22:43:19 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36C83A0F51; Fri, 13 Mar 2020 22:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nbtiTzoG9Fi; Fri, 13 Mar 2020 22:43:15 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238B13A0F5B; Fri, 13 Mar 2020 22:43:14 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id w15so3893345ilq.6; Fri, 13 Mar 2020 22:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ccaa956zNyL7pq7cVIGAoHyWaX0h8NXqFkf08pGFwzs=; b=HcRGWj/iTLofs0t2XZB0e/oDOa/yv+1C6Bnw07poMZAmGdlCpWya5x884qeTSYRajC beUvq8yuYeCY+j5MVfs0USaHN+x0E5e8XbvikRLmc90uhOk2cj+XvfwO08fNlheTikLX j1g/0wDvG1VlRWLKLefnT/t7EXcGyayvCAHQ/MPkVSG9mmFuMqAxpTELewhyWLoXeOnI pBcEHFxqKUbyYvwpvEI1D7LuYzSTMQR2feE4S6C1uD8koLKeBgg+IBt0c6Vd3WkxXp1M loWNPABVBroSVcWbxiw9fPY6Nt5FuwWDkgcdFJyEuWjZbT1UIjrPumjxbRk2V+0zJS3/ ppWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ccaa956zNyL7pq7cVIGAoHyWaX0h8NXqFkf08pGFwzs=; b=onm7dRlRU8MCptG+Uqk7ui33qzbeaVn2tuAsvRn4V2BvtAOmUkcIMrSuWtkQoS/cc0 L40+ZWveUwwLCgi2iG988ayWCy8+d/+h7l1WUr5SldBK9SIGvu3jej5P/SSV3RrIYFyb DVbIMSWw6mSOSIM2hFOiug47MeTXMtK+S16762Unz/KZk2TWN5GMJ6mosGUEBe6iFSIk NXE3c2AnILpPdgyVA5FAtORSchyFGIkSZFD2R9PQTvjCFZWsk74yvamNvJOK5dbpQXMM LcC1bhIlCRg1f+rieaFRN0o3aKfvHtbhV73s1MfBTYw/pdKewzHqv43Z0+ITzbY81s8R paWA== X-Gm-Message-State: ANhLgQ3N9LajScPiSZj1ROrJeGDWRRwiZ0pVfpyqltPym9WbPv/84n56 HUsDtKBS89L0YRHfQ6xillRXjhvVdUaliH07cRj//ahF X-Google-Smtp-Source: ADFU+vtRTG1YweDg7IjX8fg+eT9MUxhoZ7cVuJiV2MlZ6oTwLIesAmOTMH2rlFuJKQafBbXtsE67oOkFCTBGnfjEwZM= X-Received: by 2002:a05:6e02:bc7:: with SMTP id c7mr18339567ilu.78.1584164593938; Fri, 13 Mar 2020 22:43:13 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> From: Gyan Mishra Date: Sat, 14 Mar 2020 01:43:03 -0400 Message-ID: To: Toerless Eckert Cc: 6man@ietf.org, v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000e3379405a0ca0f82" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 05:43:18 -0000 --000000000000e3379405a0ca0f82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Interesting question. So IPv4 and IPv6 header both have an 8 bit field with maximum TTL of 255. The initial TTL for a flow is usually set to 60 and is decremented hop by hop by the router till the packet reaches its final destination. Distance vector based routing protocols are based on hop count such as RIP and link state protocols such as OSPF and ISIS are based on a topological link state database and path vector protocols such as BGP based on BGP path selection algorithm. IPv6 control plane packets such as ICMPv6 ND packets NS NA type 135/136 and RD RS/RA type 133/134 all have a hop count limit of 255. Since RD RS/RA and ND NS/NA packets all have a link local source IPv6 address and multicast destination FF02. I am not sure why the TTL is 255 as the packet has local scope only to be forwarded on the local subnet. I would thin the TTL for these packets should be 1. OSPF packets have ttl of 255 ISIS packets have ttl 1 BGP packets have ttl 1 As far as GTSM, it is an alternative to cryptography option for securing routing protocols. Most enterprises and SPs in general use cryptography to secure routing protocol adjacencies. I don=E2=80=99t know of any implement= ation or operator using GTSM. With GTSM the idea is to use an expected TTL value configured by adjacent peers to be set to different from the default value. So that value can be any value other then the default value. Thanks Gyan On Wed, Mar 11, 2020 at 8:01 PM Toerless Eckert wrote: > Sorry for cross posting, but this is both ops and arch questions. > > I was trying to find any generic description that/if link-local IPv6 > traffic MUST/SHOULD use Hop-count 1, but could not find one in > rfc8200 or rfc4291 and its updates. Instead, text like > MUST set Hop-limit to 1 is repeated in various RFCs using link-local > IPv6 traffic. > > Am i overlooking something ? Or is this intentional in the IPv6 > architecture ? > > If intentional, i guess it means: Any RFC introducing some type of > link-local > traffic can specify Hop-limit requirements for its traffic. As in > "our WG likes 42 as the Hop-limit" (silly to me, but should be fine with > IPv6 architecture then, right ?). > > In one of my draft document reviews using such link-local IPv6 traffic, > EricV brought up the Q if that traffic shouldn't use RFC5082 instead > of Hop-Count 1 too. But given how we do not seem to have architectural > recommendations for TTL=3D1 (unless, quite likely i overlook something), > and given how i am not aware of any actual use of GTSM, i am quite > weary to go down that route. Aka: Would like learn of actual uses of > GTSM with IPv6. > > There is an additional set of consideration re. link-local traffic > when trying to use it as a HW accelerated tunneling mechanism across link= s, > a use we both have in ANIMA, and maybe get the same in BIER (probably > other WGs too, not sure). > > In implementations, i have seen quite a range of issues with > accelerated forwarding planes across link-local addressed tunnels, > and when using non-link-local addresses (loopback addresses), > the HW plane forwarding might have issues doing HW forwarding, because > usually TTL=3D1 is only used for control plane traffic. Of course, > this is not a good architectural argument, but if given architectural > leeway to even choose 42, maybe GTSM/255 is easier to be supported > across various HW accelerated forwarding planes than 1. > > Opinions and experiences welcome! > > Thanks! > Toerless > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --000000000000e3379405a0ca0f82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interesting question.
<= br>
So IPv4 and IPv6 header both have an 8 bit field= with maximum TTL of 255.=C2=A0 The initial TTL for a flow is usually set t= o 60 and is decremented hop by hop by the router till the packet reaches it= s final destination.
=C2=A0
D= istance vector based routing protocols are based on hop count such as RIP a= nd link state protocols such as OSPF and ISIS are based on a topological li= nk state database and path vector protocols such as BGP based on BGP path s= election algorithm.=C2=A0

IPv6 control plane packets such as ICMPv6 ND packets NS NA type 135/136 a= nd RD RS/RA type 133/134 all have a hop count limit of 255.

Since RD RS/RA and ND NS/NA packets a= ll have a link local source IPv6 address and multicast =C2=A0destination = =C2=A0FF02.=C2=A0 I am not sure why the TTL is 255 as the packet has local = scope only to be forwarded on the local subnet.=C2=A0 I would thin the TTL = for these packets should be 1.

OSPF packets have ttl of 255
ISIS packets hav= e ttl 1

BGP packets have= ttl 1

As far as GTSM, i= t is an alternative to cryptography option for securing routing protocols.= =C2=A0 Most enterprises and SPs in general use cryptography to secure routi= ng protocol adjacencies.=C2=A0 I don=E2=80=99t know of any implementation o= r operator using GTSM.

W= ith GTSM the idea is to use an expected TTL value configured by adjacent pe= ers to be set to different from the default value.=C2=A0 So that value can = be any value other then the default value.

= But the builders of these networks do know whether or not that is carried i= n IPv4, or in MPLS, or so.  It is them that could say what is there, u= nderlying.

Which is why I base my statements on discussi= ons with them. Were you assuming I was looking at this from my own perspect= ive as an end-user of facebook?

 

Owen

 

__________= _____________________________________ v6ops mailing list v6ops@ietf.org htt= ps://www.ietf.org/mailman/listinfo/v6ops


*********= *************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3667241507_1396837186-- From nobody Mon Mar 16 14:20:50 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA993A1184 for ; Mon, 16 Mar 2020 14:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1L85Js64GRX for ; Mon, 16 Mar 2020 14:20:47 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A1A893A1183 for ; Mon, 16 Mar 2020 14:20:47 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02GLJk8Q227516 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Mar 2020 14:20:45 -0700 From: Owen DeLong Message-Id: <1108969B-48D5-4A81-9E51-887F37B4111C@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F84DF116-7EBA-48F7-974C-35F46CD9E863" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Mar 2020 14:20:45 -0700 In-Reply-To: <3a33c3ce-d2ce-b4b2-091b-d4aff3162461@gmail.com> Cc: Matthew Petach , v6ops@ietf.org To: Alexandre Petrescu References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <8630BF2A-9831-44EE-8CA3-0C3647E86EDE@delong.com> <7d173149-8fc1-b0db-26af-fe5db1954386@gmail.com> <7C4711FE-5C90-4065-950B-FD61B802AE70@delong.com> <3a33c3ce-d2ce-b4b2-091b-d4aff3162461@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 16 Mar 2020 14:20:46 -0700 (PDT) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 21:20:49 -0000 --Apple-Mail=_F84DF116-7EBA-48F7-974C-35F46CD9E863 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 16, 2020, at 13:40 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 16/03/2020 =C3=A0 20:42, Owen DeLong a =C3=A9crit : >>=20 >>=20 >>> On Mar 16, 2020, at 04:03 , Alexandre Petrescu = > = wrote: >>>=20 >>>=20 >>>=20 >>> Le 16/03/2020 =C3=A0 08:05, Owen DeLong a =C3=A9crit : >>>>=20 >>>>=20 >>>>> On Mar 15, 2020, at 16:32 , Matthew Petach > wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong > wrote: >>>>> > On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu = > = wrote: >>>>> > Is facebook a network? I thought of it like a server farm. >>>>>=20 >>>>> How does one run a distributed server farm throughout the world = without connecting it with a network? Am I missing something? >>>>>=20 >>>>> I believe for a very long time, that would have accurately = described Akamai. >>>>=20 >>>> Akamai didn=E2=80=99t run a backbone. I=E2=80=99d argue that they = did run many rather sizable networks. >>>>=20 >>>>> Until their announcement, long after they had established = themselves in the marketplace, that they were going to deploy a network: = https://pc.nanog.org/static/published/meetings/NANOG71/1532/20171003_Kaufm= ann_Lightning_Talk_Akamai_v1.pdf = >>>> Oh, I=E2=80=99m very familiar with that particular project=E2=80=A6 = It was in it=E2=80=99s startup hey day during my tenure in Mr. = Kaufmann=E2=80=99s group. That was Akamai building a backbone to connect = many (not nearly all) of their networks together. >>>>=20 >>>> I stand by my original statement. One cannot (usefully) run a = server farm without a network. Network !=3D backbone. >>>=20 >>> I agree a server farm needs a network. But that network might be a = switched Ethernet with VLANs in a large building, or it might be made of = long haul links (ATM, FDDI, multi-Gigabit Ethernet fiber). >>>=20 >>> In the first case (call it VLAN) it is highly possible that VLAN in = a building, or a set of close by buildings, are IPv6 only, and no IPv4. >>>=20 >>=20 >> This is just silly=E2=80=A6 For the server farm to be useful, that = =E2=80=9CVLAN=E2=80=9D still needs a larger network in front of it that = eventually makes contact (ideally in multiple diverse ways) with a = larger internet. >>>=20 >>> But if the facebook system is a geographically distributed server = farm with a large network, it might be that at some point the data is = carried on IPv4 even though it is IPv6 over IPv4. >>>=20 >> In talking to Facebook=E2=80=99s engineers, they claim to do v4<->6 = translation at the edge where necessary to talk to IPv4-only clients and = are IPv6-only throughout their datacenters and other networks. >=20 > that v4<->v6 means facebook network is not IPv6-only >=20 No, it doesn=E2=80=99t. A few translation gateways at the very edge of = the network are precisely what allows the network itself to be = IPv6-only. Owen --Apple-Mail=_F84DF116-7EBA-48F7-974C-35F46CD9E863 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 16, 2020, at 13:40 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

=20 =20


Le 16/03/2020 =C3=A0 20:42, Owen = DeLong a =C3=A9crit :


On Mar 16, 2020, at 04:03 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


Le 16/03/2020 =C3=A0 08:05, = Owen DeLong a =C3=A9crit :
=

On Mar 15, 2020, at 16:32 , Matthew Petach <mpetach@netflight.com> wrote:



On = Fri, Mar 6, 2020 at 11:54 AM Owen DeLong <owen@delong.com> wrote:
> On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> Is facebook a network?  I = thought of it like a server farm.

How does one run a distributed server farm throughout the world without connecting it with a network? Am I missing something?

I believe for a very long time, that would have accurately described Akamai.

Akamai didn=E2=80=99t run a backbone. I=E2=80=99d = argue that they did run many rather sizable networks.

Until their announcement, = long after they had established themselves in the marketplace, that they were going to deploy a network: https://pc.nanog.org/static/published/meetings/NA= NOG71/1532/20171003_Kaufmann_Lightning_Talk_Akamai_v1.pdf

Oh, I=E2=80=99m very familiar with that particular = project=E2=80=A6 It was in it=E2=80=99s startup hey day during my tenure = in Mr. Kaufmann=E2=80=99s group. That was Akamai building a = backbone to connect many (not nearly all) of their networks together.

I stand by my original statement. One cannot (usefully) run a server farm without a network. Network !=3D backbone.


I agree a server farm needs a = network.  But that network might be a switched Ethernet with VLANs in a large building, or it might be made of long haul links (ATM, FDDI, multi-Gigabit Ethernet fiber).

In the first case (call it VLAN) it is highly possible that VLAN in a building, or a set of close by buildings, are IPv6 only, and no IPv4.


This is just silly=E2=80=A6 For the server farm to be useful, = that =E2=80=9CVLAN=E2=80=9D still needs a larger network in front of = it that eventually makes contact (ideally in multiple diverse ways) with a larger internet.

But if the = facebook system is a geographically distributed server farm with a large network, it might be that at some point the data is carried on IPv4 even though it is IPv6 over IPv4.

In talking to Facebook=E2=80=99s engineers, they claim to do v4<->6 translation at the edge where necessary to talk to IPv4-only clients and are IPv6-only throughout their datacenters and other networks.


that v4<->v6 means facebook network is not = IPv6-only


No, it doesn=E2=80=99t. A few translation gateways at = the very edge of the network are precisely what allows the network = itself to be IPv6-only.

Owen

= --Apple-Mail=_F84DF116-7EBA-48F7-974C-35F46CD9E863-- From nobody Mon Mar 16 14:57:43 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8212F3A1202 for ; Mon, 16 Mar 2020 14:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.67 X-Spam-Level: X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78chpkW7Umxc for ; Mon, 16 Mar 2020 14:57:39 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892163A11FA for ; Mon, 16 Mar 2020 14:57:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02GLvTk7006765; Mon, 16 Mar 2020 22:57:29 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 091E22081E5; Mon, 16 Mar 2020 22:57:29 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E9F83208199; Mon, 16 Mar 2020 22:57:28 +0100 (CET) Received: from [10.11.240.50] ([10.11.240.50]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02GLvRpE005271; Mon, 16 Mar 2020 22:57:28 +0100 To: Owen DeLong Cc: Matthew Petach , v6ops@ietf.org References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <8630BF2A-9831-44EE-8CA3-0C3647E86EDE@delong.com> <7d173149-8fc1-b0db-26af-fe5db1954386@gmail.com> <7C4711FE-5C90-4065-950B-FD61B802AE70@delong.com> <3a33c3ce-d2ce-b4b2-091b-d4aff3162461@gmail.com> <1108969B-48D5-4A81-9E51-887F37B4111C@delong.com> From: Alexandre Petrescu Message-ID: <76c81ccb-0cde-26bb-4650-a7053311bbe8@gmail.com> Date: Mon, 16 Mar 2020 22:57:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <1108969B-48D5-4A81-9E51-887F37B4111C@delong.com> Content-Type: multipart/alternative; boundary="------------B872E4685A1E8B478B068E71" Content-Language: fr Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 21:57:42 -0000 This is a multi-part message in MIME format. --------------B872E4685A1E8B478B068E71 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 16/03/2020 à 22:20, Owen DeLong a écrit : > > >> On Mar 16, 2020, at 13:40 , Alexandre Petrescu >> > >> wrote: >> >> >> Le 16/03/2020 à 20:42, Owen DeLong a écrit : >>> >>> >>>> On Mar 16, 2020, at 04:03 , Alexandre Petrescu >>>> >>> > wrote: >>>> >>>> >>>> Le 16/03/2020 à 08:05, Owen DeLong a écrit : >>>>> >>>>> >>>>>> On Mar 15, 2020, at 16:32 , Matthew Petach >>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong >>>>> > wrote: >>>>>> >>>>>> > On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu >>>>>> >>>>> > wrote: >>>>>> > Is facebook a network?  I thought of it like a server farm. >>>>>> >>>>>> How does one run a distributed server farm throughout the >>>>>> world without connecting it with a network? Am I missing >>>>>> something? >>>>>> >>>>>> >>>>>> I believe for a very long time, that would have accurately >>>>>> described Akamai. >>>>> >>>>> Akamai didn’t run a backbone. I’d argue that they did run many >>>>> rather sizable networks. >>>>> >>>>>> Until their announcement, long after they had established >>>>>> themselves in the marketplace, that they were going to deploy a >>>>>> network: >>>>>> https://pc.nanog.org/static/published/meetings/NANOG71/1532/20171003_Kaufmann_Lightning_Talk_Akamai_v1.pdf >>>>> >>>>> Oh, I’m very familiar with that particular project… It was in it’s >>>>> startup hey day during my tenure in Mr. Kaufmann’s group. That was >>>>> Akamai building a backbone to connect many (not nearly all) of >>>>> their networks together. >>>>> >>>>> I stand by my original statement. One cannot (usefully) run a >>>>> server farm without a network. Network != backbone. >>>> >>>> >>>> I agree a server farm needs a network.  But that network might be a >>>> switched Ethernet with VLANs in a large building, or it might be >>>> made of long haul links (ATM, FDDI, multi-Gigabit Ethernet fiber). >>>> >>>> In the first case (call it VLAN) it is highly possible that VLAN in >>>> a building, or a set of close by buildings, are IPv6 only, and no IPv4. >>>> >>> >>> This is just silly… For the server farm to be useful, that “VLAN” >>> still needs a larger network in front of it that eventually makes >>> contact (ideally in multiple diverse ways) with a larger internet. >>>> >>>> But if the facebook system is a geographically distributed server >>>> farm with a large network, it might be that at some point the data >>>> is carried on IPv4 even though it is IPv6 over IPv4. >>>> >>> In talking to Facebook’s engineers, they claim to do v4<->6 >>> translation at the edge where necessary to talk to IPv4-only clients >>> and are IPv6-only throughout their datacenters and other networks. >> >> >> that v4<->v6 means facebook network is not IPv6-only >> > > No, it doesn’t. A few translation gateways at the very edge of the > network are precisely what allows the network itself to be IPv6-only. Here' s where we differ in the definition of 'IPv6-only'.  I disagree with the above statement.  An IPv6-only network has no translatio gateways.  But it's just a definition, no problem :-) Alex > > Owen > --------------B872E4685A1E8B478B068E71 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Le 16/03/2020 à 22:20, Owen DeLong a écrit :


On Mar 16, 2020, at 13:40 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


Le 16/03/2020 à 20:42, Owen DeLong a écrit :


On Mar 16, 2020, at 04:03 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


Le 16/03/2020 à 08:05, Owen DeLong a écrit :


On Mar 15, 2020, at 16:32 , Matthew Petach <mpetach@netflight.com> wrote:



On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong <owen@delong.com> wrote:
> On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> Is facebook a network?  I thought of it like a server farm.

How does one run a distributed server farm throughout the world without connecting it with a network? Am I missing something?

I believe for a very long time, that would have accurately described Akamai.

Akamai didn’t run a backbone. I’d argue that they did run many rather sizable networks.

Until their announcement, long after they had established themselves in the marketplace, that they were going to deploy a network: https://pc.nanog.org/static/published/meetings/NANOG71/1532/20171003_Kaufmann_Lightning_Talk_Akamai_v1.pdf

Oh, I’m very familiar with that particular project… It was in it’s startup hey day during my tenure in Mr. Kaufmann’s group. That was Akamai building a backbone to connect many (not nearly all) of their networks together.

I stand by my original statement. One cannot (usefully) run a server farm without a network. Network != backbone.


I agree a server farm needs a network.  But that network might be a switched Ethernet with VLANs in a large building, or it might be made of long haul links (ATM, FDDI, multi-Gigabit Ethernet fiber).

In the first case (call it VLAN) it is highly possible that VLAN in a building, or a set of close by buildings, are IPv6 only, and no IPv4.


This is just silly… For the server farm to be useful, that “VLAN” still needs a larger network in front of it that eventually makes contact (ideally in multiple diverse ways) with a larger internet.

But if the facebook system is a geographically distributed server farm with a large network, it might be that at some point the data is carried on IPv4 even though it is IPv6 over IPv4.

In talking to Facebook’s engineers, they claim to do v4<->6 translation at the edge where necessary to talk to IPv4-only clients and are IPv6-only throughout their datacenters and other networks.


that v4<->v6 means facebook network is not IPv6-only


No, it doesn’t. A few translation gateways at the very edge of the network are precisely what allows the network itself to be IPv6-only.


Here' s where we differ in the definition of 'IPv6-only'.  I disagree with the above statement.  An IPv6-only network has no translatio gateways.  But it's just a definition, no problem :-)

Alex


Owen

--------------B872E4685A1E8B478B068E71-- From nobody Mon Mar 16 15:15:37 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D1B3A1262 for ; Mon, 16 Mar 2020 15:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRL4IvH2eric for ; Mon, 16 Mar 2020 15:15:28 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74563A1261 for ; Mon, 16 Mar 2020 15:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1584396925; x=1585001725; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=yAqRh8o+qmHhY4F1o27Flz17hP1rqwp+GI MSTcY8cC0=; b=t4LlMKEpeboJMTYlRAO6la5BCEIcpnBFTkqlVrWqcA9ApTumaH moJKznyQI0uNEN9DrC+OAtvGJQgC/8QyuFlRp+en8cYi6EVv7aUbUgw+6fqy9mjz ZGnJHeBHyzaKptIAf/kHLOHnO5dVX1Q5vQucGHP5CDstLfXT04gtSr390= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 16 Mar 2020 23:15:25 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 16 Mar 2020 23:15:25 +0100 Received: from [10.10.10.100] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000093691.msg for ; Mon, 16 Mar 2020 23:15:24 +0100 X-MDRemoteIP: 2001:470:1f09:495:a83b:e378:3a37:3744 X-MDHelo: [10.10.10.100] X-MDArrival-Date: Mon, 16 Mar 2020 23:15:24 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=134411b52a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Mon, 16 Mar 2020 23:15:23 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <8630BF2A-9831-44EE-8CA3-0C3647E86EDE@delong.com> <7d173149-8fc1-b0db-26af-fe5db1954386@gmail.com> <7C4711FE-5C90-4065-950B-FD61B802AE70@delong.com> <3a33c3ce-d2ce-b4b2-091b-d4aff3162461@gmail.com> <1108969B-48D5-4A81-9E51-887F37B4111C@delong.com> <76c81ccb-0cde-26bb-4650-a7053311bbe8@gmail.com> In-Reply-To: <76c81ccb-0cde-26bb-4650-a7053311bbe8@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3667245323_1256320026" Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 22:15:33 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3667245323_1256320026 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable That=E2=80=99s why the *only* objective way to define it is to clearly stat= e what part of the network you=E2=80=99re referring to. =20 Regards, Jordi @jordipalet =20 =20 =20 El 16/3/20 22:58, "v6ops en nombre de Alexandre Petrescu" escribi=C3=B3: =20 =20 Le 16/03/2020 =C3=A0 22:20, Owen DeLong a =C3=A9crit : =20 On Mar 16, 2020, at 13:40 , Alexandre Petrescu wrote: =20 =20 Le 16/03/2020 =C3=A0 20:42, Owen DeLong a =C3=A9crit : =20 On Mar 16, 2020, at 04:03 , Alexandre Petrescu wrote: =20 =20 Le 16/03/2020 =C3=A0 08:05, Owen DeLong a =C3=A9crit : =20 On Mar 15, 2020, at 16:32 , Matthew Petach wrote: =20 =20 =20 On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong wrote: > On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu wrote: > Is facebook a network? I thought of it like a server farm. How does one run a distributed server farm throughout the world without con= necting it with a network? Am I missing something? =20 I believe for a very long time, that would have accurately described Akamai= . =20 Akamai didn=E2=80=99t run a backbone. I=E2=80=99d argue that they did run m= any rather sizable networks. Until their announcement, long after they had established themselves in the= marketplace, that they were going to deploy a network: https://pc.nanog.or= g/static/published/meetings/NANOG71/1532/20171003_Kaufmann_Lightning_Talk_A= kamai_v1.pdf =20 Oh, I=E2=80=99m very familiar with that particular project=E2=80=A6 It was = in it=E2=80=99s startup hey day during my tenure in Mr. Kaufmann=E2=80=99s = group. That was Akamai building a backbone to connect many (not nearly all)= of their networks together. =20 I stand by my original statement. One cannot (usefully) run a server farm w= ithout a network. Network !=3D backbone. =20 I agree a server farm needs a network. But that network might be a switche= d Ethernet with VLANs in a large building, or it might be made of long haul= links (ATM, FDDI, multi-Gigabit Ethernet fiber). In the first case (call it VLAN) it is highly possible that VLAN in a build= ing, or a set of close by buildings, are IPv6 only, and no IPv4. =20 This is just silly=E2=80=A6 For the server farm to be useful, that =E2=80= =9CVLAN=E2=80=9D still needs a larger network in front of it that eventuall= y makes contact (ideally in multiple diverse ways) with a larger internet. =20 But if the facebook system is a geographically distributed server farm with= a large network, it might be that at some point the data is carried on IPv= 4 even though it is IPv6 over IPv4. In talking to Facebook=E2=80=99s engineers, they claim to do v4<->6 transla= tion at the edge where necessary to talk to IPv4-only clients and are IPv6-= only throughout their datacenters and other networks. =20 that v4<->v6 means facebook network is not IPv6-only =20 No, it doesn=E2=80=99t. A few translation gateways at the very edge of the = network are precisely what allows the network itself to be IPv6-only. =20 Here' s where we differ in the definition of 'IPv6-only'. I disagree with = the above statement. An IPv6-only network has no translatio gateways. But= it's just a definition, no problem :-) Alex =20 Owen =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3667245323_1256320026 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

That=E2=80=99s why the *only* objecti= ve way to define it is to clearly state what part of the network you=E2=80= =99re referring to.

 

Regards,

Jordi

@jordipalet

=  

 

 

El 16/3/20 22:58, "v6ops en nomb= re de Alexandre Petrescu" <v6ops-bounces@ietf.org en nombre de alexandre.petrescu@gmail.com> escribi=C3=B3:

 

 <= /p>

Le 16/03/2020 =C3= =A0 22:20, Owen DeLong a =C3=A9crit :

 



On Mar 16, 2020, at 13:40 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wr= ote:

=  

 <= /p>

Le 16/03/2020 =C3= =A0 20:42, Owen DeLong a =C3=A9crit :

 



On Mar 16, 2020, at 04:03 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wr= ote:

=  

 <= /p>

Le 16/03/2020 =C3= =A0 08:05, Owen DeLong a =C3=A9crit :

 



On Mar 15, 2020, at 16:32 , Matthew Petach <mpetach@netflight.com> wrote:

 <= /p>

 

=  

On Fri, Mar 6, 2020 at 11:54 = AM Owen DeLong <owen@delong.com&g= t; wrote:

> On Mar 5, 202= 0, at 8:51 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:> Is facebook a network?  I thought of it like a server farm.
<= br>How does one run a distributed server farm throughout the world without = connecting it with a network? Am I missing something?

 

I belie= ve for a very long time, that would have accurately described Akamai.<= /o:p>

 

Akamai didn=E2=80=99t run a backbone. I= =E2=80=99d argue that they did run many rather sizable networks.=



Unt= il their announcement, long after they had established themselves in the ma= rketplace, that they were going to deploy a network: https://pc.nanog.org/static/published/meetings/NANOG7= 1/1532/20171003_Kaufmann_Lightning_Talk_Akamai_v1.pdf

 

Oh, I=E2=80=99m very familiar with that particular = project=E2=80=A6 It was in it=E2=80=99s startup hey day during my tenure in= Mr. Kaufmann=E2=80=99s group. That was Akamai building a backbone to conne= ct many (not nearly all) of their networks together.

 

<= /div>

I stand by my o= riginal statement. One cannot (usefully) run a server farm without a networ= k. Network !=3D backbone.

 

I agree a server f= arm needs a network.  But that network might be a switched Ethernet wi= th VLANs in a large building, or it might be made of long haul links (ATM, = FDDI, multi-Gigabit Ethernet fiber).

In the first case (call it VLAN) it is highly possible that VLAN in a bui= lding, or a set of close by buildings, are IPv6 only, and no IPv4.

 

This is just silly=E2=80=A6 For the server farm to be useful, = that =E2=80=9CVLAN=E2=80=9D still needs a larger network in front of it tha= t eventually makes contact (ideally in multiple diverse ways) with a larger= internet.

 

But if the f= acebook system is a geographically distributed server farm with a large net= work, it might be that at some point the data is carried on IPv4 even thoug= h it is IPv6 over IPv4.

In talking to Facebook=E2=80=99s engineers, they claim to do v4<->6 translat= ion at the edge where necessary to talk to IPv4-only clients and are IPv6-o= nly throughout their datacenters and other networks.

 

that v4<->v6 means facebook network is not IPv6-only

 

No, it doesn=E2=80=99t. A few translation gateways at the ver= y edge of the network are precisely what allows the network itself to be IP= v6-only.

<= o:p> 

Here' s where we differ= in the definition of 'IPv6-only'.  I disagree with the above statemen= t.  An IPv6-only network has no translatio gateways.  But it's ju= st a definition, no problem :-)

Alex

 

Owen

 

_______________________________________________ v6ops mailing = list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3667245323_1256320026-- From nobody Wed Mar 18 12:32:26 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC0D3A1AA4 for ; Wed, 18 Mar 2020 12:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.11 X-Spam-Level: X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk2ueNoDNyEZ for ; Wed, 18 Mar 2020 12:32:20 -0700 (PDT) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B683A1A9E for ; Wed, 18 Mar 2020 12:32:20 -0700 (PDT) Received: by mail-il1-f179.google.com with SMTP id l14so24794566ilj.8 for ; Wed, 18 Mar 2020 12:32:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PP0sjov4XBchMTTWD5UC5NHXTvJVPB6/nErPRjYNAQM=; b=GsC4gY/kP1cfvJvhirrfLIixLAcFMtaMhJofWqhd1iUuf7kKfgxQto1vY0mK0jiMa7 zfsB5Thp1YNPuxItPqrsFon00LbnOw3VXNjXIsX5jrZDVm3R+65SgfZj4o7o9R6DT80c jrkuLlGrYlNlzWG+1LutFSOfwBpIJ/emazk4mMZuk/4t9rSwBuMVLEC6R7v6yflrOf/7 rFuLilP8GgNfuoHwUlFN/5S3Gc4p3WFfZ4LBepDdKVT1vN3eJ/7C14WQWrw+bkqb8Jdl 5fmb30M0WqQT4Embg2mDQs1C6ZOJv80jFlLoTj8S6A41Q2bMlnwrEJ5VazZMW4VW4SLD RIKg== X-Gm-Message-State: ANhLgQ2Px0RZ2jja7YEKqkFq2mR3TEb8Gs/dtIHhfK9MexW2hjTwwGVA t3oX0VgJRBe/xv0oqClyUsIUqVGM0dHBWYj2CUQ= X-Google-Smtp-Source: ADFU+vtduQeiaXBicUo8uffnMHEQJpi0gnKuRBoJBBs5jqHX6WPO68y6T6MoXWPC9Mv07FuIEOh94NBtbok9dwIfnB0= X-Received: by 2002:a92:89d5:: with SMTP id w82mr5504678ilk.95.1584559939339; Wed, 18 Mar 2020 12:32:19 -0700 (PDT) MIME-Version: 1.0 References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <8630BF2A-9831-44EE-8CA3-0C3647E86EDE@delong.com> In-Reply-To: <8630BF2A-9831-44EE-8CA3-0C3647E86EDE@delong.com> From: Matthew Petach Date: Wed, 18 Mar 2020 12:32:08 -0700 Message-ID: To: Owen DeLong Cc: Alexandre Petrescu , v6ops@ietf.org Content-Type: multipart/alternative; boundary="0000000000004f4e3105a1261ca5" Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 19:32:25 -0000 --0000000000004f4e3105a1261ca5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 16, 2020 at 12:06 AM Owen DeLong wrote: > On Mar 15, 2020, at 16:32 , Matthew Petach wrote: > On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong wrote: > > > On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu < >> alexandre.petrescu@gmail.com> wrote: >> > Is facebook a network? I thought of it like a server farm. >> >> How does one run a distributed server farm throughout the world without >> connecting it with a network? Am I missing something? >> > > I believe for a very long time, that would have accurately described > Akamai. > > > Akamai didn=E2=80=99t run a backbone. I=E2=80=99d argue that they did run= many rather > sizable networks. > > Until their announcement, long after they had established themselves in > the marketplace, that they were going to deploy a network: > https://pc.nanog.org/static/published/meetings/NANOG71/1532/20171003_Kauf= mann_Lightning_Talk_Akamai_v1.pdf > > > Oh, I=E2=80=99m very familiar with that particular project=E2=80=A6 It wa= s in it=E2=80=99s startup > hey day during my tenure in Mr. Kaufmann=E2=80=99s group. That was Akamai= building > a backbone to connect many (not nearly all) of their networks together. > > I stand by my original statement. One cannot (usefully) run a server farm > without a network. Network !=3D backbone. > Fair point. Having spent so much of my career focusing on global backbones, I did become somewhat myopic in my focus on what Networks were. Yes, datacenter have networks as well. Apologies for brushing them off so cavalierly. ^_^;; > > Owen > > Matt --0000000000004f4e3105a1261ca5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Mar 16, 2020 at 12:06 AM Owen= DeLong <owen@delong.com> wrot= e:
On Mar 15, 2020, at 16:32 , Matthew Petach <mpetach@netflight.com> wrote:=C2=A0
=C2=A0 On Fri, Mar 6, 2020 at = 11:54 AM Owen DeLong <owen@delong.com> wrote:
> On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com= > wrote:
> Is facebook a network?=C2=A0 I thought of it like a server farm.

How does one run a distributed server farm throughout the world without con= necting it with a network? Am I missing something?
I believe for a very long time, that would have accurately desc= ribed Akamai.

Akam= ai didn=E2=80=99t run a backbone. I=E2=80=99d argue that they did run many = rather sizable networks.

Until their an= nouncement, long after they had established themselves in the marketplace, = that they were going to deploy a network: https://pc.nanog.org/static/published/meetings= /NANOG71/1532/20171003_Kaufmann_Lightning_Talk_Akamai_v1.pdf

Oh, I=E2=80=99m very familia= r with that particular project=E2=80=A6 It was in it=E2=80=99s startup hey = day during my tenure in Mr. Kaufmann=E2=80=99s group. That was Akamai build= ing a backbone to connect many (not nearly all) of their networks together.=

I stand by my original statement. One cannot (use= fully) run a server farm without a network. Network !=3D backbone.

Fair point.

Ha= ving spent so much of my career focusing on global backbones, I did become = somewhat myopic in my focus on what Networks were.

Yes, datacenter have networks as well.

Apologies = for brushing them off so cavalierly. =C2=A0^_^;;
=C2=A0

Owen

Matt
=C2=A0
--0000000000004f4e3105a1261ca5-- From nobody Fri Mar 20 07:32:40 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAB23A09E4; Fri, 20 Mar 2020 07:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IZ5LRHT-JLh; Fri, 20 Mar 2020 07:32:22 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE44D3A0BE4; Fri, 20 Mar 2020 07:30:15 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3AB87548047; Fri, 20 Mar 2020 15:30:09 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 331BD440040; Fri, 20 Mar 2020 15:30:09 +0100 (CET) Date: Fri, 20 Mar 2020 15:30:09 +0100 From: Toerless Eckert To: Gyan Mishra Cc: Jen Linkova , 6man <6man@ietf.org>, V6 Ops List Message-ID: <20200320143009.GA19351@faui48f.informatik.uni-erlangen.de> References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 14:32:33 -0000 On Sat, Mar 14, 2020 at 02:07:34AM -0400, Gyan Mishra wrote: > Jen > > I always wondered why RFC 4862 states that ND & RD packets have TTL 255. > We have run into so many PSIRT bugs with ND which makes it more problematic > having the TTL 255. Is there anything that would makes you think 255 is a worse choice for security than 1 ? Or is it just implementation bugs ? Cheers Toerless > Since ND & RD packets would always be local scope in your response to > Toreless you mentioned that GTSM that ND using 255 is kind of an example of > GTSM in the sense that the TTL is set to 255 for a direct neighbor > adjacency. I think though the security issues of TTL 255 with ND/RD > packets seem to make security a bigger issue then just leaving TTL=1. > > Gyan > > On Wed, Mar 11, 2020 at 8:34 PM Jen Linkova wrote: > > > On Thu, Mar 12, 2020 at 11:01 AM Toerless Eckert wrote: > > > > > > Sorry for cross posting, but this is both ops and arch questions. > > > > > > I was trying to find any generic description that/if link-local IPv6 > > > traffic MUST/SHOULD use Hop-count 1, but could not find one in > > > rfc8200 or rfc4291 and its updates. Instead, text like > > > MUST set Hop-limit to 1 is repeated in various RFCs using link-local > > > IPv6 traffic. > > > > I believe it depends what you are trying to achieve. If you want to > > make sure that the traffic never leaves the network - then hop limit = > > 1 helps. But using link-local sources/destinations would help even > > better if the routers comply with RFC4291 Section 2.5.6 > > If you want to make sure those packets are not sent by a malicious > > party from outside - hop limit shall be 255. > > For example, see RFC4861 Section 3.1 > > > > > Am i overlooking something ? Or is this intentional in the IPv6 > > architecture ? > > > > > > If intentional, i guess it means: Any RFC introducing some type of > > link-local > > > traffic can specify Hop-limit requirements for its traffic. As in > > > "our WG likes 42 as the Hop-limit" (silly to me, but should be fine with > > > IPv6 architecture then, right ?). > > > > > > In one of my draft document reviews using such link-local IPv6 traffic, > > > EricV brought up the Q if that traffic shouldn't use RFC5082 instead > > > of Hop-Count 1 too. But given how we do not seem to have architectural > > > recommendations for TTL=1 (unless, quite likely i overlook something), > > > and given how i am not aware of any actual use of GTSM, i am quite > > > weary to go down that route. Aka: Would like learn of actual uses of > > > GTSM with IPv6. > > > > Neighbor Discovery. > > > > > There is an additional set of consideration re. link-local traffic > > > when trying to use it as a HW accelerated tunneling mechanism across > > links, > > > a use we both have in ANIMA, and maybe get the same in BIER (probably > > > other WGs too, not sure). > > > > > > In implementations, i have seen quite a range of issues with > > > accelerated forwarding planes across link-local addressed tunnels, > > > and when using non-link-local addresses (loopback addresses), > > > the HW plane forwarding might have issues doing HW forwarding, because > > > usually TTL=1 is only used for control plane traffic. Of course, > > > this is not a good architectural argument, but if given architectural > > > leeway to even choose 42, maybe GTSM/255 is easier to be supported > > > across various HW accelerated forwarding planes than 1. > > > > > > Opinions and experiences welcome! > > > > If you control the router I'd say 'link-local source/destination, > > HL=255 AND RFC4291 would be the best option. > > > > I did see a few devices somewhere far away sending me ICMPv6 (packet > > too big) from their link-local addresses but it was not very common > > case. > > > > -- > > SY, Jen Linkova aka Furry > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: gyan.s.mishra@verizon.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- --- tte@cs.fau.de From nobody Fri Mar 20 08:19:17 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D6D3A09EC; Fri, 20 Mar 2020 08:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8uefOI1A48o; Fri, 20 Mar 2020 08:19:12 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75AC3A09F8; Fri, 20 Mar 2020 08:19:11 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id h9so7929817wrc.8; Fri, 20 Mar 2020 08:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oQw3l80YLOHIvxC5YrL558YVDypcKPtQkPVvP0htK7s=; b=Fuf1LxBqJvreus61Aa+w5k8Yz83WwofyihjBEuMKtSYoZLkpXqvL0+LWsshUfDcmuT cLtiOxPPOCeezdovl/29ZyThq+YqOvfexxqcWbI7P85DnjptKZxlZzdYo5duJCpwPIuu p2SSBF92h0P52XroBpvL42QOVKuyvtlitxvcNtQi8zJWDZsGY25vM8W90TxPLho14HLl QAM0gobmXrloa8bclSgyUi4d6jtriyj2Tzb4kG2cK8fDZJBJtY95+jLU4KonrXfRk7eC wxLOymhLs/unfDpc1e/rFB22buBrn81MMxnmTNHKh4w8Ho0i7b53ejYJfF8BjLxrT6FZ 2cFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oQw3l80YLOHIvxC5YrL558YVDypcKPtQkPVvP0htK7s=; b=VBbo2EGrkeKrj4i0x/PvbGIGfvf8+Xqo3+HGucnBDj+ee9KTW0EU5uAMfezWALpOmH hdpBBjglR6R1EtNki9HOPF8mTKE9AWLj6DRogMIEHjZKTofIgcOLJymIrx9BxlqO+fvO sFKmY1xOQ9dXjw0nsCYpi+aL7VGMxwQfkUTN29WPCUhSJLMlDNtvH6LqrTIeK7pyDMbC S+lMNfZ8e/UmfeFY11CqQadIX/A/jcdddqtTEad8c37ZakbLkMQvoU5u4m0KQzxagTP4 zsNFH2JPKG+33vjC/r+QJMoVmcNaoBkkHLsBvV0Bvm/q7Yzb7MuFhfp+Swxxp0waEEsn MVSA== X-Gm-Message-State: ANhLgQ3BaYNLBzNPcWgWyyb5EzYsXZWzq60JcplzYX99GK1p/YCX9Em+ u3IpO6s5f2zmzAltNl2/Zes= X-Google-Smtp-Source: ADFU+vsYlNGVwXjcO6P74VVTDmyDs9XasLNojfMRsNPfV3+uQfmmtAlv9t+rGvATe4KjsIDXyrt+OQ== X-Received: by 2002:a05:6000:cb:: with SMTP id q11mr1724977wrx.25.1584717550040; Fri, 20 Mar 2020 08:19:10 -0700 (PDT) Received: from broadband.bt.com ([2a00:23a8:4140:0:c881:c394:4fcb:1056]) by smtp.gmail.com with ESMTPSA id i1sm8999916wrs.18.2020.03.20.08.19.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2020 08:19:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Stewart Bryant In-Reply-To: <20200320143009.GA19351@faui48f.informatik.uni-erlangen.de> Date: Fri, 20 Mar 2020 15:19:07 +0000 Cc: Stewart Bryant , Gyan Mishra , 6man <6man@ietf.org>, V6 Ops List Content-Transfer-Encoding: quoted-printable Message-Id: <046A495C-068F-4F72-8545-003970DF3D25@gmail.com> References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <20200320143009.GA19351@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 15:19:15 -0000 > On 20 Mar 2020, at 14:30, Toerless Eckert wrote: >=20 > On Sat, Mar 14, 2020 at 02:07:34AM -0400, Gyan Mishra wrote: >> Jen >>=20 >> I always wondered why RFC 4862 states that ND & RD packets have TTL = 255. >> We have run into so many PSIRT bugs with ND which makes it more = problematic >> having the TTL 255. >=20 > Is there anything that would makes you think 255 is a worse > choice for security than 1 ? Or is it just implementation bugs ? >=20 > Cheers > Toerless 1 anyone can fake. 255 can only come from a neighbour which it is used as a simple security = check. Stewart >=20 >> Since ND & RD packets would always be local scope in your response to >> Toreless you mentioned that GTSM that ND using 255 is kind of an = example of >> GTSM in the sense that the TTL is set to 255 for a direct neighbor >> adjacency. I think though the security issues of TTL 255 with ND/RD >> packets seem to make security a bigger issue then just leaving TTL=3D1.= >>=20 >> Gyan >>=20 >> On Wed, Mar 11, 2020 at 8:34 PM Jen Linkova = wrote: >>=20 >>> On Thu, Mar 12, 2020 at 11:01 AM Toerless Eckert = wrote: >>>>=20 >>>> Sorry for cross posting, but this is both ops and arch questions. >>>>=20 >>>> I was trying to find any generic description that/if link-local = IPv6 >>>> traffic MUST/SHOULD use Hop-count 1, but could not find one in >>>> rfc8200 or rfc4291 and its updates. Instead, text like >>>> MUST set Hop-limit to 1 is repeated in various RFCs using = link-local >>>> IPv6 traffic. >>>=20 >>> I believe it depends what you are trying to achieve. If you want to >>> make sure that the traffic never leaves the network - then hop limit = =3D >>> 1 helps. But using link-local sources/destinations would help even >>> better if the routers comply with RFC4291 Section 2.5.6 >>> If you want to make sure those packets are not sent by a malicious >>> party from outside - hop limit shall be 255. >>> For example, see RFC4861 Section 3.1 >>>=20 >>>> Am i overlooking something ? Or is this intentional in the IPv6 >>> architecture ? >>>>=20 >>>> If intentional, i guess it means: Any RFC introducing some type of >>> link-local >>>> traffic can specify Hop-limit requirements for its traffic. As in >>>> "our WG likes 42 as the Hop-limit" (silly to me, but should be fine = with >>>> IPv6 architecture then, right ?). >>>>=20 >>>> In one of my draft document reviews using such link-local IPv6 = traffic, >>>> EricV brought up the Q if that traffic shouldn't use RFC5082 = instead >>>> of Hop-Count 1 too. But given how we do not seem to have = architectural >>>> recommendations for TTL=3D1 (unless, quite likely i overlook = something), >>>> and given how i am not aware of any actual use of GTSM, i am quite >>>> weary to go down that route. Aka: Would like learn of actual uses = of >>>> GTSM with IPv6. >>>=20 >>> Neighbor Discovery. >>>=20 >>>> There is an additional set of consideration re. link-local traffic >>>> when trying to use it as a HW accelerated tunneling mechanism = across >>> links, >>>> a use we both have in ANIMA, and maybe get the same in BIER = (probably >>>> other WGs too, not sure). >>>>=20 >>>> In implementations, i have seen quite a range of issues with >>>> accelerated forwarding planes across link-local addressed tunnels, >>>> and when using non-link-local addresses (loopback addresses), >>>> the HW plane forwarding might have issues doing HW forwarding, = because >>>> usually TTL=3D1 is only used for control plane traffic. Of course, >>>> this is not a good architectural argument, but if given = architectural >>>> leeway to even choose 42, maybe GTSM/255 is easier to be supported >>>> across various HW accelerated forwarding planes than 1. >>>>=20 >>>> Opinions and experiences welcome! >>>=20 >>> If you control the router I'd say 'link-local source/destination, >>> HL=3D255 AND RFC4291 would be the best option. >>>=20 >>> I did see a few devices somewhere far away sending me ICMPv6 (packet >>> too big) from their link-local addresses but it was not very common >>> case. >>>=20 >>> -- >>> SY, Jen Linkova aka Furry >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>>=20 >>=20 >>=20 >> --=20 >>=20 >> Gyan Mishra >>=20 >> Network Engineering & Technology >>=20 >> Verizon >>=20 >> Silver Spring, MD 20904 >>=20 >> Phone: 301 502-1347 >>=20 >> Email: gyan.s.mishra@verizon.com >=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > --=20 > --- > tte@cs.fau.de >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Mar 20 18:21:27 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29923A0FB4; Fri, 20 Mar 2020 18:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm92bF2onQYE; Fri, 20 Mar 2020 18:21:15 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154CB3A103B; Fri, 20 Mar 2020 18:21:14 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BE507548048; Sat, 21 Mar 2020 02:21:07 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B508D440040; Sat, 21 Mar 2020 02:21:07 +0100 (CET) Date: Sat, 21 Mar 2020 02:21:07 +0100 From: Toerless Eckert To: Stewart Bryant Cc: Gyan Mishra , 6man <6man@ietf.org>, V6 Ops List Message-ID: <20200321012107.GB19351@faui48f.informatik.uni-erlangen.de> References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <20200320143009.GA19351@faui48f.informatik.uni-erlangen.de> <046A495C-068F-4F72-8545-003970DF3D25@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046A495C-068F-4F72-8545-003970DF3D25@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 01:21:25 -0000 Thank, Stewart, Yes, i know. My question was specifically wrt. mentioning of PSIRT bugs by Gyan, sorry if my reply was unclear. Of course only interested in any additional security insight that is public and related to the choice of TTL by ND, not any vendor internal / implementation bug issues. Cheers Toerless On Fri, Mar 20, 2020 at 03:19:07PM +0000, Stewart Bryant wrote: > > > > On 20 Mar 2020, at 14:30, Toerless Eckert wrote: > > > > On Sat, Mar 14, 2020 at 02:07:34AM -0400, Gyan Mishra wrote: > >> Jen > >> > >> I always wondered why RFC 4862 states that ND & RD packets have TTL 255. > >> We have run into so many PSIRT bugs with ND which makes it more problematic > >> having the TTL 255. > > > > Is there anything that would makes you think 255 is a worse > > choice for security than 1 ? Or is it just implementation bugs ? > > > > Cheers > > Toerless > > 1 anyone can fake. > > 255 can only come from a neighbour which it is used as a simple security check. > > Stewart > > > > > >> Since ND & RD packets would always be local scope in your response to > >> Toreless you mentioned that GTSM that ND using 255 is kind of an example of > >> GTSM in the sense that the TTL is set to 255 for a direct neighbor > >> adjacency. I think though the security issues of TTL 255 with ND/RD > >> packets seem to make security a bigger issue then just leaving TTL=1. > >> > >> Gyan > >> > >> On Wed, Mar 11, 2020 at 8:34 PM Jen Linkova wrote: > >> > >>> On Thu, Mar 12, 2020 at 11:01 AM Toerless Eckert wrote: > >>>> > >>>> Sorry for cross posting, but this is both ops and arch questions. > >>>> > >>>> I was trying to find any generic description that/if link-local IPv6 > >>>> traffic MUST/SHOULD use Hop-count 1, but could not find one in > >>>> rfc8200 or rfc4291 and its updates. Instead, text like > >>>> MUST set Hop-limit to 1 is repeated in various RFCs using link-local > >>>> IPv6 traffic. > >>> > >>> I believe it depends what you are trying to achieve. If you want to > >>> make sure that the traffic never leaves the network - then hop limit = > >>> 1 helps. But using link-local sources/destinations would help even > >>> better if the routers comply with RFC4291 Section 2.5.6 > >>> If you want to make sure those packets are not sent by a malicious > >>> party from outside - hop limit shall be 255. > >>> For example, see RFC4861 Section 3.1 > >>> > >>>> Am i overlooking something ? Or is this intentional in the IPv6 > >>> architecture ? > >>>> > >>>> If intentional, i guess it means: Any RFC introducing some type of > >>> link-local > >>>> traffic can specify Hop-limit requirements for its traffic. As in > >>>> "our WG likes 42 as the Hop-limit" (silly to me, but should be fine with > >>>> IPv6 architecture then, right ?). > >>>> > >>>> In one of my draft document reviews using such link-local IPv6 traffic, > >>>> EricV brought up the Q if that traffic shouldn't use RFC5082 instead > >>>> of Hop-Count 1 too. But given how we do not seem to have architectural > >>>> recommendations for TTL=1 (unless, quite likely i overlook something), > >>>> and given how i am not aware of any actual use of GTSM, i am quite > >>>> weary to go down that route. Aka: Would like learn of actual uses of > >>>> GTSM with IPv6. > >>> > >>> Neighbor Discovery. > >>> > >>>> There is an additional set of consideration re. link-local traffic > >>>> when trying to use it as a HW accelerated tunneling mechanism across > >>> links, > >>>> a use we both have in ANIMA, and maybe get the same in BIER (probably > >>>> other WGs too, not sure). > >>>> > >>>> In implementations, i have seen quite a range of issues with > >>>> accelerated forwarding planes across link-local addressed tunnels, > >>>> and when using non-link-local addresses (loopback addresses), > >>>> the HW plane forwarding might have issues doing HW forwarding, because > >>>> usually TTL=1 is only used for control plane traffic. Of course, > >>>> this is not a good architectural argument, but if given architectural > >>>> leeway to even choose 42, maybe GTSM/255 is easier to be supported > >>>> across various HW accelerated forwarding planes than 1. > >>>> > >>>> Opinions and experiences welcome! > >>> > >>> If you control the router I'd say 'link-local source/destination, > >>> HL=255 AND RFC4291 would be the best option. > >>> > >>> I did see a few devices somewhere far away sending me ICMPv6 (packet > >>> too big) from their link-local addresses but it was not very common > >>> case. > >>> > >>> -- > >>> SY, Jen Linkova aka Furry > >>> > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >>> > >> > >> > >> -- > >> > >> Gyan Mishra > >> > >> Network Engineering & Technology > >> > >> Verizon > >> > >> Silver Spring, MD 20904 > >> > >> Phone: 301 502-1347 > >> > >> Email: gyan.s.mishra@verizon.com > > > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > > -- > > --- > > tte@cs.fau.de > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Fri Mar 20 18:59:58 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C093A0E77; Fri, 20 Mar 2020 18:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNaXT5L4BIog; Fri, 20 Mar 2020 18:59:46 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6253A0F50; Fri, 20 Mar 2020 18:59:25 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id m7so3568093ilg.5; Fri, 20 Mar 2020 18:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oHCwNLu17HHzPY4uNytakL4GEtyvdDItq13QEvY4h9k=; b=PtvaRiQAJCuU4K5QPWARzaKWZVhrbPLrGYsWsUA4MLzVKONiLOBFq6FjxINiOODimW o6WRxWIaPudzoRiT2SbElvJDxUk2sQG31siT0c9qY3zY9/fz3NV5yGP0ig/IDeccKrhr tx/IsEA+oPywZiWiO8IM/ywp6061XLFABbC6Y6vqreUaRQhz+X39pqMc12s+AEQdypuE 90ANk0JNjwIbL96IcPjODTf5nHbBw+B7jlziZIAB2Q6mxEfCJgOyZB6tbNlJrHD9i92t T7Fkfthyg9F8VKjOSJsgZ5cY0MSh/EQwmm38WN7+8/loIh8a0rDgpq8cLozCxqvgvlXb UlCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oHCwNLu17HHzPY4uNytakL4GEtyvdDItq13QEvY4h9k=; b=ujLEhW4SiEJjlD+7ldRhMVze8aaapmCPF5kOURPq7BPmhUY3dby4sDHRCPn3CYau4z Rt3DpvNvlSgJvbBiZRjFZqfReeXx5cz4Jvxsabrhxqv8NkOc4art8+HGtRfK5sBnt27k KYYML3lWpmjWbeSGODLaUQ5q6zXZa/ZRVNtYkcZr65me2OwB9jQd2e9o6p5PxblbwFZZ H+k676drSYWQKPBptfxAgVM/UdncA8SUe62JlX1fHvULh3yyAUMi3Ln++In+OW7h5Wd3 D+mQZmoVHWTfiISRJh0U9SEgDc2YCjIrkvWXrjGo3C+Y9QQssI6bcG3Y/sL+dmZrCVca ZhNQ== X-Gm-Message-State: ANhLgQ03xt6PMpVvNAXC2pMvRHfiugIYg4KAdLYR0SNUrCSXs/BpmB49 uEgLy6EDmOyomrH81WKcikR5BvsSBQZHodUrGbE= X-Google-Smtp-Source: ADFU+vu6df/5+2NvL3aXQC00DVz7TF2kh0M4DNSujZTEuBiXAqKOUejLQ/4HWIe2PRbkLU0LagRG8Kd3oQ4VfltDNqU= X-Received: by 2002:a92:5e91:: with SMTP id f17mr11452969ilg.239.1584755956905; Fri, 20 Mar 2020 18:59:16 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <1584173474.2857.102.camel@biplane.com.au> In-Reply-To: From: Tony Przygienda Date: Fri, 20 Mar 2020 18:57:30 -0700 Message-ID: To: Gyan Mishra Cc: Toerless Eckert , kauer@biplane.com.au, 6man <6man@ietf.org>, V6 Ops List Content-Type: multipart/alternative; boundary="000000000000ddfee205a153bf94" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 01:59:56 -0000 --000000000000ddfee205a153bf94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yepp, that's personally I prefer on multicast TTL=3D1 (and also on ISIS & e.g. on expired draft where we were carrying ISIS natively over IP). The cost of a frame running away unintended multiple-hops in a control protocol without a tunnel are simply NOT fun. The cost of such a thing (and it happened MORE than once) outweighs IMO the minor security advantage. If you read v6 BIER drafts you should read https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/ which has been published much, much earlier ... --- tony On Sat, Mar 14, 2020 at 10:38 AM Gyan Mishra wrote: > > Toreless & Tony > > I read through the draft for BIER over IPv6. > > https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06 > > So since the BIER header bitmask that denotes the BFERs in the Domain to > replicate the multicast packets is encoded in the DestOp processed by the > BFER, the packets should not be forwarded past the BFER is my guess is wi= th > ttl 255. With IPv6 ND with ttl 255 example the packet can be forwarded > past the adjacent node but I have not seen that happen. I believe Jen > Linkova on this thread has seen that. Since the BFER dest options has to > have the BIER bit mask encoding or the packet is dropped I believe is you= r > security protection from forwarding past the BIER with 255 ttl if you > decided to go that route. > > Under BIERv6 packet processing should help if ttl 255 is used to prevent > forwarding outside of bier domain > > A packet having a 'BIER Specific Handling' indication but not having > a BIER option is supposed to be a wrong packet or an ICMPv6 packet, > and the process can be refered to the example in section 3.2 . > > A packet not having a 'BIER Specific Handling' indication but having > a BIER option SHOULD be processed normally as unicast forwarding > procedures, which may be a behavior of drop, or send to CPU, or other > behaviors in existing implementations. > > > Under 5.3 security considerations should also help with ttl 255 and > forwarding outside of BIER domain > > For a router incapable of BIERv6, such BIERv6 packet will not be > processed by the procedure described in this document, but be > processed as normal IPv6 packet with unknown option, and the existing > security considerations for handling IPv6 options apply. Possible > way of handling IPv6 packets with BIER option may be send to CPU for > slow path processing, with rate-limiting, or be discarded according > to the local policy. > > For a router capable of BIERv6, such BIERv6 packet MUST NOT be > forwarded, but should be processed as a normal IPv6 packet with > unknown option, or additionally and optionally be countered and > logged if the router is capable of doing so. > > > Kind regards > > Gyan > > On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra > wrote: > >> >> Makes sense. >> >> Thanks >> >> Gyan >> >> On Sat, Mar 14, 2020 at 4:12 AM Karl Auer wrote: >> >>> On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote: >>> > I always wondered why RFC 4862 states that ND & RD packets have TTL >>> > 255. >>> >>> >From RFC4861: >>> >>> "By setting the Hop Limit to 255, Neighbor Discovery >>> is immune to off-link senders that accidentally or >>> intentionally send ND messages. In IPv4, off-link >>> senders can send both ICMP Redirects and Router >>> Advertisement messages." >>> >>> RFC4861 also requires RA and NA packets with any other TTL value to be >>> silently discarded by any receiving node. >>> >>> I can't find my original source, but my notes in a training course I >>> developed a while ago have this to say about why: >>> >>> "Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Because routers >>> decrement the hop limit on packets passing through >>> them, and discard packets where the hop count >>> decrements to zero. It is impossible to decrement >>> a one-byte counter to 255 without passing through >>> zero, because 255 is the maximum value such a counter >>> can have. So the value 255 means that the packet must >>> have been generated on the local link." >>> >>> Probably would be better expressed as "must have originated on the >>> local link". >>> >>> Regards, K. >>> >>> -- >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Karl Auer (kauer@biplane.com.au) >>> http://www.biplane.com.au/kauer >>> http://twitter.com/kauer389 >>> >>> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170 >>> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: gyan.s.mishra@verizon.com >> >> >> >> -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: gyan.s.mishra@verizon.com > > > > --000000000000ddfee205a153bf94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yepp, that's personally I prefer on multicast TTL= =3D1 (and also on ISIS & e.g. on expired draft where we were carrying I= SIS natively over IP). The cost of a frame running away unintended multiple= -hops in a control protocol without a tunnel are simply NOT fun.=C2=A0 The = cost of such a thing (and it happened MORE than once) outweighs IMO the min= or security advantage.

If you read v6 BIER dr= afts you should read https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/= which has been published much, much earlier ...

--- tony




On = Sat, Mar 14, 2020 at 10:38 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

Tore= less & Tony=C2=A0

I = read through the draft for BIER over IPv6.

So s= ince the BIER header bitmask that denotes the BFERs in the Domain to replic= ate the multicast packets is encoded in the DestOp processed by the BFER, t= he packets should not be forwarded past the BFER is my guess is with ttl 25= 5.=C2=A0 With IPv6 ND with ttl 255 example the packet can be forwarded past= the adjacent node but I have not seen that happen.=C2=A0 I believe Jen Lin= kova on this thread has seen that. Since the BFER dest options has to have = the BIER bit mask encoding or the packet is dropped I believe is your secur= ity protection from forwarding past the BIER with 255 ttl if you decided to= go that route.

Under BI= ERv6 packet processing should help if ttl 255 is used to prevent forwarding= outside of bier domain=C2=A0

A packet having a 'BIER Specific Handling' indication bu=
t not having
   a BIER option is supposed to be a wrong packet or an ICMPv6 packet,
   and the process can be refered to the example in section 3.2.

   A packet not having a 'BIER Specific Handling' indication but ha=
ving
   a BIER option SHOULD be processed normally as unicast forwarding
   procedures, which may be a behavior of drop, or send to CPU, or other
   behaviors in existing implementations.

=
Under 5.3 security considerations should also help = with ttl 255 and forwarding outside of BIER domain
<= br>
For a router incapable of BIERv6, such BIER=
v6 packet will not be
   processed by the procedure described in this document, but be
   processed as normal IPv6 packet with unknown option, and the existing
   security considerations for handling IPv6 options apply.  Possible
   way of handling IPv6 packets with BIER option may be send to CPU for
   slow path processing, with rate-limiting, or be discarded according
   to the local policy.

   For a router capable of BIERv6, such BIERv6 packet MUST NOT be
   forwarded, but should be processed as a normal IPv6 packet with
   unknown option, or additionally and optionally be countered and
   logged if the router is capable of doing so.

Kind regards=C2=A0
Gyan

On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra = <hayabusagsm@= gmail.com> wrote:

Makes sense.

Thanks=C2=A0

Gyan

On Sat, Mar 14, 2020 at 4:12 AM K= arl Auer <kaue= r@biplane.com.au> wrote:
On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote:
> I always wondered why RFC 4862 states that ND & RD packets have TT= L
> 255.

>From RFC4861:

=C2=A0 =C2=A0"By setting the Hop Limit to 255, Neighbor Discovery
=C2=A0 =C2=A0 is immune to off-link senders that accidentally or
=C2=A0 =C2=A0 intentionally send ND messages.=C2=A0=C2=A0In IPv4, off-link<= br> =C2=A0 =C2=A0 senders can send both ICMP Redirects and Router
=C2=A0 =C2=A0 Advertisement messages."

RFC4861 also requires RA and NA packets with any other TTL value to be
silently discarded by any receiving node.

I can't find my original source, but my notes in a training course I developed a while ago have this to say about why:

=C2=A0 =C2=A0"Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Becaus= e routers
=C2=A0 =C2=A0 decrement the hop limit on packets passing through
=C2=A0 =C2=A0 them, and discard packets where the hop count
=C2=A0 =C2=A0 decrements to zero. It is impossible to decrement
=C2=A0 =C2=A0 a one-byte counter to 255 without passing through
=C2=A0 =C2=A0 zero, because 255 is the maximum value such a counter
=C2=A0 =C2=A0 can have. So the value 255 means that the packet must
=C2=A0 =C2=A0 have been generated on the local link."

Probably would be better expressed as "must have originated on the
local link".

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@= biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 2561 E9EC D868 E73C 8AF1=C2=A049CF EE50 4B1D CCA1 5170
Old fingerprint: 8D08 9CAA 649A AFEF E862=C2=A0062A 2E97 42D4 A2A0 616D


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--

Gyan=C2=A0 Mishra

Network Engineering &= Technology=C2=A0

Verizon=C2=A0

Silver Sp= ring, MD 20904

Phone: 301 502-1347

Email:= gyan.s.mish= ra@verizon.com



=
--

Gyan=C2=A0 Mishra

Network Engineering &= Technology=C2=A0

Verizon=C2=A0

Silver Sp= ring, MD 20904

Phone: 301 502-1347

Email:= gyan.s.mish= ra@verizon.com



=
--000000000000ddfee205a153bf94-- From nobody Fri Mar 20 19:59:32 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F078C3A10DB; Fri, 20 Mar 2020 19:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBuF6GIcN7tE; Fri, 20 Mar 2020 19:59:03 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07393A09C1; Fri, 20 Mar 2020 19:59:02 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id m7so3685764ilg.5; Fri, 20 Mar 2020 19:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4ozEQVoiWPLMhTbEs699UWLrs2eA7mDp9D69poe+wqk=; b=OgCQu8t1BLn7iYFMbzPRwjq6/LBInUVlkHZL/q2JSctA5JzVwqrOg5wPZiVV1f3/s1 l/FXEFBeqZ7oPtRrIt0qZcyrWZ7OAvbZOhicA2MtgWTvBMoDoydau9UaEolTBPbHPHK/ fFC+sE/tXFU/7YNRsyDPADlHLUDJicYUGGxAr7WxZ+7Yv4vzJtt3uOPYc62bIFVfGu/S 61PXncV464ryO+ggO849JON2flmUCM86eFFiOh4XkaMv2B/rYOxBPYAe2IbusGE4ROl/ rckjdP95vpP1h6CVHP3DL+pYxxpCTei/AK+q9CLBjeRu+zSJi+B7ZG1+JyW91b6iSzBu l4Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4ozEQVoiWPLMhTbEs699UWLrs2eA7mDp9D69poe+wqk=; b=DqxSiEERRFV9Go2e9pVP/aBZxGkVGHXevcVCF6blkpGn7Sy2r4FyWdyO9wUxOTmzuv 9MlBS+m0b73GbTCEicnQQiOF9uzwDQ63k8KCHLz1YYDMhIsv79lc7we+YgzkydbCPvaX /ygD9v1+F2OLvQjR8gzUMGaHNKGVfR/twEid7kcMPRw5V2H780lzY4lu+VYZssCY6w5u vAZa5CjP2fLTw8/afHVEhm7xFemCX4In80zC1jjHVum0G6jKdiEDzl+Tk/jZfHDNlBsg JOU1x0B7sJb9/hkVj26b7YAxp47+65wWUSOpsjnYRDrYB6vuxh0HBSZ3pC6IlNruv1cS i42Q== X-Gm-Message-State: ANhLgQ3n8o1l3rkixtDpWZ9vKDBynMaUjMZaInDyBKp5aVeMAfj09oyw PxQNlyXBQyJIcV7XhH//rxrnEJCpl4ZbnA4Le8A= X-Google-Smtp-Source: ADFU+vu27J5IBQj+Qfa86dnWWTgwbwwrL8o6sOd33BNFIyt7TOFwhiToaXynqX5XIz/UeVtnY/8CrmkM84LdKP4recY= X-Received: by 2002:a92:96c6:: with SMTP id g189mr11107857ilh.276.1584759541781; Fri, 20 Mar 2020 19:59:01 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <1584173474.2857.102.camel@biplane.com.au> In-Reply-To: From: Gyan Mishra Date: Fri, 20 Mar 2020 22:58:50 -0400 Message-ID: To: Tony Przygienda Cc: 6man <6man@ietf.org>, Toerless Eckert , V6 Ops List , kauer@biplane.com.au Content-Type: multipart/alternative; boundary="0000000000008adc5905a15495eb" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 02:59:08 -0000 --0000000000008adc5905a15495eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 20, 2020 at 9:59 PM Tony Przygienda wrote= : > Yepp, that's personally I prefer on multicast TTL=3D1 (and also on ISIS & > e.g. on expired draft where we were carrying ISIS natively over IP). The > cost of a frame running away unintended multiple-hops in a control protoc= ol > without a tunnel are simply NOT fun. The cost of such a thing (and it > happened MORE than once) outweighs IMO the minor security advantage. > > If you read v6 BIER drafts you should read > https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/ which has been > published much, much earlier ... > > --- tony > > TTL security is a necessity for ND with limited risk of run away ND > packets as it=E2=80=99s minimal bandwidth usage. > With a multicast stream the risk is much greater if forwarded multiple hops past the BFER PE as stated and maybe a high data rate stream so undesirable to ever happen. ND is the only protocol I know of that uses TTL security. I would go with TTL=3D1. If security is a concern in the v6 tunnel, is it possible to add cryptography to BIER or even setting security TLV in the BIER header encoded in the DO on the BFIR and then validate the TLV encoding on the BFER destination endpoint. > On Sat, Mar 14, 2020 at 10:38 AM Gyan Mishra > wrote: > >> >> Toreless & Tony >> >> I read through the draft for BIER over IPv6. >> >> https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06 >> >> So since the BIER header bitmask that denotes the BFERs in the Domain to >> replicate the multicast packets is encoded in the DestOp processed by th= e >> BFER, the packets should not be forwarded past the BFER is my guess is w= ith >> ttl 255. With IPv6 ND with ttl 255 example the packet can be forwarded >> past the adjacent node but I have not seen that happen. I believe Jen >> Linkova on this thread has seen that. Since the BFER dest options has to >> have the BIER bit mask encoding or the packet is dropped I believe is yo= ur >> security protection from forwarding past the BIER with 255 ttl if you >> decided to go that route. >> >> Under BIERv6 packet processing should help if ttl 255 is used to prevent >> forwarding outside of bier domain >> >> A packet having a 'BIER Specific Handling' indication but not having >> a BIER option is supposed to be a wrong packet or an ICMPv6 packet, >> and the process can be refered to the example in section 3.2 . >> >> A packet not having a 'BIER Specific Handling' indication but having >> a BIER option SHOULD be processed normally as unicast forwarding >> procedures, which may be a behavior of drop, or send to CPU, or other >> behaviors in existing implementations. >> >> >> Under 5.3 security considerations should also help with ttl 255 and >> forwarding outside of BIER domain >> >> For a router incapable of BIERv6, such BIERv6 packet will not be >> processed by the procedure described in this document, but be >> processed as normal IPv6 packet with unknown option, and the existing >> security considerations for handling IPv6 options apply. Possible >> way of handling IPv6 packets with BIER option may be send to CPU for >> slow path processing, with rate-limiting, or be discarded according >> to the local policy. >> >> For a router capable of BIERv6, such BIERv6 packet MUST NOT be >> forwarded, but should be processed as a normal IPv6 packet with >> unknown option, or additionally and optionally be countered and >> logged if the router is capable of doing so. >> >> >> Kind regards >> >> Gyan >> >> On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra >> wrote: >> >>> >>> Makes sense. >>> >>> Thanks >>> >>> Gyan >>> >>> On Sat, Mar 14, 2020 at 4:12 AM Karl Auer wrote: >>> >>>> On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote: >>>> > I always wondered why RFC 4862 states that ND & RD packets have TTL >>>> > 255. >>>> >>>> >From RFC4861: >>>> >>>> "By setting the Hop Limit to 255, Neighbor Discovery >>>> is immune to off-link senders that accidentally or >>>> intentionally send ND messages. In IPv4, off-link >>>> senders can send both ICMP Redirects and Router >>>> Advertisement messages." >>>> >>>> RFC4861 also requires RA and NA packets with any other TTL value to be >>>> silently discarded by any receiving node. >>>> >>>> I can't find my original source, but my notes in a training course I >>>> developed a while ago have this to say about why: >>>> >>>> "Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Because routers >>>> decrement the hop limit on packets passing through >>>> them, and discard packets where the hop count >>>> decrements to zero. It is impossible to decrement >>>> a one-byte counter to 255 without passing through >>>> zero, because 255 is the maximum value such a counter >>>> can have. So the value 255 means that the packet must >>>> have been generated on the local link." >>>> >>>> Probably would be better expressed as "must have originated on the >>>> local link". >>>> >>>> Regards, K. >>>> >>>> -- >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~ >>>> Karl Auer (kauer@biplane.com.au) >>>> http://www.biplane.com.au/kauer >>>> http://twitter.com/kauer389 >>>> >>>> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170 >>>> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> -- >>> >>> Gyan Mishra >>> >>> Network Engineering & Technology >>> >>> Verizon >>> >>> Silver Spring, MD 20904 >>> >>> Phone: 301 502-1347 >>> >>> Email: gyan.s.mishra@verizon.com >>> >>> >>> >>> -- >> >> Gyan Mishra >> >> Network Engineering & Technology >> >> Verizon >> >> Silver Spring, MD 20904 >> >> Phone: 301 502-1347 >> >> Email: gyan.s.mishra@verizon.com >> >> >> >> -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --0000000000008adc5905a15495eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 20, 2020 at 9:59 PM Tony Przygienda <tonysietf@gmail.com> wrote:
Yepp, that's pers= onally I prefer on multicast TTL=3D1 (and also on ISIS & e.g. on expire= d draft where we were carrying ISIS natively over IP). The cost of a frame = running away unintended multiple-hops in a control protocol without a tunne= l are simply NOT fun.=C2=A0 The cost of such a thing (and it happened MORE = than once) outweighs IMO the minor security advantage.

<= /div>
If you read v6 BIER drafts you should read https://= datatracker.ietf.org/doc/draft-zhang-bier-bierin6/ which has been publi= shed much, much earlier ...

--- tony

TTL security is a necessity fo= r ND with limited risk of run away ND packets as it=E2=80=99s =C2=A0minimal= bandwidth usage.

=C2=A0 =C2=A0With a multicast stream the risk is much greater = if forwarded multiple hops past the BFER PE as stated and maybe a high data= rate stream so undesirable to ever happen.

=C2=A0ND is the only protocol I know of that uses TTL s= ecurity. =C2=A0

I would = go with TTL=3D1. =C2=A0

= If security is a concern in the v6 tunnel, is it possible to add cryptograp= hy to BIER or even setting security TLV in the BIER header encoded in the D= O on the BFIR and then validate the TLV encoding on the BFER destination en= dpoint.=C2=A0


=

On Sat, Mar 14, 2020 at 10:38 AM Gyan Mishra <<= a href=3D"mailto:hayabusagsm@gmail.com" target=3D"_blank">hayabusagsm@gmail= .com> wrote:

Toreless & Tony=C2=A0

I read through the draft for BI= ER over IPv6.

So since the BIER header bitmask = that denotes the BFERs in the Domain to replicate the multicast packets is = encoded in the DestOp processed by the BFER, the packets should not be forw= arded past the BFER is my guess is with ttl 255.=C2=A0 With IPv6 ND with tt= l 255 example the packet can be forwarded past the adjacent node but I have= not seen that happen.=C2=A0 I believe Jen Linkova on this thread has seen = that. Since the BFER dest options has to have the BIER bit mask encoding or= the packet is dropped I believe is your security protection from forwardin= g past the BIER with 255 ttl if you decided to go that route.

Under BIERv6 packet processing should= help if ttl 255 is used to prevent forwarding outside of bier domain=C2=A0= 

A packet having a =
'BIER Specific Handling' indication but not having
   a BIER option is supposed to be a wrong packet or an ICMPv6 packet,
   and the process can be refered to the example in section 3.2.

   A packet not having a 'BIER Specific Handling' indication but ha=
ving
   a BIER option SHOULD be processed normally as unicast forwarding
   procedures, which may be a behavior of drop, or send to CPU, or other
   behaviors in existing implementations.

=
Under 5.3 security considerations should also help = with ttl 255 and forwarding outside of BIER domain
<= br>
For a router incapable of BIERv6, such BIER=
v6 packet will not be
   processed by the procedure described in this document, but be
   processed as normal IPv6 packet with unknown option, and the existing
   security considerations for handling IPv6 options apply.  Possible
   way of handling IPv6 packets with BIER option may be send to CPU for
   slow path processing, with rate-limiting, or be discarded according
   to the local policy.

   For a router capable of BIERv6, such BIERv6 packet MUST NOT be
   forwarded, but should be processed as a normal IPv6 packet with
   unknown option, or additionally and optionally be countered and
   logged if the router is capable of doing so.

Kind regards=C2=A0
Gyan

On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra = <hayabusagsm@= gmail.com> wrote:

Makes sense.

Thanks=C2=A0

Gyan

On Sat, Mar 14, 2020 at 4:12 AM K= arl Auer <kaue= r@biplane.com.au> wrote:
On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote:
> I always wondered why RFC 4862 states that ND & RD packets have TT= L
> 255.

>From RFC4861:

=C2=A0 =C2=A0"By setting the Hop Limit to 255, Neighbor Discovery
=C2=A0 =C2=A0 is immune to off-link senders that accidentally or
=C2=A0 =C2=A0 intentionally send ND messages.=C2=A0=C2=A0In IPv4, off-link<= br> =C2=A0 =C2=A0 senders can send both ICMP Redirects and Router
=C2=A0 =C2=A0 Advertisement messages."

RFC4861 also requires RA and NA packets with any other TTL value to be
silently discarded by any receiving node.

I can't find my original source, but my notes in a training course I developed a while ago have this to say about why:

=C2=A0 =C2=A0"Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Becaus= e routers
=C2=A0 =C2=A0 decrement the hop limit on packets passing through
=C2=A0 =C2=A0 them, and discard packets where the hop count
=C2=A0 =C2=A0 decrements to zero. It is impossible to decrement
=C2=A0 =C2=A0 a one-byte counter to 255 without passing through
=C2=A0 =C2=A0 zero, because 255 is the maximum value such a counter
=C2=A0 =C2=A0 can have. So the value 255 means that the packet must
=C2=A0 =C2=A0 have been generated on the local link."

Probably would be better expressed as "must have originated on the
local link".

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@= biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 2561 E9EC D868 E73C 8AF1=C2=A049CF EE50 4B1D CCA1 5170
Old fingerprint: 8D08 9CAA 649A AFEF E862=C2=A0062A 2E97 42D4 A2A0 616D


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--

Gyan=C2=A0 Mishra

Network Engineering &= Technology=C2=A0

Verizon=C2=A0

Silver Sp= ring, MD 20904

Phone: 301 502-1347

Email:= gyan.s.mish= ra@verizon.com



=
--

Gyan=C2=A0 Mishra

Network Engineering &= Technology=C2=A0

Verizon=C2=A0

Silver Sp= ring, MD 20904

Phone: 301 502-1347

Email:= gyan.s.mish= ra@verizon.com



=
--
<= div dir=3D"ltr">

Gyan= =C2=A0 Mishra

Network Engineering & Technology= =C2=A0

Verizon=C2=A0

Silver Spring, MD 20= 904

Phone: 301 502-1347

<= font size=3D"1" color=3D"#000000" face=3D"georgia, serif">Email: gyan.s.mishra@verizon.= com



--0000000000008adc5905a15495eb-- From nobody Fri Mar 20 20:22:15 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13C03A1100; Fri, 20 Mar 2020 20:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5krm7Qs6pYM; Fri, 20 Mar 2020 20:22:04 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22BE43A1001; Fri, 20 Mar 2020 20:22:04 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id 22so2629903otf.0; Fri, 20 Mar 2020 20:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q4E8ZQ4ZRCsZBqBnPZqjTVc170jcPI1OCQl/avje3e4=; b=F4p6K172wm7HeT6tD300EO0mrFb7WvjG2US/F0t067jARqVgpaSzTCm32CBuwW6s7u mPedORWusy2/xF9ZgjXGG6kEy5XcHJ4k+tPtFbhP+j8bv8XCgR2vRHQGi0IgARJpEwgE 7/zV9mwVN8gLUbwQ9aMTZnAxayVVovvCA6X5r8KArOo3d4FskdhaW0Yi7XJKuu/OAqGS Cseqw9+fAbIMOYHSsviLMalt/MvBW2WbhhpPmgmDkD+F/7xBVEkqzMo48SNhDE8wJtg9 KkPwu8JG5OAabrXXph97R8WNJI3NGiDN0Hus2vthnKTjDI/+YPnaubqX5+nuTR4Savj3 1JAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q4E8ZQ4ZRCsZBqBnPZqjTVc170jcPI1OCQl/avje3e4=; b=Iq9ULCLtgtrSWzNxAIbguBiNc/3/7fD0tUE3VNUg2nySL8hHudVe99pw8uCc9q6MLK SVHqeyDq88baiCUmrTWBXdnSXDleCp2f4Qb6auENtjNDrXJbV769KKlBk+2sBSL4O407 aldWetjdaKbvv/Eyvgp1CMUAFiEjtTW6KwC0cOWSdBUUeng4WSKq581xxxNRU/xacwD6 584X4WT/DArcTO5Q8vDQ1OKiQq9/Dl8T/Vtvwi0Fh35V9Lv6Lbo+CHuL6rfWd+2X0M1K upeEgjxmtUXSZyRkGMn4N/7CIlWUzVew0j7bS2oZPoyrfn5m7TR3lDwTB+hqtiyCpEK2 IVBA== X-Gm-Message-State: ANhLgQ1eK0iJLhz9EW6YXosO6A4WDf9cysYuKBe/9//x5t8iO8cmYs3b NFJ7cCQRKsasfwWiSy9/e1TX7jfnFWJund0kEFg= X-Google-Smtp-Source: ADFU+vtpPrkqetxWR6x8qR86KJrMhUhcvDQl+XdmalKaESA3ed8AK8zJR548iADQxyXxp2/yo6q9dF6v8xStyxZGEYI= X-Received: by 2002:a05:6830:4035:: with SMTP id i21mr8917755ots.348.1584760923138; Fri, 20 Mar 2020 20:22:03 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <1584173474.2857.102.camel@biplane.com.au> In-Reply-To: From: Mark Smith Date: Sat, 21 Mar 2020 14:21:51 +1100 Message-ID: To: Gyan Mishra Cc: Tony Przygienda , V6 Ops List , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000e0ad8e05a154e718" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 03:22:08 -0000 --000000000000e0ad8e05a154e718 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 21 Mar 2020, 14:00 Gyan Mishra, wrote: > > > On Fri, Mar 20, 2020 at 9:59 PM Tony Przygienda > wrote: > >> Yepp, that's personally I prefer on multicast TTL=3D1 (and also on ISIS = & >> e.g. on expired draft where we were carrying ISIS natively over IP). The >> cost of a frame running away unintended multiple-hops in a control proto= col >> without a tunnel are simply NOT fun. The cost of such a thing (and it >> happened MORE than once) outweighs IMO the minor security advantage. >> >> If you read v6 BIER drafts you should read >> https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/ which has >> been published much, much earlier ... >> >> --- tony >> >> TTL security is a necessity for ND with limited risk of run away ND >> packets as it=E2=80=99s minimal bandwidth usage. >> > > With a multicast stream the risk is much greater if forwarded multiple > hops past the BFER PE as stated and maybe a high data rate stream so > undesirable to ever happen. > > ND is the only protocol I know of that uses TTL security. > > I would go with TTL=3D1. > Can you guarantee a received packet with a Hop Count value of 1 hasn't been forwarded? You can when the received packet has a Hop Count of 255. > If security is a concern in the v6 tunnel, is it possible to add > cryptography to BIER or even setting security TLV in the BIER header > encoded in the DO on the BFIR and then validate the TLV encoding on the > BFER destination endpoint. > > > >> On Sat, Mar 14, 2020 at 10:38 AM Gyan Mishra > > wrote: >> >>> >>> Toreless & Tony >>> >>> I read through the draft for BIER over IPv6. >>> >>> https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06 >>> >>> So since the BIER header bitmask that denotes the BFERs in the Domain t= o >>> replicate the multicast packets is encoded in the DestOp processed by t= he >>> BFER, the packets should not be forwarded past the BFER is my guess is = with >>> ttl 255. With IPv6 ND with ttl 255 example the packet can be forwarded >>> past the adjacent node but I have not seen that happen. I believe Jen >>> Linkova on this thread has seen that. Since the BFER dest options has t= o >>> have the BIER bit mask encoding or the packet is dropped I believe is y= our >>> security protection from forwarding past the BIER with 255 ttl if you >>> decided to go that route. >>> >>> Under BIERv6 packet processing should help if ttl 255 is used to preven= t >>> forwarding outside of bier domain >>> >>> A packet having a 'BIER Specific Handling' indication but not having >>> a BIER option is supposed to be a wrong packet or an ICMPv6 packet, >>> and the process can be refered to the example in section 3.2 . >>> >>> A packet not having a 'BIER Specific Handling' indication but having >>> a BIER option SHOULD be processed normally as unicast forwarding >>> procedures, which may be a behavior of drop, or send to CPU, or othe= r >>> behaviors in existing implementations. >>> >>> >>> Under 5.3 security considerations should also help with ttl 255 and >>> forwarding outside of BIER domain >>> >>> For a router incapable of BIERv6, such BIERv6 packet will not be >>> processed by the procedure described in this document, but be >>> processed as normal IPv6 packet with unknown option, and the existin= g >>> security considerations for handling IPv6 options apply. Possible >>> way of handling IPv6 packets with BIER option may be send to CPU for >>> slow path processing, with rate-limiting, or be discarded according >>> to the local policy. >>> >>> For a router capable of BIERv6, such BIERv6 packet MUST NOT be >>> forwarded, but should be processed as a normal IPv6 packet with >>> unknown option, or additionally and optionally be countered and >>> logged if the router is capable of doing so. >>> >>> >>> Kind regards >>> >>> Gyan >>> >>> On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra >>> wrote: >>> >>>> >>>> Makes sense. >>>> >>>> Thanks >>>> >>>> Gyan >>>> >>>> On Sat, Mar 14, 2020 at 4:12 AM Karl Auer wrote= : >>>> >>>>> On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote: >>>>> > I always wondered why RFC 4862 states that ND & RD packets have TTL >>>>> > 255. >>>>> >>>>> >From RFC4861: >>>>> >>>>> "By setting the Hop Limit to 255, Neighbor Discovery >>>>> is immune to off-link senders that accidentally or >>>>> intentionally send ND messages. In IPv4, off-link >>>>> senders can send both ICMP Redirects and Router >>>>> Advertisement messages." >>>>> >>>>> RFC4861 also requires RA and NA packets with any other TTL value to b= e >>>>> silently discarded by any receiving node. >>>>> >>>>> I can't find my original source, but my notes in a training course I >>>>> developed a while ago have this to say about why: >>>>> >>>>> "Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Because routers >>>>> decrement the hop limit on packets passing through >>>>> them, and discard packets where the hop count >>>>> decrements to zero. It is impossible to decrement >>>>> a one-byte counter to 255 without passing through >>>>> zero, because 255 is the maximum value such a counter >>>>> can have. So the value 255 means that the packet must >>>>> have been generated on the local link." >>>>> >>>>> Probably would be better expressed as "must have originated on the >>>>> local link". >>>>> >>>>> Regards, K. >>>>> >>>>> -- >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~ >>>>> Karl Auer (kauer@biplane.com.au) >>>>> http://www.biplane.com.au/kauer >>>>> http://twitter.com/kauer389 >>>>> >>>>> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170 >>>>> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D >>>>> >>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>> -- >>>> >>>> Gyan Mishra >>>> >>>> Network Engineering & Technology >>>> >>>> Verizon >>>> >>>> Silver Spring, MD 20904 >>>> >>>> Phone: 301 502-1347 >>>> >>>> Email: gyan.s.mishra@verizon.com >>>> >>>> >>>> >>>> -- >>> >>> Gyan Mishra >>> >>> Network Engineering & Technology >>> >>> Verizon >>> >>> Silver Spring, MD 20904 >>> >>> Phone: 301 502-1347 >>> >>> Email: gyan.s.mishra@verizon.com >>> >>> >>> >>> -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: gyan.s.mishra@verizon.com > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000e0ad8e05a154e718 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, 21 Mar 2020, 14:00 Gyan Mishra, <hayabus= agsm@gmail.com> wrote:
=

On Fri, Mar 20, 2020 at 9:59 PM Tony Przygienda <to= nysietf@gmail.com> wrote:
Yepp, that's personally I prefer on multicast TTL= =3D1 (and also on ISIS & e.g. on expired draft where we were carrying I= SIS natively over IP). The cost of a frame running away unintended multiple= -hops in a control protocol without a tunnel are simply NOT fun.=C2=A0 The = cost of such a thing (and it happened MORE than once) outweighs IMO the min= or security advantage.

If you read v6 BIER dr= afts you should read https://da= tatracker.ietf.org/doc/draft-zhang-bier-bierin6/ which has been publish= ed much, much earlier ...

<= div>--- tony

TTL security is a necessity for = ND with limited risk of run away ND packets as it=E2=80=99s =C2=A0minimal b= andwidth usage.

=C2=A0 =C2=A0With a multicast stream the risk is much greater if= forwarded multiple hops past the BFER PE as stated and maybe a high data r= ate stream so undesirable to ever happen.

=
=C2=A0ND is the only protocol I know of that uses TTL sec= urity. =C2=A0

I would go= with TTL=3D1. =C2=A0

Can you guarantee a received packet with= a Hop Count value of 1 hasn't been forwarded?
<= br>
You can when the received packet has a Hop Count= of 255.

=

If security is a concern in t= he v6 tunnel, is it possible to add cryptography to BIER or even setting se= curity TLV in the BIER header encoded in the DO on the BFIR and then valida= te the TLV encoding on the BFER destination endpoint.=C2=A0



On= Sat, Mar 14, 2020 at 10:38 AM Gyan Mishra <hayabusagsm@gm= ail..com> wrote:

Toreless & Tony=C2=A0

I read through the draft fo= r BIER over IPv6.

<= a href=3D"https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06"= rel=3D"noreferrer noreferrer" target=3D"_blank">https://tools.ietf.org/htm= l/draft-xie-bier-ipv6-encapsulation-06

So since the BIER header bitmask that denotes the BFERs in the Domain to r= eplicate the multicast packets is encoded in the DestOp processed by the BF= ER, the packets should not be forwarded past the BFER is my guess is with t= tl 255.=C2=A0 With IPv6 ND with ttl 255 example the packet can be forwarded= past the adjacent node but I have not seen that happen.=C2=A0 I believe Je= n Linkova on this thread has seen that. Since the BFER dest options has to = have the BIER bit mask encoding or the packet is dropped I believe is your = security protection from forwarding past the BIER with 255 ttl if you decid= ed to go that route.

Und= er BIERv6 packet processing should help if ttl 255 is used to prevent forwa= rding outside of bier domain=C2=A0

A packet having a 'BIER Specific Handling' indicati=
on but not having
   a BIER option is supposed to be a wrong packet or an ICMPv6 packet,
   and the process can be refered to the example in section 3.2.

   A packet not having a 'BIER Specific Handling' indication but ha=
ving
   a BIER option SHOULD be processed normally as unicast forwarding
   procedures, which may be a behavior of drop, or send to CPU, or other
   behaviors in existing implementations.

=
Under 5.3 security considerations should also help = with ttl 255 and forwarding outside of BIER domain
<= br>
For a router incapable of BIERv6, such BIER=
v6 packet will not be
   processed by the procedure described in this document, but be
   processed as normal IPv6 packet with unknown option, and the existing
   security considerations for handling IPv6 options apply.  Possible
   way of handling IPv6 packets with BIER option may be send to CPU for
   slow path processing, with rate-limiting, or be discarded according
   to the local policy.

   For a router capable of BIERv6, such BIERv6 packet MUST NOT be
   forwarded, but should be processed as a normal IPv6 packet with
   unknown option, or additionally and optionally be countered and
   logged if the router is capable of doing so.

Kind regards=C2=A0
Gyan

On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra = <hayabusagsm@gmail.com> wrote:

Makes sense.

Thanks=C2= =A0

Gyan
On Sa= t, Mar 14, 2020 at 4:12 AM Karl Auer <kauer@biplane.com.au<= /a>> wrote:
O= n Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote:
> I always wondered why RFC 4862 states that ND & RD packets have TT= L
> 255.

>From RFC4861:

=C2=A0 =C2=A0"By setting the Hop Limit to 255, Neighbor Discovery
=C2=A0 =C2=A0 is immune to off-link senders that accidentally or
=C2=A0 =C2=A0 intentionally send ND messages.=C2=A0=C2=A0In IPv4, off-link<= br> =C2=A0 =C2=A0 senders can send both ICMP Redirects and Router
=C2=A0 =C2=A0 Advertisement messages."

RFC4861 also requires RA and NA packets with any other TTL value to be
silently discarded by any receiving node.

I can't find my original source, but my notes in a training course I developed a while ago have this to say about why:

=C2=A0 =C2=A0"Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Becaus= e routers
=C2=A0 =C2=A0 decrement the hop limit on packets passing through
=C2=A0 =C2=A0 them, and discard packets where the hop count
=C2=A0 =C2=A0 decrements to zero. It is impossible to decrement
=C2=A0 =C2=A0 a one-byte counter to 255 without passing through
=C2=A0 =C2=A0 zero, because 255 is the maximum value such a counter
=C2=A0 =C2=A0 can have. So the value 255 means that the packet must
=C2=A0 =C2=A0 have been generated on the local link."

Probably would be better expressed as "must have originated on the
local link".

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 2561 E9EC D868 E73C 8AF1=C2=A049CF EE50 4B1D CCA1 5170
Old fingerprint: 8D08 9CAA 649A AFEF E862=C2=A0062A 2E97 42D4 A2A0 616D


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listin= fo/v6ops
--

Gyan=C2=A0 Mishra

Network Engineering &= Technology=C2=A0

Verizon=C2=A0

Silver Sp= ring, MD 20904

Phone: 301 502-1347

Email:= gyan.s.mishra@verizon.com



--

Gyan=C2=A0 Mishra

Network Engineering &= Technology=C2=A0

Verizon=C2=A0

Silver Sp= ring, MD 20904

Phone: 301 502-1347

Email:= gyan.s.mishra@verizon.com



--

Gyan=C2=A0 Mishra

Network Engineering & Technology=C2=A0

V= erizon=C2=A0

Silver Spring, MD 20904

Phon= e: 301 502-1347

Email: gyan.s.mishra@ver= izon.com



=
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www= .ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--000000000000e0ad8e05a154e718-- From nobody Mon Mar 23 22:48:09 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A783A0EE9; Mon, 23 Mar 2020 22:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6G6ASJD7x3s; Mon, 23 Mar 2020 22:47:55 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B7B3A0799; Mon, 23 Mar 2020 22:47:29 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id m14so959647oic.0; Mon, 23 Mar 2020 22:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ajQavUoaNeuied3lBwVPMc54hF5Ge0+oKnlhKMlGXbo=; b=dnNG65v82IuOqyaVA9xyuJsDGDQsGoVFOOTY255dd8/1ynkTmjgeEyOOM2UOsCdDyt Msks40jUtVnVT05f/zE6yp7QmQDpMdKkz82ENNsDZ/njfuanEJUM5lW6Gu7UHmKX9Np3 4KxObM08H41NQNEQ+KpO6UhV5k2MnY2i7Qn/LhbcImYL9EZSSf9CPaU0raniYpfjryzd 0TkXlK9ZYH99tBeiUrJcfqH9CvZsxGjzZ+GcN4EYWhKLyATc96KNdpOX7AKAUv+8VwtY V1/skSYYB2EnDXd99DAkLPIZOWd/qqOf75CCxIfDzh+tSt1SZzQ9G4eVFH+aIclHrv4c sGLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ajQavUoaNeuied3lBwVPMc54hF5Ge0+oKnlhKMlGXbo=; b=E5nWCYupROo72/4htTDL11haXCmDIZuO83c0U6r9vn8TwOgq2im7ZmwJLVr2KUwd1l awMdFmSH+U8D5NAgMLsce+N4wxH9xq64sJ/bz+wu6ie08Nb+wMADMBwK25t47FCOUS/q zWfmF5hiqYkOvaDS0pFpxN6Vmt5V54V9UW0SvLntnhYQAJnhgZfgRHcRR7CNvV59FYGU JPgmwkd4REu0bGp/IEnN0SBWSZx5vDwz0eNutYr9yZ8owtGIsVnFK9w6Wyg/4s6P9CAv RqBcz8eABM90i2XxMLoXp1EH2L7G+neE4LO5nA5W6U9ak/DsBVgmxqU7oVI3e0oD4vWT kH8A== X-Gm-Message-State: ANhLgQ3/f3gDm9JncNlVGUlYPgCL0mAZ34Ee0vbZ2gHQimgD9+smGsk5 I/789KhFMzbNRrtjhzQzCd5Fi3CGha+DXzXyB28= X-Google-Smtp-Source: ADFU+vtiuawlIKoEbu5pfJftPvPODQvrLlzQ0+cgVNzP7lGFP/VB0Jz3u28bjDurmHy9Sa+tkRw6TcJUsVXBgFwEazk= X-Received: by 2002:aca:5194:: with SMTP id f142mr2316989oib.100.1585028837691; Mon, 23 Mar 2020 22:47:17 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <1584173474.2857.102.camel@biplane.com.au> In-Reply-To: From: Erik Kline Date: Mon, 23 Mar 2020 22:47:06 -0700 Message-ID: To: Gyan Mishra Cc: Tony Przygienda , V6 Ops List , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000d455d505a1934815" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 05:48:08 -0000 --000000000000d455d505a1934815 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 20, 2020 at 7:59 PM Gyan Mishra wrote: > > > On Fri, Mar 20, 2020 at 9:59 PM Tony Przygienda > wrote: > >> Yepp, that's personally I prefer on multicast TTL=3D1 (and also on ISIS = & >> e.g. on expired draft where we were carrying ISIS natively over IP). The >> cost of a frame running away unintended multiple-hops in a control proto= col >> without a tunnel are simply NOT fun. The cost of such a thing (and it >> happened MORE than once) outweighs IMO the minor security advantage. >> >> If you read v6 BIER drafts you should read >> https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/ which has >> been published much, much earlier ... >> >> --- tony >> >> TTL security is a necessity for ND with limited risk of run away ND >> packets as it=E2=80=99s minimal bandwidth usage. >> > > With a multicast stream the risk is much greater if forwarded multiple > hops past the BFER PE as stated and maybe a high data rate stream so > undesirable to ever happen. > > ND is the only protocol I know of that uses TTL security. > > I would go with TTL=3D1. > Certainly RFC 4861 message validation sections say the message has to have a hop limit of 255, so it should go without saying that the spec should be followed where such text exists. Also BGP and other routing protocols can use hop limit security. GTSM ( https://tools.ietf.org/html/rfc5082). Specifically: https://tools.ietf.org/html/rfc5082#section-5.1 If security is a concern in the v6 tunnel, is it possible to add > cryptography to BIER or even setting security TLV in the BIER header > encoded in the DO on the BFIR and then validate the TLV encoding on the > BFER destination endpoint. > > > >> On Sat, Mar 14, 2020 at 10:38 AM Gyan Mishra > > wrote: >> >>> >>> Toreless & Tony >>> >>> I read through the draft for BIER over IPv6. >>> >>> https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06 >>> >>> So since the BIER header bitmask that denotes the BFERs in the Domain t= o >>> replicate the multicast packets is encoded in the DestOp processed by t= he >>> BFER, the packets should not be forwarded past the BFER is my guess is = with >>> ttl 255. With IPv6 ND with ttl 255 example the packet can be forwarded >>> past the adjacent node but I have not seen that happen. I believe Jen >>> Linkova on this thread has seen that. Since the BFER dest options has t= o >>> have the BIER bit mask encoding or the packet is dropped I believe is y= our >>> security protection from forwarding past the BIER with 255 ttl if you >>> decided to go that route. >>> >>> Under BIERv6 packet processing should help if ttl 255 is used to preven= t >>> forwarding outside of bier domain >>> >>> A packet having a 'BIER Specific Handling' indication but not having >>> a BIER option is supposed to be a wrong packet or an ICMPv6 packet, >>> and the process can be refered to the example in section 3.2 . >>> >>> A packet not having a 'BIER Specific Handling' indication but having >>> a BIER option SHOULD be processed normally as unicast forwarding >>> procedures, which may be a behavior of drop, or send to CPU, or othe= r >>> behaviors in existing implementations. >>> >>> >>> Under 5.3 security considerations should also help with ttl 255 and >>> forwarding outside of BIER domain >>> >>> For a router incapable of BIERv6, such BIERv6 packet will not be >>> processed by the procedure described in this document, but be >>> processed as normal IPv6 packet with unknown option, and the existin= g >>> security considerations for handling IPv6 options apply. Possible >>> way of handling IPv6 packets with BIER option may be send to CPU for >>> slow path processing, with rate-limiting, or be discarded according >>> to the local policy. >>> >>> For a router capable of BIERv6, such BIERv6 packet MUST NOT be >>> forwarded, but should be processed as a normal IPv6 packet with >>> unknown option, or additionally and optionally be countered and >>> logged if the router is capable of doing so. >>> >>> >>> Kind regards >>> >>> Gyan >>> >>> On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra >>> wrote: >>> >>>> >>>> Makes sense. >>>> >>>> Thanks >>>> >>>> Gyan >>>> >>>> On Sat, Mar 14, 2020 at 4:12 AM Karl Auer wrote= : >>>> >>>>> On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote: >>>>> > I always wondered why RFC 4862 states that ND & RD packets have TTL >>>>> > 255. >>>>> >>>>> >From RFC4861: >>>>> >>>>> "By setting the Hop Limit to 255, Neighbor Discovery >>>>> is immune to off-link senders that accidentally or >>>>> intentionally send ND messages. In IPv4, off-link >>>>> senders can send both ICMP Redirects and Router >>>>> Advertisement messages." >>>>> >>>>> RFC4861 also requires RA and NA packets with any other TTL value to b= e >>>>> silently discarded by any receiving node. >>>>> >>>>> I can't find my original source, but my notes in a training course I >>>>> developed a while ago have this to say about why: >>>>> >>>>> "Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Because routers >>>>> decrement the hop limit on packets passing through >>>>> them, and discard packets where the hop count >>>>> decrements to zero. It is impossible to decrement >>>>> a one-byte counter to 255 without passing through >>>>> zero, because 255 is the maximum value such a counter >>>>> can have. So the value 255 means that the packet must >>>>> have been generated on the local link." >>>>> >>>>> Probably would be better expressed as "must have originated on the >>>>> local link". >>>>> >>>>> Regards, K. >>>>> >>>>> -- >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~ >>>>> Karl Auer (kauer@biplane.com.au) >>>>> http://www.biplane.com.au/kauer >>>>> http://twitter.com/kauer389 >>>>> >>>>> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170 >>>>> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D >>>>> >>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>> -- >>>> >>>> Gyan Mishra >>>> >>>> Network Engineering & Technology >>>> >>>> Verizon >>>> >>>> Silver Spring, MD 20904 >>>> >>>> Phone: 301 502-1347 >>>> >>>> Email: gyan.s.mishra@verizon.com >>>> >>>> >>>> >>>> -- >>> >>> Gyan Mishra >>> >>> Network Engineering & Technology >>> >>> Verizon >>> >>> Silver Spring, MD 20904 >>> >>> Phone: 301 502-1347 >>> >>> Email: gyan.s.mishra@verizon.com >>> >>> >>> >>> -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: gyan.s.mishra@verizon.com > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000d455d505a1934815 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Fri, Mar 20, 2020= at 7:59 PM Gyan Mishra <hayabu= sagsm@gmail.com> wrote:


On Fri, Mar 20, 2020 at 9:59 PM Tony Przygien= da <tonysietf@g= mail.com> wrote:
Yepp, that's personally I prefer on multi= cast TTL=3D1 (and also on ISIS & e.g. on expired draft where we were ca= rrying ISIS natively over IP). The cost of a frame running away unintended = multiple-hops in a control protocol without a tunnel are simply NOT fun.=C2= =A0 The cost of such a thing (and it happened MORE than once) outweighs IMO= the minor security advantage.

If you read v6= BIER drafts you should read https://datatracker.ietf.org/doc= /draft-zhang-bier-bierin6/ which has been published much, much earlier = ...

--- tony

TTL security is a necessity for ND with limited risk o= f run away ND packets as it=E2=80=99s =C2=A0minimal bandwidth usage.
<= /div>

=C2=A0 =C2= =A0With a multicast stream the risk is much greater if forwarded multiple h= ops past the BFER PE as stated and maybe a high data rate stream so undesir= able to ever happen.

=C2= =A0ND is the only protocol I know of that uses TTL security. =C2=A0

I would go with TTL=3D1.
<= /div>

Certainly RFC 4861 message= validation sections say the message has to have a hop limit of 255, so it = should go without saying that the spec should be followed where such text e= xists.

Also BGP and other rou= ting protocols can use hop limit security.=C2=A0 GTSM (https://tools.ietf.org/html/rfc5082).=C2=A0= Specifically:=C2=A0https://tools.ietf.org/html/rfc5082#section-5.1

If security is a concern in the v6 tunnel, is it= possible to add cryptography to BIER or even setting security TLV in the B= IER header encoded in the DO on the BFIR and then validate the TLV encoding= on the BFER destination endpoint.=C2=A0

<= div dir=3D"auto">
On S= at, Mar 14, 2020 at 10:38 AM Gyan Mishra <hayabusagsm@gmail..com> wrote:

Toreless & Tony=C2=A0

I read through the draft for BIER over IPv6.

So since the BIER header bitmask that denotes the BFERs in t= he Domain to replicate the multicast packets is encoded in the DestOp proce= ssed by the BFER, the packets should not be forwarded past the BFER is my g= uess is with ttl 255.=C2=A0 With IPv6 ND with ttl 255 example the packet ca= n be forwarded past the adjacent node but I have not seen that happen.=C2= =A0 I believe Jen Linkova on this thread has seen that. Since the BFER dest= options has to have the BIER bit mask encoding or the packet is dropped I = believe is your security protection from forwarding past the BIER with 255 = ttl if you decided to go that route.

Under BIERv6 packet processing should help if ttl 255 is used = to prevent forwarding outside of bier domain=C2=A0
<= br>
A packet having a 'BIER Specific Handli=
ng' indication but not having
   a BIER option is supposed to be a wrong packet or an ICMPv6 packet,
   and the process can be refered to the example in section 3.2.

   A packet not having a 'BIER Specific Handling' indication but ha=
ving
   a BIER option SHOULD be processed normally as unicast forwarding
   procedures, which may be a behavior of drop, or send to CPU, or other
   behaviors in existing implementations.

=
Under 5.3 security considerations should also help = with ttl 255 and forwarding outside of BIER domain
<= br>
For a router incapable of BIERv6, such BIER=
v6 packet will not be
   processed by the procedure described in this document, but be
   processed as normal IPv6 packet with unknown option, and the existing
   security considerations for handling IPv6 options apply.  Possible
   way of handling IPv6 packets with BIER option may be send to CPU for
   slow path processing, with rate-limiting, or be discarded according
   to the local policy.

   For a router capable of BIERv6, such BIERv6 packet MUST NOT be
   forwarded, but should be processed as a normal IPv6 packet with
   unknown option, or additionally and optionally be countered and
   logged if the router is capable of doing so.

Kind regards=C2=A0
Gyan

On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra = <hayabusagsm@= gmail.com> wrote:

Makes sense.

Thanks=C2=A0

Gyan

On Sat, Mar 14, 2020 at 4:12 AM K= arl Auer <kaue= r@biplane.com.au> wrote:
On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote:
> I always wondered why RFC 4862 states that ND & RD packets have TT= L
> 255.

>From RFC4861:

=C2=A0 =C2=A0"By setting the Hop Limit to 255, Neighbor Discovery
=C2=A0 =C2=A0 is immune to off-link senders that accidentally or
=C2=A0 =C2=A0 intentionally send ND messages.=C2=A0=C2=A0In IPv4, off-link<= br> =C2=A0 =C2=A0 senders can send both ICMP Redirects and Router
=C2=A0 =C2=A0 Advertisement messages."

RFC4861 also requires RA and NA packets with any other TTL value to be
silently discarded by any receiving node.

I can't find my original source, but my notes in a training course I developed a while ago have this to say about why:

=C2=A0 =C2=A0"Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Becaus= e routers
=C2=A0 =C2=A0 decrement the hop limit on packets passing through
=C2=A0 =C2=A0 them, and discard packets where the hop count
=C2=A0 =C2=A0 decrements to zero. It is impossible to decrement
=C2=A0 =C2=A0 a one-byte counter to 255 without passing through
=C2=A0 =C2=A0 zero, because 255 is the maximum value such a counter
=C2=A0 =C2=A0 can have. So the value 255 means that the packet must
=C2=A0 =C2=A0 have been generated on the local link."

Probably would be better expressed as "must have originated on the
local link".

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@= biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 2561 E9EC D868 E73C 8AF1=C2=A049CF EE50 4B1D CCA1 5170
Old fingerprint: 8D08 9CAA 649A AFEF E862=C2=A0062A 2E97 42D4 A2A0 616D


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--

Gyan=C2=A0 Mishra

Network Engineering &= Technology=C2=A0

Verizon=C2=A0

Silver Sp= ring, MD 20904

Phone: 301 502-1347

Email:= gyan.s.mish= ra@verizon.com



=
--

Gyan=C2=A0 Mishra

Network Engineering &= Technology=C2=A0

Verizon=C2=A0

Silver Sp= ring, MD 20904

Phone: 301 502-1347

Email:= gyan.s.mish= ra@verizon.com



=
--

Gyan=C2=A0 Mishra

Network Engineering &= Technology=C2=A0

Verizon=C2=A0

Silver = Spring, MD 20904

Phone: 301 502-1347

Emai= l: gyan.s.mi= shra@verizon.com


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--000000000000d455d505a1934815-- From nobody Tue Mar 24 15:51:20 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C673A0768; Tue, 24 Mar 2020 15:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Yh-nlwBg2bD; Tue, 24 Mar 2020 15:51:11 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2720D3A0764; Tue, 24 Mar 2020 15:51:09 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02OMp5Nb660386 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Mar 2020 15:51:05 -0700 From: Owen DeLong Message-Id: <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C9C6F806-CD0E-4B7B-9630-8C2F59F5C508" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Mar 2020 15:51:05 -0700 In-Reply-To: Cc: Gyan Mishra , V6 Ops List , 6man <6man@ietf.org>, Tony Przygienda To: Erik Kline References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <1584173474.2857.102.camel@biplane.com.au> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Tue, 24 Mar 2020 15:51:05 -0700 (PDT) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 22:51:13 -0000 --Apple-Mail=_C9C6F806-CD0E-4B7B-9630-8C2F59F5C508 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > TTL security is a necessity for ND with limited risk of run away ND = packets as it=E2=80=99s minimal bandwidth usage. >=20 > With a multicast stream the risk is much greater if forwarded = multiple hops past the BFER PE as stated and maybe a high data rate = stream so undesirable to ever happen. >=20 > ND is the only protocol I know of that uses TTL security. =20 >=20 > I would go with TTL=3D1. If you think this through, it depends on which problem you are trying to = solve. If you are looking to make sure that your packet won=E2=80=99t get = accidentally forwarded by a non-malicious router, then a hop limit of 1 = works best. If you are looking to make absolutely certain that the packet didn=E2=80=99= t come from a non-local source, then a hop limit of 255 is the only = choice. If you use a hop limit of 1, then a remote attacker only needs to craft = a packet with the correct initial hop limit to ensure that it arrives on your link what the appropriate remaining hop limit of 1. OTOH, if you require a hop limit of 255 on the receive side (thus = requiring that the sender use a hop limit of 255), there=E2=80=99s no = way to get a crafted packet through a (non-malicious) router and still have the = packet retain a hop limit of 255. Owen --Apple-Mail=_C9C6F806-CD0E-4B7B-9630-8C2F59F5C508 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

TTL security is a necessity for ND with limited risk of run = away ND packets as it=E2=80=99s  minimal bandwidth = usage.

   With a = multicast stream the risk is much greater if forwarded multiple hops = past the BFER PE as stated and maybe a high data rate stream so = undesirable to ever happen.

 ND is the only = protocol I know of that uses TTL security.  

I would go = with = TTL=3D1.

If you think this through, it depends on which = problem you are trying to solve.

If = you are looking to make sure that your packet won=E2=80=99t get = accidentally forwarded by a non-malicious router, then a hop limit of 1 = works best.
If you are looking to make absolutely certain that = the packet didn=E2=80=99t come from a non-local source, then a hop limit = of 255 is the only choice.

If you = use a hop limit of 1, then a remote attacker only needs to craft a = packet with the correct initial hop limit to ensure that it arrives = on
your link what the appropriate remaining hop limit of = 1.

OTOH, if you require a hop limit = of 255 on the receive side (thus requiring that the sender use a hop = limit of 255), there=E2=80=99s no way to get
a crafted packet = through a (non-malicious) router and still have the packet retain a hop = limit of 255.

Owen


= --Apple-Mail=_C9C6F806-CD0E-4B7B-9630-8C2F59F5C508-- From nobody Tue Mar 24 19:04:06 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9479D3A07A2; Tue, 24 Mar 2020 19:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lT-0DZYywxw; Tue, 24 Mar 2020 19:03:51 -0700 (PDT) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C853A078F; Tue, 24 Mar 2020 19:03:51 -0700 (PDT) Received: by mail-pf1-x441.google.com with SMTP id j1so282655pfe.0; Tue, 24 Mar 2020 19:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=L3VkyCuTcjbFBH+4fT56le48S44v/bxeVdXt5Glv+P8=; b=qBwekb1D9DobxU5nUymyFvbbNcHvXF5wvcW1Kg9xVPE7l3jTwej9tKU1QH7ZlIRqDd hgi8mkCpFtl0uiK9MOz4dfjMD178+G4kZOeqzy3axrVPTpzaf9iY8XuC0LKv+8BIM0Bl QE51/WmYrm3umqCJeZt2r8+d6VEqv1fyPAPr15ie/iYeHY2iFL//ybB8oKzwESb7If98 ZUvb3fVwiFZK9L0AAbjEC8Xe5FezwDHtXSdZdIQLRPLBtOqUugmpiSt93gZimU331kqG j1bEQ5sbuXwu1y4txZSaiw0HrXoxCPfPPZtTmDFW5+lT8bIR3KrnLNu/RYyz8mOyiuO5 5Kww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=L3VkyCuTcjbFBH+4fT56le48S44v/bxeVdXt5Glv+P8=; b=YwNwYAPnwBuq5QZQmZcHW+pyS09VzdbUIWhh/cQj5l+jXB8dP4KGNv3GOeuaINmVXL AsM/B8nhw3GOSVkV66XrNhj9R7Zho02YNvfSfCRfDwZSu1l/qfzmhF7qr60zLvTuaYN/ grtnzGbKUG0hnfzLBn2BMuxFmprUSOdEJxWMWZI4ur0vt87PpBv6+a0Ywp+8a86R4cue KOgi/r2OAQnRW+5yp3fkgLrjCCrwVj2IKIHTUgPQgtbVWXbQNM6zDRw20Hy5xviZWGpq xj1smfG8L2P+N+RrUSC1ZJ2ERFFfIhuaG6nA/anAwDrewU3ln1987C4F0fYfShnrixmJ bDgg== X-Gm-Message-State: ANhLgQ0XVxaXE0xY4emdQSmNAuyDGJdBJu/xNBz3+7gKXrYaPFnWWJk5 D0Tfovkm4DQ9PoSCbSRLjctPJEIL X-Google-Smtp-Source: ADFU+vsv2ADuFgGrenR/iicctd5m1CNIdP4ZUgwgAh/s7QP2m69LzcxuhkfLN0MyJN6a0zIb+wkb1A== X-Received: by 2002:a65:6447:: with SMTP id s7mr714204pgv.163.1585101830809; Tue, 24 Mar 2020 19:03:50 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id i11sm3334868pje.30.2020.03.24.19.03.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2020 19:03:49 -0700 (PDT) To: Owen DeLong , Erik Kline Cc: V6 Ops List , 6man <6man@ietf.org> References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <1584173474.2857.102.camel@biplane.com.au> <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> From: Brian E Carpenter Message-ID: Date: Wed, 25 Mar 2020 15:03:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 02:03:54 -0000 Owen, On 25-Mar-20 11:51, Owen DeLong wrote: >> >> TTL security is a necessity for ND with limited risk of run aw= ay ND packets as it=E2=80=99s =C2=A0minimal bandwidth usage. >> >> >> =C2=A0 =C2=A0With a multicast stream the risk is much greater if f= orwarded multiple hops past the BFER PE as stated and maybe a high data r= ate stream so undesirable to ever happen. >> >> =C2=A0ND is the only protocol I know of that uses TTL security. =C2= =A0 >> >> I would go with TTL=3D1. >=20 > If you think this through, it depends on which problem you are trying t= o solve. >=20 > If you are looking to make sure that your packet won=E2=80=99t get acci= dentally forwarded by a non-malicious router, then a hop limit of 1 works= best. > If you are looking to make absolutely certain that the packet didn=E2=80= =99t come from a non-local source, then a hop limit of 255 is the only ch= oice. >=20 > If you use a hop limit of 1, then a remote attacker only needs to craft= a packet with the correct initial hop limit to ensure that it arrives on= > your link what the appropriate remaining hop limit of 1. Only if the router violates the spec: " Routers must not forward any packets with Link-Local source or destination addresses to other links." [RFC4291] Do we have any evidence of routers that are broken in this way? Brian =20 > OTOH, if you require a hop limit of 255 on the receive side (thus requi= ring that the sender use a hop limit of 255), there=E2=80=99s no way to g= et > a crafted packet through a (non-malicious) router and still have the pa= cket retain a hop limit of 255. >=20 > Owen >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Mar 24 19:20:32 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6793A086F; Tue, 24 Mar 2020 19:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyX8k_UCHKJj; Tue, 24 Mar 2020 19:20:07 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC923A0755; Tue, 24 Mar 2020 19:20:05 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02P2K3s6724010 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Mar 2020 19:20:03 -0700 From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7C00DED7-18DF-4CB8-9FA6-8C6848C52082" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Mar 2020 19:20:02 -0700 In-Reply-To: Cc: Erik Kline , V6 Ops List , 6man <6man@ietf.org> To: Brian E Carpenter References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <1584173474.2857.102.camel@biplane.com.au> <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Tue, 24 Mar 2020 19:20:03 -0700 (PDT) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 02:20:10 -0000 --Apple-Mail=_7C00DED7-18DF-4CB8-9FA6-8C6848C52082 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 24, 2020, at 19:03 , Brian E Carpenter = wrote: >=20 > Owen, >=20 > On 25-Mar-20 11:51, Owen DeLong wrote: >>>=20 >>> TTL security is a necessity for ND with limited risk of run = away ND packets as it=E2=80=99s minimal bandwidth usage. >>>=20 >>>=20 >>> With a multicast stream the risk is much greater if forwarded = multiple hops past the BFER PE as stated and maybe a high data rate = stream so undesirable to ever happen. >>>=20 >>> ND is the only protocol I know of that uses TTL security. =20 >>>=20 >>> I would go with TTL=3D1. >>=20 >> If you think this through, it depends on which problem you are trying = to solve. >>=20 >> If you are looking to make sure that your packet won=E2=80=99t get = accidentally forwarded by a non-malicious router, then a hop limit of 1 = works best. >> If you are looking to make absolutely certain that the packet = didn=E2=80=99t come from a non-local source, then a hop limit of 255 is = the only choice. >>=20 >> If you use a hop limit of 1, then a remote attacker only needs to = craft a packet with the correct initial hop limit to ensure that it = arrives on >> your link what the appropriate remaining hop limit of 1. >=20 > Only if the router violates the spec: > " Routers must not forward any packets with Link-Local source or > destination addresses to other links." [RFC4291] > Do we have any evidence of routers that are broken in this way? Point is I don=E2=80=99t see how a TTL of 1 is better regardless of = this=E2=80=A6 A TTL of 255 guarantees that the packet doesn=E2=80=99t = get through, even if it doesn=E2=80=99t have LL Source or destination. (Imagine a poorly crafted host that = doesn=E2=80=99t check NA or RA packets to ensure LL addresses in = header?). Don=E2=80=99t really want the data from those packets in the neighbor = table, do you? Owen --Apple-Mail=_7C00DED7-18DF-4CB8-9FA6-8C6848C52082 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 24, 2020, at 19:03 , Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Owen,

On 25-Mar-20 11:51, Owen DeLong = wrote:

       TTL security is a = necessity for ND with limited risk of run away ND packets as it=E2=80=99s =  minimal bandwidth usage.


      With a multicast stream the = risk is much greater if forwarded multiple hops past the BFER PE as = stated and maybe a high data rate stream so undesirable to ever = happen.

    ND is the = only protocol I know of that uses TTL security.  

   I would go with TTL=3D1.

If you think this through, it = depends on which problem you are trying to solve.

If you are looking to make sure that your packet won=E2=80=99t = get accidentally forwarded by a non-malicious router, then a hop limit = of 1 works best.
If you are looking to make absolutely = certain that the packet didn=E2=80=99t come from a non-local source, = then a hop limit of 255 is the only choice.

If you use a hop limit of 1, then a remote attacker only = needs to craft a packet with the correct initial hop limit to ensure = that it arrives on
your link what the appropriate = remaining hop limit of 1.

Only if the router violates the = spec:
" =  Routers must not forward any packets with Link-Local source = or
  destination addresses to other links." = [RFC4291]
Do we have = any evidence of routers that are broken in this way?

Point is I = don=E2=80=99t see how a TTL of 1 is better regardless of this=E2=80=A6 A = TTL of 255 guarantees that the packet doesn=E2=80=99t get through, even = if it doesn=E2=80=99t
have LL Source or destination. = (Imagine a poorly crafted host that doesn=E2=80=99t check NA or RA = packets to ensure LL addresses in header?).

Don=E2=80=99t really want the data from = those packets in the neighbor table, do you?

Owen

= --Apple-Mail=_7C00DED7-18DF-4CB8-9FA6-8C6848C52082-- From nobody Tue Mar 24 23:49:10 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1259C3A0989 for ; Tue, 24 Mar 2020 23:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKSr7jQECf9V for ; Tue, 24 Mar 2020 23:48:59 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25CF3A0875 for ; Tue, 24 Mar 2020 23:48:58 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id AA73241CBC for ; Wed, 25 Mar 2020 07:48:55 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 62B9E410AC; Wed, 25 Mar 2020 07:48:55 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 418F02BD65; Wed, 25 Mar 2020 07:48:55 +0100 (CET) Date: Wed, 25 Mar 2020 07:48:55 +0100 From: Gert Doering To: Brian E Carpenter Cc: Owen DeLong , Erik Kline , V6 Ops List , 6man <6man@ietf.org> Message-ID: <20200325064855.GD50230@Space.Net> References: <1584173474.2857.102.camel@biplane.com.au> <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 06:49:01 -0000 Hi, On Wed, Mar 25, 2020 at 03:03:45PM +1300, Brian E Carpenter wrote: > Only if the router violates the spec: > " Routers must not forward any packets with Link-Local source or > destination addresses to other links." [RFC4291] > Do we have any evidence of routers that are broken in this way? Yes. Last time we checked, Juniper routers just forward(ed) packets based on destination address, period. (This was a few years ago, when trying to figure out what to do against the then-current resource attacks against IOS XR LPTS with "too many ND packets", so it might have changed in the meantime) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Mar 25 13:21:55 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408293A0C9A; Wed, 25 Mar 2020 13:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY_fbza1w7kz; Wed, 25 Mar 2020 13:21:47 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B373A0C3C; Wed, 25 Mar 2020 13:21:46 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id 7so1716465pgr.2; Wed, 25 Mar 2020 13:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vlMtrnE6Z9MGqISbbdGtw5XR5PDI/1ieIaj6YYtk2uQ=; b=GtlV7ylLyjHjDRWLO8a12qwyOnyGGRX9pwwfk7BAs8T0r+eV88YovRmphB9+o0q7NF MvudBn08ijjVVMOOSSxvsWLfWjcPeYJp9kdk6AOjUs4BAvzO3g0ImQ3/jbfCwZ6s9sav 2LEBYGAVYl3SuRwTzbmvAKNMhr07aVJDGfdBcS3rOeIZR5uMxD9TwUT8uGFByq0h+6rE GrlVxnIZkLDOuK7Py/5bcK1ubc0QHsvDmxSCpy0Tv4iPuZ13VhoX4fR3/r68BqT5QPJf QBblEjb1sIVrjT4o4u+SFN2TTvgxvAJnOIBly8KvjwhEX5KhKW5Jb78T7dq5FGlWQASY qYIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vlMtrnE6Z9MGqISbbdGtw5XR5PDI/1ieIaj6YYtk2uQ=; b=SfCf2PIJ+VxN77Hf66xgVaum06FFzCMPpR1lOGXAjZBZCSFZFH++j6+/XCHotbmpO9 eKnZ/nKu7dPRJ8y7lRRZpKk5A6QfJKr5HM++H5nhSlss21iIdpHbUI1RP8gc3cxRZdp4 YO9nxVbIgFAWzbFePt2lb3rRupNym+Q02U1D+hGfziXLC4f2YyyHbMCH98ndXvvosVU5 mVv6b+ddD/Eli/6DFGt6w/GnokXjF1Mpc3wNieEkbXqmRev7ELKtj7tnxz7XqAd7Hec4 bY13tA91dbLhe2ABxxJnPZWSIEamwqrt2Oq8Ut185/JccxLTRIf5+WVMqA/sDdAqmwsy VfaQ== X-Gm-Message-State: ANhLgQ0pGt0bJP+p2V/N0Ylm5BFb4c9zrxy9vQkSfBzLWHZkL1R34cnH YbbKP5GXQTdfw2z9Gk9dWjiTAgms X-Google-Smtp-Source: ADFU+vtwTmMjcG9Lxb6iQHALfRgkMYaOQNvBGpcIUrjDvapFJ3zQCJKtDjfqUva3WnZ5QPRLhKcopw== X-Received: by 2002:a65:64cb:: with SMTP id t11mr3442870pgv.62.1585167705786; Wed, 25 Mar 2020 13:21:45 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id o128sm9255pfg.5.2020.03.25.13.21.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 13:21:45 -0700 (PDT) To: Gert Doering Cc: Owen DeLong , Erik Kline , V6 Ops List , 6man <6man@ietf.org> References: <1584173474.2857.102.camel@biplane.com.au> <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> <20200325064855.GD50230@Space.Net> From: Brian E Carpenter Message-ID: <55e4ba5d-f7cc-4fc2-dc20-3ac0fd36d46c@gmail.com> Date: Thu, 26 Mar 2020 09:21:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200325064855.GD50230@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 20:21:49 -0000 On 25-Mar-20 19:48, Gert Doering wrote: > Hi, > > On Wed, Mar 25, 2020 at 03:03:45PM +1300, Brian E Carpenter wrote: >> Only if the router violates the spec: >> " Routers must not forward any packets with Link-Local source or >> destination addresses to other links." [RFC4291] >> Do we have any evidence of routers that are broken in this way? > > Yes. Last time we checked, Juniper routers just forward(ed) packets based > on destination address, period. I'm curious. Since link-local addresses are, er, link-local, how would such a router choose the outgoing interface? Brian > > (This was a few years ago, when trying to figure out what to do against > the then-current resource attacks against IOS XR LPTS with "too many ND > packets", so it might have changed in the meantime) > > Gert Doering > -- NetMaster > From nobody Wed Mar 25 13:35:48 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9CA3A0D10; Wed, 25 Mar 2020 13:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_lbWdkxBLR1; Wed, 25 Mar 2020 13:35:31 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7B03A0DAC; Wed, 25 Mar 2020 13:35:30 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02PKZSe41146792 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Mar 2020 13:35:28 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <55e4ba5d-f7cc-4fc2-dc20-3ac0fd36d46c@gmail.com> Date: Wed, 25 Mar 2020 13:35:28 -0700 Cc: Gert Doering , Erik Kline , V6 Ops List , 6man <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <8DF1D07B-471D-4998-A25C-1EE7767EBAC2@delong.com> References: <1584173474.2857.102.camel@biplane.com.au> <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> <20200325064855.GD50230@Space.Net> <55e4ba5d-f7cc-4fc2-dc20-3ac0fd36d46c@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Wed, 25 Mar 2020 13:35:28 -0700 (PDT) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 20:35:46 -0000 > On Mar 25, 2020, at 13:21 , Brian E Carpenter = wrote: >=20 > On 25-Mar-20 19:48, Gert Doering wrote: >> Hi, >>=20 >> On Wed, Mar 25, 2020 at 03:03:45PM +1300, Brian E Carpenter wrote: >>> Only if the router violates the spec: >>> " Routers must not forward any packets with Link-Local source or >>> destination addresses to other links." [RFC4291] >>> Do we have any evidence of routers that are broken in this way? >>=20 >> Yes. Last time we checked, Juniper routers just forward(ed) packets = based >> on destination address, period. >=20 > I'm curious. Since link-local addresses are, er, link-local, how would > such a router choose the outgoing interface? >=20 I think that the point of the message is that if the packet has LL = Source and non-LL destination=E2=80=A6 It could get erroneously forwarded. Owen From nobody Wed Mar 25 13:44:49 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7083A0CF4 for ; Wed, 25 Mar 2020 13:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd_D_TRUDeBl for ; Wed, 25 Mar 2020 13:44:42 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FAE3A0CE2 for ; Wed, 25 Mar 2020 13:44:42 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02PKieX2030965 for ; Wed, 25 Mar 2020 21:44:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A7ECB205060 for ; Wed, 25 Mar 2020 21:44:40 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9E9A8204EDF for ; Wed, 25 Mar 2020 21:44:40 +0100 (CET) Received: from [10.11.240.93] ([10.11.240.93]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02PKicAf016097 for ; Wed, 25 Mar 2020 21:44:39 +0100 To: v6ops@ietf.org References: <1584173474.2857.102.camel@biplane.com.au> <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> <20200325064855.GD50230@Space.Net> <55e4ba5d-f7cc-4fc2-dc20-3ac0fd36d46c@gmail.com> <8DF1D07B-471D-4998-A25C-1EE7767EBAC2@delong.com> From: Alexandre Petrescu Message-ID: Date: Wed, 25 Mar 2020 21:44:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <8DF1D07B-471D-4998-A25C-1EE7767EBAC2@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 20:44:47 -0000 Le 25/03/2020 à 21:35, Owen DeLong a écrit : > > >> On Mar 25, 2020, at 13:21 , Brian E Carpenter wrote: >> >> On 25-Mar-20 19:48, Gert Doering wrote: >>> Hi, >>> >>> On Wed, Mar 25, 2020 at 03:03:45PM +1300, Brian E Carpenter wrote: >>>> Only if the router violates the spec: >>>> " Routers must not forward any packets with Link-Local source or >>>> destination addresses to other links." [RFC4291] >>>> Do we have any evidence of routers that are broken in this way? >>> >>> Yes. Last time we checked, Juniper routers just forward(ed) packets based >>> on destination address, period. >> >> I'm curious. Since link-local addresses are, er, link-local, how would >> such a router choose the outgoing interface? >> > > I think that the point of the message is that if the packet has LL Source and non-LL > destination… It could get erroneously forwarded. For my part, I think that is not an error. It might be that the src is link-local unicast and the dst is site-local multicast scope. I think that should work. Alex, LF/HF 1 > > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Mar 25 14:05:57 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B0A3A0946 for ; Wed, 25 Mar 2020 14:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkx5KUsZf8zd for ; Wed, 25 Mar 2020 14:05:13 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EB63A0E0A for ; Wed, 25 Mar 2020 14:05:11 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 29326436D4 for ; Wed, 25 Mar 2020 22:05:09 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id C023A410AC; Wed, 25 Mar 2020 22:05:08 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id BBBC1100185; Wed, 25 Mar 2020 22:05:08 +0100 (CET) Date: Wed, 25 Mar 2020 22:05:08 +0100 From: Gert Doering To: Brian E Carpenter Cc: Gert Doering , Owen DeLong , Erik Kline , V6 Ops List , 6man <6man@ietf.org> Message-ID: <20200325210508.GP50230@Space.Net> References: <1584173474.2857.102.camel@biplane.com.au> <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> <20200325064855.GD50230@Space.Net> <55e4ba5d-f7cc-4fc2-dc20-3ac0fd36d46c@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2SKbs2OUdOmCpwVQ" Content-Disposition: inline In-Reply-To: <55e4ba5d-f7cc-4fc2-dc20-3ac0fd36d46c@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 21:05:51 -0000 --2SKbs2OUdOmCpwVQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Mar 26, 2020 at 09:21:40AM +1300, Brian E Carpenter wrote: > On 25-Mar-20 19:48, Gert Doering wrote: > > On Wed, Mar 25, 2020 at 03:03:45PM +1300, Brian E Carpenter wrote: > >> Only if the router violates the spec: > >> " Routers must not forward any packets with Link-Local source or > >> destination addresses to other links." [RFC4291] > >> Do we have any evidence of routers that are broken in this way? > >=20 > > Yes. Last time we checked, Juniper routers just forward(ed) packets ba= sed > > on destination address, period. >=20 > I'm curious. Since link-local addresses are, er, link-local, how would > such a router choose the outgoing interface? Well, there was an "or" in the paragraph above that I neglected. Junipers (used to) forward to non-link-local destinations without checking source address. So they (used to) violate the "Routes must not forward any packets with Link-Local source [...] to other links" part. We noticed when we installed "deny ipv6 fe80::/8 $our_ripe_space::/32" filters at our edge routers, and saw quite a few hits there, coming in via transit networks not being numbered from this /32. As I said, this was a few years ago, we had no Juniper routers ourselves back then, and no contacts to get this properly addressed. It might be fixed by now, or not. Fairly easy to test, though. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Em= mer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --2SKbs2OUdOmCpwVQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAl57x4IACgkQ31bAZeTO f8WvUA//TT02t6ntwhQXqZ4jx1RqjdEX6Wjsp632eK7Qp3nGwi5E2w5hiJXv9gCK FK2931U4sPJ/xPz3kK9JQw35W0+ZO2AImXYKBy+ss6r2AQonxB+qS1n1mKxCeuw5 8ZwUN62ySuMjXODrvu0KAibJtOO6Kc379fBBAteP7AZQ5e/ySzBe0jz+zljvFttR ZLfMo9Dwpas+HOtLJfZSCeu324+TZXWdXc+ZH8zqd4k2khtWBN1Hyvtym7VW4fn2 85ZLkjMKCKz5BD0BOuxmazclHTj4JLj+u0iIXzwba90SnEFgrqw51lq62UQcPREu xzawdFw7JS8/tLz/DZLgeo+FJpX9V2c1Dv2C4RxpeFMK2YWUS9js7B9CbpwEdnAV mtUlajgfvLgJHOyXCHHX5Pw4udX+4mp6ypEFeVv5y7GGhWSMI2z74r7x7DgIcbJE MfLU+WQM+6WD9g4Jk1hGuYpy7hDgc/0hwgFPtP+sLUnvIqptQz/zFlEy0Fm2Ewq2 f4OQGF8524RJOLglF5I4Eqspg1yQGwHax54nQbOQAPy74+xHTY2lo8THrSh6RKQC JxalavHeA3isgMBYy9bvIq/MTihXpzePzPsXdEQAVHWuC3vsrZXffDLKBPXd4YcY 2PBjIKElTioJn0y0PLZQ2Iy5VWU3SD4emDHBXgJqvisXPQzXfWs= =V9DW -----END PGP SIGNATURE----- --2SKbs2OUdOmCpwVQ-- From nobody Wed Mar 25 14:07:16 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A433A0E36 for ; Wed, 25 Mar 2020 14:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS7fK_RCEv6H for ; Wed, 25 Mar 2020 14:06:57 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96323A0E12 for ; Wed, 25 Mar 2020 14:06:48 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9DE744126E for ; Wed, 25 Mar 2020 22:06:46 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 3B712410AC; Wed, 25 Mar 2020 22:06:46 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 3798E100207; Wed, 25 Mar 2020 22:06:46 +0100 (CET) Date: Wed, 25 Mar 2020 22:06:46 +0100 From: Gert Doering To: Alexandre Petrescu Cc: v6ops@ietf.org Message-ID: <20200325210646.GQ50230@Space.Net> References: <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> <20200325064855.GD50230@Space.Net> <55e4ba5d-f7cc-4fc2-dc20-3ac0fd36d46c@gmail.com> <8DF1D07B-471D-4998-A25C-1EE7767EBAC2@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 21:07:15 -0000 Hi, On Wed, Mar 25, 2020 at 09:44:38PM +0100, Alexandre Petrescu wrote: > For my part, I think that is not an error. It might be that the src is > link-local unicast and the dst is site-local multicast scope. I think > that should work. If you want that to work, you need to get that RFC updated. Until then, it is strictly forbidden. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Mar 25 14:22:33 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269FB3A0E05 for ; Wed, 25 Mar 2020 14:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6wpO4hInYII for ; Wed, 25 Mar 2020 14:22:18 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 089013A0DF2 for ; Wed, 25 Mar 2020 14:22:16 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02PLMD1J1161843 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Mar 2020 14:22:13 -0700 From: Owen DeLong Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D4AE7B25-FB85-44DC-9DF6-A283BEF03A6D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 25 Mar 2020 14:22:13 -0700 In-Reply-To: Cc: v6ops@ietf.org To: Alexandre Petrescu References: <1584173474.2857.102.camel@biplane.com.au> <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> <20200325064855.GD50230@Space.Net> <55e4ba5d-f7cc-4fc2-dc20-3ac0fd36d46c@gmail.com> <8DF1D07B-471D-4998-A25C-1EE7767EBAC2@delong.com> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Wed, 25 Mar 2020 14:22:13 -0700 (PDT) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 21:22:31 -0000 --Apple-Mail=_D4AE7B25-FB85-44DC-9DF6-A283BEF03A6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 25, 2020, at 13:44 , Alexandre Petrescu = wrote: >=20 > Le 25/03/2020 =C3=A0 21:35, Owen DeLong a =C3=A9crit : >>> On Mar 25, 2020, at 13:21 , Brian E Carpenter = wrote: >>>=20 >>> On 25-Mar-20 19:48, Gert Doering wrote: >>>> Hi, >>>>=20 >>>> On Wed, Mar 25, 2020 at 03:03:45PM +1300, Brian E Carpenter wrote: >>>>> Only if the router violates the spec: >>>>> " Routers must not forward any packets with Link-Local source or >>>>> destination addresses to other links." [RFC4291] >>>>> Do we have any evidence of routers that are broken in this way? >>>>=20 >>>> Yes. Last time we checked, Juniper routers just forward(ed) = packets based >>>> on destination address, period. >>>=20 >>> I'm curious. Since link-local addresses are, er, link-local, how = would >>> such a router choose the outgoing interface? >>>=20 >> I think that the point of the message is that if the packet has LL = Source and non-LL >> destination=E2=80=A6 It could get erroneously forwarded. >=20 > For my part, I think that is not an error. It might be that the src = is link-local unicast and the dst is site-local multicast scope. I = think that should work. Well, you are wrong. Any packet with a LL Source _OR_ Destination = address should not be forwarded. It=E2=80=99s in the RFCs that way and = it=E2=80=99s there for a reason, possibly many reasons. Owen --Apple-Mail=_D4AE7B25-FB85-44DC-9DF6-A283BEF03A6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 25, 2020, at 13:44 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

Le 25/03/2020 =C3=A0 21:35, Owen = DeLong a =C3=A9crit :
On= Mar 25, 2020, at 13:21 , Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On 25-Mar-20 19:48, Gert Doering wrote:
Hi,

On Wed, Mar 25, 2020 at 03:03:45PM +1300, Brian E Carpenter = wrote:
Only if the = router violates the spec:
"  Routers must not forward = any packets with Link-Local source or
  destination addresses to other links." = [RFC4291]
Do we have any evidence of routers that are = broken in this way?

Yes. =  Last time we checked, Juniper routers just forward(ed) packets = based
on destination address, period.

I'm curious. Since link-local = addresses are, er, link-local, how would
such a router = choose the outgoing interface?

I= think that the point of the message is that if the packet has LL Source = and non-LL
destination=E2=80=A6 It could get erroneously = forwarded.

For my part, I think that is not an error.  It might be = that the src is link-local unicast and the dst is site-local multicast = scope.  I think that should work.

Well, you are wrong. Any packet with a LL Source _OR_ = Destination address should not be forwarded. It=E2=80=99s in the RFCs = that way and it=E2=80=99s there for a reason, possibly many = reasons.

Owen

= --Apple-Mail=_D4AE7B25-FB85-44DC-9DF6-A283BEF03A6D-- From nobody Thu Mar 26 06:24:36 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5B63A0D0B; Thu, 26 Mar 2020 06:24:24 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBsS8ZbzdW9w; Thu, 26 Mar 2020 06:24:22 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA47E3A0D0A; Thu, 26 Mar 2020 06:24:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jHSUT-0000K3C; Thu, 26 Mar 2020 14:24:09 +0100 Message-Id: To: v6ops@ietf.org Cc: Gert Doering Cc: 6man <6man@ietf.org> From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <1584173474.2857.102.camel@biplane.com.au> <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> <20200325064855.GD50230@Space.Net> <55e4ba5d-f7cc-4fc2-dc20-3ac0fd36d46c@gmail.com> <20200325210508.GP50230@Space.Net> In-reply-to: Your message of "Wed, 25 Mar 2020 22:05:08 +0100 ." <20200325210508.GP50230@Space.Net> Date: Thu, 26 Mar 2020 14:24:09 +0100 Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 13:24:26 -0000 In your letter dated Wed, 25 Mar 2020 22:05:08 +0100 you wrote: >Junipers (used to) forward to non-link-local destinations without checking >source address. So they (used to) violate the "Routes must not forward any >packets with Link-Local source [...] to other links" part. > >As I said, this was a few years ago, we had no Juniper routers ourselves >back then, and no contacts to get this properly addressed. It might >be fixed by now, or not. Fairly easy to test, though. I just noticed that my ISP is sending me those packets. So yes, this behavior is still alive on todays internet. From nobody Thu Mar 26 12:57:11 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED433A0C7C; Thu, 26 Mar 2020 12:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urUa9fYVa9LO; Thu, 26 Mar 2020 12:57:08 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B8F3A09F7; Thu, 26 Mar 2020 12:57:06 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id v13so2933015pjb.0; Thu, 26 Mar 2020 12:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6eFzdZvaqSMli068fzTb1ZhV3eZ0Zm4kx6INJ8hoRAE=; b=HiDdPJXj85GlUUU5YFOxAD4jRx4h3Sh9D8XQzve8Ey3oTo2uSRpl4RqJqmGeI3VqCi +DazsxVzw4npCTNVN2FST8w+L4PS/NWmrsP6H9WuLghMwoRpJTUJG0R3QJxj44Op11Yq 9DcrGJTDiINl8sNYT7LzPgIv6iSCT0RkJ4tD41pT7SEY1isNX9zI0GZbcb0IiqvPy3hd mLHLVwZ2SobnMQWI+M3wJE6f6r+N73jUuFtzHF8MTEle6yj7E5QJa5GGZm5wxP9vWZgj K9EexSQT2Zz9EcIHj5i20SPpE6+xep1lWA7qJmbjgiYnd3D+KWnI985os/M9RpNCj7ue YXzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6eFzdZvaqSMli068fzTb1ZhV3eZ0Zm4kx6INJ8hoRAE=; b=SfcgrPzIzvnlHTUqXESgRg8V9t3YfqRyY1U+mCWGwAwtcODh3eYlcfdyJCGwDTB1YR A/Be1iXGbqr8zOQFCjpYD8FXcdufWun+Yw4T5IlAsuvogMus/HhdrgHF7TrunogqD87B tHS3zUcsF4nZNCCsYKs3zRTmNghXtnlCtaqk5+7xTuwOYKa5byx2N0l7zhGYG/kgGWCz kugABC/q9kYy9orTaYbka7ZJqecAJaNjVG8EP4cSeu/uuW18wG56bL8YDtDpNZqYhIu8 Ryk28sjU+CpxYe0GAqeRQzVtUrnwRAkXeWz/H6aFqnsL+UobwYiwcdpC32jtwNKeulEQ wR0w== X-Gm-Message-State: ANhLgQ051C/2vm0WcZF/pdAKbhhMSAhH38UAfITyyRoUdvOFeO7P005X MzVthe2lbPmBe2wCjb5O0K/1QurD X-Google-Smtp-Source: ADFU+vuHMP3JgTOmh80krP7iunNKlW4VtFQfUyTNFDamhyO4z9am8UvuspIUPNYIZn6FllI8NPo1sg== X-Received: by 2002:a17:902:6b03:: with SMTP id o3mr9506098plk.331.1585252625732; Thu, 26 Mar 2020 12:57:05 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id x4sm1585230pga.54.2020.03.26.12.57.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2020 12:57:04 -0700 (PDT) To: Philip Homburg , v6ops@ietf.org Cc: 6man <6man@ietf.org>, Gert Doering References: <1584173474.2857.102.camel@biplane.com.au> <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> <20200325064855.GD50230@Space.Net> <55e4ba5d-f7cc-4fc2-dc20-3ac0fd36d46c@gmail.com> <20200325210508.GP50230@Space.Net> From: Brian E Carpenter Message-ID: <992ba9ad-bce4-7566-4dc8-5c63ee81a7e2@gmail.com> Date: Fri, 27 Mar 2020 08:57:00 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 19:57:10 -0000 On 27-Mar-20 02:24, Philip Homburg wrote: > In your letter dated Wed, 25 Mar 2020 22:05:08 +0100 you wrote: >> Junipers (used to) forward to non-link-local destinations without checking >> source address. So they (used to) violate the "Routes must not forward any >> packets with Link-Local source [...] to other links" part. >> >> As I said, this was a few years ago, we had no Juniper routers ourselves >> back then, and no contacts to get this properly addressed. It might >> be fixed by now, or not. Fairly easy to test, though. > > I just noticed that my ISP is sending me those packets. So yes, this > behavior is still alive on todays internet. Words fail me. So it seems that setting the hop limit to 255 and checking on receipt really is desirable. Brian From nobody Sun Mar 29 21:44:26 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0BE3A0C5C; Sun, 29 Mar 2020 21:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0815jCpghKx; Sun, 29 Mar 2020 21:44:11 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C77D3A0C5A; Sun, 29 Mar 2020 21:44:11 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id z24so12837391qtu.4; Sun, 29 Mar 2020 21:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QJgSBZW1X5e2Z0gPueA0Dfo/0Ww1FBGb5UXG8UgI5MY=; b=tGo0latrrRKTAQoTOLAFx0Nxji9Brh8/tnjoU4nDDRyA8IKM1OqTTX/9CNlkdk7hpB ZIGvSHxa6s5xOC3YDG+3HC34gySQrfxEYHU5eJXHYF74115kibU74NRdmSKymVtBz2E2 RhtKq5sMiY+h8wkWvJnQWvHtuDnqU+8bW0+WNeQ4C2g9flr8TttdNaCpW0wC2uPm4lKJ YIKL/ybXVyu6RFngAG6bUzm0jEH7ZC4QS54WlW7j+WOQSaCCgf6tu+fsD+ei5TcC+Who sASQfas5/c2eEiYfJgNSiSq4pr53qyvohRbSvCoX0n09egXAc7KVap1Xclgsy5SsoM7Y WvLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QJgSBZW1X5e2Z0gPueA0Dfo/0Ww1FBGb5UXG8UgI5MY=; b=KupfyrbpoiyEgAEk74fjzyuHglvoCNgvYMtigo5pM7Igvw/XtotB2Q9SLMGgVx8zMx 4kwVuqdlhftkXeizQs2754Kfnzaf1LZxgRySqeo9K6oOpRf9EAHIWdxiTIC8nNkNIxqm 69o8TtHQ1KnXxjaS3Ootza3CzSTXCzTQ26GMyPr+H/pNNvBWRGb6bkkuQn1XHQPd4fvh HExW8dBB11Jd4ghkLzxO1ekH1Ol41DZVnuHh6VKD17A88ltAoLuenhqAfQl2OeKCNXiI 90IuzOkStxM7u14KoE+0d0elQRi72h3OKAc2DL7qZaoqXXVZ3JrO11e/kGMM3jRtyaSm UDoA== X-Gm-Message-State: ANhLgQ16gcCfxSUR0f6FWUBoF0dGd0dYtUqsvQ/GE53PTlD/MHRy2i3T NG9xA/K3/0Q9EWyL9geWS499K+E9q6HsPwSeELk= X-Google-Smtp-Source: ADFU+vvRBdfbK5R2+M1W9dzcHbVPF6tT3Gz4sF28AhDZDRDlxGJsTsE03mAQYwg23jyQ37kBHith5PDcgpfnDa/0kSI= X-Received: by 2002:ac8:6b4b:: with SMTP id x11mr10314149qts.118.1585543449941; Sun, 29 Mar 2020 21:44:09 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <1584173474.2857.102.camel@biplane.com.au> <5D374DA6-15B2-47AD-97B4-2BCC120859D1@delong.com> In-Reply-To: From: Jen Linkova Date: Mon, 30 Mar 2020 15:43:58 +1100 Message-ID: To: Brian E Carpenter Cc: Owen DeLong , Erik Kline , V6 Ops List , 6man <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 04:44:13 -0000 On Wed, Mar 25, 2020 at 1:04 PM Brian E Carpenter wrote: > > If you use a hop limit of 1, then a remote attacker only needs to craft a packet with the correct initial hop limit to ensure that it arrives on > > your link what the appropriate remaining hop limit of 1. > > Only if the router violates the spec: > " Routers must not forward any packets with Link-Local source or > destination addresses to other links." [RFC4291] > Do we have any evidence of routers that are broken in this way? I've seen it a few years ago - a few routers (same vendor, based on EUI-64 based interface IDs) somewhere far far away were sending ICMPv6 errors (packet too big) to my border routers using their link-local addresses as a source. Those packets successfully reached my network and got dropped...It was while ago but I'm not sure how much the situation has improved. -- SY, Jen Linkova aka Furry From nobody Mon Mar 30 08:47:21 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CE23A17D9 for ; Mon, 30 Mar 2020 08:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=XFB7biex; dkim=pass (1024-bit key) header.d=juniper.net header.b=ky6hm22U Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjnOMC3ZiKYL for ; Mon, 30 Mar 2020 08:47:17 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867C13A17D7 for ; Mon, 30 Mar 2020 08:47:17 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02UFbtXg001359 for ; Mon, 30 Mar 2020 08:47:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=BGDb2wuUWHYP+0Q1Vct5aC2r0BxvSywoU0bwcGd/chA=; b=XFB7biexELVSFG5gTYaCduboEKFJm/M+e9PebUPtuxW7NGJ3Xx/3a1aqj61/gXCHZ9Vs /uYYNKZqUShLJbfR9f8U1SDG5hh6p2vPK7aA2HF7QgzSk3PyCmXhT9Sh7f5Yh9GhEzeW pyxIDBR08wn2NkJfB1Pm+8MNhM9gYPA78oOegJO6t6Gl34OVS6yCBP2pd+sI8BO3cQ/i wTy3y4gTt+i/qFekJ/7HGfyZ0RqLQV71clFfcAceHAaUZkL7sDPDp0zWFgWqs0c7Sy7g MMfCtno3jDf5Bk4lUILHXprzyQvV8OUVloy+hE/xHIYJ/6KgOfWJF2STdREbYgW6Z8v5 Nw== Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2103.outbound.protection.outlook.com [104.47.55.103]) by mx0a-00273201.pphosted.com with ESMTP id 3025unb1a3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 30 Mar 2020 08:47:17 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f02OumH68y2BMp/BVWeOAamAldgUPVbOO+IVfbQgNBXCoCdAmtWcum5nw7qtq9nvuDhctJfJk02h7gcXtza0bBMEOkB/xK7a5SNuxWCM3l/WHfetWB7SV9X1R6wbqcdW5TwFGv0LnZ/IY5skXTH0WzFco1Nx1Ei92Z3SraMNdEhPwWDUXWaK/xQRCRuwJOv6PsyosJRGAs94kt17xSGf6R/SkiiBa8uflmbZNF1Cr2tTlmBjjU4UZVTWKmE85Wp/1j1HMmPu8aySQfCkc0R3ZYYEiiUrr1nqt72u37ygFHmMGkE6GZarL02P5G09Qtc+6GX3bO44/rToy3Bwty+FSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BGDb2wuUWHYP+0Q1Vct5aC2r0BxvSywoU0bwcGd/chA=; b=iIsWWjkQCrTyiX/w7d9Y+U3wja6QD54gt3O+h1UD1t/LxpXIScdDEl7C9jv53WHBPh6GZD8Gpi7TZAqUbA8jkIV756VYQ9zcbpBj3NCmoaWnkuoiE9U2SsFcKLNOs4UUTEJ83+7sZIyMZuasCdrkTWXVrRNdiMxME6IkDAdlsnaa8UcJMMII3ySs5r8yEp+K3JZtvfwIFzheIuProdBB8C9XRG2ZxczHvLtPlFl42WuKrU1uCqAFv6VmVUW2VYJl/EmUlYF8WtAUpAqF3kEij48y/XqY0yK451Oyy6MqlKvLlxdhNGcMMrDSFB4e1Hbtlcp+O55PEVRmDKhPuzFhvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BGDb2wuUWHYP+0Q1Vct5aC2r0BxvSywoU0bwcGd/chA=; b=ky6hm22UFaL87AlaOZExpE+TjQ9IBPw9ELJarmdfMO4fQt9Y65IvJMgqzM3chSXP9FiFrC8ieKK5Dnz6KJbqLdqnwOnkel5Txz6EhZUOakpz3reYBiT9sRlXn8HAwoAehFEGf4GshFpaIwrQY6W4iUy6yxNBip1OZH2OFac9pkw= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB4394.namprd05.prod.outlook.com (2603:10b6:5:9f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.13; Mon, 30 Mar 2020 15:47:14 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::cdd:ea54:f213:7e02]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::cdd:ea54:f213:7e02%5]) with mapi id 15.20.2856.019; Mon, 30 Mar 2020 15:47:14 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: WG Last Call on draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdYGqnrRGOoD4f0yRz2uh9FnYboxrQ== Date: Mon, 30 Mar 2020 15:47:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-03-30T15:47:13.3643621Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=67208681-d98f-4eec-8b68-cfba5e0c2a3d; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [108.28.233.91] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0815e964-8d44-4f74-175e-08d7d4c19e73 x-ms-traffictypediagnostic: DM6PR05MB4394: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2089; x-forefront-prvs: 0358535363 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(396003)(366004)(346002)(376002)(39860400002)(136003)(66446008)(66946007)(66556008)(66476007)(71200400001)(8676002)(2906002)(76116006)(81166006)(81156014)(8936002)(55016002)(9686003)(316002)(6916009)(478600001)(64756008)(86362001)(558084003)(5660300002)(33656002)(26005)(186003)(6506007)(52536014)(7696005); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iIRSDn8fw4CsWtK0hL2ch3hlEYu6JC68SXu1faYliOxWXlQMGGSfvixLO+GyTpYOmFA/wJMgU3DF0QWZ9Kuq0T/UGpYOX8JAM0qN0d2e/wNU0VnpdF2sECr6xPZOy7wR3Xmy84bLWtpRNjxEUfqtOaU0rusgoLNrRlCE0jPJSRRb0KOlBlarWEWptN6VZtAW6YQG2TpEduP8q9HQcEIbaNj8sF3CJfq3P0elWGAdzZclbtVkrOGJrMXgMyxGkQAagx3Kvz6t+WgWscdcGdeS/C8HxcLv7knAivSxkNtRq6ibg5kMJmXnBPlpPxmH5h3CaRBp2FubsU83Ir6Ui+4/NT6QK0mNFzNquMU1wdo3LkjNXHbfXuCpGCND5Xu47MWmhu+CF72cpA/pA0UnmW4tyOvN0HxHciIsM5Ovf4NwzmKFIgoQsyPOdhMWBncP5lWp x-ms-exchange-antispam-messagedata: fSEM+qa/uVKqp+pluKXeyy7Vvb+MaAupifK4Wmim3gKZzaevU9X73swA1V4p6HHIW19oKrH1ZWmQBHJyX7LqEP7VYfux6qdYWFv0NNykwkR4iWCFN2NorvWXDnvEgUR6iTLhVN4ra6uz3fYUs2E8LQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB63485C37CC3ADCF87CB8BC9CAECB0DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 0815e964-8d44-4f74-175e-08d7d4c19e73 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2020 15:47:14.6444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qgZnMbMR91DxYEDeowbuVtFlCT/Ej6F0cdbpmHvBcYuTmhHtb+T4jyROtFCtiFL22jnIBto2IyeQoyWhmGu1fg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4394 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-03-30_06:2020-03-30, 2020-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 phishscore=0 impostorscore=0 suspectscore=0 clxscore=1015 spamscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=453 bulkscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003300144 Archived-At: Subject: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 15:47:19 -0000 --_000_DM6PR05MB63485C37CC3ADCF87CB8BC9CAECB0DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum. Please submit comments by April 13, 2020. Fred and Ron Juniper Business Use Only --_000_DM6PR05MB63485C37CC3ADCF87CB8BC9CAECB0DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

This message initiates a WG Last Call on draft-ietf-= v6ops-cpe-slaac-renum.

 

Please submit comments by April 13, 2020.=

 

        &nbs= p;            &= nbsp;            Fre= d and Ron


Juniper Business= Use Only

--_000_DM6PR05MB63485C37CC3ADCF87CB8BC9CAECB0DM6PR05MB6348namp_--


Thanks=C2=A0

Gyan

On Wed, Mar 11, 2020 at 8:01= PM Toerless Eckert <tte@cs.fau.de&= gt; wrote:
Sorry for cross posting,= but this is both ops and arch questions.

I was trying to find any generic description that/if link-local IPv6
traffic MUST/SHOULD use Hop-count 1, but could not find one in
rfc8200 or rfc4291 and its updates. Instead, text like
MUST set Hop-limit to 1 is repeated in various RFCs using link-local
IPv6 traffic.

Am i overlooking something ? Or is this intentional in the IPv6 architectur= e ?

If intentional, i guess it means: Any RFC introducing some type of link-loc= al
traffic can specify Hop-limit requirements for its traffic. As in
"our WG likes 42 as the Hop-limit" (silly to me, but should be fi= ne with
IPv6 architecture then, right ?).

In one of my draft document reviews using such link-local IPv6 traffic,
EricV brought up the Q if that traffic shouldn't use RFC5082 instead of Hop-Count 1 too. But given how we do not seem to have architectural
recommendations for TTL=3D1 (unless, quite likely i overlook something), and given how i am not aware of any actual use of GTSM, i am quite
weary to go down that route. Aka: Would like learn of actual uses of
GTSM with IPv6.

There is an additional set of consideration re. link-local traffic
when trying to use it as a HW accelerated tunneling mechanism across links,=
a use we both have in ANIMA, and maybe get the same in BIER (probably
other WGs too, not sure).

In implementations, i have seen quite a range of issues with
accelerated forwarding planes across link-local addressed tunnels,
and when using non-link-local addresses (loopback addresses),
the HW plane forwarding might have issues doing HW forwarding, because
usually TTL=3D1 is only used for control plane traffic. Of course,
this is not a good architectural argument, but if given architectural
leeway to even choose 42, maybe GTSM/255 is easier to be supported
across various HW accelerated forwarding planes than 1.

Opinions and experiences welcome!

Thanks!
=C2=A0 =C2=A0 Toerless

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--
<= div dir=3D"ltr">

Gyan= =C2=A0 Mishra

Network Engineering & Technology= =C2=A0

Verizon=C2=A0

Silver Spring, MD 20= 904

Phone: 301 502-1347

<= font size=3D"1" color=3D"#000000" face=3D"georgia, serif">Email: gyan.s.mishra@verizon.= com



--000000000000e3379405a0ca0f82-- From nobody Fri Mar 13 23:08:38 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2EC3A0FDE; Fri, 13 Mar 2020 23:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m09MJqPFG7po; Fri, 13 Mar 2020 23:08:16 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E635C3A0FDD; Fri, 13 Mar 2020 23:08:15 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id w9so11806761iob.12; Fri, 13 Mar 2020 23:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V+VUBS4bxdDxWqWmLbNw3vsp1vdyh00nh5lwQm8cRy4=; b=NP0u+HC3WDSJuvMQZWS+j+nlfDWj15y6HZj54Z4QvWMo3Z8TmX0ZC/oIOHRR59orkz HTWLQ0xHa89b+DaznAqo3NvRTd+GGGcza5BLISGMrMxcOn/jW4K6DwgNoXDzdTqN5fZo 2LnhiZ9PLKwntdl5igG8rFr2cdrXQVHjhh2cpPj2FydncLkXlxoB+bpKyctiaXgotdNV srbzfe+rld2CpufSINhvaoBof9ficTmLkq9ubvXHBTssS/OevRMfQLFv1mHVkq1HghNE lJ72vHGF3NfkZkHWd1JEjzVAMOGRztoY3I+0Cvv9giCJlKRgm2TT4s9jTFGpLDrgIbmH 07wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V+VUBS4bxdDxWqWmLbNw3vsp1vdyh00nh5lwQm8cRy4=; b=p1Po89Lu0nLspsuN4+Fk6IVM8UFeBVygEWmK9GWfEbskP1jRqslNABvFzCQ3r634x/ qTueGPr/ViwChNiEtI7iwyk/DGqNsTBnvubE1lzIT2V+vFvyoAaGEYdz4ZVpouQkiE1o lfMvUmkw8OLdk5imgcSArud4QytBTMyHGpN2DKjynTRWA9JUy0qHVK5Z8MUfpzScUHNG cjn0sPvOiHm2tzkMGXyuWmX1e4aiAqsx1OXtuCgL/7Y/4fjDB0ljTynb0+GZlxqdQzRJ 4NqQB0vKC4/axH1nE1oE7385gn0HFjHxmv0xXjOCvDFUo8/qhfbm+Vlqu6wIlopfDsh3 yxkQ== X-Gm-Message-State: ANhLgQ0POssDoujS8TTNGk0VlyuZbQfVKUuvkFTdMd/KrtKI4/TpKF8s VhgD7Jgilj3qXLh+tiuuhXnJ0ioAFWS74P3HRHY= X-Google-Smtp-Source: ADFU+vsmFD0G6moEDSB/PMtl6zlowDPnd5I2P9qEI+o3csahnCnm3w+EvqznsPMNHQ9X9PRJ33aWrWq0i01gQxzLXI0= X-Received: by 2002:a5d:9697:: with SMTP id m23mr15622383ion.45.1584166095010; Fri, 13 Mar 2020 23:08:15 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> In-Reply-To: From: Gyan Mishra Date: Sat, 14 Mar 2020 02:07:34 -0400 Message-ID: To: Jen Linkova Cc: Toerless Eckert , V6 Ops List , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000005bbf8605a0ca691a" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 06:08:19 -0000 --0000000000005bbf8605a0ca691a Content-Type: text/plain; charset="UTF-8" Jen I always wondered why RFC 4862 states that ND & RD packets have TTL 255. We have run into so many PSIRT bugs with ND which makes it more problematic having the TTL 255. Since ND & RD packets would always be local scope in your response to Toreless you mentioned that GTSM that ND using 255 is kind of an example of GTSM in the sense that the TTL is set to 255 for a direct neighbor adjacency. I think though the security issues of TTL 255 with ND/RD packets seem to make security a bigger issue then just leaving TTL=1. Gyan On Wed, Mar 11, 2020 at 8:34 PM Jen Linkova wrote: > On Thu, Mar 12, 2020 at 11:01 AM Toerless Eckert wrote: > > > > Sorry for cross posting, but this is both ops and arch questions. > > > > I was trying to find any generic description that/if link-local IPv6 > > traffic MUST/SHOULD use Hop-count 1, but could not find one in > > rfc8200 or rfc4291 and its updates. Instead, text like > > MUST set Hop-limit to 1 is repeated in various RFCs using link-local > > IPv6 traffic. > > I believe it depends what you are trying to achieve. If you want to > make sure that the traffic never leaves the network - then hop limit = > 1 helps. But using link-local sources/destinations would help even > better if the routers comply with RFC4291 Section 2.5.6 > If you want to make sure those packets are not sent by a malicious > party from outside - hop limit shall be 255. > For example, see RFC4861 Section 3.1 > > > Am i overlooking something ? Or is this intentional in the IPv6 > architecture ? > > > > If intentional, i guess it means: Any RFC introducing some type of > link-local > > traffic can specify Hop-limit requirements for its traffic. As in > > "our WG likes 42 as the Hop-limit" (silly to me, but should be fine with > > IPv6 architecture then, right ?). > > > > In one of my draft document reviews using such link-local IPv6 traffic, > > EricV brought up the Q if that traffic shouldn't use RFC5082 instead > > of Hop-Count 1 too. But given how we do not seem to have architectural > > recommendations for TTL=1 (unless, quite likely i overlook something), > > and given how i am not aware of any actual use of GTSM, i am quite > > weary to go down that route. Aka: Would like learn of actual uses of > > GTSM with IPv6. > > Neighbor Discovery. > > > There is an additional set of consideration re. link-local traffic > > when trying to use it as a HW accelerated tunneling mechanism across > links, > > a use we both have in ANIMA, and maybe get the same in BIER (probably > > other WGs too, not sure). > > > > In implementations, i have seen quite a range of issues with > > accelerated forwarding planes across link-local addressed tunnels, > > and when using non-link-local addresses (loopback addresses), > > the HW plane forwarding might have issues doing HW forwarding, because > > usually TTL=1 is only used for control plane traffic. Of course, > > this is not a good architectural argument, but if given architectural > > leeway to even choose 42, maybe GTSM/255 is easier to be supported > > across various HW accelerated forwarding planes than 1. > > > > Opinions and experiences welcome! > > If you control the router I'd say 'link-local source/destination, > HL=255 AND RFC4291 would be the best option. > > I did see a few devices somewhere far away sending me ICMPv6 (packet > too big) from their link-local addresses but it was not very common > case. > > -- > SY, Jen Linkova aka Furry > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --0000000000005bbf8605a0ca691a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jen

I always wondered why RFC 4862 stat= es that ND & RD packets have TTL 255.=C2=A0 We have=C2=A0run into so ma= ny PSIRT bugs with=C2=A0ND which makes it more problematic having the TTL 2= 55.

Since ND & RD packets would always be loca= l scope in your response to Toreless you mentioned that GTSM that ND using = 255 is kind of an example of GTSM in the sense that the TTL is set to 255 f= or a direct neighbor adjacency.=C2=A0 I think though the security issues of= TTL 255 with ND/RD packets seem to make security a bigger issue then just = leaving TTL=3D1.

Gyan

On Wed, Mar 11, 2020 at= 8:34 PM Jen Linkova <furry13@gmail= .com> wrote:
On Thu, Mar 12, 2020 at 11:01 AM Toerless Eckert <tte@cs.fau.de> wrote:
>
> Sorry for cross posting, but this is both ops and arch questions.
>
> I was trying to find any generic description that/if link-local IPv6 > traffic MUST/SHOULD use Hop-count 1, but could not find one in
> rfc8200 or rfc4291 and its updates. Instead, text like
> MUST set Hop-limit to 1 is repeated in various RFCs using link-local > IPv6 traffic.

I believe it depends what you are trying to achieve. If you want to
make sure that the traffic never leaves the network - then hop limit =3D 1 helps. But using link-local sources/destinations would help even
better if the routers comply with RFC4291 Section 2.5.6
If you want to make sure those packets are not sent by a malicious
party from outside - hop limit shall be 255.
For example, see RFC4861 Section 3.1

> Am i overlooking something ? Or is this intentional in the IPv6 archit= ecture ?
>
> If intentional, i guess it means: Any RFC introducing some type of lin= k-local
> traffic can specify Hop-limit requirements for its traffic. As in
> "our WG likes 42 as the Hop-limit" (silly to me, but should = be fine with
> IPv6 architecture then, right ?).
>
> In one of my draft document reviews using such link-local IPv6 traffic= ,
> EricV brought up the Q if that traffic shouldn't use RFC5082 inste= ad
> of Hop-Count 1 too. But given how we do not seem to have architectural=
> recommendations for TTL=3D1 (unless, quite likely i overlook something= ),
> and given how i am not aware of any actual use of GTSM, i am quite
> weary to go down that route. Aka: Would like learn of actual uses of > GTSM with IPv6.

Neighbor Discovery.

> There is an additional set of consideration re. link-local traffic
> when trying to use it as a HW accelerated tunneling mechanism across l= inks,
> a use we both have in ANIMA, and maybe get the same in BIER (probably<= br> > other WGs too, not sure).
>
> In implementations, i have seen quite a range of issues with
> accelerated forwarding planes across link-local addressed tunnels,
> and when using non-link-local addresses (loopback addresses),
> the HW plane forwarding might have issues doing HW forwarding, because=
> usually TTL=3D1 is only used for control plane traffic. Of course,
> this is not a good architectural argument, but if given architectural<= br> > leeway to even choose 42, maybe GTSM/255 is easier to be supported
> across various HW accelerated forwarding planes than 1.
>
> Opinions and experiences welcome!

If you control the router I'd say 'link-local source/destination, HL=3D255 AND RFC4291 would be the best option.

I did see a few devices somewhere far away sending me ICMPv6 (packet
too big) from their link-local addresses but it was not very common
case.

--
SY, Jen Linkova aka Furry

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------


--

Gyan=C2=A0 Mi= shra

Network Engineering & Technology=C2=A0

Verizon=C2=A0

Silver Spring, MD 20904=

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com



--0000000000005bbf8605a0ca691a-- From nobody Sat Mar 14 01:11:23 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF663A11BA; Sat, 14 Mar 2020 01:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAWuHVBlFWLk; Sat, 14 Mar 2020 01:11:19 -0700 (PDT) Received: from ipmail02.adl4.internode.on.net (ipmail02.adl4.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id EA9F03A11B9; Sat, 14 Mar 2020 01:11:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DwAACSkGxe/7t/ZZYNWRwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF7gxWBKgeEFpEYm0EJAS8QBAEBhEMCgkE4EwIQAQEGAQEBAQE?= =?us-ascii?q?FBIZDhXABAQEDIw8BVgsYAgImAgJXBgESHIMLgwOrSnWBMoU6EYNSgT6BDiq?= =?us-ascii?q?MSIFBP4FHgl4+glkLAoE9gzmCXgSwPYE3gQ+HVo84g0uXeI8EiQGCPIJ6gVC?= =?us-ascii?q?NZWKBGDMaCBcZggSBIwlHJZBKgUaKaWCMCYJCAQE?= Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.119]) ([150.101.127.187]) by ipmail02.adl4.internode.on.net with ESMTP; 14 Mar 2020 18:41:15 +1030 Message-ID: <1584173474.2857.102.camel@biplane.com.au> From: Karl Auer Reply-To: kauer@biplane.com.au To: 6man <6man@ietf.org>, V6 Ops List Date: Sat, 14 Mar 2020 19:11:14 +1100 In-Reply-To: References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 08:11:21 -0000 On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote: > I always wondered why RFC 4862 states that ND & RD packets have TTL > 255. >From RFC4861:    "By setting the Hop Limit to 255, Neighbor Discovery     is immune to off-link senders that accidentally or     intentionally send ND messages.  In IPv4, off-link     senders can send both ICMP Redirects and Router     Advertisement messages." RFC4861 also requires RA and NA packets with any other TTL value to be silently discarded by any receiving node. I can't find my original source, but my notes in a training course I developed a while ago have this to say about why:    "Why does 255 mean “local source”? Because routers     decrement the hop limit on packets passing through     them, and discard packets where the hop count     decrements to zero. It is impossible to decrement     a one-byte counter to 255 without passing through     zero, because 255 is the maximum value such a counter     can have. So the value 255 means that the packet must     have been generated on the local link." Probably would be better expressed as "must have originated on the local link". Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170 Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D From nobody Sat Mar 14 01:30:30 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB933A0911; Sat, 14 Mar 2020 01:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6vWSveovXLE; Sat, 14 Mar 2020 01:30:22 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33663A0904; Sat, 14 Mar 2020 01:30:21 -0700 (PDT) Received: from [IPv6:2a02:20c8:5921:100:103:7604:71f1:436b] (unknown [IPv6:2a02:20c8:5921:100:103:7604:71f1:436b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id DAC484E11B4C; Sat, 14 Mar 2020 08:30:20 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Sat, 14 Mar 2020 09:30:17 +0100 Message-Id: References: <1584173474.2857.102.camel@biplane.com.au> Cc: 6man <6man@ietf.org>, V6 Ops List In-Reply-To: <1584173474.2857.102.camel@biplane.com.au> To: kauer@biplane.com.au X-Mailer: iPhone Mail (17E5249a) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 08:30:24 -0000 Gyan, ND packets have a hop limit of 255 for security. A receiver of an ND packet i= s required to verify hop limit =3D=3D 255. This protects against off-link at= tacks.=20 That is not possible with hop limit 1. Cheers=20 Ole > On 14 Mar 2020, at 09:12, Karl Auer wrote: >=20 > =EF=BB=BFOn Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote: >> I always wondered why RFC 4862 states that ND & RD packets have TTL >> 255. >=20 >> =46rom RFC4861: >=20 > "By setting the Hop Limit to 255, Neighbor Discovery > is immune to off-link senders that accidentally or > intentionally send ND messages. In IPv4, off-link > senders can send both ICMP Redirects and Router > Advertisement messages." >=20 > RFC4861 also requires RA and NA packets with any other TTL value to be > silently discarded by any receiving node. >=20 > I can't find my original source, but my notes in a training course I > developed a while ago have this to say about why: >=20 > "Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Because routers > decrement the hop limit on packets passing through > them, and discard packets where the hop count > decrements to zero. It is impossible to decrement > a one-byte counter to 255 without passing through > zero, because 255 is the maximum value such a counter > can have. So the value 255 means that the packet must > have been generated on the local link." >=20 > Probably would be better expressed as "must have originated on the > local link". >=20 > Regards, K. >=20 > --=20 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 >=20 > GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170 > Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Mar 14 01:40:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AAC3A0958 for ; Sat, 14 Mar 2020 01:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWzpKuWx_wBu for ; Sat, 14 Mar 2020 01:39:59 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586673A096A for ; Sat, 14 Mar 2020 01:39:58 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 85D324194E for ; Sat, 14 Mar 2020 09:39:56 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 660614194A; Sat, 14 Mar 2020 09:39:56 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 49071108079; Sat, 14 Mar 2020 09:39:56 +0100 (CET) Date: Sat, 14 Mar 2020 09:39:56 +0100 From: Gert Doering To: Gyan Mishra Cc: Jen Linkova , 6man <6man@ietf.org>, V6 Ops List , Toerless Eckert Message-ID: <20200314083956.GS50230@Space.Net> References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 08:40:02 -0000 Hi, On Sat, Mar 14, 2020 at 02:07:34AM -0400, Gyan Mishra wrote: > I always wondered why RFC 4862 states that ND & RD packets have TTL 255. > We have run into so many PSIRT bugs with ND which makes it more problematic > having the TTL 255. Read what has been written in this thread. On the *receiving end* you MUST filter on TTL=255 for ND packets, to ensure that these packets can never be send from an off-link node. Consequently, you MUST send with TTL=255, so that the filter on the receiving end can work. > Since ND & RD packets would always be local scope in your response to > Toreless you mentioned that GTSM that ND using 255 is kind of an example of > GTSM in the sense that the TTL is set to 255 for a direct neighbor > adjacency. I think though the security issues of TTL 255 with ND/RD > packets seem to make security a bigger issue then just leaving TTL=1. You do not seem to understand the security issues involved :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Sat Mar 14 07:26:19 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D193A15A3; Sat, 14 Mar 2020 07:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWgY-505Mgm0; Sat, 14 Mar 2020 07:26:14 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53493A15A4; Sat, 14 Mar 2020 07:26:13 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id l14so11936227ilj.8; Sat, 14 Mar 2020 07:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r2FWV/hjj2Yt8PcP+AiMPOtv8wy//a/4RBYUaOCI1dA=; b=Z/e47d9gyTLWCO9ELbp/X0vn/B5IpsmZsbCLaWij764MfRhPcGyVEyJM1YkWX5uMFx P2WOzgJYua01zzBLGFLZmSYPmIUrvrR2eGNa5czOC94cAv1CTC13TzPAggTY8T1uUgmQ xK3D0cZHMO1/oimV4QJffCD51TJsmV+aPANhu3A6xfY1WoHT7jb/DNgUVRa/MB2NvjRO R4f1UVCakITE6yfGGKlkbjW6mq3K3bizlRl4IH/jr0Yyqjsnjyb98eZ2jlmUs1yWMoiU Okk8GxDs0zcwYPfemRx3c+IaKxPDicInwCQPqFQLxwz4ceWmsdmeRILQv0hkTEIy+qH0 0ddQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r2FWV/hjj2Yt8PcP+AiMPOtv8wy//a/4RBYUaOCI1dA=; b=oEfRszlrjeZZYk9ht7Q0FL/2q9bLQhIwsTIlNRNEV/QasnMn63XvLYTEppN6HDmzVl xrTpqwqAWny0m620D0cQCJ1nVlJd2mMVcjjkVcPJwZH73lIVdOwLYHuXNMfvDEu1H9dq tvwP41C9CV0H04gHeazxYwAbBNhY7ArymDQsuLLXBJbin0ESlT4TrvevJ0GxU552wS7t AQl/4ljg5b+5QuLCwpktbJkqEt22AajTK/My84YmcRmQWrDOOj4epHXhMML7SXKVCBI+ 3L2apy4iGKOcaI1xnW/cWhE9f+wYlel7HOPdBCV1omOZTH+CCe8GrO1GMYzvqiTnuu9A OJCw== X-Gm-Message-State: ANhLgQ1n7o6zqNrG/GluTCGg4VNuLN3Gaxnfdbxj7OOy+ZILKmXj8rBx tuJXEW+cMrVMEOM57Pz2cRby8RaUKFAH8sfk0Tw= X-Google-Smtp-Source: ADFU+vv8NtozFVELcmcu4Iy0UNm/USfFxYJyOP87CZ+DThWCWHSFnLPs7arz0RTH+64JAGdVgdLHJW96YGmslufQ0xc= X-Received: by 2002:a92:5dc7:: with SMTP id e68mr15174755ilg.205.1584195972760; Sat, 14 Mar 2020 07:26:12 -0700 (PDT) MIME-Version: 1.0 References: <1584173474.2857.102.camel@biplane.com.au> In-Reply-To: From: Gyan Mishra Date: Sat, 14 Mar 2020 10:26:02 -0400 Message-ID: To: Ole Troan Cc: 6man <6man@ietf.org>, V6 Ops List , kauer@biplane.com.au Content-Type: multipart/alternative; boundary="00000000000036088e05a0d15eb1" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 14:26:18 -0000 --00000000000036088e05a0d15eb1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ole Gyan On Sat, Mar 14, 2020 at 4:30 AM Ole Troan wrote: > Gyan, > > ND packets have a hop limit of 255 for security. A receiver of an ND > packet is required to verify hop limit =3D=3D 255. This protects against > off-link attacks. > > That is not possible with hop limit 1. > > Cheers > Ole > > > On 14 Mar 2020, at 09:12, Karl Auer wrote: > > > > =EF=BB=BFOn Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote: > >> I always wondered why RFC 4862 states that ND & RD packets have TTL > >> 255. > > > >> From RFC4861: > > > > "By setting the Hop Limit to 255, Neighbor Discovery > > is immune to off-link senders that accidentally or > > intentionally send ND messages. In IPv4, off-link > > senders can send both ICMP Redirects and Router > > Advertisement messages." > > > > RFC4861 also requires RA and NA packets with any other TTL value to be > > silently discarded by any receiving node. > > > > I can't find my original source, but my notes in a training course I > > developed a while ago have this to say about why: > > > > "Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Because routers > > decrement the hop limit on packets passing through > > them, and discard packets where the hop count > > decrements to zero. It is impossible to decrement > > a one-byte counter to 255 without passing through > > zero, because 255 is the maximum value such a counter > > can have. So the value 255 means that the packet must > > have been generated on the local link." > > > > Probably would be better expressed as "must have originated on the > > local link". > > > > Regards, K. > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Karl Auer (kauer@biplane.com.au) > > http://www.biplane.com.au/kauer > > http://twitter.com/kauer389 > > > > GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170 > > Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --00000000000036088e05a0d15eb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ole

Gyan

On Sat, Mar 14, 2020 at 4:30 AM Ole Troan <otroan@employees.org> wrote:
=
Gyan,

ND packets have a hop limit of 255 for security. A receiver of an ND packet= is required to verify hop limit =3D=3D 255. This protects against off-link= attacks.

That is not possible with hop limit 1.

Cheers
Ole

> On 14 Mar 2020, at 09:12, Karl Auer <kauer@biplane.com.au> wrote:
>
> =EF=BB=BFOn Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote:
>> I always wondered why RFC 4862 states that ND & RD packets hav= e TTL
>> 255.
>
>> From RFC4861:
>
>=C2=A0 =C2=A0 "By setting the Hop Limit to 255, Neighbor Discovery=
>=C2=A0 =C2=A0 =C2=A0is immune to off-link senders that accidentally or<= br> >=C2=A0 =C2=A0 =C2=A0intentionally send ND messages.=C2=A0 In IPv4, off-= link
>=C2=A0 =C2=A0 =C2=A0senders can send both ICMP Redirects and Router
>=C2=A0 =C2=A0 =C2=A0Advertisement messages."
>
> RFC4861 also requires RA and NA packets with any other TTL value to be=
> silently discarded by any receiving node.
>
> I can't find my original source, but my notes in a training course= I
> developed a while ago have this to say about why:
>
>=C2=A0 =C2=A0 "Why does 255 mean =E2=80=9Clocal source=E2=80=9D? B= ecause routers
>=C2=A0 =C2=A0 =C2=A0decrement the hop limit on packets passing through<= br> >=C2=A0 =C2=A0 =C2=A0them, and discard packets where the hop count
>=C2=A0 =C2=A0 =C2=A0decrements to zero. It is impossible to decrement >=C2=A0 =C2=A0 =C2=A0a one-byte counter to 255 without passing through >=C2=A0 =C2=A0 =C2=A0zero, because 255 is the maximum value such a count= er
>=C2=A0 =C2=A0 =C2=A0can have. So the value 255 means that the packet mu= st
>=C2=A0 =C2=A0 =C2=A0have been generated on the local link."
>
> Probably would be better expressed as "must have originated on th= e
> local link".
>
> Regards, K.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~
> Karl Auer (k= auer@biplane.com.au)
> http://www.biplane.com.au/kauer
> http://twitter.com/kauer389
>
> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170
> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--
<= div dir=3D"ltr">

Gyan= =C2=A0 Mishra

Network Engineering & Technology= =C2=A0

Verizon=C2=A0

Silver Spring, MD 20= 904

Phone: 301 502-1347

<= font size=3D"1" color=3D"#000000" face=3D"georgia, serif">Email: gyan.s.mishra@verizon.= com



--00000000000036088e05a0d15eb1-- From nobody Sat Mar 14 07:32:19 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AE93A082C; Sat, 14 Mar 2020 07:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMozQk-Mls82; Sat, 14 Mar 2020 07:32:10 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E129E3A079A; Sat, 14 Mar 2020 07:31:54 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id c8so12014582ilm.1; Sat, 14 Mar 2020 07:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=91j3b5bZ0/lbYXVErDpz6zoCX3WVhsnrj38XZ4nz70U=; b=vRfmadtTbz91OBbLhb7R1xslaWfpWK2CXmks6/rTx/yRL4jDc36rrdsXYcS8zV0+yc qm7O9As1jDyVoC87dsfohe5UcZ7hF/M8cN2WdYMrMAPPbZFqZAaKGx0wz6NaCiIi+BcO N5btJRTJ2G8pzaS3kxA7XzSibQHLW4XkD5HGVHOp/Nmwz9GxAGH2f3qcxJ5fa7cud4T/ hYgFLJpnQhiBEIx886UXfwlf7igzbnuf6w9YJPQHZsjt+XvxSpwnWVySntTA5SJXhDuZ i/6+YDSJ0b9UTvXypwMzKTKW4xjUzyBTkio+zK51SReFYWFyS4u6zOB47eOUBscRnjUr AKGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=91j3b5bZ0/lbYXVErDpz6zoCX3WVhsnrj38XZ4nz70U=; b=Bs6Bmv6TkWQXv/NvBdLb3h1/jateP/HUg4WKgysqDbum1sY0yN1XVd/v1Gdvpv9atE D+HaVayJTB7XLY1QYsqRD8Gv6foX1l9klcp7JXc0/B2rBNm/W2lYYFxQo+IcF7Sv2nOn FjVzT7pXOR8kn8OD1WG6135mcT1vKfMJhGZdXkvwEDLVfWllAxeR840o8wmNHj1Ye5F3 uQZCvVmOJSJZYU+dnxJyk/oZwCEr9VGcroem8eFKqPCJ/9cI/krMDO+kJ1cS6Bt0ezPp yvJBeCw4nORRFfW5ys+SRKG53C9EDspGXZd/MxO/OlwwkmfL5vzpISdVCtNxWag6tu7i /+QA== X-Gm-Message-State: ANhLgQ1QA4qZNFG5a2iUh3AOvrZXaN2Q5gVJkYxxO/h93xv8moGVTCym vsMGNq9luIelnZyDHBRyMJ8h4NxReF/gS4t+zF+CfD2Y X-Google-Smtp-Source: ADFU+vuojH0M6KRC+CRT41eSE3IFd8QIKX+x/1Xz8bYw/WsAfg87+55JQ182iCTKyriIDoyS8BE2UEE4uV0gPGQH+TM= X-Received: by 2002:a92:5dc7:: with SMTP id e68mr15196270ilg.205.1584196313605; Sat, 14 Mar 2020 07:31:53 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <1584173474.2857.102.camel@biplane.com.au> In-Reply-To: <1584173474.2857.102.camel@biplane.com.au> From: Gyan Mishra Date: Sat, 14 Mar 2020 10:31:43 -0400 Message-ID: To: kauer@biplane.com.au Cc: 6man <6man@ietf.org>, V6 Ops List Content-Type: multipart/alternative; boundary="00000000000086eae705a0d17279" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 14:32:17 -0000 --00000000000086eae705a0d17279 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Makes sense. Thanks Gyan On Sat, Mar 14, 2020 at 4:12 AM Karl Auer wrote: > On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote: > > I always wondered why RFC 4862 states that ND & RD packets have TTL > > 255. > > >From RFC4861: > > "By setting the Hop Limit to 255, Neighbor Discovery > is immune to off-link senders that accidentally or > intentionally send ND messages. In IPv4, off-link > senders can send both ICMP Redirects and Router > Advertisement messages." > > RFC4861 also requires RA and NA packets with any other TTL value to be > silently discarded by any receiving node. > > I can't find my original source, but my notes in a training course I > developed a while ago have this to say about why: > > "Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Because routers > decrement the hop limit on packets passing through > them, and discard packets where the hop count > decrements to zero. It is impossible to decrement > a one-byte counter to 255 without passing through > zero, because 255 is the maximum value such a counter > can have. So the value 255 means that the packet must > have been generated on the local link." > > Probably would be better expressed as "must have originated on the > local link". > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer@biplane.com.au) > http://www.biplane.com.au/kauer > http://twitter.com/kauer389 > > GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170 > Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --00000000000086eae705a0d17279 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Makes sense.
<= br>
Thanks=C2=A0

Gyan

On Sat, Mar 14, 2020 at 4:12 AM Karl Auer <kauer@biplane.com.au> wrote:
On Sat, 2020-03-14 at 02:07 -0400, Gyan M= ishra wrote:
> I always wondered why RFC 4862 states that ND & RD packets have TT= L
> 255.

>From RFC4861:

=C2=A0 =C2=A0"By setting the Hop Limit to 255, Neighbor Discovery
=C2=A0 =C2=A0 is immune to off-link senders that accidentally or
=C2=A0 =C2=A0 intentionally send ND messages.=C2=A0=C2=A0In IPv4, off-link<= br> =C2=A0 =C2=A0 senders can send both ICMP Redirects and Router
=C2=A0 =C2=A0 Advertisement messages."

RFC4861 also requires RA and NA packets with any other TTL value to be
silently discarded by any receiving node.

I can't find my original source, but my notes in a training course I developed a while ago have this to say about why:

=C2=A0 =C2=A0"Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Becaus= e routers
=C2=A0 =C2=A0 decrement the hop limit on packets passing through
=C2=A0 =C2=A0 them, and discard packets where the hop count
=C2=A0 =C2=A0 decrements to zero. It is impossible to decrement
=C2=A0 =C2=A0 a one-byte counter to 255 without passing through
=C2=A0 =C2=A0 zero, because 255 is the maximum value such a counter
=C2=A0 =C2=A0 can have. So the value 255 means that the packet must
=C2=A0 =C2=A0 have been generated on the local link."

Probably would be better expressed as "must have originated on the
local link".

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@= biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 2561 E9EC D868 E73C 8AF1=C2=A049CF EE50 4B1D CCA1 5170
Old fingerprint: 8D08 9CAA 649A AFEF E862=C2=A0062A 2E97 42D4 A2A0 616D


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--
<= div dir=3D"ltr">

Gyan= =C2=A0 Mishra

Network Engineering & Technology= =C2=A0

Verizon=C2=A0

Silver Spring, MD 20= 904

Phone: 301 502-1347

<= font size=3D"1" color=3D"#000000" face=3D"georgia, serif">Email: gyan.s.mishra@verizon.= com



--00000000000086eae705a0d17279-- From nobody Sat Mar 14 10:38:44 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40443A087E; Sat, 14 Mar 2020 10:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_tm6zGpRO_m; Sat, 14 Mar 2020 10:38:30 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37543A087C; Sat, 14 Mar 2020 10:38:30 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id p1so12219666ils.12; Sat, 14 Mar 2020 10:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yF9FXEox+szDDTYkBnmz6rea0a+cg0hXBzgwq4DC+1Q=; b=hXs8BaYlGsZeQQxMyqol9SX/Kw+LaFBclV+JhpiDFpbygPAmlqBqC7xmWllhkAvqbK Makv0V6Rr78XKTIKjkr64ROOdphliWJiB2NhLJ4jRU3hVAYE0V+pqpp3LKiiSV8SVLWq iLra1Ba7H1AFwiDrRgSXpIES594aEPM47BQ6JPuSrTENcvP4/gtd/kbQEFugke6eB0ec ulf3yr0Ow+yZvxZhUT+LqgzKOjwkCrizDzoDaoLuvwn1K5BHaXWmGxfoWMKd2EmY5a79 57kykziOE0USV2r36HmDZSBNMDV7256623YK/Aba9vRmucFuDOWi+brrJzmPpimU9ZgF lWMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yF9FXEox+szDDTYkBnmz6rea0a+cg0hXBzgwq4DC+1Q=; b=thodsGoA9kPj5OIbMYt53PUOrN4JQABk+kn721HHh0ELgxNpkKCuweH+vOu11cuieE YP3dA5pWlq7k6xOJIiFEO4sTwu3caj4EtVWRxzjxg/MxK90sqNGvTXJzcWejgLxYr3X/ iy70LXDCXUDapl/I3ZiNbyn4FxmbXpBKbB7BhLWtmhchVeg2UKZPx2Of2hCSDRx4LBSX CKvSdQGByexQU11QeSKd7EtiPYLvX11TXYZty6MO7MOMr6yT3mlIMeq3V5/YoqFz3kKH CCT4WXbvK9Um97KNSxjV7QZ1MtHjbTb/kJhphBJr/KNd4gIVE+5pBTMFbRRdD2i77CeW TnaQ== X-Gm-Message-State: ANhLgQ22mHIXVHY36PYzItuTSX93f1nYFMJSGeNT8VBeBVPRVN4tkgVm lukNytYfFsHaOwhdNtIGqI7Z14nasqxVUEMYCFk= X-Google-Smtp-Source: ADFU+vtxFWatpKiPo0pcMYTvO3F3GSJ20U8FE/7KHAiA+EJFn8z6zq+4EGUn081e7DyhK3b4Dz4Kj8oyYykiIvDnvpA= X-Received: by 2002:a92:8352:: with SMTP id f79mr15109189ild.58.1584207509803; Sat, 14 Mar 2020 10:38:29 -0700 (PDT) MIME-Version: 1.0 References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <1584173474.2857.102.camel@biplane.com.au> In-Reply-To: From: Gyan Mishra Date: Sat, 14 Mar 2020 13:38:19 -0400 Message-ID: To: Toerless Eckert , Tony Przygienda , kauer@biplane.com.au Cc: 6man <6man@ietf.org>, V6 Ops List Content-Type: multipart/alternative; boundary="000000000000df56c705a0d40dfd" Archived-At: Subject: Re: [v6ops] IPv6 link-local traffic questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 17:38:33 -0000 --000000000000df56c705a0d40dfd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Toreless & Tony I read through the draft for BIER over IPv6. https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06 So since the BIER header bitmask that denotes the BFERs in the Domain to replicate the multicast packets is encoded in the DestOp processed by the BFER, the packets should not be forwarded past the BFER is my guess is with ttl 255. With IPv6 ND with ttl 255 example the packet can be forwarded past the adjacent node but I have not seen that happen. I believe Jen Linkova on this thread has seen that. Since the BFER dest options has to have the BIER bit mask encoding or the packet is dropped I believe is your security protection from forwarding past the BIER with 255 ttl if you decided to go that route. Under BIERv6 packet processing should help if ttl 255 is used to prevent forwarding outside of bier domain A packet having a 'BIER Specific Handling' indication but not having a BIER option is supposed to be a wrong packet or an ICMPv6 packet, and the process can be refered to the example in section 3.2 . A packet not having a 'BIER Specific Handling' indication but having a BIER option SHOULD be processed normally as unicast forwarding procedures, which may be a behavior of drop, or send to CPU, or other behaviors in existing implementations. Under 5.3 security considerations should also help with ttl 255 and forwarding outside of BIER domain For a router incapable of BIERv6, such BIERv6 packet will not be processed by the procedure described in this document, but be processed as normal IPv6 packet with unknown option, and the existing security considerations for handling IPv6 options apply. Possible way of handling IPv6 packets with BIER option may be send to CPU for slow path processing, with rate-limiting, or be discarded according to the local policy. For a router capable of BIERv6, such BIERv6 packet MUST NOT be forwarded, but should be processed as a normal IPv6 packet with unknown option, or additionally and optionally be countered and logged if the router is capable of doing so. Kind regards Gyan On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra wrote: > > Makes sense. > > Thanks > > Gyan > > On Sat, Mar 14, 2020 at 4:12 AM Karl Auer wrote: > >> On Sat, 2020-03-14 at 02:07 -0400, Gyan Mishra wrote: >> > I always wondered why RFC 4862 states that ND & RD packets have TTL >> > 255. >> >> >From RFC4861: >> >> "By setting the Hop Limit to 255, Neighbor Discovery >> is immune to off-link senders that accidentally or >> intentionally send ND messages. In IPv4, off-link >> senders can send both ICMP Redirects and Router >> Advertisement messages." >> >> RFC4861 also requires RA and NA packets with any other TTL value to be >> silently discarded by any receiving node. >> >> I can't find my original source, but my notes in a training course I >> developed a while ago have this to say about why: >> >> "Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Because routers >> decrement the hop limit on packets passing through >> them, and discard packets where the hop count >> decrements to zero. It is impossible to decrement >> a one-byte counter to 255 without passing through >> zero, because 255 is the maximum value such a counter >> can have. So the value 255 means that the packet must >> have been generated on the local link." >> >> Probably would be better expressed as "must have originated on the >> local link". >> >> Regards, K. >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Karl Auer (kauer@biplane.com.au) >> http://www.biplane.com.au/kauer >> http://twitter.com/kauer389 >> >> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170 >> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: gyan.s.mishra@verizon.com > > > > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com --000000000000df56c705a0d40dfd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Toreless & Tony=C2=A0

I read through the draft for BIER o= ver IPv6.


So since the BIER header bitmask that denotes the BFE= Rs in the Domain to replicate the multicast packets is encoded in the DestO= p processed by the BFER, the packets should not be forwarded past the BFER = is my guess is with ttl 255.=C2=A0 With IPv6 ND with ttl 255 example the pa= cket can be forwarded past the adjacent node but I have not seen that happe= n.=C2=A0 I believe Jen Linkova on this thread has seen that. Since the BFER= dest options has to have the BIER bit mask encoding or the packet is dropp= ed I believe is your security protection from forwarding past the BIER with= 255 ttl if you decided to go that route.

=
Under BIERv6 packet processing should help if ttl 255 is = used to prevent forwarding outside of bier domain=C2=A0

A packet having a &#=
39;BIER Specific Handling' indication but not having
   a BIER option is supposed to be a wrong packet or an ICMPv6 packet,
   and the process can be refered to the example in section 3=
.2.

   A packet not having a 'BIER Specific Handling' indication but ha=
ving
   a BIER option SHOULD be processed normally as unicast forwarding
   procedures, which may be a behavior of drop, or send to CPU, or other
   behaviors in existing implementations.

=
Under 5.3 security considerations should also help = with ttl 255 and forwarding outside of BIER domain
<= br>
For a router incapable of=
 BIERv6, such BIERv6 packet will not be
   processed by the procedure described in this document, but be
   processed as normal IPv6 packet with unknown option, and the existing
   security considerations for handling IPv6 options apply.  Possible
   way of handling IPv6 packets with BIER option may be send to CPU for
   slow path processing, with rate-limiting, or be discarded according
   to the local policy.

   For a router capable of BIERv6, such BIERv6 packet MUST NOT be
   forwarded, but should be processed as a normal IPv6 packet with
   unknown option, or additionally and optionally be countered and
   logged if the router is capable of doing so.

Kind regards=C2=A0
Gyan

On Sat, Mar 14, 2020 at 10:31 AM Gyan Mishra = <hayabusagsm@gmail.com> = wrote:

Makes sense.

T= hanks=C2=A0

G= yan

On Sat, Mar 14, 2020 at 4:12 AM Karl Auer <kauer@biplane.com.au> wrote:
On Sat, 2020-03-14 at 02:07 -0400, Gyan Mi= shra wrote:
> I always wondered why RFC 4862 states that ND & RD packets have TT= L
> 255.

>From RFC4861:

=C2=A0 =C2=A0"By setting the Hop Limit to 255, Neighbor Discovery
=C2=A0 =C2=A0 is immune to off-link senders that accidentally or
=C2=A0 =C2=A0 intentionally send ND messages.=C2=A0=C2=A0In IPv4, off-link<= br> =C2=A0 =C2=A0 senders can send both ICMP Redirects and Router
=C2=A0 =C2=A0 Advertisement messages."

RFC4861 also requires RA and NA packets with any other TTL value to be
silently discarded by any receiving node.

I can't find my original source, but my notes in a training course I developed a while ago have this to say about why:

=C2=A0 =C2=A0"Why does 255 mean =E2=80=9Clocal source=E2=80=9D? Becaus= e routers
=C2=A0 =C2=A0 decrement the hop limit on packets passing through
=C2=A0 =C2=A0 them, and discard packets where the hop count
=C2=A0 =C2=A0 decrements to zero. It is impossible to decrement
=C2=A0 =C2=A0 a one-byte counter to 255 without passing through
=C2=A0 =C2=A0 zero, because 255 is the maximum value such a counter
=C2=A0 =C2=A0 can have. So the value 255 means that the packet must
=C2=A0 =C2=A0 have been generated on the local link."

Probably would be better expressed as "must have originated on the
local link".

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@= biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 2561 E9EC D868 E73C 8AF1=C2=A049CF EE50 4B1D CCA1 5170
Old fingerprint: 8D08 9CAA 649A AFEF E862=C2=A0062A 2E97 42D4 A2A0 616D


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--

Gyan=C2=A0 Mishra

Network Engineering & Technology=C2=A0

V= erizon=C2=A0

Silver Spring, MD 20904

Phon= e: 301 502-1347

Email: gyan.s.mishra@verizon.com



=
--
<= div dir=3D"ltr">

Gyan= =C2=A0 Mishra

Network Engineering & Technology= =C2=A0

Verizon=C2=A0

Silver Spring, MD 20= 904

Phone: 301 502-1347

<= font size=3D"1" color=3D"#000000" face=3D"georgia, serif">Email: gyan.s.mishra@verizon.= com



--000000000000df56c705a0d40dfd-- From nobody Sun Mar 15 10:31:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5084D3A1974 for ; Sun, 15 Mar 2020 10:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmYDcor0qZ3q for ; Sun, 15 Mar 2020 10:31:05 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A343E3A1975 for ; Sun, 15 Mar 2020 10:31:04 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id v11so18346682wrm.9 for ; Sun, 15 Mar 2020 10:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Cne8JULs5v4icSbvDlnoRBpSkykzP4ebEuaS/Ce74yg=; b=iPufziioXD/hYrVDl0pqK+0WPBl23KpvCNnd8k0Pg124CcJmzgrTZHTDcDcQFQ4gf1 QI5LDOHptrHww1TQfBP/CIU4IgAGuMDxSW4Hg8LpFfWjv6VYmVoCaBvIPUhCJAX6wTf+ r6Sc0fMgv4jL71ZP0xF6tYyKUTCcP7iPje7z0IMNjYDbkMd1nhStq2cFwlh7wLU0p64o kZ8BQfXuRsU96kIOslP2gHZENSRdVPjJMlZ7tov6kqvGoat3VuL7vgtyTvloRf6o+sgx cBWh01iO2dQx91VLt3lFHf4Fd8VBXIYIIpQZCLykpXtf9J1HV8Ich+UlwxlEBRH3Ugpf Yfww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Cne8JULs5v4icSbvDlnoRBpSkykzP4ebEuaS/Ce74yg=; b=TllG8Xt7hcMTSwzBmvypwiPI5yXq8sHb5WukYAqU7mwCOZpttLRpyXAdTkewSKL7v0 D0mYcVqMaHFnGjLjFwm3wXKAR0VwAHslSN7SB9veFQmUBJZKR3AWrbhmCXT4zkHteccA fuwvmhxy1qCzMfuUj8BDGXlod2K+qlhYdIHTI+lFxxeYpf9NYDID94eDtfvyIfSfEFY0 D8tOkH9hBrmkEU02tBP/Preu6KFKvPSb38w4rve/BlbSrdwJ4hNjhKL4SWjAUtW65yaN fzNyWi5rY0I+ze0+iVjngaBD7MYdIxKgX7p6PriIOw8UYJhCZ1YFB9nrqtPaIN6oWCYr UeoA== X-Gm-Message-State: ANhLgQ0dWTk1oNp0LWJhhZtbp/2E+NLr9PCVCvbidgBj+mej/rOQ68e4 43k9IYbkKOOsT8uGpthKamUVV6E3 X-Google-Smtp-Source: ADFU+vv5nczAOjoG8IFvLIK3V0auTNRQWmPM1K2QzqMV/MteIlaVim8EWsPfK9f8hLQLgKMLCSQOAQ== X-Received: by 2002:adf:d4d1:: with SMTP id w17mr31179809wrk.206.1584293462776; Sun, 15 Mar 2020 10:31:02 -0700 (PDT) Received: from ?IPv6:2600:8802:5900:13c4::105a? ([2600:8802:5900:13c4::105a]) by smtp.gmail.com with ESMTPSA id n1sm45486088wrj.77.2020.03.15.10.31.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Mar 2020 10:31:01 -0700 (PDT) From: Fred Baker Message-Id: <75DB7A3D-74D6-477B-A6C1-57638C070576@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_FC0BD7FA-6904-4C4A-848E-C10883CF92DF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 15 Mar 2020 10:30:58 -0700 In-Reply-To: Cc: v6ops@ietf.org To: JORDI PALET MARTINEZ References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <3567F570-BC40-470E-971B-2368E1ACD80C@gmail.com> <1FC68A89-A5E2-4FF3-836C-5AEC3D295299@delong.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 17:31:06 -0000 --Apple-Mail=_FC0BD7FA-6904-4C4A-848E-C10883CF92DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 12, 2020, at 4:17 AM, JORDI PALET MARTINEZ = wrote: >=20 > 12. IPv4 Exclusion >=20 > If an IPv6-only network or part of it, has strict filtering rules to > avoid IPv4 to be transported on top of IPv6, this should be > explicitly cited. For example, and enterprise LAN, where employees > can't use VPNs, tunnels, or even translations, could be named as > "IPv6-only LAN with IPv4 Exclusion". >=20 > =EF=BB=BFEl 12/3/20 12:04, "JORDI PALET MARTINEZ" = escribi=C3=B3: >=20 > + Any environment where IPv4 usage has been = discontinued and IPv6 is the sole remaining active protocol > OR > + Any environment where IPv4 was never deployed = and IPv6 is the only protocol ever deployed >=20 > It was in response to a statement that IPv6-only could only = mean an environment where IPv4 once existed and had been removed. Sigh. You have heard me say this before, and I'll say it again. This is = me saying it now. "I'm sure we can make this complicated if we try hard enough." To me, and yes, Owen, I'm agreeing with you, an IPv6-only *anything* is = a thing that is only using IPv6. If the character string "IPv4" shows up = somewhere in the definition, it is overly complex. If you want to = discuss an IPv6-only puppy kennel, there are two things that should show = up in the dentition: that it is a puppy kennel, and that it only uses = IPv6 to communicate. --Apple-Mail=_FC0BD7FA-6904-4C4A-848E-C10883CF92DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl5uZlIACgkQEhdRnd2G P+BtrxAAqdG1OyLvXBB/P1ysj33pQkIOwEkPjpOqs4Na5CHp+ZE2smzvdxB+yxN0 AHm9yBWYHbmhBVGxnWFXKtUWAB3db7kHZXzp/txeX5DqtYE4DlRBsujqQxKFdQNc HVLpJJV8Ok/UP8eilpppRIty8NZL/KSsMq61P7gkLrsltnqBmFBt2+7f7O1XcWZd 8BOIk+QR1Qhvf/++vK04Nz0BZKXn1XUdgdyVa/YdUzzXxND1GgQK252yW8zvk7U0 bLfwE5wMorQ9xnobacLDzrwOLhkhMMT0O8qucpmYNBcn51Uu9oUf8n47SRBVIkTj +FOh3jJowvFtbv0E1N5kK1xVgA6UC9uA8SVRQ+wgx0uZTR8G4t8wzvryeDi/Secs A5R57a4i6oXu7gjYAfPgKBxbVdWoUnYWqgcj9JoE4J/1PYIfasqPFGLa4csDP9Hx y56k7XNlVnpMcb2sVQozyBOFs8ElKxFbRcLciFRvlJ3+zA1BsSz7L7nbbV4NLG4h Yz/HaplQwF+MyoTo4EqMTcooldyKj24jgR4QIglE+FR4kMfQeSdRkJ/6ZJtvvelu qFMCQycVt8LybbM9HZ3zQvTro/K58eUWuvRChQ8y5Fg5U8nb6G/Mu4d66YSw0Ubd Y1ezW/JhvA2C6QpV7/Gx8/0YVRiS83FuMihVsBUHoWDsfuhs+/Q= =cGpA -----END PGP SIGNATURE----- --Apple-Mail=_FC0BD7FA-6904-4C4A-848E-C10883CF92DF-- From nobody Sun Mar 15 10:48:20 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8B33A19AF for ; Sun, 15 Mar 2020 10:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgseXgbDKnbN for ; Sun, 15 Mar 2020 10:48:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BE1093A19AD for ; Sun, 15 Mar 2020 10:48:15 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02FHmCuK3861741 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 15 Mar 2020 10:48:13 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Owen DeLong In-Reply-To: <75DB7A3D-74D6-477B-A6C1-57638C070576@gmail.com> Date: Sun, 15 Mar 2020 10:48:12 -0700 Cc: JORDI PALET MARTINEZ , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <3567F570-BC40-470E-971B-2368E1ACD80C@gmail.com> <1FC68A89-A5E2-4FF3-836C-5AEC3D295299@delong.com> <75DB7A3D-74D6-477B-A6C1-57638C070576@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Sun, 15 Mar 2020 10:48:13 -0700 (PDT) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 17:48:18 -0000 > On Mar 15, 2020, at 10:30 , Fred Baker = wrote: >=20 >=20 >=20 >> On Mar 12, 2020, at 4:17 AM, JORDI PALET MARTINEZ = wrote: >>=20 >> 12. IPv4 Exclusion >>=20 >> If an IPv6-only network or part of it, has strict filtering rules to >> avoid IPv4 to be transported on top of IPv6, this should be >> explicitly cited. For example, and enterprise LAN, where employees >> can't use VPNs, tunnels, or even translations, could be named as >> "IPv6-only LAN with IPv4 Exclusion". >>=20 >> =EF=BB=BFEl 12/3/20 12:04, "JORDI PALET MARTINEZ" = escribi=C3=B3: >>=20 >> + Any environment where IPv4 usage has been = discontinued and IPv6 is the sole remaining active protocol >> OR >> + Any environment where IPv4 was never deployed = and IPv6 is the only protocol ever deployed >>=20 >> It was in response to a statement that IPv6-only could only = mean an environment where IPv4 once existed and had been removed. >=20 > Sigh. You have heard me say this before, and I'll say it again. This = is me saying it now. >=20 > "I'm sure we can make this complicated if we try hard enough." >=20 > To me, and yes, Owen, I'm agreeing with you, an IPv6-only *anything* = is a thing that is only using IPv6. If the character string "IPv4" shows = up somewhere in the definition, it is overly complex. If you want to = discuss an IPv6-only puppy kennel, there are two things that should show = up in the dentition: that it is a puppy kennel, and that it only uses = IPv6 to communicate. Fair enough, and I somewhat agree with you, but even that statement runs = into problems if one gets pedantic. IPv6 only surely isn=E2=80=99t = intended to exclude, e.g. UNIX domain sockets, named pipes, etc. In fact, is it even our intent that =E2=80=9CIPv6-only=E2=80=9D should = preclude the use of other non-IP networking protocols? Perhaps: IPv6-only means a system or environment where the only version = of Internet Protocol in use is Version 6. Does that work? Owen From nobody Sun Mar 15 11:44:41 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6813A1A6C for ; Sun, 15 Mar 2020 11:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3dISZ6C3tkx for ; Sun, 15 Mar 2020 11:44:37 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC753A1A68 for ; Sun, 15 Mar 2020 11:44:37 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id r15so18502254wrx.6 for ; Sun, 15 Mar 2020 11:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IICXndy24BfHRUDBIpEifjc6kuGv4xCGykyThiHkRQ8=; b=tF0OPoxk/OJu757IZU8uIQ1tBpk3KjG+lSiVIMXCKohc1KKFBU87DiDCMkHUcO9ptI 2iIvb8bSe9tAvT5zgWe4cvW7mfMoYIUaBtblxBXQSoxrCUJwXJHTf1Si5xekEqcOkG4e HWK2GT6eyoeVmTgTCx/bnbf/HNycc7QBcAQnniPF1pqSievF3biM6a6j+4SCpN5d7SLV UCmwilcDYp1SLNFu7bd3/Wsq/l03hup0XkKdmjl4un/hIbD3DsBuraSX2jymbh2exDOQ PIiyseDri+TsVEdBLeVfcHavrOoyCD9Aj3sxfnzcUVhNOouQxWzbJ900dnp/AwQjLKbn Iq6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IICXndy24BfHRUDBIpEifjc6kuGv4xCGykyThiHkRQ8=; b=genZhMC+AszSF81GnDVLiv3ngEI/7WTM67XwYO+qN0PXp+2n+W9tce43/LBB5HIA2F xIM8WjxjWqfDZsLaWoDIsxdPIuP7XxUkwbESJlDGPrmDTl89/BWEcDwTNjlnCFh9oI7h hCMq6j1LacWdIlQKLKkL5AJlCuy4xgq/cwRxTqDHMqYNu9tH/wP8Czj1IWYAxBMXLnMj UiWMx5IxNvRxyK+c2rZYyC6TYSp/AZkycYx3gkBx9oislsMsZ3t+DpkxHJG44P1g4/V/ cGhI5lefxBjFH6mx1PNlfQYB/NQw5j4UK9Mbz2lMSpEv7a3AsR05MFR4Da5WTG1kqcdY 7ong== X-Gm-Message-State: ANhLgQ2lWRTE3PpYXq6l7BITh59P1ToPJ/LMYJEI5PoNbj84lIkS1rVB o+cNZW3tRbWNqkoGE3hVGdbhWuIy X-Google-Smtp-Source: ADFU+vumIZ/+0swzWL/AilUyIIYvFVCJ6Ckp6peUfReC38VUH4VgTZD16qvdlDPowW/DSdh4qzMnSQ== X-Received: by 2002:adf:e6ce:: with SMTP id y14mr26352421wrm.152.1584297875595; Sun, 15 Mar 2020 11:44:35 -0700 (PDT) Received: from ?IPv6:2600:8802:5900:13c4::105b? ([2600:8802:5900:13c4::105b]) by smtp.gmail.com with ESMTPSA id v2sm21015974wme.2.2020.03.15.11.44.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Mar 2020 11:44:34 -0700 (PDT) From: Fred Baker Message-Id: <94287DAC-7D43-4BBE-B49B-9C6EE120234F@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5B8AF47B-9AAE-46AD-9C15-46BA5F6C1B7C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 15 Mar 2020 11:44:31 -0700 In-Reply-To: Cc: JORDI PALET MARTINEZ , v6ops@ietf.org To: Owen DeLong References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <3567F570-BC40-470E-971B-2368E1ACD80C@gmail.com> <1FC68A89-A5E2-4FF3-836C-5AEC3D295299@delong.com> <75DB7A3D-74D6-477B-A6C1-57638C070576@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 18:44:40 -0000 --Apple-Mail=_5B8AF47B-9AAE-46AD-9C15-46BA5F6C1B7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 15, 2020, at 10:48 AM, Owen DeLong wrote: >=20 > Perhaps: IPv6-only means a system or environment where the only = version of Internet Protocol in use is Version 6. Close enough for government work :-) --Apple-Mail=_5B8AF47B-9AAE-46AD-9C15-46BA5F6C1B7C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAl5ud48ACgkQEhdRnd2G P+DTERAAp8b4FoRWWn51EGiSxvULG+ouRDkco9QtIsxS7k78q4DsDnpNnosd0V2s sZKHw9kQSGY0x1n2NM3SHVLhNnv8WZQ1DDp6/6YauqLRJSoHnhR6jnIMEW6Kk2zA UmP7XRv1zZrpZoZE1fntuLU7O7SY0PueJqZbgKbnKtczTdlVW0mD4Aivqfl2j3Wl ghIWAqOQftSKE6C7xpMNbf/6hfeDpRUVsicRzKeCLRQLs5rJHvB/d6gmTDDEBrpi RIJ5MXA4R3JmDwMrvzy17NB2Yl1Rm/c+TBAniB1TyCVekM4PekMBJYi++aFdSdLD 6jt1gQJPi8PZFnNdOYdxNZPN2DHvaXI2PdynfXtuBqVIAJwWQs7sEtzvjH/jxrQ6 iVm3xHZTb54NRLmb/QLaPwC0uZOq8k2vasahpH+ONiix+/zO+05Qv2F5RqgYhzGS ITJacyNIi5y7UcX5cbojzamhdm0bEmNUgC5v3r3HRQ0znI42tD/3xZqy9KRZ8L9W OzN/6kNN600zs4waDx2siUeMxKXwU0a16gLhjiC+h4G74PH7g9RBpJjndKZfPZoC Pr82sx4TiP60D9WFVfCJ6XKhsnFRdkmXsqPxxdTALfAJjFuEE2OKIknYBVI6mouU hCpc7H1AXYGOXSzAps/mTOB2EuEPHN9D8ChBmj2ttkQXImoo1Vk= =EHqY -----END PGP SIGNATURE----- --Apple-Mail=_5B8AF47B-9AAE-46AD-9C15-46BA5F6C1B7C-- From nobody Sun Mar 15 14:08:31 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9B93A1C59 for ; Sun, 15 Mar 2020 14:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxDB-ZLmm7l5 for ; Sun, 15 Mar 2020 14:08:28 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF45B3A1C58 for ; Sun, 15 Mar 2020 14:08:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02FL8QZn017240 for ; Sun, 15 Mar 2020 22:08:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 12F18202E7B for ; Sun, 15 Mar 2020 22:08:26 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 09756200DAB for ; Sun, 15 Mar 2020 22:08:26 +0100 (CET) Received: from [10.8.113.150] ([10.8.113.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02FL8ONR007691 for ; Sun, 15 Mar 2020 22:08:25 +0100 To: v6ops@ietf.org References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <3567F570-BC40-470E-971B-2368E1ACD80C@gmail.com> <1FC68A89-A5E2-4FF3-836C-5AEC3D295299@delong.com> <75DB7A3D-74D6-477B-A6C1-57638C070576@gmail.com> From: Alexandre Petrescu Message-ID: <6a3c0822-64af-9435-b0e7-764854d73810@gmail.com> Date: Sun, 15 Mar 2020 22:08:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 21:08:30 -0000 Le 15/03/2020 à 18:48, Owen DeLong a écrit : > >> On Mar 15, 2020, at 10:30 , Fred Baker wrote: >> >> >> >>> On Mar 12, 2020, at 4:17 AM, JORDI PALET MARTINEZ wrote: >>> >>> 12. IPv4 Exclusion >>> >>> If an IPv6-only network or part of it, has strict filtering rules to >>> avoid IPv4 to be transported on top of IPv6, this should be >>> explicitly cited. For example, and enterprise LAN, where employees >>> can't use VPNs, tunnels, or even translations, could be named as >>> "IPv6-only LAN with IPv4 Exclusion". >>> >>> El 12/3/20 12:04, "JORDI PALET MARTINEZ" escribió: >>> >>> + Any environment where IPv4 usage has been discontinued and IPv6 is the sole remaining active protocol >>> OR >>> + Any environment where IPv4 was never deployed and IPv6 is the only protocol ever deployed >>> >>> It was in response to a statement that IPv6-only could only mean an environment where IPv4 once existed and had been removed. >> Sigh. You have heard me say this before, and I'll say it again. This is me saying it now. >> >> "I'm sure we can make this complicated if we try hard enough." >> >> To me, and yes, Owen, I'm agreeing with you, an IPv6-only *anything* is a thing that is only using IPv6. If the character string "IPv4" shows up somewhere in the definition, it is overly complex. If you want to discuss an IPv6-only puppy kennel, there are two things that should show up in the dentition: that it is a puppy kennel, and that it only uses IPv6 to communicate. > Fair enough, and I somewhat agree with you, but even that statement runs into problems if one gets pedantic. IPv6 only surely isn’t intended to exclude, e.g. UNIX domain sockets, named pipes, etc. > > In fact, is it even our intent that “IPv6-only” should preclude the use of other non-IP networking protocols? > > Perhaps: IPv6-only means a system or environment where the only version of Internet Protocol in use is Version 6. works for me. Alex > > Does that work? > > Owen > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Mar 15 16:33:00 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E283A1E2D for ; Sun, 15 Mar 2020 16:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.11 X-Spam-Level: X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMraxnYi74IP for ; Sun, 15 Mar 2020 16:32:56 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C9C3A0FB1 for ; Sun, 15 Mar 2020 16:32:56 -0700 (PDT) Received: by mail-io1-f46.google.com with SMTP id v3so15291258iom.13 for ; Sun, 15 Mar 2020 16:32:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5qKxL/NrCBSYjyTBXemOspoIuGvcMkb3J04gBmR+6sM=; b=VV1Kb6G8/G6ygRSqg11YPr4oCRoAbAHxlBVq4MCvj8GJ4XQoluEeIEiA7W4E0bjpph wPBjuKx1r/CPX7LmB/c/QK3CNIAucrPXcAsgq+zLRBOau2n/8NQFvpqH9W8InnDLs489 loFoaQ1JVoJ4PlJ01Dx6Ccqj1asnrBFLZ2vfDzdGMYZauTdAAM23Ajz3USIlHuk7rXQU 2edUPCQA8Jz73x3I0y0deRGAXJRhwi6xcyrpz5UGTmYHPP8GWJg9yLmDE1DtyBPyHeJ6 n7uO+0PiAiPBSbSb1bX7mALejIRTO1jyr+c34LLSaXbcJYWmquUlfyA0InSCvy8Uc9dR blzA== X-Gm-Message-State: ANhLgQ1BF5fisSwpOFii+YXmATmZkvEc/UYONFVuOwCol3EuBR3p+kn/ Gftxmk0KxVYG0JD752GoWRfs36JVx7SlpTX3GXc= X-Google-Smtp-Source: ADFU+vtnw9H0lesBFENpvbuCGFfXrPWYkDUzYKHMFRFadaleMge6AfKDVXo3wtc8v9Cw06ERFqZeC6fId6iRldmB38w= X-Received: by 2002:a5e:dc04:: with SMTP id b4mr18607579iok.166.1584315175332; Sun, 15 Mar 2020 16:32:55 -0700 (PDT) MIME-Version: 1.0 References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> In-Reply-To: From: Matthew Petach Date: Sun, 15 Mar 2020 16:32:43 -0700 Message-ID: To: Owen DeLong Cc: Alexandre Petrescu , v6ops@ietf.org Content-Type: multipart/alternative; boundary="0000000000003cf11d05a0ed1fe6" Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 23:32:59 -0000 --0000000000003cf11d05a0ed1fe6 Content-Type: text/plain; charset="UTF-8" On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong wrote: > > On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > > Is facebook a network? I thought of it like a server farm. > > How does one run a distributed server farm throughout the world without > connecting it with a network? Am I missing something? > I believe for a very long time, that would have accurately described Akamai. Until their announcement, long after they had established themselves in the marketplace, that they were going to deploy a network: https://pc.nanog.org/static/published/meetings/NANOG71/1532/20171003_Kaufmann_Lightning_Talk_Akamai_v1.pdf Matt --0000000000003cf11d05a0ed1fe6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 6, 2020 = at 11:54 AM Owen DeLong <owen@delong.= com> wrote:
> On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com= > wrote:
> Is facebook a network?=C2=A0 I thought of it like a server farm.

How does one run a distributed server farm throughout the world without con= necting it with a network? Am I missing something?
I believe for a very long time, that would have accurately desc= ribed Akamai.

Until their announcement, long after= they had established themselves in the marketplace, that they were going t= o deploy a network: https://pc.= nanog.org/static/published/meetings/NANOG71/1532/20171003_Kaufmann_Lightnin= g_Talk_Akamai_v1.pdf

Matt
=C2=A0
--0000000000003cf11d05a0ed1fe6-- From nobody Mon Mar 16 00:06:08 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C4C3A1FF3 for ; Mon, 16 Mar 2020 00:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZiqg04mCQdJ for ; Mon, 16 Mar 2020 00:06:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD133A10D2 for ; Mon, 16 Mar 2020 00:06:02 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02G75xag4057293 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Mar 2020 00:05:59 -0700 From: Owen DeLong Message-Id: <8630BF2A-9831-44EE-8CA3-0C3647E86EDE@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4E3B1C1B-0328-444C-BE45-A7701E22A1D9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Mar 2020 00:05:59 -0700 In-Reply-To: Cc: Alexandre Petrescu , v6ops@ietf.org To: Matthew Petach References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 16 Mar 2020 00:06:00 -0700 (PDT) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 07:06:07 -0000 --Apple-Mail=_4E3B1C1B-0328-444C-BE45-A7701E22A1D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 15, 2020, at 16:32 , Matthew Petach = wrote: >=20 >=20 >=20 > On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong > wrote: > > On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu = > = wrote: > > Is facebook a network? I thought of it like a server farm. >=20 > How does one run a distributed server farm throughout the world = without connecting it with a network? Am I missing something? >=20 > I believe for a very long time, that would have accurately described = Akamai. Akamai didn=E2=80=99t run a backbone. I=E2=80=99d argue that they did = run many rather sizable networks. > Until their announcement, long after they had established themselves = in the marketplace, that they were going to deploy a network: = https://pc.nanog.org/static/published/meetings/NANOG71/1532/20171003_Kaufm= ann_Lightning_Talk_Akamai_v1.pdf = Oh, I=E2=80=99m very familiar with that particular project=E2=80=A6 It = was in it=E2=80=99s startup hey day during my tenure in Mr. Kaufmann=E2=80= =99s group. That was Akamai building a backbone to connect many (not = nearly all) of their networks together. I stand by my original statement. One cannot (usefully) run a server = farm without a network. Network !=3D backbone. Owen --Apple-Mail=_4E3B1C1B-0328-444C-BE45-A7701E22A1D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 15, 2020, at 16:32 , Matthew Petach <mpetach@netflight.com> wrote:



On Fri, Mar 6, 2020 at 11:54 AM Owen = DeLong <owen@delong.com> wrote:
> On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> Is facebook a network?  I thought of it like a server farm.

How does one run a distributed server farm throughout the world without = connecting it with a network? Am I missing something?

I believe for a very long time, that would have accurately = described Akamai.

Akamai didn=E2=80=99t run a backbone. I=E2=80=99d argue = that they did run many rather sizable networks.

Until their announcement, long = after they had established themselves in the marketplace, that they were = going to deploy a network: https://pc.nanog.org/static/published/meetings/NANOG71/1532/201= 71003_Kaufmann_Lightning_Talk_Akamai_v1.pdf

Oh, I=E2=80=99m very familiar = with that particular project=E2=80=A6 It was in it=E2=80=99s startup hey = day during my tenure in Mr. Kaufmann=E2=80=99s group. That was Akamai = building a backbone to connect many (not nearly all) of their networks = together.

I stand by my original = statement. One cannot (usefully) run a server farm without a network. = Network !=3D backbone.

Owen

= --Apple-Mail=_4E3B1C1B-0328-444C-BE45-A7701E22A1D9-- From nobody Mon Mar 16 04:03:12 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF3D3A22D0 for ; Mon, 16 Mar 2020 04:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.67 X-Spam-Level: X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XPDxnr6KuSm for ; Mon, 16 Mar 2020 04:03:08 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E353A22CD for ; Mon, 16 Mar 2020 04:03:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02GB31le022142; Mon, 16 Mar 2020 12:03:01 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CFF4A2030B5; Mon, 16 Mar 2020 12:03:01 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BD9E02019D8; Mon, 16 Mar 2020 12:03:01 +0100 (CET) Received: from [10.8.114.142] ([10.8.114.142]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02GB3093031078; Mon, 16 Mar 2020 12:03:01 +0100 To: Owen DeLong , Matthew Petach Cc: v6ops@ietf.org References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <8630BF2A-9831-44EE-8CA3-0C3647E86EDE@delong.com> From: Alexandre Petrescu Message-ID: <7d173149-8fc1-b0db-26af-fe5db1954386@gmail.com> Date: Mon, 16 Mar 2020 12:03:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <8630BF2A-9831-44EE-8CA3-0C3647E86EDE@delong.com> Content-Type: multipart/alternative; boundary="------------20123FB17D54B60A8CBB209B" Content-Language: fr Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 11:03:11 -0000 This is a multi-part message in MIME format. --------------20123FB17D54B60A8CBB209B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 16/03/2020 à 08:05, Owen DeLong a écrit : > > >> On Mar 15, 2020, at 16:32 , Matthew Petach > > wrote: >> >> >> >> On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong > > wrote: >> >> > On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu >> > > wrote: >> > Is facebook a network?  I thought of it like a server farm. >> >> How does one run a distributed server farm throughout the world >> without connecting it with a network? Am I missing something? >> >> >> I believe for a very long time, that would have accurately described >> Akamai. > > Akamai didn’t run a backbone. I’d argue that they did run many rather > sizable networks. > >> Until their announcement, long after they had established themselves >> in the marketplace, that they were going to deploy a network: >> https://pc.nanog.org/static/published/meetings/NANOG71/1532/20171003_Kaufmann_Lightning_Talk_Akamai_v1.pdf > > Oh, I’m very familiar with that particular project… It was in it’s > startup hey day during my tenure in Mr. Kaufmann’s group. That was > Akamai building a backbone to connect many (not nearly all) of their > networks together. > > I stand by my original statement. One cannot (usefully) run a server > farm without a network. Network != backbone. I agree a server farm needs a network.  But that network might be a switched Ethernet with VLANs in a large building, or it might be made of long haul links (ATM, FDDI, multi-Gigabit Ethernet fiber). In the first case (call it VLAN) it is highly possible that VLAN in a building, or a set of close by buildings, are IPv6 only, and no IPv4. But if the facebook system is a geographically distributed server farm with a large network, it might be that at some point the data is carried on IPv4 even though it is IPv6 over IPv4. From an end user perspective it is hard to find out on what is transported her data: IPv4, VLAN, gigabit Ethernet, whatever. Because traceroute does not show this (some times one can see somethings about ipv4 or ipv6 acronyms in the name of the hosts, but rarely). But the builders of these networks do know whether or not that is carried in IPv4, or in MPLS, or so.  It is them that could say what is there, underlying. Alex Alex > > Owen > --------------20123FB17D54B60A8CBB209B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Le 16/03/2020 à 08:05, Owen DeLong a écrit :


On Mar 15, 2020, at 16:32 , Matthew Petach <mpetach@netflight.com> wrote:



On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong <owen@delong.com> wrote:
> On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> Is facebook a network?  I thought of it like a server farm.

How does one run a distributed server farm throughout the world without connecting it with a network? Am I missing something?

I believe for a very long time, that would have accurately described Akamai.

Akamai didn’t run a backbone. I’d argue that they did run many rather sizable networks.

Until their announcement, long after they had established themselves in the marketplace, that they were going to deploy a network: https://pc.nanog.org/static/published/meetings/NANOG71/1532/20171003_Kaufmann_Lightning_Talk_Akamai_v1.pdf

Oh, I’m very familiar with that particular project… It was in it’s startup hey day during my tenure in Mr. Kaufmann’s group. That was Akamai building a backbone to connect many (not nearly all) of their networks together.

I stand by my original statement. One cannot (usefully) run a server farm without a network. Network != backbone.


I agree a server farm needs a network.  But that network might be a switched Ethernet with VLANs in a large building, or it might be made of long haul links (ATM, FDDI, multi-Gigabit Ethernet fiber).

In the first case (call it VLAN) it is highly possible that VLAN in a building, or a set of close by buildings, are IPv6 only, and no IPv4.

But if the facebook system is a geographically distributed server farm with a large network, it might be that at some point the data is carried on IPv4 even though it is IPv6 over IPv4.

From an end user perspective it is hard to find out on what is transported her data: IPv4, VLAN, gigabit Ethernet, whatever.  Because traceroute does not show this (some times one can see somethings about ipv4 or ipv6 acronyms in the name of the hosts, but rarely).

But the builders of these networks do know whether or not that is carried in IPv4, or in MPLS, or so.  It is them that could say what is there, underlying.

Alex

Alex


Owen

--------------20123FB17D54B60A8CBB209B-- From nobody Mon Mar 16 12:42:33 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4291F3A0FE3 for ; Mon, 16 Mar 2020 12:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu6ZY576_Hr5 for ; Mon, 16 Mar 2020 12:42:25 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1B43A0FB8 for ; Mon, 16 Mar 2020 12:42:24 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 02GJgMVw193360 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Mar 2020 12:42:22 -0700 From: Owen DeLong Message-Id: <7C4711FE-5C90-4065-950B-FD61B802AE70@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CBA165FA-6326-4EDE-A99C-21D01C4D6199" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Mar 2020 12:42:22 -0700 In-Reply-To: <7d173149-8fc1-b0db-26af-fe5db1954386@gmail.com> Cc: Matthew Petach , v6ops@ietf.org To: Alexandre Petrescu References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <8630BF2A-9831-44EE-8CA3-0C3647E86EDE@delong.com> <7d173149-8fc1-b0db-26af-fe5db1954386@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 16 Mar 2020 12:42:23 -0700 (PDT) Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 19:42:32 -0000 --Apple-Mail=_CBA165FA-6326-4EDE-A99C-21D01C4D6199 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 16, 2020, at 04:03 , Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 16/03/2020 =C3=A0 08:05, Owen DeLong a =C3=A9crit : >>=20 >>=20 >>> On Mar 15, 2020, at 16:32 , Matthew Petach > wrote: >>>=20 >>>=20 >>>=20 >>> On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong > wrote: >>> > On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu = > = wrote: >>> > Is facebook a network? I thought of it like a server farm. >>>=20 >>> How does one run a distributed server farm throughout the world = without connecting it with a network? Am I missing something? >>>=20 >>> I believe for a very long time, that would have accurately described = Akamai. >>=20 >> Akamai didn=E2=80=99t run a backbone. I=E2=80=99d argue that they did = run many rather sizable networks. >>=20 >>> Until their announcement, long after they had established themselves = in the marketplace, that they were going to deploy a network: = https://pc.nanog.org/static/published/meetings/NANOG71/1532/20171003_Kaufm= ann_Lightning_Talk_Akamai_v1.pdf = >> Oh, I=E2=80=99m very familiar with that particular project=E2=80=A6 = It was in it=E2=80=99s startup hey day during my tenure in Mr. = Kaufmann=E2=80=99s group. That was Akamai building a backbone to connect = many (not nearly all) of their networks together. >>=20 >> I stand by my original statement. One cannot (usefully) run a server = farm without a network. Network !=3D backbone. >=20 > I agree a server farm needs a network. But that network might be a = switched Ethernet with VLANs in a large building, or it might be made of = long haul links (ATM, FDDI, multi-Gigabit Ethernet fiber). >=20 > In the first case (call it VLAN) it is highly possible that VLAN in a = building, or a set of close by buildings, are IPv6 only, and no IPv4. >=20 This is just silly=E2=80=A6 For the server farm to be useful, that = =E2=80=9CVLAN=E2=80=9D still needs a larger network in front of it that = eventually makes contact (ideally in multiple diverse ways) with a = larger internet. > But if the facebook system is a geographically distributed server farm = with a large network, it might be that at some point the data is carried = on IPv4 even though it is IPv6 over IPv4. >=20 In talking to Facebook=E2=80=99s engineers, they claim to do v4<->6 = translation at the edge where necessary to talk to IPv4-only clients and = are IPv6-only throughout their datacenters and other networks. I have no reason to doubt the veracity of their claims and indeed = everything I have seen leads me to believe that they would be jumping = for joy if they could shut down those remaining systems supporting IPv4. > =46rom an end user perspective it is hard to find out on what is = transported her data: IPv4, VLAN, gigabit Ethernet, whatever. Because = traceroute does not show this (some times one can see somethings about = ipv4 or ipv6 acronyms in the name of the hosts, but rarely). >=20 While this is a valid and true statement, I=E2=80=99m not sure how it is = relevant to this discussion. > But the builders of these networks do know whether or not that is = carried in IPv4, or in MPLS, or so. It is them that could say what is = there, underlying. >=20 Which is why I base my statements on discussions with them. Were you = assuming I was looking at this from my own perspective as an end-user of = facebook? Owen --Apple-Mail=_CBA165FA-6326-4EDE-A99C-21D01C4D6199 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 16, 2020, at 04:03 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

=20 =20


Le 16/03/2020 =C3=A0 08:05, Owen = DeLong a =C3=A9crit :


On Mar 15, 2020, at 16:32 , Matthew Petach = <mpetach@netflight.com> wrote:



On Fri, Mar 6, = 2020 at 11:54 AM Owen DeLong <owen@delong.com> wrote:
> On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu = <alexandre.petrescu@gmail.com> wrote:
> Is facebook a network?  I thought of it = like a server farm.

How does one run a distributed server farm throughout the world without connecting it with a network? Am I missing something?

I believe for a very long time, that would have accurately described Akamai.

Akamai didn=E2=80=99t run a backbone. I=E2=80=99d argue that = they did run many rather sizable networks.

Until their announcement, long after they had established themselves in the marketplace, that they were going to deploy a network: https://pc.nanog.org/static/published/meetings/NA= NOG71/1532/20171003_Kaufmann_Lightning_Talk_Akamai_v1.pdf

Oh, I=E2=80=99m very familiar with that particular project=E2=80=A6= It was in it=E2=80=99s startup hey day during my tenure in Mr. = Kaufmann=E2=80=99s group. That was Akamai building a backbone to connect many (not nearly all) of their networks together.

I stand by my original statement. One cannot = (usefully) run a server farm without a network. Network !=3D backbone.


I agree a server farm needs a network.  But = that network might be a switched Ethernet with VLANs in a large building, or it might be made of long haul links (ATM, FDDI, multi-Gigabit Ethernet = fiber).

In the first case (call it VLAN) it is highly = possible that VLAN in a building, or a set of close by buildings, are IPv6 only, and no IPv4.


This is just silly=E2=80=A6 For the server farm to be = useful, that =E2=80=9CVLAN=E2=80=9D still needs a larger network in = front of it that eventually makes contact (ideally in multiple diverse = ways) with a larger internet.

But if the facebook system is a geographically = distributed server farm with a large network, it might be that at some point the data is carried on IPv4 even though it is IPv6 over = IPv4.

In talking to Facebook=E2=80=99s = engineers, they claim to do v4<->6 translation at the edge where = necessary to talk to IPv4-only clients and are IPv6-only throughout = their datacenters and other networks.

I have no reason to doubt the veracity of their = claims and indeed everything I have seen leads me to believe that they = would be jumping for joy if they could shut down those remaining systems = supporting IPv4.

=46rom an end user perspective = it is hard to find out on what is transported her data: IPv4, VLAN, gigabit Ethernet, = whatever.  Because traceroute does not show this (some times one can see somethings about ipv4 or ipv6 acronyms in the name of the hosts, but rarely).

While this is a valid and = true statement, I=E2=80=99m not sure how it is relevant to this = discussion.

But the builders of these = networks do know whether or not that is carried in IPv4, or in MPLS, or so.  It is them that could = say what is there, underlying.

Which is why I base my = statements on discussions with them. Were you assuming I was looking at = this from my own perspective as an end-user of facebook?

Owen

= --Apple-Mail=_CBA165FA-6326-4EDE-A99C-21D01C4D6199-- From nobody Mon Mar 16 13:41:07 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA423A10F0 for ; Mon, 16 Mar 2020 13:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.679 X-Spam-Level: X-Spam-Status: No, score=0.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vuF4jbfkOxm for ; Mon, 16 Mar 2020 13:41:01 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38093A10EC for ; Mon, 16 Mar 2020 13:41:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02GKerpe040125; Mon, 16 Mar 2020 21:40:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3FDE02082A0; Mon, 16 Mar 2020 21:40:53 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2DB192067CF; Mon, 16 Mar 2020 21:40:53 +0100 (CET) Received: from [10.11.240.50] ([10.11.240.50]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 02GKeqwF021145; Mon, 16 Mar 2020 21:40:52 +0100 To: Owen DeLong Cc: Matthew Petach , v6ops@ietf.org References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <8630BF2A-9831-44EE-8CA3-0C3647E86EDE@delong.com> <7d173149-8fc1-b0db-26af-fe5db1954386@gmail.com> <7C4711FE-5C90-4065-950B-FD61B802AE70@delong.com> From: Alexandre Petrescu Message-ID: <3a33c3ce-d2ce-b4b2-091b-d4aff3162461@gmail.com> Date: Mon, 16 Mar 2020 21:40:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <7C4711FE-5C90-4065-950B-FD61B802AE70@delong.com> Content-Type: multipart/alternative; boundary="------------E1DE3E9EDE08125EAF68FA57" Content-Language: fr Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 20:41:06 -0000 This is a multi-part message in MIME format. --------------E1DE3E9EDE08125EAF68FA57 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 16/03/2020 à 20:42, Owen DeLong a écrit : > > >> On Mar 16, 2020, at 04:03 , Alexandre Petrescu >> > >> wrote: >> >> >> Le 16/03/2020 à 08:05, Owen DeLong a écrit : >>> >>> >>>> On Mar 15, 2020, at 16:32 , Matthew Petach >>> > wrote: >>>> >>>> >>>> >>>> On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong >>> > wrote: >>>> >>>> > On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu >>>> >>> > wrote: >>>> > Is facebook a network?  I thought of it like a server farm. >>>> >>>> How does one run a distributed server farm throughout the world >>>> without connecting it with a network? Am I missing something? >>>> >>>> >>>> I believe for a very long time, that would have accurately >>>> described Akamai. >>> >>> Akamai didn’t run a backbone. I’d argue that they did run many >>> rather sizable networks. >>> >>>> Until their announcement, long after they had established >>>> themselves in the marketplace, that they were going to deploy a >>>> network: >>>> https://pc.nanog.org/static/published/meetings/NANOG71/1532/20171003_Kaufmann_Lightning_Talk_Akamai_v1.pdf >>> >>> Oh, I’m very familiar with that particular project… It was in it’s >>> startup hey day during my tenure in Mr. Kaufmann’s group. That was >>> Akamai building a backbone to connect many (not nearly all) of their >>> networks together. >>> >>> I stand by my original statement. One cannot (usefully) run a server >>> farm without a network. Network != backbone. >> >> >> I agree a server farm needs a network.  But that network might be a >> switched Ethernet with VLANs in a large building, or it might be made >> of long haul links (ATM, FDDI, multi-Gigabit Ethernet fiber). >> >> In the first case (call it VLAN) it is highly possible that VLAN in a >> building, or a set of close by buildings, are IPv6 only, and no IPv4. >> > > This is just silly… For the server farm to be useful, that “VLAN” > still needs a larger network in front of it that eventually makes > contact (ideally in multiple diverse ways) with a larger internet. >> >> But if the facebook system is a geographically distributed server >> farm with a large network, it might be that at some point the data is >> carried on IPv4 even though it is IPv6 over IPv4. >> > In talking to Facebook’s engineers, they claim to do v4<->6 > translation at the edge where necessary to talk to IPv4-only clients > and are IPv6-only throughout their datacenters and other networks. that v4<->v6 means facebook network is not IPv6-only Alex > > I have no reason to doubt the veracity of their claims and indeed > everything I have seen leads me to believe that they would be jumping > for joy if they could shut down those remaining systems supporting IPv4. >> >> From an end user perspective it is hard to find out on what is >> transported her data: IPv4, VLAN, gigabit Ethernet, whatever.  >> Because traceroute does not show this (some times one can see >> somethings about ipv4 or ipv6 acronyms in the name of the hosts, but >> rarely). >> > While this is a valid and true statement, I’m not sure how it is > relevant to this discussion. >> >> But the builders of these networks do know whether or not that is >> carried in IPv4, or in MPLS, or so.  It is them that could say what >> is there, underlying. >> > Which is why I base my statements on discussions with them. Were you > assuming I was looking at this from my own perspective as an end-user > of facebook? > > Owen > --------------E1DE3E9EDE08125EAF68FA57 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Le 16/03/2020 à 20:42, Owen DeLong a écrit :


On Mar 16, 2020, at 04:03 , Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


Le 16/03/2020 à 08:05, Owen DeLong a écrit :


On Mar 15, 2020, at 16:32 , Matthew Petach <mpetach@netflight.com> wrote:



On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong <owen@delong.com> wrote:
> On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> Is facebook a network?  I thought of it like a server farm.

How does one run a distributed server farm throughout the world without connecting it with a network? Am I missing something?

I believe for a very long time, that would have accurately described Akamai.

Akamai didn’t run a backbone. I’d argue that they did run many rather sizable networks.

Until their announcement, long after they had established themselves in the marketplace, that they were going to deploy a network: https://pc.nanog.org/static/published/meetings/NANOG71/1532/20171003_Kaufmann_Lightning_Talk_Akamai_v1.pdf

Oh, I’m very familiar with that particular project… It was in it’s startup hey day during my tenure in Mr. Kaufmann’s group. That was Akamai building a backbone to connect many (not nearly all) of their networks together.

I stand by my original statement. One cannot (usefully) run a server farm without a network. Network != backbone.


I agree a server farm needs a network.  But that network might be a switched Ethernet with VLANs in a large building, or it might be made of long haul links (ATM, FDDI, multi-Gigabit Ethernet fiber).

In the first case (call it VLAN) it is highly possible that VLAN in a building, or a set of close by buildings, are IPv6 only, and no IPv4.


This is just silly… For the server farm to be useful, that “VLAN” still needs a larger network in front of it that eventually makes contact (ideally in multiple diverse ways) with a larger internet.

But if the facebook system is a geographically distributed server farm with a large network, it might be that at some point the data is carried on IPv4 even though it is IPv6 over IPv4.

In talking to Facebook’s engineers, they claim to do v4<->6 translation at the edge where necessary to talk to IPv4-only clients and are IPv6-only throughout their datacenters and other networks.


that v4<->v6 means facebook network is not IPv6-only

Alex


I have no reason to doubt the veracity of their claims and indeed everything I have seen leads me to believe that they would be jumping for joy if they could shut down those remaining systems supporting IPv4.

From an end user perspective it is hard to find out on what is transported her data: IPv4, VLAN, gigabit Ethernet, whatever.  Because traceroute does not show this (some times one can see somethings about ipv4 or ipv6 acronyms in the name of the hosts, but rarely).

While this is a valid and true statement, I’m not sure how it is relevant to this discussion.

But the builders of these networks do know whether or not that is carried in IPv4, or in MPLS, or so.  It is them that could say what is there, underlying.

Which is why I base my statements on discussions with them. Were you assuming I was looking at this from my own perspective as an end-user of facebook?

Owen

--------------E1DE3E9EDE08125EAF68FA57-- From nobody Mon Mar 16 14:12:00 2020 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0D73A1146 for ; Mon, 16 Mar 2020 14:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKKa-oaj1DaX for ; Mon, 16 Mar 2020 14:11:55 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323E13A1151 for ; Mon, 16 Mar 2020 14:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1584393112; x=1584997912; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=AJqPGNyQpvi/T4BXjr8oSRhODbbycahVjf AxdvUOW/U=; b=vZyNqK1jJL3AFpGQDfWwKAHgzDqtDb96CMqwNftj1L6tPs98xG hGzua2IPjlZ37My49gzxIYJ7V00S8cgz4vQuPhEPcDtz5O1OqqTYdNj/P+YSDaiW 1kF1ZG8bew6SGD5H5q+jAqtzOTHx6QTJ1RU671HbmqZ8MTfSQAla2SJ88= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 16 Mar 2020 22:11:52 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 16 Mar 2020 22:11:50 +0100 Received: from [10.10.10.100] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000093631.msg for ; Mon, 16 Mar 2020 22:11:49 +0100 X-MDRemoteIP: 2001:470:1f09:495:a83b:e378:3a37:3744 X-MDHelo: [10.10.10.100] X-MDArrival-Date: Mon, 16 Mar 2020 22:11:49 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=134411b52a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Mon, 16 Mar 2020 22:11:47 +0100 From: JORDI PALET MARTINEZ To: Message-ID: <700F43D9-5CBD-4048-84C3-4D324E5EC9F6@consulintel.es> Thread-Topic: [v6ops] About Req for Comments - "Transition to IPv6" References: <7eb4dc25-28a6-4927-2356-846e200681d2@gmail.com> <0791D4B0-8390-48D7-AF0A-CE004EC3224C@consulintel.es> <52b6b9a4f46a49598eccee1b35e5efc5@irs.gov> <89127c25-9c51-c4bb-97ae-3567e80a4c52@gmail.com> <43D0E5A1-E5C5-4ACA-A44D-BC2F67129174@delong.com> <8630BF2A-9831-44EE-8CA3-0C3647E86EDE@delong.com> <7d173149-8fc1-b0db-26af-fe5db1954386@gmail.com> <7C4711FE-5C90-4065-950B-FD61B802AE70@delong.com> <3a33c3ce-d2ce-b4b2-091b-d4aff3162461@gmail.com> In-Reply-To: <3a33c3ce-d2ce-b4b2-091b-d4aff3162461@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3667241507_1396837186" Archived-At: Subject: Re: [v6ops] About Req for Comments - "Transition to IPv6" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 21:11:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3667241507_1396837186 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I can confirm what Owen said. =20 I=E2=80=99ve several friends working at Facebook, and actually I=E2=80=99ve= seen several of their presentations where the DCs are IPv6-only. =20 This was done circa 2014-2015 if I recall correctly. =20 So, following what I=E2=80=99m suggesting FB DC is and IPv6-only DC. =20 They have some transition at the border of the network. So their global net= work is dual-stack, but the DC is IPv6-only. =20 Regards, Jordi @jordipalet =20 =20 =20 El 16/3/20 21:41, "v6ops en nombre de Alexandre Petrescu" escribi=C3=B3: =20 =20 Le 16/03/2020 =C3=A0 20:42, Owen DeLong a =C3=A9crit : =20 On Mar 16, 2020, at 04:03 , Alexandre Petrescu wrote: =20 =20 Le 16/03/2020 =C3=A0 08:05, Owen DeLong a =C3=A9crit : =20 On Mar 15, 2020, at 16:32 , Matthew Petach wrote: =20 =20 =20 On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong wrote: > On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu wrote: > Is facebook a network? I thought of it like a server farm. How does one run a distributed server farm throughout the world without con= necting it with a network? Am I missing something? =20 I believe for a very long time, that would have accurately described Akamai= . =20 Akamai didn=E2=80=99t run a backbone. I=E2=80=99d argue that they did run m= any rather sizable networks. Until their announcement, long after they had established themselves in the= marketplace, that they were going to deploy a network: https://pc.nanog.or= g/static/published/meetings/NANOG71/1532/20171003_Kaufmann_Lightning_Talk_A= kamai_v1.pdf =20 Oh, I=E2=80=99m very familiar with that particular project=E2=80=A6 It was = in it=E2=80=99s startup hey day during my tenure in Mr. Kaufmann=E2=80=99s = group. That was Akamai building a backbone to connect many (not nearly all)= of their networks together. =20 I stand by my original statement. One cannot (usefully) run a server farm w= ithout a network. Network !=3D backbone. =20 I agree a server farm needs a network. But that network might be a switche= d Ethernet with VLANs in a large building, or it might be made of long haul= links (ATM, FDDI, multi-Gigabit Ethernet fiber). In the first case (call it VLAN) it is highly possible that VLAN in a build= ing, or a set of close by buildings, are IPv6 only, and no IPv4. =20 This is just silly=E2=80=A6 For the server farm to be useful, that =E2=80= =9CVLAN=E2=80=9D still needs a larger network in front of it that eventuall= y makes contact (ideally in multiple diverse ways) with a larger internet. But if the facebook system is a geographically distributed server farm with= a large network, it might be that at some point the data is carried on IPv= 4 even though it is IPv6 over IPv4. In talking to Facebook=E2=80=99s engineers, they claim to do v4<->6 transla= tion at the edge where necessary to talk to IPv4-only clients and are IPv6-= only throughout their datacenters and other networks. =20 that v4<->v6 means facebook network is not IPv6-only Alex =20 I have no reason to doubt the veracity of their claims and indeed everythin= g I have seen leads me to believe that they would be jumping for joy if the= y could shut down those remaining systems supporting IPv4. >From an end user perspective it is hard to find out on what is transported = her data: IPv4, VLAN, gigabit Ethernet, whatever. Because traceroute does = not show this (some times one can see somethings about ipv4 or ipv6 acronym= s in the name of the hosts, but rarely). While this is a valid and true statement, I=E2=80=99m not sure how it is re= levant to this discussion. But the builders of these networks do know whether or not that is carried i= n IPv4, or in MPLS, or so. It is them that could say what is there, underl= ying. Which is why I base my statements on discussions with them. Were you assumi= ng I was looking at this from my own perspective as an end-user of facebook= ? =20 Owen =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3667241507_1396837186 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I can confirm what Owen said.

 

= I= =E2=80=99ve several friends working at Facebook, and actually I=E2=80=99ve = seen several of their presentations where the DCs are IPv6-only.=

 

This was done circa 2014-2015 if I recall correctly.

 

<= span lang=3DEN-US style=3D'font-size:12.0pt;color:black'>So, following what= I=E2=80=99m suggesting FB DC is and IPv6-only DC.

 

They have some transition at the border o= f the network. So their global network is dual-stack, but the DC is IPv6-on= ly.

 

Regards,<= /o:p>

Jordi

@jordipalet

 

 

 <= /o:p>

El 16/3/20 21:41, "v6ops en nombre de Alexandre Petrescu" <v6ops-bounces@ietf.org en nombr= e de alexandre.petrescu@gma= il.com> escribi=C3=B3:

 

 

Le 16/03/2020 =C3=A0 20:42, Owen DeLong a =C3=A9crit&n= bsp;:

 



<= /o:p>

On Mar 16, 2020, at 04:03 ,= Alexandre Petrescu <ale= xandre.petrescu@gmail.com> wrote:

 

 

Le 16/03/2020 =C3=A0 08:05, Owen DeLong a =C3=A9crit&nbs= p;:

 =



On Mar 15, 2020, at 16:32 , M= atthew Petach <mpetach@netflight.com> wrote:

 =

<= o:p> 

 

On Fri, Mar 6, 2020 at 11:54 AM Owen DeLong <owen@delong.com> wrote:

> On Mar 5, 2020, at 8:51 AM, Alexandre Petrescu <<= a href=3D"mailto:alexandre.petrescu@gmail.com" target=3D"_blank">alexandre.= petrescu@gmail.com> wrote:
> Is facebook a network?  I th= ought of it like a server farm.

How does one run a distributed serve= r farm throughout the world without connecting it with a network? Am I miss= ing something?

 

I believe for a very long time, that would h= ave accurately described Akamai.

=  

Aka= mai didn=E2=80=99t run a backbone. I=E2=80=99d argue that they did run many= rather sizable networks.



Until their announcement, long after they = had established themselves in the marketplace, that they were going to depl= oy a network: https://pc.nanog.= org/static/published/meetings/NANOG71/1532/20171003_Kaufmann_Lightning_Talk= _Akamai_v1.pdf

 

Oh, I=E2=80=99m v= ery familiar with that particular project=E2=80=A6 It was in it=E2=80=99s s= tartup hey day during my tenure in Mr. Kaufmann=E2=80=99s group. That was A= kamai building a backbone to connect many (not nearly all) of their network= s together.

 

I stand by my original statement. One cannot (usefully) = run a server farm without a network. Network !=3D backbone.

<= /div>

 

I agree a server farm needs a network.  But that net= work might be a switched Ethernet with VLANs in a large building, or it mig= ht be made of long haul links (ATM, FDDI, multi-Gigabit Ethernet fiber).

In the first case (call it VLAN) it i= s highly possible that VLAN in a building, or a set of close by buildings, = are IPv6 only, and no IPv4.

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>This is just silly=E2=80= =A6 For the server farm to be useful, that =E2=80=9CVLAN=E2=80=9D still nee= ds a larger network in front of it that eventually makes contact (ideally i= n multiple diverse ways) with a larger internet.

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

But if the facebook system is a geographically distributed server farm with a large network, it might be th= at at some point the data is carried on IPv4 even though it is IPv6 over IP= v4.

In talking to Facebook=E2=80=99s engineers, they claim to= do v4<->6 translation at the edge where necessary to talk to IPv4-on= ly clients and are IPv6-only throughout their datacenters and other network= s.

&n= bsp;

that v4<->v6 means face= book network is not IPv6-only

Alex

 

I have no= reason to doubt the veracity of their claims and indeed everything I have = seen leads me to believe that they would be jumping for joy if they could s= hut down those remaining systems supporting IPv4.

From an end user perspective it is hard to find out on wh= at is transported her data: IPv4, VLAN, gigabit Ethernet, whatever.  B= ecause traceroute does not show this (some times one can see somethings abo= ut ipv4 or ipv6 acronyms in the name of the hosts, but rarely).<= /p>

While this is a valid and true statement, I=E2=80=99m not sure how it is= relevant to this discussion.