Re: [v6ops] Opsdir early review of draft-ietf-v6ops-v4v6-xlat-prefix-00
Fred Baker <fredbaker.ietf@gmail.com> Tue, 02 May 2017 15:04 UTC
Return-Path: <fredbaker.ietf@gmail.com>
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 D8AB0129483; Tue, 2 May 2017 08:04:20 -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 QkN7nOtP5dvh; Tue, 2 May 2017 08:04:19 -0700 (PDT)
Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 6212C129C48; Tue, 2 May 2017 08:00:34 -0700 (PDT)
Received: by mail-wr0-x244.google.com with SMTP id w50so18018341wrc.0; Tue, 02 May 2017 08:00:34 -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=2wmV8QaEM0maQQlHLupXU4ebkY8R0aEYVYkyBINHq50=; b=UIF6XQnFgEDXCIDEAt81zYZOcDvPAUK031rA2K0aR4KcSLa/O1qVim25aa0U6mBXgC 5EHriJOsJBABc2vA9cbkx4L0rIthOzuTQ65yDeK40mklbfU+Ul4smYndH5jiaLy0tpb0 Mei/agJavBPWaLuSfK/kXQYUTkUPa2nBED+X+8PrMgfq39xJgdEvjPgC8CwPrX4fuCCH txWWaHc6NniZkR44z5W+67runHF5l5Q9JDvI81Sr483faeziB+apDyGLF9uah2X+Cd3p vV0IzuPlQi59sVXDfaTbrttNggMXWeQGdIjhNSKCM8cFPwIqp2uLzapXXxUnbm0hi6XP z5oQ==
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=2wmV8QaEM0maQQlHLupXU4ebkY8R0aEYVYkyBINHq50=; b=o3jDeq/10snfU77Z6YMmXsi8G7YXJvRhmeFLkamFZcm3r9eIsKHTN7XghqW69htPy4 Jc3nkjZ1ApbmigNN3tM5UJg6GMn3+MTKL/+l25ruHhGiI86iSrd5DM7cjQrr5C7kasc2 WL6ApB6nuO+1/d6BmbFXMltHMaGrS5IV0yf+WXP3WIbHhf6XCwt+jsBPFNvOnP4Tipbx YGTYsRxrbbqW+fZr7KENWnc/8uqmB1KPNnmeK8g3sBxjTMDaiIhMVBPX+/0ZDcNjoAgZ wzzULp8sqjNOahDGWzKsCOF3415+QPmg37ZW92FQJak43c6qygEaohUFgIYJfStLiZ2Z 7Osg==
X-Gm-Message-State: AN3rC/47i6ip+I3BklqeDYKZwC1AAo7pzHbYWtNESuhIyMb5y0NTckKI mfmUFbNvAbs/br7kYlE=
X-Received: by 10.223.170.195 with SMTP id i3mr22855918wrc.49.1493737232886; Tue, 02 May 2017 08:00:32 -0700 (PDT)
Received: from 135.66.20.149.in-addr.arpa (135.66.20.149.in-addr.arpa. [149.20.66.135]) by smtp.gmail.com with ESMTPSA id i199sm1224083wmf.33.2017.05.02.08.00.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 08:00:31 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <149373185172.9923.9255526962045750289@ietfa.amsl.com>
Date: Tue, 02 May 2017 11:00:27 -0400
Cc: ops-dir@ietf.org, v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <7789CECA-165C-417F-B485-03A154327AC1@gmail.com>
References: <149373185172.9923.9255526962045750289@ietfa.amsl.com>
To: Joe Clarke <jclarke@cisco.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/mbz462bioSYmgUZo8H_8Cn5eU24>
Subject: Re: [v6ops] Opsdir early review of draft-ietf-v6ops-v4v6-xlat-prefix-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2017 15:04:21 -0000
Thanks! > On May 2, 2017, at 9:30 AM, Joe Clarke <jclarke@cisco.com> wrote: > > Reviewer: Joe Clarke > Review result: Has Issues > > Hello, Tore and Fred. Thanks for requesting an OPSDIR review of this > draft. Up front, I'd like to say that I enjoyed hearing the > discussion on why certain decisions were made, especially with concern > to ease of use for operators and compatibility with other established > translation approaches. That said, I have a few minor > issues/questions and nits concerning this draft. I think they will be > easy to address. > > ISSUES/QUESTIONS: > > You set out to define WKP as _the_ well-known prefix. For the most > part you adhere to this language in the draft. However, in section 3, > you state (highlighting added by me): > > Also, because the WKP is a /96, an operator preferring to use _a WKP_ > over an NSP can only do so for only one of his IPv4/IPv6 translation > mechanisms. All others must necessarily use an NSP. > > And then in section 5: > > When 64:ff9b:1::/48 or a more-specific prefix is used with the > [RFC6052] algorithm, it is considered to be a Network-Specific > Prefix. > > I believe what you're saying is that while you define 64:ff9b:1::/48 > as a WKP in _this_ draft, respective to RFC6052, it is an NSP. > However, the combination of text in both sections was a bit confusing > to me, and perhaps it would be useful to clarify your use of terms. > > === > > In Section 3, you state: > > Since the WKP 64:ff9b::/96 was reserved by [RFC6052], several new > IPv4/IPv6 translation mechanisms have been defined by the IETF > > I think it would be useful to mention some of these new translation > mechanisms as non-normative references, and if need be, show an > example of interoperability. > > NITS: > > In your Abstract, you mention RFC6890, but this does not appear to be > an xref to it, and it should be. > > === > > In Section 4.1 you state: > > OLD: > The second criterion is that the prefix length chosen is is a > multiple of 16. This ensures the prefix ends on a colon boundary > when representing it in text, easing operator interaction with it. > > NEW: > The second criterion is that the prefix length chosen is a > multiple of 16. This ensures the prefix ends on a colon boundary > when representing it in text, easing operator interaction with it. > > (Removed a redundant "is".) > > === > > In Section 4.1 again: > > OLD: > The [RFC6052] algorithm specifies IPv4/IPv6 translation prefixes as > short as /32. In order to facilitate multiple instances of > translation mechanisms using /32s, while at the same time aligning on > a 16-bit boundary, it would be necessary to reserve a /16. Doing so > was however considered as too wasteful by the IPv6 Operations working > group. > > NEW: > The [RFC6052] algorithm specifies IPv4/IPv6 translation prefixes as > short as /32. In order to facilitate multiple instances of > translation mechanisms using /32s, while at the same time aligning on > a 16-bit boundary, it would be necessary to reserve a /16. Doing so, > however, was considered too wasteful by the IPv6 Operations working > group. > > === > > In Section 6: > > OLD: > The Stateless IP/ICMP Translation algorithm [RFC7915] is one well- > known algorithm that can operate in a checksum-neutral manner, when > using the [RFC6052] algorithm for all of its address translations. > However, in order to attain checksum neutrality is imperative that > the translation prefix is chosen carefully. Specifically, in order > for a 96-bit [RFC6052] prefix to be checksum neutral, all the six > 16-bit words in the prefix must add up to a multiple of 0xffff. > > NEW: > The Stateless IP/ICMP Translation algorithm [RFC7915] is one well- > known algorithm that can operate in a checksum-neutral manner, when > using the [RFC6052] algorithm for all of its address translations. > However, in order to attain checksum neutrality it is imperative that > the translation prefix is chosen carefully. Specifically, in order > for a 96-bit [RFC6052] prefix to be checksum neutral, all the six > 16-bit words in the prefix must add up to a multiple of 0xffff. > > (Added a missing "it".) > > === >
- [v6ops] Opsdir early review of draft-ietf-v6ops-v… Joe Clarke
- Re: [v6ops] Opsdir early review of draft-ietf-v6o… Fred Baker
- Re: [v6ops] Opsdir early review of draft-ietf-v6o… David Farmer
- Re: [v6ops] Opsdir early review of draft-ietf-v6o… Brian E Carpenter
- Re: [v6ops] Opsdir early review of draft-ietf-v6o… Joe Clarke (jclarke)
- Re: [v6ops] Opsdir early review of draft-ietf-v6o… Fred Baker
- Re: [v6ops] [OPS-DIR] Opsdir early review of draf… Phil Shafer
- Re: [v6ops] Opsdir early review of draft-ietf-v6o… Tore Anderson
- Re: [v6ops] Opsdir early review of draft-ietf-v6o… Tore Anderson
- Re: [v6ops] Opsdir early review of draft-ietf-v6o… Joe Clarke