From nobody Mon Apr 1 00:55:07 2019 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 44D7B120091 for ; Mon, 1 Apr 2019 00:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ykayquaBcv-B for ; Mon, 1 Apr 2019 00:55:02 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 9FE8E12008C for ; Mon, 1 Apr 2019 00:55:02 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id d1so7269663edd.13 for ; Mon, 01 Apr 2019 00:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=W8GdkvLXVxf3RX6LtEbidLqpJSp86nj7F/eqCQQ45b0=; b=WQQaOHF350DRrAdPgis5RXT4WUK74Cki09WaXGhbJlmZzdtkaDaTHb/I4ZQR8mh6lG i6zjtj5nyH+MynWsCFTcTmUNAHgTaMloFx4eyBjNjaPfQHLMCp3wfjkaBWQEHk4b9Zj0 Rfd0Xii3PyA2c4vMRVvBkc+eQpqCiVdZjJlmv03PMAtf6oWGKUZ1njGHZLl/eyFFqkXl axxEbqH0pgL4jf5cUfuTMyJ/Zv4He4H4byAuH86PfEX0PiHf/d+vbbuoEu7Wb9Iesvfx 9hWOC2mcS94wa9vmoeOFmuHDz95bpAKxGOqwiwBL7U++0LXc74LAD5c0sjDm9ej0kf30 L1cQ== 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:date:references:to :in-reply-to:message-id; bh=W8GdkvLXVxf3RX6LtEbidLqpJSp86nj7F/eqCQQ45b0=; b=kfmnK6ku07XyJyRBDbO1I2bAcYlUGjXMXmIXV37GtcqgIdcyPE+8Z50AvJSl7XNixp lisz0qNkf+VdIzwHnHGkzz66ktvHI1cahKLsrFQHmX2cASQh/LOb9B6T6DXkk21ncYck M/AtOAhETRuNJAwZwyot08URhj5qN9bi0XnVV0WFnh+xdRsNgCne5NTX6O0hW6ohw83K c3i5TAo9RHq16vgRAKnvyjinuXHcfvcVhmDbmh3xV2yvcYlToRRurNNmMJ74aGjbSxW7 ojpvHzwEBBHPiFJxftpSGKvwoy+GJ17s4JLe+b2ThO5GfqXN3pvk4KGoGmG49u6YioOi SOgA== X-Gm-Message-State: APjAAAWCc9FujbAqFTST1bRFm9zS5UdbWyELegri15Yq2zyBrCocvQpH HnVhQwsR6qMlb97eDVCT+0pqm19K21E= X-Google-Smtp-Source: APXvYqwj3EdxqqJA19zcL66wE2qAFa1WwO6RvwbSy/YleuXIu30EsM4n9KXoklbrKWfUx2FO7ZJOrw== X-Received: by 2002:a50:976d:: with SMTP id d42mr41269547edb.5.1554105300747; Mon, 01 Apr 2019 00:55:00 -0700 (PDT) Received: from 200.66.20.149.in-addr.arpa (200.66.20.149.in-addr.arpa. [149.20.66.200]) by smtp.gmail.com with ESMTPSA id c16sm967720edc.75.2019.04.01.00.54.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Apr 2019 00:54:59 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_753446DB-C5E0-4421-98B3-18A580062843"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 1 Apr 2019 09:54:54 +0200 References: <000000000000f0ec8d05856a3b2b@google.com> To: IPv6 Operations In-Reply-To: <000000000000f0ec8d05856a3b2b@google.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [v6ops] IPv6Ready Logo Scenario document 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, 01 Apr 2019 07:55:05 -0000 --Apple-Mail=_753446DB-C5E0-4421-98B3-18A580062843 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 https://ipv6ready.org/docs/CE_Router_Interoperability_Latest.pdf I'm not at all sure why this suddenly showed up in a Google Alert; the = document may be new or updated. That said, and thinking about Mikael's = talk last week, it seems that the issues he was raising are possibly = things that could or should be tested by the Logo program or etc. Those of us that are in contact with them (I'm not) might mention that = to them. > On Mar 31, 2019, at 11:03 PM, Google Alerts = wrote: >=20 >=20 > IPv6 > Daily update =E2=8B=85 March 31, 2019 > NEWS > RIPE NCCc and Ogero to Lead Menog 19 Discussion on Accelerating = Internet Infrastructure ... > Al-Bawaba > The smooth and on-time implementation of IPv6 in collaboration with = RIPE NCC is part of the medium-term plan of OGERO to ensure that we are = on ... > Flag as irrelevant > WEB > IPv6 Ready CE Router (CPE) Interoperability Test Scenario > IPv6 Ready Logo > Flag as irrelevant > See more results | Edit this alert > You have received this email because you have subscribed to Google = Alerts. > Unsubscribe | View all your alerts > Receive this alert as RSS feed > Send Feedback = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_753446DB-C5E0-4421-98B3-18A580062843 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+AFAlyhw84ACgkQEhdRnd2G P+D2nA/9FTY72tMP+RI/hAIH3iT31suwdPorewTAQzBkrOKWTIKPzprnVGCOZEU8 Bvc1WixPv4seGYPSfGI2vqJd1CgmPEsUe1ubO1qUovmu0eGiUb1r/hHp62UOXkkt JF6LbJcnMdbkbJje6Cn7C8uANAe/6lYkOXz7VQrmAqpcZSOZF/fFR762xbVRFkN9 DAbrLldDPpZGfjs0iG8IY85lQ/A7oyt5/E8r7p9dJK07yMaJfCVgn3aEMCNk3bt9 ErXyqWi0q9WpNf4x5DcGgtBNQ78PSYxKbW3aqz7dKvdWA5ZjVBxK3H/F/5ADOfQ3 SljCDcSgE+p+bloykIOX7pdOzUHmq9/DnIPEKSw+28MJkHr7m8F25BZA22coK3Wy 2pNQERyiYQDTOKrW1s9Cdk1uj8e7ODUJ4kJF429enu8nimvLHJOGWHBzw7w75JC9 TAszbWZOk3i1VE9CStYdk5+Y0d0v6yGRe7jO6ivXoRqxnLsWvfhmZClUROWEAYmu YMLWuSSD4zYkKMLkVNuLTjZv3XldQmG+QEu32ZIlcRjkCmShxGP3f+ETsP0cZUSb xJnlfUYulSR515nDWP5y8OlIpenUcHc/jgBlK3kWu4l7rmxjwZmiwIJkArZd89Ob JTWjKhD/CbH/wtO89I6n0bxpE7MANNPtIve/bSmjK9VEb6BjMUA= =4XAF -----END PGP SIGNATURE----- --Apple-Mail=_753446DB-C5E0-4421-98B3-18A580062843-- From nobody Mon Apr 1 02:32:10 2019 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 9D37D1200D6 for ; Mon, 1 Apr 2019 02:32:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 lryNZ14Lu_fH for ; Mon, 1 Apr 2019 02:32:06 -0700 (PDT) Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (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 4B22B1200D5 for ; Mon, 1 Apr 2019 02:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at tul.cz Received: from rumburak.ite.tul.cz (rumburak.ite.ip6.tul.cz [IPv6:2001:718:1c01:72:224:1dff:fe77:e35c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 95496180651E6 for ; Mon, 1 Apr 2019 11:32:02 +0200 (CEST) From: Martin Hunek To: v6ops@ietf.org Date: Mon, 01 Apr 2019 11:31:54 +0200 Message-ID: <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> Organization: Technical University of Liberec In-Reply-To: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11434363.8mZZc7ftAB"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [v6ops] Operational Headache: DHCP V6 Relay 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, 01 Apr 2019 09:32:09 -0000 --nextPart11434363.8mZZc7ftAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Fred, I would be interested to address this issue, as it is the one I'm also havi= ng. But I would need some assistance, as I don't really know my ways around= IETF processes yet. Martin Dne p=C3=A1tek 29. b=C5=99ezna 2019 6:37:25 CEST, Fred Baker napsal(a): > https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terast= ream/, slide 3-4 >=20 > What do we want to say about DHCPv6 issues in vendor product and/or servi= ces? This headache doesn't have an obvious draft. I think that probably cal= ls for a person or design team to create such a draft for discussion on the= list and in Montreal. >=20 > Any takers? > -------------------------------------------------------------------------= =2D------ > The fact that there is a highway to hell and a stairway to heaven is an i= nteresting comment on projected traffic volume... >=20 --nextPart11434363.8mZZc7ftAB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJcodqSAAoJELUQZepRHeVcGCAH/0y4SyOrVYHTkQN72dCzHUIK 5cO9sOG7SD/dxSFWIdqBhHWRM8jWG/b3cN2yVNrlgCBdwjdKvfCxfjaLl5V41Dgp 0TB94fGLUMU+hvtpMLJq/1P2F2/UAthCIimwrEkKyfNuQtfPSQAOVcaSjw+DGyNC KeltYm8AYznDDq7KT0moEm39jMvKZ17pe7xY305H1KE8oY9bp7LGDGM3LSzzrNZ1 glUPTPKPHMWLyV7fE1xNt5ywsdTDeTqrhnlC8ZwJGbLsq8MWY85YKWR8HWpPWuER CvWvd56+F7LYsRKrwi2QuwfCrXJ5kwqk6qyjJ6pc9EqYP+EU8PR5V5AIj2KT4Qo= =FA89 -----END PGP SIGNATURE----- --nextPart11434363.8mZZc7ftAB-- From nobody Mon Apr 1 02:57:59 2019 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 8F8201200CE for ; Mon, 1 Apr 2019 02:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=helix-net-nz.20150623.gappssmtp.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 dSjhlRbjeZu9 for ; Mon, 1 Apr 2019 02:57:47 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 BB7811200E0 for ; Mon, 1 Apr 2019 02:57:47 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id b16so3249156ybr.13 for ; Mon, 01 Apr 2019 02:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lYENKvNWoipPgPZLwn3jfa1OAOmcqESPNYL0QLuvoC4=; b=mKulw2CYwx0Q/niEQHpgY+RGIXtGBfbA4Cy2I5SttURyo6nFNSs/nYIUH9FPW9puml jmvUBVXP6eX8r8hvRhUB2ln61h7pP3979siw5E/EYAf8KMwy9KQ3x1kjq53jpFQnfAF+ A6vLioNQWwuFiQb0EiW3I1ZkJ7csl6tfBPpnR+9F39O75RplU1RsXlpr/WCmO1UH1B/+ vxH2zOVCkMVXvrvLXlucrAuBszVCTR88mPClavJIQmeoGbYnVg/C1VY68rmlVaMaSVZ3 34h8YCaRxNI+l+6/Uw2YWhxPoIz5r96AeGGhxY+kjw2e0FLXUxpah4+w0IDjyBzscG/b Qgug== 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:content-transfer-encoding; bh=lYENKvNWoipPgPZLwn3jfa1OAOmcqESPNYL0QLuvoC4=; b=EWn7uAZUTF20Pqqgn2+a9c3GQCt6wqBsfKpdjqAIvnx2e/ZltR59PDUOCyTBelomBg 4ggviCplb5+8HPgDX2jC+JaonOd/bwqbV4ccEYvEBZwDbuXEg0euuhuiP+uH6ERwuJdA 8//9eAJKfROj/dCvo1N13nXGb7PwBNOEZ+S2LMv9HvpswdEas4YwHxHEdfp+v2IQb/8/ 8IEHWRe8m5M6lgXiV9rBLC/a7BjQXeyNSNyT7VbQMSlh6G81bphG+JjnFrh2av6bYfE6 Zr5Uya2ZDH1ixkRErsMSbkjsc4fSU1IwpSfXaVVavG9d3/DikIIqd0jQRmW185rW11Gh 6gSA== X-Gm-Message-State: APjAAAXuSh4gGL4Ftuy5Z6U/zwpCHdCPYOzbFNjiqIXDzj/qH+WGpX/y f0L3FDysOxvFm3sdUMESvepRh/WdWak= X-Google-Smtp-Source: APXvYqwt7jYHlMiQKtQgymHC9xQlPLmNQzR2YQhlcNwNkKMRFGlJoFQXvpByRPMwKUy0IhEKFqBbTg== X-Received: by 2002:a25:abce:: with SMTP id v72mr8230432ybi.490.1554112666904; Mon, 01 Apr 2019 02:57:46 -0700 (PDT) Received: from mail-yw1-f46.google.com (mail-yw1-f46.google.com. [209.85.161.46]) by smtp.gmail.com with ESMTPSA id 23sm3493801ywq.91.2019.04.01.02.57.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Apr 2019 02:57:46 -0700 (PDT) Received: by mail-yw1-f46.google.com with SMTP id l5so3033153ywa.0 for ; Mon, 01 Apr 2019 02:57:45 -0700 (PDT) X-Received: by 2002:a81:3dd5:: with SMTP id k204mr52199487ywa.502.1554112665762; Mon, 01 Apr 2019 02:57:45 -0700 (PDT) MIME-Version: 1.0 References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> In-Reply-To: <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> From: Richard Patterson Date: Mon, 1 Apr 2019 10:57:34 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Martin Hunek Cc: "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Operational Headache: DHCP V6 Relay 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, 01 Apr 2019 09:57:51 -0000 Hi Martin, I'd be interested in hearing more detail about the problems that you're experiencing related to this, if possible? One of the intentions of draft-patterson-intarea-ipoe-health is to detect and recover from invalid state in a DHCP relay. -Rich On Mon, 1 Apr 2019 at 10:32, Martin Hunek wrote: > > Hi Fred, > > I would be interested to address this issue, as it is the one I'm also ha= ving. But I would need some assistance, as I don't really know my ways arou= nd IETF processes yet. > > Martin > > Dne p=C3=A1tek 29. b=C5=99ezna 2019 6:37:25 CEST, Fred Baker napsal(a): > > https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-tera= stream/, slide 3-4 > > > > What do we want to say about DHCPv6 issues in vendor product and/or ser= vices? This headache doesn't have an obvious draft. I think that probably c= alls for a person or design team to create such a draft for discussion on t= he list and in Montreal. > > > > Any takers? > > -----------------------------------------------------------------------= --------- > > The fact that there is a highway to hell and a stairway to heaven is an= interesting comment on projected traffic volume... > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 1 05:11:50 2019 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 9826A12010C for ; Mon, 1 Apr 2019 05:11:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 q2gijgLhvEvS for ; Mon, 1 Apr 2019 05:11:46 -0700 (PDT) Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (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 311E1120100 for ; Mon, 1 Apr 2019 05:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at tul.cz Received: from rumburak.ite.tul.cz (rumburak.ite.ip6.tul.cz [IPv6:2001:718:1c01:72:224:1dff:fe77:e35c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 97438180651F1; Mon, 1 Apr 2019 14:11:42 +0200 (CEST) From: Martin Hunek To: Richard Patterson , v6ops@ietf.org Date: Mon, 01 Apr 2019 14:11:38 +0200 Message-ID: <3278909.DE8sFe37VJ@rumburak.ite.tul.cz> Organization: Technical University of Liberec In-Reply-To: References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3941558.1zU8iMPKNK"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [v6ops] Operational Headache: DHCP V6 Relay 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, 01 Apr 2019 12:11:49 -0000 --nextPart3941558.1zU8iMPKNK Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Richard, It has been a while, but basically I had a problem with DHCPv6 server not d= oing (or providing) routing of prefixes handed out by it. When I had tested this (with Debian 8 and included ISC DHCP), there was a p= ossibility of doing hook but this would work only if: 1) Client is using DUID-LL (type 3) or DUID-LLT (type 1) 2) Source of calculation of DUID is MAC of WAN interface 3) CPE is using EUI-64 for Link-local address How ever this is not every time the case. Some operating systems are using = DUID-UUID, some calculate DUID from LAN interface and some are even using s= ort of privacy extension on Link-local address instead of EUI-64. I even ha= d a device which was using DUID-UUID generated on every boot, how ever it s= hould be fixed by now. My idea for the draft would be a very short document saying something like: "DHCPv6-PD capable service MUST provide routing information for every activ= e lease, consisting at least: leased prefix, next hop and time when lease e= xpires. Service SHOULD also provide every other information send and receiv= e either as part of any request or reply of DHCPv6 service." "DHCPv6-PD capable service MUST provide way how to directly insert and upda= te routing information in the routing table of device on which it is hosted= =2E" "Routing information on active leases MUST be either persistent or the DHCP= v6-PD service MUST be capable of recovering this information." "Information provided by DHCPv6-PD MUST be accessible by other services on = the same device and MUST provide the way for remote logging." I will do some more recent test of DHCPv6 Servers and Relays and I'll try t= o put it in writing. What I understand from feedback I have been getting ov= er a years is that routing is usually fine on DHCPv6 Relays however so far = I have seen just one DHCPv6 Server which allows to directly export active l= eases into routing table. So we are talking about different things here. One thing is the fault recov= ery on DHCPv6 Relay and one is DHCPv6 Server/Relay not doing routing at all. Martin Dne pond=C4=9Bl=C3=AD 1. dubna 2019 11:57:34 CEST jste napsal(a): > Hi Martin, >=20 > I'd be interested in hearing more detail about the problems that > you're experiencing related to this, if possible? > One of the intentions of draft-patterson-intarea-ipoe-health is to > detect and recover from invalid state in a DHCP relay. >=20 > -Rich >=20 > On Mon, 1 Apr 2019 at 10:32, Martin Hunek wrote: > > > > Hi Fred, > > > > I would be interested to address this issue, as it is the one I'm also = having. But I would need some assistance, as I don't really know my ways ar= ound IETF processes yet. > > > > Martin > > > > Dne p=C3=A1tek 29. b=C5=99ezna 2019 6:37:25 CEST, Fred Baker napsal(a): > > > https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-te= rastream/, slide 3-4 > > > > > > What do we want to say about DHCPv6 issues in vendor product and/or s= ervices? This headache doesn't have an obvious draft. I think that probably= calls for a person or design team to create such a draft for discussion on= the list and in Montreal. > > > > > > Any takers? > > > ---------------------------------------------------------------------= =2D---------- > > > The fact that there is a highway to hell and a stairway to heaven is = an interesting comment on projected traffic volume... > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops --nextPart3941558.1zU8iMPKNK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJcof/+AAoJELUQZepRHeVcIIUH/RfhVqo1FIY7pfc8u9kX+hBs YlsY5oPy7O9DKqk5YWS6jkVUMc2NkUud7X0EZSI6p+UxPmk58elVBJZK7YxXTT5D 12mxpIiTY9UtSoyZJox+P32Yrj+l0GQG8vKMf1/oozZhQ/rrdZkMgF4vrUXqnQXb PyHFO56ZabjZLHbUY/L7IoReduniEoLvY5LTErT4FxA5vgJI91q+4hkEMlPLIIIs ve+FIFvj2mL2QShOjBC3cTg8k7O6dmJ0vgWc1EUoQSwaGa6k0goEtsPeq+IeKx+W 6yiD89+QjYwxa6IDoY/Dik1xsPnZ3CFheKKIo2Bd1fZFCrBd5q9DuBJHsa0PpfE= =pWoC -----END PGP SIGNATURE----- --nextPart3941558.1zU8iMPKNK-- From nobody Mon Apr 1 05:50:03 2019 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 6FCFF120118 for ; Mon, 1 Apr 2019 05:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=iol.unh.edu 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 T1GXkztGen3O for ; Mon, 1 Apr 2019 05:49:57 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450: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 0B63B12011E for ; Mon, 1 Apr 2019 05:49:57 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id p10so11894960wrq.1 for ; Mon, 01 Apr 2019 05:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=04aVsvXoLwk4K8yv/OTe9GKkli0oToGk6i0x3y+tYOk=; b=UgKEx3iOsdHD8RAUJW2+VfDMrrYHPrnbxwdyMufgcH6lHz+ffw9hB6aIKaZERZkWnI iGVXpfvqEdOHV2nIP3ARlnNlE8Vu+oSeV3mV14u9IZPy6BfKEPbXcfSGCmh8hPDAfI8z EycF9/jNUtSRxixGp6zm0fbd3aja3tiFGdB8E= 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=04aVsvXoLwk4K8yv/OTe9GKkli0oToGk6i0x3y+tYOk=; b=A6lvx63gY9Ffb3S7ZO0aCNvjU4mYDbhMpZnbzCpnVoLE3ExRHrf2k/C8cVk0tGV/Ge iPt8pCX8IOfXS6RQI4JeUNYBc7FmN6VAuyjAQM2hzVnd1/gYLmdD+tpiBgwICnxFxSZj 6ViOncAjZ8TpqJQPv4Suyeof3Dz4wqxRi+0Nn/sF5kV5cEtStENrkjRW+YYKUABqxQ40 PpjSLgPyNeVzlg5MVXG7jjVMq6CWKkpHq3wpzgq4aEkh7DrBRMlskTDgQvkiooOnW4Se E9FXXOiLZq9N/Tk8Vdi/Twxm1ylKmDB/WDlJCoIxsRjkq3r1oU49cn5uLSr2nxPmWUN3 CK6w== X-Gm-Message-State: APjAAAV8EBKlZy5IKk34IVRXAtdh5GRtOo1sTAttqDC7xJYl7Kak816L rCyvFQxTyvID8XzCCwEl8SOne5uqyUH4ZmY3HpBo6w== X-Google-Smtp-Source: APXvYqzI3TgB+tT70Yuyy+K7wAz0bFqqOlDoHVel/GHVMlx+x03Ps1WY7tfDcO9BvuIwYvfBNjVI9EwkSPBaILdHTsw= X-Received: by 2002:a5d:448f:: with SMTP id j15mr11172780wrq.79.1554122995151; Mon, 01 Apr 2019 05:49:55 -0700 (PDT) MIME-Version: 1.0 References: <000000000000f0ec8d05856a3b2b@google.com> In-Reply-To: From: Timothy Winters Date: Mon, 1 Apr 2019 08:49:43 -0400 Message-ID: To: Fred Baker Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000104df905857775d4" Archived-At: Subject: Re: [v6ops] IPv6Ready Logo Scenario document 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, 01 Apr 2019 12:50:00 -0000 --000000000000104df905857775d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fred, We haven't updated it recently, we currently working on an update. The IPv6 Ready Logo has always tested to RFC, in this case 7084. It sounds like some of the issues that Mikael discussed last week are outside that document, but if there are useful test to add we would love to get that input. Regards, Tim IPv6 Ready Logo Chair On Mon, Apr 1, 2019 at 3:55 AM Fred Baker wrote: > https://ipv6ready.org/docs/CE_Router_Interoperability_Latest.pdf > > I'm not at all sure why this suddenly showed up in a Google Alert; the > document may be new or updated. That said, and thinking about Mikael's ta= lk > last week, it seems that the issues he was raising are possibly things th= at > could or should be tested by the Logo program or etc. > > Those of us that are in contact with them (I'm not) might mention that to > them. > > > On Mar 31, 2019, at 11:03 PM, Google Alerts < > googlealerts-noreply@google.com> wrote: > > > > > > IPv6 > > Daily update =E2=8B=85 March 31, 2019 > > NEWS > > RIPE NCCc and Ogero to Lead Menog 19 Discussion on Accelerating Interne= t > Infrastructure ... > > Al-Bawaba > > The smooth and on-time implementation of IPv6 in collaboration with RIP= E > NCC is part of the medium-term plan of OGERO to ensure that we are on ... > > Flag as irrelevant > > WEB > > IPv6 Ready CE Router (CPE) Interoperability Test Scenario > > IPv6 Ready Logo > > Flag as irrelevant > > See more results | Edit this alert > > You have received this email because you have subscribed to Google > Alerts. > > Unsubscribe | View all your alerts > > Receive this alert as RSS feed > > Send Feedback > > > -------------------------------------------------------------------------= ------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000104df905857775d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fred,

We haven't updated it rece= ntly, we currently working on an update.=C2=A0 =C2=A0The IPv6 Ready Logo ha= s always tested to RFC, in this case 7084.=C2=A0 =C2=A0It sounds like some = of the issues that Mikael discussed last week are outside that document, bu= t if there are useful test to add we would love to get that input.

Regards,
Tim
IPv6 Ready Logo Chair

On Mon, Apr 1, 2019 at 3:55 AM Fred Baker <fredbaker.ietf@gmail.com> wrote:
https://ipv6ready.org/docs/CE_Router_Interoperability_Latest.pdf
I'm not at all sure why this suddenly showed up in a Google Alert; the = document may be new or updated. That said, and thinking about Mikael's = talk last week, it seems that the issues he was raising are possibly things= that could or should be tested by the Logo program or etc.

Those of us that are in contact with them (I'm not) might mention that = to them.

> On Mar 31, 2019, at 11:03 PM, Google Alerts <googlealerts-noreply@google.= com> wrote:
>
>
> IPv6
> Daily update =E2=8B=85 March 31, 2019
> NEWS
> RIPE NCCc and Ogero to Lead Menog 19 Discussion on Accelerating Intern= et Infrastructure ...
> Al-Bawaba
> The smooth and on-time implementation of IPv6 in collaboration with RI= PE NCC is part of the medium-term plan of OGERO to ensure that we are on ..= .
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Flag as irrelevant
> WEB
> IPv6 Ready CE Router (CPE) Interoperability Test Scenario
> IPv6 Ready Logo
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Flag as irrelevant
> See more results | Edit this alert
> You have received this email because you have subscribed to Google Ale= rts.
> Unsubscribe | View all your alerts
>=C2=A0 =C2=A0Receive this alert as RSS feed
> Send Feedback

---------------------------------------------------------------------------= -----
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
=C2=A0 =C2=A0 =C2=A0Sun Tzu

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000104df905857775d4-- From nobody Mon Apr 1 06:04:25 2019 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 472AD120118 for ; Mon, 1 Apr 2019 06:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=gmx.net 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 8YzWYIUOlkOn for ; Mon, 1 Apr 2019 06:04:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 831CC12010E for ; Mon, 1 Apr 2019 06:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1554123856; bh=aeicqu7zqPoetYvKxzuNUs/FzO9ZlvKxVNn/vdvi+8g=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=KGK8d6trg2R5hNr/sZeCGXwVMTYi1e94tW9ULIa0s31QqjoXYKrd5O9byzV6UXJ9M 5YZ+8eAREui5Bopg3thC4k3rNMueXAANpsWF5kAT/5K8Bxl+PWaNRSpiZbKDuhnKrc V5cCi1QnzRuAeb5XnWj4HrkKRgcV6utEs6zm/8hw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.228] ([80.159.240.8]) by mail.gmx.com (mrgmx001 [212.227.17.184]) with ESMTPSA (Nemesis) id 0LdHeL-1gTOb33WkL-00iVz8; Mon, 01 Apr 2019 15:04:16 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: ianfarrer@gmx.com In-Reply-To: <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> Date: Mon, 1 Apr 2019 15:04:15 +0200 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8F987994-DF3A-4FF4-B8C7-CFAC62FACFF2@gmx.com> References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> To: Martin Hunek X-Mailer: Apple Mail (2.3445.102.3) X-Provags-ID: V03:K1:lA0+5qVU9hgYNsHhiRzJZL57XojbTnM9aeFqtevqDFpDlCP0bV0 955LOy/pUea8V+Wobje3ScMrU5uJAgRV1LQvtg01CwRIqWf7WEPaGusX/V2pjaem0XW8oUl ZNfWlk1ouEu6qc+Axk3KbeCTS5rcMMvRhWCFsv0LD6DiAc8Wo1n0FZpu7gKzO656r+knJqm TYz/TSfqDuA/9kqIgBlNg== X-UI-Out-Filterresults: notjunk:1;V03:K0:HjvfaL2uTx0=:7THJJS+h6xr7578Gc/tPUv aTsVJYytOwMuSJ8HsGAWS0AdLmx7iKRRPfqwEsResHPrNa+N/qwZowH2BHy4JLIuz+vB6KSB1 cqMU+ePxQKThAjFoc4/ZVq7cI24aQuyi4iflZ6M9/HF81g8pH4shalrR5BHmRfRsVwe6l1Xd9 UV+6NqZQ+/Ld+q2UNb5hX7ss+fAD7cyyZzF7qVovFgbzu0r9cV7dMRA/8Xj+5Tesh3rZzcCDo KuPkdt9B4zEXdaQIk6UafLNto/3Qry7CiVwnVF7lkUPDqfkiXJBYfOYFz5dV2Goa3Z65yL+Qt H4UVSkjEFR2PrDApzOvxiJsfj9IkQxY3c7imcV1uj5diYEuvpuVVe8xpW+h8Dp4DQDAYOdLpn eINRnj/rmrX9lPG3athpvfBZt6S9Kf29pnFLFxqKaKIWnFRnbVz/EAsjAdfzu+viNPGb6paT3 Sq6PjEoYI6LY+4RF7xkeP2F62lBwdcrvxYMthpTDFOk+zu1lFssF2Ml+ZCilmAw8HgFJ0RlpC xDf3rXkPdhKpKuGmjeufuW0AIqIDz/pA0HR5oMMJgobbTOAKBTi2WKrjn1pAy0vzEjoR+XNYp icOzpaa2/Ms0rRAnSlr5VLkjrKbolCuak1oAnJOTv3BvvMPH7+Ji/g65lbQDiZ4WuITe6nR32 c5N2SxJAgNp/VUHkoh+Dq2FeQogJST8aM2OwIePft+nTeqeoWSgqY6YmFNg1Ogbme3iE9LJ0A uA3Yny9MQ8xTFiHrwp015SxqZSdSUp3Dlkun2JgZ8/xMLZAeBvnzX1wAgANHSQ3GVfgI+Rvhh 0lrFloZbnmDrAKPS5epmVqsWpbTNDpI+fLWDnulBSGFM8hg+WUUCmknM0gJ5OjCUUq52ojDOO 3zAXhfY52HS1rmblJWSiINqJfCCsLrRnZV2FHvZ0igPbszWVPyQIhTDYsV3OjFybHQOoApPfx KUVH2i0m1UQ== Archived-At: Subject: Re: [v6ops] Operational Headache: DHCP V6 Relay 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, 01 Apr 2019 13:04:24 -0000 Hi Martin, I would also be interested in working on this as it=E2=80=99s a problem = for us. I=E2=80=99ve got something I wrote a while back. I=E2=80=99ll = share it as a starting point. Cheers, Ian > On 1. Apr 2019, at 11:31, Martin Hunek wrote: >=20 > Hi Fred, >=20 > I would be interested to address this issue, as it is the one I'm also = having. But I would need some assistance, as I don't really know my ways = around IETF processes yet. >=20 > Martin >=20 > Dne p=C3=A1tek 29. b=C5=99ezna 2019 6:37:25 CEST, Fred Baker = napsal(a): >> = https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastr= eam/, slide 3-4 >>=20 >> What do we want to say about DHCPv6 issues in vendor product and/or = services? This headache doesn't have an obvious draft. I think that = probably calls for a person or design team to create such a draft for = discussion on the list and in Montreal. >>=20 >> Any takers? >> = --------------------------------------------------------------------------= ------ >> The fact that there is a highway to hell and a stairway to heaven is = an interesting comment on projected traffic volume... >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 1 10:35:01 2019 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 CBD161204CD for ; Mon, 1 Apr 2019 10:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Q5Mrrhyci-Rb for ; Mon, 1 Apr 2019 10:34:55 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 6A9911204CC for ; Mon, 1 Apr 2019 10:34:55 -0700 (PDT) Received: from [IPv6:2601:647:4201:4561:b522:b4e8:2b6d:d5d0] ([IPv6:2601:647:4201:4561:b522:b4e8:2b6d:d5d0]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id x31HYr0O022894; Mon, 1 Apr 2019 17:34:54 GMT (envelope-from joelja@bogus.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Joel Jaeggli In-Reply-To: <29ad0e7d-79be-8612-84e5-ffb10eb78e27@gmail.com> Date: Mon, 1 Apr 2019 10:34:33 -0700 Cc: Fred Baker , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <195B4AFD-2F15-4CF1-9F97-C8CFCD3037A7@bogus.com> References: <29ad0e7d-79be-8612-84e5-ffb10eb78e27@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] Operational Headache: Multi Attached Data Center Host configuration 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, 01 Apr 2019 17:34:59 -0000 > On Mar 29, 2019, at 17:31, Brian E Carpenter = wrote: >=20 > Another question before starting to discuss: would this problem be = helped by universal deployment of https://tools.ietf.org/html/rfc8028 ? = And if not, > why not? >=20 > Regards > Brian Carpenter >=20 > On 29-Mar-19 18:37, Fred Baker wrote: >> = https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastr= eam/, slide 6 >>=20 >> What do we want to say on this topic? There are a number of screwball = interactions, and vendor product seems to vary. This seems to call for = an draft named might call for a draft = draft-ietf-v6ops-operational-thoughts-on-multi-attached-hosts-in-data-cent= ers or something like that. Is there a person or set of people that = would be interested to form a design team around that topic? One of the obvious questions for me from the outset is, are we going = about this completely wrong especially with respect to data-centers? DHCP/DHCPv6/RA/DHCPv6PD are basic configuration mechanisms for devices = to attach to networks with which they have arms length relationships.=20 Their use for initial attachment and boot-strapping network connectivity = is straight-forward in datacenters. To suppose that they are therefore = the appropriate to have a host configure what prefixes it might expose = to the outside word, how it should configure it's internal topology, how = it should manage sub-delegation and so forth seems like it ignores most = of the work done in the IETF on management and routing. If you need to configure a host in a managed environment once it's = first network interface is up you can: * use netconf * incorporate your collection of nfv/sdx control functions into hosts * roll your own=20 if you need to express to a network what prefixes should be sent to you = and on what interface * use a routing protocol This is what people do today, and I wouldn't call them screwball. in datacenters I've run or worked in the last decade we have followed = largely similar playbooks: DHCP/DHCPv6 for bootstrap configuration of management interfaces. We use a provisioning system and a backing database to apply network = configuration to ports / loopbacks / multiple kernel routing tables / = VRFS / internal bridges / nat-translators / tunnels and so forth. When = the configuration changes, agents are used to insure that this system = converges in timely fashion. There's no concept of a lease, lifetime or = ttl here, nor are those appropriate, a resource or configuration is in = place until it is removed, waiting for a timer on a resource to expire = in order to assume that hosts will change their behavior isn't an = appropiate way to reallocate resources... A configured host can signal the network for the purpose of programing = the forwarding plane of it's availability as well as address usage using = a routing protocol. the most common used for these purposes these days = is probably ebgp. convergence of forwarding is bounded by bgp signaling = rather than by lease / lifetime / ttl with the upper bound being defined = by the keep-alive rate or in some cases by BFD. expressive controls on = the host path selection may also be exposed through routing when the = host engages in next hop selection, or path selection if mols or some = other overlay topology is present, when it is not that function is = abrogated to an upstream network device (which may in fact have to = resort to policy based routing in order to place the right sources on = the right networks. >> = --------------------------------------------------------------------------= ------ >> The fact that there is a highway to hell and a stairway to heaven is = an interesting comment on projected traffic volume... >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Tue Apr 2 16:11:01 2019 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 0F40012000E; Tue, 2 Apr 2019 16:10:53 -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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <155424665298.6362.4024106345182960707@ietfa.amsl.com> Date: Tue, 02 Apr 2019 16:10:53 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-04.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: Tue, 02 Apr 2019 23:10:53 -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 : NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-nat64-deployment-04.txt Pages : 37 Date : 2019-04-02 Abstract: This document describes how NAT64 and 464XLAT can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise and the issues to be considered when having an IPv6-only access link, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nat64-deployment-04 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-deployment-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-deployment-04 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 Tue Apr 2 16:14:03 2019 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 E19EA12034A for ; Tue, 2 Apr 2019 16:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 341ChJDqHoPW for ; Tue, 2 Apr 2019 16:14: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 B45DB12000E for ; Tue, 2 Apr 2019 16:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1554246838; x=1554851638; 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=DrBKrkwi I14hYmDq3fsPr6CYa5MB/vLcorNcKGNbOic=; b=ftpBopmpv5ouS9+pkjUUKHYO sPal1/hJT6RWhFdc1ED+1NI5tExO1g3IIBYqphoEDc6wCrLN+0l7oZ2E7CZyr9yV NQjQugQrPNH7ngBjkYy1P3dhAURJ0AzLXWHm+BIWcwPgYS1DXZCEhAweg+eNuek0 Rsq5S1Aluy8yqUrqBuc= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 03 Apr 2019 01:13:58 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 03 Apr 2019 01:13:57 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006206642.msg for ; Wed, 03 Apr 2019 01:13:57 +0200 X-MDRemoteIP: 2001:470:1f09:495:4d12:7ab1:d8e2:246b X-MDHelo: [10.10.10.130] X-MDArrival-Date: Wed, 03 Apr 2019 01:13:57 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1995792148=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.8.190312 Date: Wed, 03 Apr 2019 01:13:53 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-04.txt References: <155424665298.6362.4024106345182960707@ietfa.amsl.com> In-Reply-To: <155424665298.6362.4024106345182960707@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [v6ops] FW: I-D Action: draft-ietf-v6ops-nat64-deployment-04.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, 02 Apr 2019 23:14:02 -0000 Hi all, This new version only updates some nits and include a new short section for= EAMT consideration. https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/?include= _text=3D1 Regards, Jordi =20 =20 =EF=BB=BFEl 3/4/19 1:12, "v6ops-bounces@ietf.org en nombre de internet-draf= ts@ietf.org" = escribi=C3=B3: =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : NAT64/464XLAT Deployment Guidelines in Operat= or and Enterprise Networks Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-nat64-deployment-04.txt Pages : 37 Date : 2019-04-02 =20 Abstract: This document describes how NAT64 and 464XLAT can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise and the issues to be considered when having an IPv6-only access link, regarding: a) DNS64, b) applications or devices that use literal IPv= 4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nat64-deployment-04 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-deployment= -04 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-deployment-0= 4 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =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 Mon Apr 8 08:47:06 2019 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 53673120409 for ; Mon, 8 Apr 2019 08:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 LgHwifBjJm7F for ; Mon, 8 Apr 2019 08:46:36 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 76C26120315 for ; Mon, 8 Apr 2019 08:46:28 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id o129so8235837qke.8 for ; Mon, 08 Apr 2019 08:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sigUQlqpJ0mdNJfQN3vFl3BSCUcKv95m2Ypx4229y2k=; b=Lr1Jb1ot5ZP7Y983rstuH1HtMDbEACu5Nte8exZd1Fl8aeq0yT7sfrUiA3JHBLq8tf PHGYgA4vV9d5iIHiYtiJfYzWtpsFiUO6DS8ICv2XAGIZTBNFY87CRHCe5lg/kHgDTNob j4RvgvSnjUe37P1HF6iIm6zA73P1Q1M8DhLHYlq4r/5ZfIuppEnVzW/V+Ijf3ggJEzKX /BktZDqnunjzLmoThyniFaAFFuFfXdMosjsUiLF/AHOD6llIl/70V7V8BmvdIrJU8v1u 8MzjxpfiimN4rEVfyR3OBKsMI3PzVa52ZHIahIaJFjbFtzID3BvbxLr1gVgWiMAFw/oq KYUA== 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=sigUQlqpJ0mdNJfQN3vFl3BSCUcKv95m2Ypx4229y2k=; b=bK/OtZkEL1vxjHhWcYgdMEfnX9NjirIPFmbmdDXfpSBLSd8Z9CU6zkodAzITHVcSWp a/HxN2wFe3aZxVG5zMI6wZnHC0dvc+aKEyoDCIvqqGuxKXjbvhWdsW8mQe2a+ics3ygc dzxhAGej7xNw09xJ0/99cr5HMyQdkCTvxiLz2U0Vun/Tec33qgjFJKvrV6WbRetSG96d /SbrII7z1GFD3WPzlD0Epha7+GZGoFzx/gS76vtuXk/9GsLmS/o/sBF8XSaa9+PgHO8M stag/Fek+hFwNdW0gZhd4QJ7665dVbGgJ/8LP3payRlUKW81NAb6e04HFK07KITEnCIJ SZpQ== X-Gm-Message-State: APjAAAUEu+nUMv7el4PNYFJnBu8P/qTTy/ZohAINxQiv7EARRWqDeznf y1vJgCP79yibQ8+uIuPLguj1Yw== X-Google-Smtp-Source: APXvYqz2j2exRdM90AsdmpGoX3EGxSdzB+62inznKSOXO10khW9htQt5wlZWwreawU6b9x64l0BZ9g== X-Received: by 2002:a05:620a:11b5:: with SMTP id c21mr23542345qkk.222.1554738387380; Mon, 08 Apr 2019 08:46:27 -0700 (PDT) Received: from [10.0.100.12] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id x8sm19240910qtj.45.2019.04.08.08.46.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 08:46:26 -0700 (PDT) From: Ted Lemon Message-Id: <35947BFD-5D4C-4342-AEB0-631FB0ECF920@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E4C4A30D-2935-49C7-906A-F49149C2A30F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Mon, 8 Apr 2019 11:46:24 -0400 In-Reply-To: Cc: Fred Baker , IPv6 Operations To: Mikael Abrahamsson References: <92e28c87-5c05-af81-8258-64c3bca9be78@gmail.com> <09B9AD86-B21F-4A9E-A6A5-A06FB361BF17@gmail.com> X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [v6ops] Operational Headache: Provisioning domains 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, 08 Apr 2019 15:46:47 -0000 --Apple-Mail=_E4C4A30D-2935-49C7-906A-F49149C2A30F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 31, 2019, at 7:15 AM, Mikael Abrahamsson = wrote: > I don't want to lose the PVD discussion in a discussion of what good = use of addresses is or not. They're orthogonal issues. Indeed. The original intended use case for PVDs was for situations = where a host is multiply connected, or where a network is multiply = connected, and the configuration that works on one egress will not work = on the other. Another use case is the case where one apparent egress = may not work at all until captive portal authentication has happened, = and the information received from that egress, if used for the other = egress, would cause the working egress to suddenly stop working. The Terastream use case is a cute hack, but not a primary use case. = Mikael is reporting it because it=E2=80=99s a problem for him, not = because it is the primary use case for PVDs. --Apple-Mail=_E4C4A30D-2935-49C7-906A-F49149C2A30F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Mar 31, 2019, at 7:15 AM, Mikael Abrahamsson <swmike@swm.pp.se> = wrote:
I don't want = to lose the PVD discussion in a discussion of what good use of addresses = is or not. They're orthogonal issues.

Indeed.   The original intended use case = for PVDs was for situations where a host is multiply connected, or where = a network is multiply connected, and the configuration that works on one = egress will not work on the other.   Another use case is the case = where one apparent egress may not work at all until captive portal = authentication has happened, and the information received from that = egress, if used for the other egress, would cause the working egress to = suddenly stop working.

The Terastream use case is a cute hack, but not a primary use = case.   Mikael is reporting it because it=E2=80=99s a problem for = him, not because it is the primary use case for PVDs.

= --Apple-Mail=_E4C4A30D-2935-49C7-906A-F49149C2A30F-- From nobody Mon Apr 8 08:53:27 2019 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 E3EC3120431; Mon, 8 Apr 2019 08:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 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, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 wYa8lVY-V2HF; Mon, 8 Apr 2019 08:53:17 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 8FE4E120428; Mon, 8 Apr 2019 08:53:17 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x38EDamk001128; Mon, 8 Apr 2019 07:20:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=zknZqHQLX74QAxfbocfMD3z0WQv2PLFSQT58h9Tv0ec=; b=UC5948BS2PuaAb+pkWyBwOnFyQcTftpMeca6qyqpqEj+05aTT2GyTgcOURB7B8mQVbWN 1oBR969KGA8d6II+Oy0hpYg902kgfKsw9KM1kC3+vB6FPSLq1in7YCV0am9bvJBeVFY0 6WibykCu0B9nOh0+Nhb8EIdWaSyXShtLiSX3PEY7hpMgM7RJKlK/s/xGTZanX8JIopYu B94sv413H9e2NgwAn/EKrBFrRm8hx1HkwEex+PJGfjB+IJggeNlwWu9TlCD6oaMZJ5CM LbX0eorc0jWZ11QxCyZekkYSHFJjiiLZrlfQIC+MukHbK0yx9AwRHF+wubTD1w7EkfzQ 7g== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2055.outbound.protection.outlook.com [104.47.36.55]) by mx0b-00273201.pphosted.com with ESMTP id 2rr5070a0s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 08 Apr 2019 07:20:09 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB4743.namprd05.prod.outlook.com (52.135.233.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.11; Mon, 8 Apr 2019 14:20:06 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::30f9:29cf:6d50:edd4]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::30f9:29cf:6d50:edd4%4]) with mapi id 15.20.1792.009; Mon, 8 Apr 2019 14:20:05 +0000 From: Ron Bonica To: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" Thread-Topic: WGLC: draft-ietf-v6ops-nat64-deployment-04 Thread-Index: AdTuFevwhUrweEmoS22jgEJvFmhhxw== Content-Class: Date: Mon, 8 Apr 2019 14:20:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action 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=2019-04-08T14:20:03.1405839Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5125d2e0-8f5a-4a2f-33d9-08d6bc2d4c57 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB4743; x-ms-traffictypediagnostic: BYAPR05MB4743: x-microsoft-antispam-prvs: x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(346002)(376002)(396003)(366004)(199004)(189003)(33656002)(256004)(478600001)(74316002)(97736004)(2501003)(486006)(106356001)(105586002)(476003)(186003)(14454004)(2906002)(450100002)(110136005)(26005)(5660300002)(305945005)(53936002)(102836004)(7736002)(8936002)(25786009)(55016002)(3846002)(6506007)(9686003)(6116002)(316002)(71190400001)(81156014)(52536014)(81166006)(8676002)(66066001)(7696005)(71200400001)(86362001)(68736007)(6436002)(99286004)(558084003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4743; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: tA+6Y0E/Fvt90aaGRUjqKc/jMINORmCgAwqNtCTu/UU87zFN13XCNYjUeX/VWxYE52iKj5FVUNQNdvcmR0a/TpHuGLTPmD+mGDABqCbrbkWCUPftcxobNVnED+ZJaIzNsGtDg5IhYb4SzE1gJ/AWwsRLL0hWO3E+GyORD/ftHvoHBqfIlD6w3GCfoitnYJ+x7vsUGVU2M33LPfa5B6rG1lDGtO/HibfmAZYb3zrrFI1IWLpAUOkuqiCdg5pHTdYlWqNMRw3miHexbTfHmktRYF5QJiWqCpDpNextz9dMI2rTTo7hJQLgMj9AtSIjnOcQtwW8uQWVDMpwezL89TjsvldGroABX0BplFbomDDjgUzJGbtJXLEk5+3y+kCYA2rzP93uOF4ZTR8qRDbSkRwGRmozp7N7AjIxaTLMZPPpphQ= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 5125d2e0-8f5a-4a2f-33d9-08d6bc2d4c57 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 14:20:05.8026 (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-Transport-CrossTenantHeadersStamped: BYAPR05MB4743 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=507 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080120 Archived-At: Subject: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 08 Apr 2019 15:53:24 -0000 Folks, This email initiates a Working Group Last call on draft-ietf-v6ops-nat64-de= ployment-04. WGLC will end at COB, April 22, 2019. Authors, Please respond to this message indicating whether you are aware of any IPR = regarding this draft. Ron Juniper Internal From nobody Mon Apr 8 09:02:59 2019 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 20EF0120302 for ; Mon, 8 Apr 2019 09:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 NJ5k1RAd_PtD for ; Mon, 8 Apr 2019 09:02:54 -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 EAC391203E5 for ; Mon, 8 Apr 2019 09:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1554739356; x=1555344156; 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=wR91G9j7D/M/v5T5ScTIw P1NfWBog0PGXaqTkH//XyQ=; b=DddtNaRj8X3GpuDzzSi0udfrcPEBzRE6SmqR6 3eoQEJ8m5mZyMX0LQo8aCoRcsOQfw7wbkNN8YEWgDxZOJnSMd9zgwnpW77SVegx9 n61UVK8TnwJaGSfJcSM035hdWAf1o12Fjlmz76Q1IL03df1j9+DT35TqcgDaze6/ iJzJlE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 08 Apr 2019 18:02:36 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 08 Apr 2019 18:02:36 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006212157.msg for ; Mon, 08 Apr 2019 18:02:35 +0200 X-MDRemoteIP: 2001:470:1f09:495:5cd2:8ca7:da6d:ede4 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Mon, 08 Apr 2019 18:02:35 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=10017e4ea3=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.8.190312 Date: Mon, 08 Apr 2019 18:02:33 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <11DA6245-76CB-4DBD-B0EB-11ADA7BA00AE@consulintel.es> Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 08 Apr 2019 16:02:57 -0000 Hi Ron, I'm not aware of any IPR on this document. Regards, Jordi =20 =20 =EF=BB=BFEl 8/4/19 17:54, "v6ops en nombre de Ron Bonica" escribi=C3=B3: Folks, =20 This email initiates a Working Group Last call on draft-ietf-v6ops-nat6= 4-deployment-04. WGLC will end at COB, April 22, 2019. =20 Authors, =20 Please respond to this message indicating whether you are aware of any = IPR regarding this draft. =20 R= on =20 =20 Juniper Internal =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 Tue Apr 9 10:49:01 2019 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 19EAE1200EA; Tue, 9 Apr 2019 10:48:53 -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, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 VotET524_esm; Tue, 9 Apr 2019 10:48:51 -0700 (PDT) Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 84CB412089C; Tue, 9 Apr 2019 10:48:48 -0700 (PDT) Received: by mail-wm1-f44.google.com with SMTP id n25so4339239wmk.4; Tue, 09 Apr 2019 10:48:48 -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=E5jjEWjTD8Jh56Ggt3rueaVaMEllxBNK7pyM9zuTHWI=; b=DtEV2SQ05l28SoHzNJtfOrahGGPCjZdq7ygoe5UDSrcfEMwI7rlxaiFwbkhqo3IQz3 4vEzxwCMe/a7NrAI4DdZH55c9UTm875T5r6HpCSekGjkUEyd01raj4SY1EaUpgRAaK/d qHAtqAgfnUxE9Tit3EqBPpGxQD6a3CD5hzPFKXYQ1JTRhni/NdfVCUX4u0WRapIu4Hrj Xhmj3XhZSySI3W4jyb1lXvjuBv0POkYwbSC4bqO9QLqpdTfMryDy4WUbVAM7Yv4Yr49u Vq3EzyxcjsIm/jL2r0i4XjFmMOH7gbgLc7EtokY4iPdr3nLs7Zw0LeGbez49xpq1lpxy 3z2Q== X-Gm-Message-State: APjAAAVeRAQ6hM0dzKjtXhC9Mlz7JxN46NkFh4fep4wc8XS+q1GvZmsz bo8oc0sGmw7WwNgupwpqzafntoiou4DH0H0adWU= X-Google-Smtp-Source: APXvYqynu9ngEh28/jOS9c59UfAopELgeFIOAZr6zLU5rqefwWjlRRZtF4mq2agLsJ0o1IDR3r2onVbNRu/2/WMbe58= X-Received: by 2002:a05:600c:2294:: with SMTP id 20mr1908828wmf.56.1554832126733; Tue, 09 Apr 2019 10:48:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 9 Apr 2019 10:48:35 -0700 Message-ID: To: Fred Baker Cc: IPv6 Operations , opsec@ietf.org Content-Type: multipart/alternative; boundary="00000000000099736c05861c909a" Archived-At: Subject: Re: [v6ops] draft-ietf-opsec-v6 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, 09 Apr 2019 17:48:53 -0000 --00000000000099736c05861c909a Content-Type: text/plain; charset="UTF-8" (Note: I don't subscribe to opsec@ietf.org. So I expect this message will be subject to moderation). At Fri, 29 Mar 2019 06:18:37 +0100, Fred Baker wrote: > Yesterday, the authors of an opec draft asked us for comments on their draft, which is in a second WGLC in opec (opsec@ietf.org). You may have missed the character string: > > https://datatracker.ietf.org/doc/draft-ietf-opsec-v6 > https://tools.ietf.org/html/draft-ietf-opsec-v6 > "Operational Security Considerations for IPv6 Networks", Eric Vyncke, > Chittimaneni Kk, Merike Kaeo, Enno Rey, 2019-03-11, > > I'd encourage people to read it and comment on the opec list. One quick comment, in case no one pointed it out: Section 2.3.3 refers to I-D.ietf-dhc-sedhcpv6 as follows: [...] Another way to secure DHCPv6 would be to use the secure DHCPv6 protocol which is currently work in progress per [I-D.ietf-dhc-sedhcpv6] , but, with no real deployment known by the authors of this document. In my understanding, this draft is effectively dead rather than just missing deployment. There may be yet another attempt of restarting it in future, but I see no indication of it right now. Even if the work is eventually restarted it will be something completely different from the current latest draft. So I'd suggest either: - just remove this sentence, or - if you want to keep the reference, make it more consistent with the current situation, like: There was a proposal of secure DHCPv6 protocol [I-D.ietf-dhc-sedhcpv6], but the work has been effectively suspended and there is no indication of a restart anytime soon. -- JINMEI, Tatuya --00000000000099736c05861c909a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Note: I don't subscribe to opsec@ietf.org.=C2=A0 So I expect this messa= ge
will be subject to moderation).

At Fri, 29 Mar 2019 06:18:37 += 0100,
Fred Baker <fredbak= er.ietf@gmail.com> wrote:

> Yesterday, the authors of an o= pec draft asked us for comments on their draft, which is in a second WGLC i= n opec (opsec@ietf.org). You may have= missed the character string:
>
> https://datatracker.ietf.org/doc/draft= -ietf-opsec-v6
> https://tools.ietf.org/html/draft-ietf-opsec-v6
>=C2= =A0=C2=A0 "Operational Security Considerations for IPv6 Networks"= , Eric Vyncke,
>=C2=A0=C2=A0 Chittimaneni Kk, Merike Kaeo, Enno Rey, = 2019-03-11,
>
> I'd encourage people to read it and commen= t on the opec list.

One quick comment, in case no one pointed it out= : Section 2.3.3 refers
to I-D.ietf-dhc-sedhcpv6 as follows:

=C2= =A0=C2=A0 [...] Another way to secure
=C2=A0=C2=A0 DHCPv6 would be to us= e the secure DHCPv6 protocol which is currently
=C2=A0=C2=A0 work in pro= gress per [I-D.ietf-dhc-sedhcpv6] , but, with no real
=C2=A0=C2=A0 deplo= yment known by the authors of this document.

In my understanding, th= is draft is effectively dead rather than just
missing deployment.=C2=A0 = There may be yet another attempt of restarting it
in future, but I see n= o indication of it right now.=C2=A0 Even if the work
is eventually resta= rted it will be something completely different from
the current latest d= raft.=C2=A0 So I'd suggest either:
- just remove this sentence, or- if you want to keep the reference, make it more consistent with the
= =C2=A0 current situation, like:
=C2=A0=C2=A0=C2=A0 There was a proposal = of secure DHCPv6 protocol [I-D.ietf-dhc-sedhcpv6],
=C2=A0=C2=A0=C2=A0 bu= t the work has been effectively suspended and there is no
=C2=A0=C2=A0= =C2=A0 indication of a restart anytime soon.

--
JINMEI, Tatuya
--00000000000099736c05861c909a-- From nobody Tue Apr 9 14:32:12 2019 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 7E183120342; Tue, 9 Apr 2019 14:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mop4HsSnyE9b; Tue, 9 Apr 2019 14:31:59 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 7A35F1201BD; Tue, 9 Apr 2019 14:31:59 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id s39so157831edb.2; Tue, 09 Apr 2019 14:31:59 -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=JxgMzufMMBESMBkTouukq49avZQz9y5uxG1XP7OJjdE=; b=QlcjNRCaRU83wAHzcVy1ACPozOneL0yaM5nTTgAeDxK6mIZK1bRELywFXk+COMYZr4 ycG0KBNzZJRk77Ktb8Lgfx2eyLzLpzmjxPT4X3XQZhGX56HcT8H+YqRjjEa/QTmqdYRO 5RN5zVKy6C/u4jB28mYQ3F+mwzzZLZpVBV/o9d9nLLv64rsk2FFWBAsX4lDoSYpZmWJ3 n1qlfYpbjBZhqblU3hncxBERLX7NrhBC+obNkEwH5Mnql98sNg3/dKojn4+O0KdSaXGy BhiJjMDJwBLsZYksAJGJwq9PD6hyg9TpGIAXmyFUIGqJxeDES4I6SDH5bXP8k1wVtkzE PiIg== 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=JxgMzufMMBESMBkTouukq49avZQz9y5uxG1XP7OJjdE=; b=G+BJuZ7SInJ12xHRWAYju+RExFsrTJx5lh/6Ebqs0fUpgR+9lNi6ZURUc5uEl08ul3 czUV637Qpg8RkjC7FgbhW0arQu867+JKXlYPqXUYLgt3fI5xwIUTImj37Nzz2j5u2xmK ktSQRhQ1CceoY4/1jeeZIvD9HnIhaH2ewGE3goc8mL27I0NTdxscJK43m2nQKNAiRUXz IzvtjtbaUNiNwZo0IqNmTTMrjMerowpAPqsj4xFyUJ8kkOrX/jojw73BrNB/Mxbdysix U44AiZ4WAkvgv42W2SUw69vMv6qlU9z7Rakyj55ODUwjoiCTOPEoH6Ju36PbhjfFFjV8 4AKA== X-Gm-Message-State: APjAAAW6h9jFzKrTw2aff1otD5x15H1cW43427A3Dv/szPIQBDipCbSw sDNUKPRpRLM8v9C7c1UAZd0= X-Google-Smtp-Source: APXvYqxXpi7WLL/PeOk4czbZSJxlL86D+BDew9s811c5BF+wEgNq/taNLr6KU9k49k8Pa8pejmUgIQ== X-Received: by 2002:a50:e610:: with SMTP id y16mr23618914edm.67.1554845517966; Tue, 09 Apr 2019 14:31:57 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:164::1002? ([2600:8802:5600:164::1002]) by smtp.gmail.com with ESMTPSA id k17sm6166921eja.41.2019.04.09.14.31.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 14:31:56 -0700 (PDT) From: Fred Baker Message-Id: <5D4BAD99-D920-4AAA-9E1D-A9C931BC73B1@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CCBEE20E-0239-4177-999F-43D20FBA4868"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 9 Apr 2019 14:31:54 -0700 In-Reply-To: Cc: IPv6 Operations , opsec@ietf.org To: =?utf-8?B?56We5piO6YGU5ZOJ?= References: X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [v6ops] draft-ietf-opsec-v6 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, 09 Apr 2019 21:32:02 -0000 --Apple-Mail=_CCBEE20E-0239-4177-999F-43D20FBA4868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I do subscribe, so this note may accomplish the goal. https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ says that = [I-D.ietf-dhc-sedhcpv6] is "dead" from the IESG's perspective. They have = asked for a revised draft, over two years ago, and none has been posted. > On Apr 9, 2019, at 10:48 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > (Note: I don't subscribe to opsec@ietf.org. So I expect this message > will be subject to moderation). >=20 > At Fri, 29 Mar 2019 06:18:37 +0100, > Fred Baker wrote: >=20 > > Yesterday, the authors of an opec draft asked us for comments on = their draft, which is in a second WGLC in opec (opsec@ietf.org). You may = have missed the character string: > > > > https://datatracker.ietf.org/doc/draft-ietf-opsec-v6 > > https://tools.ietf.org/html/draft-ietf-opsec-v6 > > "Operational Security Considerations for IPv6 Networks", Eric = Vyncke, > > Chittimaneni Kk, Merike Kaeo, Enno Rey, 2019-03-11, > > > > I'd encourage people to read it and comment on the opec list. >=20 > One quick comment, in case no one pointed it out: Section 2.3.3 refers > to I-D.ietf-dhc-sedhcpv6 as follows: >=20 > [...] Another way to secure > DHCPv6 would be to use the secure DHCPv6 protocol which is = currently > work in progress per [I-D.ietf-dhc-sedhcpv6] , but, with no real > deployment known by the authors of this document. >=20 > In my understanding, this draft is effectively dead rather than just > missing deployment. There may be yet another attempt of restarting it > in future, but I see no indication of it right now. Even if the work > is eventually restarted it will be something completely different from > the current latest draft. So I'd suggest either: > - just remove this sentence, or > - if you want to keep the reference, make it more consistent with the > current situation, like: > There was a proposal of secure DHCPv6 protocol = [I-D.ietf-dhc-sedhcpv6], > but the work has been effectively suspended and there is no > indication of a restart anytime soon. >=20 > -- > JINMEI, Tatuya = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_CCBEE20E-0239-4177-999F-43D20FBA4868 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+AFAlytD0oACgkQEhdRnd2G P+Cv8A/9FK/+mTQW3UyHAgj5SStBMDJScvWAFQbgYLqLFsclEcj+cg4Q5mXDldGb vN9jlSJM7jf8lS68DIELA2Y+44u3zRwelBOeIBtIq6VRyyxiV5q0uY5tPz+1Im7D 98a6toai1k/oVSRx7S25AaW3mxEGuApchNgpmR1HcTwsYtsIF5bif7VHM95/bZTe Pnpbki6AoRq+4Ijj8euCgUlBv+Qr4T5gNFd4XuLnVs9J6yKEDigJYLHA6cKamYN0 anNBUW8WgT4IHyF7pEI0+XSH1+BtdU6lCB6GEX28rrT91gyhxnCglzMaDrcccQE9 HnXMy+EcNc874apItKzIzF8Cp1bX3FC/tY1P2ush/ydXhKsh6Zf/beRFjs5my/nz EQkaR/HHU7b38UEBsNNEKXe/7XLIRI1M7heI18i9VFcWny1neJdLHyWfQrhTG7V5 /EDYXQh+1a9OEsEBWOpCDkVA8S0Eo6TQ/2lSiZAIZ45EDhnxHMCymo4e4+pDIc5b O0OeYRfNsSAXqWlS+GcmhqLjMFdZosonQy7R5XbwMLTPd9jft6ExzqIjWHUakrwp v+xsclt51kFZdwCKtGBOCS8ZYsyBbI6oGXZN8g4W+LEcLsLB76t67os5f0GOgGWx qkRjUY8hQ7GVUKMFSDgJNG6upLr2pDAbG/JxHQJYTNYq9v3qg0w= =Mumb -----END PGP SIGNATURE----- --Apple-Mail=_CCBEE20E-0239-4177-999F-43D20FBA4868-- From nobody Tue Apr 9 15:11:25 2019 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 9E8DE120089; Tue, 9 Apr 2019 15:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=PyPflBCA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=J8GNomgJ 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 hWNBy_6KtQ4S; Tue, 9 Apr 2019 15:11:19 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA90A120013; Tue, 9 Apr 2019 15:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13401; q=dns/txt; s=iport; t=1554847878; x=1556057478; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VrGJwFVcMfjCjZ/wnek0yn/d2atQ4PvYn8KszqaIwAo=; b=PyPflBCANSuEyZ5PAa8pl3e+bQiX+4Q9FVHKe7INp1y6bX10JaHDZadT l2PT+qBR2Nczwir1WFLiwSpWyuRmPpC8XL/oOqvegdfOlZJUgpZl4p7p/ 5z4R5u4R85Ddza5FSli1lndf/GsHlVZtoMUtOyjVoHj25Hm7qDSlJOb7p U=; IronPort-PHdr: =?us-ascii?q?9a23=3AaKN2ph0X/23VqeJ2smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGCt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8TgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdCCDV/TJ//xZCt8F8NHBxdo?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAAA0F61c/5NdJa1eBxoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVEFAQEBAQsBgT0pJwNoVCAECycKhASDRwOEUopWjA+JFoR?= =?us-ascii?q?KgS6BJANUDgEBGAEKCYRAAheFSSI0CQ0BAQMBAQkBAgECbRwMhUsCBAEBIR0?= =?us-ascii?q?BASwLAQ8CAQYCJBsDAgICHwYLFBECBA4FgyIBgRFMAxUBAgySR5BeAooUcYE?= =?us-ascii?q?vgnkBAQWBMQEDAg5BgwINC4IMAwWBMAGLRheBf4ERJx+CTD6CGkcBAQIBAYF?= =?us-ascii?q?KKhaCXTGCJopggjaELpQPNgkCiAKIPINEGoIGiXmIYJF1gUSMFwIEAgQFAg4?= =?us-ascii?q?BAQWBTziBVnAVOyoBgkGCCoEkAQiCQoUUhT9ygSiMdymBBQGBHwEB?= X-IronPort-AV: E=Sophos;i="5.60,331,1549929600"; d="scan'208,217";a="545767977" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2019 22:11:16 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x39MBGDx012553 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Apr 2019 22:11:16 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Apr 2019 17:11:16 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 9 Apr 2019 17:11:15 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 9 Apr 2019 18:11:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VrGJwFVcMfjCjZ/wnek0yn/d2atQ4PvYn8KszqaIwAo=; b=J8GNomgJSzHLXlIS6UmlnOURPQuHJ8FAAyiUWJHqj292gBl6pU537DXInS+WyH+h15U8oTOGmZ9EzgqrNRSmy0jPkZFRIkT5EsqIMdgN/HTkg6QuKL8ixAOWNWDb8B8qmXnbCNNUDL2Fne8uvVwIP7rczMBBwesHrA62scfTzIM= Received: from BN8PR11MB3601.namprd11.prod.outlook.com (20.178.219.23) by BN8PR11MB3796.namprd11.prod.outlook.com (20.178.221.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Tue, 9 Apr 2019 22:11:13 +0000 Received: from BN8PR11MB3601.namprd11.prod.outlook.com ([fe80::8c78:bc80:a926:7111]) by BN8PR11MB3601.namprd11.prod.outlook.com ([fe80::8c78:bc80:a926:7111%3]) with mapi id 15.20.1771.016; Tue, 9 Apr 2019 22:11:13 +0000 From: "Bernie Volz (volz)" To: Fred Baker CC: =?utf-8?B?56We5piO6YGU5ZOJ?= , IPv6 Operations , "opsec@ietf.org" Thread-Topic: [v6ops] draft-ietf-opsec-v6 Thread-Index: AQHU5e8Bxb92Qee7NU+s0MLwz0d7R6Y0a6XsgAAKx8Y= Date: Tue, 9 Apr 2019 22:11:13 +0000 Message-ID: <09BCBD8D-EFF0-4B07-A3A4-7F63C2E84960@cisco.com> References: , <5D4BAD99-D920-4AAA-9E1D-A9C931BC73B1@gmail.com> In-Reply-To: <5D4BAD99-D920-4AAA-9E1D-A9C931BC73B1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com; x-originating-ip: [24.233.121.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4fac8493-0853-4b7e-9a07-08d6bd3847c7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BN8PR11MB3796; x-ms-traffictypediagnostic: BN8PR11MB3796: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(39860400002)(346002)(376002)(366004)(199004)(189003)(2906002)(25786009)(256004)(6916009)(14454004)(5660300002)(82746002)(486006)(14444005)(76176011)(236005)(229853002)(53546011)(476003)(186003)(4326008)(3846002)(6116002)(26005)(6306002)(6506007)(6512007)(54896002)(6436002)(102836004)(2616005)(11346002)(446003)(606006)(966005)(478600001)(8676002)(81156014)(81166006)(6246003)(6486002)(33656002)(8936002)(97736004)(105586002)(561944003)(53936002)(54906003)(68736007)(99286004)(106356001)(71190400001)(86362001)(316002)(36756003)(71200400001)(66066001)(7736002)(83716004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3796; H:BN8PR11MB3601.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kt2guoV9EyMn0SyFtP5TGOaqsLpo04eXxXbv4vrWuFL8tNcKocQHk+zkWiXOlZHy2rWGe/4kZCm0Kz59HZ6CQxwfloRx0YwiPf0PXBTFB0YaxSGbyUfcmvWmKdV498j8CfGMlLCfs4Ptf9iRJ+ySoVYEtdK7ykh5ibeeo5byr0JAAz24Dx3OdZOg8yXfO37TG7dYUXyeVdXV0MsviOfCkBipbT3OLyKalbmGZBPqAHe4RwVkaJHkDrDOvZjRGh7rmgrWCshtVmwm3yLVbAL6R4zeNdo8COybzxyjPCIOghu+NczVXslDCfVgBdScqCN8V6tNmC5dPp6sbO18DVRNgUNv9XcVTgj+jROMP5djGwSmPNuDNDBbv3yaS4VrKA8v0PlB+qPW44ulCvBCp9etWq8e8f7dz40DKAsdbp6cRas= Content-Type: multipart/alternative; boundary="_000_09BCBD8DEFF04B07A3A47F63C2E84960ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4fac8493-0853-4b7e-9a07-08d6bd3847c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 22:11:13.7704 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3796 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [v6ops] draft-ietf-opsec-v6 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, 09 Apr 2019 22:11:23 -0000 --_000_09BCBD8DEFF04B07A3A47F63C2E84960ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYgaXMgZGVhZC4gVGhlcmUgYXJlIG5vIHBsYW5zIHRvIHdv cmsgb24gdGhpcyB0b3BpYyB3aXRoaW4gdGhlIGRoYyB3Zy4NCg0KUkZDODQxNeKAmXMgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMsIHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODQx NSNzZWN0aW9uLTIyLCBkaXNjdXNzZXMgb3B0aW9ucyAoaW5jbHVkaW5nIHVzZSBvZiBzYXZpKS4g VGhpcyBzZWN0aW9uIHdhcyBncmVhdGx5IGV4cGFuZGVkIG92ZXIgd2hhdCB3YXMgaW4gUkZDMzMx NS4NCg0KLSBCZXJuaWUgKGRoYyB3ZyBjby1jaGFpcikNCg0KT24gQXByIDksIDIwMTksIGF0IDU6 MzIgUE0sIEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbTxtYWlsdG86ZnJlZGJh a2VyLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCkkgZG8gc3Vic2NyaWJlLCBzbyB0aGlzIG5v dGUgbWF5IGFjY29tcGxpc2ggdGhlIGdvYWwuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LyBzYXlzIHRoYXQgW0ktRC5pZXRmLWRoYy1z ZWRoY3B2Nl0gaXMgImRlYWQiIGZyb20gdGhlIElFU0cncyBwZXJzcGVjdGl2ZS4gVGhleSBoYXZl IGFza2VkIGZvciBhIHJldmlzZWQgZHJhZnQsIG92ZXIgdHdvIHllYXJzIGFnbywgYW5kIG5vbmUg aGFzIGJlZW4gcG9zdGVkLg0KDQpPbiBBcHIgOSwgMjAxOSwgYXQgMTA6NDggQU0sIOelnuaYjumB lOWTiSA8amlubWVpQHdpZGUuYWQuanA8bWFpbHRvOmppbm1laUB3aWRlLmFkLmpwPj4gd3JvdGU6 DQoNCihOb3RlOiBJIGRvbid0IHN1YnNjcmliZSB0byBvcHNlY0BpZXRmLm9yZzxtYWlsdG86b3Bz ZWNAaWV0Zi5vcmc+LiAgU28gSSBleHBlY3QgdGhpcyBtZXNzYWdlDQp3aWxsIGJlIHN1YmplY3Qg dG8gbW9kZXJhdGlvbikuDQoNCkF0IEZyaSwgMjkgTWFyIDIwMTkgMDY6MTg6MzcgKzAxMDAsDQpG cmVkIEJha2VyIDxmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmZyZWRiYWtlci5pZXRm QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpZZXN0ZXJkYXksIHRoZSBhdXRob3JzIG9mIGFuIG9wZWMg ZHJhZnQgYXNrZWQgdXMgZm9yIGNvbW1lbnRzIG9uIHRoZWlyIGRyYWZ0LCB3aGljaCBpcyBpbiBh IHNlY29uZCBXR0xDIGluIG9wZWMgKG9wc2VjQGlldGYub3JnPG1haWx0bzpvcHNlY0BpZXRmLm9y Zz4pLiBZb3UgbWF5IGhhdmUgbWlzc2VkIHRoZSBjaGFyYWN0ZXIgc3RyaW5nOg0KDQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2VjLXY2DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vcHNlYy12Ng0KICJPcGVyYXRpb25hbCBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyBmb3IgSVB2NiBOZXR3b3JrcyIsIEVyaWMgVnluY2tlLA0KIENo aXR0aW1hbmVuaSBLaywgTWVyaWtlIEthZW8sIEVubm8gUmV5LCAyMDE5LTAzLTExLA0KDQpJJ2Qg ZW5jb3VyYWdlIHBlb3BsZSB0byByZWFkIGl0IGFuZCBjb21tZW50IG9uIHRoZSBvcGVjIGxpc3Qu DQoNCk9uZSBxdWljayBjb21tZW50LCBpbiBjYXNlIG5vIG9uZSBwb2ludGVkIGl0IG91dDogU2Vj dGlvbiAyLjMuMyByZWZlcnMNCnRvIEktRC5pZXRmLWRoYy1zZWRoY3B2NiBhcyBmb2xsb3dzOg0K DQogIFsuLi5dIEFub3RoZXIgd2F5IHRvIHNlY3VyZQ0KICBESENQdjYgd291bGQgYmUgdG8gdXNl IHRoZSBzZWN1cmUgREhDUHY2IHByb3RvY29sIHdoaWNoIGlzIGN1cnJlbnRseQ0KICB3b3JrIGlu IHByb2dyZXNzIHBlciBbSS1ELmlldGYtZGhjLXNlZGhjcHY2XSAsIGJ1dCwgd2l0aCBubyByZWFs DQogIGRlcGxveW1lbnQga25vd24gYnkgdGhlIGF1dGhvcnMgb2YgdGhpcyBkb2N1bWVudC4NCg0K SW4gbXkgdW5kZXJzdGFuZGluZywgdGhpcyBkcmFmdCBpcyBlZmZlY3RpdmVseSBkZWFkIHJhdGhl ciB0aGFuIGp1c3QNCm1pc3NpbmcgZGVwbG95bWVudC4gIFRoZXJlIG1heSBiZSB5ZXQgYW5vdGhl ciBhdHRlbXB0IG9mIHJlc3RhcnRpbmcgaXQNCmluIGZ1dHVyZSwgYnV0IEkgc2VlIG5vIGluZGlj YXRpb24gb2YgaXQgcmlnaHQgbm93LiAgRXZlbiBpZiB0aGUgd29yaw0KaXMgZXZlbnR1YWxseSBy ZXN0YXJ0ZWQgaXQgd2lsbCBiZSBzb21ldGhpbmcgY29tcGxldGVseSBkaWZmZXJlbnQgZnJvbQ0K dGhlIGN1cnJlbnQgbGF0ZXN0IGRyYWZ0LiAgU28gSSdkIHN1Z2dlc3QgZWl0aGVyOg0KLSBqdXN0 IHJlbW92ZSB0aGlzIHNlbnRlbmNlLCBvcg0KLSBpZiB5b3Ugd2FudCB0byBrZWVwIHRoZSByZWZl cmVuY2UsIG1ha2UgaXQgbW9yZSBjb25zaXN0ZW50IHdpdGggdGhlDQogY3VycmVudCBzaXR1YXRp b24sIGxpa2U6DQogICBUaGVyZSB3YXMgYSBwcm9wb3NhbCBvZiBzZWN1cmUgREhDUHY2IHByb3Rv Y29sIFtJLUQuaWV0Zi1kaGMtc2VkaGNwdjZdLA0KICAgYnV0IHRoZSB3b3JrIGhhcyBiZWVuIGVm ZmVjdGl2ZWx5IHN1c3BlbmRlZCBhbmQgdGhlcmUgaXMgbm8NCiAgIGluZGljYXRpb24gb2YgYSBy ZXN0YXJ0IGFueXRpbWUgc29vbi4NCg0KLS0NCkpJTk1FSSwgVGF0dXlhDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpUaGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgaGlnaHdheSB0byBoZWxsIGFu ZCBhIHN0YWlyd2F5IHRvIGhlYXZlbiBpcyBhbiBpbnRlcmVzdGluZyBjb21tZW50IG9uIHByb2pl Y3RlZCB0cmFmZmljIHZvbHVtZS4uLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWls dG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzDQo= --_000_09BCBD8DEFF04B07A3A47F63C2E84960ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPmRy YWZ0LWlldGYtZGhjLXNlZGhjcHY2PC9zcGFuPiZuYnNwO2lzIGRlYWQuIFRoZXJlIGFyZSBubyBw bGFucyB0byB3b3JrIG9uIHRoaXMgdG9waWMgd2l0aGluIHRoZSBkaGMgd2cuDQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5SRkM4NDE14oCZcyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgc2VlJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0MTUjc2VjdGlvbi0y MiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0MTUjc2VjdGlvbi0yMjwvYT4sIGRp c2N1c3NlcyBvcHRpb25zIChpbmNsdWRpbmcgdXNlIG9mIHNhdmkpLiBUaGlzIHNlY3Rpb24gd2Fz IGdyZWF0bHkgZXhwYW5kZWQgb3ZlciB3aGF0IHdhcyBpbiBSRkMzMzE1LjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4tIEJlcm5pZSAoZGhjIHdnIGNvLWNo YWlyKTwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KT24gQXByIDksIDIwMTksIGF0IDU6MzIg UE0sIEZyZWQgQmFrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVkYmFrZXIuaWV0ZkBnbWFpbC5j b20iPmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj48c3Bhbj5JIGRv IHN1YnNjcmliZSwgc28gdGhpcyBub3RlIG1heSBhY2NvbXBsaXNoIHRoZSBnb2FsLjwvc3Bhbj48 YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYvIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni88L2E+IHNheXMgdGhhdCBb SS1ELmlldGYtZGhjLXNlZGhjcHY2XSBpcyAmcXVvdDtkZWFkJnF1b3Q7IGZyb20gdGhlIElFU0cn cyBwZXJzcGVjdGl2ZS4gVGhleSBoYXZlIGFza2VkIGZvciBhIHJldmlzZWQgZHJhZnQsIG92ZXIg dHdvIHllYXJzDQogYWdvLCBhbmQgbm9uZSBoYXMgYmVlbiBwb3N0ZWQuPC9zcGFuPjxicj4NCjxz cGFuPjwvc3Bhbj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5PbiBBcHIgOSwg MjAxOSwgYXQgMTA6NDggQU0sIOelnuaYjumBlOWTiSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppbm1l aUB3aWRlLmFkLmpwIj5qaW5tZWlAd2lkZS5hZC5qcDwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+KE5vdGU6IEkg ZG9uJ3Qgc3Vic2NyaWJlIHRvIDxhIGhyZWY9Im1haWx0bzpvcHNlY0BpZXRmLm9yZyI+DQpvcHNl Y0BpZXRmLm9yZzwvYT4uICZuYnNwO1NvIEkgZXhwZWN0IHRoaXMgbWVzc2FnZTwvc3Bhbj48YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj53aWxsIGJlIHN1 YmplY3QgdG8gbW9kZXJhdGlvbikuPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5BdCBGcmksIDI5IE1hciAyMDE5IDA2OjE4OjM3ICYjNDM7 MDEwMCw8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PHNwYW4+RnJlZCBCYWtlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZyZWRiYWtlci5pZXRmQGdtYWls LmNvbSI+ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxicj4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPlllc3RlcmRheSwgdGhlIGF1dGhvcnMgb2YgYW4gb3BlYyBkcmFmdCBh c2tlZCB1cyBmb3IgY29tbWVudHMgb24gdGhlaXIgZHJhZnQsIHdoaWNoIGlzIGluIGEgc2Vjb25k IFdHTEMgaW4gb3BlYyAoPGEgaHJlZj0ibWFpbHRvOm9wc2VjQGlldGYub3JnIj5vcHNlY0BpZXRm Lm9yZzwvYT4pLiBZb3UgbWF5IGhhdmUgbWlzc2VkIHRoZSBjaGFyYWN0ZXIgc3RyaW5nOjwvc3Bh bj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtb3BzZWMtdjYiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtb3BzZWMtdjY8L2E+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtb3BzZWMtdjYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2Vj LXY2PC9hPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiZuYnNwOyZx dW90O09wZXJhdGlvbmFsIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGZvciBJUHY2IE5ldHdvcmtz JnF1b3Q7LCBFcmljIFZ5bmNrZSw8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj4mbmJzcDtDaGl0dGltYW5lbmkgS2ssIE1lcmlrZSBLYWVvLCBFbm5vIFJleSwgMjAxOS0w My0xMSw8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5JJ2QgZW5jb3VyYWdlIHBlb3BsZSB0byBy ZWFkIGl0IGFuZCBjb21tZW50IG9uIHRoZSBvcGVjIGxpc3QuPC9zcGFuPjxicj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bh bj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5PbmUg cXVpY2sgY29tbWVudCwgaW4gY2FzZSBubyBvbmUgcG9pbnRlZCBpdCBvdXQ6IFNlY3Rpb24gMi4z LjMgcmVmZXJzPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxzcGFuPnRvIEktRC5pZXRmLWRoYy1zZWRoY3B2NiBhcyBmb2xsb3dzOjwvc3Bhbj48YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJy Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jm5ic3A7Jm5i c3A7Wy4uLl0gQW5vdGhlciB3YXkgdG8gc2VjdXJlPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiZuYnNwOyZuYnNwO0RIQ1B2NiB3b3VsZCBi ZSB0byB1c2UgdGhlIHNlY3VyZSBESENQdjYgcHJvdG9jb2wgd2hpY2ggaXMgY3VycmVudGx5PC9z cGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiZu YnNwOyZuYnNwO3dvcmsgaW4gcHJvZ3Jlc3MgcGVyIFtJLUQuaWV0Zi1kaGMtc2VkaGNwdjZdICwg YnV0LCB3aXRoIG5vIHJlYWw8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PHNwYW4+Jm5ic3A7Jm5ic3A7ZGVwbG95bWVudCBrbm93biBieSB0aGUgYXV0 aG9ycyBvZiB0aGlzIGRvY3VtZW50Ljwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SW4gbXkgdW5kZXJzdGFuZGluZywgdGhpcyBkcmFmdCBp cyBlZmZlY3RpdmVseSBkZWFkIHJhdGhlciB0aGFuIGp1c3Q8L3NwYW4+PGJyPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+bWlzc2luZyBkZXBsb3ltZW50LiAm bmJzcDtUaGVyZSBtYXkgYmUgeWV0IGFub3RoZXIgYXR0ZW1wdCBvZiByZXN0YXJ0aW5nIGl0PC9z cGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmlu IGZ1dHVyZSwgYnV0IEkgc2VlIG5vIGluZGljYXRpb24gb2YgaXQgcmlnaHQgbm93LiAmbmJzcDtF dmVuIGlmIHRoZSB3b3JrPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPmlzIGV2ZW50dWFsbHkgcmVzdGFydGVkIGl0IHdpbGwgYmUgc29tZXRo aW5nIGNvbXBsZXRlbHkgZGlmZmVyZW50IGZyb208L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+dGhlIGN1cnJlbnQgbGF0ZXN0IGRyYWZ0LiAm bmJzcDtTbyBJJ2Qgc3VnZ2VzdCBlaXRoZXI6PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPi0ganVzdCByZW1vdmUgdGhpcyBzZW50ZW5jZSwg b3I8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+LSBpZiB5b3Ugd2FudCB0byBrZWVwIHRoZSByZWZlcmVuY2UsIG1ha2UgaXQgbW9yZSBjb25z aXN0ZW50IHdpdGggdGhlPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPiZuYnNwO2N1cnJlbnQgc2l0dWF0aW9uLCBsaWtlOjwvc3Bhbj48YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4mbmJzcDsmbmJz cDsmbmJzcDtUaGVyZSB3YXMgYSBwcm9wb3NhbCBvZiBzZWN1cmUgREhDUHY2IHByb3RvY29sIFtJ LUQuaWV0Zi1kaGMtc2VkaGNwdjZdLDwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDtidXQgdGhlIHdvcmsgaGFz IGJlZW4gZWZmZWN0aXZlbHkgc3VzcGVuZGVkIGFuZCB0aGVyZSBpcyBubzwvc3Bhbj48YnI+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4mbmJzcDsmbmJzcDsm bmJzcDtpbmRpY2F0aW9uIG9mIGEgcmVzdGFydCBhbnl0aW1lIHNvb24uPC9zcGFuPjxicj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4tLTwvc3Bhbj48YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5KSU5NRUksIFRh dHV5YTwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyPg0KPHNwYW4+VGhlIGZhY3QgdGhhdCB0 aGVyZSBpcyBhIGhpZ2h3YXkgdG8gaGVsbCBhbmQgYSBzdGFpcndheSB0byBoZWF2ZW4gaXMgYW4g aW50ZXJlc3RpbmcgY29tbWVudCBvbiBwcm9qZWN0ZWQgdHJhZmZpYyB2b2x1bWUuLi48L3NwYW4+ PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj48c3Bhbj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj52Nm9wcyBtYWls aW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3Jn Ij52Nm9wc0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_09BCBD8DEFF04B07A3A47F63C2E84960ciscocom_-- From nobody Tue Apr 9 17:37:35 2019 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 2983D120123 for ; Tue, 9 Apr 2019 17:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gkEPBrHahUCZ for ; Tue, 9 Apr 2019 17:37:30 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 D1DBC1200DE for ; Tue, 9 Apr 2019 17:37:29 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id e5so325198otk.12 for ; Tue, 09 Apr 2019 17:37:29 -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 :content-transfer-encoding:message-id:references:to; bh=PfgqZY76uHvG3ps3OWRR1vFOrQ7WFCo7vc9ocbzjOFc=; b=KocyoXZcmJlmTdBNnxnrZuyUgG7ZNdyTX1CoteRShB9wzu5UphuxtsgFT7XY0ofhml bwniKE3NR9XOjyOF2wgpbGc2QxNVWtVKHxwpBiRAripA3IkPvjoOaM5apWoKTyMFqt5N 4JuyqxC9zlhFMpsp/N38WEwpFJEP8mathXOMVe3cIHVxrvWKelOlfzhAfzG/XjqL63gd oQO+CofO1tY1tx0CGylkjla24PU/7ePGcbVYtUQjiJ+FurF+Nx1gHatuA+8covOcDPpo 5OhhFGLbcP9U7V9jY6cPaYl4YAbosNW4uyKyML5lKBHHkvCRyopf8CJgO41JfTLrtu9+ PYdw== 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 :content-transfer-encoding:message-id:references:to; bh=PfgqZY76uHvG3ps3OWRR1vFOrQ7WFCo7vc9ocbzjOFc=; b=L5MslKARp6Qg6N5wcZAwLIa1w8o7QGrC2nZhDUf19OwvcNuYU34L3YtUiq2stXluHa 7oYdEqOhv7PAGjbgNFQLW1o9wiACrDSBce7OEIIIQGzJ+xfvyMICH/vywwU0ffpDIIZC DybnxXg2XF2EQVapGvrAbS4hw5e4YC9yoLQC+NGeF4dDRWy/2evhLWP7qUlOcuM+h/oV nwH4rcWsEEeF890Yz4jdPQTVO9rMm5pK0GSozxgSigWx0Yn3RXkUI1qCXKcwtfVT8KLB uGnVTNw4ERUfxm++MNeoChCU4FuJ05UMeYSUoVFCEzvye69DThMaLL5eJi+bf1QXXuZw lz/Q== X-Gm-Message-State: APjAAAVd4vnXWGE1RJdkdwb3sP0j3Y42zEpzEtS7z3NbSNi/c4sLNImu cgi8JWOu3SKd4Y4rX2GDX9m7dQvc X-Google-Smtp-Source: APXvYqw7ELn+T7rTKUWur1v6lBTW1kU+G3NPJJwR66DxhX1Bj97982Dv2jjev4AKBcCG/OSy9IgY1Q== X-Received: by 2002:a9d:4e1a:: with SMTP id p26mr25850356otf.116.1554856648997; Tue, 09 Apr 2019 17:37:28 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:164::1004? ([2600:8802:5600:164::1004]) by smtp.gmail.com with ESMTPSA id b24sm13334231oti.29.2019.04.09.17.37.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 17:37:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPhone Mail (16F5129d) In-Reply-To: <11DA6245-76CB-4DBD-B0EB-11ADA7BA00AE@consulintel.es> Date: Tue, 9 Apr 2019 17:37:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62D9F3DE-2712-48D8-BFAA-8DF67C925190@gmail.com> References: <11DA6245-76CB-4DBD-B0EB-11ADA7BA00AE@consulintel.es> To: "v6ops@ietf.org" Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 10 Apr 2019 00:37:33 -0000 For the record, the question here is two-fold. First, is it correct and comp= lete? Is there more, or less, that should be said? Second, are there operato= rs -ISPs, IxPs, enterprise, or whatever, that consider this useful in their d= eployments? > On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ wrote: >=20 > Hi Ron, >=20 > I'm not aware of any IPR on this document. >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BFEl 8/4/19 17:54, "v6ops en nombre de Ron Bonica" escribi=C3=B3: >=20 > Folks, >=20 > This email initiates a Working Group Last call on draft-ietf-v6ops-nat6= 4-deployment-04. WGLC will end at COB, April 22, 2019. >=20 > Authors, >=20 > Please respond to this message indicating whether you are aware of any I= PR regarding this draft. >=20 > R= on >=20 >=20 > Juniper Internal >=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 Mon Apr 15 16:31:32 2019 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 2CF451201BF for ; Mon, 15 Apr 2019 16:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecentro.net.ar 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 LMEXoe47KnDQ for ; Mon, 15 Apr 2019 16:31:28 -0700 (PDT) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4365C12022D for ; Mon, 15 Apr 2019 16:31:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 264013200604; Mon, 15 Apr 2019 20:31:25 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id R-GfIgk5eZI3; Mon, 15 Apr 2019 20:31:23 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 87C2A3201CDB; Mon, 15 Apr 2019 20:31:23 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 87C2A3201CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1555371083; bh=/i+o6xpkcdbfH9uXk6NcwbqbDygn8DcQPh0si1BhkBg=; h=Date:From:To:Message-ID:MIME-Version; b=Fb1rKrNCpqXB9qg0+KiN08sTbGOXwsM60syc1V3A9fEVCKgOXTtEbmWRA6LkmL8uP wZsxQdgsPacJKzUPouTXNa4K7geCHwQiNrHow9o8etDtPvaOJtzQpvf7QZvA01k3DN cPA1uz28O3aSvvt5Z/F4rBdMGjvEyUVuCtOG6foP6aPznp2uTybiMK1Bl8wY8D4cwr c9CjvB91FqsjqWCOZD87z19GDa6RddsTvL67twqRHTFw8g9+z9Wl6qZWcT5rnVpfij mpQo6cLKozCkROOn9mXBazwqGftMLeBCltJhj+hKsc4YgFKbQ1OHCT7QtxYpYoCDmM MRT7TIqzt27TA== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WxMTgFI28nL5; Mon, 15 Apr 2019 20:31:23 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 6CC9A3200604; Mon, 15 Apr 2019 20:31:23 -0300 (-03) Date: Mon, 15 Apr 2019 20:31:23 -0300 (ART) From: Alejandro D'Egidio To: Fred Baker Cc: "v6ops@ietf.org list" Message-ID: <893204406.85487280.1555371083358.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <62D9F3DE-2712-48D8-BFAA-8DF67C925190@gmail.com> References: <11DA6245-76CB-4DBD-B0EB-11ADA7BA00AE@consulintel.es> <62D9F3DE-2712-48D8-BFAA-8DF67C925190@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC73 (Win)/8.8.8_GA_1703) Thread-Topic: WGLC: draft-ietf-v6ops-nat64-deployment-04 Thread-Index: 7Tz9FdieDg2il7waECYwxA8ctI+3lg== Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 15 Apr 2019 23:31:31 -0000 Hello, >From my point of view, I think this document is really useful. In my case, I consider 464XLAT as a very good solution and in fact I alread= y have a cablemodem with a FW with CLAT and it works perfectly! Regarding the content. In "possible communication paths" for both cases with and without DNS64, we= have this option: " c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected that services are deployed in Internet using IPv6-only, unless there is certainty that peers will also be IPv6-capable. " If we consider EAMT (RFC7757) as we are suggesting in draft-palet-v6ops-464= xlat-opt-cdn-caches-01 it could be possible. Maybe you can add some note that It is possible if we CPE supports EAMT all= owing to connect IPv4-only devices/apps to IPv6 services. Regards, Alejandro ----- Mensaje original ----- De: "Fred Baker" Para: "v6ops@ietf.org list" Enviados: Martes, 9 de Abril 2019 21:37:26 Asunto: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 For the record, the question here is two-fold. First, is it correct and com= plete? Is there more, or less, that should be said? Second, are there opera= tors -ISPs, IxPs, enterprise, or whatever, that consider this useful in the= ir deployments? > On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ wrote: >=20 > Hi Ron, >=20 > I'm not aware of any IPR on this document. >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BFEl 8/4/19 17:54, "v6ops en nombre de Ron Bonica" escribi=C3=B3= : >=20 > Folks, >=20 > This email initiates a Working Group Last call on draft-ietf-v6ops-nat= 64-deployment-04. WGLC will end at COB, April 22, 2019. >=20 > Authors, >=20 > Please respond to this message indicating whether you are aware of any= IPR regarding this draft. >=20 > = Ron >=20 >=20 > Juniper Internal >=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 c= onfidential. 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 co= nsidered 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 prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal 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 From nobody Tue Apr 16 00:09:58 2019 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 51B53120134 for ; Tue, 16 Apr 2019 00:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 eLojWNSTEPLq for ; Tue, 16 Apr 2019 00:09:54 -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 CCACA120108 for ; Tue, 16 Apr 2019 00:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555398590; x=1556003390; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=K4KjSxpihx0/potqzMhJS slOkTPgvomvVftdOeN1fKc=; b=TxuBGc2rl0R6xzRKLSuYe38L2FI6twPcCYGwV 7sn3QCTVmYzxE8+HptS6iQgjnyxK3zk30CbUW+P4Giuz0c8t8Ghp5yrVlnT8Mn5R yiqsjJ6IZlZxc1OIxFFrUux4LYTdKq3r+Xoeo+eadFGzUxjAGeajH66jiTNWXi2O MPR5IA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 16 Apr 2019 09:09:50 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 16 Apr 2019 09:09:50 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006221003.msg for ; Tue, 16 Apr 2019 09:09:48 +0200 X-MDRemoteIP: 2001:470:1f09:495:94bb:21cf:eb3b:cc68 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Tue, 16 Apr 2019 09:09:48 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=100922cfbb=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.8.190312 Date: Tue, 16 Apr 2019 09:09:48 +0200 From: JORDI PALET MARTINEZ To: Alejandro D'Egidio , Fred Baker CC: "v6ops@ietf.org list" Message-ID: <1302AFA4-A976-45AC-9F63-AD8F82D02BDB@consulintel.es> Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 07:09:56 -0000 Hi Alejandro, Thanks for your support. I understand that you want to see this document pu= blished, just to make it sure. Regards, Jordi =20 =20 =EF=BB=BFEl 16/4/19 1:31, "v6ops en nombre de Alejandro D'Egidio" = escribi=C3=B3: Hello, >From my point of view, I think this document is really useful. In my case, I consider 464XLAT as a very good solution and in fact I al= ready have a cablemodem with a FW with CLAT and it works perfectly! =20 Regarding the content. =20 In "possible communication paths" for both cases with and without DNS64= , we have this option: " c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected th= at services are deployed in Internet using IPv6-only, unless there is certainty that peers will also be IPv6-capable. " =20 If we consider EAMT (RFC7757) as we are suggesting in draft-palet-v6ops= -464xlat-opt-cdn-caches-01 it could be possible. =20 Maybe you can add some note that It is possible if we CPE supports EAMT= allowing to connect IPv4-only devices/apps to IPv6 services. In the last version, the only change is a section for EAMT. So, what I can = do is a call in "c" to that section. The reason for not having more explicit text about EAMT, is that this secti= on is talking about the "actual" 464XLAT (RFC6877) support. So, rewording i= t for a "future possible update of 464XLAT that include a MUST for EAMT sup= port", will not be acceptable. =20 =20 Regards, Alejandro =20 ----- Mensaje original ----- De: "Fred Baker" Para: "v6ops@ietf.org list" Enviados: Martes, 9 de Abril 2019 21:37:26 Asunto: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 =20 For the record, the question here is two-fold. First, is it correct and= complete? Is there more, or less, that should be said? Second, are there o= perators -ISPs, IxPs, enterprise, or whatever, that consider this useful in= their deployments? =20 > On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ wrote: >=20 > Hi Ron, >=20 > I'm not aware of any IPR on this document. >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BFEl 8/4/19 17:54, "v6ops en nombre de Ron Bonica" escribi= =C3=B3: >=20 > Folks, >=20 > This email initiates a Working Group Last call on draft-ietf-v6ops= -nat64-deployment-04. WGLC will end at COB, April 22, 2019. >=20 > Authors, >=20 > Please respond to this message indicating whether you are aware of= any IPR regarding this draft. >=20 > = Ron >=20 >=20 > Juniper Internal >=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 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 _______________________________________________ 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 Tue Apr 16 05:24:12 2019 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 4B820120320 for ; Tue, 16 Apr 2019 05:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=telecentro.net.ar 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 c2ox0SL6crSq for ; Tue, 16 Apr 2019 05:24:06 -0700 (PDT) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0011200C3 for ; Tue, 16 Apr 2019 05:24:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 548F53201E22; Tue, 16 Apr 2019 09:24:03 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id I2_ywqTfLgwi; Tue, 16 Apr 2019 09:24:02 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id EA84F3201E8F; Tue, 16 Apr 2019 09:24:01 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar EA84F3201E8F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1555417442; bh=DAbZKmsASEzZgrnBcWRtkGJTrGIreJM+ptjF3tyGIOQ=; h=Date:From:To:Message-ID:MIME-Version; b=f06vyZ3cTaoKj9yqBKrRFUL1anpR7YKRraTVBoUDDZgrRn54Tu/eW/mDR/KLD2+xU zDiEC5aBwiLsBSIS/H64QsZUi2S7NRARc8H1CQey8fXivEZB/dRe2NSiJupA4dva0N T9jU1o3yn0E5rKpvoC9iuWAKmq0n1BgZWrSHOnNQFu8lx5jCL90zr+wdjBNnIh1BzR o8d2zxTQWgkQfSirCe/tA24WERlcqwKkCswAw8yMSzQrsknYv7F+FQahugtZH2bSYK /HueYWrUoXiOrWYve5N+RF5CRjDABfYNZtABkdmv0b3T+GWKcqQEE3U1OXwGWN4JOf atythP8CmK2LA== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Yb6cTUJYYjVP; Tue, 16 Apr 2019 09:24:01 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 0292E320208F; Tue, 16 Apr 2019 09:24:01 -0300 (-03) Date: Tue, 16 Apr 2019 09:24:00 -0300 (ART) From: Alejandro D'Egidio To: JORDI PALET MARTINEZ Cc: Fred Baker , "v6ops@ietf.org list" Message-ID: <912345910.89785335.1555417440276.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <1302AFA4-A976-45AC-9F63-AD8F82D02BDB@consulintel.es> References: <1302AFA4-A976-45AC-9F63-AD8F82D02BDB@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC73 (Win)/8.8.8_GA_1703) Thread-Topic: WGLC: draft-ietf-v6ops-nat64-deployment-04 Thread-Index: e8oiLyqQSWu8f1nOFlOycJCbq6EtAw== Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 12:24:10 -0000 Hello Jordi, Yes, I would like to see this document published. Regards, Alejandro ----- Mensaje original ----- > De: "JORDI PALET MARTINEZ" > Para: "Alejandro Degidio" , "Fred Baker" > CC: "v6ops@ietf.org list" > Enviados: Martes, 16 de Abril 2019 4:09:48 > Asunto: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 > Hi Alejandro, >=20 > Thanks for your support. I understand that you want to see this document > published, just to make it sure. >=20 >=20 >=20 > Regards, > Jordi >=20 >=20 >=20 >=EF=BB=BFEl 16/4/19 1:31, "v6ops en nombre de Alejandro D'Egidio" =EF=BB=BFen nombre de adegidio=3D40telecentro.net.ar@dmarc.ietf.org> escri= bi=C3=B3: >=20 > Hello, > >From my point of view, I think this document is really useful. > In my case, I consider 464XLAT as a very good solution and in fact I a= lready > have a cablemodem with a FW with CLAT and it works perfectly! > =20 > Regarding the content. > =20 > In "possible communication paths" for both cases with and without DNS6= 4, we have > this option: > " c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected t= hat > services are deployed in Internet using IPv6-only, unless there > is certainty that peers will also be IPv6-capable. > " > =20 > If we consider EAMT (RFC7757) as we are suggesting in > draft-palet-v6ops-464xlat-opt-cdn-caches-01 it could be possible. > =20 > Maybe you can add some note that It is possible if we CPE supports EAM= T allowing > to connect IPv4-only devices/apps to IPv6 services. >=20 > In the last version, the only change is a section for EAMT. So, what I ca= n do is > a call in "c" to that section. Yes, I think it's ok if you add a call in that point. >=20 > The reason for not having more explicit text about EAMT, is that this sec= tion is > talking about the "actual" 464XLAT (RFC6877) support. So, rewording it fo= r a > "future possible update of 464XLAT that include a MUST for EAMT support",= will > not be acceptable. >=20 > =20 > =20 > Regards, > Alejandro > =20 > ----- Mensaje original ----- > De: "Fred Baker" > Para: "v6ops@ietf.org list" > Enviados: Martes, 9 de Abril 2019 21:37:26 > Asunto: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 > =20 > For the record, the question here is two-fold. First, is it correct an= d > complete? Is there more, or less, that should be said? Second, are the= re > operators -ISPs, IxPs, enterprise, or whatever, that consider this use= ful in > their deployments? > =20 > > On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ > > wrote: > >=20 > > Hi Ron, > >=20 > > I'm not aware of any IPR on this document. > >=20 > > Regards, > > Jordi > >=20 > >=20 > >=20 > > =EF=BB=BFEl 8/4/19 17:54, "v6ops en nombre de Ron Bonica" > =EF=BB=BFnombre de rbonica=3D40juniper.net@dmarc.ietf.org> escribi= =C3=B3: > >=20 > > Folks, > >=20 > > This email initiates a Working Group Last call on > > draft-ietf-v6ops-nat64-deployment-04. WGLC will end at COB, April= 22, 2019. > >=20 > > Authors, > >=20 > > Please respond to this message indicating whether you are aware o= f any IPR > > regarding this draft. > >=20 > > = Ron > >=20 > >=20 > > Juniper Internal > >=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 > > confidential. The information is intended to be for the exclusive us= e of the > > individual(s) named above and further non-explicilty authorized disc= losure, > > copying, distribution or use of the contents of this information, ev= en 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 strictl= y > > 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 > =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 > confidential. The information is intended to be for the exclusive use of = the > individual(s) named above and further non-explicilty authorized disclosur= e, > 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 a= ware > 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 t= he > original sender to inform about this communication and delete it. From nobody Tue Apr 16 06:10:26 2019 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 23B73120362 for ; Tue, 16 Apr 2019 06:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ykqsX_uJPAsI for ; Tue, 16 Apr 2019 06:10:23 -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 1EA4C12002E for ; Tue, 16 Apr 2019 06:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555420219; x=1556025019; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=lymphyRjqVWhy1EUrZJqH AQeq4QadKbQMN16mqISmGo=; b=YXx8+SL1wafOBrzZtUaSJRLdjqPVws6pt4OD3 bJsLxlNjTDAvEoCoYrbLVdeDkzm/3mLCaDJHP0heVdix0KB1zS2ijF601ctXFevL C9ZS7BQQ74oD3M+xfd3HlFvhttGc6CpPZ8J1LCHOCBJXKck9/ERu7nxx7X10W/LE jGFVhI= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 16 Apr 2019 15:10:19 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 16 Apr 2019 15:10:18 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006221301.msg for ; Tue, 16 Apr 2019 15:10:17 +0200 X-MDRemoteIP: 2001:470:1f09:495:11c:bfce:3ad8:91e6 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Tue, 16 Apr 2019 15:10:17 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=100922cfbb=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.8.190312 Date: Tue, 16 Apr 2019 15:10:12 +0200 From: JORDI PALET MARTINEZ To: Alejandro D'Egidio CC: "v6ops@ietf.org list" Message-ID: <7F022EB1-6C84-4B46-914A-335AEFD3DD3F@consulintel.es> Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 13:10:25 -0000 Hi Alejandro, I've a draft v05 with the following changes to address this at section 3.1.= 2: The possible communication paths, among the IPv4/IPv6 stacks of both peers, in this case, are: a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers. b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT implements EAMT as indicated by Section 4.11. In principle, it is not expected that services are deployed in Internet using IPv6-only, unless there is certainty that peers will also be IPv6-capable. d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 translations. e. Local-IPv4 to Remote-dual-stack using EAMT optimization: If the CLAT implements EAMT as indicated by Section 4.11, instead of using the path d. above, NAT64 is avoided and the flow will use IPv6 from the CLAT to the destination. The same text (c y e) apply to section 3.1.3. Also, added a new paragraph at the end of 4.11. EAMT Considerations Explicit Address Mappings for Stateless IP/ICMP Translation [RFC7757] provides a way to configure explicit mappings between IPv4 and IPv6 prefixes of any length. When this is used, for example in a CLAT, it may provide a simple mechanism in order to avoid traffic flows between IPv4-only nodes or applications and dual-stack destinations to be translated twice (NAT46 and NAT64), by creating mapping entries with the GUA of the IPv6-reachable destination. This optimization of the NAT64 usage is very useful in many scenarios, including CDNs and caches, as described in [I-D.palet-v6ops-464xlat-opt-cdn-caches]. In addition to that, it may provide as well a way for IPv4-only nodes or applications to communicate with IPv6-only destinations. I will wait for further comments and I understand that even if the last cal= l succedes, I can do those updates before a possible IETF LC. Thanks! Regards, Jordi =20 =20 =EF=BB=BFEl 16/4/19 14:24, "v6ops en nombre de Alejandro D'Egidio" = escribi=C3=B3: Hello Jordi, Yes, I would like to see this document published. =20 =20 Regards, Alejandro =20 =20 ----- Mensaje original ----- > De: "JORDI PALET MARTINEZ" > Para: "Alejandro Degidio" , "Fred Baker" = > CC: "v6ops@ietf.org list" > Enviados: Martes, 16 de Abril 2019 4:09:48 > Asunto: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 =20 > Hi Alejandro, >=20 > Thanks for your support. I understand that you want to see this docum= ent > published, just to make it sure. >=20 >=20 >=20 > Regards, > Jordi >=20 >=20 >=20 >=EF=BB=BFEl 16/4/19 1:31, "v6ops en nombre de Alejandro D'Egidio" =EF=BB=BFen nombre de adegidio=3D40telecentro.net.ar@dmarc.ietf.org> e= scribi=C3=B3: >=20 > Hello, > >From my point of view, I think this document is really useful. > In my case, I consider 464XLAT as a very good solution and in fact= I already > have a cablemodem with a FW with CLAT and it works perfectly! > =20 > Regarding the content. > =20 > In "possible communication paths" for both cases with and without = DNS64, we have > this option: > " c. Local-IPv4 to Remote-IPv6: Not possible. It is not expect= ed that > services are deployed in Internet using IPv6-only, unless t= here > is certainty that peers will also be IPv6-capable. > " > =20 > If we consider EAMT (RFC7757) as we are suggesting in > draft-palet-v6ops-464xlat-opt-cdn-caches-01 it could be possible. > =20 > Maybe you can add some note that It is possible if we CPE supports= EAMT allowing > to connect IPv4-only devices/apps to IPv6 services. >=20 > In the last version, the only change is a section for EAMT. So, what = I can do is > a call in "c" to that section. Yes, I think it's ok if you add a call in that point. =20 =20 >=20 > The reason for not having more explicit text about EAMT, is that this= section is > talking about the "actual" 464XLAT (RFC6877) support. So, rewording i= t for a > "future possible update of 464XLAT that include a MUST for EAMT suppo= rt", will > not be acceptable. >=20 > =20 > =20 > Regards, > Alejandro > =20 > ----- Mensaje original ----- > De: "Fred Baker" > Para: "v6ops@ietf.org list" > Enviados: Martes, 9 de Abril 2019 21:37:26 > Asunto: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 > =20 > For the record, the question here is two-fold. First, is it correc= t and > complete? Is there more, or less, that should be said? Second, are= there > operators -ISPs, IxPs, enterprise, or whatever, that consider this= useful in > their deployments? > =20 > > On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ > > wrote: > >=20 > > Hi Ron, > >=20 > > I'm not aware of any IPR on this document. > >=20 > > Regards, > > Jordi > >=20 > >=20 > >=20 > > =EF=BB=BFEl 8/4/19 17:54, "v6ops en nombre de Ron Bonica" > =EF=BB=BFnombre de rbonica=3D40juniper.net@dmarc.ietf.org> escri= bi=C3=B3: > >=20 > > Folks, > >=20 > > This email initiates a Working Group Last call on > > draft-ietf-v6ops-nat64-deployment-04. WGLC will end at COB, A= pril 22, 2019. > >=20 > > Authors, > >=20 > > Please respond to this message indicating whether you are awa= re of any IPR > > regarding this draft. > >=20 > > = Ron > >=20 > >=20 > > Juniper Internal > >=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 privil= eged or > > confidential. The information is intended to be for the exclusiv= e 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 recip= ient be aware > > that any disclosure, copying, distribution or use of the content= s of this > > information, even if partially, including attached files, is str= ictly > > prohibited, will be considered a criminal offense, so you must r= eply 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 > _______________________________________________ > 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 > confidential. The information is intended to be for the exclusive use= of the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n 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 _______________________________________________ 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 Tue Apr 16 06:37:29 2019 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 79D6F120021 for ; Tue, 16 Apr 2019 06:37:26 -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 W10fGEmQmrUI for ; Tue, 16 Apr 2019 06:37:23 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 A789B120371 for ; Tue, 16 Apr 2019 06:37:22 -0700 (PDT) Received: from [192.168.11.4] (pl22370.ag1212.nttpc.ne.jp [1.33.49.98]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x3GDb7Ua079268 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 16 Apr 2019 15:37:15 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host pl22370.ag1212.nttpc.ne.jp [1.33.49.98] claimed to be [192.168.11.4] To: v6ops@ietf.org References: <11DA6245-76CB-4DBD-B0EB-11ADA7BA00AE@consulintel.es> <62D9F3DE-2712-48D8-BFAA-8DF67C925190@gmail.com> From: =?UTF-8?Q?G=c3=a1bor_Lencse?= Message-ID: Date: Tue, 16 Apr 2019 22:37:06 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <62D9F3DE-2712-48D8-BFAA-8DF67C925190@gmail.com> Content-Type: multipart/alternative; boundary="------------54A81E9AB86BCC4D6C51DDDF" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=1.33.49.98; helo=[192.168.11.4]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 13:37:27 -0000 This is a multi-part message in MIME format. --------------54A81E9AB86BCC4D6C51DDDF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Jordi, I think your draft contains valuable material, and I support its publication as an RFC. I try to do my best to read it, but I cannot finish it today. While reading, I take notes below. The majority of them will be nits. The sign "-->" means a suggestion for correction. 1. Introduction: NAT64 ([RFC6146 ]) describes a stateful IPv6 to IPv4 translation, -->*Stateful* NAT64 ([RFC6146 ]) describes a stateful IPv6 to IPv4 translation, (Saying simply "NAT64" may include both stateful and stateless NAT64. If you do not want to write always "stateful NAT64", then perhaps you should explain in the beginning that you mean "stateful NAT64" under "NAT64".) Page 8.: Furthermore, as indicated in [RFC6877 ] (464XLAT),_can be used_ in broadband IPv6 network architectures, by implementing the CLAT functionality at the CE. I do not understand WHAT can be used. Perhaps you meant: Furthermore, as indicated in [RFC6877 ],*464XLAT can be used* in broadband IPv6 network architectures, by implementing the CLAT functionality at the CE. Page 9. c. Local-IPv4 to Remote-IPv6: Not possible._It is not expected that services are deployed in Internet using IPv6-only, unless there is certainty that peers will also be IPv6-capable._ Perhaps a philosophical question: When will it be expected? (How long shell we need to always consider IPv4?) Section 3.1.3. However, doesn't look a sensible approach from an Operating System or application vendor perspective, to provide IPv6-only support unless, similarly to c. above, there is certainty of peers supporting IPv6 as well. I understand, but I am not happy with that. I am not arguing with you but with this approach... Section 3.2. _In addition to the different pros, cons and trade-offs_, which may be acceptable for some operators, they have implementation difficulties, as they are beyond the original expectations of the NAT64/DNS64 original intent. You might want to refer to our I-D as an informative reference: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02 I have stopped reading at the beginning of Section 4 (because of my time zone), I hope to be able to continue tomorrow. Best regards, Gábor On 4/10/2019 09:37, Fred Baker wrote: > For the record, the question here is two-fold. First, is it correct and complete? Is there more, or less, that should be said? Second, are there operators -ISPs, IxPs, enterprise, or whatever, that consider this useful in their deployments? > >> On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ wrote: >> >> Hi Ron, >> >> I'm not aware of any IPR on this document. >> >> Regards, >> Jordi >> >> >> >> El 8/4/19 17:54, "v6ops en nombre de Ron Bonica" escribió: >> >> Folks, >> >> This email initiates a Working Group Last call on draft-ietf-v6ops-nat64-deployment-04. WGLC will end at COB, April 22, 2019. >> >> Authors, >> >> Please respond to this message indicating whether you are aware of any IPR regarding this draft. >> >> Ron >> >> >> Juniper Internal >> >> _______________________________________________ >> 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --------------54A81E9AB86BCC4D6C51DDDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear Jordi,

I think your draft contains valuable material, and I support its publication as an RFC. I try to do my best to read it, but I cannot finish it today.

While reading, I take notes below. The majority of them will be nits. The sign "-->" means a suggestion for correction.

1. Introduction:

  NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation, -->   Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation,

(Saying simply "NAT64" may include both stateful and stateless NAT64. If you do not want to write always "stateful NAT64", then perhaps you should explain in the beginning that you mean "stateful NAT64" under "NAT64".)

Page 8.:
   Furthermore, as indicated in [RFC6877] (464XLAT), can be used in
   broadband IPv6 network architectures, by implementing the CLAT
   functionality at the CE.
I do not understand WHAT can be used. Perhaps you meant:
   Furthermore, as indicated in [RFC6877], 464XLAT can be used in
   broadband IPv6 network architectures, by implementing the CLAT
   functionality at the CE.

Page 9.
   c.  Local-IPv4 to Remote-IPv6: Not possible.  It is not expected that
       services are deployed in Internet using IPv6-only, unless there
       is certainty that peers will also be IPv6-capable.

Perhaps a philosophical question: When will it be expected? (How long shell we need to always consider IPv4?)


Section 3.1.3.
However, doesn't
   look a sensible approach from an Operating System or application
   vendor perspective, to provide IPv6-only support unless, similarly to
   c.  above, there is certainty of peers supporting IPv6 as well.

I understand, but I am not happy with that. I am not arguing with you but with this approach...


Section 3.2.
In addition to the different pros, cons and
   trade-offs, which may be acceptable for some operators, they have
   implementation difficulties, as they are beyond the original
   expectations of the NAT64/DNS64 original intent.
You might want to refer to our I-D as an informative reference: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02


I have stopped reading at the beginning of Section 4 (because of my time zone), I hope to be able to continue tomorrow.

Best regards,

Gábor

On 4/10/2019 09:37, Fred Baker wrote:
For the record, the question here is two-fold. First, is it correct and complete? Is there more, or less, that should be said? Second, are there operators -ISPs, IxPs, enterprise, or whatever, that consider this useful in their deployments?


On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:

Hi Ron,

I'm not aware of any IPR on this document.

Regards,
Jordi



El 8/4/19 17:54, "v6ops en nombre de Ron Bonica" <v6ops-bounces@ietf.org en nombre de rbonica=40juniper.net@dmarc.ietf.org> escribió:

   Folks,

   This email initiates a Working Group Last call on draft-ietf-v6ops-nat64-deployment-04. WGLC will end at COB, April 22, 2019.

   Authors,

   Please respond to this message indicating whether you are aware of any IPR regarding this draft.

                                                                         Ron


   Juniper Internal

   _______________________________________________
   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

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------54A81E9AB86BCC4D6C51DDDF-- From nobody Tue Apr 16 08:51:03 2019 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 8F362120641 for ; Tue, 16 Apr 2019 08:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, 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 Z5Rm0AMbD3d3 for ; Tue, 16 Apr 2019 08:50:50 -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 F0DA2120674 for ; Tue, 16 Apr 2019 07:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555424829; x=1556029629; 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=xkQo9EFAp0onwivmy1bE+Pq1wDmI6heJkk fFhYhbpYs=; b=er6+fwXACFyPG0OCaSXaqHfLi+2utL9O0k9YIEhHWE0cjjWuct pbDK/KqWMJ37xhcvq9MA4gVrDlowFhx+H5PEj0qCl0h911oa6T7ohNZuRu3R5s4c X2syG0ECF6uLseyhoQy7ksuogSrH28Y8tSfSr3QL0RrGlimKf9LXAqFgY= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 16 Apr 2019 16:27:09 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 16 Apr 2019 16:27:08 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006221369.msg for ; Tue, 16 Apr 2019 16:27:07 +0200 X-MDRemoteIP: 2001:470:1f09:495:11c:bfce:3ad8:91e6 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Tue, 16 Apr 2019 16:27:07 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=100922cfbb=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.8.190312 Date: Tue, 16 Apr 2019 16:27:05 +0200 From: JORDI PALET MARTINEZ To: =?UTF-8?B?R8OhYm9y?= Lencse , Message-ID: <2C7133B6-2E91-47EF-931F-594F61F7D665@consulintel.es> Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 References: <11DA6245-76CB-4DBD-B0EB-11ADA7BA00AE@consulintel.es> <62D9F3DE-2712-48D8-BFAA-8DF67C925190@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3638276825_680081145" Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 15:50:55 -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_3638276825_680081145 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Gabor, =20 Thanks a lot! =20 Responding below in-line. Regards, Jordi =20 =20 =20 El 16/4/19 15:38, "v6ops en nombre de G=C3=A1bor Lencse" escribi=C3=B3: =20 Dear Jordi, I think your draft contains valuable material, and I support its publicatio= n as an RFC. I try to do my best to read it, but I cannot finish it today. While reading, I take notes below. The majority of them will be nits. The s= ign "-->" means a suggestion for correction. 1. Introduction: =C2=A0 NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation, -->= =C2=A0=C2=A0Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 t= ranslation, (Saying simply "NAT64" may include both stateful and stateless NAT64. If yo= u do not want to write always "stateful NAT64", then perhaps you should exp= lain in the beginning that you mean "stateful NAT64" under "NAT64".) I=E2=80=99ve now addressed this in v05, thanks! Page 8.: =C2=A0=C2=A0 Furthermore, as indicated in [RFC6877] (464XLAT), can be used = in =C2=A0=C2=A0 broadband IPv6 network architectures, by implementing the CLAT =C2=A0=C2=A0 functionality at the CE. I do not understand WHAT can be used. Perhaps you meant: =C2=A0=C2=A0 Furthermore, as indicated in [RFC6877], 464XLAT can be used in =C2=A0=C2=A0 broadband IPv6 network architectures, by implementing the CLAT =C2=A0=C2=A0 functionality at the CE. =20 Done! =20 Page 9. =C2=A0=C2=A0 c.=C2=A0 Local-IPv4 to Remote-IPv6: Not possible.=C2=A0 It is = not expected that =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 services are deployed in Internet usin= g IPv6-only, unless there =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is certainty that peers will also be I= Pv6-capable. =20 Perhaps a philosophical question: When will it be expected? (How long shell= we need to always consider IPv4?) =20 I don=E2=80=99t think this is something to be discussed in this document, h= owever, this text has changed in v05, see my earlier response with new text= to Alejandro. Anyway, I=E2=80=99m happy to amend it again, if the WG belie= ves we should enter into philosophical discussions =E2=80=A6 =20 Section 3.1.3. However, doesn't =C2=A0=C2=A0 look a sensible approach from an Operating System or applicati= on =C2=A0=C2=A0 vendor perspective, to provide IPv6-only support unless, simil= arly to =C2=A0=C2=A0 c.=C2=A0 above, there is certainty of peers supporting IPv6 as= well. =20 I understand, but I am not happy with that. I am not arguing with you but w= ith this approach...=20 =20 I=E2=80=99m not sure to understand your point here. Should I explicitly say= that providing IPv6-only for an OS is a bad thing? That is contradictory w= ith your previous philosophical discussion =E2=80=A6 Maybe you want to sugg= est some specific wording so I can get your point better? =20 =20 =20 Section 3.2. In addition to the different pros, cons and =C2=A0=C2=A0 trade-offs, which may be acceptable for some operators, they h= ave =C2=A0=C2=A0 implementation difficulties, as they are beyond the original =C2=A0=C2=A0 expectations of the NAT64/DNS64 original intent. You might want to refer to our I-D as an informative reference: https://too= ls.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02 =20 Yes, good point :-) =20 I have stopped reading at the beginning of Section 4 (because of my time zo= ne), I hope to be able to continue tomorrow. =20 Thanks again! =20 Best regards, =20 G=C3=A1bor =20 On 4/10/2019 09:37, Fred Baker wrote: For the record, the question here is two-fold. First, is it correct and com= plete? Is there more, or less, that should be said? Second, are there opera= tors -ISPs, IxPs, enterprise, or whatever, that consider this useful in the= ir deployments? =20 On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ wrote: =20 Hi Ron, =20 I'm not aware of any IPR on this document. =20 Regards, Jordi =20 =20 =20 =EF=BB=BFEl 8/4/19 17:54, "v6ops en nombre de Ron Bonica" escribi=C3=B3: =20 =C2=A0=C2=A0 Folks, =20 =C2=A0=C2=A0 This email initiates a Working Group Last call on draft-ietf-v= 6ops-nat64-deployment-04. WGLC will end at COB, April 22, 2019. =20 =C2=A0=C2=A0 Authors, =20 =C2=A0=C2=A0 Please respond to this message indicating whether you are awar= e of any IPR regarding this draft. =20 =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=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=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron =20 =20 =C2=A0=C2=A0 Juniper Internal =20 =C2=A0=C2=A0 _______________________________________________ =C2=A0=C2=A0 v6ops mailing list =C2=A0=C2=A0 v6ops@ietf.org =C2=A0=C2=A0 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 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. =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 _______________________________________________ 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_3638276825_680081145 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Gabor,

 

Thanks a lot!=

 

Responding below in-line.


Regards= ,

= Jordi

 

 

 

El 16/4/19 15= :38, "v6ops en nombre de G=C3=A1bor Lencse" <v6ops-bounces@ietf.org en nombre de lencse@hit.bme.hu> escribi=C3=B3:

<= o:p> 

Dear Jordi,<= /o:p>

I think your draft contains valuab= le material, and I support its publication as an RFC. I try to do my best t= o read it, but I cannot finish it today.

While reading, I take notes below. The majority of them will be= nits. The sign "-->" means a suggestion for correction.<= /o:p>

1. Introduction:

=C2=A0 NAT64 ([RFC6146]) desc= ribes a stateful IPv6 to IPv4 translation, --> =C2=A0=C2=A0Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 trans= lation,

(Saying simply &quo= t;NAT64" may include both stateful and stateless NAT64. If you do not = want to write always "stateful NAT64", then perhaps you should ex= plain in the beginning that you mean "stateful NAT64" under "= ;NAT64".)

I=E2=80=99ve now addressed this in v05, thanks!

Page= 8.:

=C2=A0=C2=A0 Furthermore, as indicated in [RFC6877] (464XLAT), can =
be used in
=C2=A0=C2=
=A0 broadband IPv6 network architectures, by implementing the CLAT
=C2=A0=C2=A0 functionality at the=
 CE.

I do not understand WHAT can be used. Perhaps you meant:<= /p>

=C2=A0=C2=A0 Furthermore, a=
s indicated in [RFC68=
77], 464XLAT can be used in
=C2=A0=C2=A0 broadband IPv6 network architectures, by implementing the C=
LAT
=C2=A0=C2=A0 function=
ality at the CE.

 = ;

Done!=

 

Page 9.

=C2=A0=C2=A0 c.=C2=A0 Local-IPv4 to Remote-IPv6: Not possible.=C2=A0 I=
t is not expected that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 services are deployed in Internet=
 using IPv6-only, unless there
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is certainty that peers w=
ill also be IPv6-capable.

 

Perhaps a philosophical question: Wh= en will it be expected? (How long shell we need to always consider IPv4?)

<= o:p> 

I do= n=E2=80=99t think this is something to be discussed in this document, howev= er, this text has changed in v05, see my earlier response with new text to = Alejandro. Anyway, I=E2=80=99m happy to amend it again, if the WG believes = we should enter into philosophical discussions =E2=80=A6<= /p>

=  

Section 3.1.3.

However, doesn't
=C2=A0=C2=A0 look a sensible approach from an Operatin=
g System or application
=
=C2=A0=C2=A0 vendor perspective, to provide IPv6-only support unless, simil=
arly to
=C2=A0=C2=A0 c.=
=C2=A0 above, there is certainty of peers supporting IPv6 as well.

 <= /o:p>

I und= erstand, but I am not happy with that. I am not arguing with you but with t= his approach...

 

I=E2=80=99m not sure to understand your point= here. Should I explicitly say that providing IPv6-only for an OS is a bad = thing? That is contradictory with your previous philosophical discussion = =E2=80=A6 Maybe you want to suggest some specific wording so I can get your= point better?

 

 

=  

Section 3.2.

In addition to the different pros, cons an= d
=C2=A0=C2=A0 tra=
de-offs, which may be acceptable for some operators, they have
=C2=A0=C2=A0 implementation diffi=
culties, as they are beyond the original
=C2=A0=C2=A0 expectations of the NAT64/DNS64 original inten=
t.

You might want to refer to our I-D as an informative reference: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02<= o:p>

=  

Yes, good point :-)

 

I have stopped reading at the beginning of Section 4 (because of my= time zone), I hope to be able to continue tomorrow.

 

<= p class=3DMsoNormal>Thanks again!

&nb= sp;

Best regards,

 

G=C3=A1bor

 

On 4/10/2019 09:37, Fred Baker= wrote:

For the record, the question =
here is two-fold. First, is it correct and complete? Is there more, or less=
, that should be said? Second, are there operators -ISPs, IxPs, enterprise,=
 or whatever, that consider this useful in their deployments?
 
On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.e=
s@dmarc.ietf.org> wrote:
 
Hi Ron,
 
I'm not aware of any IPR on this document.
 
Regards,
Jordi
&=
nbsp;
 
<=
pre style=3D'margin-left:35.4pt'> 
=EF=BB=BFEl 8/4/19 17:54, "v6ops en nombre de Ron Bonic=
a" <v6ops-bounces@ietf.org en nombre de rbonica=3D40=
juniper.net@dmarc.ietf.org> escribi=C3=B3:
 
=C2=A0=C2=A0 Folks,
 
=C2=A0=C2=A0 Thi=
s email initiates a Working Group Last call on draft-ietf-v6ops-nat64-deplo=
yment-04. WGLC will end at COB, April 22, 2019.
 
=C2=A0=C2=A0 Authors,
 
=C2=A0=C2=A0 Pl=
ease respond to this message indicating whether you are aware of any IPR re=
garding this draft.
=
 
=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=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=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=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=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=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron
 
 
=C2=A0=C2=A0 Juniper=
 Internal
 
=C2=A0=C2=A0 ____________________=
___________________________
=C2=A0=C2=A0 v6ops mailing list
=C2=A0=C2=A0 v6ops@ietf.org=

=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/v6ops
 
 
 
&n=
bsp;
*************************=
*********************
IPv=
4 is over
Are you ready f=
or 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 th=
e exclusive use of the individual(s) named above and further non-explicilty=
 authorized disclosure, copying, distribution or use of the contents of thi=
s information, even if partially, including attached files, is strictly pro=
hibited and will be considered a criminal offense. If you are not the inten=
ded recipient be aware that any disclosure, copying, distribution or use of=
 the contents of this information, even if partially, including attached fi=
les, is strictly prohibited, will be considered a criminal offense, so you =
must reply to the original sender to inform about this communication and de=
lete it.
 
 
 
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6op=
s
______=
_________________________________________
v6ops mailing list
v6ops@ietf.org<=
/pre>
https://www.ietf.org/mailman/listinfo/v6ops
 
_____________________=
__________________________ v6ops mailing list v6ops@ietf.org https://www.ie=
tf.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_3638276825_680081145--


From nobody Tue Apr 16 08:57:16 2019
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 7E7DF12079A for ; Tue, 16 Apr 2019 08:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 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, 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 LAWtCnP5_cxk for ; Tue, 16 Apr 2019 08:57:03 -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 B2884120C54 for ; Tue, 16 Apr 2019 07:57:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555426634; x=1556031434; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=BdrpWH/Fr894q9TmT3yWrf uPCUrQpZp+82/TxO25yrw=; b=DXWffGdIjZi+03xJQ2NO4nGSxZ7xPNxG2CKr4I 35YqisHQLTFwApNejsS4elDBKm71w6VcQMJ3Ydn/jFNrQhV+lwmI4ux+Dof/x0/c lyxsLfwjmJE0eNnJlCkk0eS4z37ltVGxujsfsrixvaZ+G2Ak3aoqlfd5RMR6Uncs zv1x8=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Tue, 16 Apr 2019 16:57:14 +0200
X-Spam-Processed: mail.consulintel.es, Tue, 16 Apr 2019 16:57:13 +0200
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2)  with ESMTPA id md50006221389.msg for ; Tue, 16 Apr 2019 16:57:12 +0200
X-MDRemoteIP: 2001:470:1f09:495:11c:bfce:3ad8:91e6
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Tue, 16 Apr 2019 16:57:12 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=100922cfbb=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.8.190312
Date: Tue, 16 Apr 2019 16:57:10 +0200
From: JORDI PALET MARTINEZ 
To: 
Message-ID: <36E5648E-102C-480F-AEFA-EB502F366A4C@consulintel.es>
Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04
References: <11DA6245-76CB-4DBD-B0EB-11ADA7BA00AE@consulintel.es> <62D9F3DE-2712-48D8-BFAA-8DF67C925190@gmail.com>  
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3638278630_2126638191"
Archived-At: 
Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04
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, 16 Apr 2019 15:57:08 -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_3638278630_2126638191
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

I=E2=80=99m confused about one of your inputs, see below.

=20

El 16/4/19 16:27, "JORDI PALET MARTINEZ"  escri=
bi=C3=B3:

=20

Hi Gabor,

=20

Thanks a lot!

=20

Responding below in-line.


Regards,

Jordi

=20

=20

=20

El 16/4/19 15:38, "v6ops en nombre de G=C3=A1bor Lencse"  escribi=C3=B3:

=20

Dear Jordi,

I think your draft contains valuable material, and I support its publicatio=
n as an RFC. I try to do my best to read it, but I cannot finish it today.

While reading, I take notes below. The majority of them will be nits. The s=
ign "-->" means a suggestion for correction.

1. Introduction:
  NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation, -->   St=
ateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation,
(Saying simply "NAT64" may include both stateful and stateless NAT64. If yo=
u do not want to write always "stateful NAT64", then perhaps you should exp=
lain in the beginning that you mean "stateful NAT64" under "NAT64".)

I=E2=80=99ve now addressed this in v05, thanks!

Page 8.:

   Furthermore, as indicated in [RFC6877] (464XLAT), can be used in
   broadband IPv6 network architectures, by implementing the CLAT
   functionality at the CE.
I do not understand WHAT can be used. Perhaps you meant:

   Furthermore, as indicated in [RFC6877], 464XLAT can be used in
   broadband IPv6 network architectures, by implementing the CLAT
   functionality at the CE.
=20

This is the same text as what I=E2=80=99ve:

=C2=A0=C2=A0 Furthermore, as indicated in [RFC6877], 464XLAT can be used in

=C2=A0=C2=A0 broadband IPv6 network architectures, by implementing the CLAT

=C2=A0=C2=A0 functionality at the CE.

=20

=20

Page 9.

   c.  Local-IPv4 to Remote-IPv6: Not possible.  It is not expected that
       services are deployed in Internet using IPv6-only, unless there
       is certainty that peers will also be IPv6-capable.
=20

Perhaps a philosophical question: When will it be expected? (How long shell=
 we need to always consider IPv4?)

=20

I don=E2=80=99t think this is something to be discussed in this document, h=
owever, this text has changed in v05, see my earlier response with new text=
 to Alejandro. Anyway, I=E2=80=99m happy to amend it again, if the WG belie=
ves we should enter into philosophical discussions =E2=80=A6

=20

Section 3.1.3.
However, doesn't
   look a sensible approach from an Operating System or application
   vendor perspective, to provide IPv6-only support unless, similarly to
   c.  above, there is certainty of peers supporting IPv6 as well.
=20

I understand, but I am not happy with that. I am not arguing with you but w=
ith this approach...=20

=20

I=E2=80=99m not sure to understand your point here. Should I explicitly say=
 that providing IPv6-only for an OS is a bad thing? That is contradictory w=
ith your previous philosophical discussion =E2=80=A6 Maybe you want to sugg=
est some specific wording so I can get your point better?

=20

=20

=20

Section 3.2.

In addition to the different pros, cons and
   trade-offs, which may be acceptable for some operators, they have
   implementation difficulties, as they are beyond the original
   expectations of the NAT64/DNS64 original intent.
You might want to refer to our I-D as an informative reference: https://too=
ls.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02

=20

Yes, good point :-)

=20

After re-reading, I=E2=80=99ve decided that it makes more sense to have thi=
s reference at the end of the intro, to state that there are other choices =
than just NAT64/464XLAT.

=20

I have stopped reading at the beginning of Section 4 (because of my time zo=
ne), I hope to be able to continue tomorrow.

=20

Thanks again!

=20

Best regards,

=20

G=C3=A1bor

=20

On 4/10/2019 09:37, Fred Baker wrote:
For the record, the question here is two-fold. First, is it correct and com=
plete? Is there more, or less, that should be said? Second, are there opera=
tors -ISPs, IxPs, enterprise, or whatever, that consider this useful in the=
ir deployments?
=20
On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ  wrote:
=20
Hi Ron,
=20
I'm not aware of any IPR on this document.
=20
Regards,
Jordi
=20
=20
=20
=EF=BB=BFEl 8/4/19 17:54, "v6ops en nombre de Ron Bonica"  escribi=C3=B3:
=20
   Folks,
=20
   This email initiates a Working Group Last call on draft-ietf-v6ops-nat64=
-deployment-04. WGLC will end at COB, April 22, 2019.
=20
   Authors,
=20
   Please respond to this message indicating whether you are aware of any I=
PR regarding this draft.
=20
                                                                         Ro=
n
=20
=20
   Juniper Internal
=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 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.
=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
_______________________________________________ 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_3638278630_2126638191
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


I=E2=80=99m =
confused about one of your inputs, see below.
 
El 16/4/19 16:27, "JORDI PAL=
ET MARTINEZ" <jordi.p=
alet@consulintel.es> escribi=C3=B3:
<=
p class=3DMsoNormal style=3D'margin-left:35.4pt'> 
Hi Gabor,
 =

Thanks a lot!
 
Respondi=
ng below in-line.

Regards,
Jordi
 
 
 
El 16/4/19 15:38, "v6ops en nombre de G=C3=
=A1bor Lencse" <v6ops-bou=
nces@ietf.org en nombre de lencse@=
hit.bme.hu> escribi=C3=B3:
 
Dear Jordi,
I think your draft contains valuable material, and I support its p=
ublication as an RFC. I try to do my best to read it, but I cannot finish i=
t today.
While reading, I tak=
e notes below. The majority of them will be nits. The sign "-->&quo=
t; means a suggestion for correction.
1. Introduction:
&=
nbsp; NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 tr=
anslation, -->   Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation,
(Saying simply "NAT64" may include both s=
tateful and stateless NAT64. If you do not want to write always "state=
ful NAT64", then perhaps you should explain in the beginning that you =
mean "stateful NAT64" under "NAT64".)
I=E2=80=99ve now addressed this in v05, thanks!
   Furthermore, as indicated in [<=
a href=3D"https://tools.ietf.org/html/rfc6877" title=3D""464XLAT: Comb=
ination of Stateful and Stateless Translation"">RFC6877] (464XLAT)=
, can be used in
&=
nbsp;  broadband IPv6 network architectures, by implementing the CLAT<=
o:p>
   functionalit=
y at the CE.
I do not understand WHAT can be used. Perhaps you meant:
   Furthe=
rmore, as indicated in [RFC6877], 464XLAT can be used in
   broadband IPv6 network architectures, =
by implementing the CLAT
=
   functionality at the CE.
 
This is the same tex=
t as what I=E2=80=99ve:
=C2=A0=C2=A0 Furthermore, as indicated=
 in [RFC6877], 464XLAT can be used in
=C2=A0=C2=A0 broadband I=
Pv6 network architectures, by implementing the CLAT
=C2=A0=C2=
=A0 functionality at the CE.
 
 =

Page 9.
   c.  Local-IPv4 to Remote-IPv6: Not pos=
sible.  It is not expected that
       services are dep=
loyed in Internet using IPv6-only, unless there
       is certa=
inty that peers will also be IPv6-capable.
<=
p class=3DMsoNormal style=3D'margin-left:70.8pt'> 
Perhaps a philosoph=
ical question: When will it be expected? (How long shell we need to always =
consider IPv4?)
 
I don=E2=80=99t think this is so=
mething to be discussed in this document, however, this text has changed in=
 v05, see my earlier response with new text to Alejandro. Anyway, I=E2=80=
=99m happy to amend it again, if the WG believes we should enter into philo=
sophical discussions =E2=80=A6
&n=
bsp;
Section 3.1.3.
However, doesn't
   look a sensible approach from an Opera=
ting System or application
   vendor perspective, to provide IPv6-only support unless, sim=
ilarly to
   c.=
  above, there is certainty of peers supporting IPv6 as well.

 

I understand,= but I am not happy with that. I am not arguing with you but with this appr= oach...

 

I=E2=80=99m not sure to understand your point here. Should I explicitl= y say that providing IPv6-only for an OS is a bad thing? That is contradict= ory with your previous philosophical discussion =E2=80=A6 Maybe you want to= suggest some specific wording so I can get your point better?<= /o:p>

 

 

 

Section 3.2.

In addition to the different pros, cons = and
   t=
rade-offs, which may be acceptable for some operators, they have
   implementation dif=
ficulties, as they are beyond the original
   expectations of the NAT64/DNS64 original int=
ent.

You might want to refer to our I-D as an informative reference: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02

 

Yes, good point :-)

For the record, the question here is two-fold. First, is it =
correct and complete? Is there more, or less, that should be said? Second, =
are there operators -ISPs, IxPs, enterprise, or whatever, that consider thi=
s useful in their deployments?
 
On Apr 8, 2019, at 9:02 AM, =
JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote:=

 
Hi Ron,
 
I'm not aware of any IPR on this document.
 
Regards,
Jordi
 =

 
 
=EF=BB=BFEl 8/4/19 17:54, "v6ops en nombre de Ron Bonica" <=
a href=3D"mailto:v6ops-bounces@ietf.orgennombrederbonica=3D40juniper.net@dm=
arc.ietf.org"><v6ops-bounces@ietf.org en nombre de rbonica=3D40juniper.n=
et@dmarc.ietf.org> escribi=C3=B3:
 
&n=
bsp;  Folks,
 <=
o:p>
   This email i=
nitiates a Working Group Last call on draft-ietf-v6ops-nat64-deployment-04.=
 WGLC will end at COB, April 22, 2019.
 
&nbs=
p;  Authors,
 <=
o:p>
   Please respo=
nd to this message indicating whether you are aware of any IPR regarding th=
is draft.
 
     &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
     Ron
 
 
   Juniper Internal
 
   ________________________________=
_______________
 &nb=
sp; v6ops mailing list
&n=
bsp;  v6ops@ietf.org<=
/pre>
   https://www.ietf.org/mailman/listinfo/v6op=
s
 
 
 
 
****************=
******************************
IPv4 is over
Are yo=
u ready for the new Internet ?
http://www.theipv6company.c=
om
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-exp=
licilty authorized disclosure, copying, distribution or use of the contents=
 of this information, even if partially, including attached files, is stric=
tly prohibited and will be considered a criminal offense. If you are not th=
e 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 of=
fense, so you must reply to the original sender to inform about this commun=
ication and delete it.
&n=
bsp;
 
 
_______________________________________________
v6ops mailing list
v6ops=
@ietf.org
https://www.ietf.org/mailman/l=
istinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6op=
s
 
________=
_______________________________________ v6ops mailing list v6ops@ietf.org h=
ttps://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_3638278630_2126638191-- From nobody Tue Apr 16 09:00:06 2019 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 3BAE212081B for ; Tue, 16 Apr 2019 09:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 73ZCW5QxelRw for ; Tue, 16 Apr 2019 09:00: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 B17F912084D for ; Tue, 16 Apr 2019 08:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555427269; x=1556032069; 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=q5ZVDxt5/Mj7U6VGbe1gN g/P86G89rovw7x8lnpRWUE=; b=iTqCYuJ8zQjvk94ORvILJzmIov3F5EJEFI6Gd DHxQCVt3WjwxJZ+SPyLcbDlLkJWa8cNlZz+mOfJMkRJpKPEye0ITu94XPhpJbScs doX/m1EsyzThq6qfIrid/w3HOTYhGqOHXuryvzFGZfdyf5t7aGQjQNI10txSqwh4 eHfIuk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 16 Apr 2019 17:07:49 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 16 Apr 2019 17:07:48 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006221396.msg for ; Tue, 16 Apr 2019 17:07:48 +0200 X-MDRemoteIP: 2001:470:1f09:495:11c:bfce:3ad8:91e6 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Tue, 16 Apr 2019 17:07:48 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=100922cfbb=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.8.190312 Date: Tue, 16 Apr 2019 17:07:45 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: <8EA3A0A4-146E-4F7E-94E2-83DF3C2D2C96@consulintel.es> Thread-Topic: the list stopped working ? Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [v6ops] the list stopped working ? 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, 16 Apr 2019 16:00:01 -0000 Or is just happening to me? Regards, Jordi ********************************************** 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 Tue Apr 16 09:04:35 2019 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 D4D731208D0; Tue, 16 Apr 2019 09:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Nqqlsp-LYDXc; Tue, 16 Apr 2019 09:04:33 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0: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 5B5D41208BD; Tue, 16 Apr 2019 08:28:22 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id c8so10566110pfd.10; Tue, 16 Apr 2019 08:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=X6cpDbqVrkmfGEB3aPxHMUveHBL2t8lpJz+hOpaNwao=; b=reW256+7NgnAU91oBWxamdTgI26JDA4HSCRpLwaZttpTpNl99wZrZSWlpG0V6gWE5Q eIGXT+zyI9aOKGjqb4WO2IVtU4qBMiO1b+n1wxZnCptVerT5f/yvA0tjvw80hWyJsrc+ 3bxlJH/ZBK/pDY19ofbIeKw01LdQZBrmzgk4hBnrtEsJnNXfye6QLiNsvzCqYmJMfI9r lM4p534D3Yly0K+18p2VUhLqBIGOh5/xTnJ3T488xkVuoVnYAoj/puVSdJp0joc4jMBu kKzTwGy4xt0ULGy0nPO7YoARxyJLGZCvfvmFIV1gkcvodQ9ltQMvNY5sv6nhSGXxcj/H qa9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=X6cpDbqVrkmfGEB3aPxHMUveHBL2t8lpJz+hOpaNwao=; b=HqwSy7kU4QLluVkNE6AIpO9uj44nC9lV9qwn7h3yZxuzpz5CvXzDMH2Fzl23qOYHGI zH8zA/H7J+WlnGaFW13UIu+uYc8ThE1AQfo5b0jIdQgYucI+roDc7w+XYY86o9QbJ8VE 4iRWpQIniu8DD8OuWO+jH1KuhgS3pExcVq7SJ279AEi+MIZ5/jxuad+tfK87dhg4791z XtBb5yg1xF9puHByjTbBdhRRZ0pPRDqDJ6il7NDdjaDN6y0j0qFojjyNgFMqWqDa+n/z gLFehjUS4OepkQz9c50ZEGQ81QltFhCye2A3ZNvbNbtgY1VR2iMiAWDL/jDt/dKnLtGs txaQ== X-Gm-Message-State: APjAAAVCmRyyRCzlUhNfVkoFEfK2WwcAy/nyU7IAHXfqyZAydCOd/Ld7 UUSNUcG2keOX5nzneWqht1XM6Ws4YVo= X-Google-Smtp-Source: APXvYqzzwzfkInAAG6weBMZFxEqZnhQe7MBJiagibKk2w26mdizzKIDQtPdX/t17//vztIGbB9oyzQ== X-Received: by 2002:a63:f212:: with SMTP id v18mr74947618pgh.231.1555428501646; Tue, 16 Apr 2019 08:28:21 -0700 (PDT) Received: from sjcldanwi.lan ([75.111.84.113]) by smtp.gmail.com with ESMTPSA id n82sm86823670pfi.63.2019.04.16.08.28.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 08:28:20 -0700 (PDT) From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <0565EE13-3E04-41CE-AF42-BE96ED5B65BE@gmail.com> Date: Tue, 16 Apr 2019 08:28:19 -0700 Cc: fredbaker.ietf@gmail.com, Ron Bonica , draft-ietf-v6ops-nat64-deployment@ietf.org To: v6ops@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 16:04:35 -0000 Fred Baker wrote: > For the record, the question here is two-fold. First, is it correct = and complete? Is there more, or less, that should be said? Second, are = there operators -ISPs, IxPs, enterprise, or whatever, that consider this = useful in their deployments? I find the document useful. There are two things I noticed with this one sentence in Section 5, "however the built-in address synthesis feature is out of their = control, and can only be resolved by operating system vendors." which should mention (1) DoT and DoH and (2) centralized un-encrypted = DNS, detailed below. 1. DoT and DoH are provided by the application, not provided by OS = vendors (at least, not yet) - but that text implies only the OS vendor = can change how DNS works on the host. DoT and DoH demonstrate = otherwise. The above text should at least mention that DoT and DoH = standards have declared DNS64 (and thus NAT64) out of their scope but = explain that an application doing DoT/DoH will break with NAT64, and = should discuss the operational difficulties of DoT and DoH on a network = with NAT64 and DNS64. 2. The document should also mention using a non-network provided DNS = (e.g., 8.8.8.8) won't provide the necessary/expected DNS64. Most hosts = do not support changing DNS settings on a per-network basis, either, so = using a specific DNS like 8.8.8.8 when on WiFi and using the = network-provided DNS64 when on a NAT64 network is usually not possible = -- a further operational difficulty placed on the user. =20 -d From nobody Tue Apr 16 09:25:29 2019 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 9A724120481; Tue, 16 Apr 2019 09:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Xa2sAxsK_9ko; Tue, 16 Apr 2019 09:25:25 -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 6F47A1206B0; Tue, 16 Apr 2019 09:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555431410; x=1556036210; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=vpsUbSyqjyz6hO6yIqvEEP4Bbk924OxoxBvcbQd9zSs=; b=PvmJ1GXoiMP68 PfYHSbhKN8LAZMxuhojZPVTT+yN80t8yUReZBFN2GxkSFXDJ+BpWYG7d48p5zLI+ CozMkdwwT1OItSv6WlzaVpuma8fqUDkWmAaTB2vjA6tCoEyKWhqKQ+TabaOCC0e4 7OJCueKt3hgKNVUNLcC9nrPfXj+h9M= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 16 Apr 2019 18:16:50 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 16 Apr 2019 18:16:50 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006221474.msg; Tue, 16 Apr 2019 18:16:48 +0200 X-MDRemoteIP: 2001:470:1f09:495:2c92:adb:56a:4d4e X-MDHelo: [10.10.10.139] X-MDArrival-Date: Tue, 16 Apr 2019 18:16:48 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=100922cfbb=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.8.190312 Date: Tue, 16 Apr 2019 18:16:45 +0200 From: JORDI PALET MARTINEZ To: Dan Wing , CC: Message-ID: <4573D6CB-61AC-4BB3-ACA4-B56E20E113D1@consulintel.es> Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 References: <0565EE13-3E04-41CE-AF42-BE96ED5B65BE@gmail.com> In-Reply-To: <0565EE13-3E04-41CE-AF42-BE96ED5B65BE@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 16:25:28 -0000 Hi Dan, Thanks a lot for the inputs. =EF=BB=BFEl 16/4/19 18:05, "v6ops en nombre de Dan Wing" escribi=C3=B3: Fred Baker wrote: =20 > For the record, the question here is two-fold. First, is it correct a= nd complete? Is there more, or less, that should be said? Second, are there= operators -ISPs, IxPs, enterprise, or whatever, that consider this useful = in their deployments? =20 I find the document useful. =20 =20 There are two things I noticed with this one sentence in Section 5, =20 "however the built-in address synthesis feature is out of their contr= ol, and can only be resolved by operating system vendors." =20 which should mention (1) DoT and DoH and (2) centralized un-encrypted D= NS, detailed below. I will update/reword the sentence. There is an explicit section (4.5. DNS = Privacy) covering that. =20 1. DoT and DoH are provided by the application, not provided by OS vend= ors (at least, not yet) - but that text implies only the OS vendor can chan= ge how DNS works on the host. DoT and DoH demonstrate otherwise. The abov= e text should at least mention that DoT and DoH standards have declared DNS= 64 (and thus NAT64) out of their scope but explain that an application doin= g DoT/DoH will break with NAT64, and should discuss the operational difficu= lties of DoT and DoH on a network with NAT64 and DNS64. Exactly, we had that discussion when I was working in the initial versions = of this document and the DoH work was on-going as well. =20 2. The document should also mention using a non-network provided DNS (e= .g., 8.8.8.8) won't provide the necessary/expected DNS64. Most hosts do no= t support changing DNS settings on a per-network basis, either, so using a = specific DNS like 8.8.8.8 when on WiFi and using the network-provided DNS64= when on a NAT64 network is usually not possible -- a further operational d= ifficulty placed on the user. =20 This is covered in Section 4.4. Manual Configuration of Foreign DNS. I wil= l double check that I'm not missing it in the summary. =20 -d =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 Tue Apr 16 09:26:02 2019 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 5CD5812067D for ; Tue, 16 Apr 2019 09:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, 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 4mZctfEOoHgS for ; Tue, 16 Apr 2019 09:25:53 -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 3944B1206E2 for ; Tue, 16 Apr 2019 09:18:23 -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 x3GGIJPO024529; Tue, 16 Apr 2019 18:18:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4E8D72057DC; Tue, 16 Apr 2019 18:18:19 +0200 (CEST) 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 41159205693; Tue, 16 Apr 2019 18:18:19 +0200 (CEST) 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 x3GGIJWb028982; Tue, 16 Apr 2019 18:18:19 +0200 To: JORDI PALET MARTINEZ , "v6ops@ietf.org list" References: <8EA3A0A4-146E-4F7E-94E2-83DF3C2D2C96@consulintel.es> From: Alexandre Petrescu Message-ID: <8e9c9511-484c-7ba2-9f4e-3f8e65cb6db9@gmail.com> Date: Tue, 16 Apr 2019 18:18:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <8EA3A0A4-146E-4F7E-94E2-83DF3C2D2C96@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] the list stopped working ? 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, 16 Apr 2019 16:26:00 -0000 I have a break in emails on this list between 10 and 16 of April, maybe it's normal... Le 16/04/2019 à 17:07, JORDI PALET MARTINEZ a écrit : > Or is just happening to me? > > Regards, > Jordi > > > > > > ********************************************** > 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 Tue Apr 16 10:21:46 2019 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 9B567120152 for ; Tue, 16 Apr 2019 10:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 T2eK32SvPMtr for ; Tue, 16 Apr 2019 10:21:42 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 021651200D5 for ; Tue, 16 Apr 2019 10:21:42 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id j184so11996727vsd.11 for ; Tue, 16 Apr 2019 10:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=KTvSkgi5xvdRXyBTg4LAzPolehKnA9qyelEKYdvU6ew=; b=YGOCcIww11kTs3fPhCEGxWhi/YY3epMLRb67/m3HW5R2FjgUJqOVlFSffjVs22BwNa NJgoFSroPEtmtW6thDtu71cmov9o4PLvEy1iF9x+37gmoQHBaSsOCoTEnsZ2gfaltvzK QwJXJvo5pKBqBxnBmXvjB9ZSt8iLWuMj0PhBXZMjNPAK6ah/D5zyQqTGEtE7C4Fa5Pgp lexURGV6NciyqtxrY5Z7bKSWx9EZ4GXoLNGrz09UkpqXFd4T8HXX688HAql6DZ14It8A yW2Ko5CzGiQcmZPMDbLIhwi+8GQ1Sm5SQrT53qfYcv5ecijOfydWOtgPlRx+8QAyyGjq WTig== 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:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KTvSkgi5xvdRXyBTg4LAzPolehKnA9qyelEKYdvU6ew=; b=SxvT0oVXDiOXpMwkyIcNXPMxMSkijArFShK0NssYt/SJNpNhtYBKW1GqZNRyg1I4me eGc0F1VMyIzo7vCdDSVk21HyNa/rsLzfaczirgxUz4t7rSriNoU2Z3n+0MG73CUlnEHg sy/pqT6xtXFjSwa1N1lh5I6bOFL7lQ2T82fcwSvMkFaeBlsYTjSvUzlkMB5j//UyHQdw kbzHYglr8QC6fdhsFByg+KZwromTpKOA3pTQTio2u9WtrVA8cC3wooXoPCkFmxLD5geY jrpmiUE0n1Zq0cylk9F6ABdXdx5fU8MOSvGAdfgfj8b/UrSioi42v6aT0NSIXSzRC4/m yJMQ== X-Gm-Message-State: APjAAAUHuBXidI6XANUCybXKRmKO/J7L17Eji+Z0W2Nbm7ea/00rh4oW 0DcQCgSzwqR9lpNv+S/yD5ayUe7Jncc= X-Google-Smtp-Source: APXvYqzBzsiqujZKKr7W0qO0QGOrhnq6Vrqsadr66eVwMwr8KZMU6MtVdYkVs7F7G40jRHc11l/gPA== X-Received: by 2002:a67:f416:: with SMTP id p22mr46259935vsn.175.1555435300536; Tue, 16 Apr 2019 10:21:40 -0700 (PDT) Received: from MacBook-Pro-2.local ([190.199.172.207]) by smtp.gmail.com with ESMTPSA id u6sm40459914vke.54.2019.04.16.10.21.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 10:21:39 -0700 (PDT) To: v6ops@ietf.org References: <1302AFA4-A976-45AC-9F63-AD8F82D02BDB@consulintel.es> <912345910.89785335.1555417440276.JavaMail.zimbra@telecentro.net.ar> From: Alejandro Acosta Message-ID: <155ad06a-7028-4bfd-299f-87f94094aa91@gmail.com> Date: Tue, 16 Apr 2019 13:21:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <912345910.89785335.1555417440276.JavaMail.zimbra@telecentro.net.ar> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: es-ES Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 17:21:45 -0000 Hello,   I have to say that I also find this document useful and certainly 464XLAT is a mechanisms that I would like to see more out there. Alejandro, El 16/4/19 a las 07:24, Alejandro D'Egidio escribió: > Hello Jordi, > Yes, I would like to see this document published. > > > Regards, > Alejandro > > > ----- Mensaje original ----- >> De: "JORDI PALET MARTINEZ" >> Para: "Alejandro Degidio" , "Fred Baker" >> CC: "v6ops@ietf.org list" >> Enviados: Martes, 16 de Abril 2019 4:09:48 >> Asunto: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 >> Hi Alejandro, >> >> Thanks for your support. I understand that you want to see this document >> published, just to make it sure. >> >> >> >> Regards, >> Jordi >> >> >> >> El 16/4/19 1:31, "v6ops en nombre de Alejandro D'Egidio" > en nombre de adegidio=40telecentro.net.ar@dmarc.ietf.org> escribió: >> >> Hello, >> >From my point of view, I think this document is really useful. >> In my case, I consider 464XLAT as a very good solution and in fact I already >> have a cablemodem with a FW with CLAT and it works perfectly! >> >> Regarding the content. >> >> In "possible communication paths" for both cases with and without DNS64, we have >> this option: >> " c. Local-IPv4 to Remote-IPv6: Not possible. It is not expected that >> services are deployed in Internet using IPv6-only, unless there >> is certainty that peers will also be IPv6-capable. >> " >> >> If we consider EAMT (RFC7757) as we are suggesting in >> draft-palet-v6ops-464xlat-opt-cdn-caches-01 it could be possible. >> >> Maybe you can add some note that It is possible if we CPE supports EAMT allowing >> to connect IPv4-only devices/apps to IPv6 services. >> >> In the last version, the only change is a section for EAMT. So, what I can do is >> a call in "c" to that section. > Yes, I think it's ok if you add a call in that point. > > >> The reason for not having more explicit text about EAMT, is that this section is >> talking about the "actual" 464XLAT (RFC6877) support. So, rewording it for a >> "future possible update of 464XLAT that include a MUST for EAMT support", will >> not be acceptable. >> >> >> >> Regards, >> Alejandro >> >> ----- Mensaje original ----- >> De: "Fred Baker" >> Para: "v6ops@ietf.org list" >> Enviados: Martes, 9 de Abril 2019 21:37:26 >> Asunto: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 >> >> For the record, the question here is two-fold. First, is it correct and >> complete? Is there more, or less, that should be said? Second, are there >> operators -ISPs, IxPs, enterprise, or whatever, that consider this useful in >> their deployments? >> >> > On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ >> > wrote: >> > >> > Hi Ron, >> > >> > I'm not aware of any IPR on this document. >> > >> > Regards, >> > Jordi >> > >> > >> > >> > El 8/4/19 17:54, "v6ops en nombre de Ron Bonica" > > nombre de rbonica=40juniper.net@dmarc.ietf.org> escribió: >> > >> > Folks, >> > >> > This email initiates a Working Group Last call on >> > draft-ietf-v6ops-nat64-deployment-04. WGLC will end at COB, April 22, 2019. >> > >> > Authors, >> > >> > Please respond to this message indicating whether you are aware of any IPR >> > regarding this draft. >> > >> > Ron >> > >> > >> > Juniper Internal >> > >> > _______________________________________________ >> > 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 >> >> _______________________________________________ >> 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 alfredo@tecnocratica.net Tue Apr 16 10:09:36 2019 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 64CE9120388 for ; Tue, 16 Apr 2019 10:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qXGkp1369wVR for ; Tue, 16 Apr 2019 10:09:34 -0700 (PDT) Received: from s1.solucionesdinamicas.net (s1.solucionesdinamicas.net [194.176.119.3]) by ietfa.amsl.com (Postfix) with ESMTP id 28450120226 for ; Tue, 16 Apr 2019 10:09:33 -0700 (PDT) Received: from [192.168.91.54] (unknown [10.0.6.1]) by s1.solucionesdinamicas.net (Postfix) with ESMTPSA id D3AAA83A049; Tue, 16 Apr 2019 19:09:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Alfredo Sola In-Reply-To: <62D9F3DE-2712-48D8-BFAA-8DF67C925190@gmail.com> Date: Tue, 16 Apr 2019 19:09:31 +0200 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <11DA6245-76CB-4DBD-B0EB-11ADA7BA00AE@consulintel.es> <62D9F3DE-2712-48D8-BFAA-8DF67C925190@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 17:30:30 -0000 Hello, > For the record, the question here is two-fold. First, is it correct = and complete? Is there more, or less, that should be said? Second, are = there operators -ISPs, IxPs, enterprise, or whatever, that consider this = useful in their deployments? =46rom my perspective as a network operator, I think this = document is useful and mature (both correct and complete). In my = opinion, it should be published as soon as the author finishes = addressing the current feedback round, which seems to revolve around = clarifications and not challenging the ideas presented. --=20 Alfredo Sola https://www.tecnocratica.net From nobody Tue Apr 16 11:22:59 2019 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 81EC612010C for ; Tue, 16 Apr 2019 11:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=telecentro.net.ar 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 VmaW3vWKrQI4 for ; Tue, 16 Apr 2019 11:22:54 -0700 (PDT) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8CB012037B for ; Tue, 16 Apr 2019 11:22:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 13F22320220A; Tue, 16 Apr 2019 15:22:51 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5pZYdhzZ12R5; Tue, 16 Apr 2019 15:22:50 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 624BB3202327; Tue, 16 Apr 2019 15:22:50 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 624BB3202327 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1555438970; bh=i5VJMJnr0EkJhh9wkdWIjJwr/5o9tM9Nf5ogCW+WAmE=; h=Date:From:To:Message-ID:MIME-Version; b=VKGctO7lRHgrNtY+mVwW54l3xAeqgb7AMJE1dn1xVuqKSanuSzgdVCcw2LZmzg8s3 KA6jh1g0wFugZAbX8/S6lzE40iqXPCOjS4k9Rt5spGa9tuQUk0ChmTdavUYsvkzaqO oTprXol+wtiXNUt7BjqgAgsppWimuQ0X+nwtG1UUTBJQ+CXf2wi/D8gGtL0hCWLjC2 ieicA3DImdaj9T3VpDfx3H4cWCub/s57bDLaHydWyonXKfb2gMc36Jl4lY8UjKB5WR fc2ktbaefWEHFAiz5+KhclhoZPO565Z76B/3ixoqMiOJAw4FoYl2TrsJJFplabfuah umjvxDlALM00w== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MZBdm875GyQj; Tue, 16 Apr 2019 15:22:50 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 45025320220A; Tue, 16 Apr 2019 15:22:50 -0300 (-03) Date: Tue, 16 Apr 2019 15:22:50 -0300 (ART) From: Alejandro D'Egidio To: JORDI PALET MARTINEZ Cc: "v6ops@ietf.org list" Message-ID: <95985493.92165202.1555438970197.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <7F022EB1-6C84-4B46-914A-335AEFD3DD3F@consulintel.es> References: <7F022EB1-6C84-4B46-914A-335AEFD3DD3F@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC73 (Win)/8.8.8_GA_1703) Thread-Topic: WGLC: draft-ietf-v6ops-nat64-deployment-04 Thread-Index: GzPKjFNWx7WjNg6cnjdnReGRacpK7Q== Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 18:22:57 -0000 Hello Jordi, I think it's much better. Thanks for considering my comments. Regards, Alejandro ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "Alejandro Degidio" CC: "v6ops@ietf.org list" Enviados: Martes, 16 de Abril 2019 10:10:12 Asunto: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 Hi Alejandro, I've a draft v05 with the following changes to address this at section 3.1.= 2: The possible communication paths, among the IPv4/IPv6 stacks of both peers, in this case, are: a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers. b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT implements EAMT as indicated by Section 4.11. In principle, it is not expected that services are deployed in Internet using IPv6-only, unless there is certainty that peers will also be IPv6-capable. d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 translations. e. Local-IPv4 to Remote-dual-stack using EAMT optimization: If the CLAT implements EAMT as indicated by Section 4.11, instead of using the path d. above, NAT64 is avoided and the flow will use IPv6 from the CLAT to the destination. The same text (c y e) apply to section 3.1.3. Also, added a new paragraph at the end of 4.11. EAMT Considerations Explicit Address Mappings for Stateless IP/ICMP Translation [RFC7757] provides a way to configure explicit mappings between IPv4 and IPv6 prefixes of any length. When this is used, for example in a CLAT, it may provide a simple mechanism in order to avoid traffic flows between IPv4-only nodes or applications and dual-stack destinations to be translated twice (NAT46 and NAT64), by creating mapping entries with the GUA of the IPv6-reachable destination. This optimization of the NAT64 usage is very useful in many scenarios, including CDNs and caches, as described in [I-D.palet-v6ops-464xlat-opt-cdn-caches]. In addition to that, it may provide as well a way for IPv4-only nodes or applications to communicate with IPv6-only destinations. I will wait for further comments and I understand that even if the last cal= l succedes, I can do those updates before a possible IETF LC. Thanks! Regards, Jordi =20 =20 =EF=BB=BFEl 16/4/19 14:24, "v6ops en nombre de Alejandro D'Egidio" = escribi=C3=B3: Hello Jordi, Yes, I would like to see this document published. =20 =20 Regards, Alejandro =20 =20 ----- Mensaje original ----- > De: "JORDI PALET MARTINEZ" > Para: "Alejandro Degidio" , "Fred Baker" = > CC: "v6ops@ietf.org list" > Enviados: Martes, 16 de Abril 2019 4:09:48 > Asunto: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 =20 > Hi Alejandro, >=20 > Thanks for your support. I understand that you want to see this docum= ent > published, just to make it sure. >=20 >=20 >=20 > Regards, > Jordi >=20 >=20 >=20 >=EF=BB=BFEl 16/4/19 1:31, "v6ops en nombre de Alejandro D'Egidio" =EF=BB=BFen nombre de adegidio=3D40telecentro.net.ar@dmarc.ietf.org> e= scribi=C3=B3: >=20 > Hello, > >From my point of view, I think this document is really useful. > In my case, I consider 464XLAT as a very good solution and in fact= I already > have a cablemodem with a FW with CLAT and it works perfectly! > =20 > Regarding the content. > =20 > In "possible communication paths" for both cases with and without = DNS64, we have > this option: > " c. Local-IPv4 to Remote-IPv6: Not possible. It is not expect= ed that > services are deployed in Internet using IPv6-only, unless t= here > is certainty that peers will also be IPv6-capable. > " > =20 > If we consider EAMT (RFC7757) as we are suggesting in > draft-palet-v6ops-464xlat-opt-cdn-caches-01 it could be possible. > =20 > Maybe you can add some note that It is possible if we CPE supports= EAMT allowing > to connect IPv4-only devices/apps to IPv6 services. >=20 > In the last version, the only change is a section for EAMT. So, what = I can do is > a call in "c" to that section. Yes, I think it's ok if you add a call in that point. =20 =20 >=20 > The reason for not having more explicit text about EAMT, is that this= section is > talking about the "actual" 464XLAT (RFC6877) support. So, rewording i= t for a > "future possible update of 464XLAT that include a MUST for EAMT suppo= rt", will > not be acceptable. >=20 > =20 > =20 > Regards, > Alejandro > =20 > ----- Mensaje original ----- > De: "Fred Baker" > Para: "v6ops@ietf.org list" > Enviados: Martes, 9 de Abril 2019 21:37:26 > Asunto: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 > =20 > For the record, the question here is two-fold. First, is it correc= t and > complete? Is there more, or less, that should be said? Second, are= there > operators -ISPs, IxPs, enterprise, or whatever, that consider this= useful in > their deployments? > =20 > > On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ > > wrote: > >=20 > > Hi Ron, > >=20 > > I'm not aware of any IPR on this document. > >=20 > > Regards, > > Jordi > >=20 > >=20 > >=20 > > =EF=BB=BFEl 8/4/19 17:54, "v6ops en nombre de Ron Bonica" > =EF=BB=BFnombre de rbonica=3D40juniper.net@dmarc.ietf.org> escri= bi=C3=B3: > >=20 > > Folks, > >=20 > > This email initiates a Working Group Last call on > > draft-ietf-v6ops-nat64-deployment-04. WGLC will end at COB, A= pril 22, 2019. > >=20 > > Authors, > >=20 > > Please respond to this message indicating whether you are awa= re of any IPR > > regarding this draft. > >=20 > > = Ron > >=20 > >=20 > > Juniper Internal > >=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 privil= eged or > > confidential. The information is intended to be for the exclusiv= e 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 recip= ient be aware > > that any disclosure, copying, distribution or use of the content= s of this > > information, even if partially, including attached files, is str= ictly > > prohibited, will be considered a criminal offense, so you must r= eply 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 > _______________________________________________ > 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 > confidential. The information is intended to be for the exclusive use= of the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n 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 _______________________________________________ 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 Tue Apr 16 12:24:08 2019 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 3FCE71203CD; Tue, 16 Apr 2019 12:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FFcYZJAwKuNr; Tue, 16 Apr 2019 12:24:03 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 52E8A12016F; Tue, 16 Apr 2019 12:24:03 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id n8so10800712plp.10; Tue, 16 Apr 2019 12:24:03 -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=f9m3t5weli7a1Tu59t5Qvla5QoPUtlSU5ue0gGFuYB8=; b=pUSqw56ax0Qw6cR5SBBMQdIyNI0BhUIZ6iYchl1gz6pydZTf20C8J32AGigijmsFsX 19qPmpM+dTnWQKkPDW6nSfH/H8bvkef8lRN/7mX1Q0Sl6Lf1Kx37fgtL7Wv7E4C1C5XO APqJDQJJ8MWh//SEx92iCcVnVriRBE6sZ+JmX257wjZQe/uv1kltkj0D9WT9xfn5lb9u YqPA8hun3FykLSYDSQd0qFwOMhZpWQIefK0Syi+p0MUthzC5CexdoN5mMzfsqcnxey2l KrUu24eICZ8IXImWEFeHBjye0kzdVg2K4eg8C/jyxeaklGxv85ogDYqK0sfONK5Ix9/c 6Jag== 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=f9m3t5weli7a1Tu59t5Qvla5QoPUtlSU5ue0gGFuYB8=; b=BxqGxPwpdIdWCqhut+RnEHP0ubEqLfuWA7II2fzXSZKoBA5A5Tr00UgneOZkMQ3ZYC ZMGALDwDSBMMdMyFujkU/ybMkd7b41hN4hQXzKrc9V3YuRLcndVb0VZknQf84vVFSzXl 1lSagnvr2J2fgaAB69W8EKAJs6Nk098EQYH7AG+QYgJW8y0eSDe+/C1mX/Klqm/QT5+Q XgSszcmDFazraiXk6q61KiQ5XPsh1iNR5AkGvifdnocFshKYOlxW66+jH3vEBAa8UA6/ lHUFM+/B1dLzxkR2//NNw/k/DpbkyPtiK4WyNaBWjzYvvJ468J8CZnglMeGEpjBEGVoh pgQA== X-Gm-Message-State: APjAAAVI8U2YaiZewGTf5A9X7wYIPtj9rhVxK7m9MkZ1Ri2vU8GWoTT1 hR9TslAbm0vSYC1O6gCiQKk= X-Google-Smtp-Source: APXvYqzWs6VD5PeZQIQY0HEG8nm4ilW2+fjWWnxUSWXeTmQD63TF4u8Xmt3Gz70BUF7IT9gCio+Jbg== X-Received: by 2002:a17:902:362:: with SMTP id 89mr84988889pld.172.1555442642689; Tue, 16 Apr 2019 12:24:02 -0700 (PDT) Received: from sjcldanwi.lan ([75.111.84.113]) by smtp.gmail.com with ESMTPSA id p26sm131776797pfa.49.2019.04.16.12.24.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 12:24:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Dan Wing In-Reply-To: <4573D6CB-61AC-4BB3-ACA4-B56E20E113D1@consulintel.es> Date: Tue, 16 Apr 2019 12:23:58 -0700 Cc: v6ops@ietf.org, draft-ietf-v6ops-nat64-deployment@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6D0132CB-D460-4D83-8F92-C11CE48E0872@gmail.com> References: <0565EE13-3E04-41CE-AF42-BE96ED5B65BE@gmail.com> <4573D6CB-61AC-4BB3-ACA4-B56E20E113D1@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 19:24:06 -0000 On Apr 16, 2019, at 9:16 AM, JORDI PALET MARTINEZ = wrote: > Hi Dan, >=20 > Thanks a lot for the inputs. >=20 > =EF=BB=BFEl 16/4/19 18:05, "v6ops en nombre de Dan Wing" = escribi=C3=B3: >=20 > Fred Baker wrote: >=20 >> For the record, the question here is two-fold. First, is it correct = and complete? Is there more, or less, that should be said? Second, are = there operators -ISPs, IxPs, enterprise, or whatever, that consider this = useful in their deployments? >=20 > I find the document useful. >=20 >=20 > There are two things I noticed with this one sentence in Section 5, >=20 > "however the built-in address synthesis feature is out of their = control, and can only be resolved by operating system vendors." >=20 > which should mention (1) DoT and DoH and (2) centralized = un-encrypted DNS, detailed below. >=20 > I will update/reword the sentence. There is an explicit section (4.5. = DNS Privacy) covering that. Thanks for the pointer. That existing text in 4.5 makes an unstated = assumption that the DNS-over-encrypted-channel server is not doing = DNS64. I would make that clearer. Note there are ideas floating = around, such as draft-reddy-dprive-bootstrap-dns-server, which have the = local network provide the DNS-over-encrypted-channel function, where = DNS64 could be provided. I don't think = draft-reddy-dprive-bootstrap-dns-server is ready to be cited yet, but I = would tighten up the wording of Section 4.5 to make clear the problem is = the DoH/DoT/DoQ operator is not also doing the necessary DNS64 function. = If they are, the operational problem goes away (right?). > 1. DoT and DoH are provided by the application, not provided by OS = vendors (at least, not yet) - but that text implies only the OS vendor = can change how DNS works on the host. DoT and DoH demonstrate = otherwise. The above text should at least mention that DoT and DoH = standards have declared DNS64 (and thus NAT64) out of their scope but = explain that an application doing DoT/DoH will break with NAT64, and = should discuss the operational difficulties of DoT and DoH on a network = with NAT64 and DNS64. >=20 > Exactly, we had that discussion when I was working in the initial = versions of this document and the DoH work was on-going as well. Ok. I suggest changing that sentence in Section 5 something like this, OLD: can only be resolved by operating system vendors NEW: can be synthesized by the OS vendor (via its DNS resolver API) or the = application (via its own own DNS resolver). > 2. The document should also mention using a non-network provided = DNS (e.g., 8.8.8.8) won't provide the necessary/expected DNS64. Most = hosts do not support changing DNS settings on a per-network basis, = either, so using a specific DNS like 8.8.8.8 when on WiFi and using the = network-provided DNS64 when on a NAT64 network is usually not possible = -- a further operational difficulty placed on the user. =20 >=20 > This is covered in Section 4.4. Manual Configuration of Foreign DNS. = I will double check that I'm not missing it in the summary. Thanks for the pointer. I'm confused that both section 4.4 and section = 4.5 are about manual configuration of a foreign DNS -- 4.4 is = un-encrypted, 4.5 is encrypted. =20 -d > -d >=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 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 From nobody Tue Apr 16 13:26:43 2019 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 677201200D8; Tue, 16 Apr 2019 13:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 AWpkC-e8TzfU; Tue, 16 Apr 2019 13:26:38 -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 CD85C12004C; Tue, 16 Apr 2019 13:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555446396; x=1556051196; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=bZZ5od1g6tuTgBafY9OPPAYcQ2cIat10y9XlLNQjZW0=; b=QRc4Kq0/bp/A3 nMhaTTs/2jHVhzAhNTO3AT2a6SzZXMSKKtfQIEql93xbwJBMBh1KXLCqZ+bEx3xM nK/45DQIoU8XQZO/kDuZwK6zWZtlDC+3Id7b6285tafKwPRTSIBJrhrab+sMGf2X oe1s2EO65xeGg47mV4mZr3m1FmE848= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 16 Apr 2019 22:26:36 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 16 Apr 2019 22:26:35 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006221632.msg; Tue, 16 Apr 2019 22:26:35 +0200 X-MDRemoteIP: 2001:470:1f09:495:cba:2be4:400d:3cf5 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Tue, 16 Apr 2019 22:26:35 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=100922cfbb=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.8.190312 Date: Tue, 16 Apr 2019 22:26:34 +0200 From: JORDI PALET MARTINEZ To: Dan Wing CC: , Message-ID: <84D6C6E6-4F62-4078-860F-19248FCE03CE@consulintel.es> Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 References: <0565EE13-3E04-41CE-AF42-BE96ED5B65BE@gmail.com> <4573D6CB-61AC-4BB3-ACA4-B56E20E113D1@consulintel.es> <6D0132CB-D460-4D83-8F92-C11CE48E0872@gmail.com> In-Reply-To: <6D0132CB-D460-4D83-8F92-C11CE48E0872@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 16 Apr 2019 20:26:41 -0000 Hi Dan, Thanks again, below some responses.=20 =EF=BB=BFEl 16/4/19 21:24, "Dan Wing" escribi=C3=B3: On Apr 16, 2019, at 9:16 AM, JORDI PALET MARTINEZ wrote: > Hi Dan, >=20 > Thanks a lot for the inputs. >=20 > =EF=BB=BFEl 16/4/19 18:05, "v6ops en nombre de Dan Wing" escribi=C3=B3: >=20 > Fred Baker wrote: >=20 >> For the record, the question here is two-fold. First, is it correct = and complete? Is there more, or less, that should be said? Second, are ther= e operators -ISPs, IxPs, enterprise, or whatever, that consider this useful= in their deployments? >=20 > I find the document useful. >=20 >=20 > There are two things I noticed with this one sentence in Section 5= , >=20 > "however the built-in address synthesis feature is out of their = control, and can only be resolved by operating system vendors." >=20 > which should mention (1) DoT and DoH and (2) centralized un-encryp= ted DNS, detailed below. >=20 > I will update/reword the sentence. There is an explicit section (4.5.= DNS Privacy) covering that. =20 =20 Thanks for the pointer. That existing text in 4.5 makes an unstated as= sumption that the DNS-over-encrypted-channel server is not doing DNS64. I = would make that clearer. Note there are ideas floating around, such as dra= ft-reddy-dprive-bootstrap-dns-server, which have the local network provide = the DNS-over-encrypted-channel function, where DNS64 could be provided. I = don't think draft-reddy-dprive-bootstrap-dns-server is ready to be cited ye= t, but I would tighten up the wording of Section 4.5 to make clear the prob= lem is the DoH/DoT/DoQ operator is not also doing the necessary DNS64 funct= ion. If they are, the operational problem goes away (right?). Thanks, I will also re-read draft-reddy-dprive-bootstrap-dns-server and upd= ate the text. =20 =20 > 1. DoT and DoH are provided by the application, not provided by OS= vendors (at least, not yet) - but that text implies only the OS vendor can= change how DNS works on the host. DoT and DoH demonstrate otherwise. The= above text should at least mention that DoT and DoH standards have declare= d DNS64 (and thus NAT64) out of their scope but explain that an application= doing DoT/DoH will break with NAT64, and should discuss the operational di= fficulties of DoT and DoH on a network with NAT64 and DNS64. >=20 > Exactly, we had that discussion when I was working in the initial ver= sions of this document and the DoH work was on-going as well. =20 =20 Ok. I suggest changing that sentence in Section 5 something like this, =20 OLD: can only be resolved by operating system vendors NEW: can be synthesized by the OS vendor (via its DNS resolver API) or the= application (via its own own DNS resolver). I think is perfect, thanks again! =20 =20 > 2. The document should also mention using a non-network provided D= NS (e.g., 8.8.8.8) won't provide the necessary/expected DNS64. Most hosts = do not support changing DNS settings on a per-network basis, either, so usi= ng a specific DNS like 8.8.8.8 when on WiFi and using the network-provided = DNS64 when on a NAT64 network is usually not possible -- a further operatio= nal difficulty placed on the user. =20 >=20 > This is covered in Section 4.4. Manual Configuration of Foreign DNS.= I will double check that I'm not missing it in the summary. =20 =20 Thanks for the pointer. I'm confused that both section 4.4 and section= 4.5 are about manual configuration of a foreign DNS -- 4.4 is un-encrypted= , 4.5 is encrypted. =20 Another good point. The explanation is simple. I did 4.4 in earlier version= s and then created 4.5. It clearly makes sense to have a single section (4.= 4) and a sub-section for each one, so definitively will work on this tomorr= ow and try to publish how it will look like in the list to seek further com= ments. =20 -d =20 =20 > -d >=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 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 =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 Wed Apr 17 04:50:36 2019 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 93341120356; Wed, 17 Apr 2019 04:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 x4yPo7x0TOI6; Wed, 17 Apr 2019 04:50:31 -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 1816D120092; Wed, 17 Apr 2019 04:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555501828; x=1556106628; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=bVQdrvuFaeRJ4GxfnuTD3 PEfgVZybG1T8/wwXgdi3Ac=; b=vRXgpkdBzEyiUcikiBGu61jF+zC2ck7UXmfJ/ Muj/8mhEihF9dRCJU5pB/CYTXDh9gVO4vE9NvOJvQJe3v8dM3H37kN/YC2ByeCJO YaapYR6KF/wW6uue8CyRHEzOvLOYG3X5DfcPk8l2WADUA3UBiG1/X45P5CaxGAOH T/GPXE= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 17 Apr 2019 13:50:28 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 17 Apr 2019 13:50:27 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006222154.msg; Wed, 17 Apr 2019 13:50:27 +0200 X-MDRemoteIP: 2001:470:1f09:495:25e2:9e4c:ee17:b32f X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 17 Apr 2019 13:50:27 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=10107b3cc1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.9.190412 Date: Wed, 17 Apr 2019 13:50:22 +0200 From: JORDI PALET MARTINEZ To: Dan Wing CC: , Message-ID: <1BDB7B2B-BF96-4515-AA66-FA21B53FB5E7@consulintel.es> Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 17 Apr 2019 11:50:35 -0000 Hi Dan, I've reworded the complete section for "foreign DNS", as follows: 4.4. Foreign DNS When clients, in a service provider network, use DNS servers from other networks, they may support or not DNS64, so the considerations in Section 4.3 will apply as well. This may be the case either if individual applications use their own DNS server, the Operating System itself or even the CE, or combinations of all the above. Even in the case that the external DNS supports the DNS64 function, we may be in the situation of providing incorrect configurations parameters, for example un-matching WKP or NSP, or a case such the one described in Section 3.2.3. Having a CLAT, even if using an external DNS without DNS64, ensures that everything will work, so the CLAT must be considered as an advantage against user configuration errors. The cost of it is that all the traffic will use a double translation (NAT46 at the CLAT and NAT64 at the operator network), unless there is support for EAMT (Section 4.9). An exception to that is the case when there is a CLAT at the CE, which is not able to obtain the correct configuration parameters (again, un-matching WKP or NSP). However, it needs to be reinforced, that if there is not a CLAT (scenarios without 464XLAT), an external DNS without DNS64 support, will disallow any access to IPv4-only destination networks, and will not guarantee DNSSEC, so will behave as in the Section 3.2.1. The causes of "foreign DNS" could be classified in three main categories, as depicted in the following sub-sections. 4.4.1. Manual Configuration of Foreign DNS It is becoming increasingly common that end-users or even devices or=20 applications configure alternative DNS in their Operating Systems, and some times in CEs. 4.4.2. DNS Privacy A new trend is for clients or applications to use mechanisms for DNS privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC ([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH and DoQ. Those DNS privacy/encryption options, currently are typically provided by the applications, not the Operating System vendors. At the time of writing this document, at least DoT and DoH standards have declared DNS64 (and consequently NAT64) out of their scope, so an application using them may break NAT64, unless a correctly configured CLAT is used. 4.4.3. Split DNS When networks or hosts use "split-DNS" (also called Split Horizon) or private DNS,the successful use of the DNS64 is not guaranteed. Section 4. of [RFC6950], analyses this case. A similar situation may happen in case of VPNs that force all the DNS queries thru the VPN, ignoring the DNS64. =20 Then, section 5 paragraph becomes: The only 100% safe solution, which also resolves all the issues, will be, in addition to having a CLAT, not using a DNS64 but instead making sure that the hosts have a built-in address synthesis feature. Operators could manage to use the CLAT, however the built-in address synthesis feature is out of their control. If the synthesis is provided either by the Operating System (via its DNS resolver API) or by the application (via its own DNS resolver), in such way that the prefix used for the NAT64 is reachable for the host, the problem goes away. Note than when rewriting the text, I realized that even if the DoT/DoH prov= ider is able to provide a DNS64 function, this needs to "know" what is the = operator NAT64, or an alternative one, so the "operational" problem really = goes away. So, I've slightly modified your previous text suggestions, tryin= g to address that. Thanks again and happy to hear your inputs on this new text. =EF=BB=BFEl 16/4/19 22:27, "v6ops en nombre de JORDI PALET MARTINEZ" escribi=C3=B3: Hi Dan, =20 Thanks again, below some responses.=20 =20 =EF=BB=BFEl 16/4/19 21:24, "Dan Wing" escribi=C3=B3= : =20 On Apr 16, 2019, at 9:16 AM, JORDI PALET MARTINEZ wrote: > Hi Dan, >=20 > Thanks a lot for the inputs. >=20 > =EF=BB=BFEl 16/4/19 18:05, "v6ops en nombre de Dan Wing" escribi=C3=B3: >=20 > Fred Baker wrote: >=20 >> For the record, the question here is two-fold. First, is it corr= ect and complete? Is there more, or less, that should be said? Second, are = there operators -ISPs, IxPs, enterprise, or whatever, that consider this us= eful in their deployments? >=20 > I find the document useful. >=20 >=20 > There are two things I noticed with this one sentence in Secti= on 5, >=20 > "however the built-in address synthesis feature is out of th= eir control, and can only be resolved by operating system vendors." >=20 > which should mention (1) DoT and DoH and (2) centralized un-en= crypted DNS, detailed below. >=20 > I will update/reword the sentence. There is an explicit section (= 4.5. DNS Privacy) covering that. =20 =20 Thanks for the pointer. That existing text in 4.5 makes an unstate= d assumption that the DNS-over-encrypted-channel server is not doing DNS64.= I would make that clearer. Note there are ideas floating around, such as= draft-reddy-dprive-bootstrap-dns-server, which have the local network prov= ide the DNS-over-encrypted-channel function, where DNS64 could be provided.= I don't think draft-reddy-dprive-bootstrap-dns-server is ready to be cite= d yet, but I would tighten up the wording of Section 4.5 to make clear the = problem is the DoH/DoT/DoQ operator is not also doing the necessary DNS64 f= unction. If they are, the operational problem goes away (right?). =20 Thanks, I will also re-read draft-reddy-dprive-bootstrap-dns-server and= update the text. =20 =20 > 1. DoT and DoH are provided by the application, not provided b= y OS vendors (at least, not yet) - but that text implies only the OS vendor= can change how DNS works on the host. DoT and DoH demonstrate otherwise. = The above text should at least mention that DoT and DoH standards have dec= lared DNS64 (and thus NAT64) out of their scope but explain that an applica= tion doing DoT/DoH will break with NAT64, and should discuss the operationa= l difficulties of DoT and DoH on a network with NAT64 and DNS64. >=20 > Exactly, we had that discussion when I was working in the initial= versions of this document and the DoH work was on-going as well. =20 =20 Ok. I suggest changing that sentence in Section 5 something like t= his, =20 OLD: can only be resolved by operating system vendors NEW: can be synthesized by the OS vendor (via its DNS resolver API) or= the application (via its own own DNS resolver). =20 I think is perfect, thanks again! =20 =20 > 2. The document should also mention using a non-network provid= ed DNS (e.g., 8.8.8.8) won't provide the necessary/expected DNS64. Most ho= sts do not support changing DNS settings on a per-network basis, either, so= using a specific DNS like 8.8.8.8 when on WiFi and using the network-provi= ded DNS64 when on a NAT64 network is usually not possible -- a further oper= ational difficulty placed on the user. =20 >=20 > This is covered in Section 4.4. Manual Configuration of Foreign = DNS. I will double check that I'm not missing it in the summary. =20 =20 Thanks for the pointer. I'm confused that both section 4.4 and sec= tion 4.5 are about manual configuration of a foreign DNS -- 4.4 is un-encry= pted, 4.5 is encrypted. =20 =20 Another good point. The explanation is simple. I did 4.4 in earlier ver= sions and then created 4.5. It clearly makes sense to have a single section= (4.4) and a sub-section for each one, so definitively will work on this to= morrow and try to publish how it will look like in the list to seek further= comments. =20 -d =20 =20 > -d >=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 privile= ged or confidential. The information is intended to be for the exclusive us= e of the individual(s) named above and further non-explicilty authorized di= sclosure, copying, distribution or use of the contents of this information,= even if partially, including attached files, is strictly prohibited and wi= ll 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 strict= ly 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 =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 t= he individual(s) named above and further non-explicilty authorized disclosu= re, 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 awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal 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 ********************************************** 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 Wed Apr 17 05:40:59 2019 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 70FD3120091 for ; Wed, 17 Apr 2019 05:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RGXDEMAVY9WJ for ; Wed, 17 Apr 2019 05:40:54 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 541F312008D for ; Wed, 17 Apr 2019 05:40:54 -0700 (PDT) Received: from [192.168.11.4] (pl22370.ag1212.nttpc.ne.jp [1.33.49.98]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x3HCec9V013721 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 17 Apr 2019 14:40:46 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host pl22370.ag1212.nttpc.ne.jp [1.33.49.98] claimed to be [192.168.11.4] To: jordi.palet@theipv6company.com References: <1BDB7B2B-BF96-4515-AA66-FA21B53FB5E7@consulintel.es> Cc: v6ops@ietf.org From: =?UTF-8?Q?G=c3=a1bor_Lencse?= Message-ID: <0eb9d30f-7b77-7f01-3d80-6801f58386aa@hit.bme.hu> Date: Wed, 17 Apr 2019 21:40:38 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1BDB7B2B-BF96-4515-AA66-FA21B53FB5E7@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=1.33.49.98; helo=[192.168.11.4]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 17 Apr 2019 12:40:58 -0000 Hi Jordi, Could you send the "-05" version, so that I can continue on reading the most up to date text form Section 4? Perhaps it is worth sending it on the list, if possible. Thanks. Gábor On 4/17/2019 20:50, JORDI PALET MARTINEZ wrote: > Hi Dan, > > I've reworded the complete section for "foreign DNS", as follows: > > 4.4. Foreign DNS > > When clients, in a service provider network, use DNS servers from > other networks, they may support or not DNS64, so the considerations > in Section 4.3 will apply as well. > > This may be the case either if individual applications use their own > DNS server, the Operating System itself or even the CE, or > combinations of all the above. > > Even in the case that the external DNS supports the DNS64 function, we > may be in the situation of providing incorrect configurations > parameters, for example un-matching WKP or NSP, or a case such the > one described in Section 3.2.3. > > Having a CLAT, even if using an external DNS without DNS64, ensures > that everything will work, so the CLAT must be considered as an > advantage against user configuration errors. The cost of it is that > all the traffic will use a double translation (NAT46 at the CLAT and > NAT64 at the operator network), unless there is support for EAMT > (Section 4.9). > > An exception to that is the case when there is a CLAT at the CE, > which is not able to obtain the correct configuration parameters > (again, un-matching WKP or NSP). > > However, it needs to be reinforced, that if there is not a CLAT > (scenarios without 464XLAT), an external DNS without DNS64 support, > will disallow any access to IPv4-only destination networks, and will > not guarantee DNSSEC, so will behave as in the Section 3.2.1. > > The causes of "foreign DNS" could be classified in three main > categories, as depicted in the following sub-sections. > > 4.4.1. Manual Configuration of Foreign DNS > > It is becoming increasingly common that end-users or even devices or > applications configure alternative DNS in their Operating Systems, > and some times in CEs. > > 4.4.2. DNS Privacy > > A new trend is for clients or applications to use mechanisms for DNS > privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS > ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC > ([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH > and DoQ. > > Those DNS privacy/encryption options, currently are typically > provided by the applications, not the Operating System vendors. At > the time of writing this document, at least DoT and DoH standards > have declared DNS64 (and consequently NAT64) out of their scope, so > an application using them may break NAT64, unless a correctly > configured CLAT is used. > > 4.4.3. Split DNS > > When networks or hosts use "split-DNS" (also called Split Horizon) or > private DNS,the successful use of the DNS64 is not guaranteed. > Section 4. of [RFC6950], analyses this case. > > A similar situation may happen in case of VPNs that force all the DNS > queries thru the VPN, ignoring the DNS64. > > Then, section 5 paragraph becomes: > > The only 100% safe solution, which also resolves all the issues, will > be, in addition to having a CLAT, not using a DNS64 but instead > making sure that the hosts have a built-in address synthesis feature. > Operators could manage to use the CLAT, however the built-in address > synthesis feature is out of their control. If the synthesis is > provided either by the Operating System (via its DNS resolver API) or > by the application (via its own DNS resolver), in such way that the > prefix used for the NAT64 is reachable for the host, the problem goes > away. > > > Note than when rewriting the text, I realized that even if the DoT/DoH provider is able to provide a DNS64 function, this needs to "know" what is the operator NAT64, or an alternative one, so the "operational" problem really goes away. So, I've slightly modified your previous text suggestions, trying to address that. > > Thanks again and happy to hear your inputs on this new text. > > El 16/4/19 22:27, "v6ops en nombre de JORDI PALET MARTINEZ" escribió: > > Hi Dan, > > Thanks again, below some responses. > > El 16/4/19 21:24, "Dan Wing" escribió: > > On Apr 16, 2019, at 9:16 AM, JORDI PALET MARTINEZ wrote: > > Hi Dan, > > > > Thanks a lot for the inputs. > > > > El 16/4/19 18:05, "v6ops en nombre de Dan Wing" escribió: > > > > Fred Baker wrote: > > > >> For the record, the question here is two-fold. First, is it correct and complete? Is there more, or less, that should be said? Second, are there operators -ISPs, IxPs, enterprise, or whatever, that consider this useful in their deployments? > > > > I find the document useful. > > > > > > There are two things I noticed with this one sentence in Section 5, > > > > "however the built-in address synthesis feature is out of their control, and can only be resolved by operating system vendors." > > > > which should mention (1) DoT and DoH and (2) centralized un-encrypted DNS, detailed below. > > > > I will update/reword the sentence. There is an explicit section (4.5. DNS Privacy) covering that. > > > Thanks for the pointer. That existing text in 4.5 makes an unstated assumption that the DNS-over-encrypted-channel server is not doing DNS64. I would make that clearer. Note there are ideas floating around, such as draft-reddy-dprive-bootstrap-dns-server, which have the local network provide the DNS-over-encrypted-channel function, where DNS64 could be provided. I don't think draft-reddy-dprive-bootstrap-dns-server is ready to be cited yet, but I would tighten up the wording of Section 4.5 to make clear the problem is the DoH/DoT/DoQ operator is not also doing the necessary DNS64 function. If they are, the operational problem goes away (right?). > > Thanks, I will also re-read draft-reddy-dprive-bootstrap-dns-server and update the text. > > > > 1. DoT and DoH are provided by the application, not provided by OS vendors (at least, not yet) - but that text implies only the OS vendor can change how DNS works on the host. DoT and DoH demonstrate otherwise. The above text should at least mention that DoT and DoH standards have declared DNS64 (and thus NAT64) out of their scope but explain that an application doing DoT/DoH will break with NAT64, and should discuss the operational difficulties of DoT and DoH on a network with NAT64 and DNS64. > > > > Exactly, we had that discussion when I was working in the initial versions of this document and the DoH work was on-going as well. > > > Ok. I suggest changing that sentence in Section 5 something like this, > > OLD: > can only be resolved by operating system vendors > NEW: > can be synthesized by the OS vendor (via its DNS resolver API) or the application (via its own own DNS resolver). > > I think is perfect, thanks again! > > > > 2. The document should also mention using a non-network provided DNS (e.g., 8.8.8.8) won't provide the necessary/expected DNS64. Most hosts do not support changing DNS settings on a per-network basis, either, so using a specific DNS like 8.8.8.8 when on WiFi and using the network-provided DNS64 when on a NAT64 network is usually not possible -- a further operational difficulty placed on the user. > > > > This is covered in Section 4.4. Manual Configuration of Foreign DNS. I will double check that I'm not missing it in the summary. > > > Thanks for the pointer. I'm confused that both section 4.4 and section 4.5 are about manual configuration of a foreign DNS -- 4.4 is un-encrypted, 4.5 is encrypted. > > Another good point. The explanation is simple. I did 4.4 in earlier versions and then created 4.5. It clearly makes sense to have a single section (4.4) and a sub-section for each one, so definitively will work on this tomorrow and try to publish how it will look like in the list to seek further comments. > > -d > > > > -d > > > > _______________________________________________ > > 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. > > > > > > > > > > > > ********************************************** > 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 > > > > > ********************************************** > 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 Wed Apr 17 05:57:22 2019 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 6C4E8120320; Wed, 17 Apr 2019 05:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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=swm.pp.se 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 a9Iz3kbZ-D1d; Wed, 17 Apr 2019 05:57:17 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 EB5EC12015C; Wed, 17 Apr 2019 05:57:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 84285B1; Wed, 17 Apr 2019 14:57:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1555505833; bh=vVMs31nckCjMvpqHQBJwwToYG+89L6IUhDzisYZ1u6s=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vYo7sFOhi+quxYFd7mhx3sjLlhkpQMnoRRxjM7nVZmmWaCsQqtWtUuEufhG0r7jnU mmQlTcRd030A7SVWDYgZQvk1uTNcuhFsrznIuoH08XiRVARkMKyhCD01/yiuINwXFJ XN11Rrrrx9SUfqe+mTN0T0OdrYv0B6HvdFajSN94= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 822A9B0; Wed, 17 Apr 2019 14:57:13 +0200 (CEST) Date: Wed, 17 Apr 2019 14:57:13 +0200 (CEST) From: Mikael Abrahamsson To: Ron Bonica cc: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 17 Apr 2019 12:57:21 -0000 On Mon, 8 Apr 2019, Ron Bonica wrote: > Folks, > > This email initiates a Working Group Last call on draft-ietf-v6ops-nat64-deployment-04. WGLC will end at COB, April 22, 2019. I have been asked to be document shepherd of this document. The below text is not written with document shepherd hat on, but from me as a regular WG participant. ------------------- While reading through the document, I encountered some nits: In parts of the document it's called "a NAT64" and in other parts it's called "NAT64 function". I'd like to see this done the same throughout. So for instance in 3.1.1 there is: "... he DNS64 function, and the NAT64 function is provided ..." "... service provider offers the NAT64 only, and the DNS64 function ..." So in the last paragraph, say "... the NAT64 function only ..." ? Or remove the "function" from several places? I would just like to see this used the same way throughout. 3.3 a. Replace with: "DNSSEC: Are there hosts validating DNSSEC?" " As a general conclusion, we should note that if the network must support applications using literals, non-IPv6-compliant APIs, or IPv4-only hosts or applications, only the scenarios with 464XLAT, or equivalent built-in local address synthesis features, will provide a solution. " Please make this a bullet list or something, that sentence is hard to read. Also, perhaps add that it's "IPv4 literals" (if that's the case)? 4. This entire section has sentences that are hard to read because they're long and contain a lot of commas. "So, such clients, if DNS64 is enabled, will never get A records, even for IPv4-only servers, and they may be in the path before the NAT64 and accessible by IPv4." " When clients, in a service provider network, use DNS servers from other networks, for example manually configured by users, they may support or not DNS64, so the considerations in Section 4.3 will apply as well." This is not wrong per se, but it makes the sentences quite hard to read. 4.1.1 For DHCPv6 options, shouldn't RFC 7051 be mentioned here? 4.6. " As already indicated in precedent sections, the successful use of the DNS64 is not guaranteed when networks or hosts can use "split-DNS" (also called Split Horizon), private DNS. Section 4. of [RFC6950], analyses this case. This a very common situation when using VPNs." I don't understand the sentence that ends with ", private DNS". Are there some missing words here? Should it be ", also called private DNS" or something? "" a. The WKP MUST NOT be used to represent non-global IPv4 addresses. If this is required, because the network to be translated use non-global addresses then an NSP is required." "the network to be translated", can we have some other phrase here? This sentence is hard for me to parse. Perhaps: "" a. The WKP MUST NOT be used to represent non-global IPv4 addresses. If this is required because the addresses to be translated use non-global addresses, then an NSP is required." " b. The WKP MAY appear in inter-domain routing tables, if the operator provides NAT64 to peers, however special considerations related to BGP filtering are then required and IPv4-embedded IPv6 prefixes longer than the WKP MUST NOT be advertised in BGP. An NSP may be a more appropriate option in those cases." replace with: " b. The WKP MAY appear in inter-domain routing tables. If the operator provides NAT64 to peers, special considerations related to BGP filtering are then required and IPv4-embedded IPv6 prefixes longer than the WKP MUST NOT be advertised (or accepted) in BGP. An NSP may be a more appropriate option in those cases." 4.8. " Those alternatives will solve the problem for and end-hosts, however, if that end-hosts is providing "tethering" or an equivalent service to others hosts, that need to be considered as well. In other words, in a case of a cellular network, it resolves the issue for the UE itself, but may be not the case for hosts behind it." what are "those alternatives"? "problem for and end-hosts" ? Can you please take a look at this entire paragraph because I can't parse it. 4.10. typo: " an instead a single" "So, in this case, the UEs typically have a build-in CLAT client, which is doing a stateful NAT44 before the stateless NAT46." replace: "So, in this case, the UEs typically have a build-in CLAT client which is performing a stateful NAT44 translation before the stateless NAT46." 5. " It can be argued that none of the possible transition mechanisms is perfect, and somehow, we may consider that actually this is a good thing as a way to push for the IPv6 deployment, or otherwise, it may be further delayed, with clear undesirable effects for the global Internet." Can you please check this section some more? " In an ideal world will, we could safely use DNS64, if the approach proposed in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed, avoiding the cases where DNSSEC may be broken." Typo? 10.1. As a summary, I think this document needs a serious once-over in the aspect that the sentences are long and contains lots of commas (the above examples are only a few examples). Also, Jordi, I know you like this deployment strategy but it shines through in the document, especially in section 5 which isn't really a summary but almost a marketing piece (especially in the beginning). Can you look over the document (especially section 5) and keep to the facts and do a bit less of "selling" of this specific deployment scenario? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 17 06:04:32 2019 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 D2FFB120455 for ; Wed, 17 Apr 2019 06:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 EL9IbMlUWTWJ for ; Wed, 17 Apr 2019 06:04: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 340F1120355 for ; Wed, 17 Apr 2019 06:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555506264; x=1556111064; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=vPL/dz9QhdJrv8EUBTvjFyhNRqx85PXiBUriTo6eliE=; b=KC2TMynXS3rj7 OVOzEdWJLxjTJOR6dSf7qYN1FFX1wW0hV4ojW7OtjDYC86xpxtu8TaniWDvn/qUI MQ9/qdp+5tcVZELIUyMHrjlkZkU1rxb/oWx5fp3vXQEr3NAtlfyRdAEXg6VawhvL IT9caYd7SSa3tj1wyq6frAzRBibGPA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 17 Apr 2019 15:04:24 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 17 Apr 2019 15:04:23 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006222208.msg for ; Wed, 17 Apr 2019 15:04:22 +0200 X-MDRemoteIP: 2001:470:1f09:495:e9d7:3580:5ba3:bead X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 17 Apr 2019 15:04:22 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=10107b3cc1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.9.190412 Date: Wed, 17 Apr 2019 15:04:18 +0200 From: JORDI PALET MARTINEZ To: =?UTF-8?B?R8OhYm9y?= Lencse CC: Message-ID: Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 References: <1BDB7B2B-BF96-4515-AA66-FA21B53FB5E7@consulintel.es> <0eb9d30f-7b77-7f01-3d80-6801f58386aa@hit.bme.hu> In-Reply-To: <0eb9d30f-7b77-7f01-3d80-6801f58386aa@hit.bme.hu> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 17 Apr 2019 13:04:31 -0000 Hi Gabor, The changes are only those that have been reflected in emails in the list, = anyway, I will make a txt version and email directly to you. Saludos, Jordi =20 =20 =EF=BB=BFEl 17/4/19 14:41, "v6ops en nombre de G=C3=A1bor Lencse" escribi=C3=B3: Hi Jordi, =20 Could you send the "-05" version, so that I can continue on reading the= =20 most up to date text form Section 4? =20 Perhaps it is worth sending it on the list, if possible. =20 Thanks. =20 G=C3=A1bor =20 =20 On 4/17/2019 20:50, JORDI PALET MARTINEZ wrote: > Hi Dan, > > I've reworded the complete section for "foreign DNS", as follows: > > 4.4. Foreign DNS > > When clients, in a service provider network, use DNS servers from > other networks, they may support or not DNS64, so the considerati= ons > in Section 4.3 will apply as well. > > This may be the case either if individual applications use their = own > DNS server, the Operating System itself or even the CE, or > combinations of all the above. > > Even in the case that the external DNS supports the DNS64 functio= n, we > may be in the situation of providing incorrect configurations > parameters, for example un-matching WKP or NSP, or a case such th= e > one described in Section 3.2.3. > > Having a CLAT, even if using an external DNS without DNS64, ensur= es > that everything will work, so the CLAT must be considered as an > advantage against user configuration errors. The cost of it is t= hat > all the traffic will use a double translation (NAT46 at the CLAT = and > NAT64 at the operator network), unless there is support for EAMT > (Section 4.9). > > An exception to that is the case when there is a CLAT at the CE, > which is not able to obtain the correct configuration parameters > (again, un-matching WKP or NSP). > > However, it needs to be reinforced, that if there is not a CLAT > (scenarios without 464XLAT), an external DNS without DNS64 suppor= t, > will disallow any access to IPv4-only destination networks, and w= ill > not guarantee DNSSEC, so will behave as in the Section 3.2.1. > > The causes of "foreign DNS" could be classified in three main > categories, as depicted in the following sub-sections. > > 4.4.1. Manual Configuration of Foreign DNS > > It is becoming increasingly common that end-users or even devices= or > applications configure alternative DNS in their Operating Systems= , > and some times in CEs. > > 4.4.2. DNS Privacy > > A new trend is for clients or applications to use mechanisms for = DNS > privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DT= LS > ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC > ([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, = DoH > and DoQ. > > Those DNS privacy/encryption options, currently are typically > provided by the applications, not the Operating System vendors. = At > the time of writing this document, at least DoT and DoH standards > have declared DNS64 (and consequently NAT64) out of their scope, = so > an application using them may break NAT64, unless a correctly > configured CLAT is used. > > 4.4.3. Split DNS > > When networks or hosts use "split-DNS" (also called Split Horizon= ) or > private DNS,the successful use of the DNS64 is not guaranteed. > Section 4. of [RFC6950], analyses this case. > > A similar situation may happen in case of VPNs that force all the= DNS > queries thru the VPN, ignoring the DNS64. > =20 > Then, section 5 paragraph becomes: > > The only 100% safe solution, which also resolves all the issues, = will > be, in addition to having a CLAT, not using a DNS64 but instead > making sure that the hosts have a built-in address synthesis feat= ure. > Operators could manage to use the CLAT, however the built-in addr= ess > synthesis feature is out of their control. If the synthesis is > provided either by the Operating System (via its DNS resolver API= ) or > by the application (via its own DNS resolver), in such way that t= he > prefix used for the NAT64 is reachable for the host, the problem = goes > away. > > > Note than when rewriting the text, I realized that even if the DoT/Do= H provider is able to provide a DNS64 function, this needs to "know" what i= s the operator NAT64, or an alternative one, so the "operational" problem r= eally goes away. So, I've slightly modified your previous text suggestions,= trying to address that. > > Thanks again and happy to hear your inputs on this new text. > > =EF=BB=BFEl 16/4/19 22:27, "v6ops en nombre de JORDI PALET MARTINEZ" = escribi=C3=B3: > > Hi Dan, > =20 > Thanks again, below some responses. > =20 > =EF=BB=BFEl 16/4/19 21:24, "Dan Wing" escrib= i=C3=B3: > =20 > On Apr 16, 2019, at 9:16 AM, JORDI PALET MARTINEZ wrote: > > Hi Dan, > > > > Thanks a lot for the inputs. > > > > =EF=BB=BFEl 16/4/19 18:05, "v6ops en nombre de Dan Wing" <= v6ops-bounces@ietf.org en nombre de danwing@gmail.com> escribi=C3=B3: > > > > Fred Baker wrote: > > > >> For the record, the question here is two-fold. First, is = it correct and complete? Is there more, or less, that should be said? Secon= d, are there operators -ISPs, IxPs, enterprise, or whatever, that consider = this useful in their deployments? > > > > I find the document useful. > > > > > > There are two things I noticed with this one sentence i= n Section 5, > > > > "however the built-in address synthesis feature is ou= t of their control, and can only be resolved by operating system vendors." > > > > which should mention (1) DoT and DoH and (2) centralize= d un-encrypted DNS, detailed below. > > > > I will update/reword the sentence. There is an explicit se= ction (4.5. DNS Privacy) covering that. > =20 > =20 > Thanks for the pointer. That existing text in 4.5 makes an = unstated assumption that the DNS-over-encrypted-channel server is not doing= DNS64. I would make that clearer. Note there are ideas floating around, = such as draft-reddy-dprive-bootstrap-dns-server, which have the local netwo= rk provide the DNS-over-encrypted-channel function, where DNS64 could be pr= ovided. I don't think draft-reddy-dprive-bootstrap-dns-server is ready to = be cited yet, but I would tighten up the wording of Section 4.5 to make cle= ar the problem is the DoH/DoT/DoQ operator is not also doing the necessary = DNS64 function. If they are, the operational problem goes away (right?). > =20 > Thanks, I will also re-read draft-reddy-dprive-bootstrap-dns-ser= ver and update the text. > =20 > =20 > > 1. DoT and DoH are provided by the application, not pro= vided by OS vendors (at least, not yet) - but that text implies only the OS= vendor can change how DNS works on the host. DoT and DoH demonstrate othe= rwise. The above text should at least mention that DoT and DoH standards h= ave declared DNS64 (and thus NAT64) out of their scope but explain that an = application doing DoT/DoH will break with NAT64, and should discuss the ope= rational difficulties of DoT and DoH on a network with NAT64 and DNS64. > > > > Exactly, we had that discussion when I was working in the = initial versions of this document and the DoH work was on-going as well. > =20 > =20 > Ok. I suggest changing that sentence in Section 5 something= like this, > =20 > OLD: > can only be resolved by operating system vendors > NEW: > can be synthesized by the OS vendor (via its DNS resolver = API) or the application (via its own own DNS resolver). > =20 > I think is perfect, thanks again! > =20 > =20 > > 2. The document should also mention using a non-network= provided DNS (e.g., 8.8.8.8) won't provide the necessary/expected DNS64. = Most hosts do not support changing DNS settings on a per-network basis, eit= her, so using a specific DNS like 8.8.8.8 when on WiFi and using the networ= k-provided DNS64 when on a NAT64 network is usually not possible -- a furth= er operational difficulty placed on the user. > > > > This is covered in Section 4.4. Manual Configuration of F= oreign DNS. I will double check that I'm not missing it in the summary. > =20 > =20 > Thanks for the pointer. I'm confused that both section 4.4 = and section 4.5 are about manual configuration of a foreign DNS -- 4.4 is u= n-encrypted, 4.5 is encrypted. > =20 > Another good point. The explanation is simple. I did 4.4 in earl= ier versions and then created 4.5. It clearly makes sense to have a single = section (4.4) and a sub-section for each one, so definitively will work on = this tomorrow and try to publish how it will look like in the list to seek = further comments. > =20 > -d > =20 > =20 > > -d > > > > _______________________________________________ > > 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 exclu= sive use of the individual(s) named above and further non-explicilty author= ized disclosure, copying, distribution or use of the contents of this infor= mation, even if partially, including attached files, is strictly prohibited= and will be considered a criminal offense. If you are not the intended rec= ipient be aware that any disclosure, copying, distribution or use of the co= ntents of this information, even if partially, including attached files, is= strictly prohibited, will be considered a criminal offense, so you must re= ply to the original sender to inform about this communication and delete it= . > > > > > > > =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 privil= eged or confidential. The information is intended to be for the exclusive u= se of the individual(s) named above and further non-explicilty authorized d= isclosure, copying, distribution or use of the contents of this information= , even if partially, including attached files, is strictly prohibited and w= ill 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 stric= tly 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 > =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 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. > > > > _______________________________________________ > 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 Wed Apr 17 06:38:17 2019 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 01ED3120364; Wed, 17 Apr 2019 06:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ChN-POEtVKRP; Wed, 17 Apr 2019 06:38:07 -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 B8DF112034A; Wed, 17 Apr 2019 06:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555508283; x=1556113083; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=HATRC8sYnXo7SuWzKdqf2Nv98JkG3eHm2EdMzKRyRo4=; b=WuzeRis+Ge2Qs yhkYS9iK6K+s/h6FUEodNJcxU4OYQqtA63ujgTKa+RjYngr6oD400epbQAhA2GAq 55p0JzxQ2E9fNZjaOurYjm5rYve5k9XkwhBr6kzjaBMbXu/pgYsjIYpCnlaEqWu3 497uaY8F3JelG7cWm86KyzZdg2LgKk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 17 Apr 2019 15:38:03 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 17 Apr 2019 15:38:03 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006222232.msg; Wed, 17 Apr 2019 15:38:02 +0200 X-MDRemoteIP: 2001:470:1f09:495:e9d7:3580:5ba3:bead X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 17 Apr 2019 15:38:02 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=10107b3cc1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.9.190412 Date: Wed, 17 Apr 2019 15:37:59 +0200 From: JORDI PALET MARTINEZ To: Mikael Abrahamsson , Ron Bonica CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" Message-ID: <203DF4C2-3BC0-4521-B28F-0B56E2BF2690@consulintel.es> Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 17 Apr 2019 13:38:10 -0000 Hi Mikael, Thanks for the review ... responding in-line. =EF=BB=BFEl 17/4/19 14:57, "v6ops en nombre de Mikael Abrahamsson" escribi=C3=B3: On Mon, 8 Apr 2019, Ron Bonica wrote: =20 > Folks, > > This email initiates a Working Group Last call on draft-ietf-v6ops-na= t64-deployment-04. WGLC will end at COB, April 22, 2019. =20 I have been asked to be document shepherd of this document. The below t= ext=20 is not written with document shepherd hat on, but from me as a regular = WG=20 participant. =20 ------------------- =20 While reading through the document, I encountered some nits: =20 In parts of the document it's called "a NAT64" and in other parts it's= =20 called "NAT64 function". I'd like to see this done the same throughout.= So=20 for instance in 3.1.1 there is: =20 "... he DNS64 function, and the NAT64 function is provided ..." =20 "... service provider offers the NAT64 only, and the DNS64 function ...= " =20 So in the last paragraph, say "... the NAT64 function only ..." ? Or=20 remove the "function" from several places? I would just like to see thi= s=20 used the same way throughout. I think it will be more clear to use "function" all the way thru (expect if= there is a specific reason for not doing so - now just thinking loud), but= I'm going to review all the document and make sure about one or the other = way and make it uniform for the v05. =20 =20 3.3 a. =20 Replace with: "DNSSEC: Are there hosts validating DNSSEC?" Done! =20 =20 " As a general conclusion, we should note that if the network must support applications using literals, non-IPv6-compliant APIs, or IPv4-only hosts or applications, only the scenarios with 464XLAT, o= r equivalent built-in local address synthesis features, will provide = a solution. " =20 Please make this a bullet list or something, that sentence is hard to= =20 read. Also, perhaps add that it's "IPv4 literals" (if that's the case)? Done! =20 4. =20 This entire section has sentences that are hard to read because they're= =20 long and contain a lot of commas. =20 "So, such clients, if DNS64 is enabled, will never get A records, even for IPv4-only servers, and they may = be in the path before the NAT64 and accessible by IPv4." =20 " When clients, in a service provider network, use DNS servers from other networks, for example manually configured by users, they may support or not DNS64, so the considerations in Section 4.3 will app= ly as well." =20 This is not wrong per se, but it makes the sentences quite hard to read= . Will work on this tonight. =20 4.1.1 =20 For DHCPv6 options, shouldn't RFC 7051 be mentioned here? Will re-read and do. =20 4.6. =20 " As already indicated in precedent sections, the successful use of t= he DNS64 is not guaranteed when networks or hosts can use "split-DNS" (also called Split Horizon), private DNS. Section 4. of [RFC6950], analyses this case. This a very common situation when using VPNs." =20 I don't understand the sentence that ends with ", private DNS". Are the= re=20 some missing words here? Should it be ", also called private DNS" or=20 something? This has been already reworded (see the previous email). I will clarify any= way, if is still not sufficient. =20 "" a. The WKP MUST NOT be used to represent non-global IPv4 addresses= . If this is required, because the network to be translated use non-global addresses then an NSP is required." =20 "the network to be translated", can we have some other phrase here? Thi= s=20 sentence is hard for me to parse. Perhaps: =20 "" a. The WKP MUST NOT be used to represent non-global IPv4 addresses= . If this is required because the addresses to be translated use non-global addresses, then an NSP is required." =20 " b. The WKP MAY appear in inter-domain routing tables, if the operator provides NAT64 to peers, however special consideration= s related to BGP filtering are then required and IPv4-embedded IP= v6 prefixes longer than the WKP MUST NOT be advertised in BGP. An NSP may be a more appropriate option in those cases." =20 replace with: =20 " b. The WKP MAY appear in inter-domain routing tables. If the operator provides NAT64 to peers, special considerations related to BGP filtering are then required and IPv4-embedded IP= v6 prefixes longer than the WKP MUST NOT be advertised (or accepte= d) in BGP. An NSP may be a more appropriate option in those cases= ." Yeah both rewordings look fine. =20 4.8. =20 " Those alternatives will solve the problem for and end-hosts, howeve= r, if that end-hosts is providing "tethering" or an equivalent service to others hosts, that need to be considered as well. In other word= s, in a case of a cellular network, it resolves the issue for the UE itself, but may be not the case for hosts behind it." =20 what are "those alternatives"? Will reword. =20 "problem for and end-hosts" ? Can you please take a look at this entire= =20 paragraph because I can't parse it. Will reword. =20 4.10. =20 typo: " an instead a single" Done! =20 "So, in this case, the UEs typically have a build-in CLAT client, which is doing= a stateful NAT44 before the stateless NAT46." =20 replace: =20 "So, in this case, the UEs typically have a build-in CLAT client which is perfor= ming a stateful NAT44 translation before the stateless NAT46." Done! =20 5. =20 " It can be argued that none of the possible transition mechanisms is perfect, and somehow, we may consider that actually this is a good thing as a way to push for the IPv6 deployment, or otherwise, it ma= y be further delayed, with clear undesirable effects for the global Internet." =20 Can you please check this section some more? Will do! =20 " In an ideal world will, we could safely use DNS64, if the approach proposed in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed, avoiding the cases where DNSSEC may be broken." =20 Typo? Done! =20 10.1. =20 As a summary, I think this document needs a serious once-over in the=20 aspect that the sentences are long and contains lots of commas (the abo= ve=20 examples are only a few examples). I will review all the doc again to try to avoid all the long sentences. I t= end to do that, and I know "how to read them" but I understand is not easy = to read for everyone from scratch. =20 Also, Jordi, I know you like this deployment strategy but it shines=20 through in the document, especially in section 5 which isn't really a= =20 summary but almost a marketing piece (especially in the beginning). Can= =20 you look over the document (especially section 5) and keep to the facts= =20 and do a bit less of "selling" of this specific deployment scenario? I was tempted several times to change the title of this section. I will rev= iew it and check how to better approach this change. Maybe we don't need a = summary, or clearly state "if you decide to use NAT64 or 464XLAT, this is t= he decision flow chart" (or something in this line). Thanks a lot! Regards, Jordi =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =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 Wed Apr 17 10:42:17 2019 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 DB8BB1200C1; Wed, 17 Apr 2019 10:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HN8ynlznTKdm; Wed, 17 Apr 2019 10:42:12 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 76E4C120187; Wed, 17 Apr 2019 10:41:38 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id d46so16895144eda.7; Wed, 17 Apr 2019 10:41:38 -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=kqhGKOb/2vm2cDqfZIJWfPVm0rEA5Hp1abV8l/8ulBM=; b=ggI46eEqiS1DPq/9Jw8ULJ/+Shv3Ql230VRCgd3molD+07vcT/xco/S/Gbz+NMWH9W wy5XBEoTKZK5jV4oc8Oh+SFdrxCE9Yz4OgQQiANoA9upC0Czsvwmm4tdVwjFhWKi7q45 xGAEGfp8IjoRfVFd+ayUl/etvH2PQ9dGG8IaaMbw2Mv+TFBKMM3DesBSuRT2BdLiW3A0 BbtBAC7q/DMRV3Fl4m5LP16WBuSFE0Ei5aW5/fiOmjmt4pGxg0JAgELsN4G3LCgIp0Rc XkbeQzXd3vX0NtqviX3dpjFFj75xWDwHmsIvaT+XfDSA/cGE7dqWgsmdqh2Qs1Zli3Vg vuNQ== 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=kqhGKOb/2vm2cDqfZIJWfPVm0rEA5Hp1abV8l/8ulBM=; b=grZRdumsXZTTvMvM8Xqc4q6ZI0lWkihiJlrasIJpPuIZG1OnCrCFj2y0vWA1HBKlrJ 6YXYCNBr8rdPktHkSnxp74VolzsoXwZsMCJg2K4cZhKIQ5dIvLhTNznvbPpF84dXYzDD iws56DqXLsZQuQnQaFbbLcnm66P58lKMK3paQ4XDyIouAwPSqSKP7Scaad/34SWnRAY0 Cn0XzNiB/0qgTdnafN/EF/ui4cXxJgMbsgGj1d2T00E4bzvrvAAyfnh2J2bdEMXRPsJ+ NTQyS+Cik+2vchsGc0UObvV/buwSb/gaGSpNwqWQOEMmhgc3QW/0lzC+hY2A8WIx/4CH 07yA== X-Gm-Message-State: APjAAAVKKyXyHbULiahZcbERBoqT59CGhMiL/iZl+vyd5CkUc1l9AesA MvZqAcZplIW3Zju7nQAhC10B8fdl X-Google-Smtp-Source: APXvYqwYEqhEeGml3MIc20Njtk0c+wuQ/Jh8vX7RnNchfBQaHFOFC6PqOcWiuypolArfzN73BOIy8Q== X-Received: by 2002:a50:b48f:: with SMTP id w15mr7718196edd.242.1555522896999; Wed, 17 Apr 2019 10:41:36 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:164::1002? ([2600:8802:5600:164::1002]) by smtp.gmail.com with ESMTPSA id g91sm1396658ede.41.2019.04.17.10.41.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 10:41:35 -0700 (PDT) From: Fred Baker Message-Id: <0017F057-33A5-4E74-A44F-97AD053A3A54@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8B3A61C6-0FB8-42C6-9C36-94F46C440A08"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 17 Apr 2019 10:41:32 -0700 In-Reply-To: <203DF4C2-3BC0-4521-B28F-0B56E2BF2690@consulintel.es> Cc: Mikael Abrahamsson , Ron Bonica , "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" To: JORDI PALET MARTINEZ References: <203DF4C2-3BC0-4521-B28F-0B56E2BF2690@consulintel.es> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 17 Apr 2019 17:42:15 -0000 --Apple-Mail=_8B3A61C6-0FB8-42C6-9C36-94F46C440A08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I'd suggest you post -05 for people to comment on, and -06 over the = weekend. > On Apr 17, 2019, at 6:37 AM, JORDI PALET MARTINEZ = wrote: >=20 > Hi Mikael, >=20 > Thanks for the review ... responding in-line. >=20 > =EF=BB=BFEl 17/4/19 14:57, "v6ops en nombre de Mikael Abrahamsson" = escribi=C3=B3: >=20 > On Mon, 8 Apr 2019, Ron Bonica wrote: >=20 >> Folks, >>=20 >> This email initiates a Working Group Last call on = draft-ietf-v6ops-nat64-deployment-04. WGLC will end at COB, April 22, = 2019. >=20 > I have been asked to be document shepherd of this document. The = below text > is not written with document shepherd hat on, but from me as a = regular WG > participant. >=20 > ------------------- >=20 > While reading through the document, I encountered some nits: >=20 > In parts of the document it's called "a NAT64" and in other parts = it's > called "NAT64 function". I'd like to see this done the same = throughout. So > for instance in 3.1.1 there is: >=20 > "... he DNS64 function, and the NAT64 function is provided ..." >=20 > "... service provider offers the NAT64 only, and the DNS64 function = ..." >=20 > So in the last paragraph, say "... the NAT64 function only ..." ? = Or > remove the "function" from several places? I would just like to see = this > used the same way throughout. >=20 > I think it will be more clear to use "function" all the way thru = (expect if there is a specific reason for not doing so - now just = thinking loud), but I'm going to review all the document and make sure = about one or the other way and make it uniform for the v05. >=20 >=20 > 3.3 a. >=20 > Replace with: "DNSSEC: Are there hosts validating DNSSEC?" >=20 > Done! >=20 >=20 > " As a general conclusion, we should note that if the network = must > support applications using literals, non-IPv6-compliant APIs, = or > IPv4-only hosts or applications, only the scenarios with = 464XLAT, or > equivalent built-in local address synthesis features, will = provide a > solution. " >=20 > Please make this a bullet list or something, that sentence is hard = to > read. Also, perhaps add that it's "IPv4 literals" (if that's the = case)? >=20 > Done! >=20 > 4. >=20 > This entire section has sentences that are hard to read because = they're > long and contain a lot of commas. >=20 > "So, such clients, if DNS64 is enabled, > will never get A records, even for IPv4-only servers, and they = may be > in the path before the NAT64 and accessible by IPv4." >=20 > " When clients, in a service provider network, use DNS servers = from > other networks, for example manually configured by users, they = may > support or not DNS64, so the considerations in Section 4.3 will = apply > as well." >=20 > This is not wrong per se, but it makes the sentences quite hard to = read. >=20 > Will work on this tonight. >=20 > 4.1.1 >=20 > For DHCPv6 options, shouldn't RFC 7051 be mentioned here? >=20 > Will re-read and do. >=20 > 4.6. >=20 > " As already indicated in precedent sections, the successful use = of the > DNS64 is not guaranteed when networks or hosts can use = "split-DNS" > (also called Split Horizon), private DNS. Section 4. of = [RFC6950], > analyses this case. This a very common situation when using = VPNs." >=20 > I don't understand the sentence that ends with ", private DNS". Are = there > some missing words here? Should it be ", also called private DNS" = or > something? >=20 >=20 > This has been already reworded (see the previous email). I will = clarify anyway, if is still not sufficient. >=20 >=20 > "" a. The WKP MUST NOT be used to represent non-global IPv4 = addresses. > If this is required, because the network to be translated = use > non-global addresses then an NSP is required." >=20 > "the network to be translated", can we have some other phrase here? = This > sentence is hard for me to parse. Perhaps: >=20 > "" a. The WKP MUST NOT be used to represent non-global IPv4 = addresses. > If this is required because the addresses to be translated = use > non-global addresses, then an NSP is required." >=20 > " b. The WKP MAY appear in inter-domain routing tables, if the > operator provides NAT64 to peers, however special = considerations > related to BGP filtering are then required and = IPv4-embedded IPv6 > prefixes longer than the WKP MUST NOT be advertised in BGP. = An > NSP may be a more appropriate option in those cases." >=20 > replace with: >=20 > " b. The WKP MAY appear in inter-domain routing tables. If the > operator provides NAT64 to peers, special considerations > related to BGP filtering are then required and = IPv4-embedded IPv6 > prefixes longer than the WKP MUST NOT be advertised (or = accepted) > in BGP. An NSP may be a more appropriate option in those = cases." >=20 > Yeah both rewordings look fine. >=20 > 4.8. >=20 > " Those alternatives will solve the problem for and end-hosts, = however, > if that end-hosts is providing "tethering" or an equivalent = service > to others hosts, that need to be considered as well. In other = words, > in a case of a cellular network, it resolves the issue for the = UE > itself, but may be not the case for hosts behind it." >=20 > what are "those alternatives"? >=20 > Will reword. >=20 > "problem for and end-hosts" ? Can you please take a look at this = entire > paragraph because I can't parse it. >=20 > Will reword. >=20 > 4.10. >=20 > typo: " an instead a single" >=20 > Done! >=20 > "So, in this > case, the UEs typically have a build-in CLAT client, which is = doing a > stateful NAT44 before the stateless NAT46." >=20 > replace: >=20 > "So, in this > case, the UEs typically have a build-in CLAT client which is = performing > a stateful NAT44 translation before the stateless NAT46." >=20 >=20 > Done! >=20 > 5. >=20 > " It can be argued that none of the possible transition = mechanisms is > perfect, and somehow, we may consider that actually this is a = good > thing as a way to push for the IPv6 deployment, or otherwise, = it may > be further delayed, with clear undesirable effects for the = global > Internet." >=20 > Can you please check this section some more? >=20 > Will do! >=20 > " In an ideal world will, we could safely use DNS64, if the = approach > proposed in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed, > avoiding the cases where DNSSEC may be broken." >=20 > Typo? >=20 > Done! >=20 > 10.1. >=20 > As a summary, I think this document needs a serious once-over in = the > aspect that the sentences are long and contains lots of commas (the = above > examples are only a few examples). >=20 > I will review all the doc again to try to avoid all the long = sentences. I tend to do that, and I know "how to read them" but I = understand is not easy to read for everyone from scratch. >=20 > Also, Jordi, I know you like this deployment strategy but it shines > through in the document, especially in section 5 which isn't really = a > summary but almost a marketing piece (especially in the beginning). = Can > you look over the document (especially section 5) and keep to the = facts > and do a bit less of "selling" of this specific deployment = scenario? >=20 > I was tempted several times to change the title of this section. I = will review it and check how to better approach this change. Maybe we = don't need a summary, or clearly state "if you decide to use NAT64 or = 464XLAT, this is the decision flow chart" (or something in this line). >=20 >=20 > Thanks a lot! >=20 > Regards, > Jordi >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se >=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 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 = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_8B3A61C6-0FB8-42C6-9C36-94F46C440A08 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+AFAly3ZUwACgkQEhdRnd2G P+CLhg//Qz42WTZAoA4yan+jUb+H6fNQJXKsus0PhXUzkWKf24HER4d3Dh7nU9vF CcwokVdN4ueydGOclki228CEJmz7dC4kz4xl3ehWEMciTg0WDYffAdHDQEgU8TSY XlcpJWVEDC6d3gi8bK3isYi6wmNQh0WAttr6R5QEz0jlhXMA+U2ICCKiOLOlIyde pNnRALFkCqkt7+h8PiAb3dn3Lpu8fzNBFsq7YW7IqM2FFsxpUtRl4G6tStuCDHzi jbBVtMpJmgJhHR3fiOLfsTBDsalGnbETV037YSV5C6mnWz9lh5c2yTCfmPlpSuKH B5l3jrzWKroikn60sMGJiRZFZKwdviM+xmTebcKV1g+jh++hsJfJoUT1Ky94u5zq IBkQAtniE7B8zrF+ORgK4ZRK1OAZD0hLPgEjQCbwsKM48Jv4u1kevMwOyhEkxU/C LvD3jL0sitprSZQxzv2odGgz5FcxltwddjL2fNkv8fp1f4rHLS59bRNPjzAvyIsB 1+k1brB9dxOG46T5TJqfsWfSCDZXJ1wIb1dED5zEXcAzkY04/K7YbQuZ1FKJ9UJZ UHw2M71Ywapk00A/NRy6rd7ixvp+XCvhPW+WU4MVWjz0uI4Gpq+cv/F9nstAJe/J 4HA+fdShngoUIYQ3MC9HP5WcGPxTnByoSxkuMeBkP+cSOvbeEQo= =Lmbs -----END PGP SIGNATURE----- --Apple-Mail=_8B3A61C6-0FB8-42C6-9C36-94F46C440A08-- From nobody Thu Apr 18 02:42:47 2019 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 546CC12016D; Thu, 18 Apr 2019 02:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 sJBehUH3TWe9; Thu, 18 Apr 2019 02:42:44 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043A7120123; Thu, 18 Apr 2019 02:42:44 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 44lDfp3KV1zFqPj; Thu, 18 Apr 2019 11:42:42 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 44lDfp2TzvzCqkK; Thu, 18 Apr 2019 11:42:42 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM34.corporate.adroot.infra.ftgroup ([fe80::7873:1668:636f:52c%21]) with mapi id 14.03.0439.000; Thu, 18 Apr 2019 11:42:41 +0200 From: To: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" Thread-Topic: WGLC: draft-ietf-v6ops-nat64-deployment-04 Thread-Index: AdTuFevwhUrweEmoS22jgEJvFmhhxwHtKmKg Date: Thu, 18 Apr 2019 09:42:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA626D2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 18 Apr 2019 09:42:45 -0000 Hi Jordi, all, FWIW, you may find some comments to this version at:=20 * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-i= etf-v6ops-nat64-deployment-04-rev%20Med.pdf=20 * doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ie= tf-v6ops-nat64-deployment-04-rev%20Med.doc Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Ron Bonica > Envoy=E9=A0: lundi 8 avril 2019 16:20 > =C0=A0: v6ops@ietf.org; draft-ietf-v6ops-nat64-deployment@ietf.org > Objet=A0: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 >=20 > Folks, >=20 > This email initiates a Working Group Last call on draft-ietf-v6ops-nat64- > deployment-04. WGLC will end at COB, April 22, 2019. >=20 > Authors, >=20 > Please respond to this message indicating whether you are aware of any IP= R > regarding this draft. >=20 > Ron >=20 >=20 > Juniper Internal >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Apr 18 02:59:39 2019 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 6110F1202F2; Thu, 18 Apr 2019 02:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 SDivR8wA_Gco; Thu, 18 Apr 2019 02:59: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 9BB481202F6; Thu, 18 Apr 2019 02:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555581571; x=1556186371; 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=VsY+szRTNDcD4vnZPK2T9 /4RjqBd2nbdgL6AJX2tFLw=; b=Gau54E3o1FnC2izvGisEaHpe86HZR+7gffLzx rNHtomJlmu2snvJKxK7ROuWmLWZu83TaQ2Q5oVcZahViyMECMr0+bv+IvtZUzdT2 Q5lBxOwetuORwrJkFOSxd4t08Tfe4cr58oPsRJ+qlGXDPKBGvQr7P/zA/aNE+n33 RmWY+k= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 18 Apr 2019 11:59:31 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 18 Apr 2019 11:59:31 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006222834.msg; Thu, 18 Apr 2019 11:59:30 +0200 X-MDRemoteIP: 2001:470:1f09:495:6949:ce4a:8242:5d4b X-MDHelo: [10.10.10.139] X-MDArrival-Date: Thu, 18 Apr 2019 11:59:30 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1011068430=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.9.190412 Date: Thu, 18 Apr 2019 11:59:27 +0200 From: JORDI PALET MARTINEZ To: , "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" Message-ID: Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 18 Apr 2019 09:59:37 -0000 Hi Med, Thanks a lot for your detailed review. I may come back with any doubt's or = questions later on. I'm already working in your inputs as well as Mikael ones. The plan is now to publish a new version (v05) during the day (I will try t= o accommodate other inputs that come today as well), and I will continue wo= rking if needed, in a new version on Sunday/Monday. Regards, Jordi =20 =20 =EF=BB=BFEl 18/4/19 11:43, "v6ops-bounces@ietf.org en nombre de mohamed.bou= cadair@orange.com" escribi=C3=B3: Hi Jordi, all, =20 FWIW, you may find some comments to this version at:=20 =20 * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/dra= ft-ietf-v6ops-nat64-deployment-04-rev%20Med.pdf=20 * doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draf= t-ietf-v6ops-nat64-deployment-04-rev%20Med.doc =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Ron Bonica > Envoy=C3=A9 : lundi 8 avril 2019 16:20 > =C3=80 : v6ops@ietf.org; draft-ietf-v6ops-nat64-deployment@ietf.org > Objet : [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 >=20 > Folks, >=20 > This email initiates a Working Group Last call on draft-ietf-v6ops-na= t64- > deployment-04. WGLC will end at COB, April 22, 2019. >=20 > Authors, >=20 > Please respond to this message indicating whether you are aware of an= y IPR > regarding this draft. >=20 > = Ron >=20 >=20 > Juniper Internal >=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 Apr 18 05:07:33 2019 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 BB31B1200A0 for ; Thu, 18 Apr 2019 05:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 v4RW7JJ9dQK9 for ; Thu, 18 Apr 2019 05:07:27 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 1256E120052 for ; Thu, 18 Apr 2019 05:07:25 -0700 (PDT) Received: from [192.168.11.4] (pl22370.ag1212.nttpc.ne.jp [1.33.49.98]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x3IC6pnw043536 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 18 Apr 2019 14:06:59 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host pl22370.ag1212.nttpc.ne.jp [1.33.49.98] claimed to be [192.168.11.4] To: JORDI PALET MARTINEZ Cc: v6ops@ietf.org References: <1BDB7B2B-BF96-4515-AA66-FA21B53FB5E7@consulintel.es> <0eb9d30f-7b77-7f01-3d80-6801f58386aa@hit.bme.hu> From: =?UTF-8?Q?G=c3=a1bor_Lencse?= Message-ID: <8ef2c5e3-88cd-5524-40e9-3631f4b75a5a@hit.bme.hu> Date: Thu, 18 Apr 2019 21:06:54 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A8E134D00DF4B5C869F3EF68" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=1.33.49.98; helo=[192.168.11.4]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: [v6ops] Minor additions/corrections -- Re: WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 18 Apr 2019 12:07:32 -0000 This is a multi-part message in MIME format. --------------A8E134D00DF4B5C869F3EF68 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jordi, Just a few suggestions: 12.ANNEX C: Benchmarking Several documents provide references to benchmarking, for example in the case of DNS64, [DNS64-Benchm]. --> 12.ANNEX C: Benchmarking ***[RFC8219] has defined a benchmarking methodology for IPv6 transition ** **   technologies. NAT64 and 464XLAT is addressed among the single ** **   translation and double translation technologies, respectively. DNS64    is addressed**its Section 9, and the methodology is more elaborated in ** **   [DNS64-BM-Meth].*    Several documents provide references to benchmarking *results*, for example in the case of DNS64, [DNS64-Benchm]. 16.2.Informative References [...] [DNS64-Benchm] "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications _(Elsevier_), vol. 127, no. 1, pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September 2018. --> [DNS64-Benchm] *Lencse, G. and Y. Kadobayashi, *"Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications, vol. 127, no. 1, pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September 2018. *[DNS64-BM-Meth] **Lencse, G., Georgescu, ***M. *and Y. Kadobayashi, "Benchmarking               Methodology for DNS64 Servers", Computer Communications,               vol. 109, no. 1, pp. 162-175, September 1, 2017,               DOI: 10.1016/j.comcom.2017.06.004* [Threat-DNS64] "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security _(Elsevier)_, vol. 77, no. 1, pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August 2018. --> [Threat-DNS64] *Lencse, G. and Y. Kadobayashi, *"Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security, vol. 77, no. 1, pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August 2018. Best regards, Gábor On 4/17/2019 22:04, JORDI PALET MARTINEZ wrote: > Hi Gabor, > > The changes are only those that have been reflected in emails in the list, anyway, I will make a txt version and email directly to you. > > Saludos, > Jordi > > > > El 17/4/19 14:41, "v6ops en nombre de Gábor Lencse" escribió: > > Hi Jordi, > > Could you send the "-05" version, so that I can continue on reading the > most up to date text form Section 4? > > Perhaps it is worth sending it on the list, if possible. > > Thanks. > > Gábor > > > On 4/17/2019 20:50, JORDI PALET MARTINEZ wrote: > > Hi Dan, > > > > I've reworded the complete section for "foreign DNS", as follows: > > > > 4.4. Foreign DNS > > > > When clients, in a service provider network, use DNS servers from > > other networks, they may support or not DNS64, so the considerations > > in Section 4.3 will apply as well. > > > > This may be the case either if individual applications use their own > > DNS server, the Operating System itself or even the CE, or > > combinations of all the above. > > > > Even in the case that the external DNS supports the DNS64 function, we > > may be in the situation of providing incorrect configurations > > parameters, for example un-matching WKP or NSP, or a case such the > > one described in Section 3.2.3. > > > > Having a CLAT, even if using an external DNS without DNS64, ensures > > that everything will work, so the CLAT must be considered as an > > advantage against user configuration errors. The cost of it is that > > all the traffic will use a double translation (NAT46 at the CLAT and > > NAT64 at the operator network), unless there is support for EAMT > > (Section 4.9). > > > > An exception to that is the case when there is a CLAT at the CE, > > which is not able to obtain the correct configuration parameters > > (again, un-matching WKP or NSP). > > > > However, it needs to be reinforced, that if there is not a CLAT > > (scenarios without 464XLAT), an external DNS without DNS64 support, > > will disallow any access to IPv4-only destination networks, and will > > not guarantee DNSSEC, so will behave as in the Section 3.2.1. > > > > The causes of "foreign DNS" could be classified in three main > > categories, as depicted in the following sub-sections. > > > > 4.4.1. Manual Configuration of Foreign DNS > > > > It is becoming increasingly common that end-users or even devices or > > applications configure alternative DNS in their Operating Systems, > > and some times in CEs. > > > > 4.4.2. DNS Privacy > > > > A new trend is for clients or applications to use mechanisms for DNS > > privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS > > ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC > > ([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH > > and DoQ. > > > > Those DNS privacy/encryption options, currently are typically > > provided by the applications, not the Operating System vendors. At > > the time of writing this document, at least DoT and DoH standards > > have declared DNS64 (and consequently NAT64) out of their scope, so > > an application using them may break NAT64, unless a correctly > > configured CLAT is used. > > > > 4.4.3. Split DNS > > > > When networks or hosts use "split-DNS" (also called Split Horizon) or > > private DNS,the successful use of the DNS64 is not guaranteed. > > Section 4. of [RFC6950], analyses this case. > > > > A similar situation may happen in case of VPNs that force all the DNS > > queries thru the VPN, ignoring the DNS64. > > > > Then, section 5 paragraph becomes: > > > > The only 100% safe solution, which also resolves all the issues, will > > be, in addition to having a CLAT, not using a DNS64 but instead > > making sure that the hosts have a built-in address synthesis feature. > > Operators could manage to use the CLAT, however the built-in address > > synthesis feature is out of their control. If the synthesis is > > provided either by the Operating System (via its DNS resolver API) or > > by the application (via its own DNS resolver), in such way that the > > prefix used for the NAT64 is reachable for the host, the problem goes > > away. > > > > > > Note than when rewriting the text, I realized that even if the DoT/DoH provider is able to provide a DNS64 function, this needs to "know" what is the operator NAT64, or an alternative one, so the "operational" problem really goes away. So, I've slightly modified your previous text suggestions, trying to address that. > > > > Thanks again and happy to hear your inputs on this new text. > > > > El 16/4/19 22:27, "v6ops en nombre de JORDI PALET MARTINEZ" escribió: > > > > Hi Dan, > > > > Thanks again, below some responses. > > > > El 16/4/19 21:24, "Dan Wing" escribió: > > > > On Apr 16, 2019, at 9:16 AM, JORDI PALET MARTINEZ wrote: > > > Hi Dan, > > > > > > Thanks a lot for the inputs. > > > > > > El 16/4/19 18:05, "v6ops en nombre de Dan Wing" escribió: > > > > > > Fred Baker wrote: > > > > > >> For the record, the question here is two-fold. First, is it correct and complete? Is there more, or less, that should be said? Second, are there operators -ISPs, IxPs, enterprise, or whatever, that consider this useful in their deployments? > > > > > > I find the document useful. > > > > > > > > > There are two things I noticed with this one sentence in Section 5, > > > > > > "however the built-in address synthesis feature is out of their control, and can only be resolved by operating system vendors." > > > > > > which should mention (1) DoT and DoH and (2) centralized un-encrypted DNS, detailed below. > > > > > > I will update/reword the sentence. There is an explicit section (4.5. DNS Privacy) covering that. > > > > > > Thanks for the pointer. That existing text in 4.5 makes an unstated assumption that the DNS-over-encrypted-channel server is not doing DNS64. I would make that clearer. Note there are ideas floating around, such as draft-reddy-dprive-bootstrap-dns-server, which have the local network provide the DNS-over-encrypted-channel function, where DNS64 could be provided. I don't think draft-reddy-dprive-bootstrap-dns-server is ready to be cited yet, but I would tighten up the wording of Section 4.5 to make clear the problem is the DoH/DoT/DoQ operator is not also doing the necessary DNS64 function. If they are, the operational problem goes away (right?). > > > > Thanks, I will also re-read draft-reddy-dprive-bootstrap-dns-server and update the text. > > > > > > > 1. DoT and DoH are provided by the application, not provided by OS vendors (at least, not yet) - but that text implies only the OS vendor can change how DNS works on the host. DoT and DoH demonstrate otherwise. The above text should at least mention that DoT and DoH standards have declared DNS64 (and thus NAT64) out of their scope but explain that an application doing DoT/DoH will break with NAT64, and should discuss the operational difficulties of DoT and DoH on a network with NAT64 and DNS64. > > > > > > Exactly, we had that discussion when I was working in the initial versions of this document and the DoH work was on-going as well. > > > > > > Ok. I suggest changing that sentence in Section 5 something like this, > > > > OLD: > > can only be resolved by operating system vendors > > NEW: > > can be synthesized by the OS vendor (via its DNS resolver API) or the application (via its own own DNS resolver). > > > > I think is perfect, thanks again! > > > > > > > 2. The document should also mention using a non-network provided DNS (e.g., 8.8.8.8) won't provide the necessary/expected DNS64. Most hosts do not support changing DNS settings on a per-network basis, either, so using a specific DNS like 8.8.8.8 when on WiFi and using the network-provided DNS64 when on a NAT64 network is usually not possible -- a further operational difficulty placed on the user. > > > > > > This is covered in Section 4.4. Manual Configuration of Foreign DNS. I will double check that I'm not missing it in the summary. > > > > > > Thanks for the pointer. I'm confused that both section 4.4 and section 4.5 are about manual configuration of a foreign DNS -- 4.4 is un-encrypted, 4.5 is encrypted. > > > > Another good point. The explanation is simple. I did 4.4 in earlier versions and then created 4.5. It clearly makes sense to have a single section (4.4) and a sub-section for each one, so definitively will work on this tomorrow and try to publish how it will look like in the list to seek further comments. > > > > -d > > > > > > > -d > > > > > > _______________________________________________ > > > 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. > > > > > > > > > > > > > > > > > > > > > ********************************************** > > 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 > > > > > > > > > > ********************************************** > > 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. > > > > --------------A8E134D00DF4B5C869F3EF68 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Jordi,

Just a few suggestions:

12.  ANNEX C: Benchmarking

   Several documents provide references to benchmarking, for example in
   the case of DNS64, [DNS64-Benchm].

-->

12.  ANNEX C: Benchmarking

   [RFC8219] has defined a benchmarking methodology for IPv6 transition
   technologies. NAT64 and 464XLAT is addressed among the single
   translation and double translation technologies, respectively. DNS64
   is addressed its Section 9, and the methodology is more elaborated in
   [DNS64-BM-Meth].

   Several documents provide references to benchmarking results, for example in
   the case of DNS64, [DNS64-Benchm].


16.2.  Informative References

[...]

   [DNS64-Benchm]
              "Benchmarking DNS64 Implementations: Theory and Practice",
              Computer Communications (Elsevier), vol. 127, no. 1,
              pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September
              2018.

-->

   [DNS64-Benchm]
              Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice",
              Computer Communications, vol. 127, no. 1,
              pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September
              2018.


   [DNS64-BM-Meth]
              Lencse, G., Georgescu, M. and Y. Kadobayashi, "Benchmarking
              Methodology for DNS64 Servers", Computer Communications,
              vol. 109, no. 1, pp. 162-175, September 1, 2017,
              DOI: 10.1016/j.comcom.2017.06.004



   [Threat-DNS64]
              "Methodology for the identification of potential security
              issues of different IPv6 transition technologies: Threat
              analysis of DNS64 and stateful NAT64", Computers &
              Security (Elsevier), vol. 77, no. 1, pp. 397-411,
              DOI 10.1016/j.cose.2018.04.012, August 2018.

-->

   [Threat-DNS64]
              Lencse, G. and Y. Kadobayashi, "Methodology for the identification of potential security
              issues of different IPv6 transition technologies: Threat
              analysis of DNS64 and stateful NAT64", Computers &
              Security, vol. 77, no. 1, pp. 397-411,
              DOI 10.1016/j.cose.2018.04.012, August 2018.



Best regards,

Gábor

On 4/17/2019 22:04, JORDI PALET MARTINEZ wrote:
Hi Gabor,

The changes are only those that have been reflected in emails in the list, anyway, I will make a txt version and email directly to you.

Saludos,
Jordi
 
 

El 17/4/19 14:41, "v6ops en nombre de Gábor Lencse" <v6ops-bounces@ietf.org en nombre de lencse@hit.bme.hu> escribió:

    Hi Jordi,
    
    Could you send the "-05" version, so that I can continue on reading the 
    most up to date text form Section 4?
    
    Perhaps it is worth sending it on the list, if possible.
    
    Thanks.
    
    Gábor
    
    
    On 4/17/2019 20:50, JORDI PALET MARTINEZ wrote:
    > Hi Dan,
    >
    > I've reworded the complete section for "foreign DNS", as follows:
    >
    > 4.4.  Foreign DNS
    >
    >     When clients, in a service provider network, use DNS servers from
    >     other networks, they may support or not DNS64, so the considerations
    >     in Section 4.3 will apply as well.
    >
    >     This may be the case either if individual applications use their own
    >     DNS server, the Operating System itself or even the CE, or
    >     combinations of all the above.
    >
    >     Even in the case that the external DNS supports the DNS64 function, we
    >     may be in the situation of providing incorrect configurations
    >     parameters, for example un-matching WKP or NSP, or a case such the
    >     one described in Section 3.2.3.
    >
    >     Having a CLAT, even if using an external DNS without DNS64, ensures
    >     that everything will work, so the CLAT must be considered as an
    >     advantage against user configuration errors.  The cost of it is that
    >     all the traffic will use a double translation (NAT46 at the CLAT and
    >     NAT64 at the operator network), unless there is support for EAMT
    >     (Section 4.9).
    >
    >     An exception to that is the case when there is a CLAT at the CE,
    >     which is not able to obtain the correct configuration parameters
    >     (again, un-matching WKP or NSP).
    >
    >     However, it needs to be reinforced, that if there is not a CLAT
    >     (scenarios without 464XLAT), an external DNS without DNS64 support,
    >     will disallow any access to IPv4-only destination networks, and will
    >     not guarantee DNSSEC, so will behave as in the Section 3.2.1.
    >
    >     The causes of "foreign DNS" could be classified in three main
    >     categories, as depicted in the following sub-sections.
    >
    > 4.4.1.  Manual Configuration of Foreign DNS
    >
    >     It is becoming increasingly common that end-users or even devices or
    >     applications configure alternative DNS in their Operating Systems,
    >     and some times in CEs.
    >
    > 4.4.2.  DNS Privacy
    >
    >     A new trend is for clients or applications to use mechanisms for DNS
    >     privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS
    >     ([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC
    >     ([I-D.huitema-quic-dnsoquic]).  Those are commonly cited as DoT, DoH
    >     and DoQ.
    >
    >     Those DNS privacy/encryption options, currently are typically
    >     provided by the applications, not the Operating System vendors.  At
    >     the time of writing this document, at least DoT and DoH standards
    >     have declared DNS64 (and consequently NAT64) out of their scope, so
    >     an application using them may break NAT64, unless a correctly
    >     configured CLAT is used.
    >
    > 4.4.3.  Split DNS
    >
    >     When networks or hosts use "split-DNS" (also called Split Horizon) or
    >     private DNS,the successful use of the DNS64 is not guaranteed.
    >     Section 4. of [RFC6950], analyses this case.
    >
    >     A similar situation may happen in case of VPNs that force all the DNS
    >     queries thru the VPN, ignoring the DNS64.
    >   
    > Then, section 5 paragraph becomes:
    >
    >     The only 100% safe solution, which also resolves all the issues, will
    >     be, in addition to having a CLAT, not using a DNS64 but instead
    >     making sure that the hosts have a built-in address synthesis feature.
    >     Operators could manage to use the CLAT, however the built-in address
    >     synthesis feature is out of their control.  If the synthesis is
    >     provided either by the Operating System (via its DNS resolver API) or
    >     by the application (via its own DNS resolver), in such way that the
    >     prefix used for the NAT64 is reachable for the host, the problem goes
    >     away.
    >
    >
    > Note than when rewriting the text, I realized that even if the DoT/DoH provider is able to provide a DNS64 function, this needs to "know" what is the operator NAT64, or an alternative one, so the "operational" problem really goes away. So, I've slightly modified your previous text suggestions, trying to address that.
    >
    > Thanks again and happy to hear your inputs on this new text.
    >
    > El 16/4/19 22:27, "v6ops en nombre de JORDI PALET MARTINEZ" <v6ops-bounces@ietf.org en nombre de jordi.palet=40consulintel.es@dmarc.ietf.org> escribió:
    >
    >      Hi Dan,
    >      
    >      Thanks again, below some responses.
    >      
    >      El 16/4/19 21:24, "Dan Wing" <danwing@gmail.com> escribió:
    >      
    >          On Apr 16, 2019, at 9:16 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
    >          > Hi Dan,
    >          >
    >          > Thanks a lot for the inputs.
    >          >
    >          > El 16/4/19 18:05, "v6ops en nombre de Dan Wing" <v6ops-bounces@ietf.org en nombre de danwing@gmail.com> escribió:
    >          >
    >          >    Fred Baker <fredbaker.ietf@gmail.com> wrote:
    >          >
    >          >> For the record, the question here is two-fold. First, is it correct and complete? Is there more, or less, that should be said? Second, are there operators -ISPs, IxPs, enterprise, or whatever, that consider this useful in their deployments?
    >          >
    >          >    I find the document useful.
    >          >
    >          >
    >          >    There are two things I noticed with this one sentence in Section 5,
    >          >
    >          >      "however the built-in address synthesis feature is out of their control, and can only be resolved by operating system vendors."
    >          >
    >          >    which should mention (1) DoT and DoH and (2) centralized un-encrypted DNS, detailed below.
    >          >
    >          > I will update/reword the sentence. There is an explicit section (4.5.  DNS Privacy) covering that.
    >          
    >          
    >          Thanks for the pointer.  That existing text in 4.5 makes an unstated assumption that the DNS-over-encrypted-channel server is not doing DNS64.  I would make that clearer.  Note there are ideas floating around, such as draft-reddy-dprive-bootstrap-dns-server, which have the local network provide the DNS-over-encrypted-channel function, where DNS64 could be provided.  I don't think draft-reddy-dprive-bootstrap-dns-server is ready to be cited yet, but I would tighten up the wording of Section 4.5 to make clear the problem is the DoH/DoT/DoQ operator is not also doing the necessary DNS64 function.  If they are, the operational problem goes away (right?).
    >      
    >      Thanks, I will also re-read draft-reddy-dprive-bootstrap-dns-server and update the text.
    >          
    >          
    >          >    1. DoT and DoH are provided by the application, not provided by OS vendors (at least, not yet) - but that text implies only the OS vendor can change how DNS works on the host.  DoT and DoH demonstrate otherwise.  The above text should at least mention that DoT and DoH standards have declared DNS64 (and thus NAT64) out of their scope but explain that an application doing DoT/DoH will break with NAT64, and should discuss the operational difficulties of DoT and DoH on a network with NAT64 and DNS64.
    >          >
    >          > Exactly, we had that discussion when I was working in the initial versions of this document and the DoH work was on-going as well.
    >          
    >          
    >          Ok.  I suggest changing that sentence in Section 5 something like this,
    >          
    >          OLD:
    >            can only be resolved by operating system vendors
    >          NEW:
    >            can be synthesized by the OS vendor (via its DNS resolver API) or the application (via its own own DNS resolver).
    >      
    >      I think is perfect, thanks again!
    >          
    >          
    >          >    2. The document should also mention using a non-network provided DNS (e.g., 8.8.8.8) won't provide the necessary/expected DNS64.  Most hosts do not support changing DNS settings on a per-network basis, either, so using a specific DNS like 8.8.8.8 when on WiFi and using the network-provided DNS64 when on a NAT64 network is usually not possible -- a further operational difficulty placed on the user.
    >          >
    >          > This is covered in Section 4.4.  Manual Configuration of Foreign DNS. I will double check that I'm not missing it in the summary.
    >          
    >          
    >          Thanks for the pointer.  I'm confused that both section 4.4 and section 4.5 are about manual configuration of a foreign DNS -- 4.4 is un-encrypted, 4.5 is encrypted.
    >      
    >      Another good point. The explanation is simple. I did 4.4 in earlier versions and then created 4.5. It clearly makes sense to have a single section (4.4) and a sub-section for each one, so definitively will work on this tomorrow and try to publish how it will look like in the list to seek further comments.
    >          
    >          -d
    >          
    >          
    >          >    -d
    >          >
    >          >    _______________________________________________
    >          >    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.
    >          >
    >          >
    >          >
    >          
    >          
    >      
    >      
    >      
    >      **********************************************
    >      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
    >      
    >
    >
    >
    > **********************************************
    > 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.
--------------A8E134D00DF4B5C869F3EF68-- From nobody Thu Apr 18 05:21:08 2019 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 77E1F1202FF for ; Thu, 18 Apr 2019 05:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 T3125xM-o-6U for ; Thu, 18 Apr 2019 05:21:04 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 3752912030A for ; Thu, 18 Apr 2019 05:21:04 -0700 (PDT) Received: from [192.168.11.4] (pl22370.ag1212.nttpc.ne.jp [1.33.49.98]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id x3ICKoir044182 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 18 Apr 2019 14:20:58 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host pl22370.ag1212.nttpc.ne.jp [1.33.49.98] claimed to be [192.168.11.4] To: JORDI PALET MARTINEZ References: <11DA6245-76CB-4DBD-B0EB-11ADA7BA00AE@consulintel.es> <62D9F3DE-2712-48D8-BFAA-8DF67C925190@gmail.com> <36E5648E-102C-480F-AEFA-EB502F366A4C@consulintel.es> Cc: v6ops@ietf.org From: =?UTF-8?Q?G=c3=a1bor_Lencse?= Message-ID: Date: Thu, 18 Apr 2019 21:20:53 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <36E5648E-102C-480F-AEFA-EB502F366A4C@consulintel.es> Content-Type: multipart/alternative; boundary="------------824B03C41234F0C2F66A07F0" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.101.2 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=1.33.49.98; helo=[192.168.11.4]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 18 Apr 2019 12:21:06 -0000 This is a multi-part message in MIME format. --------------824B03C41234F0C2F66A07F0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Jordi, On 4/16/2019 23:57, JORDI PALET MARTINEZ wrote: > I’m confused about one of your inputs, see below. > [...] > Page 8.: > > Furthermore, as indicated in [RFC6877 ] (464XLAT),_can be used_ in >    broadband IPv6 network architectures, by implementing the CLAT >    functionality at the CE. > > I do not understand WHAT can be used. Perhaps you meant: > >    Furthermore, as indicated in [RFC6877 ],*464XLAT can be used* in >    broadband IPv6 network architectures, by implementing the CLAT >    functionality at the CE. > > This is the same text as what I’ve: > >    Furthermore, as indicated in [RFC6877], 464XLAT can be used in > >    broadband IPv6 network architectures, by implementing the CLAT > >    functionality at the CE. > Yes, you are completely right! In fact, I accidentally started reading the "-00" version, and when I noticed that, I revised my notes and deleted some others, which were already corrected in the "-04" version, but I somehow did not notice this one. Gábor --------------824B03C41234F0C2F66A07F0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, Jordi,

On 4/16/2019 23:57, JORDI PALET MARTINEZ wrote:

I’m confused about one of your inputs, see below.

 

[...]


Page 8.:

   Furthermore, as indicated in [RFC6877] (464XLAT), can be used in
   broadband IPv6 network architectures, by implementing the CLAT
   functionality at the CE.

I do not understand WHAT can be used. Perhaps you meant:

   Furthermore, as indicated in [RFC6877], 464XLAT can be used in
   broadband IPv6 network architectures, by implementing the CLAT
   functionality at the CE.

 

This is the same text as what I’ve:

   Furthermore, as indicated in [RFC6877], 464XLAT can be used in

   broadband IPv6 network architectures, by implementing the CLAT

   functionality at the CE.

Yes, you are completely right!

In fact, I accidentally started reading the "-00" version, and when I noticed that, I revised my notes and deleted some others, which were already corrected in the "-04" version, but I somehow did not notice this one.

Gábor


--------------824B03C41234F0C2F66A07F0-- From nobody Thu Apr 18 05:22:28 2019 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 0FDF7120052 for ; Thu, 18 Apr 2019 05:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 3LiLF4W6H7ip for ; Thu, 18 Apr 2019 05:22:25 -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 0760A1202FF for ; Thu, 18 Apr 2019 05:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555590141; x=1556194941; 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=CE56rHZSABj64Otcv9uTpTAo47MqWBm1Xf 4Fg6q8jXs=; b=H0Lws5t708F+M+opET6/NrOhXiv3aY9vRsFQJxqgQaeSLNJ/T0 3xA1b6+EBu406yx5bIOE+6QSOOo0D01hnyKcoEaD0SaLRq+PTmQ1NArnlj4aUMYm nmUDgtOb1k/f2UT7zGBCk5FhlPBPItZWswppyZde7xzb4gKa6xFDc7aPU= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 18 Apr 2019 14:22:21 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 18 Apr 2019 14:22:20 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006222932.msg for ; Thu, 18 Apr 2019 14:22:20 +0200 X-MDRemoteIP: 2001:470:1f09:495:6949:ce4a:8242:5d4b X-MDHelo: [10.10.10.139] X-MDArrival-Date: Thu, 18 Apr 2019 14:22:20 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1011068430=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.9.190412 Date: Thu, 18 Apr 2019 14:22:16 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <4AD6856F-6188-47D8-AD77-99ED44C0A253@consulintel.es> Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 References: <11DA6245-76CB-4DBD-B0EB-11ADA7BA00AE@consulintel.es> <62D9F3DE-2712-48D8-BFAA-8DF67C925190@gmail.com> <36E5648E-102C-480F-AEFA-EB502F366A4C@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3638442136_315482190" Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 18 Apr 2019 12:22:27 -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_3638442136_315482190 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Perfect, thanks a lot! Regards, Jordi =20 =20 =20 El 18/4/19 14:21, "G=C3=A1bor Lencse" escribi=C3=B3: =20 Hi, Jordi, On 4/16/2019 23:57, JORDI PALET MARTINEZ wrote: =20 I=E2=80=99m confused about one of your inputs, see below. =20 [...] Page 8.: Furthermore, as indicated in [RFC6877] (464XLAT), can be used in broadband IPv6 network architectures, by implementing the CLAT functionality at the CE. I do not understand WHAT can be used. Perhaps you meant: Furthermore, as indicated in [RFC6877], 464XLAT can be used in broadband IPv6 network architectures, by implementing the CLAT functionality at the CE. =20 This is the same text as what I=E2=80=99ve: Furthermore, as indicated in [RFC6877], 464XLAT can be used in broadband IPv6 network architectures, by implementing the CLAT functionality at the CE. Yes, you are completely right! In fact, I accidentally started reading the "-00" version, and when I notic= ed that, I revised my notes and deleted some others, which were already cor= rected in the "-04" version, but I somehow did not notice this one. G=C3=A1bor ********************************************** 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_3638442136_315482190 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Perfect, thanks a lot!

=


Regards,

Jordi

 

 

&= nbsp;

El 18/4/19 14:21, "G=C3=A1bor Lencse" <lencse@hit.bme.hu> escribi=C3=B3:

&n= bsp;

Hi, Jordi,

On 4/16/2019 23:57= , JORDI PALET MARTINEZ wrote:

 

I=E2=80=99m confused about one of your inputs, see below.

 

[...]<= o:p>



Page 8.:

&n=
bsp;  Furthermore, as indicated in [RFC6877] (464XLAT), can be used in
   broadband IPv=
6 network architectures, by implementing the CLAT
   functionality at the CE.<=
/pre>

I do not= understand WHAT can be used. Perhaps you meant:

<= pre style=3D'margin-left:106.2pt'>   Furthermore, as indicated in= [RFC6877], 46= 4XLAT can be used in
   broadband IPv6 network architectures, by implementing the CLA=
T
   functiona=
lity at the CE.

 

This is the sam= e text as what I=E2=80=99ve:

&nbs= p;  Furthermore, as indicated in [RFC6877], 464XLAT can be used in

   broadband IPv6 network = architectures, by implementing the CLAT

   functionality at the CE.

Yes, you are completely right!

In fact, I accidentally started = reading the "-00" version, and when I noticed that, I revised my = notes and deleted some others, which were already corrected in the "-0= 4" version, but I somehow did not notice this one.

G=C3=A1bor




***************= *******************************
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_3638442136_315482190-- From nobody Thu Apr 18 13:10:40 2019 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 0A5561203D2 for ; Thu, 18 Apr 2019 13:10:38 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 cNFLWSjK56Ss for ; Thu, 18 Apr 2019 13:10:33 -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 83220120403 for ; Thu, 18 Apr 2019 13:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555618230; x=1556223030; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=X5JG9+mklqys/kJl+w7bAD thuVMnI60TL09nBncd4YU=; b=SYbTzFQcAy113RXb10idMDOZ+yVm6GBf9mBAD8 0Q5QNzVB8pbVJi6JjZ1FH+SoeWBXC0fzC917JfXAZ3nEVAM8KpxQu/5KZ8X4JlxQ 0mU3SmR5T82UcOZUi/86abOMum2oJwDZmzwPLGwnc3ujS1WVUNJoDIOVWTzPsk0T e5AA0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 18 Apr 2019 22:10:30 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 18 Apr 2019 22:10:28 +0200 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006223208.msg for ; Thu, 18 Apr 2019 22:10:27 +0200 X-MDRemoteIP: 2001:470:1f09:495:887d:f39:786f:c8d2 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Thu, 18 Apr 2019 22:10:27 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1011068430=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.9.190412 Date: Thu, 18 Apr 2019 22:10:23 +0200 From: JORDI PALET MARTINEZ To: =?UTF-8?B?R8OhYm9y?= Lencse CC: Message-ID: <48C7DC59-AAA7-4F6E-9111-BD9EA8D77350@consulintel.es> Thread-Topic: Minor additions/corrections -- Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 References: <1BDB7B2B-BF96-4515-AA66-FA21B53FB5E7@consulintel.es> <0eb9d30f-7b77-7f01-3d80-6801f58386aa@hit.bme.hu> <8ef2c5e3-88cd-5524-40e9-3631f4b75a5a@hit.bme.hu> In-Reply-To: <8ef2c5e3-88cd-5524-40e9-3631f4b75a5a@hit.bme.hu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3638470223_832740961" Archived-At: Subject: Re: [v6ops] Minor additions/corrections -- Re: WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 18 Apr 2019 20:10:39 -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_3638470223_832740961 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Gabor, =20 Resolved, thanks! Regads, Jordi =20 =20 =20 El 18/4/19 14:07, "G=C3=A1bor Lencse" escribi=C3=B3: =20 Hi Jordi, Just a few suggestions: 12.=C2=A0 ANNEX C: Benchmarking =C2=A0=C2=A0 Several documents provide references to benchmarking, for exam= ple in =C2=A0=C2=A0 the case of DNS64, [DNS64-Benchm]. --> 12.=C2=A0 ANNEX C: Benchmarking =C2=A0=C2=A0 [RFC8219] has defined a benchmarking methodology for IPv6 tran= sition=20 technologies. NAT64 and 464XLAT is addressed among the single=20 translation and double translation technologies, respectively. DNS64=20 is addressed its Section 9, and the methodology is more elaborated in=20 [DNS64-BM-Meth]. Several documents provide references to benchmarking results, for exampl= e in =C2=A0=C2=A0 the case of DNS64, [DNS64-Benchm]. =20 16.2.=C2=A0 Informative References [...] =20 =C2=A0=C2=A0 [DNS64-Benchm] =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 "Benchmarking DNS64 Implementations: Theory and Practice", =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 Computer Communications (Elsevier), vol. 127, no. 1, =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 pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September =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=A02018.=20 --> =C2=A0=C2=A0 [DNS64-Benchm] =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 Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 Implementations: The= ory and Practice", =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 Computer Communications, vol. 127, no. 1, =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 pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September =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 2018. =20 [DNS64-BM-Meth] Lencse, G., Georgescu, M. and Y. Kadobayashi, "Benchmarking= =20 Methodology for DNS64 Servers", Computer Communications,=20 vol. 109, no. 1, pp. 162-175, September 1, 2017,=20 DOI: 10.1016/j.comcom.2017.06.004=20 =20 =20 =C2=A0=C2=A0 [Threat-DNS64] =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 "Methodology for the identification of potential security =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 issues of different IPv6 transition technologies: Threat =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 analysis of DNS64 and stateful NAT64", Computers & =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 Security (Elsevier), vol. 77, no. 1, pp. 397-411, =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 DOI 10.1016/j.cose.2018.04.012, August 2018. --> =C2=A0=C2=A0 [Threat-DNS64] =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 Lencse, G. and Y. Kadobayashi, "Methodology for the identification of p= otential security =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 issues of different IPv6 transition technologies: Threat =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 analysis of DNS64 and stateful NAT64", Computers & =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 Security, vol. 77, no. 1, pp. 397-411, =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 DOI 10.1016/j.cose.2018.04.012, August 2018. =20 =20 Best regards, =20 G=C3=A1bor =20 On 4/17/2019 22:04, JORDI PALET MARTINEZ wrote: Hi Gabor, =20 The changes are only those that have been reflected in emails in the list, = anyway, I will make a txt version and email directly to you. =20 Saludos, Jordi =20 =C2=A0 =20 =EF=BB=BFEl 17/4/19 14:41, "v6ops en nombre de G=C3=A1bor Lencse" escribi=C3=B3: =20 =C2=A0=C2=A0=C2=A0 Hi Jordi, =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0Could you send the "-05" version, so that I can con= tinue on reading the=20 =C2=A0=C2=A0=C2=A0=C2=A0most up to date text form Section 4? =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0Perhaps it is worth sending it on the list, if poss= ible. =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0Thanks. =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0G=C3=A1bor =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0On 4/17/2019 20:50, JORDI PALET MARTINEZ wrote: =C2=A0=C2=A0=C2=A0 > Hi Dan, =C2=A0=C2=A0=C2=A0 > =C2=A0 =C2=A0=C2=A0> I've reworded the complete section for "foreign DNS", = as follows: =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > 4.4.=C2=A0 Foreign DNS =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 When clients, in a service pro= vider network, use DNS servers from =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 other networks, they may suppo= rt or not DNS64, so the considerations =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 in Section 4.3 will apply as w= ell. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 This may be the case either if= individual applications use their own =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 DNS server, the Operating Syst= em itself or even the CE, or =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 combinations of all the above. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 Even in the case that the exte= rnal DNS supports the DNS64 function, we =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 may be in the situation of pro= viding incorrect configurations =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 parameters, for example un-mat= ching WKP or NSP, or a case such the =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 one described in Section 3.2.3= . =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 Having a CLAT, even if using a= n external DNS without DNS64, ensures =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 that everything will work, so = the CLAT must be considered as an =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 advantage against user configu= ration errors.=C2=A0 The cost of it is that =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 all the traffic will use a dou= ble translation (NAT46 at the CLAT and =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 NAT64 at the operator network)= , unless there is support for EAMT =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 (Section 4.9). =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 An exception to that is the ca= se when there is a CLAT at the CE, =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 which is not able to obtain th= e correct configuration parameters =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 (again, un-matching WKP or NSP= ). =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 However, it needs to be reinfo= rced, that if there is not a CLAT =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 (scenarios without 464XLAT), a= n external DNS without DNS64 support, =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 will disallow any access to IP= v4-only destination networks, and will =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 not guarantee DNSSEC, so will = behave as in the Section 3.2.1. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 The causes of "foreign DNS" co= uld be classified in three main =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 categories, as depicted in the= following sub-sections. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > 4.4.1.=C2=A0 Manual Configuration of Foreign DNS =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 It is becoming increasingly co= mmon that end-users or even devices or =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 applications configure alterna= tive DNS in their Operating Systems, =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 and some times in CEs. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > 4.4.2.=C2=A0 DNS Privacy =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 A new trend is for clients or = applications to use mechanisms for DNS =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 privacy/encryption, such as DN= S over TLS ([RFC7858]), DNS over DTLS =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 ([RFC8094]), DNS queries over = HTTPS ([RFC8484]) or DNS over QUIC =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 ([I-D.huitema-quic-dnsoquic]).= =C2=A0 Those are commonly cited as DoT, DoH =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 and DoQ. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 Those DNS privacy/encryption o= ptions, currently are typically =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 provided by the applications, = not the Operating System vendors.=C2=A0 At =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 the time of writing this docum= ent, at least DoT and DoH standards =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 have declared DNS64 (and conse= quently NAT64) out of their scope, so =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 an application using them may = break NAT64, unless a correctly =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 configured CLAT is used. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > 4.4.3.=C2=A0 Split DNS =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 When networks or hosts use "sp= lit-DNS" (also called Split Horizon) or =C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0 private DNS,the successful use= of the DNS64 is not guaranteed. =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 Section 4. of [RFC6950], analy= ses this case. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 A similar situation may happen= in case of VPNs that force all the DNS =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 queries thru the VPN, ignoring= the DNS64. =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0> Then, section 5 paragraph becomes: =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 The only 100% safe solution, w= hich also resolves all the issues, will =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 be, in addition to having a CL= AT, not using a DNS64 but instead =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 making sure that the hosts hav= e a built-in address synthesis feature. =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 Operators could manage to use = the CLAT, however the built-in address =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 synthesis feature is out of th= eir control.=C2=A0 If the synthesis is =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 provided either by the Operati= ng System (via its DNS resolver API) or =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 by the application (via its ow= n DNS resolver), in such way that the =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 prefix used for the NAT64 is r= eachable for the host, the problem goes =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 away. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > Note than when rewriting the text, I realized that eve= n if the DoT/DoH provider is able to provide a DNS64 function, this needs t= o "know" what is the operator NAT64, or an alternative one, so the "operati= onal" problem really goes away. So, I've slightly modified your previous te= xt suggestions, trying to address that. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > Thanks again and happy to hear your inputs on this new= text. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > =EF=BB=BFEl 16/4/19 22:27, "v6ops en nombre de JORDI P= ALET MARTINEZ" escribi=C3=B3: =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi Dan, =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks again, below= some responses. =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =EF=BB=BFEl 16/4/19= 21:24, "Dan Wing" escribi=C3=B3: =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =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 On Apr 16, 2019, at 9:16 AM, JORDI PALET MARTINEZ wrote: =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > Hi Dan, =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=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > Thanks a lot for the inputs. =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=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > =EF=BB=BFEl 16/4/19 18:05, "v6ops en nombre de Dan Wing" escribi=C3=B3: =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=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=A0 Fred Baker wrote: =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=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >> For the record, the question here is two-fold. First, is it correct and = complete? Is there more, or less, that should be said? Second, are there op= erators -ISPs, IxPs, enterprise, or whatever, that consider this useful in = their deployments? =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=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=A0 I find the document useful. =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=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=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 There are two things I noticed with this one sentence i= n Section 5, =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=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=A0=C2=A0=C2=A0 "however the built-in address synthesis fea= ture is out of their control, and can only be resolved by operating system = vendors." =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=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=A0 which should mention (1) DoT and DoH and (2) centralize= d un-encrypted DNS, detailed below. =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=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > I will update/reword the sentence. There is an explicit section (4.5. =C2= =A0DNS Privacy) covering that. =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =20 =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=20 =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 Thanks for the pointer.=C2=A0 That existing text in 4.5 makes an uns= tated assumption that the DNS-over-encrypted-channel server is not doing DN= S64.=C2=A0 I would make that clearer.=C2=A0 Note there are ideas floating a= round, such as draft-reddy-dprive-bootstrap-dns-server, which have the loca= l network provide the DNS-over-encrypted-channel function, where DNS64 coul= d be provided.=C2=A0 I don't think draft-reddy-dprive-bootstrap-dns-server = is ready to be cited yet, but I would tighten up the wording of Section 4.5= to make clear the problem is the DoH/DoT/DoQ operator is not also doing th= e necessary DNS64 function.=C2=A0 If they are, the operational problem goes= away (right?). =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks, I will also= re-read draft-reddy-dprive-bootstrap-dns-server and update the text. =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =20 =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=20 =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=A0=C2=A0=C2=A0 1. DoT and DoH are provided by the application, = not provided by OS vendors (at least, not yet) - but that text implies only= the OS vendor can change how DNS works on the host.=C2=A0 DoT and DoH demo= nstrate otherwise.=C2=A0 The above text should at least mention that DoT an= d DoH standards have declared DNS64 (and thus NAT64) out of their scope but= explain that an application doing DoT/DoH will break with NAT64, and shoul= d discuss the operational difficulties of DoT and DoH on a network with NAT= 64 and DNS64. =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=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > Exactly, we had that discussion when I was working in the initial version= s of this document and the DoH work was on-going as well. =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =20 =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=20 =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 Ok.=C2=A0 I suggest changing that sentence in Section 5 something li= ke this, =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =20 =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 OLD: =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=A0 can only be resolved by operating system vendors =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = NEW: =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=A0 can be synthesized by the OS vendor (via its DNS resolver API)= or the application (via its own own DNS resolver). =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I think is perfect,= thanks again! =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =20 =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=20 =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=A0=C2=A0=C2=A0 2. The document should also mention using a non-= network provided DNS (e.g., 8.8.8.8) won't provide the necessary/expected D= NS64.=C2=A0 Most hosts do not support changing DNS settings on a per-networ= k basis, either, so using a specific DNS like 8.8.8.8 when on WiFi and usin= g the network-provided DNS64 when on a NAT64 network is usually not possibl= e -- a further operational difficulty placed on the user. =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=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > This is covered in Section 4.4.=C2=A0 Manual Configuration of Foreign DNS= . I will double check that I'm not missing it in the summary. =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =20 =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=20 =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 Thanks for the pointer.=C2=A0 I'm confused that both section 4.4 and= section 4.5 are about manual configuration of a foreign DNS -- 4.4 is un-e= ncrypted, 4.5 is encrypted. =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Another good point.= The explanation is simple. I did 4.4 in earlier versions and then created = 4.5. It clearly makes sense to have a single section (4.4) and a sub-sectio= n for each one, so definitively will work on this tomorrow and try to publi= sh how it will look like in the list to seek further comments. =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =20 =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 -d =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=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=20 =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=A0=C2=A0=C2=A0 -d =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=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=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=A0=C2=A0=C2=A0 v6ops mailing list =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=A0=C2=A0 v6ops@ietf.org =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=A0=C2=A0https://www.ietf.org/mailman/listinfo/v6ops =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=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=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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > IPv4 is over =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > Are you ready for the new Internet ? =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > http://www.theipv6company.com =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > The IPv6 Company =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=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = > This electronic message contains information which may be privileged or c= onfidential. 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 co= nsidered 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 prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. =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=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =20 =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=20 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =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=A0=C2=A0=C2=A0=C2=A0 IPv4 is over =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Are you ready for the ne= w Internet ? =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.theipv6compan= y.com =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The IPv6 Company =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This electronic mes= sage contains information which may be privileged or confidential. The info= rmation is intended to be for the exclusive use of the individual(s) named = above and further non-explicilty authorized disclosure, copying, distributi= on or use of the contents of this information, even if partially, including= attached files, is strictly prohibited and will be considered a criminal o= ffense. 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 consid= ered a criminal offense, so you must reply to the original sender to inform= about this communication and delete it. =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =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=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 v6ops mailing list =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v6ops@ietf.org =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mai= lman/listinfo/v6ops =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 =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=A0=C2=A0=C2=A0 > IPv4 is over =C2=A0=C2=A0=C2=A0 > Are you ready for the new Internet ? =C2=A0=C2=A0=C2=A0 > http://www.theipv6company.com =C2=A0=C2=A0=C2=A0 > The IPv6 Company =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > 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 intended= recipient be aware that any disclosure, copying, distribution or use of th= e contents of this information, even if partially, including attached files= , is strictly prohibited, will be considered a criminal offense, so you mus= t reply to the original sender to inform about this communication and delet= e it. =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=A0=C2=A0 > v6ops mailing list =C2=A0=C2=A0=C2=A0 > v6ops@ietf.org =C2=A0=C2=A0=C2=A0 > https://www.ietf.org/mailman/listinfo/v6ops =C2=A0 =C2=A0=C2=A0> =C2=A0=C2=A0=C2=A0=20 =C2=A0=C2=A0=C2=A0=C2=A0_______________________________________________ =C2=A0=C2=A0=C2=A0 v6ops mailing list =C2=A0=C2=A0=C2=A0 v6ops@ietf.org =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/v6ops =C2=A0=C2=A0=C2=A0=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 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. =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. --B_3638470223_832740961 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Gabor,

 

Resolved, thanks= !


Regads,

Jordi

 

 

 

El 18/4/19 14:07, "G=C3=A1bor L= encse" <lencse@hit.bme.hu&= gt; escribi=C3=B3:

 

Hi Jordi,

Just a few= suggestions:

12.=C2=A0 ANNEX C: Benchmarking

=C2=A0=C2=A0 Several documents provide refere= nces to benchmarking, for example in
=C2=A0=C2=A0 the case of DNS64, [DN= S64-Benchm].

-->

12.=C2=A0 ANNEX C: Benchmarking

=C2=A0=C2=A0 [RFC8219] has defin= ed a benchmarking methodology for IPv6 transition
   technolo= gies. NAT64 and 464XLAT is addressed among the single
   tran= slation and double translation technologies, respectively. DNS64
 =   is addressed its Section 9, and the methodology is more elaborated i= n
   [DNS64-BM-Meth].

   Several documents provide references to benchmarkin= g results, for example in
=C2=A0=C2=A0 the case of DNS64, [DNS64-= Benchm].

 

16.= 2.=C2=A0 Informative References

[...]

 

=C2=A0=C2=A0 [DNS64-Benchm]
= =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 "Benchmarking DNS64 Implementations: Theory and Practice",
=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 Computer Commu= nications (Elsevier), vol. 127, no. 1,
=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 pp. 61-74, DOI 10.10= 16/j.comcom.2018.05.005, September
=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=A02018.

-->

=C2= =A0=C2=A0 [DNS64-Benchm]
=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 Lencse, G. and Y. Kadobayashi, &qu= ot;Benchmarking DNS64 Implementations: Theory and Practice",
=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 Co= mputer Communications, vol. 127, no. 1,
=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 pp. 61-74, DOI 10.1016/j.c= omcom.2018.05.005, September
=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 2018.

 

   [DNS64-BM-Meth]
 =              Le= ncse, G., Georgescu, M. and Y. Kadobayashi, "Benchmarking
            &n= bsp; Methodology for DNS64 Servers", Computer Communications,
&nbs= p;             = vol. 109, no. 1, pp. 162-175, September 1, 2017,
   &nbs= p;          DOI: 10.1016/j.com= com.2017.06.004

 

 

=C2=A0=C2=A0 [Threat-DNS64]=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 "Methodology for the identification of potential security
= =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 issues of different IPv6 transition technologies: Threat
=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 analy= sis of DNS64 and stateful NAT64", Computers &
=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 Security (Elsevier), vol. 77, no. 1, pp. 397-411,
=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 DOI 10.1016/j.cose.2= 018.04.012, August 2018.

-->

=C2=A0=C2=A0 [Threat-DNS64]
=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= Lencse, G. and Y. Kadobayashi, "Methodology for the identifica= tion of potential security
=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 issues of different IPv6 transition techn= ologies: Threat
=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 analysis of DNS64 and stateful NAT64", Comput= ers &
=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 Security, vol. 77, no. 1, pp. 397-411,
=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 DOI 10.1= 016/j.cose.2018.04.012, August 2018.

 

=

 

Best regards,=

 

G=C3=A1bor

 

On 4/17/2019 22:04, JORDI PALET MARTINEZ wrote:

Hi Gabor,
 
T=
he changes are only those that have been reflected in emails in the list, a=
nyway, I will make a txt version and email directly to you.
 
Saludos,
Jordi
 
=

=C2=A0
 
=
=EF=BB=BFEl 17/4/19 14:41, "v6ops en nombre de G=C3=A1bor Lencse"=
 <v=
6ops-bounces@ietf.org en nombre de lencse@hit.bme.hu> escribi=C3=B3:=

 
<=
pre style=3D'margin-left:35.4pt'>=C2=A0=C2=A0=C2=A0 Hi Jordi,
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0Could you send the =
"-05" version, so that I can continue on reading the <=
/pre>
=C2=A0=C2=A0=C2=A0=C2=A0most up to d=
ate text form Section 4?
=
=C2=A0=C2=A0=C2=A0 
=C2=
=A0=C2=A0=C2=A0=C2=A0Perhaps it is worth sending it on the list, if possibl=
e.
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0Tha=
nks.
=C2=A0=C2=A0=C2=A0 <=
o:p>
=C2=A0=C2=A0=C2=A0=C2=A0G=
=C3=A1bor
=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0On 4/17/2019 20:50, JORDI PALE=
T MARTINEZ wrote:
=C2=A0=
=C2=A0=C2=A0 > Hi Dan,
=C2=A0=C2=A0=C2=A0 >
=
=C2=A0 =C2=A0=C2=A0> I've reworded the complete section for "foreig=
n DNS", as follows:
=
=C2=A0=C2=A0=C2=A0 >
=
=C2=A0=C2=A0=C2=A0 > 4.4.=C2=A0 Foreign DNS
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 Whe=
n clients, in a service provider network, use DNS servers from
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 other networks, they may support or not DNS64, so the consider=
ations
=C2=A0=C2=A0=C2=A0=
 >=C2=A0=C2=A0=C2=A0=C2=A0 in Section 4.3 will apply as well.=

=C2=A0=C2=A0=C2=A0 ><=
/pre>
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 This may be the case either if individual applications use the=
ir own
=C2=A0=C2=A0=C2=A0=
 >=C2=A0=C2=A0=C2=A0=C2=A0 DNS server, the Operating System itself or ev=
en the CE, or
=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 combinations of all the above.<=
/o:p>
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 >=C2=A0=
=C2=A0=C2=A0=C2=A0 Even in the case that the external DNS supports the DNS6=
4 function, we
=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 may be in the situation of providing=
 incorrect configurations
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 parameters, for example un=
-matching WKP or NSP, or a case such the
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 one describ=
ed in Section 3.2.3.
=C2=
=A0=C2=A0=C2=A0 >
=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 Having a CLAT, even if using a=
n external DNS without DNS64, ensures
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 that everythin=
g will work, so the CLAT must be considered as an
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 ad=
vantage against user configuration errors.=C2=A0 The cost of it is that
=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 all the traffic will use a double translation (NAT46 =
at the CLAT and
=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 NAT64 at the operator network), unle=
ss there is support for EAMT
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 (Section 4.9).
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=
=A0=C2=A0=C2=A0 An exception to that is the case when there is a CLAT at th=
e CE,
=C2=A0=C2=A0=C2=A0 =
>=C2=A0=C2=A0=C2=A0=C2=A0 which is not able to obtain the correct config=
uration parameters
=C2=A0=
=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 (again, un-matching WKP or NSP).<=
o:p>
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 However, it needs to be reinforced, that if there is =
not a CLAT
=C2=A0=C2=A0=
=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 (scenarios without 464XLAT), an externa=
l DNS without DNS64 support,
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 will disallow any acces=
s to IPv4-only destination networks, and will
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 not gu=
arantee DNSSEC, so will behave as in the Section 3.2.1.
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 The causes of "foreign DNS" could be classified in three main=

=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 categories, =
as depicted in the following sub-sections.
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 > 4.4.1.=C2=A0 Manual Configuration =
of Foreign DNS
=C2=A0=C2=
=A0=C2=A0 >
=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 It is becoming increasingly common t=
hat end-users or even devices or
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 applications config=
ure alternative DNS in their Operating Systems,
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 and=
 some times in CEs.
=C2=
=A0=C2=A0=C2=A0 >
=C2=
=A0=C2=A0=C2=A0 > 4.4.2.=C2=A0 DNS Privacy
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 A new t=
rend is for clients or applications to use mechanisms for DNS
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=
=A0=C2=A0 privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DT=
LS
=C2=A0=C2=A0=C2=A0 >=
;=C2=A0=C2=A0=C2=A0=C2=A0 ([RFC8094]), DNS queries over HTTPS ([RFC8484]) o=
r DNS over QUIC
=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 ([I-D.huitema-quic-dnsoquic]).=C2=A0=
 Those are commonly cited as DoT, DoH
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 and DoQ.<=
/o:p>
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 >=C2=A0=
=C2=A0=C2=A0=C2=A0 Those DNS privacy/encryption options, currently are typi=
cally
=C2=A0=C2=A0=C2=A0 =
>=C2=A0=C2=A0=C2=A0=C2=A0 provided by the applications, not the Operatin=
g System vendors.=C2=A0 At
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 the time of writing this =
document, at least DoT and DoH standards
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 have declar=
ed DNS64 (and consequently NAT64) out of their scope, so
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=
=C2=A0 an application using them may break NAT64, unless a correctly
=C2=A0=C2=A0=C2=A0 >=C2=A0=
=C2=A0=C2=A0=C2=A0 configured CLAT is used.
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 > 4.4.3.=C2=A0 Split DNS=

=C2=A0=C2=A0=C2=A0 ><=
/pre>
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 When networks or hosts use "split-DNS" (also called =
Split Horizon) or
 =C2=A0=
=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0 private DNS,the successful use of =
the DNS64 is not guaranteed.
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 Section 4. of [RFC6950]=
, analyses this case.
=C2=
=A0=C2=A0=C2=A0 >
=C2=
=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 A similar situation may happen=
 in case of VPNs that force all the DNS
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 queries thru=
 the VPN, ignoring the DNS64.
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0> Then, section 5 paragraph bec=
omes:
=C2=A0=C2=A0=C2=A0 =
>
=C2=A0=C2=A0=C2=A0 &=
gt;=C2=A0=C2=A0=C2=A0=C2=A0 The only 100% safe solution, which also resolve=
s all the issues, will
=
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 be, in addition to having a=
 CLAT, not using a DNS64 but instead
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 making sure tha=
t the hosts have a built-in address synthesis feature.
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=
=A0 Operators could manage to use the CLAT, however the built-in address
=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0=C2=A0 synthesis feature is out of their control.=C2=A0 If the synthesis is
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 provided either by th=
e Operating System (via its DNS resolver API) or
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 by =
the application (via its own DNS resolver), in such way that the=

=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0 prefix used for the NAT64 is reachable for the host, the probl=
em goes
=C2=A0=C2=A0=C2=
=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 away.
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 > Note than when rewriting the text, I re=
alized that even if the DoT/DoH provider is able to provide a DNS64 functio=
n, this needs to "know" what is the operator NAT64, or an alterna=
tive one, so the "operational" problem really goes away. So, I've=
 slightly modified your previous text suggestions, trying to address that.<=
o:p>
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 > Th=
anks again and happy to hear your inputs on this new text.
=

=C2=A0=C2=A0=C2=A0 >
<=
pre style=3D'margin-left:35.4pt'>=C2=A0=C2=A0=C2=A0 > =EF=BB=BFEl 16/4/1=
9 22:27, "v6ops en nombre de JORDI PALET MARTINEZ" <v6ops-bounces@ietf.org en nombre de jordi.palet=3D40consulintel=
.es@dmarc.ietf.org> escribi=C3=B3:
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi Da=
n,
=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=A0=C2=A0=C2=A0=C2=A0 Thanks a=
gain, below some responses.
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<= pre style=3D'margin-left:35.4pt'>=C2=A0=C2=A0=C2=A0=C2=A0>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =EF=BB=BFEl 16/4/19 21:24, "Dan Wing" <danwing@gmail.com> escribi=C3=B3:<= o:p>
=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 On Apr 16, 2019, at 9:16 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
=C2=A0=C2=A0=C2=
=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Hi Dan,=

=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=A0=C2=A0 >=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Thanks a lot for the inputs.
=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=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =EF=BB=BFEl 16/4/19 18:05, "=
v6ops en nombre de Dan Wing" <v6ops-bounces@ietf.org en nombre de danwing=
@gmail.com> escribi=C3=B3:
=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=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=A0 Fred Baker =
<fredbaker.ietf@gmail.com> wrote:
=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=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 >> For the record, the question here is two-fold. First, is it=
 correct and complete? Is there more, or less, that should be said? Second,=
 are there operators -ISPs, IxPs, enterprise, or whatever, that consider th=
is useful in their deployments?
=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=
=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=A0 I find the document useful.
=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=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=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 There are two t= hings I noticed with this one sentence in Section 5,
=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=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=A0=C2=A0=C2=A0 "however the built-=
in address synthesis feature is out of their control, and can only be resol=
ved by operating system vendors."
=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=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=A0 which should mention (1) DoT and DoH and (2) cen=
tralized un-encrypted DNS, detailed below.
=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=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 > I will update/reword the sentence. There is an explicit section=
 (4.5. =C2=A0DNS Privacy) covering that.
=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=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=A0=C2=
=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks =
for the pointer.=C2=A0 That existing text in 4.5 makes an unstated assumpti=
on that the DNS-over-encrypted-channel server is not doing DNS64.=C2=A0 I w=
ould make that clearer.=C2=A0 Note there are ideas floating around, such as=
 draft-reddy-dprive-bootstrap-dns-server, which have the local network prov=
ide the DNS-over-encrypted-channel function, where DNS64 could be provided.=
=C2=A0 I don't think draft-reddy-dprive-bootstrap-dns-server is ready to be=
 cited yet, but I would tighten up the wording of Section 4.5 to make clear=
 the problem is the DoH/DoT/DoQ operator is not also doing the necessary DN=
S64 function.=C2=A0 If they are, the operational problem goes away (right?)=
.
=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=A0=C2=A0=C2=A0=C2=A0 Thanks, I=
 will also re-read draft-reddy-dprive-bootstrap-dns-server and update the t=
ext.
=C2=A0=C2=A0=C2=A0 &=
gt;=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=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=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 1. DoT and DoH are provi=
ded by the application, not provided by OS vendors (at least, not yet) - bu=
t that text implies only the OS vendor can change how DNS works on the host=
.=C2=A0 DoT and DoH demonstrate otherwise.=C2=A0 The above text should at l=
east mention that DoT and DoH standards have declared DNS64 (and thus NAT64=
) out of their scope but explain that an application doing DoT/DoH will bre=
ak with NAT64, and should discuss the operational difficulties of DoT and D=
oH on a network with NAT64 and DNS64.
=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=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 > Exactly, we had that discussion when I was working in the initial =
versions of this document and the DoH work was on-going as well.=

=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=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=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Ok.=C2=A0 I suggest changing that sentence in Section 5 someth=
ing like this,
=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/o:p>
=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 OLD:
=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=A0 can only be resolved by=
 operating system vendors
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 NEW:
=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=A0 =
can be synthesized by the OS vendor (via its DNS resolver API) or the application (via its own own DNS resolver).
=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=A0=C2=A0=C2=A0=C2=A0 I think is perfect, thanks a=
gain!
=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=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=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=A0=C2=A0 2. The document should a=
lso mention using a non-network provided DNS (e.g., 8.8.8.8) won't provide =
the necessary/expected DNS64.=C2=A0 Most hosts do not support changing DNS =
settings on a per-network basis, either, so using a specific DNS like 8.8.8=
.8 when on WiFi and using the network-provided DNS64 when on a NAT64 networ=
k is usually not possible -- a further operational difficulty placed on the=
 user.
=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=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > This is covered in Section =
4.4.=C2=A0 Manual Configuration of Foreign DNS. I will double check that I'=
m not missing it in the summary.
=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=
=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
o:p>
=C2=A0=C2=A0=C2=A0=C2=A0&=
gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks for the po=
inter.=C2=A0 I'm confused that both section 4.4 and section 4.5 are about m=
anual configuration of a foreign DNS -- 4.4 is un-encrypted, 4.5 is encrypt=
ed.
=C2=A0=C2=A0=C2=A0 &g=
t;=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=A0 Another=
 good point. The explanation is simple. I did 4.4 in earlier versions and t=
hen created 4.5. It clearly makes sense to have a single section (4.4) and =
a sub-section for each one, so definitively will work on this tomorrow and =
try to publish how it will look like in the list to seek further comments.<=
o:p>
=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=A0=C2=A0=C2=A0>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -d
=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=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=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=A0=C2=A0 -d
=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=A0=C2=A0 &=
gt;=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=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=A0 v6ops mailing list= 
=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=A0=C2=
=A0 v6ops@ietf.org
=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=A0=C2=A0https://www.ietf.org/mailman/listi= nfo/v6ops
=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=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=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=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=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=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > IPv4 is over
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Are you ready for the new Internet ?= 
=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > http://www.theipv6company.com
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > The IPv6 Company
=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=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 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) na=
med above and further non-explicilty authorized disclosure, copying, distri=
bution or use of the contents of this information, even if partially, inclu=
ding attached files, is strictly prohibited and will be considered a crimin=
al offense. If you are not the intended recipient be aware that any disclos=
ure, copying, distribution or use of the contents of this information, even=
 if partially, including attached files, is strictly prohibited, will be co=
nsidered a criminal offense, so you must reply to the original sender to in=
form about this communication and delete it.
=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=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=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=
=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=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=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=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=A0>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 **********************************************<=
o:p>
=C2=A0=C2=A0=C2=A0 >=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IPv4 is over
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ar=
e you ready for the new Internet ?
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.theipv6company.com=

=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 The IPv6 Company
=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=A0=C2=A0=C2=A0=C2=A0 This electronic message contains information which=
 may be privileged or confidential. The information is intended to be for t=
he exclusive use of the individual(s) named above and further non-explicilt=
y authorized disclosure, copying, distribution or use of the contents of th=
is information, even if partially, including attached files, is strictly pr=
ohibited and will be considered a criminal offense. If you are not the inte=
nded recipient be aware that any disclosure, copying, distribution or use o=
f the contents of this information, even if partially, including attached f=
iles, is strictly prohibited, will be considered a criminal offense, so you=
 must reply to the original sender to inform about this communication and d=
elete it.
=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=A0=C2=A0=C2=A0=C2=A0 <=
o:p>
=C2=A0=C2=A0=C2=A0=C2=A0&=
gt;=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=A0 ______=
_________________________________________
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v6op=
s mailing list
=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v6ops@ietf.org
=
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/v6=
ops
=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=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 > **********************************=
************
=C2=A0=C2=A0=
=C2=A0 > IPv4 is over
=
=C2=A0=C2=A0=C2=A0 > Are you ready for the new Internet ?
=C2=A0=C2=A0=C2=A0 > http://www.theipv6company.com
=C2=A0=C2=A0=C2=A0 > The IPv6 Company=

=C2=A0=C2=A0=C2=A0 ><=
/pre>
=C2=A0=C2=A0=C2=A0 > This electro=
nic message contains information which may be privileged or confidential. T=
he information is intended to be for the exclusive use of the individual(s)=
 named above and further non-explicilty authorized disclosure, copying, dis=
tribution or use of the contents of this information, even if partially, in=
cluding attached files, is strictly prohibited and will be considered a cri=
minal offense. If you are not the intended recipient be aware that any disc=
losure, copying, distribution or use of the contents of this information, e=
ven 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.
=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=A0=C2=A0 > v6ops mailing list
=C2=A0=C2=A0=C2=A0 > v6=
ops@ietf.org
=C2=A0=
=C2=A0=C2=A0 > h=
ttps://www.ietf.org/mailman/listinfo/v6ops
=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 v6ops mailing list
=C2=A0=C2=A0=C2=A0 v6ops@ietf.org=

=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mai=
lman/listinfo/v6ops
=
=C2=A0=C2=A0=C2=A0 
=
 
 
=

 
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
 
This electro=
nic message contains information which may be privileged or confidential. T=
he information is intended to be for the exclusive use of the individual(s)=
 named above and further non-explicilty authorized disclosure, copying, dis=
tribution or use of the contents of this information, even if partially, in=
cluding attached files, is strictly prohibited and will be considered a cri=
minal offense. If you are not the intended recipient be aware that any disc=
losure, copying, distribution or use of the contents of this information, e=
ven 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.
 
 
 <=
/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_3638470223_832740961-- From nobody Thu Apr 18 17:11:36 2019 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 34F3512021C; Thu, 18 Apr 2019 17:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 efng6Day8sqJ; Thu, 18 Apr 2019 17:11:33 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 A83D51200F6; Thu, 18 Apr 2019 17:11:33 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id y3so1891511pgk.12; Thu, 18 Apr 2019 17:11:33 -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=aYQB/+9p9BMcBWVi4/OEg5DRR4/L0GCYMf8VXImZEdU=; b=GdaodNseOnKKmbyK3dzwTSU37VJpW5EYxEuKwRBuuYasAjA3+fijVg64uyn+o8aYlW J/f/CPQdkglBG3Bn8X4u13zqZ1VQklG1xoXrd3HzNO6UhTSOmSpmiiV3YpnWONfULbKU OCDJQ25JExHS4lWL9ZFm4pax8hVhv/2ngZlur3PP9xraJs6yN0uHlGmAZB3Qye3ECPdv S57ucr/8zkH2JZ1c8JuUqP3dipjysz6Ta4PmqvyPWGZPiA95vXrQ1/oSjB2Wkj52Hdj4 Bo0sjhq74qI6dCeBjxEg0C5D7NvxSjuMxTUEvQy74LpwKOTLJ8yAqy3dcsZjugo5UH6a D0Hg== 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=aYQB/+9p9BMcBWVi4/OEg5DRR4/L0GCYMf8VXImZEdU=; b=pF7MuORjRC9hJZH99A2Hhg3btskjVeDCsauQnYUMpteZ0sJZd+cyUyuzq7MO6tltVa Ui4XXagL/F37/bEWq0QZ1yd6U00BlbBITUtNsyWPIZJ/RXHNzeQcxwgvPmZbPqP990RA NeAQFiM7ScvnsrKwKP7RfIy/l1+/8py+y+Oqh73/6Pl9sT8LSOdpyUpju0B+avfGXp54 X5UUK5v5fWVnbLd3zr5yfQVCJAmxxaWsUYKZOomCMhj6Qzi3WLkZPOu7lkJct79fvHpF +rxVEbsbIxxCVWhIcdh0HBjV4khcijrDNQtkJywDt1QPVLKfP7aHVbhWp5+O7zs5bQcG kdyA== X-Gm-Message-State: APjAAAUGc8CKurEeTwv4YXNCtzfj5/3i4+A04e919/mk40zDFSAxJwto hkIKq3DAOzYV7qgx8JTsXp/ssjUU X-Google-Smtp-Source: APXvYqyYxLWUBSdDPJ5n2aMIRMgGnZKT/toy+tQcVZkNTxTZwoyyaI1cU+GGbpevRYX1MHQ2vvHe9Q== X-Received: by 2002:a62:1795:: with SMTP id 143mr610099pfx.104.1555632692927; Thu, 18 Apr 2019 17:11:32 -0700 (PDT) Received: from sjcldanwi.citrite.net ([162.221.154.11]) by smtp.gmail.com with ESMTPSA id h3sm4824620pgl.3.2019.04.18.17.11.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Apr 2019 17:11:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Dan Wing In-Reply-To: <1BDB7B2B-BF96-4515-AA66-FA21B53FB5E7@consulintel.es> Date: Thu, 18 Apr 2019 17:11:31 -0700 Cc: v6ops@ietf.org, draft-ietf-v6ops-nat64-deployment@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <26C054EE-4247-4C7F-AE2D-969D22988F3F@gmail.com> References: <1BDB7B2B-BF96-4515-AA66-FA21B53FB5E7@consulintel.es> To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 19 Apr 2019 00:11:35 -0000 On Apr 17, 2019, at 4:50 AM, JORDI PALET MARTINEZ = wrote: >=20 > Hi Dan, >=20 > I've reworded the complete section for "foreign DNS", as follows: >=20 > 4.4. Foreign DNS ... > Thanks again and happy to hear your inputs on this new text. Exactly the sort of re-structuring that I was thinking -- but I did not = explain well. Thank you! The new section 5 paragraph is great, too, = because it explains the end-goal for the client endpoint to do the DNS64 = synthesis -- which is also the only way for the client endpoint to = validate DNSSEC. Thanks again, -d From nobody Fri Apr 19 15:19:59 2019 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 550CB120098; Fri, 19 Apr 2019 15:19:57 -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.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <155571239725.5471.10489752675372337280@ietfa.amsl.com> Date: Fri, 19 Apr 2019 15:19:57 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-05.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: Fri, 19 Apr 2019 22:19:57 -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 : Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-nat64-deployment-05.txt Pages : 42 Date : 2019-04-19 Abstract: This document describes how NAT64 (including 464XLAT) can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise, and possible optimizations. The document also discusses issues to be considered when having IPv6-only connectivity, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nat64-deployment-05 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-deployment-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-deployment-05 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 Fri Apr 19 15:21:44 2019 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 043961200D7; Fri, 19 Apr 2019 15:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 JXdvZldiy5kM; Fri, 19 Apr 2019 15:21:40 -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 C531A12016C; Fri, 19 Apr 2019 15:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1555712496; x=1556317296; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=8YRWFXj3Wtn3en8WGCe7vYLtLwfF4H4yEl1F5I7u2Og=; b=HZMqtOP03Igw6 iZ4k8NltKfWFelFj3dng30UsR57fSd29ur8QhyKTcbyiu+m5N7TbG0xKew+nF4L+ ldnMN1B43c2Do4I9UefWtZh8NH+ULK2ZhctxRAvNtBKCH9GOiXxa76hdkHRQxRc0 pZM5BP9PLZvtPfICF1B9KN3KxKoJ3E= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 20 Apr 2019 00:21:36 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 20 Apr 2019 00:21:35 +0200 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006224105.msg; Sat, 20 Apr 2019 00:21:34 +0200 X-MDRemoteIP: 2001:470:1f09:495:f169:f22d:99a6:ca0d X-MDHelo: [10.10.10.130] X-MDArrival-Date: Sat, 20 Apr 2019 00:21:34 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1012b54ed4=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.9.190412 Date: Sat, 20 Apr 2019 00:21:30 +0200 From: JORDI PALET MARTINEZ To: Mikael Abrahamsson , Ron Bonica CC: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" Message-ID: <10274EB5-E7BD-4063-8C79-44AB1D652D9F@consulintel.es> Thread-Topic: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 References: <203DF4C2-3BC0-4521-B28F-0B56E2BF2690@consulintel.es> In-Reply-To: <203DF4C2-3BC0-4521-B28F-0B56E2BF2690@consulintel.es> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 19 Apr 2019 22:21:43 -0000 Hi Mikael, all, Sorry, it took much more work (and time) than expected. I just finished doing all the edits, including the several inputs in the li= st (including your own ones), some received in private, and the ones from M= ed, which provided also a very detailed review. In some cases, I've clarifi= ed directly with some folks some of the inputs. https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/?include= _text=3D1 I've reinforced that this document is not a "selling tool" for NAT64/464XLA= T, but a tool to understand implications and relevant documents and a guide= line for those that already took the decision and how to approach specific = details. Once more, thanks a lot to all! Some questions: 1) I'm using NAT64 and DNS64 when referring to the "protocols", but using N= AT64 function/DNS64 function when talking about how it is/can be deployed a= t the operator. I tried to make sure to use them consistently across the do= cument and that they are easier to differentiate across the document. I thi= nk it helps, but happy to hear about this. 2) Section 5, "summary", I reworded it already (as well as some other rewor= dings across the documents considering all the inputs), but as said in the = previous email (below), I'm still not sure to call it summary or something = else. The idea is not just to be a summary, but also "flow guide" for someb= ody to follow when already decided to use NAT64. Thinking loud, I still thi= nk it is a summary, but just in case there is any other idea from the WG. 3) In the intro I had already a reference to RFC7269, which is a 2014 docum= ent providing other NAT64 deployment options and experience. Discussing wit= h Med, he suggested to modify a bit the title of this one, so I added "Addi= tional" in front of the previous title, because both documents work togethe= r as complementary. I'm wondering if it makes sense to "update" RFC7269 fro= m this document, I don't think there anything actually updated, but in the = sense that it will be convenient for a reader to actually read both of them= , so somehow "linking" them "bidirectionally" makes a lot of sense because = the complementarity. 4) Considering the number of inputs, the new version from that, that I was = slower to react to those edits, and that part of the WGLC happened in a hol= iday season, I understand that some folks may be available to read this ver= sion and provide additional inputs. So, I will like to suggest to the chair= s, I think Mikael, already mention that, to extend it for a few more days. Any other inputs? Regards, Jordi =20 =20 =EF=BB=BFEl 17/4/19 15:38, "v6ops en nombre de JORDI PALET MARTINEZ" escribi=C3=B3: Hi Mikael, =20 Thanks for the review ... responding in-line. =20 =EF=BB=BFEl 17/4/19 14:57, "v6ops en nombre de Mikael Abrahamsson" escribi=C3=B3: =20 On Mon, 8 Apr 2019, Ron Bonica wrote: =20 > Folks, > > This email initiates a Working Group Last call on draft-ietf-v6op= s-nat64-deployment-04. WGLC will end at COB, April 22, 2019. =20 I have been asked to be document shepherd of this document. The bel= ow text=20 is not written with document shepherd hat on, but from me as a regu= lar WG=20 participant. =20 ------------------- =20 While reading through the document, I encountered some nits: =20 In parts of the document it's called "a NAT64" and in other parts i= t's=20 called "NAT64 function". I'd like to see this done the same through= out. So=20 for instance in 3.1.1 there is: =20 "... he DNS64 function, and the NAT64 function is provided ..." =20 "... service provider offers the NAT64 only, and the DNS64 function= ..." =20 So in the last paragraph, say "... the NAT64 function only ..." ? O= r=20 remove the "function" from several places? I would just like to see= this=20 used the same way throughout. =20 I think it will be more clear to use "function" all the way thru (expec= t if there is a specific reason for not doing so - now just thinking loud),= but I'm going to review all the document and make sure about one or the ot= her way and make it uniform for the v05. =20 =20 3.3 a. =20 Replace with: "DNSSEC: Are there hosts validating DNSSEC?" =20 Done! =20 =20 " As a general conclusion, we should note that if the network mus= t support applications using literals, non-IPv6-compliant APIs, o= r IPv4-only hosts or applications, only the scenarios with 464XLA= T, or equivalent built-in local address synthesis features, will prov= ide a solution. " =20 Please make this a bullet list or something, that sentence is hard = to=20 read. Also, perhaps add that it's "IPv4 literals" (if that's the ca= se)? =20 Done! =20 4. =20 This entire section has sentences that are hard to read because the= y're=20 long and contain a lot of commas. =20 "So, such clients, if DNS64 is enabled, will never get A records, even for IPv4-only servers, and they = may be in the path before the NAT64 and accessible by IPv4." =20 " When clients, in a service provider network, use DNS servers fr= om other networks, for example manually configured by users, they = may support or not DNS64, so the considerations in Section 4.3 will= apply as well." =20 This is not wrong per se, but it makes the sentences quite hard to = read. =20 Will work on this tonight. =20 4.1.1 =20 For DHCPv6 options, shouldn't RFC 7051 be mentioned here? =20 Will re-read and do. =20 4.6. =20 " As already indicated in precedent sections, the successful use = of the DNS64 is not guaranteed when networks or hosts can use "split-D= NS" (also called Split Horizon), private DNS. Section 4. of [RFC69= 50], analyses this case. This a very common situation when using VP= Ns." =20 I don't understand the sentence that ends with ", private DNS". Are= there=20 some missing words here? Should it be ", also called private DNS" o= r=20 something? =20 =20 This has been already reworded (see the previous email). I will clarify= anyway, if is still not sufficient. =20 =20 "" a. The WKP MUST NOT be used to represent non-global IPv4 addre= sses. If this is required, because the network to be translated u= se non-global addresses then an NSP is required." =20 "the network to be translated", can we have some other phrase here?= This=20 sentence is hard for me to parse. Perhaps: =20 "" a. The WKP MUST NOT be used to represent non-global IPv4 addre= sses. If this is required because the addresses to be translated = use non-global addresses, then an NSP is required." =20 " b. The WKP MAY appear in inter-domain routing tables, if the operator provides NAT64 to peers, however special considera= tions related to BGP filtering are then required and IPv4-embedde= d IPv6 prefixes longer than the WKP MUST NOT be advertised in BGP.= An NSP may be a more appropriate option in those cases." =20 replace with: =20 " b. The WKP MAY appear in inter-domain routing tables. If the operator provides NAT64 to peers, special considerations related to BGP filtering are then required and IPv4-embedde= d IPv6 prefixes longer than the WKP MUST NOT be advertised (or acc= epted) in BGP. An NSP may be a more appropriate option in those c= ases." =20 Yeah both rewordings look fine. =20 4.8. =20 " Those alternatives will solve the problem for and end-hosts, ho= wever, if that end-hosts is providing "tethering" or an equivalent ser= vice to others hosts, that need to be considered as well. In other = words, in a case of a cellular network, it resolves the issue for the = UE itself, but may be not the case for hosts behind it." =20 what are "those alternatives"? =20 Will reword. =20 "problem for and end-hosts" ? Can you please take a look at this en= tire=20 paragraph because I can't parse it. =20 Will reword. =20 4.10. =20 typo: " an instead a single" =20 Done! =20 "So, in this case, the UEs typically have a build-in CLAT client, which is d= oing a stateful NAT44 before the stateless NAT46." =20 replace: =20 "So, in this case, the UEs typically have a build-in CLAT client which is pe= rforming a stateful NAT44 translation before the stateless NAT46." =20 =20 Done! =20 5. =20 " It can be argued that none of the possible transition mechanism= s is perfect, and somehow, we may consider that actually this is a g= ood thing as a way to push for the IPv6 deployment, or otherwise, i= t may be further delayed, with clear undesirable effects for the glob= al Internet." =20 Can you please check this section some more? =20 Will do! =20 " In an ideal world will, we could safely use DNS64, if the approa= ch proposed in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed, avoiding the cases where DNSSEC may be broken." =20 Typo? =20 Done! =20 10.1. =20 As a summary, I think this document needs a serious once-over in th= e=20 aspect that the sentences are long and contains lots of commas (the= above=20 examples are only a few examples). =20 I will review all the doc again to try to avoid all the long sentences.= I tend to do that, and I know "how to read them" but I understand is not e= asy to read for everyone from scratch. =20 Also, Jordi, I know you like this deployment strategy but it shines= =20 through in the document, especially in section 5 which isn't really= a=20 summary but almost a marketing piece (especially in the beginning).= Can=20 you look over the document (especially section 5) and keep to the f= acts=20 and do a bit less of "selling" of this specific deployment scenario= ? =20 I was tempted several times to change the title of this section. I will= review it and check how to better approach this change. Maybe we don't nee= d a summary, or clearly state "if you decide to use NAT64 or 464XLAT, this = is the decision flow chart" (or something in this line). =20 =20 Thanks a lot! =20 Regards, Jordi =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =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= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, 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 awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal 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 ********************************************** 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 Mon Apr 22 12:54:12 2019 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 2A057120362; Mon, 22 Apr 2019 12:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 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, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 sfouUofjP-NQ; Mon, 22 Apr 2019 12:54:10 -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 06A2C120267; Mon, 22 Apr 2019 12:54:09 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3MJi73J006355; Mon, 22 Apr 2019 12:54:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=IKs6Jq6oycFeVdUdYXJDFR332mP3ZZ8e+M6ihtys3MQ=; b=ZwlMs1uoepBZTwmB587aE//c53IwnTDQjJ/fK9orE/kE/h2/dxCsgzvVjs2QTGhYaZtu rVi7cHbggxhYpmUKnxql2kOKIY5jP48weB2cz2joznPvd6eSyllQ84gV3f1vmX5LxdVF a1SBEkqMqUaBiDqv7w2mWDbnSloCY9S1YpO6aintcnuPt4b9rPE06BCGtZ6S3rVeB/z8 YWc5PxIkR4VcRqWuXWbdv/6O2gK9UgI9m0K+++QNRscpVXwYbd5SbrALf5yhR5AjNOTP Q+4ad7QEcMcaQ5DlByM+jFEr8X9wTSPZVIPvOiiUGYhVLr0gvr/in19n9XolSAdac0Qa ug== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp2052.outbound.protection.outlook.com [104.47.41.52]) by mx0a-00273201.pphosted.com with ESMTP id 2s1cr5grtg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 22 Apr 2019 12:54:09 -0700 Received: from BN7PR05MB4243.namprd05.prod.outlook.com (52.133.222.152) by BN7PR05MB5937.namprd05.prod.outlook.com (20.176.31.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.8; Mon, 22 Apr 2019 19:54:06 +0000 Received: from BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::8906:7b1e:6bd0:28f2]) by BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::8906:7b1e:6bd0:28f2%7]) with mapi id 15.20.1813.011; Mon, 22 Apr 2019 19:54:06 +0000 From: Ron Bonica To: "v6ops@ietf.org" , "draft-ietf-v6ops-nat64-deployment@ietf.org" Thread-Topic: WGLC: draft-ietf-v6ops-nat64-deployment-04 Thread-Index: AdTuFevwhUrweEmoS22jgEJvFmhhxwLLs80w Date: Mon, 22 Apr 2019 19:54:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action 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=2019-04-08T14:20:03.1405839Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c5b15b2-61f2-4d8f-1012-08d6c75c471e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BN7PR05MB5937; x-ms-traffictypediagnostic: BN7PR05MB5937: x-microsoft-antispam-prvs: x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(136003)(396003)(346002)(13464003)(189003)(199004)(446003)(256004)(14454004)(66446008)(11346002)(86362001)(25786009)(6246003)(3846002)(6116002)(486006)(2501003)(316002)(74316002)(5660300002)(53936002)(4744005)(99286004)(66556008)(476003)(66476007)(68736007)(64756008)(76176011)(73956011)(2906002)(7696005)(186003)(110136005)(26005)(53546011)(6506007)(76116006)(66946007)(450100002)(102836004)(71190400001)(81166006)(33656002)(8936002)(66066001)(81156014)(9686003)(8676002)(55016002)(478600001)(305945005)(52536014)(97736004)(7736002)(6436002)(71200400001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB5937; H:BN7PR05MB4243.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PBRFSskBnZBCyGtZ0gx5YjhHuC95RZQku3xlrdOVq+1g9Vsr5hYvlemqU3CGllr8qk1u8um72p3Yo1mhubsVgXFY8C1nJEjH36at6amgxV28tcqnebHJbO5x3hRL3ZqC6CcQl03vEGexLJhA1d05d19k6DCJZCZSFC5+xTDX6jN5gAuNEAR1X/0Dtk1kZA8lVZ4IZWkIzmFAnOa0A9vhIPoRbPTEIbvOkWTpfWxyqVqXuiYSdacHEgGraay4M+M6NR8gPkFTg1JE0CXsItQB2DeCLnlcQCSWWPhn5yANu2+lL7e4RedEqSgemKCQ/BUprmtU0OF5X/sQTQFi5WaGoX9uAO0+S96K8OQrP4j+bxFTz+Hr1w3OXb+vbEHL3jy4la5lmcvikcph61C+54MCYTMqMsfyNonvGIB1jHujIH0= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 5c5b15b2-61f2-4d8f-1012-08d6c75c471e X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2019 19:54:06.2625 (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-Transport-CrossTenantHeadersStamped: BN7PR05MB5937 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-22_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=622 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904220149 Archived-At: Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04 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, 22 Apr 2019 19:54:11 -0000 Folks, This ends WG Last Call on draft-ietf-v6ops-nat64-deployment-04. Mikael, Would you provide the shepherd's write-up. = Ron Juniper Internal > -----Original Message----- > From: Ron Bonica > Sent: Monday, April 8, 2019 10:20 AM > To: v6ops@ietf.org; draft-ietf-v6ops-nat64-deployment@ietf.org > Subject: WGLC: draft-ietf-v6ops-nat64-deployment-04 >=20 > Folks, >=20 > This email initiates a Working Group Last call on draft-ietf-v6ops-nat64- > deployment-04. WGLC will end at COB, April 22, 2019. >=20 > Authors, >=20 > Please respond to this message indicating whether you are aware of any IP= R > regarding this draft. >=20 > Ron >=20 >=20 > Juniper Internal From nobody Mon Apr 22 12:56:29 2019 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 D5FD0120382; Mon, 22 Apr 2019 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 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, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 mM6cgHP83r0U; Mon, 22 Apr 2019 12:56:26 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 55B9312037D; Mon, 22 Apr 2019 12:56:23 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3MJu4Ao023159; Mon, 22 Apr 2019 12:56:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=83XwUWslfhBXx9CwMD3nYelNcRCbo/xt1NumXnrMEN8=; b=mBgcQIL/h2ymwBCpFqc3DroYiaZVI8crptiXJypnMUELl1ieFLi82TlIhxs2fHg3N5kT r0yQfSr2Cmsmw54VdS9qQnMV5iqMkz1/ilsvuMNgQ7GFg9etIuaqwnT5N7N+/JY+jBIF WfJlsthyecvATeqhmtPg1dIlQJEivXi0kFNvTtBjsYwIrPVOr/ZW7r2aL+sZ6uJoNQeU DTAjBac6gPcsKVcuRZ1MYFprOC1UAPizdXFXAYNpmVDsB1/eLVHEf9rRI2Db+lPbhKQl 5t8SkcANi3Vsv0AgE+TF7EOdPQMh3JJ3Rb/IR/+afs/OE+hWhJmCZaP6VnW+ipqpeUjK sg== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2051.outbound.protection.outlook.com [104.47.36.51]) by mx0b-00273201.pphosted.com with ESMTP id 2s178bs62v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 22 Apr 2019 12:56:21 -0700 Received: from BN7PR05MB4243.namprd05.prod.outlook.com (52.133.222.152) by BN7PR05MB4098.namprd05.prod.outlook.com (52.132.219.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.9; Mon, 22 Apr 2019 19:56:18 +0000 Received: from BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::8906:7b1e:6bd0:28f2]) by BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::8906:7b1e:6bd0:28f2%7]) with mapi id 15.20.1813.011; Mon, 22 Apr 2019 19:56:18 +0000 From: Ron Bonica To: "v6ops@ietf.org" , "draft-palet-v6ops-464xlat-opt-cdn-caches@ietf.org" Thread-Topic: draft-palet-v6ops-464xlat-opt-cdn-caches Thread-Index: AdT5RVBW+rVbn5unTl20xloarF3lSA== Content-Class: Date: Mon, 22 Apr 2019 19:56:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action 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=2019-04-22T19:56:16.9773086Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ece49ff5-801e-4605-8c85-08d6c75c9603 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BN7PR05MB4098; x-ms-traffictypediagnostic: BN7PR05MB4098: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(396003)(346002)(366004)(199004)(189003)(33656002)(8676002)(102836004)(186003)(26005)(6506007)(52536014)(256004)(66066001)(99286004)(558084003)(3846002)(2501003)(73956011)(71200400001)(66476007)(25786009)(66556008)(64756008)(66946007)(71190400001)(66446008)(97736004)(6116002)(76116006)(8936002)(53936002)(14454004)(450100002)(5660300002)(81166006)(81156014)(6436002)(110136005)(316002)(2906002)(7736002)(7696005)(9686003)(486006)(86362001)(55016002)(476003)(68736007)(478600001)(305945005)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4098; H:BN7PR05MB4243.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +x3JU9rC0RiQDL3FVA7SeTRqhDwKlIHfrdtVgCmGoaCjC9DhIOOO+FKrb3sLW8BsOJA7cvFBg9p/eV8fHCZNZqNjsHe6eXCHJ6jTweEOjTTufMj19tE8nkUWHdtt8zXpgzc02e97zGhqw1zcAJMrmjD9ygo0+EVChFw67xCNsvMiw587GoD5sQieJmt8b4Ki9vB7vmMNk6d4iWklfX///DOPMX/oGkM9VXPKqHmED82Aziid4bvLpefRBDWM5uBwR5JrM+PfZHvyKJfL9LYZT8r7xsAGdeXzGy278Wc/DFulxO6/9HKs5eb69L3v8SluXKny6TXa3XJkx3XcVORJc9AAJzlU0cnRjXzR4ckaC0Sndq8h4PIGgDx2i++a+b0BUf/EYSvOEZwI8vytywAi0geOm2vf2EfCk1clCKWArOM= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: ece49ff5-801e-4605-8c85-08d6c75c9603 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2019 19:56:18.6278 (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-Transport-CrossTenantHeadersStamped: BN7PR05MB4098 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-22_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=329 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904220150 Archived-At: Subject: [v6ops] draft-palet-v6ops-464xlat-opt-cdn-caches 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, 22 Apr 2019 19:56:28 -0000 Folks, Each week between now and IETF 105, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-palet-v6ops-464xlat-opt-cdn-c= aches. Fred and Ron Juniper Internal From nobody Thu Apr 25 12:12:55 2019 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 6798712025B; Thu, 25 Apr 2019 12:12:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155621957335.14976.16794070183255829570.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2019 12:12:53 -0700 Archived-At: Subject: [v6ops] v6ops - New Meeting Session Request for IETF 105 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: Thu, 25 Apr 2019 19:12:54 -0000 A new meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: 6man intarea tsvwg suit rtgwg opsec grow People who must be present: Fred Baker Ron Bonica Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Apr 29 10:32:55 2019 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 25B171205EB for ; Mon, 29 Apr 2019 10:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 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, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 BPZ7dXQDCmHQ for ; Mon, 29 Apr 2019 10:32:51 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 C03711204AE for ; Mon, 29 Apr 2019 10:32:51 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3THPC9C027266 for ; Mon, 29 Apr 2019 10:32:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=SHQ1aMYTkuRX0IOOpYdE6zKNWruVFfPcUJBhH3Kiq6Y=; b=qY9NDiBhHNPEltPTPlPk47T7XtowbOy54mYTcU5VeTdmml3WC/wqp6YTUrAH29HMPBPR ToVcX6AFfsyxTfjTNl0JwGFo7qZmQh1X8MLDH6PKKoYLYAd4UdCEgF4vmvyC2uqbbH4J +yO5b5rP6o246n6wMVp9/FSizuXQ4KBB0YUOejYOjfehpPwRPb9p5yWE1Kt+5tZ/qyEM fO6guHgm5GfliixBrgMq//AqgBUZ289ppBGCGQ8u1fJLcYzTo3OfBZdhQjqkcV5veBkv Bym31ssSpAYxfKoYRume7dMpUL6BJaXe/EAzhZzBkvmeUnu+iBVJeHFYt1R6J2wPU6QN bA== Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp2055.outbound.protection.outlook.com [104.47.49.55]) by mx0b-00273201.pphosted.com with ESMTP id 2s5xkh0nf5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 29 Apr 2019 10:32:48 -0700 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB4390.namprd05.prod.outlook.com (52.135.202.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.9; Mon, 29 Apr 2019 17:32:47 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::e1e7:cf02:f236:ab29]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::e1e7:cf02:f236:ab29%7]) with mapi id 15.20.1856.008; Mon, 29 Apr 2019 17:32:47 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-lmhp-v6ops-transition-comparison Thread-Index: AdT+sYl14V39O6d3SHm5TvaWZM7WXw== Content-Class: Date: Mon, 29 Apr 2019 17:32:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action msip_labels: MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Enabled=True; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Owner=rbonica@juniper.net; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_SetDate=2019-04-29T17:32:05.0684592Z; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Name=Non-Juniper; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Application=Microsoft Azure Information Protection; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Extended_MSFT_Method=Manual; Sensitivity=Non-Juniper x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d02618fb-6f26-4dbe-88a8-08d6ccc8b21d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB4390; x-ms-traffictypediagnostic: BYAPR05MB4390: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(39860400002)(396003)(346002)(366004)(199004)(189003)(53936002)(316002)(66066001)(558084003)(68736007)(256004)(8676002)(4743002)(7736002)(9686003)(305945005)(74316002)(8936002)(86362001)(81156014)(81166006)(71190400001)(71200400001)(5660300002)(66946007)(64756008)(66446008)(476003)(76116006)(2351001)(73956011)(7696005)(33656002)(99286004)(55016002)(6116002)(3846002)(5640700003)(26005)(6506007)(6436002)(102836004)(25786009)(66556008)(66476007)(97736004)(2501003)(6916009)(14454004)(478600001)(52536014)(186003)(486006)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4390; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CMJGr/0H7+GZEnBQkGwm7b572Be0gs+80AsW8oT6csZ/6hSUtVaIAMfJPt7qlebKdKsNV0gkBt08pwj737eDUwmA7QSkn6Pok1TN0yiug7VAJ2C4grwM1XY3iASzA5rsfSCWSN67HX8UF+UsNqbPb87USOI50LNR6aOf1U0f4H3PkFbsQVQP67eg3HcmVj80qobZIdBu2DfLKETAX1zqsR8He1zWBSzFKrbTvP0I2detpPXsjJIy6/V1h1Q3tFmUlqjHIPV5g9MH0MYx8wZnPdCXtyep3sZ0FwJtvXWD1dAltmRAOYR7Nq4dmeaIPSPpL9Am8XdVphg3U1TLYYX63GbvYB38XvxlL306VCJZFNImkm4mz9UQzzCGiVfoP5nl9t73jDXPn2Rsu5z1YhiXD5yffDHxxP0vGYZY4cijvcA= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: d02618fb-6f26-4dbe-88a8-08d6ccc8b21d X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 17:32:47.1910 (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-Transport-CrossTenantHeadersStamped: BYAPR05MB4390 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-29_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=562 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904290119 Archived-At: Subject: [v6ops] draft-lmhp-v6ops-transition-comparison 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, 29 Apr 2019 17:32:53 -0000 Folks, Each week between now and IETF 105, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-lmhp-v6ops-transition-compari= son. Fred and Ron Non-Juniper From nobody Mon Apr 29 19:03:38 2019 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 EA12D1207C8 for ; Mon, 29 Apr 2019 19:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 z4MJJejYnglz for ; Mon, 29 Apr 2019 19:03:35 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 3979612013A for ; Mon, 29 Apr 2019 19:03:35 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id w25so6250676pfi.9 for ; Mon, 29 Apr 2019 19:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=n8M9ai0/hko1jImk1qdU0DViGBpJ/kezyNBkn5PdYbs=; b=QB4UfRtvq7NYONld5C6gBHl/qXEr2JSeHkx+YXzm7JDihQpVEGufXYKE4KZEZC9hDy zmuDChSMn5QbK4mvk94aeUlxwxjuuh4Az7BrNTXHH+4Kr2yo2nLAFWawek0+yd1vBXK/ fmcDF5Fx9FAiLflaO8mwEUpZh0OOk5ZRvG7Y4vQVC3XnRHfo7Ah7l5hRqFZohHCmDVTL ztjM5Eme7dEtVExD1odjMA4pnPQ3FPgEg312V7ttEBX2mRucL0FYJ9w6IqKYrdAlsaln ePlbL3rc4oCxv+WW0GGkGNtWq7GDdnlgh0br3ja0CTfptJFyRWGuWnHe7LgtW3iZK/ri bZtg== 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:date:references:to :in-reply-to:message-id; bh=n8M9ai0/hko1jImk1qdU0DViGBpJ/kezyNBkn5PdYbs=; b=dF9zT/RyFeHmUX788NHSNlN2cy88uXnKossu5Uc65jvi1NtEnBslUZqxYMjCr20tu7 yjzEegHrcMrLrN9k4PRWj7dV8nFUNl+wi6oKOLbAS94QWP7HWV78uGZOuKji+bUqCyb8 sB3ypOjFNLmRkGTsenC32xdd/nfOx+GkmZ4jj8o6Ob/5trXaja9GHFIXuU8+TUe7pMxK 9kHLo1351X9v6PXte8dcNzA9BVQmS3KDS4orWLms8zNSHGZoR3igTZPJWCbAoLBZG2SL kexdX8spka/rdPw+12pJZjTiudCCte4ob3jgvnR7MRy2CM690f7FmO9K4SIA47v2AUr9 STdw== X-Gm-Message-State: APjAAAV/gOCE5UmYifK/d9/h81pJ1rW7rN6USDpGnlZN3dFYsonR6FJ/ Bq4cIJahJTU/yEcue9EyXoIFCMb5 X-Google-Smtp-Source: APXvYqypRsX5/eAKIMBZ3taiSqPkk6l8oOQNYXfJY5RylLQIQlfGWtfLG8oDS6Mdrl5W7y5AaAbFGg== X-Received: by 2002:a65:5009:: with SMTP id f9mr62755232pgo.390.1556589814648; Mon, 29 Apr 2019 19:03:34 -0700 (PDT) Received: from ?IPv6:2600:8801:d004:600:f026:9fcf:6237:4279? ([2600:8801:d004:600:f026:9fcf:6237:4279]) by smtp.gmail.com with ESMTPSA id f5sm39079788pgo.75.2019.04.29.19.03.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 19:03:33 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_E4DE670F-4B1E-4B97-A0B2-3D96141188CB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 29 Apr 2019 19:03:31 -0700 References: To: "v6ops@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [v6ops] draft-lmhp-v6ops-transition-comparison 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, 30 Apr 2019 02:03:37 -0000 --Apple-Mail=_E4DE670F-4B1E-4B97-A0B2-3D96141188CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At least part of the question is that the authors would like this to be = a working group draft. I'm interested to know what the working group = thinks of it. It started out as an essentially academic paper, and would = update or obsolete RFC 6180. > On Apr 29, 2019, at 10:32 AM, Ron Bonica = wrote: >=20 > Folks, >=20 > Each week between now and IETF 105, we will review and discuss one = draft with an eye towards progressing it. >=20 > This week, please review and comment on = draft-lmhp-v6ops-transition-comparison. >=20 > Fred and = Ron >=20 > Non-Juniper >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_E4DE670F-4B1E-4B97-A0B2-3D96141188CB 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+AFAlzHrPMACgkQEhdRnd2G P+ACAw//f0yacLgjA/L+xznh+KskKoLpQ7VSBy/dy3ckzBaS2Kbxedaje0+D5Cah rL8VzQyCBDEtZDPkH33hkR7aGiusbYKv3BfB5QGfzmtG7TMwieO/CAekuVM9fDzy UU8qOrnzLfhiuUMrXNXM9lDioGEr+qhEsuMh9sXaaM8jKD7nmEbCgx/dlIeGnN/+ WHIeOmKsMRU8PePNykFZqddgmT/BZL3Mw0fdgr1/jBRZz3CwXMMDwbOmrCvt5n3C Lc9QcOt/f0g9wV+5WNyIIlgAR8ZVtk6YhN9JhV9GyFQrWWSCS1w1ES23fBanIusL 54gaqbCAWy90ofE8oKw599v6sDtQj+oiU7T86x+KEyhfM8pC9bIhVJYdPuRnBoXl c/B/1UoAS+p/QcS1Z2Z+97vwwYbzn6FD/RGVwt8X6MHD0JQqM04qiSkejISLS65+ MjGwpBKhuIiWH/ysiyY1gP5RTYvJxrO5Ist3+mKhPYt7p0iGqBlYlnDEdjF0F+Xm Dlh3gdNsJKRXGAm7XeiJhUVdnvf4z3DLt+1s9brAifkfidyjOM99W9ONSZB15DyA TQxO4hy58a5zsDLtvJF4xeHzBwue+wfweHhjmbf+eOScV0E2ZUlA00hDYa8N4tSk RZRbFttNquiETXyTmaqfrYOb3NmnxyfWY6eX9MuvsTZ3dV/+2sM= =auRL -----END PGP SIGNATURE----- --Apple-Mail=_E4DE670F-4B1E-4B97-A0B2-3D96141188CB--