From nobody Mon May 1 11:47:51 2017 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 C944A129C0C for ; Mon, 1 May 2017 11:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oC0NURz_x4Yr for ; Mon, 1 May 2017 11:47:48 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 5256B129BC4 for ; Mon, 1 May 2017 11:44:16 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id y33so95247324qta.2 for ; Mon, 01 May 2017 11:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RqRLRI8VWYZj8NTcpIRVw//9MOMvcpOQ9/KEMWo78hc=; b=POH11PrTDKQ11SbfsUxddm9J+poEdDQhGgf2DclmJfbBSywh6VZio9NlISxpY1ecD6 35/JouMn1s1BsddAIiN6q0D7YhWb/mQOP8xTHg+r1JjtdZTR9yHHyMK3crLprhjhPuY6 E5Thra/vdRuvOyQjATUl7PcRMolnuDqprnHSvm/j8OSZrULcK76BNeFcT2Hs+uezk7ua Sf1PQ70g3d63gaM4sFnqsg0xrKIBSjVSZWePa6YpZXB6rPc3dyaH6IlGIwDGsIDdBHE+ SyNEZlar0bFO9cgV1lxDYnAf/ELd6qP2fB/4JeYD0XMZLTcV3jSoPdBD/i+F+kJW+ZHz dw+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RqRLRI8VWYZj8NTcpIRVw//9MOMvcpOQ9/KEMWo78hc=; b=ec6rODah8FrAvEhfmHf4+AbAiRCJHP75ZLJs4MQFn7VvOhiEuokOCHS8HcNZcBZpAQ 1aiyn+Igs98R6Hm64DP/0JCrs22gVOTKJD6y7ndHbOFp5KUi3QBwgojv6u/VXMJ487fG tH27zecaweDIJeonQIiqDcb6nh7ZEDZnHiF/qPO6qGq8UwqJmfK8lwUOENHzzD8ndn9I 7KC35fZsEHPe19oM2rLr6lBkVEM2C7PRcyt0+HpJ7Q/N85xdzfzL5hygSvEHsglwK/Sk FMt+iryBv1YZ5yl+NkTvUM0SAqVGbQODP4m1IO8xqZC885QS/gRXVhNAHEzy/NvehOHr XBgA== X-Gm-Message-State: AN3rC/4ov+UbR3qHgBON/ro0tqcB+eIRiNB44R7bYfbOADNn6E4ZSDuM 2BGSCtDxbdSRrGpA8B08hSkheJbdEGfjhlU= X-Received: by 10.200.41.8 with SMTP id y8mr23457565qty.220.1493664255314; Mon, 01 May 2017 11:44:15 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.208 with HTTP; Mon, 1 May 2017 11:44:14 -0700 (PDT) In-Reply-To: References: <149184472785.3090.17232934855800683894.idtracker@ietfa.amsl.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 1 May 2017 11:44:14 -0700 X-Google-Sender-Auth: cpZVXfXNIM1jAKd0MIPREVKz8Cg Message-ID: To: David Schinazi Cc: IPv6 Ops WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] Happy Eyeballs v2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 18:47:50 -0000 At Mon, 10 Apr 2017 10:43:45 -0700, David Schinazi wrote: > We've updated our "Update to Happy Eyeballs" document to address feedback received so far: > https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00 > Thanks to everyone who sent feedback, and please let us know if this > addresses yours. My question (https://www.ietf.org/mail-archive/web/v6ops/current/msg25780.html) is addressed with a reference to DNS-PUSH. Thanks for that. The following are my comments on the new version: - general: in my understanding one of the biggest changes from RFC6555 is the introduction of asynchronous DNS resolution. And, also in my understanding, the overall wg feedback so far is that while it's nice to have it's too strong to say it's this is *the* (using MUST/MUST NOT) way to implement the technique called "Happy Eyeballs". If this observation is accurate, the current text seems to be too radical. While I personally don't have a strong opinion, I suspect this document will have to - get a wg consensus on its strong requirement, or - weaken the claim (not to say "obsolete RFC6555" and avoid MUST/MUST NOT) - abstract: this doesn't talk much about asynchronous DNS resolution explicitly (maybe it's intended to be part of "algorithms that reduce this user-visible delay", but it's quite indirect). As it's a major update, I think the abstract should clearly state it. - Section 3 Implementations MUST NOT wait for both families of answers to return before attempting connection establishment. See the above general comment. This seems to be one of the too strong statements in this doc. - Section 3 The RECOMMENDED value for the Resolution Delay is 50 milliseconds. I'd suggest providing rationale for the choice of this value. - Section 4 [...] If the client keeps track of which addresses it has used in the past, it SHOULD add another destination address selection rule between the RTT rule and rule 9, which prefers used addresses over unused ones. This can read as if once a destination address is known to work and is used other addresses will never be used as long as the chosen address is usable. Is that the intent? - Section 4 Next, the client SHOULD modify the ordered list to interleave address families. Whichever address family is first in the list should be followed by an address of the other address family; It's not clear to me whether this applies only to the first IPv6 address and the first IPv4 address in the list, or any "pair" of IPv6/IPv4 addresses in the list. - Section 5 the "Connection Attempt Delay" SHOULD NOT such an aggressive backoff, as it would harm user experience. (editorial) it looks like a verb is missing after "SHOULD NOT". -- JINMEI, Tatuya From nobody Mon May 1 19:55:02 2017 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 2403012EA97 for ; Mon, 1 May 2017 19:55:00 -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 jOFSID_rcdL5 for ; Mon, 1 May 2017 19:54:58 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 4D8DA12E05D for ; Mon, 1 May 2017 19:52:22 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id t7so53340676pgt.3 for ; Mon, 01 May 2017 19:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=QIOQEuceyQqRJNBbAGceVnbvjNp/+74H2FaRgW8oDwg=; b=rBerXKY43Okki4wcuTRMRFfzKOEQzv+4ieem2yoKqp7GwAUkweTn9ckqYxmOqylufp pMOIq/5IVVm1Zgj1DiCtUK86NdBtnWoIYsLZX2XEeFLmci92OWnRxv68KcMpuGpSfR2A b33Qwi0iheL5oGftYk0jXffXQ2V5tDGknoiU3O4c0zGxlqCAtPB6+thAtk5f+6/7JBfa 7P2/vjIWCsOwEr3h71+TPo9S25l2alahvUo6ugPQZKiCFNGj/cOW0VUKrqDOJOSJMivK ryvAfvym/zu83FNMIVUHPk/VPBscEFqTquwi/KXYVBKqyJPk2CSwkOpjZDIJUUV9SRW2 vhyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=QIOQEuceyQqRJNBbAGceVnbvjNp/+74H2FaRgW8oDwg=; b=COmN6ZH/LCY4RMTbFZ7pTYYrdFNkVpDovhezpJi/xKIXzUI3MQit3lsPuwcJtonBD/ g7ksLxEdMEgFEkw/G4jB0TtV30KpjueGLC4hz7xGdw4gdjJ587J5BEdLYvUgtx2KSmyX ykWqhb8VQDsTtI6dgMB+4wFH3JuOqfn9olVfk/tlNaMq5xfXx3u8VFGZGDPS+vXs9osa 393Sm6ps2GgDLNg5D3tHBE/FVqnG/jF3FgkPKI+Zzd5peRYWQBXCUBCtW2q2us5r/elD T39aF6P5+Uyg3VI3DeWdywTuTJItlnx3UhTKH+DqroodQVo7ii6LHXRImecLVLFzCpI+ RZCQ== X-Gm-Message-State: AN3rC/51AjOyjW2yC/1HuictAFjkDI/EnPq1ZzIxuA2UAV1E1z1eY7q3 1AzdZk/lNKL9vvVT X-Received: by 10.84.129.67 with SMTP id 61mr38478261plb.150.1493693541533; Mon, 01 May 2017 19:52:21 -0700 (PDT) Received: from [130.216.38.57] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.57]) by smtp.gmail.com with ESMTPSA id x2sm26456588pfi.80.2017.05.01.19.52.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 19:52:20 -0700 (PDT) To: v6ops@ietf.org References: <5149F9F2-5E83-42E1-9852-4CB593F3823F@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <36051317-0427-9347-0246-593dcbbcd0ed@gmail.com> Date: Tue, 2 May 2017 14:52:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5149F9F2-5E83-42E1-9852-4CB593F3823F@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Brian's review of draft-ietf-v6ops-ula-usage-considerations-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 02:55:00 -0000 Hi, We're specifying the use of ULAs in Anima and I've been using them in tests with no problem. So here is my review of draft-ietf-v6ops-ula-usage-considerations-02. (There are also a few issues of English, but let's work out the technical content first.) > 1. Introduction ... > - Globally Unique > > ULAs are defined as a global scope address space. However, they > are not intended to be used globally on the public Internet; in > contrast, they are mostly used locally, for example, in isolated > networks, internal networks, or VPNs. Because of draft-bchv-rfc6890bis-06 (just approved as BCP), I suggest revising this paragraph: ULAs are defined as having global scope. However, they are not intended to be used globally on the public Internet, so they are not considered globally routable [I-D.bchv-rfc6890bis]. In contrast, they are mostly used locally, for example, in isolated networks, internal networks, or VPNs. ... > - Well Known Prefix > > The prefixes of ULAs are well known thus they are easily > identified and filtered. I suggest: The prefix (fc00::/7) of all ULAs is well known, so they are easily identified and filtered at a border router. Individual /48 ULA prefixes may be filtered by normal configuration. ... > 3.1. Do Not Treat ULA Equal to RFC1918 ... > (People may still > have a requirement for NAT with ULA, this is discussed in > Section 4.3. But people also need to keep in mind that ULA is not > intentionally designed for this kind of use case.) I think this parenthesis does more harm than good, so I would prefer to delete it. Let's keep the tricky discussion in one place. > Another important difference is the ability to merge two ULA networks > without renumbering (because of the uniqueness), which is a big > advantage over [RFC1918]. I suggest: Another important difference is the ability to merge two ULA networks without renumbering (because of their unique /48 prefixes), which is a big advantage over [RFC1918]. > 4.1. ULA-only in Isolated Networks A general comment on this section: should we include virtual networks here, or add a section "ULA-only in Virtual Networks"? (I'm thinking of draft-ietf-anima-autonomic-control-plane as a use case, but there will certainly be others.) ... > o Prefix generation: randomly generated according to the algorithms > defined in [RFC4193] or manually assigned. Normally, automatic > generation of the prefixes is recommended, following [RFC4193]. > If there are some specific reasons that call for manual > assignment, administrators have to plan the prefixes carefully to > avoid collision. This text seems to encourage manual assignment, which is against the MUST in Section 3.2.1 of RFC4193. I suggest: o Prefix generation: randomly generated according to the algorithms defined in [RFC4193]. Note that this may be an automatic process. Alternatively, prefixes may be randomly generated off-line, checked for uniqueness within the domain concerned, and then configured by administrators. > o Prefix announcement: in some cases, networks might need to > announce prefixes to each other. For example, in vehicle networks > with infrastructure-less settings such as Vehicle-to-Vehicle (V2V) > communication, prior knowledge of the respective prefixes is > unlikely. Hence, a prefix announcement mechanism is needed to > enable inter-vehicle communications based on IP. As one > possibility, such announcements could rely on extensions to the > Router Advertisement message of the Neighbor Discovery Protocol > (e.g., [I-D.petrescu-autoconf-ra-based-routing] and > [I-D.jhlee-mext-mnpp]). I suggest deleting the last sentence. It's not very solid and I suspect that we should leave the question open for now. > 4.2. ULA+PA in Connected Networks ... > [RFC7084] requires the CPE to support ULA. I suggest adding: and [RFC7368] recommends using them in home networks. ... > Benefits of Using ULAs in this scenario: > > o Separated local communication plane:... To be clear, this is a different case from my suggestion above to add "ULA-only in Virtual Networks", although the argument is similar. ... > Drawbacks: > > o Operational Complexity: there are some arguments that in practice > the use of ULA+PA creates additional operational complexity. This > is not a ULA-specific problem; the multiple-addresses-per- > interface is an important feature of IPv6 protocol. Add a reference to [RFC7157] ? > 4.3. ULA-Only in Connected Networks Could we get consensus to say simply: There is no recommended mechanism for connecting a ULA-only network to the Internet; see previous section. > 4.5. IPv4 Co-existence Considerations ... > However, > there are still lots of hosts using the old standard [RFC3484] Is that still true? If so, I suggest s/lots of/many/ ... > Happy Eyeballs [RFC6555] solves this connection failure problem Only for applicaions that support it! > 5. Security Considerations ... > As mentioned in Section 4.2, when using NPTv6, the administrators > need to know where the firewall is located to set proper filtering > rules. I think this refers to some deleted text and so it should also be deleted. Regards Brian From nobody Tue May 2 06:30:54 2017 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 B73D3128796; Tue, 2 May 2017 06:30:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joe Clarke To: Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149373185172.9923.9255526962045750289@ietfa.amsl.com> Date: Tue, 02 May 2017 06:30:51 -0700 Archived-At: Subject: [v6ops] Opsdir early review of draft-ietf-v6ops-v4v6-xlat-prefix-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 13:30:52 -0000 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".) === From nobody Tue May 2 08:04:22 2017 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 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 In-Reply-To: <149373185172.9923.9255526962045750289@ietfa.amsl.com> Date: Tue, 2 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 X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 15:04:21 -0000 Thanks! > On May 2, 2017, at 9:30 AM, Joe Clarke 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".) > > === > From nobody Tue May 2 08:43:20 2017 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 55B5E129BFC for ; Tue, 2 May 2017 08:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.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 9p3ixq8TWwrT for ; Tue, 2 May 2017 08:43:16 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 D8C5A129C1D for ; Tue, 2 May 2017 08:40:24 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 62DD35ED for ; Tue, 2 May 2017 15:40:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OW0HVaMIZVh for ; Tue, 2 May 2017 10:40:24 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 12461996 for ; Tue, 2 May 2017 10:40:23 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id 33so28366136uat.9 for ; Tue, 02 May 2017 08:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mKDR4TsVoAf5yD6T1Wnu1N90c7rw1rJXMSzEYqzFvWQ=; b=P33IFbt3gm/TDFYFRFy8Gtrhern9a7HyCKyyOVFu+j8W1is5Pj0Wq6kTO5Yf3klSlP uJyZAlN2UjU2bohS+E0MAhIFDoXuvnWwYPoL4Vrjz7ARuWMWiX+1SYRGAuod9O8wZatN S2E0DcLDp/0caRqrb5u9QEdjICZM2x13ZHwgi6jDUtFpxfAocZqrunRHT+VXuGiPuDjM PNnhC9OOmZSVZhbJmvtLdti5AODzPpPZsyFqLX5aDew4Q7qwuDGXNkIGW/Lh4+/e0mzq JrvZiDUF0WIB3kV2M0VVeASXRsyanBZ7F31aUx+wgGmUlPcS0ITtt3pE8cD0yAR6tKyB henw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mKDR4TsVoAf5yD6T1Wnu1N90c7rw1rJXMSzEYqzFvWQ=; b=sGIy67AtWIY/9BwhZAIV6v9swyev6wMd9IO1dc454MvmVGdQDZHO++fraFru8J1oZ2 9fl4Bzz5cbI9lryh6do7HuC8Dd46wZnm51XC6xoI4IIMlb9DwukMItz4obrUPbTFZlMY TH4PL19bE1kI+sRlhOAmY0rJOHluA96ODtNRBa/mBWKqrDnuUJEBjuiMTa+loQ6xw4fu e1RjU738OWe9Jhd3vDUaQczTdcot7kud78kx9FmH9CgWA91tFRdFpx+KWWB/o/XFczzn O4xmvZ6YBSufOH7F9cExyaAxPZCZ6/APq02AFg5Nav/8QSGmtPIyE4MImTPourq+RCci RCrw== X-Gm-Message-State: AN3rC/4B3zHRX57ed/O+4CA6CX845EDWinKk24y48ESFsPXzrl92RYNc Q3FMDbI+XZ+XcHHEGSgz7nAE77I+013SI2Kvs7n40o49gkEE/c6wXl3KnFjQU+uhlTk6iP+Y5ZS DrpUbrnABrg8Am5oJ X-Received: by 10.159.48.8 with SMTP id h8mr16594678uab.142.1493739623335; Tue, 02 May 2017 08:40:23 -0700 (PDT) X-Received: by 10.159.48.8 with SMTP id h8mr16594660uab.142.1493739622956; Tue, 02 May 2017 08:40:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.44.69 with HTTP; Tue, 2 May 2017 08:40:22 -0700 (PDT) In-Reply-To: <7789CECA-165C-417F-B485-03A154327AC1@gmail.com> References: <149373185172.9923.9255526962045750289@ietfa.amsl.com> <7789CECA-165C-417F-B485-03A154327AC1@gmail.com> From: David Farmer Date: Tue, 2 May 2017 10:40:22 -0500 Message-ID: To: Fred Baker Cc: V6 Ops List , draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org, IETF-Discussion Discussion Content-Type: multipart/alternative; boundary=f403045dce5e9d1e9c054e8c5bd4 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 15:43:18 -0000 --f403045dce5e9d1e9c054e8c5bd4 Content-Type: text/plain; charset=UTF-8 Prompted by this review, I reread the document and found what I think are a couple additional typos. Section 4.2, Prefix Value, compares two options: 64:ff9a:ffff:ffff::/48 and 64:ff9b:1::/48. However in the fifth paragraph of the section, I believe there are two errant references to 64:ff9b:1::/96, that should instead be 64:ff9b:1::/48, unless I'm misunderstanding the intent of the paragraph. Thanks. On Tue, May 2, 2017 at 10:00 AM, Fred Baker wrote: > Thanks! > > > On May 2, 2017, at 9:30 AM, Joe Clarke 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 mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f403045dce5e9d1e9c054e8c5bd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Prompted by this review, I reread the document and found w= hat I think are a couple additional typos. =C2=A0

Sectio= n 4.2, Prefix Value, compares=C2=A0two options: 64:ff9a:ffff:ffff::/48 and 64:ff9b:1::/48.= However in the fifth paragraph of the section, I believe there=C2=A0are tw= o errant references=C2=A0to=C2=A064:ff9b:1::/96, that should instead be=C2=A064:ff9b:1::/48= , unless I'm misunderstanding the intent of the paragraph.=C2=A0=C2=A0<= /span>

Thanks.

On Tue, May 2, 2017 at 10:00 AM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
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.=C2=A0 Thanks for requesting an OPSDIR review of = this
> draft.=C2=A0 Up front, I'd like to say that I enjoyed hearing the<= br> > discussion on why certain decisions were made, especially with concern=
> to ease of use for operators and compatibility with other established<= br> > translation approaches.=C2=A0 =C2=A0That said, I have a few minor
> issues/questions and nits concerning this draft.=C2=A0 I think they wi= ll be
> easy to address.
>
> ISSUES/QUESTIONS:
>
> You set out to define WKP as _the_ well-known prefix.=C2=A0 For the mo= st
> part you adhere to this language in the draft.=C2=A0 However, in secti= on 3,
> you state (highlighting added by me):
>
> Also, because the WKP is a /96, an operator preferring to use _a WKP_<= br> > over an NSP can only do so for only one of his IPv4/IPv6 translation > mechanisms.=C2=A0 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<= br> > to me, and perhaps it would be useful to clarify your use of terms. >
> =3D=3D=3D
>
> 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<= br> > an xref to it, and it should be.
>
> =3D=3D=3D
>
> In Section 4.1 you state:
>
> OLD:
> The second criterion is that the prefix length chosen is is a
> multiple of 16.=C2=A0 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.=C2=A0 This ensures the prefix ends on a colon boundary=
> when representing it in text, easing operator interaction with it.
>
> (Removed a redundant "is".)
>
> =3D=3D=3D
>
> In Section 4.1 again:
>
> OLD:
> The [RFC6052] algorithm specifies IPv4/IPv6 translation prefixes as > short as /32.=C2=A0 In order to facilitate multiple instances of
> translation mechanisms using /32s, while at the same time aligning on<= br> > a 16-bit boundary, it would be necessary to reserve a /16.=C2=A0 Doing= so
> was however considered as too wasteful by the IPv6 Operations working<= br> > group.
>
> NEW:
> The [RFC6052] algorithm specifies IPv4/IPv6 translation prefixes as > short as /32.=C2=A0 In order to facilitate multiple instances of
> translation mechanisms using /32s, while at the same time aligning on<= br> > a 16-bit boundary, it would be necessary to reserve a /16.=C2=A0 Doing= so,
> however, was considered too wasteful by the IPv6 Operations working > group.
>
> =3D=3D=3D
>
> 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.=C2=A0 Specifically, in ord= er
> 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<= br> > the translation prefix is chosen carefully.=C2=A0 Specifically, in ord= er
> 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".)
>
> =3D=3D=3D
>

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



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommun= ication Services
Office of Information Technology
University of Minne= sota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phon= e: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-= 9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
--f403045dce5e9d1e9c054e8c5bd4-- From nobody Tue May 2 16:04:11 2017 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 074901296CD; Tue, 2 May 2017 16:04:02 -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 SpLORBmE6cVW; Tue, 2 May 2017 16:03:59 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 9ECD4129515; Tue, 2 May 2017 16:01:55 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id v1so24936532pgv.3; Tue, 02 May 2017 16:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nABeFVGEteVxrwA3WaMfm5HI0sp9CxaZ2upwSNaRnzM=; b=qlx8SLhnpeh1FqS/fBb3zbi01Qog1R+uZweSX8vEiywoqper7C6S9RoUMzWK495tOt 95DDK/3ncpkZtCGjPSCQJC9NieAGx8QfZJRFN+efSTjQVPDE26FlUTJi+WZ5Fin8MfQG 6+v7xwWe0ANt2IPnq7M6FWb/aY4qdTBmk3JVhhN0ajt+Tnb/AzBvaPj509Xkthfk4jZc hoXoIQSdJmkGMk/Sqzms8DpY/YA87K1NXObFqM6JDKfEl/7w4DhLRFD4jy0OY3W2dFIN 9NcS2B27OIearPofNefms3sxK06nHn4u1WRlnxC8zBL8ZpPhkjLfzCMKc8kcgwTF8+Kv /fQg== 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:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=nABeFVGEteVxrwA3WaMfm5HI0sp9CxaZ2upwSNaRnzM=; b=DplQTVIJPHvtsZdXCExK3V3JLjMCNrFjzzu/Nhrzmsc64ARSEwqnhqgEnruz8UuTo0 f+T/5F7iW5nY1iCIvAgdi2ofmtZOuy0b7fvF6r5OAXxAJg7uUwaOEh04kHHnWvQ9j0xS T2hwvFBpldX79vIzu2H8YhZGoACxtqeiXEM+t7j5bV1keFE4AWFBi/uFCQnAWE+Ajb5y 8mKjK+4x4f0YzISIUKO6MyMqC7wGwHiZo90zXBHFGrn6BVLWju6Vt0l1JMQ9DeXEM0E6 WUzaYcewGh5sYjOlNP3k9QSXnnWCY9cDbVaITDyOicIMwYpVi11mKX7LWyBMNK6mFFfY Ph/g== X-Gm-Message-State: AN3rC/4m12at13vuYjt72Yr9U3WhyL+TptfqhtBuR8/sggPHMyiKTRzx TSop57ve00OEIA== X-Received: by 10.84.192.37 with SMTP id b34mr45181043pld.174.1493766115295; Tue, 02 May 2017 16:01:55 -0700 (PDT) Received: from ?IPv6:2406:e001:3a49:1:28cc:dc4c:9703:6781? ([2406:e001:3a49:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p28sm791331pfd.53.2017.05.02.16.01.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 16:01:54 -0700 (PDT) To: Joe Clarke , ops-dir@ietf.org References: <149373185172.9923.9255526962045750289@ietfa.amsl.com> Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <06e8313e-38ed-7ea5-76f0-db2f6352844e@gmail.com> Date: Wed, 3 May 2017 11:01:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149373185172.9923.9255526962045750289@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 23:04:02 -0000 On 03/05/2017 01:30, Joe Clarke wrote: ... > NITS: > > In your Abstract, you mention RFC6890, but this does not appear to be > an xref to it, and it should be. afaik, the RFC Editor style does not allow xrefs in the Abstract. (Also: draft-bchv-rfc6890bis will update 6890 soon. I don't know whether that's relevant.) Brian From nobody Tue May 2 16:09:27 2017 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 5CDB312EAF0; Tue, 2 May 2017 16:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 0h7OsoB650Mb; Tue, 2 May 2017 16:09:24 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B166127097; Tue, 2 May 2017 16:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=624; q=dns/txt; s=iport; t=1493766395; x=1494975995; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sS2HCvjTUHNvtKHaOu/En2ooNbMt7HBuTHPzrj1VXm0=; b=I/pNkjdzTBSnL7ZLyIq3DP6KWgOn2s3p4KsxnaZ53WBP00Ub/W94aKtH bDEA8hX47Qbn0YInQb5splU6GSQ+7Lkey6iwTdehDoWdIycMW74Z62JqA /FtnbXd0Hq0sCeEHbPWd2W99RSRYQcgHzmxo8K1Vu04Oift/jmHxS9xL1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAACkDwlZ/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQyOAJFPiCKNTIIPKIV8AoRQPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBOj8FCwIBCBgeECERJQIEDgWKBgMNCLJZhzkNg1sBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdhl+BXiuCcIJUKIFngzSCMQWdGTsBjkKEToFqGI9ciHeCKCeIagE?= =?us-ascii?q?fOIEKbxVWAYZddgGJCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,281,1491264000"; d="scan'208";a="418830551" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2017 23:06:34 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v42N6YS5029729 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2017 23:06:34 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 2 May 2017 18:06:33 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Tue, 2 May 2017 18:06:33 -0500 From: "Joe Clarke (jclarke)" To: Brian E Carpenter CC: "ops-dir@ietf.org" , "v6ops@ietf.org" , "ietf@ietf.org" , "draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org" Thread-Topic: [v6ops] Opsdir early review of draft-ietf-v6ops-v4v6-xlat-prefix-00 Thread-Index: AQHSw5gYiMaIOea5YEmnrvODvaYgVqHhqktV Date: Tue, 2 May 2017 23:06:33 +0000 Message-ID: <8392FFDD-AA72-47B6-B689-1EE2C8967A2E@cisco.com> References: <149373185172.9923.9255526962045750289@ietfa.amsl.com>, <06e8313e-38ed-7ea5-76f0-db2f6352844e@gmail.com> In-Reply-To: <06e8313e-38ed-7ea5-76f0-db2f6352844e@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 23:09:25 -0000 PGP Key : http://www.marcuscom.com/pgp.asc > On May 2, 2017, at 19:01, Brian E Carpenter = wrote: >=20 >> On 03/05/2017 01:30, Joe Clarke wrote: >> ... >> NITS: >>=20 >> In your Abstract, you mention RFC6890, but this does not appear to be >> an xref to it, and it should be. >=20 > afaik, the RFC Editor style does not allow xrefs in the Abstract. I've seen some that do (ostensibly). But this if this isn't required, it w= asn't critical. Joe >=20 > (Also: draft-bchv-rfc6890bis will update 6890 soon. I don't know whether > that's relevant.) >=20 > Brian From nobody Wed May 3 03:23:56 2017 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 F18BE12947F; Wed, 3 May 2017 03:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 AzKKcCIbTyuc; Wed, 3 May 2017 03:23:39 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::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 8F58F1294A4; Wed, 3 May 2017 03:21:21 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id y10so11630432wmh.0; Wed, 03 May 2017 03:21:21 -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=rZbdHYtfYjfsXJIXrrLvj38ladSzLZBOFy7InbpDnxQ=; b=F7b3kkHpNy7IXCbQ2qQJxthR9SRwdoscj0uCa8GpISDiT3TOMg24F3VOoMQurGvlOb jWK151kxPuWUTDFSYrxXz2NXfmRpCtSwdm1fMYrWRpdJO20409CE40aR64bJMGwy5boF S6Xs+npQj53YBTs3G/KeruUuEZF2VKdTx8R49LJ4+31WuietbVH0A48LLpfzaYiZdikv rFkje0uPs0dNgHKDBHmzB61hiu8KWhqSWGz5s5mF/77+nDm+Vsup4MwANA+k2dTMhZU7 SF2ag8bVd0csuJYlL+6G6Dm51DYe6sLa+hSp/KQEtDBj8I0XBmn2wiMq6zCxp3BTsJvF GNuQ== 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=rZbdHYtfYjfsXJIXrrLvj38ladSzLZBOFy7InbpDnxQ=; b=AOcT0Ur3a8mZu9lZAltTQihE0U38f5otkurFrB0oGM5Naq7QPFAuCr1Mrw22Jg7N+u OZTcvZystOM4p74Wlta+gP1Ox5as9Vv3ABdP2OU11Irs46r8fqpHsDlNRK+14DMr+VhX 9AiNQEpHlU8OV1JTLDKN4B57LBYqQO37S7ar0GvOXsiIUO971l5Ln1i0N9eLEsPlrk+4 E33z5EhTrdZBEps2US9xrtGg4aAv/x+VTdf2MIFpCujthDBKfPiMsqeQzeYtHsVFZcIN yLpYNiS6YT+OQF0j63qsTo7iz8+mZDaiqymAhIaXjbOOEAtQtGWLmhsHWjm9IKFODccm fGmA== X-Gm-Message-State: AODbwcBI65MxrjiGO01OyY0CU2aCLk1vxLpCgZke0p0ler653gIN18m6 0qNBS89cmlXLZg== X-Received: by 10.28.193.138 with SMTP id r132mr221724wmf.87.1493806880047; Wed, 03 May 2017 03:21:20 -0700 (PDT) Received: from 211.66.20.149.in-addr.arpa (211.66.20.149.in-addr.arpa. [149.20.66.211]) by smtp.gmail.com with ESMTPSA id u200sm4395602wmd.16.2017.05.03.03.21.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 03:21:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <8392FFDD-AA72-47B6-B689-1EE2C8967A2E@cisco.com> Date: Wed, 3 May 2017 06:21:14 -0400 Cc: Brian E Carpenter , "ops-dir@ietf.org" , "v6ops@ietf.org" , "ietf@ietf.org" , "draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149373185172.9923.9255526962045750289@ietfa.amsl.com> <06e8313e-38ed-7ea5-76f0-db2f6352844e@gmail.com> <8392FFDD-AA72-47B6-B689-1EE2C8967A2E@cisco.com> To: Joe Clarke X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 10:23:42 -0000 One of the issues with a document that updates another document is that = it is supposed to say in the abstract that it does. > On May 2, 2017, at 7:06 PM, Joe Clarke (jclarke) = wrote: >=20 >=20 >=20 > PGP Key : http://www.marcuscom.com/pgp.asc >=20 >> On May 2, 2017, at 19:01, Brian E Carpenter = wrote: >>=20 >>> On 03/05/2017 01:30, Joe Clarke wrote: >>> ... >>> NITS: >>>=20 >>> In your Abstract, you mention RFC6890, but this does not appear to = be >>> an xref to it, and it should be. >>=20 >> afaik, the RFC Editor style does not allow xrefs in the Abstract. >=20 > I've seen some that do (ostensibly). But this if this isn't required, = it wasn't critical. >=20 > Joe >=20 >>=20 >> (Also: draft-bchv-rfc6890bis will update 6890 soon. I don't know = whether >> that's relevant.) >>=20 >> Brian From nobody Wed May 3 05:54:20 2017 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 91A741294C8; Wed, 3 May 2017 05:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 RWksgt7WIRKx; Wed, 3 May 2017 05:54:02 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0091.outbound.protection.outlook.com [104.47.42.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB281294EC; Wed, 3 May 2017 05:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1fYL5aMCLgRxvROUAsm7o/fdkG4GtsJyV+x8tY7MryI=; b=JZV9cZCn4prVGq7BVYVFuVkXPz2i7F1eB8DJeROx6s1HdNBDXuU1CR1Wv5Qdbi09UATZveUlnoozv307V9ja4krulEimcMp3LXLHVFc4LLWNal/DvPS5BSvFMCXtKEEhhtCjEhKM8+oJhia8yXIl4PCVQjlx+NU8bLrD4/r6oKE= Received: from DM2PR0501CA0015.namprd05.prod.outlook.com (10.162.29.153) by BN1PR05MB043.namprd05.prod.outlook.com (10.255.202.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Wed, 3 May 2017 12:51:26 +0000 Received: from CO1NAM05FT059.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::207) by DM2PR0501CA0015.outlook.office365.com (2a01:111:e400:5148::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1 via Frontend Transport; Wed, 3 May 2017 12:51:27 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT059.mail.protection.outlook.com (10.152.96.177) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Wed, 3 May 2017 12:51:26 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 3 May 2017 05:50:56 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v43CotRd028026; Wed, 3 May 2017 05:50:56 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v43ComaK047821; Wed, 3 May 2017 08:50:49 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201705031250.v43ComaK047821@idle.juniper.net> To: "Joe Clarke (jclarke)" CC: Brian E Carpenter , "ops-dir@ietf.org" , "v6ops@ietf.org" , "draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org" , "ietf@ietf.org" In-Reply-To: <8392FFDD-AA72-47B6-B689-1EE2C8967A2E@cisco.com> Date: Wed, 3 May 2017 08:50:48 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39860400002)(39450400003)(39840400002)(2980300002)(189002)(199003)(9170700003)(8276002)(54356999)(50986999)(2950100002)(6916009)(356003)(230783001)(8936002)(229853002)(8676002)(5003940100001)(305945005)(54906002)(48376002)(189998001)(558084003)(50466002)(110136004)(5660300001)(6246003)(38730400002)(7126002)(77096006)(478600001)(53936002)(4326008)(7696004)(106466001)(81166006)(47776003)(105596002)(2810700001)(39060400002)(2906002)(86362001)(1076002)(76506005)(53416004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB043; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT059; 1:9UBspxCGDjhqUC2NpiasH8xQWiuAckUwIdI0X1byTY1Fop90dqX/jFUUlXIIxcSAhZMsferxozIZD0HVex7r0aKgIoIICT/W/0rkPvwkEmSkO+OxmFn9KgjNfNeNL9On6xuqvB42zN6WRHb/83/sekbnWDXcRDiIsDMhe7CpXDnKoyy46kv5358uJa+tuagUjuwNDydLDelXGi4wqr8oK+kDmoOQR1uHJ8IGOtktSlI1F5E+uyI7Ne8saV2k13z2r9hCjLKac87SDODCLMWCVnG8D/lbdrDgOlzERJp7S0xKGMVwiaPee673Fa8lOsdnFZ7EsymLdjaR08l5mxy3oi/CTrd2V4XaRpdxShLYVfx8UwrO5KQZ+OefBEd5knS/r+MxY5knxFEOjKhAlQI849Z9B16UOY44POvzEIWW7Qd+YZZ55R7vB0GJ4ntNaePrv0GhJGrQF5v7hxxv9EK5kVtiXz2KUTGpgDOadTT3ov+qdea8ZTqDndHn9L4nnbmt0TcUoRUyg2uNuO2OcTKk3wyVgZgfW+QCTN5WfC2WHkwmAVY5M6uCWn9kLU1skAfIJHOhsaP+hw6x9+394WDzWfzAQ9gkduVw3w6Kxty1I1PpcJ/Dx8sltE9czEh1y+qw X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cc6a2b48-f8c2-495c-6d78-08d492231c8e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BN1PR05MB043; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB043; 3:2OxT0DAoW4ZrkK4/Qs7VgtODJQt8lKPjRYNyPlhmSaL46+XQFKDD4MbV67N0N01TxhXyxDa47TFZdvg8IZ8U/TZ+G3MTO74mfEKlifIMiTSUJ8hTTkCwf7eD45IUiPvyjh11EMtYLE79mQlaPdywfj6jfn398KCUt7VxxwoIBMrq4oSzzxKHYAt4F3fEhB/68hAN7owEVdfPp1v796lWAKfub8wmksiHg5nRD6Kg0BQbUADuq3XtZNkSDvpKHgbTT+cTzyKuC/jDS8VZa4iv7nOxedyjkIziYKJj9meXFSeAWE99cEvv2ABIfqbT6YwLiJwihG2ITqTIyHJq9K9jjxAJrfshL6sXVPR4aJ5tK8H0CBBWjXv9FySa4O77242N9HwFNbtO6N1NIhp5nquRiI37HhLAgpfQtvgijgeEBm2B1M8zzR6CdBek4aRBxFVgJA3uzZzJX8avUnnojrxMKDu/+OfIGaz24G8u3ybES5NVFoqltjg/R1r6rhSMRpGB X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB043; 25:cQkTAKaEnCTj0ey/p5XRAEXAaYokYOb3s976JqU52dKtgBzYkMdioeViZg7mG+eCW0zlmxd9+s6DbFeQEWSDYphziEsQbIh1e+eYnF+jXwnW/hZGwzM4tyQ/bnR4r7Et4Qji+OtR53zAhqBR6i37wTvJRcy+YZ/Mgu4W5rTR3u/5JQTS0ksWu+UqxzKnet/cDkfPK2qsa2WdDrvKRCIcaoy5F90uhE7takYEPst9VhvztzGfZA6z9xvTmeCJfwXMZhwO8Xg/iya+VChVISdYj9J9TQEFOXfp8RzuEYwAZfc4b3qvbuOyRsJWvZkHcQPuoX2axtvtHSix8NbD+b73sSGvqg6ImP7Ddaiy7b942vKVopDHGF7q7McRGIQoU/BTgDwT4gt8Yr0Yoyn7rnl5vXh/bbCrUX3GWuO8ZR9DnQSaCl7Zx3ZIpq2bZdnq69tBKvqVaQ7IKNgcWIj/iK0munSOTxs4mInqLjTKFjeHQFQ=; 31:D5BAPBJwzGC8FszN8leu2fxmk1hkup3CwYEKVl6P4BryHKZIBQAdLaYkhW8cahPwjjkMmPztQhltKpT0pZFRTzMvwHNkb9gnSTCKD/cQQ7iS2oqpnuRipoJuPcpIEUwa9MyeahEQwPpujMiUEjo/OtT3MsynZnCor2JPZfFk0RzAfXuHt8Dwd2KLfgiqRgqcUVZP3gRCteh/A4d1L2WiDdUdszMFi/cCfcp8wMMpXa60B6vvIN9aA7LUaMsWZHonKSSOPVeZuOUCNekF7DqxSlEtzU9hI4F0uRK/8/Ydvq4= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB043; 20:Sa4xmtqRtAup668Utk9HhcrOJspD9ir6oLRKE42PovG0eoNGuBPyZCV6NVQSFS71WDxC7sdbMFjGtaegG+KRXkFXmM1imE4S/fkHM1Ahd2kAx8QsDILE7GCG1vAa4Atw+vx28IN4n2+KNT0e03yDSvbmD023gDIFk66eOjZcg0wugOpGL7iu/KzbrUshhw8U+Fo0vp3V+rXb+2L3XPc3hhPmJKP7zemGZzxPo5MYgF1o1SG5RFHcRniZ5Y8DiH+1bD0mI3x1u9kCLZVq4L9WqcIhtT4oJMbZX34tsI/vRmyTpRlvgsLcu/Dne1CjlKxN5gcIgnJ0UbwpPYyy+An+3tEYAtQpzdthlFtAWsw4q5qL1faycnDEcSo3P76Ddpg3ZeunXeDyD2zUOz/fJBKgOK1ccxQ10hSKN/JBi83pNnibNw4gIzsfWyzM0QKuoDbRpXv12uvTweT/xUqDRF8iyZYcZJed7Gavfr96kwRwYjMDnhG9ErjkhDmHumppgVEh X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13018025)(13024025)(13017025)(13023025)(8121501046)(13015025)(5005006)(3002001)(93006095)(93003095)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(6072148); SRVR:BN1PR05MB043; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB043; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB043; 4:aH8u1a/2yKNgnaPHnAYG+UiTdXf1kHcNqngeEYysOxYevstH0JXQIjR9hUG3MCiaHuBvd+3XsJMzWWE0ZrXzYl+iOZt2xnK97ncdqMd1iaUaRTW2VZxoNeaYMGSXO27y8nOaZ3xvry17DCIKI/YtKQEufJkTrLaubABzymQhEqWs5ZMBZjgTp9OKH4sga8kfWrXtd/hgvuPnzvbNKCbCDdcKsxmxXacqzHi+wYi4i1/eXQZjhVhxvoPNensWiAOlBwaE+Mgt/hfMDByxqeYd+iATiOxpzIVmtKpQakaLLxL0byGDobHVHy9jSz/PO+8U6AqfYs/R3TdZbEcukd9rLyYZkAOxKBOPYUx0+nUqxH/kpS7jKNQKsiQUEhcgHpcZAp/hZf1pvuxk8PMTSjaluXWnqhnbtBeP3EzHlWxVIAnpZcXCeEoWGC91kudnKbvGfWL+/yjDJ6uPJyaiOV001ceN4Z/148nW74i8kLhq9Q0K9P63/J4Xw0wiE1/JY3SLyJxjHATu6XyUjfQ2lFGOh2JV0t0icnMKwvK4rqeEdBhSGRBhe+8M0wm4Ie+uvzasOSyxbwxmOWeHNC8FaezKAjBrjB8Ar6Bbt6Pdv1aLAvVYQKS53PlnGYrDfBArd8hY/s0YV1ZCc1txPOOU0bjEeyXUapc9rmVMZBJe7Yt0+R8SHeatDaFxAoCty51Y+LA0jChF13v6j4skHtBTUFnIq3CaC/lnDP2VOQ3SurGRkNGk3urQPa6ATbpwHlnfHW9oSXc9BXa3xg8UPxGWF2kfH3H5FwBXtzRAH4Ew3rZZ2EBAI0V6MQB60K/ppqywP9vq6cvMlstWMSqKqhxzXqmSkzkQ4yQ5osuOvoHTngGxdp7xOKIITmDr5oIlZoGmS7WPboekJzdsqfLdofMJqnp/ng== X-Forefront-PRVS: 029651C7A1 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB043; 23:iANeDwwLvikuXy8M60fGvClYEO8MHcJwOe/Nf5vJe9?= =?us-ascii?Q?LcHe4faUP0+o9TKmBo7jMrZnjKxRJAfveAESrHvR1EVif9YQA+uM3qfQglQf?= =?us-ascii?Q?IX3eKBUJkJ6pcADMS4hCv/W0YS0KIdicDz31pnxT9hsKEVQ6eP8lH3eFMKEX?= =?us-ascii?Q?kEFgDajKQ5pmmX0qjp36XvH+6BoPWzdjPdV73VXjF6R3q0BTZDvNoCZo5w0j?= =?us-ascii?Q?qu8q1/ZLWdN+ezFNKhogvvCu4+eWFGU24f5P/2mI9xvHjawRRageMD3ZBVcl?= =?us-ascii?Q?kQXZ7UG6BfG1mapuQ17b0ncgFZgJRpeOg9Bq+lZI4YJt0NcFED6oN60qjtit?= =?us-ascii?Q?isf7z/XflbfoTB6GvJUKyAUuZlWuEXlpJg2alYvKroImApeVNd+T+dcfZPMa?= =?us-ascii?Q?YybBUT0r/QYSRPoZrAW0YqCnyG0nzP6zNTkchPCxthJnluZ7zZNceNPXNuCs?= =?us-ascii?Q?dQfTh14fhuneMSvgd4gOP0gP6iSTzOoeVF/q0rrKMEzP+bEznys74HVq2cty?= =?us-ascii?Q?4DxAtrRUYCRCp7h8fqLqjcqJPzwfwN/qsvAadq+s2CYuhw0B+WaRl3JTlLJr?= =?us-ascii?Q?iOebE4uy2kGEsFnnAwJDnyIGwGJPCIDaZUyIkZtMhoNWxgMjEqi+49kSJlrr?= =?us-ascii?Q?yG/DinVW+Ym9dDRhor97xB71/OGVBSj71TlaEgXplVmHtkdx8PTZpH6wFxP4?= =?us-ascii?Q?WUcXaz2fQJkqcRBIbjHo2spkLsoOXHDjqJVQDF6wNTMLqhqRoFUL7kGEx0aW?= =?us-ascii?Q?pBdgRmwlYhqiELJCxzWgFRykGm5wYWgq0dKBs/zgQfbHKkSmAeFhftb09Hn1?= =?us-ascii?Q?upX5KQVinnx65kGXZdUwQOhXKTd3wmW3aPyusOkWzSo7L+jBJ3TVDYhDcy8M?= =?us-ascii?Q?TQUCHdSmJZUlXRNFCGyN/1hvuh94u5llc0zCE42H4Li4oSsWy5w2cuA3Rdqp?= =?us-ascii?Q?AnhipSuSeoU6Rfrb2F+VdWdOgnu9OVUZ25fu8hc6NI5IujSwvy5aiAef4Aiv?= =?us-ascii?Q?NCsGud3ec/EGCvH0SckPhD0Zqu/UojWkBjUYyzK4+zlTThopHs1BCNIE/99R?= =?us-ascii?Q?bjdriG/+W0A5zK0hVQZJjSN1ELCpmHhgFOG6w08FGQaSu1BKZIUkwcOBhMPv?= =?us-ascii?Q?Y1hZXpkZGDH2xsuh/t6IpVf+5xwNgBcMDks4hrUmUG8OBt+0Zzw+G6ZKg5Gz?= =?us-ascii?Q?XxyVoNIuAPIQ+M6Yh+Uy3w+i/zjw1aiTTwSiDQieCLWLvy6KefqLINcQ=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB043; 6:2pkJaFSbqdyWtxHvIqgRia8RIhgBii4fYNjIOTmXFGwyZZaN2jki9X4cW1RRqwf7237gZfYlPdXQZK5C/FGCaEcU8DcnjNqhI5Uhsbj3Reouf6dT+RP0Ywjg28KwjBBQp15OvbHex5KOLlP25lY8UIRFUbBtkJor2P6wBPw1H/Wn4hXbN6smviX5NEnBoPHs/545M42c6TSGmbWFlEaeHJfKFunUN5cUC6NdQKwopRRYnj976dSFfhfRil0PDJ/83w3nphEhEHjcXK2UPyQESGPsXk3YUi5uZ15KB4BjWRv16w8EsXjYnSI3K6S9w4oLZUzcZAcbdAKwZFRl1xLTnsbUq6PoQAx/UGPdpaR/8Uq07tzjTTCGTtcxL41uEA/Tu1WqW6qQjtNcBPyHeNxq1Kw++v3M+EJzMEIUnxcZqx0g7VBqm7nX45fOpF2qKiSxlX+B8S4d9qxsx1ZQVLQBJUEDOUS3i8vSSbnHKmFHPppbpMA39ahQitkhv2ZCnFwbWPcInzD2BDLcTXlysvbrdGOl4F5LMLWUwpjE1wgAT/A=; 5:ncUMV+RAEuW7KcfjFifWExGeT+HT4asZ4ccIpK1BewSKZtaT6viAqEF4X61q/USJbsjgOA/qv0mpz3lFyOyPlDU+Nrrz5XQ6q/WcTWL5WsC67AkC20abRzwu7g7bzkckGSd3WR1oAv4sPz1tCI+waQ==; 24:/rj7y3flFwI0dMSepps4ccPQMFhWVVLDZED6ujAl/gJC6v8Fa9BDuSoFR0CFoZH4NWA5CRLZS3JpjamAbYc6/fZ724XD0CZ7ppLxFhfGL78= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB043; 7:9vM+/30Wt8Sd9ONIASuXZKnUFPu5ICEy+TeZxyGf730hqXW17NdmKqaHiHJLEbhYOH7FZd7f47DYv/ZG81ER02ZNka52cNOAEbpZoLMQLfVVsx1OMOOCMe8cowHFWH2wwgx7uZCLTDLQj+uTWziutn7HRQfpje0HkXACOqtVc4/RvrB+NsuZtfJWX9sdQl8B5y/OSMIwyy4hi4z4mct4SQAx7OsivGUj0tI11HQG7no0PfA0z8zfThkCtTKHDjPfpv/QTu3wGt4tGkidvOusy0PhB3xQQ3qN/3f0eq5tuoFnb8Cx+EHy1qnDjdkrVsxY6uZEic6N5cX9chKz7+xjcg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 May 2017 12:51:26.3997 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB043 Archived-At: Subject: Re: [v6ops] [OPS-DIR] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 12:54:05 -0000 "Joe Clarke (jclarke)" writes: >I've seen some that do (ostensibly). But this if this isn't required, it wasn't critical. idnits certainly complains about it. Thanks, Phil From nobody Fri May 5 08:07:14 2017 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 2F0571294B8 for ; Fri, 5 May 2017 08:07:13 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 XHHgG3q94Yo9 for ; Fri, 5 May 2017 08:07:11 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7400512943B for ; Fri, 5 May 2017 08:07:11 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id u75so7505349qka.3 for ; Fri, 05 May 2017 08:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=VSat03VtkiJ6WqckRb44ND+8a2Qrp51iyfskUbb8Qnk=; b=faLN8Hc4sNnlpbARdU24/b83fnOl12FlzkEst2yg/hCkWeEy5saQ6ErZ0abcPeF7tE nb+4qH8zyy5SAh6w1uP0V7G+jVeDrVsGN/l8MSAAKPygtJxl2Bd9IN4jn1vTQ+/Lok8Q gV3mS2si7y25sTHriWbcDiIhf6GrdZQ7VPQ7yfhV68KPqTrzA70Azn+LwVh0nI+3ZJ/O qEnTwS3OI8WXIwrGSeZXsNGDRnu51AfpLuaPtZd7uR8QRlvZkQbfR2oqHpsOLTT4EHlO vzZXfnGpjMTas9N9nzUEcjVhA3SQXn/lMBqzvXWADs1mQkaFS9aDzMsvO+feoTcccAsY LQ+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VSat03VtkiJ6WqckRb44ND+8a2Qrp51iyfskUbb8Qnk=; b=XCIZnxt2p3dEqwEt40lEAkOPtHghacINylJoZvyVSq8ErsYThvUEgjnrJgtsYTVYel VrAmbcU0G+lvMznYZi31rDuvOJFm/oT48cDLT3/RLMBqLUApXXGgrVRVqasT1/6oDXLx xieMPUabrRZpLgdPN0il7bY4uecpu+NP6xZZGjaJ+z+RzqNftISo803M2nk6hG92giOJ Ab8Gb+gBEC+AGpiPWTvhn9S2p3Hcx4Dd51C6r4Fw2ODaKWiY9zVp5uSx8Jnia9HrL7EV UhROInzAipJdigaIno8z/SkFzOG0J4oApCCeCzUyau0nNX3U1pxS8VCOF14oL0vCL5P/ tYfA== X-Gm-Message-State: AODbwcASLIS/FquhHHHC7Yv1H55neCfrmDX4ThcPIV8ye12Y1jnlU4zH zDVcz1c2KRIi7qQZq26wDbxWABw3eJx5 X-Received: by 10.233.223.134 with SMTP id t128mr14565937qkf.64.1493996830388; Fri, 05 May 2017 08:07:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.171.68 with HTTP; Fri, 5 May 2017 08:06:29 -0700 (PDT) From: Warren Kumari Date: Fri, 5 May 2017 11:06:29 -0400 Message-ID: To: IPv6 Operations , draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org, Joe Clarke Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 15:07:13 -0000 First off, thank you for a clear, well written document. I have completed my AD review, and had a few comments / suggestions. I'd also like to thank Fred for requesting early review, and Joe Clarke for the helpful review. I agree with all of his comments, other than the xref in the abstract -- but, see below on the Updates bit. I've annotated my comments with [C]. W Abstract This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. This document updates RFC6890. [C]: This document updates RFC6890 by ... ? A very brief summary would be good. Actually, I'm not really sure *why* this updates 6890, from what I can see it simply reserves an additional prefix in the registry. If it really *does* update 6890 it should also have a section clearly explaining what changes it makes (including the "new" text). It's entirely possible that I've missed something really obvious here... 4. Why 64:ff9b:1::/48? [C]: I suspect that there may be some feedback during IESG review that this section is really long, and provides a lot of (once published) unnecessary justification -- however, I found it useful and interesting (and likely needed before publication) - just mentioning so you are prepared. 5. Deployment Considerations 64:ff9b:1::/48 is intended as a technology-agnostic and generic reservation. A network operator may freely use it in combination with any kind of IPv4/IPv6 translation mechanism deployed within his network. [C]: If editing anyway, may want to replace "his" with "their" - normally I wouldn't point this out, but apart from the gender issue, network operator could be plural / networks are often owned by multiple people / an org. 64:ff9b:1::/48 or any other more-specific prefix SHOULD NOT be advertised in inter-domain routing, except by explicit agreement between all involved parties. Such prefixes MUST NOT be advertised to the default-free zone. [C]: ... but you *know* that they will leak - what happens when they do? Does this break anything? (probably not, *might* be worth mentioning though) 6. Checksum Neutrality Use of 64:ff9b:1::/48 does not in itself guarantee checksum neutrality, as many of the IPv4/IPv6 translation algorithms it can be used with are fundamentally incompatible with checksum-neutral address translations. [C]: Er?! What is this checksum neutral thing of which you speak?! :-) (I think you need a reference here -- I *think* that RFC6296, Section 2.6 is the closest.) 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. The following non-exhaustive list contains examples of translation prefixes that are checksum neutral when used with the [RFC7915] and [RFC6052] algorithms: o 64:ff9b:1:fffe::/96 o 64:ff9b:1:fffd:1::/96 o 64:ff9b:1:fffc:2::/96 o 64:ff9b:1:abcd:0:5431::/96 Section 4.1 of [RFC6052] contains further discussion about IPv4/IPv6 translation and checksum neutrality. [C]: Oh! Here is the reference (I think 6296 Sec 2.6 is clearer.) 7. IANA Considerations The IANA is requested to add the following entry to the IPv6 Special- Purpose Address Registry: +----------------------+---------------------+ | Attribute | Value | +----------------------+---------------------+ | Address Block | 64:ff9b:1::/48 | | Name | IPv4-IPv6 Translat. | | RFC | (TBD) | | Allocation Date | (TBD) | | Termination Date | N/A | | Source | True | | Destination | True | | Forwardable | True | | Global | False | | Reserved-by-Protocol | False | +----------------------+---------------------+ The IANA is furthermore requested to add the following footnote to the 0000::/8 entry of the Internet Protocol Version 6 Address Space registry: 64:ff9b:1::/48 reserved for Local-use IPv4/IPv6 Translation [TBD] 8. Security Considerations The reservation of 64:ff9b:1::/48 is not known to cause any new security considerations beyond those documented in Section 5 of [RFC6052]. 9. References 9.1. Normative References [SNIP] [C]: IMO it would be better to have the Acknowledgments section as a numbered section, not an Appendix (I'm not sure if this is actually required, but is, IMO, better form). Appendix A. Acknowledgments The author would like to thank Fred Baker, Mohamed Boucadair, Brian E Carpenter, Pier Carlo Chiodi, David Farmer, Holger Metschulat and David Schinazi for contributing to the creation of this document. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri May 5 13:12:03 2017 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 B79E5124217 for ; Fri, 5 May 2017 13:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 xBFCn2CFnV9j for ; Fri, 5 May 2017 13:12:00 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 F0EFC12869B for ; Fri, 5 May 2017 13:11:59 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id q66so7237430pfi.3 for ; Fri, 05 May 2017 13:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=4gykqvaepFSaoDhygzLNQGuVMuqXeHe2Vik3rSL71P0=; b=BXkBVjMitxso4XryagLfHTV3M2FF94yILK1GapbaVUgr8hJbjkeLsAGYAokzrD6mCj HBI58mSipIdlKAt1B505OLM6e7qjJhsacxZVaCpr3DC3Y8C6VkWNAaqL2jqF/6hvKaxr aX7KFoLcFqOWE6+34JNF5wqa/1GhRL9EyHfLuNsdIHx1tepKCCjN8MYaCFs/CPq+8kIf wYtvOOOJi9j1rGm8St7nZzb1+Z84r8IzHSc7LxI7rbX0V9VW+Jq09eJEWSxidKqFE7cA D96EztwB3dU1gnO3bqWpRqb41aF0/gN5qmefo2lY0o1ShkmIBce8iysCwXYVUd27wEyV TyZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=4gykqvaepFSaoDhygzLNQGuVMuqXeHe2Vik3rSL71P0=; b=ZUILoHcRomS6Xn48Qu1QBa8sFPCgC/VmqqFl2EfwrZqr+qLNGClhexigoBu2BsnOxe KJjmcOr12Wfw6P2aKEBE6HCQbexosTdxBIOEwx8sxrvKkVUE74DJjoqiO6ts6OYbPhBL XnnOYB0uN7TjSmqAHJQLUb1QzsjSKEkjNepO5AhwyE70famUXrzlInqG6XoLgFPvsj8I yjAgj4+N3yGKo3OovDYWEavLoIPIv+m4dEwpA1rv3y2t5WTkNlnGI3PWo8Qs+RZc7BIE TY1VOyiq/DhdTg2QC9XynMVTCIk8UfkqplRJSTVesUAsuB5FoECahn7VV/XDDAEzNAEQ q1Mw== X-Gm-Message-State: AN3rC/5WeL4gI1pgw+uhp/fUM6KVHiyG9Urwf74R64TzMoT+dzP92pp3 kEiZDH6v0bng36Bll3I= X-Received: by 10.98.66.212 with SMTP id h81mr18958679pfd.182.1494015119463; Fri, 05 May 2017 13:11:59 -0700 (PDT) Received: from ?IPv6:2406:e001:506d:1:28cc:dc4c:9703:6781? ([2406:e001:506d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z5sm12388462pff.73.2017.05.05.13.11.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 13:11:58 -0700 (PDT) To: IPv6 Operations References: <149400889554.8520.7151475257014654925@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <59385bfd-d2d3-98e1-a0ae-7f6a16eb2cd9@gmail.com> Date: Sat, 6 May 2017 08:12:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149400889554.8520.7151475257014654925@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-v6ops-ipv6rtr-reqs-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 20:12:02 -0000 Was this meant to be draft-ietf-v6ops-ipv6rtr-reqs? Regards Brian From nobody Fri May 5 13:22:06 2017 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 09606128BB6 for ; Fri, 5 May 2017 13:22:05 -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 iiduP3jysqSD for ; Fri, 5 May 2017 13:22:03 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 86894124217 for ; Fri, 5 May 2017 13:22:03 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id e64so7375242pfd.1 for ; Fri, 05 May 2017 13:22: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=tBDaPVZh/FsVhHKyEWe65Jjr4NJjnzu8ossCQ4N7Z2g=; b=c+kQAtK4g47F5izqB5K98omwwR//vODp7PLaV77pyHo8ccsQNd7xAkKJg+POSNO7Hw dQfx9VGvSJZRbxseZhz7P0Uw9zNvM8GhUnBq8muL/KA7Y1HD54Fj7sxHBDzwLbWGXn35 ihSBOPRu8rDszTDAvKc2HtA/oUeVblKRBuZ2TMNVp6YNro3Xlv0Z01U1k+u3BNn4vzjW yhABBvO6mRyOgTma3/q4ve3Othj5Fw8e1/LVYn8uqkkQbLs5NbGThpfOnOpyKFEo0T64 ocNj37ysK8GGErWkxiK+ZuKKhMStRdIrjoeLtomnEtI+GEerS6XFu3CE31F/3ByZ+TUP 3UwQ== 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=tBDaPVZh/FsVhHKyEWe65Jjr4NJjnzu8ossCQ4N7Z2g=; b=FDD+68kv0bKGTJRAVv6jjwmJ0UNVHLNBOJCX/acJ6iIM1VHMnApi4EuhLcjZI7cBSF AnNw7ut8DDxYSzKIWrYOa7l8UXug+rf/7Lhh6cH1MKyjW+j9pFesWXJ+Dg2drsWOOFHz ORqXkBigBuBDIPbCNFoU68eI7ZXy0xKBo6V24vdt2xs5d72GZi54lxv1yzpTXR6tnbOw kHnIkTSb1I3TXaOaBOyZbr71Ibh4gUvITWLVkeo2Wx6FVdRtPA+Rm64uE7+2w+Jp9lY8 qQcwbzNqhmwlKP7iM72w1K76CYgVuohpzDNMAPNqcMSV2DpD8fRPpdkxmics1QME+3N3 8D8g== X-Gm-Message-State: AN3rC/4PgY42HBokfOCZhe1JHUYBMmGXSPgAAQqD9jJuPHvQn6AQjUyO 1nKBLO3SnHGoZQ== X-Received: by 10.98.98.66 with SMTP id w63mr19060895pfb.44.1494015723202; Fri, 05 May 2017 13:22:03 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id s65sm5217847pgb.34.2017.05.05.13.22.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 13:22:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <59385bfd-d2d3-98e1-a0ae-7f6a16eb2cd9@gmail.com> Date: Fri, 5 May 2017 13:22:00 -0700 Cc: IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: <566A84A4-2352-4DB0-A0E6-BC39502276E5@gmail.com> References: <149400889554.8520.7151475257014654925@ietfa.amsl.com> <59385bfd-d2d3-98e1-a0ae-7f6a16eb2cd9@gmail.com> To: Brian E Carpenter , Russ White X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-v6ops-ipv6rtr-reqs-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 20:22:05 -0000 Yes, it was.=20 Russ, would you please refile as draft-ietf-v6ops-ipv6rtr-reqs (which = fits the naming conventions in the IETF guidelines for draft authors and = is the name I authorized as a working group draft), and note that it = replaces draft-ali-ipv6rtr-reqs and draft-v6ops-ipv6rtr-reqs (removing = them from the draft directory)? Thanks. > On May 5, 2017, at 1:12 PM, Brian E Carpenter = wrote: >=20 > Was this meant to be draft-ietf-v6ops-ipv6rtr-reqs? >=20 > Regards > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri May 5 13:28:17 2017 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 AA819124217; Fri, 5 May 2017 13:28:15 -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 fC-pZ_CKLQy9; Fri, 5 May 2017 13:28:14 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 2CAA01200FC; Fri, 5 May 2017 13:28:14 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id q20so7461052pfg.0; Fri, 05 May 2017 13:28:14 -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=rzdVPSg7TSFWTO7VKxVsKx1kQWvi+iE+JHHAm2dSZyg=; b=i5w8du8wdYrdVr2kceLTZv534jzd5iqY8HUJEKvJXCEW8kzIslm0EhlQaADPnrVIQL bm74s+yiKKPk4Uu3u+ScYM1SUnHUyjPmprwiER3V6dGIEGTTfyh6j4t22uPlYKASiyM+ mDHETy4s3Ag15qx1qRaYUEX4akw1NKSXeO3Mli2wSbZ0qMM+1aEYL1Cjnedm0OM9FNhR GxeTdAifUpX+FC/xkvuvWVrLZ4lmZZLDE1vQ3KDZT1LcurR6MGt9/Ck7fuShHkL1t3Ph 6crFDw8tidWclX+1yZhDfIos5hH7e3g2C9QmPWaHvvxSzFC9/kYv5j6l0jAHbd1MSnoL YmHg== 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=rzdVPSg7TSFWTO7VKxVsKx1kQWvi+iE+JHHAm2dSZyg=; b=bQlCHLy4qwwpkxiT0gIcZqvoUP4QhbfKzCdn8a0Q4ir/9f2Nh66hBVs8jLJXS3SdTk 9xfxsNh15/ji7/2LznF88MwAQixMZ+gkBWWhFfNNlpNyMQlY6ZE70PR6DRzkggazwIpi /vWAPmMOZxafawo5QYaN6UG7Ti/f0pInWApJk2G6DJG0g1rMKgd1WuUQGWqO36fyl0vL xs5CZ0NV20Cel08bV8gNR5l12SCylgg21kTM28WNZMTMWpLdcFxjEl4y/si2que6Jnj8 lRt87p3pSijWzokoxHHRqY2bHanV5fHuRAJZwbg9gZi891/qFcztFRBNKNcYZqkqXWTD MtJA== X-Gm-Message-State: AN3rC/7bWgCSs0ouDjE4PEDRtJw5i/KN0Id1Iau8JPd1xv3lbpAE+cuf FbQmzrTEjAJzNQ== X-Received: by 10.98.193.65 with SMTP id i62mr6517263pfg.134.1494016093782; Fri, 05 May 2017 13:28:13 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id r1sm2965669pfj.68.2017.05.05.13.28.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 13:28:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: Date: Fri, 5 May 2017 13:28:11 -0700 Cc: IPv6 Operations , draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org, Joe Clarke Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 20:28:15 -0000 > On May 5, 2017, at 8:06 AM, Warren Kumari wrote: >=20 > First off, thank you for a clear, well written document. > I have completed my AD review, and had a few comments / suggestions. >=20 > I'd also like to thank Fred for requesting early review, and Joe = Clarke for > the helpful review. I agree with all of his comments, other than the = xref in the > abstract -- but, see below on the Updates bit. >=20 > I've annotated my comments with [C]. >=20 > W >=20 >=20 > Abstract >=20 > This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use > within domains that enable IPv4/IPv6 translation mechanisms. This > document updates RFC6890. >=20 > [C]: This document updates RFC6890 by ... ? A very brief summary would = be good. > Actually, I'm not really sure *why* this updates 6890, from what I can = see it > simply reserves an additional prefix in the registry. If it really > *does* update 6890 it should also have a section clearly explaining > what changes it makes (including the "new" text). It's entirely > possible that I've missed > something really obvious here... Tore and I had a conversation about that, and came up with a possible = solution. The argument for "updates" was that it creates a prefix that = 6890-next should include. But the next question, and the context of our = conversation, was the status - "standards track" vs "BCP". I argued that = if the document updated a BCP, it should be a BCP. Tore argued that the = prefixes 6890 reports are all in standards track documents. Our outcome, which I wonder if you would buy, would be to drop the = "updates" aspect, but make this a "standards track" document that = 6890-next might refer to as it does other standards track documents. = Does that work? I'll leave the rest of your email between you and Tore.= From nobody Fri May 5 13:37:05 2017 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 3DF0212947B for ; Fri, 5 May 2017 13:37:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 N4D-obkw3Ia3 for ; Fri, 5 May 2017 13:37:02 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 9BE7112944E for ; Fri, 5 May 2017 13:37:01 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id m36so14544215qtb.0 for ; Fri, 05 May 2017 13:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hcuwIaxKJq7HlTIBiVYK4OcEFpFjL9LdowHSXwr/1Pc=; b=zeIU5Ny0ZXMKvsPP3/OhghtPeDl/nBUPwi+J60k/21uP9kUCmbgxE01JvyGX5AvbIL Zsep1OusMJJTWAncymhZCKDQJnDK/XBFCDg6OSNuUUfJ00WEWJvKX6LskODsIvlbUbvk LOSAjVNIr2KZS6PNHY5myLY5wmzAls0f7WnVgb2gWxrh3kYbYakd3xSahg4oNNFKSDQO 8eOm3U0NmyceQCN/eRoOSZ82r/Gs+Rw8xjlSVH1uXt42scoIazv2ZXeg0Hfuma3mbN8v /Gw06WHEkfdO+qEgTMjiv5Xt1mZi2oNEliWqPJz8R6r+8Ms/nUU+Q4xbVmlK3IhzOrTF 4OBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hcuwIaxKJq7HlTIBiVYK4OcEFpFjL9LdowHSXwr/1Pc=; b=V+uV9kabyA/WJSGG3sYD3gKrvCSq/AkbQHvmuw7pxrvNV6iKk3VdH0oXz8PAtk88Ld Rm51m5b7/7tac1lTvvjXTwKOL0dJiv6313AYwhL9tYtlQDJrSRxCCg3C7kyPLXQLGMbw iph18MCNrMLjzfzDMvn4hbjPKdiKngdpnZawwSYVKoWZLA7VD8rDI33HsJxa9OrH6pxS MkML8bhLn1BhuzexxQ29oyFZ7Y71Yg0H94Mcl0bcORAgeYPJPS22A2uR60sgr6gIEgoT vuU9b3Ndc3d4N2cvjM2HPduTJXZg2PZSX+49PfqbMtV4YbNNMyuQOxWW/8zNDsnbzD1k mOvA== X-Gm-Message-State: AN3rC/7PvzCbwK9RX+5z+2cXBNuq8Dh/a+16o63SRm+KDbw/DsHSKdAn uy+Tmx+szkWOXTQhATYnoV3K9xweb2KliQjGNQ== X-Received: by 10.200.45.204 with SMTP id q12mr46748126qta.235.1494016620683; Fri, 05 May 2017 13:37:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.171.68 with HTTP; Fri, 5 May 2017 13:36:20 -0700 (PDT) In-Reply-To: References: From: Warren Kumari Date: Fri, 5 May 2017 16:36:20 -0400 Message-ID: To: Fred Baker Cc: IPv6 Operations , draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org, Joe Clarke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 20:37:04 -0000 On Fri, May 5, 2017 at 4:28 PM, Fred Baker wrote= : > >> On May 5, 2017, at 8:06 AM, Warren Kumari wrote: >> >> First off, thank you for a clear, well written document. >> I have completed my AD review, and had a few comments / suggestions. >> >> I'd also like to thank Fred for requesting early review, and Joe Clarke = for >> the helpful review. I agree with all of his comments, other than the xre= f in the >> abstract -- but, see below on the Updates bit. >> >> I've annotated my comments with [C]. >> >> W >> >> >> Abstract >> >> This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use >> within domains that enable IPv4/IPv6 translation mechanisms. This >> document updates RFC6890. >> >> [C]: This document updates RFC6890 by ... ? A very brief summary would b= e good. >> Actually, I'm not really sure *why* this updates 6890, from what I can s= ee it >> simply reserves an additional prefix in the registry. If it really >> *does* update 6890 it should also have a section clearly explaining >> what changes it makes (including the "new" text). It's entirely >> possible that I've missed >> something really obvious here... > > Tore and I had a conversation about that, and came up with a possible sol= ution. The argument for "updates" was that it creates a prefix that 6890-ne= xt should include. But the next question, and the context of our conversati= on, was the status - "standards track" vs "BCP". I argued that if the docum= ent updated a BCP, it should be a BCP. Tore argued that the prefixes 6890 r= eports are all in standards track documents. > > Our outcome, which I wonder if you would buy, would be to drop the "updat= es" aspect, but make this a "standards track" document that 6890-next might= refer to as it does other standards track documents. Does that work? That works for me. My reading of 6890 is that its purpose is to restructure / update the registries. New registrations can simply be requests to add to the registry. If there is another restructuring (or a respin of 6890) it would incorporate / reference everything in the registry. So, yes, the current Proposed Standard seems right, just drop the "Updates" bit and all is good... > > I'll leave the rest of your email between you and Tore. W --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri May 5 15:01:23 2017 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 B5E83126E64 for ; Fri, 5 May 2017 15:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 O30XMwG321qE for ; Fri, 5 May 2017 15:01:20 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D75D126DC2 for ; Fri, 5 May 2017 15:01:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8842E209C0; Fri, 5 May 2017 18:01:19 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 05 May 2017 18:01:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=Nl9AQsk0fcWH8Xs1aZGordFrB2O1beUv4shi9Xtljnk=; b=no2rqLo9 AnXnLpPS9MU5YYu0a8ps/z/S0dsC3GmkWjHVwp+4t12L5YeiZQAHR93ZW6AqsV3H FP8NYPgoWdSatIGrPCf+ASRJGm6OsXTkmYWuTHc804M/bVwL0e4pdiSgVRA1TnSQ yhyzOKbB0XPJ18Iy1YOXWSgRWI7dRsZygqNIWEPTNIpyKl9gHv1uklvUZA380LJh 2kJiOTgiej++7Rlk+48L2rakREEeis8pGZWdB3soxi0cYqV6/z6/GfaTQ6epIUm/ L2uB4A7CbCsmrhhbd6GvHvrNz7qHxdDIWxtFI8Qp+OgI7dUnEfJPxdr7sVuoUFlD DdPpqvVFSO3oeg== X-ME-Sender: X-Sasl-enc: qLzR5GW+8wkVO6hB7ACQwo/uBT3b+wgJeCKnUzdubuOQ 1494021679 Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net [108.78.210.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 733B3248B8; Fri, 5 May 2017 18:01:18 -0400 (EDT) From: "Russ White" To: "'Fred Baker'" , "'Brian E Carpenter'" Cc: "'IPv6 Operations'" References: <149400889554.8520.7151475257014654925@ietfa.amsl.com> <59385bfd-d2d3-98e1-a0ae-7f6a16eb2cd9@gmail.com> <566A84A4-2352-4DB0-A0E6-BC39502276E5@gmail.com> In-Reply-To: <566A84A4-2352-4DB0-A0E6-BC39502276E5@gmail.com> Date: Fri, 5 May 2017 18:01:16 -0400 Message-ID: <014401d2c5eb$1fae51b0$5f0af510$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKgQPo00LwwVzd9mpoTFIJjTX5o0QIlwaJUAa6vh1qgLLCnsA== Content-Language: en-us Archived-At: Subject: Re: [v6ops] I-D Action: draft-v6ops-ipv6rtr-reqs-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 22:01:22 -0000 > Russ, would you please refile as draft-ietf-v6ops-ipv6rtr-reqs (which = fits the > naming conventions in the IETF guidelines for draft authors and is the = name I > authorized as a working group draft), and note that it replaces = draft-ali- > ipv6rtr-reqs and draft-v6ops-ipv6rtr-reqs (removing them from the = draft > directory)? Done. =F0=9F=98=8A /r From nobody Fri May 5 15:01:36 2017 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 55E58128C82; Fri, 5 May 2017 15:01:34 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149402169430.8512.11192508581005769547@ietfa.amsl.com> Date: Fri, 05 May 2017 15:01:34 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 22:01:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Requirements for IPv6 Routers Authors : Zaid Ali Kahn John Brzozowski Russ White Filename : draft-ietf-v6ops-ipv6rtr-reqs-00.txt Pages : 29 Date : 2017-05-05 Abstract: The Internet is not one network, but rather a collection of networks. The interconnected nature of these networks, and the nature of the interconneted systems that make up these networks, is often more fragile than it appears. Perhaps "robust but fragile" is an overstatement, but the actions of each vendor, implementor, and operator in such an interconneted environment can have a major impact on the stability of the overall Internet (as a system). The widespread adoption of IPv6 could, particularly, disrupt network operations, in a way that impacts the entire system. This time of transition is an opportune time to take stock of lessons learned through the operation of large scale networks on IPv4, and consider how to apply these lessons to IPv6. This document provides an overview of the design and architectural decisions that attend IPv6 deployment, and a set of IPv6 requirements for routers, switches, and middleboxes deployed in IPv6 networks. The hope of the editors and contributors is to provide the neccessary background to guide equipment manufacturers, protocol implemenetors, and network operators in effective IPv6 deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6rtr-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-00 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6rtr-reqs-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 5 15:42:18 2017 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 D839E126DC2 for ; Fri, 5 May 2017 15:42:16 -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 I4IYn1OWKsr4 for ; Fri, 5 May 2017 15:42:15 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 937C1120227 for ; Fri, 5 May 2017 15:42:15 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id u187so704980pgb.0 for ; Fri, 05 May 2017 15:42:15 -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 :to; bh=6oEarRemE6RBblBL37Q/GacAaK35BD6n9yrTUK04pqI=; b=EQQK/nZTlWFLQQlEyhRLe/NRGHyJrrqT7r5svfs9rWnMERZu5YdHy/svE++U09u1Ug 0fdnX3si6EFRbXCxA/MH6KIOaBcL8Tdv/uzFuTHRORAdBCFgRtIeubzlcTHElSl6wsIl qJnnZVSkaLNDlU+MoU4n2N2f1b34v+TvfmLJvQbSZ63VBq0+aJ0YkPjE9veaoa3BwiMJ sQ/sA3UvHouTOUvUP6UyAoybdqfFlEj1oyiHM7reOhrjvhyc9LBA7enANQxYfvlMNfXj qcbpSrrPYTfqwHYRKyfDW4BXnkusKL1vq6UuoX82RicaQ8WFLHxnWzYtbNMy6LWjqHT/ FOXg== 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:to; bh=6oEarRemE6RBblBL37Q/GacAaK35BD6n9yrTUK04pqI=; b=eIapnDLP7vHdoH29KlrlptsniP37xMYcc+jsAbNY+mKUTMe89wSlYII/sbONai7zLP x3EgDaba3TRMdNIK1X60t+So6gB5aPpfOjFdlMxWxi46mbQANP3jAKfPjwIuAiZHN6Nz JrguHCINmut7FuIE4kOGk5aW4a/rWsbcINfO2HCBPFRRjhNudxiVRqwbAhRMp/40Nqc+ 4ov7jczpV0IzysESZ1W1bZPPWEqxViKKAHi2ga88/R+E6lP9ykeTS39gk5yNSRfD1wnV 4Slzrbr2SGRyJcRwwqJFziL/VNVlPnVlZK7YosmqsvLil+DQU/88DPHKqLWh6FOw3WGc Yv0Q== X-Gm-Message-State: AN3rC/7b/yS961IfO63oQsc+Z11jqKuGATd+dMToXfYN/bKf8lNBmvxr mppJ+CAqf5MSlkWQp/g= X-Received: by 10.99.111.1 with SMTP id k1mr6105300pgc.194.1494024134546; Fri, 05 May 2017 15:42:14 -0700 (PDT) Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id z62sm4298003pgb.1.2017.05.05.15.42.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 15:42:13 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <1990BCB7-764C-4115-ACEE-40D1931F4B0D@gmail.com> Date: Fri, 5 May 2017 15:42:11 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] State of play as of today X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 22:42:17 -0000 FYI... IESG: AD Evaluation 2017-05-04 draft-ietf-v6ops-v4v6-xlat-prefix WG: Unupdated WG Document 2017-03-13 draft-ietf-v6ops-ula-usage-considerations 2016-11-13 draft-ietf-v6ops-design-choices WG: Updated WG Document 2017-05-05 draft-ietf-v6ops-ipv6rtr-reqs 2017-04-12 draft-ietf-v6ops-rfc7084-bis 2017-04-10 draft-ietf-v6ops-rfc6555bis WG: WG Consensus: Waiting for Write-Up 2017-04-11 draft-ietf-v6ops-unique-ipv6-prefix-per-host Individual Submission: Unupdated 2017-03-27 draft-templin-v6ops-pdhost 2017-03-13 draft-gont-v6ops-host-configuration 2017-03-13 draft-petrescu-v6ops-ipv6-power-ipv4 2017-02-24 draft-shi-v6ops-caba 2017-01-28 draft-xli-v6ops-cernet-deployment From nobody Fri May 5 18:27:42 2017 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 BA6F1127B60; Fri, 5 May 2017 18:27:40 -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 aaRNare7aVAe; Fri, 5 May 2017 18:27:40 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 DC7ED1270A7; Fri, 5 May 2017 18:27:39 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id u26so2521207pfd.2; Fri, 05 May 2017 18:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OKiosY01z5PzQACsaUDif+zsEk9wM4ICNvwCKoKFUmY=; b=DtroJX23rfCVFCdgDbxzeImkpYP6tSLtIq9TLi7I4L8ibN/d0gGOD2+1i06MOPeDJx Zh8FFqsUDx+QUuBzZrVz1DJuIpwJzxRReiZr6aaiOowRMpptuWoWiLdURJwJmORKCuoF hSdjslLYzOcageCFLt+T7uMxw+pGSPl5KLjbhT3ELJH2kPU+Bh8lX3yCCSaGvc8XXciU /E6LtABJmWYQhlrg94tzxUjz8Hsz6lc0jphDRC5C6aeruH7JtKZpl+iPqgl1QDzCmixU XpfWjGqZ1X27RtJzBFuGoG3tcR7dG16t9BKwrk4nsmY8E/1dOYUyl0xvRiKUIiuj8+RS pTjQ== 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:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=OKiosY01z5PzQACsaUDif+zsEk9wM4ICNvwCKoKFUmY=; b=O4kcJa6TZr7j9gVnLuWR6FZv/quwHSTDwjpXGGKGniTsLX/6ui5C8emqzqdVvQYE3j 3Jq3EaxfuGTuczHPz/qkKn1aCRrnWwidyzk9Y9N0wr+IgvMXna0EyWw+hOMiiLQOWo1r hTlb4rdknVpoFlm8bEiEYvbyclFcoDbKLq64ed1z3xLBXGn23LQd3KiGRE7JHhUnLv4K +NYeHDQm2cGqawiVeUScswFzaayiIyb4hsGtToMT8SDAl+eoo3uvlco2fwB7xOeT5hLx fyQ9U0E1dsLYxMMTlzhLMZA6aAPhVAuimZmrUauCKHDZl4Izc3T3whk3CPTr+vTs9oT7 fHfA== X-Gm-Message-State: AN3rC/4nWz/H1kSau0zAfLQfi3Xfzeq2+eAEB2nJsjffXcYwLEgA9CPJ W3c4Aej7apgxkA== X-Received: by 10.98.23.78 with SMTP id 75mr10192943pfx.30.1494034059562; Fri, 05 May 2017 18:27:39 -0700 (PDT) Received: from ?IPv6:2406:e001:506d:1:28cc:dc4c:9703:6781? ([2406:e001:506d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k198sm4758918pga.54.2017.05.05.18.27.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 18:27:38 -0700 (PDT) To: Warren Kumari , Fred Baker References: Cc: IPv6 Operations , Joe Clarke , draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <54650a62-083d-808b-1ef4-6bce31db0ab3@gmail.com> Date: Sat, 6 May 2017 13:27:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 01:27:41 -0000 > If there is another restructuring (or a respin of 6890) That would be draft-bchv-rfc6890bis which is now "Approved-announcement to be sent::Point Raised - writeup needed" so all this needs to be updated accordingly. Regards Brian From nobody Sat May 6 11:49:39 2017 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 B2426127201 for ; Sat, 6 May 2017 11:49:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 sK4Rq-2lFoba for ; Sat, 6 May 2017 11:49:36 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 7E0F51201F8 for ; Sat, 6 May 2017 11:49:36 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id e55so23391477uaa.2 for ; Sat, 06 May 2017 11:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uslv21fdnD85VkiQOjoXL2olIxP+53OOKNP2KOCehSE=; b=YeCgAlO5asRZ4HJQ0/IixCmi2jUF6bwkNUVgyZRDQVVBVENj3OVFPK9UR5SKvJDUqr fv7aM3ZoEruT+Vjw0LAjUOCabMrhe/9yXqyQFO3FLsPJE/jybcXlE74CTJo0MfU5DTiZ NdGLM3b77oDpUjdjtmE0A37onzNV0+oOSydxF0Y10cUjvNXnvI1O0Q+CBHxsFOabLY6s 9qp7OKFF/wQpDg125lLyiW+Eu0Dx0mqA4Z8O9g9hKTmuuD5rwQM/B91Yp4guIRj+kGLT uu6ljKV9wBw/nESsAH9MGpLlj+8tLffYB9geI6sRxX1L59b4GuxO6Jkd9R3Qj0hwmujd nGGw== 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=Uslv21fdnD85VkiQOjoXL2olIxP+53OOKNP2KOCehSE=; b=UtFLIAqESNY5DF1/teLnSZqPVPxBNlQRHit/zkvmidg3sa/EeSKjdyHgyDM2RxKvEv HV8J/CYMdlznMcC4U406u2RqqXKzTbv+lO7RbeOeZnq4nLPKYtrsHRT1J3iH7gjD7l+J z+tkBL8l+WGdkL4vlECNyGAogoiTzZ5jXX26/ppx2Dvy1bNSG5ERYelkRAja5ve0whNK HOUQYgZ1tEoTzX+EYd/mf9GIRHEyz+ircCsYlyRucmEJYJ7ICNo9dFT/jXBw3V4rSrKU jpqmjoaEWZYxXMQksS9w3c8vU1QktXr1oDxgawU/jXBrUBEhh1+a3+Enh7nYKun9DIdd yKTQ== X-Gm-Message-State: AODbwcBbWFt64p8fcNzk0baVj76DqVeQgX4k0nrNt39aWtbWBezNS6E5 II/KSKOnK3wLPoNiYU0TIgk3+L5d11Wq X-Received: by 10.176.74.212 with SMTP id t20mr1413617uae.89.1494096575667; Sat, 06 May 2017 11:49:35 -0700 (PDT) MIME-Version: 1.0 References: <54650a62-083d-808b-1ef4-6bce31db0ab3@gmail.com> In-Reply-To: <54650a62-083d-808b-1ef4-6bce31db0ab3@gmail.com> From: Warren Kumari Date: Sat, 06 May 2017 18:49:25 +0000 Message-ID: To: Brian E Carpenter , Fred Baker Cc: IPv6 Operations , Joe Clarke , draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org Content-Type: multipart/alternative; boundary=f403045f8fcca75589054edf7786 Archived-At: Subject: Re: [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 18:49:38 -0000 --f403045f8fcca75589054edf7786 Content-Type: text/plain; charset=UTF-8 ... sob... Yup. W On Fri, May 5, 2017 at 9:27 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > If there is another restructuring (or a respin of 6890) > > That would be draft-bchv-rfc6890bis which is now > "Approved-announcement to be sent::Point Raised - writeup needed" > > so all this needs to be updated accordingly. > > Regards > Brian > --f403045f8fcca75589054edf7786 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ... sob...

Yup.
W
= On Fri, May 5, 2017 at 9:27 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>=C2=A0 If there is another restructuri= ng (or a respin of 6890)

That would be draft-bchv-rfc6890bis which is now
"Approved-announcement to be sent::Point Raised - writeup needed"=

so all this needs to be updated accordingly.

Regards
=C2=A0 =C2=A0Brian
--f403045f8fcca75589054edf7786-- From nobody Sun May 7 19:11:12 2017 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 D9EC1128DF2 for ; Sun, 7 May 2017 19:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 sX8mhVFAupz1 for ; Sun, 7 May 2017 19:11:10 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 2AB621293EC for ; Sun, 7 May 2017 19:11:10 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id v20so21356093vke.2 for ; Sun, 07 May 2017 19:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=N7GUUUthjbPJ/+OXEreLDTYvk+LhnnmM4Ykbev3JYiQ=; b=ZT+NlKL9gVUOW++XR2w6JOny+j2AvzwOrg9dzek+0K7cB5IvhucAcutCAdISpOpxhy gZweJ+BP5GQOGEkj+PsMqe/SO0FDixaHL0B/K8m2mgZS22U9iCEhnhXM6G3eFYpIrQVq //aXOKe6lsWLCrO6NTDbBmNwBhptM7B5fVeGMrHSAjcNNRdh9MSLmQCtU95lk6veRFQM BWjANKZI/mmm0gMU5g8o9lmONr5VzHJ37JzFi8FuH5xfJL4yBBjcafG2xMV9JNo6PpPe gP90XZRWTmrlVW5vjgzKGRVTSXWhZH2l9MM+jYRf3nDX0w+atceOgTj2W3QQRvqk/ROn 0PUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=N7GUUUthjbPJ/+OXEreLDTYvk+LhnnmM4Ykbev3JYiQ=; b=Qr7Zb9bGMbqysiUrC8hXxMoOKjUIPyB0w3XWZaMPKznLUfcNDLDQS7I6MuTtAYWhcW MsiYSJjF3mHMV54T1cc7iLmRJmxLepVa7y/SSft33Au1ozWeGp3YFFyoGFnZiw/3Erb6 /RNTpoALK1LTLVZP3rG1lHEZqQNkpYF9byK8xRsf9XMqQBn8xet2215yQmRu1Q5HOxi2 SHksUCPJfp84b9OvZ3F6jwDcKY4enmv4PaFT4hsXJeN+aQIwBAMwSMVpy0OrJst0XEBG HiyNPY25iBcIrEi7Qucs8XQUTf3iX2Dd6JYkwDSnKTHSkzMtibikGqbIRDPR1hxub48j l5EQ== X-Gm-Message-State: AODbwcAOYo4q7CDMR/34/ZAwiIFqe7rPaMe6vuT2+/pF7Xb8z+xVVsEP F3+xD+UjBLa7a3fbuAbob7pswLtx2Jr+/vrJ5A== X-Received: by 10.31.12.204 with SMTP id 195mr7383794vkm.18.1494209468747; Sun, 07 May 2017 19:11:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.148.145 with HTTP; Sun, 7 May 2017 19:10:48 -0700 (PDT) In-Reply-To: <149402169430.8512.11192508581005769547@ietfa.amsl.com> References: <149402169430.8512.11192508581005769547@ietfa.amsl.com> From: Lorenzo Colitti Date: Mon, 8 May 2017 11:10:48 +0900 Message-ID: To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary=001a114558b49b432f054ef9c09c Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 02:11:12 -0000 --001a114558b49b432f054ef9c09c Content-Type: text/plain; charset=UTF-8 On Sat, May 6, 2017 at 7:01 AM, wrote: > Title : Requirements for IPv6 Routers > Authors : Zaid Ali Kahn > John Brzozowski > Russ White > Filename : draft-ietf-v6ops-ipv6rtr-reqs-00.txt > As Ted has stated many times, this text: ====== Routers supporting IPv6, and intended for user facing connections, MUST support: o [RFC3646]: DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). ====== needs clarification. Does it mean that: 1. A router MUST contain a stateless DHCPv6 server implementation that supports the DNS option? 2. A router MUST contain a DHCPv6 relay implementation that supports the DNS option? 3. If a router contains an DHCPv6 server or relay implementation, then that implementation supports the DNS option? #1 or #2 would be a change to the IPv6 node requirements, which say : ==== support for DHCP server functionality on routers is optional. However, routers targeted for deployment within more complex scenarios (as described above) SHOULD support relay agent functionality ==== I don't think it makes sense to say #1 or #2 and thus say that all IPv6 routers MUST support DHCPv6, because: 1. Other than for home gateways where DHCPv6 is required, I'd expect that the vast majority of routers don't actually support it at all (at least not in all feature sets). 2. In most places in the network there's not even any point in supporting it, because it will never be used. DHCPv6 can only ever be used in routers that serve as first-hop routers for hosts, so a backbone router will never need a DHCPv6 server or relay. #3 does make sense. --001a114558b49b432f054ef9c09c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, May 6, 2017 at 7:01 AM, <internet-drafts@ietf.org> wrote:
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Requireme= nts for IPv6 Routers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Zaid= Ali Kahn
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Brzozowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Russ White
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-ipv6rtr-reqs-00.txt

As Ted= has stated many times, this text:

=3D=3D=3D=3D=3D= =3D
=C2=A0Routers supporting IPv6, and intended for user facing
=C2=A0 =C2=A0connections, MUST support:

=C2=A0 =C2=A0o =C2=A0[RFC3646]: DNS Configuration options for Dynamic Ho= st
=C2=A0 =C2=A0 =C2=A0 Configuration Protocol for IPv6 (DHCPv6).=
=3D=3D=3D=3D=3D=3D

needs clarificat= ion. Does it mean that:
  1. A router MUST contain a stateless= DHCPv6 server implementation that supports the DNS option?
  2. A route= r MUST contain a DHCPv6 relay implementation that supports the DNS option?<= /li>
  3. If a router contains an DHCPv6 server or relay implementation, then= that implementation supports the DNS option?
#1 or= #2 would be a change to the IPv6 node requirements, which say:

=3D=3D=3D=3D
=C2=A0 =C2=A0support for DHCP
=C2=A0 =C2=A0server functionality on routers is optional.=C2=A0 However, r= outers
=C2=A0 =C2=A0targeted for deployment within more complex s= cenarios (as described
=C2=A0 =C2=A0above) SHOULD support relay a= gent functionality
=3D=3D=3D=3D

I = don't think it makes sense to say #1 or #2 and thus say that all IPv6 r= outers MUST support DHCPv6, because:
  1. Other than for home = gateways where DHCPv6 is required, I'd expect that the vast majority of= routers don't actually support it at all (at least not in all feature = sets).
  2. In most places in the network there's not even any point= in supporting it, because it will never be used. DHCPv6 can only ever be u= sed in routers that serve as first-hop routers for hosts, so a backbone rou= ter will never need a DHCPv6 server or relay.
#3 does m= ake sense.
--001a114558b49b432f054ef9c09c-- From nobody Mon May 8 00:17:12 2017 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 E1C5C120726 for ; Mon, 8 May 2017 00:17: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, 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 JlAxW2cOy_y2 for ; Mon, 8 May 2017 00:17:09 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 9A9871252BA for ; Mon, 8 May 2017 00:17:09 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id t26so27353998qtg.0 for ; Mon, 08 May 2017 00:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1RLL7mw4s/kcOoeaHbQovAY5qiPI1Un5wVMIZjTh7A8=; b=LQEI7jyWjg7wqkjQ5tmJJkaFkfdFJd+Wzry/Tl8CNEoXarSQtBXxX0eAYKydqVqaB1 SN6oJiuNjzA+0tb2cqkqxUX+C4v33/XL7XvxCjBPIBRrQb6xXgqq33xIYyJLfu9GlVIR Q8z5+IUrBBDHjkLYQyLWkY/bLQkX5ShLGPGwG+TyeklX0Lc8gecGFsagiBa2UMgr8Zb9 dTSPYO3gv7uYjtWIRnZFbsdtQbA/xdIFhUWsq5rF8X/Rxi53NZFcT1ddZSl0RNCFoiLX gRkteL0VUPSTFnGeCvbhDDpwYD7RwGM3BlGlo81Kp/v49H9jwmZ4AQtAXIZFaZhDqXYc 9Cug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1RLL7mw4s/kcOoeaHbQovAY5qiPI1Un5wVMIZjTh7A8=; b=Y3WdHaQZoVN9/AUI+FAl2HojhAwt/EAKhCeBo0lygyqXehdI5jUwUKtOgoxsSow0zK fyNKOKQiEREHBNe3H5PMgr/sb5V3s3Mc7bYL+von+XvUfKjQbvuH8O171WQ6j5lS5W1b nE2Bygv3ZYZjUkkIH8JFxR3uSZWz5TE9Aln8RL2QFSHw/tPXLFlJD4YjwqzUXOXUcE2Z zREtxSX9eWy1rDSMCDPzkOOsjGWcNBh2YmKteQN/l8+iHOSygRlHslIs1Ub8XZPk+c2l Ypd8WTq0eqplxu0hhmvyu8xpyOeFQnZWQ4gqd6EFpD25kCC16aioJcEZSIVSLjKqyMEq dFQg== X-Gm-Message-State: AN3rC/7cYgzSjycUiVW7kEqVaO0wt5MMn3uK5aczyH/PwrOyYS/h4Fri CLgvt91c1rbzQq/cV7DAF8OI9mGvWA== X-Received: by 10.200.42.29 with SMTP id k29mr56770046qtk.186.1494227828780; Mon, 08 May 2017 00:17:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.41.59 with HTTP; Mon, 8 May 2017 00:16:48 -0700 (PDT) In-Reply-To: References: <149402169430.8512.11192508581005769547@ietfa.amsl.com> From: Richard Hartmann Date: Mon, 8 May 2017 09:16:48 +0200 Message-ID: To: Lorenzo Colitti Cc: "v6ops@ietf.org WG" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 07:17:11 -0000 On Mon, May 8, 2017 at 4:10 AM, Lorenzo Colitti wrote: > ====== > Routers supporting IPv6, and intended for user facing > connections, MUST support: > > o [RFC3646]: DNS Configuration options for Dynamic Host > Configuration Protocol for IPv6 (DHCPv6). > ====== > > needs clarification. Does it mean that: This section could use some extra clarification, indeed. > A router MUST contain a stateless DHCPv6 server implementation that supports > the DNS option? > A router MUST contain a DHCPv6 relay implementation that supports the DNS > option? > If a router contains an DHCPv6 server or relay implementation, then that > implementation supports the DNS option? #1 is the only logically consistent interpretation. #2 would merely shift the problem outside of what you call "first-hop routers" and the draft calls "Routers supporting IPv6, and intended for user facing connections". And then the draft would not apply to those devices any more. #3 is essentially a no-op and runs counter to the apparent/obvious intent of draft-ietf-v6ops-ipv6rtr-reqs Again, this should be cleared up. > #1 or #2 would be a change to the IPv6 node requirements, which say: This is inherent to the current chicken-and-egg situation. The way I read the draft, it partially wants to address exactly this stand-off of mutually-assured non-complete-stack between RAs & DHCPv6, enabling more comprehensive IPv6 adoption, instead. > I don't think it makes sense to say #1 or #2 and thus say that all IPv6 > routers MUST support DHCPv6, because: It does not say that "all IPv6 routers", it says "Routers supporting IPv6, and intended for user facing connections". > Other than for home gateways where DHCPv6 is required, I'd expect that the > vast majority of routers don't actually support it at all (at least not in > all feature sets). I would argue that this also includes corporate/campus settings. > In most places in the network there's not even any point in supporting it, > because it will never be used. DHCPv6 can only ever be used in routers that > serve as first-hop routers for hosts, so a backbone router will never need a > DHCPv6 server or relay. All of this is neatly addressed in the draft as it limits the scope of DHCPv6 MUST to routers intended for end-user networks. Richard From nobody Mon May 8 03:32:29 2017 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 55CFE129423 for ; Mon, 8 May 2017 03:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 cSkXySpy5cQj for ; Mon, 8 May 2017 03:32:26 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E3D1293D6 for ; Mon, 8 May 2017 03:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1494239544; bh=Z8lZ/BGYXGGemunpMVnA/7grHJLDDbXwIivpo5hrf2k=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=E0KIWZ1KWjpgLbJzlNXhwcGRaXr0NAqq93jVTBO50xGNsZk7+DQpICQcu5RNMd576LEvzJ2SwJn1SLmOYkLHiJRhe/OhDL8sC5H3Hnl46CSQJsKuIMrl7unf5wOyUB1UDjI9a9gg0AMQ5v8kn1W48BTQPkQv1nuaEbr0ETba0sY= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0209.outbound.protection.outlook.com [213.199.154.209]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-64--nuCjy-nNf2v3rJ747e5Zg-1; Mon, 08 May 2017 11:32:20 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Mon, 8 May 2017 10:32:18 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a%15]) with mapi id 15.01.1084.015; Mon, 8 May 2017 10:32:18 +0000 From: Tim Chown To: Lorenzo Colitti CC: "v6ops@ietf.org WG" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-00.txt Thread-Index: AQHSxetDwSE+lEBW30O41GjofsWp46HptMcAgACMJoA= Date: Mon, 8 May 2017 10:32:18 +0000 Message-ID: References: <149402169430.8512.11192508581005769547@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:e966:38a8:dbd6:9e99] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:PLHwSSkGLMcgfwNoNBXhgnohjLkKqOxtPJBW1O6evJPkkRcbO+ZUPhhS33hCc4AFDjawXU9QrWdIaYsX4udwaVLjSDwujTQNQXoc01YZENj2cLP3dFnZ55Rh3PnxjFa+C7JwfyViPuHRr7sKggSocdo+3nFTp0QJbbAEGGKIS+Ie7RhzmhTi1x1OAxVZ0BncE6HMDXLjLuQ5UBjkUBQo/ONBBjQCJsPT/A+cbppqEhpGEJ8GiY8035+G+D5EeJ09PptmLlXLqoLasqPqrv3cPqo2Os7ZrMwfBOl+sF03GMxW/WQn466D5W2zI8sUFJ8iMgLIm1gTgywWwt/wHaAK1A==; 20:EejyofVep8OwPm+8Lmogg2nlXGmJoFywiveKSL+mqiXostPVnNpbGxSRF+rgxsFQ2lt1wanXuhLYPRk3bq7VZYxjWT6VhPOMHAlrp37bNg7FZfNMyd2Uznp5M4iBRi13WQxTOwbPgnSbgZiDplwO6wqO/WklJha1t9/29fWmkcM= x-ms-office365-filtering-correlation-id: b3471678-bd85-4812-f949-08d495fd80ae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1140; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; x-forefront-prvs: 0301360BF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(24454002)(377454003)(110136004)(3280700002)(5660300001)(25786009)(3660700001)(6246003)(86362001)(38730400002)(53546009)(33656002)(5250100002)(36756003)(4326008)(81166006)(8936002)(2906002)(230783001)(8676002)(50226002)(2950100002)(6512007)(478600001)(6916009)(6486002)(189998001)(99286003)(305945005)(74482002)(82746002)(7736002)(83716003)(6506006)(229853002)(6436002)(50986999)(53936002)(76176999)(102836003)(6116002)(42882006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <0AB27719B625C54B806D803A52E5DB83@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2017 10:32:18.3016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: -nuCjy-nNf2v3rJ747e5Zg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 10:32:28 -0000 SGksDQoNCj4gT24gOCBNYXkgMjAxNywgYXQgMDM6MTAsIExvcmVuem8gQ29saXR0aSA8bG9yZW56 b0Bnb29nbGUuY29tPiB3cm90ZToNCj4gDQo+IE9uIFNhdCwgTWF5IDYsIDIwMTcgYXQgNzowMSBB TSwgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQo+ICAgICAgICAgVGl0bGUgICAg ICAgICAgIDogUmVxdWlyZW1lbnRzIGZvciBJUHY2IFJvdXRlcnMNCj4gICAgICAgICBBdXRob3Jz ICAgICAgICAgOiBaYWlkIEFsaSBLYWhuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSm9o biBCcnpvem93c2tpDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgUnVzcyBXaGl0ZQ0KPiAg ICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdjZvcHMtaXB2NnJ0ci1yZXFzLTAw LnR4dA0KPiANCj4gQXMgVGVkIGhhcyBzdGF0ZWQgbWFueSB0aW1lcywgdGhpcyB0ZXh0Og0KPiAN Cj4gPT09PT09DQo+ICBSb3V0ZXJzIHN1cHBvcnRpbmcgSVB2NiwgYW5kIGludGVuZGVkIGZvciB1 c2VyIGZhY2luZw0KPiAgICBjb25uZWN0aW9ucywgTVVTVCBzdXBwb3J0Og0KPiANCj4gICAgbyAg W1JGQzM2NDZdOiBETlMgQ29uZmlndXJhdGlvbiBvcHRpb25zIGZvciBEeW5hbWljIEhvc3QNCj4g ICAgICAgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NiAoREhDUHY2KS4NCj4gPT09PT09 DQo+IA0KPiBuZWVkcyBjbGFyaWZpY2F0aW9uLiBEb2VzIGl0IG1lYW4gdGhhdDoNCj4gCeKAoiBB IHJvdXRlciBNVVNUIGNvbnRhaW4gYSBzdGF0ZWxlc3MgREhDUHY2IHNlcnZlciBpbXBsZW1lbnRh dGlvbiB0aGF0IHN1cHBvcnRzIHRoZSBETlMgb3B0aW9uPw0KPiAJ4oCiIEEgcm91dGVyIE1VU1Qg Y29udGFpbiBhIERIQ1B2NiByZWxheSBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRzIHRoZSBE TlMgb3B0aW9uPw0KPiAJ4oCiIElmIGEgcm91dGVyIGNvbnRhaW5zIGFuIERIQ1B2NiBzZXJ2ZXIg b3IgcmVsYXkgaW1wbGVtZW50YXRpb24sIHRoZW4gdGhhdCBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0 cyB0aGUgRE5TIG9wdGlvbj8NCj4gIzEgb3IgIzIgd291bGQgYmUgYSBjaGFuZ2UgdG8gdGhlIElQ djYgbm9kZSByZXF1aXJlbWVudHMsIHdoaWNoIHNheToNCj4gDQo+ID09PT0NCj4gICAgc3VwcG9y dCBmb3IgREhDUA0KPiAgICBzZXJ2ZXIgZnVuY3Rpb25hbGl0eSBvbiByb3V0ZXJzIGlzIG9wdGlv bmFsLiAgSG93ZXZlciwgcm91dGVycw0KPiAgICB0YXJnZXRlZCBmb3IgZGVwbG95bWVudCB3aXRo aW4gbW9yZSBjb21wbGV4IHNjZW5hcmlvcyAoYXMgZGVzY3JpYmVkDQo+ICAgIGFib3ZlKSBTSE9V TEQgc3VwcG9ydCByZWxheSBhZ2VudCBmdW5jdGlvbmFsaXR5DQo+ID09PT0NCj4gDQo+IEkgZG9u J3QgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gc2F5ICMxIG9yICMyIGFuZCB0aHVzIHNheSB0aGF0 IGFsbCBJUHY2IHJvdXRlcnMgTVVTVCBzdXBwb3J0IERIQ1B2NiwgYmVjYXVzZToNCj4gCeKAoiBP dGhlciB0aGFuIGZvciBob21lIGdhdGV3YXlzIHdoZXJlIERIQ1B2NiBpcyByZXF1aXJlZCwgSSdk IGV4cGVjdCB0aGF0IHRoZSB2YXN0IG1ham9yaXR5IG9mIHJvdXRlcnMgZG9uJ3QgYWN0dWFsbHkg c3VwcG9ydCBpdCBhdCBhbGwgKGF0IGxlYXN0IG5vdCBpbiBhbGwgZmVhdHVyZSBzZXRzKS4NCj4g CeKAoiBJbiBtb3N0IHBsYWNlcyBpbiB0aGUgbmV0d29yayB0aGVyZSdzIG5vdCBldmVuIGFueSBw b2ludCBpbiBzdXBwb3J0aW5nIGl0LCBiZWNhdXNlIGl0IHdpbGwgbmV2ZXIgYmUgdXNlZC4gREhD UHY2IGNhbiBvbmx5IGV2ZXIgYmUgdXNlZCBpbiByb3V0ZXJzIHRoYXQgc2VydmUgYXMgZmlyc3Qt aG9wIHJvdXRlcnMgZm9yIGhvc3RzLCBzbyBhIGJhY2tib25lIHJvdXRlciB3aWxsIG5ldmVyIG5l ZWQgYSBESENQdjYgc2VydmVyIG9yIHJlbGF5Lg0KPiAjMyBkb2VzIG1ha2Ugc2Vuc2UuDQoNCldv cnRoIG5vdGluZyB0aGF0IHRoZSBub2RlIHJlcXVpcmVtZW50cyBkb2N1bWVudCBpcyB1bmRlcmdv aW5nIGFuIHVwZGF0ZSwgc28gaXRzIHRleHQgbWlnaHQgY2hhbmdlLg0KDQpJIHdvdWxkIGNlcnRh aW5seSBzYXkgdGhhdCAjMyBpcyBhIG1pbmltdW0NCg0KVGhlcmUgYXJlIGFsc28gb2YgY291cnNl IGVudGVycHJpc2VzIHRoYXQgd2lzaCB0byBydW4gREhDUHY2LCBidXQgSeKAmWQgYXNzdW1lIHRo ZXkgd291bGQgZG8gc28gdXNpbmcgZmlyc3QtaG9wIHJlbGF5cy4gSW4gdGhhdCBsaWdodCwgYWRk aW5nIGF0IGxlYXN0IGEgU0hPVUxEIGZvciBSRkM2OTM5IHdvdWxkIGJlIGdvb2QsIGlmIGl0cyBu b3QgaW4gdGhpcyBkcmFmdCBhbHJlYWR5LiANCg0KVGhlIHRleHQgc2hvdWxkIHByb2JhYmx5IHRh bGsgYWJvdXQgREhDUHY2IHJlcXVpcmVtZW50cyBmb3Igcm91dGVycyB0aGF0IG1heSB0eXBpY2Fs bHkgYmUgZGVwbG95ZWQgaW4gY2xpZW50LWZhY2luZyBzY2VuYXJpb3MuDQoNClRpbQ0KDQo= From nobody Mon May 8 23:36:22 2017 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 0C3D8129AEB; Mon, 8 May 2017 23:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 oil-ADeIGEXc; Mon, 8 May 2017 23:36:18 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CE8129AFF; Mon, 8 May 2017 23:36:17 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id D5CD51604E6; Tue, 9 May 2017 08:36:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id B75FC16005E; Tue, 9 May 2017 08:36:15 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0339.000; Tue, 9 May 2017 08:36:15 +0200 From: To: Warren Kumari , IPv6 Operations , "draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org" , Joe Clarke Thread-Topic: [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix Thread-Index: AQHSxbFPs712K9DuykCz43s9LaifGqHrjZsg Date: Tue, 9 May 2017 06:36:14 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E6C4E8@OPEXCLILMA3.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.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 06:36:20 -0000 Hi Warren, all,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Warren Kumari > Envoy=E9=A0: vendredi 5 mai 2017 17:06 > =C0=A0: IPv6 Operations; draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org; = Joe > Clarke > Objet=A0: [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix >=20 > First off, thank you for a clear, well written document. > I have completed my AD review, and had a few comments / suggestions. >=20 > I'd also like to thank Fred for requesting early review, and Joe Clarke > for > the helpful review. I agree with all of his comments, other than the xref > in the > abstract -- but, see below on the Updates bit. >=20 > I've annotated my comments with [C]. >=20 > W >=20 >=20 > Abstract >=20 > This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use > within domains that enable IPv4/IPv6 translation mechanisms. This > document updates RFC6890. >=20 > [C]: This document updates RFC6890 by ... ? A very brief summary would be > good. > Actually, I'm not really sure *why* this updates 6890, from what I can se= e > it > simply reserves an additional prefix in the registry. If it really > *does* update 6890 it should also have a section clearly explaining > what changes it makes (including the "new" text). It's entirely > possible that I've missed > something really obvious here... >=20 >=20 > 4. Why 64:ff9b:1::/48? >=20 > [C]: I suspect that there may be some feedback during IESG review that > this section is really long, and provides a lot of (once published) > unnecessary justification -- however, I found it useful and > interesting (and likely needed before publication) - just mentioning > so you are prepared. >=20 > 5. Deployment Considerations >=20 > 64:ff9b:1::/48 is intended as a technology-agnostic and generic > reservation. A network operator may freely use it in combination > with any kind of IPv4/IPv6 translation mechanism deployed within his > network. >=20 > [C]: If editing anyway, may want to replace "his" with "their" - > normally I wouldn't point this out, but apart from the gender issue, > network operator could be plural / networks are often owned by > multiple people / an org. >=20 >=20 > 64:ff9b:1::/48 or any other more-specific prefix SHOULD NOT be > advertised in inter-domain routing, except by explicit agreement > between all involved parties. Such prefixes MUST NOT be advertised > to the default-free zone. >=20 > [C]: ... but you *know* that they will leak - what happens when they > do? Does this break anything? (probably not, *might* be worth > mentioning though) [Med] I wonder if a pointer to https://tools.ietf.org/html/rfc6052#section-= 3.2 would be sufficient here instead of having the full discussion.=20 >=20 >=20 > 6. Checksum Neutrality >=20 > Use of 64:ff9b:1::/48 does not in itself guarantee checksum > neutrality, as many of the IPv4/IPv6 translation algorithms it can be > used with are fundamentally incompatible with checksum-neutral > address translations. >=20 > [C]: Er?! What is this checksum neutral thing of which you speak?! :-) > (I think you need a reference here -- I *think* that RFC6296, Section > 2.6 is the closest.) >=20 [Med] The text already cites a pointer that is relevant for IPv4/IPv6 addre= ss translation matters:=20 Section 4.1 of [RFC6052] contains further discussion about IPv4/IPv6 translation and checksum neutrality. >=20 > 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. >=20 > The following non-exhaustive list contains examples of translation > prefixes that are checksum neutral when used with the [RFC7915] and > [RFC6052] algorithms: >=20 > o 64:ff9b:1:fffe::/96 >=20 > o 64:ff9b:1:fffd:1::/96 >=20 > o 64:ff9b:1:fffc:2::/96 >=20 > o 64:ff9b:1:abcd:0:5431::/96 >=20 > Section 4.1 of [RFC6052] contains further discussion about IPv4/IPv6 > translation and checksum neutrality. >=20 > [C]: Oh! Here is the reference (I think 6296 Sec 2.6 is clearer.) [Med] Citing RFC6052 is appropriate here because it discusses IPv4/IPv6 add= ress translation matters while RFC6269 is about IPv6 prefix translation. RF= C6052 is clear about the meaning:=20 ... one's complement checksum if both the IPv4- translatable and the IPv4-converted IPv6 addresses were constructed in a "checksum-neutral" manner, that is, if the IPv6 addresses would have the same one's complement checksum as the embedded IPv4 address. >=20 > 7. IANA Considerations >=20 > The IANA is requested to add the following entry to the IPv6 Special- > Purpose Address Registry: >=20 > +----------------------+---------------------+ > | Attribute | Value | > +----------------------+---------------------+ > | Address Block | 64:ff9b:1::/48 | > | Name | IPv4-IPv6 Translat. | > | RFC | (TBD) | > | Allocation Date | (TBD) | > | Termination Date | N/A | > | Source | True | > | Destination | True | > | Forwardable | True | > | Global | False | > | Reserved-by-Protocol | False | > +----------------------+---------------------+ >=20 > The IANA is furthermore requested to add the following footnote to > the 0000::/8 entry of the Internet Protocol Version 6 Address Space > registry: >=20 > 64:ff9b:1::/48 reserved for Local-use IPv4/IPv6 Translation [TBD] >=20 > 8. Security Considerations >=20 > The reservation of 64:ff9b:1::/48 is not known to cause any new > security considerations beyond those documented in Section 5 of > [RFC6052]. >=20 > 9. References >=20 > 9.1. Normative References >=20 > [SNIP] >=20 > [C]: IMO it would be better to have the Acknowledgments section as a > numbered section, not an Appendix (I'm not sure if this is actually > required, but is, IMO, better form). >=20 > Appendix A. Acknowledgments >=20 > The author would like to thank Fred Baker, Mohamed Boucadair, Brian E > Carpenter, Pier Carlo Chiodi, David Farmer, Holger Metschulat and > David Schinazi for contributing to the creation of this document. >=20 >=20 > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue May 9 00:16:18 2017 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 676A7127180 for ; Tue, 9 May 2017 00:16:15 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 gImwmdfXwUHG for ; Tue, 9 May 2017 00:16:13 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 28295126E3A for ; Tue, 9 May 2017 00:16:13 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id e55so65607570uaa.2 for ; Tue, 09 May 2017 00:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iE3tPo/KOJMmWpF6aaW5UIY97uoF/JoW+U5BMVdXe44=; b=TIZHmK4FE9dfnQDlR/uUl0QJJTbKTNQAWsfabL/i8cz5IcD1+PYOg2AOS3lS5HluDy e6WqVnvQGCU0tBS6yUH5YpME4IeSbMZynjsUX7zZNvCzYbIuqTQCCP6/SqVoSZTRU63z EpYYhWnDbeJ9SeuStlYhAte1f7draBS0yF6/7ZN7LSvweaNPuvh34Jzd62dIxbhOItYf N//OGd/JAnUChEsVM5Wc6Do5B62zmzEjYAO23KxiCIx51lhkoS5RUeRfawcBV0wX6toJ fZymzIKYDTzj0VloX/31UZn64FYXUAeNMv1nTs+9c1Zfjp1mDZb/9WTgwukuBEVjc8YU VCRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iE3tPo/KOJMmWpF6aaW5UIY97uoF/JoW+U5BMVdXe44=; b=ss9zn6mhTWwfdGgcdHNZPS45yxvoYEScbtsu6ZMEj+/UjK4zC6NZFBTl0Q9dze23EO kMYZ34zRmK9ZzrVXI5ctH0p4laFI3IfXHd4PKt48yvrtrhlcirzKdgMMFpZggXE+WNTP UpzG2feWBwABx++kLOaI/0+1Soit7cpMrv97EJwXVcA32+p6nU5D1Rft/BxLnNLFF5Qs rHnNevoZknx7kQw9zSSiic7ibCJPj+SUz+eZfrBy2rbNkm7L0Dmha6h96Zli8D0+A2pw YfBx5y0/ykYyIJPGSAYxrVEY+sJEQFaTkUeFnH6IRnafc1oYz4wOR0+lJNTyIypl5SO5 i6WQ== X-Gm-Message-State: AN3rC/5VsrV0gOkLposIdkwjfHHH0dGZ7J3w6V+59J81N56xP+OlG+r6 q0JzEr7VLg7LFSfAgxV5Gmla3dM+aMo2 X-Received: by 10.159.51.232 with SMTP id y40mr28030409uab.76.1494314172103; Tue, 09 May 2017 00:16:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.71.83 with HTTP; Tue, 9 May 2017 00:15:31 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E6C4E8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933009E6C4E8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Warren Kumari Date: Tue, 9 May 2017 03:15:31 -0400 Message-ID: To: "mohamed.boucadair@orange.com" Cc: IPv6 Operations , "draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org" , Joe Clarke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 07:16:15 -0000 On Tue, May 9, 2017 at 2:36 AM, wrote: > Hi Warren, all, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Warren Kumari >> Envoy=C3=A9 : vendredi 5 mai 2017 17:06 >> =C3=80 : IPv6 Operations; draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org= ; Joe >> Clarke >> Objet : [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix >> >> First off, thank you for a clear, well written document. >> I have completed my AD review, and had a few comments / suggestions. >> >> I'd also like to thank Fred for requesting early review, and Joe Clarke >> for >> the helpful review. I agree with all of his comments, other than the xre= f >> in the >> abstract -- but, see below on the Updates bit. >> >> I've annotated my comments with [C]. >> >> W >> >> >> Abstract >> >> This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use >> within domains that enable IPv4/IPv6 translation mechanisms. This >> document updates RFC6890. >> >> [C]: This document updates RFC6890 by ... ? A very brief summary would b= e >> good. >> Actually, I'm not really sure *why* this updates 6890, from what I can s= ee >> it >> simply reserves an additional prefix in the registry. If it really >> *does* update 6890 it should also have a section clearly explaining >> what changes it makes (including the "new" text). It's entirely >> possible that I've missed >> something really obvious here... >> >> >> 4. Why 64:ff9b:1::/48? >> >> [C]: I suspect that there may be some feedback during IESG review that >> this section is really long, and provides a lot of (once published) >> unnecessary justification -- however, I found it useful and >> interesting (and likely needed before publication) - just mentioning >> so you are prepared. >> >> 5. Deployment Considerations >> >> 64:ff9b:1::/48 is intended as a technology-agnostic and generic >> reservation. A network operator may freely use it in combination >> with any kind of IPv4/IPv6 translation mechanism deployed within his >> network. >> >> [C]: If editing anyway, may want to replace "his" with "their" - >> normally I wouldn't point this out, but apart from the gender issue, >> network operator could be plural / networks are often owned by >> multiple people / an org. >> >> >> 64:ff9b:1::/48 or any other more-specific prefix SHOULD NOT be >> advertised in inter-domain routing, except by explicit agreement >> between all involved parties. Such prefixes MUST NOT be advertised >> to the default-free zone. >> >> [C]: ... but you *know* that they will leak - what happens when they >> do? Does this break anything? (probably not, *might* be worth >> mentioning though) > > [Med] I wonder if a pointer to https://tools.ietf.org/html/rfc6052#sectio= n-3.2 would be sufficient here instead of having the full discussion. Yup, works for me. > >> >> >> 6. Checksum Neutrality >> >> Use of 64:ff9b:1::/48 does not in itself guarantee checksum >> neutrality, as many of the IPv4/IPv6 translation algorithms it can be >> used with are fundamentally incompatible with checksum-neutral >> address translations. >> >> [C]: Er?! What is this checksum neutral thing of which you speak?! :-) >> (I think you need a reference here -- I *think* that RFC6296, Section >> 2.6 is the closest.) >> > > [Med] The text already cites a pointer that is relevant for IPv4/IPv6 add= ress translation matters: Ok. You might want to mention RFC6052 here, but I'm fine if not (someone new to the topic will read down to here, and then get confused and might not read to end of section). > > Section 4.1 of [RFC6052] contains further discussion about IPv4/IPv6 > translation and checksum neutrality. > >> >> 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. >> >> The following non-exhaustive list contains examples of translation >> prefixes that are checksum neutral when used with the [RFC7915] and >> [RFC6052] algorithms: >> >> o 64:ff9b:1:fffe::/96 >> >> o 64:ff9b:1:fffd:1::/96 >> >> o 64:ff9b:1:fffc:2::/96 >> >> o 64:ff9b:1:abcd:0:5431::/96 >> >> Section 4.1 of [RFC6052] contains further discussion about IPv4/IPv6 >> translation and checksum neutrality. >> >> [C]: Oh! Here is the reference (I think 6296 Sec 2.6 is clearer.) > > [Med] Citing RFC6052 is appropriate here because it discusses IPv4/IPv6 a= ddress translation matters while RFC6269 is about IPv6 prefix translation. = RFC6052 is clear about the meaning: > > ... one's complement checksum if both the IPv4- > translatable and the IPv4-converted IPv6 addresses were constructed > in a "checksum-neutral" manner, that is, if the IPv6 addresses would > have the same one's complement checksum as the embedded IPv4 address. Ok, fine with me. Once Tore pushes a new version (without the Updates: , and other changes) I can start the IETF LC. W > >> >> 7. IANA Considerations >> >> The IANA is requested to add the following entry to the IPv6 Special- >> Purpose Address Registry: >> >> +----------------------+---------------------+ >> | Attribute | Value | >> +----------------------+---------------------+ >> | Address Block | 64:ff9b:1::/48 | >> | Name | IPv4-IPv6 Translat. | >> | RFC | (TBD) | >> | Allocation Date | (TBD) | >> | Termination Date | N/A | >> | Source | True | >> | Destination | True | >> | Forwardable | True | >> | Global | False | >> | Reserved-by-Protocol | False | >> +----------------------+---------------------+ >> >> The IANA is furthermore requested to add the following footnote to >> the 0000::/8 entry of the Internet Protocol Version 6 Address Space >> registry: >> >> 64:ff9b:1::/48 reserved for Local-use IPv4/IPv6 Translation [TBD] >> >> 8. Security Considerations >> >> The reservation of 64:ff9b:1::/48 is not known to cause any new >> security considerations beyond those documented in Section 5 of >> [RFC6052]. >> >> 9. References >> >> 9.1. Normative References >> >> [SNIP] >> >> [C]: IMO it would be better to have the Acknowledgments section as a >> numbered section, not an Appendix (I'm not sure if this is actually >> required, but is, IMO, better form). >> >> Appendix A. Acknowledgments >> >> The author would like to thank Fred Baker, Mohamed Boucadair, Brian E >> Carpenter, Pier Carlo Chiodi, David Farmer, Holger Metschulat and >> David Schinazi for contributing to the creation of this document. >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu May 11 04:19:12 2017 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 5CC32126DED; Thu, 11 May 2017 04:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 OEfotGmLtbDB; Thu, 11 May 2017 04:18:51 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 AC63F12EBF6; Thu, 11 May 2017 04:16:53 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=53692 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1d8m5L-0004nc-DY; Thu, 11 May 2017 11:16:43 +0000 Date: Thu, 11 May 2017 13:16:42 +0200 From: Tore Anderson To: Joe Clarke Cc: , v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org Message-ID: <20170511131642.1f408832@echo.ms.redpill-linpro.com> In-Reply-To: <149373185172.9923.9255526962045750289@ietfa.amsl.com> References: <149373185172.9923.9255526962045750289@ietfa.amsl.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 11:18:54 -0000 Hi Joe, and thank you very much for your review. See in-line for my comments. * Joe Clarke > 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): >=20 > 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. Good catch! I changed =C2=ABa WKP=C2=BB to =C2=ABthe WKP=C2=BB. > And then in section 5: >=20 > 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. >=20 > 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.=20 > 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. Actually I'm trying to not imply anywhere that 64:ff9b:1::/48 is a/the =C2=ABWKP=C2=BB (although the previous point you brought up was a failure i= n that regard). The WKP is defined to be exactly 64:ff9b::/96 by RFC6052, and I do not want to cause any ambiguity here. I rewrote the paragraph in question as follows: Note that 64:ff9b:1::/48 (or any more-specific prefix) is distinct fr= om the WKP 64:ff9b::/96. Therefore, the restrictions on the use of the W= KP described in Section 3.1 of do not apply t= o the use of 64:ff9b:1::/48. Is that better? > In Section 3, you state: >=20 > Since the WKP 64:ff9b::/96 was reserved by [RFC6052], several new > IPv4/IPv6 translation mechanisms have been defined by the IETF >=20 > 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. How about: =C2=ABSince the WKP 64:ff9b::/96 was reserved by [RFC6052], several new IPv4/IPv6 translation mechanisms have been defined by the IETF, such as [RFC6146] and [RFC7915].=C2=BB ? These two mechanisms do not interoperate at all, so they need different translation prefixes if they're to be deployed in the same network. > NITS: >=20 > In your Abstract, you mention RFC6890, but this does not appear to be > an xref to it, and it should be. As mentioned by others, the idnits tool complains about xrefs in the abstract. In any case I've just dropped the Updates on 6890 completely. > In Section 4.1 you state: >=20 > 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. >=20 > 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. >=20 > (Removed a redundant "is".) Fixed, thanks! > In Section 4.1 again: >=20 > 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. >=20 > 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. Fixed, thanks! > In Section 6: >=20 > 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. >=20 > 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. >=20 > (Added a missing "it".) Fixed, thanks! Tore From nobody Thu May 11 04:24:15 2017 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 53B9912EBD6; Thu, 11 May 2017 04:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 47yhldYiOAMf; Thu, 11 May 2017 04:24:06 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 E29B4129789; Thu, 11 May 2017 04:22:01 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=53752 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1d8mAM-0004oD-Hi; Thu, 11 May 2017 11:21:54 +0000 Date: Thu, 11 May 2017 13:21:53 +0200 From: Tore Anderson To: David Farmer Cc: Fred Baker , V6 Ops List , draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org, IETF-Discussion Discussion Message-ID: <20170511132153.269fd1d7@echo.ms.redpill-linpro.com> In-Reply-To: References: <149373185172.9923.9255526962045750289@ietfa.amsl.com> <7789CECA-165C-417F-B485-03A154327AC1@gmail.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 11:24:08 -0000 Hi David, > Prompted by this review, I reread the document and found what I think are a > couple additional typos. > > Section 4.2, Prefix Value, compares two options: 64:ff9a:ffff:ffff::/48 and > 64:ff9b:1::/48. However in the fifth paragraph of the section, I believe > there are two errant references to 64:ff9b:1::/96, that should instead > be 64:ff9b:1::/48, > unless I'm misunderstanding the intent of the paragraph. You're absolutely right. Fixed. Thank you! Tore From nobody Thu May 11 05:00:04 2017 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 AC650126579; Thu, 11 May 2017 05:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 bei6tw_hj4Uk; Thu, 11 May 2017 05:00:01 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 1B9C512EBDA; Thu, 11 May 2017 04:58:03 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=54188 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1d8mjF-0004r0-GY; Thu, 11 May 2017 11:57:57 +0000 Date: Thu, 11 May 2017 13:57:57 +0200 From: Tore Anderson To: Warren Kumari Cc: IPv6 Operations , draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org, Joe Clarke Message-ID: <20170511135757.27cabad7@echo.ms.redpill-linpro.com> In-Reply-To: References: X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 12:00:03 -0000 Hi Warren, * Warren Kumari > First off, thank you for a clear, well written document. > I have completed my AD review, and had a few comments / suggestions. Thank you very much! My comments in-line: > Abstract >=20 > This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use > within domains that enable IPv4/IPv6 translation mechanisms. This > document updates RFC6890. >=20 > [C]: This document updates RFC6890 by ... ? A very brief summary would be= good. > Actually, I'm not really sure *why* this updates 6890, from what I can se= e it > simply reserves an additional prefix in the registry. If it really > *does* update 6890 it should also have a section clearly explaining > what changes it makes (including the "new" text). It's entirely > possible that I've missed > something really obvious here... As discussed later on in this thread, I've "solved" this by dropping the RFC6890 update completely. > 4. Why 64:ff9b:1::/48? >=20 > [C]: I suspect that there may be some feedback during IESG review that > this section is really long, and provides a lot of (once published) > unnecessary justification -- however, I found it useful and > interesting (and likely needed before publication) - just mentioning > so you are prepared. Thanks for the heads up. The reason for it being so long is because the working group wanted it to be (the selection of the exact prefix took like 90%+ of the time spent on the draft), so I'm loath to start trimming it down again... > 5. Deployment Considerations >=20 > 64:ff9b:1::/48 is intended as a technology-agnostic and generic > reservation. A network operator may freely use it in combination > with any kind of IPv4/IPv6 translation mechanism deployed within his > network. >=20 > [C]: If editing anyway, may want to replace "his" with "their" - > normally I wouldn't point this out, but apart from the gender issue, > network operator could be plural / networks are often owned by > multiple people / an org. Changed, thanks! > 64:ff9b:1::/48 or any other more-specific prefix SHOULD NOT be > advertised in inter-domain routing, except by explicit agreement > between all involved parties. Such prefixes MUST NOT be advertised > to the default-free zone. >=20 > [C]: ... but you *know* that they will leak - what happens when they > do? Does this break anything? (probably not, *might* be worth > mentioning though) I implemented Mohamed's follow-up suggestion by rewriting this paragraph as follows: 64:ff9b:1::/48 or any more-specific prefix may only be used in inter-domain routing if done in accordance with the rules described in Section 3.2 of [RFC6052]. Does that work for you? > 6. Checksum Neutrality >=20 > Use of 64:ff9b:1::/48 does not in itself guarantee checksum > neutrality, as many of the IPv4/IPv6 translation algorithms it can > be used with are fundamentally incompatible with checksum-neutral > address translations. >=20 > [C]: Er?! What is this checksum neutral thing of which you speak?! :-) > (I think you need a reference here -- I *think* that RFC6296, Section > 2.6 is the closest.) >=20 >=20 > 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. >=20 > The following non-exhaustive list contains examples of translation > prefixes that are checksum neutral when used with the [RFC7915] and > [RFC6052] algorithms: >=20 > o 64:ff9b:1:fffe::/96 >=20 > o 64:ff9b:1:fffd:1::/96 >=20 > o 64:ff9b:1:fffc:2::/96 >=20 > o 64:ff9b:1:abcd:0:5431::/96 >=20 > Section 4.1 of [RFC6052] contains further discussion about > IPv4/IPv6 translation and checksum neutrality. >=20 > [C]: Oh! Here is the reference (I think 6296 Sec 2.6 is clearer.) As Mohamed also mentioned in his follow-up I believe RFC6052 section 4.1 is the correct reference here. I reordered this section though so that the paragraph with the RFC6052 section 4.1 pointer comes second, before the paragraphs with the RFC7915 discussion and examples. No word changes. Better? > [C]: IMO it would be better to have the Acknowledgments section as a > numbered section, not an Appendix (I'm not sure if this is actually > required, but is, IMO, better form). >=20 > Appendix A. Acknowledgments When I wrote RFC7755 I originally had the Acknowledgements section as an ordinary numbered section, but the RFC Editor moved it into the with =C2=ABnumbered=3D"no"=C2=BB. So I'll just leave it where it is but add =C2=ABnumbered=3D"no"=C2=BB, whic= h I'd forgotten about in this draft. I hope that's good enough. Tore From nobody Thu May 11 10:18:25 2017 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 E9DA013144E; Thu, 11 May 2017 10:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 LBv4dVwwiXnk; Thu, 11 May 2017 10:18:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44015129B84; Thu, 11 May 2017 10:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1747; q=dns/txt; s=iport; t=1494522793; x=1495732393; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Wh1VPyjsGml3rxZ8GRBQQKBqkw2eioriHRPujgzWpZ8=; b=Bi9VEd8IkJr56HYGN04zwhujZJm/zyJ92cGP2hTvw2gU6sy36VucMKX3 /7QaJesuxJeW1yLWVfSPIUF+Q8e7Be6+2Zq3zWq1KwvfnaqdhlljtPVDy gkrkT2YC7ihG0CF88ffgdp6ujTB9EHE6q7+clT0wbBoH4AtDjacNv6QqO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAgBXmxRZ/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1WFV5tRIXKVAoIPhiQChQ1AFwECAQEBAQEBAWsohRUBAQEBAgE?= =?us-ascii?q?jDwFGEAsYAgImAgJXBg0IAQGKFgixUYImincBAQEBAQEBAQEBAQEBAQEBASGBC?= =?us-ascii?q?4VUgV4rC4IxNId1gmABBJZvhxuTG4sChmmUQyABNoEKTyEVh1ckiRIBAQE?= X-IronPort-AV: E=Sophos;i="5.38,325,1491264000"; d="scan'208";a="241986267" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2017 17:13:12 +0000 Received: from [10.82.250.3] (rtp-vpn6-513.cisco.com [10.82.250.3]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v4BHDABw017783; Thu, 11 May 2017 17:13:12 GMT To: Tore Anderson Cc: ops-dir@ietf.org, v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org References: <149373185172.9923.9255526962045750289@ietfa.amsl.com> <20170511131642.1f408832@echo.ms.redpill-linpro.com> From: Joe Clarke Organization: Cisco Message-ID: <9d92e7bd-5b55-fb1f-5572-b69b6507ee7c@cisco.com> Date: Thu, 11 May 2017 13:13:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170511131642.1f408832@echo.ms.redpill-linpro.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 17:18:17 -0000 On 5/11/17 07:16, Tore Anderson wrote: > Actually I'm trying to not imply anywhere that 64:ff9b:1::/48 is a/the > «WKP» (although the previous point you brought up was a failure in that > regard). The WKP is defined to be exactly 64:ff9b::/96 by RFC6052, and > I do not want to cause any ambiguity here. > > I rewrote the paragraph in question as follows: > > Note that 64:ff9b:1::/48 (or any more-specific prefix) is distinct from > the WKP 64:ff9b::/96. Therefore, the restrictions on the use of the WKP > described in Section 3.1 of do not apply to the > use of 64:ff9b:1::/48. > > Is that better? Yes, I think that text plus the previous clarification is good. > >> 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. > > How about: «Since the WKP 64:ff9b::/96 was reserved by [RFC6052], > several new IPv4/IPv6 translation mechanisms have been defined by the > IETF, such as [RFC6146] and [RFC7915].» ? > > These two mechanisms do not interoperate at all, so they need different > translation prefixes if they're to be deployed in the same network. That works. > >> NITS: >> >> In your Abstract, you mention RFC6890, but this does not appear to be >> an xref to it, and it should be. > > As mentioned by others, the idnits tool complains about xrefs in the > abstract. In any case I've just dropped the Updates on 6890 completely. Thanks. Joe From nobody Fri May 12 02:46:49 2017 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 9F3D012957B; Fri, 12 May 2017 02:46:41 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149458240158.16677.10308385408365124921@ietfa.amsl.com> Date: Fri, 12 May 2017 02:46:41 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-v4v6-xlat-prefix-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 09:46:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Local-use IPv4/IPv6 Translation Prefix Author : Tore Anderson Filename : draft-ietf-v6ops-v4v6-xlat-prefix-01.txt Pages : 7 Date : 2017-05-12 Abstract: This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6-xlat-prefix/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-v4v6-xlat-prefix-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-v4v6-xlat-prefix-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-v4v6-xlat-prefix-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 15 21:18:34 2017 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 1080A127342 for ; Mon, 15 May 2017 21:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 5pttZGKwccEz for ; Mon, 15 May 2017 21:18:31 -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 2387A129C73 for ; Mon, 15 May 2017 21:15:34 -0700 (PDT) Received: from [192.168.0.116] (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPA id v4G4FVlc051646; Tue, 16 May 2017 04:15:31 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be [192.168.0.116] Content-Type: multipart/mixed; boundary=Apple-Mail-BAC9B58A-3012-4CB1-BC75-D93AC2FD9AE6 Mime-Version: 1.0 From: joel jaeggli X-Enigmail-Draft-Status: N1110 Fcc: imap://joelja@nagasaki.bogus.com/Sent In-Reply-To: X-Identity-Key: id1 Date: Mon, 15 May 2017 21:15:26 -0700 X-Account-Key: account1 Cc: "v6ops@ietf.org" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0; attachmentreminder=0 Message-Id: Content-Transfer-Encoding: 7bit References: <914B3454-58A4-4130-8B90-6371100D619D@fugue.com> <20170405.145921.74683020.sthaug@nethelp.no> <22348F51-ECB4-44F4-8D99-265FAEFB3830@jisc.ac.uk> X-Mailer: iPhone Mail (14F89) To: Brian E Carpenter , Lorenzo Colitti , Tim Chown Archived-At: Subject: Re: [v6ops] Making RDNSS a MUST? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 04:18:33 -0000 --Apple-Mail-BAC9B58A-3012-4CB1-BC75-D93AC2FD9AE6 Content-Type: application/pgp-encrypted; name=mime-attachment; x-apple-part-url=D13A0336-9822-4508-89BF-2F46015ECF36 Content-Disposition: attachment; filename=mime-attachment Content-Transfer-Encoding: 7bit Version: 1 --Apple-Mail-BAC9B58A-3012-4CB1-BC75-D93AC2FD9AE6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --Apple-Mail-BAC9B58A-3012-4CB1-BC75-D93AC2FD9AE6 Content-Type: application/octet-stream; name=encrypted.asc; x-apple-part-url=17F90958-9B37-4BC8-8EA2-92B62D3450A5 Content-Disposition: attachment; filename=encrypted.asc Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Comment: GPGTools - http://gpgtools.org hQQOA3odf+YpQH+SEA/+P78mBQoTHEVJNWhKL/yFoDCTFdTvwlhN/IwY714kYkI2 0nl+Bwnbc857DYzppkSF2xGSvJdQosxNBlFkaaRI7VDweKGg0TnndLje8pxyn+rw KS09WZu21vkz+iSX+jCxT87V73biOPaXYgzbZ+Rdf8pPhM1JCWPGuW1DTeiIHF9P bU7s0SIUDKKCkdB4to/Y8mH2PtDO6ayskpGOmLzMQlF+a8nZQhTATqwi24LE7/t1 NpZLL5EWANrx7khSDD9uO4V0i9lhoXxqPoV83HxpE9/KysWXt4khsuWn7D0ocrRC UBiH8mz/kSgyKUuEWbSqWQxrP3i1Yw5AodtiLDERNQQQ2s13aUTCJKF26I7GoQvM iqQBtX2d71p7Ln1TyxyGhYx5iBkPlEeELtDUZDf93rtl2uNfm8XVjd0UKxeG5kQp 3d2FvWJsH6/ob55iyGnp8Wy0TurNuwtSp9w+55nc23izaa9z2ydBUdZjYGXyjvvQ +J9uJpb9ULQuWQlX6hRu52iGPMhKriYSkFvZ8t10E0vqi5t+1RjOf+h3bwKh/1ZX WOitOO1ofu/q22h1++k8ZMvHTi7mQfl4jDPaUQK8PocFAoiXIUa9sDUl0ihaRKfQ V3LURyj0jLHNoQLsSYSbQtIXND50hqB2Ok4236zRZ2/XduetUiCv2eNGB0JAk2EP /2FdiCpNM1HkemDbEtIV7+hmhmz+20j4DYEE+P/qUKflrbkhl4AjtNzAwjq9h0XQ mSh8oJjMdV5wAME6B8b+r2WOTuUkyb+HKIvz7tsqIG82I0ybU8OCs4jUIxUbiPR7 KmONSjqIAHYPDHXyZ+AvgEO7Qaa6PbeAf8e6fAR3BhA6zu6HJJPlwqDw3Xsxs5WF Ypwl4EYuG/x/rUdL4ceZdTMqwG6v4PvpZnxKut74s1veerc3KBKv/1z42U9p/N7o QcltA0/duMspR6VZ++hDzP+DsPOSfQ87OPUP/q4A7kbQ/YPWINOnzHDetHAftCU1 eCakJAuMEsMVf1M63Tb1Leb/KfvZoT0ictAPrn4Pt7m4L4e7hZ5gH/x65dBUj0cm W6MGVuBljp33Flm7qTNKeguCT5W30SjRn3OTs+vrDoSnl4PvR6ur8jMlQCCMaxX2 OxjyYotFkQnyI3AMHe/eq0ekBOQXNY44goDbC4nVu2aJ43IUd2V68V5sg0UHq/bX CXypvkFfPy81K+MH85ZyV+57ZgGYJfsYDxGnUUz93JzZIqfRTN9z2yjAX7YlSkPk OJrdcAKn5Oy0InMj9FykyOokYI9R1Bc6EVIkwQV57axmWTsnu5sxa3Y8pOLfS+9Q Clw51JtqEmD3dbUiKVwNRkvXDTAcRJ62QKgxmylibCjg0uoBq+9ukw/dEpxD9Fcd +fcLlrv65Sg6GwZ/edXtFUE0cvxzEfAtZpCr8FNCiNJykWGlo3rz1tUuTCOL5xtH tH3ufpZ+XPA7azjcYBPMr2SSjkBUIp1oPoBerW5LSKo2j3L89HVPfTOEcT4Eey0I 4Bsc/ppH0226txZzU9682P5fdw3p3Hn4cAq4IebCZxPxlsIEtek2lu2GbHr5TuP6 xLiQbGawWCRge9iuizu48cGgG6NCxLHuIVAsePpodK82Z6IaeJEogAzEjA6UoNsc Gh3WIYwIT0aJoGcSxmW4wVkdar9TSQFXsS3oXD6LhF6yu3dtWtxLKBB10YcAGFYI YE8C9CEHJ08XfGyvHJ3Lr0Opz/9fJqck4FFwFwdNbq3K4KiMsJ6namCiNz7hbtA2 QgChebIlvxdlLD/mbya3RDTI2lmNb8T6/fq3UdT0pejrdt8z3ixp9WB54nK7LljR HvzCjod+a0/7v939zrdWIDFGDf064kd6vDF3qnq0pE/JYRoTC8tjx7dP3uAO2Lbw J+KXDQLDMTfkLg9nVolHUilqMH6ESPrXrp9jNUMKhjZNYqPk7rf5Ca5cKXa4R70I FhG7r65/kxwFYO6jmmotSQgtZO9fLkguyD1QNTLYdxeEL4OAOXSbM9/3keLDeBfo ZK/ULAfzDtQwVX2BrClPeAX7d+urBA26DlDubqijmEdjONlkh5FPcw6lPE1jV1pN Xm4E5qKtyixj3gTACgZ/YLAUp0FkiT+lDc8LVKgVhjEzVFTEC9VozPHS15rrxHFW VV+BnwO8U6rupY6VNM8wka75ZOrJATM8ZEMg4lELrG2Ib7iuQEIc3BKmYD/VF11B CMDEk1eklijS4p42BMBdjWDvcvGjss6QeE0B9XlOUgtqlFW83b9EJDxwNezDmyyd 6mW/4fFCDQKFy4k5Ce6kJnJI+nrDfD6604+H7rwmkKbEZqBK45oOLCe52CU3uo/9 9pHrlsNAiPTKW4Inw11A1yYEwmGMnJlSxY88LhgRCC9pqc8PdPTe2GaD6+oip/O/ bZnN4Saa9qf0gWxtHIDXzNUExW9lQKtpbNMSA8lRZFlFvqDc3itiOCclX1lScNzb emAvCjwbEbdVkyP9pXricNySjz+jCTc+b1/GDK3q8TTbpAFthd3EAcEOH0NuZPeY xMQ+FaXRQUTh7K8n8VrDebvKnvdzdB4Q7Lugz+IphynTPE31hoTYqsbGmWp5wq6C R6gPGzDkWMJg2dfCOj0bK9h+33idPaCRFmLvLCmcct3iBFTTV2cb31/yTBBG09Id iKXRykurCK36dSJmOMIircNyqJkmKAH66AWFhU18PK3ukrreBlLqxlGxCZSeoOYt m9HR6WLoZL+hJ1baZJGLoxwt1CstrL317S/+SIqTj7hmdQLREnnqG1F2e/W5H4P7 O1nGzEE7CgpCG5bn+E94Enn0SCKapXU3MGt/NtiQLZJeTqbPetMdTZrwjSVbLerP GCgABnjrRWdQwlTY6FFml3ex4Ag9cM5Mbg6liZvQwB/ZoXCYQA960Xu20d7nQffF i01whplIerwoom3iG6a/duIAnjISGvn93H0MQy8UZt9Rk/7nIAEdGXphNDD8MjNq EPvDG3JRqVyd1dtmp8rjMZ5cbL3OuoUxORy3qO5JY2X7XtVKoQUsdwm9vJ+OWfXl kWD+WuQWcZb0SLs4P546YyphTX1tkkEUx7Fnt5DzYhi8qq5rN1fw5a2MNQcUEmOE RMyq/SCiCSX+4fnvwdpXEUwtV3bjzO7ClcDELWsZOYsqqpmKOg4AEVyUOfnKVuJo 35fJLOVzYBdtJjGCri2vBVClUQigqIg9utWGVcnPNfpvZagVmBjQsgrKNx/F7ewM el0ryhQLoan8X6Pj2PTt5/s+VA6O7Or3/U44dKa1xPDAFIWoOgAI3zPpXw7Oce5T nUgBvk6k1taXBEEj1p9gBwxz4tfj30BMBkNN2FGqoTBi+k5/hbpZqL30v9nJ5CHN RdDp9qKupj14lqkdEUsooYGGnNGUPsWE2k2vKh+bP18cvwOywJxBRgl2sbvbu5kg 8PcIhW8Qzsxz1PxAllKpBqmr4PtJ7mY404H2lsZkWngh4wqGyrsxt+t0P5m7rrpg 0myBXwvAdAhPLBHvmhHb6IuxFq90IK2ugh7HPAaMKhJLm/jG9FQGCMt7+yF+uYD5 WTWph5ZoSrr7nBRU8WrqUoBSRbAA+CmQyaBiYxHRyoAUHB5h2R28wBZHW3JBAJ0M evVEnqlkcqcVPLkQ/KHq1BzOZv3OHHSMgn4i3mupKbbA1KVra8oM8ju3NsPpR7Gd RLsl6ZV4jiyb8n50pxqqZaTFXJJQAfskYMSzlX2j/XJIeoEtFLiQpCRGVPyNAkZM 1wNdQ5q+o+nq1syw2sPV9Xk2LK/vxa4C9vRTcnTG9v9ngqG13PgspyA3YqmkgRZI 7UrnN5LB26WVs35z/ywKqNLVEJQeUlX0VMEdxdJCDWxncJew7LoR4cNJ5iov5NpP eYQ= =RWCR -----END PGP MESSAGE----- --Apple-Mail-BAC9B58A-3012-4CB1-BC75-D93AC2FD9AE6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --Apple-Mail-BAC9B58A-3012-4CB1-BC75-D93AC2FD9AE6-- From nobody Wed May 17 02:58:36 2017 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 0070312940E; Wed, 17 May 2017 02:58:27 -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.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149501510695.6733.2757441046539773447@ietfa.amsl.com> Date: Wed, 17 May 2017 02:58:26 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 09:58:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt Pages : 8 Date : 2017-05-17 Abstract: In some IPv6 environments, the need has arisen for hosts to be able to utilize a unique IPv6 prefix, even though the link or media may be shared. Typically hosts (subscribers) on a shared network, either wired or wireless, such as Ethernet, WiFi, etc., will acquire unique IPv6 addresses from a common IPv6 prefix that is allocated or assigned for use on a specific link. In most deployments today, IPv6 address assignment from a single IPv6 prefix on a shared network is done by either using IPv6 stateless address auto-configuration (SLAAC) and/or stateful DHCPv6. While this is still viable and operates as designed, there are some large scale environments where this concept introduces significant performance challenges and implications, specifically related to IPv6 router and neighbor discovery. This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 22 11:26:03 2017 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 38D8D127444; Mon, 22 May 2017 11:25:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk CC: v6ops@ietf.org, fredbaker.ietf@gmail.com, v6ops-chairs@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org, warren@kumari.net, Fred Baker Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149547755522.9058.6555837394853713750.idtracker@ietfa.amsl.com> Date: Mon, 22 May 2017 11:25:55 -0700 Archived-At: Subject: [v6ops] Last Call: (Local-use IPv4/IPv6 Translation Prefix) to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 18:25:55 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Local-use IPv4/IPv6 Translation Prefix' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-06-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6-xlat-prefix/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6-xlat-prefix/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue May 23 12:41:44 2017 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 770B012EAC4; Tue, 23 May 2017 12:41:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk CC: Ron Bonica , v6ops@ietf.org, rbonica@juniper.net, draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org, warren@kumari.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> Date: Tue, 23 May 2017 12:41:43 -0700 Archived-At: Subject: [v6ops] Last Call: (Unique IPv6 Prefix Per Host) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 19:41:43 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Unique IPv6 Prefix Per Host' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-06-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In some IPv6 environments, the need has arisen for hosts to be able to utilize a unique IPv6 prefix, even though the link or media may be shared. Typically hosts (subscribers) on a shared network, either wired or wireless, such as Ethernet, WiFi, etc., will acquire unique IPv6 addresses from a common IPv6 prefix that is allocated or assigned for use on a specific link. In most deployments today, IPv6 address assignment from a single IPv6 prefix on a shared network is done by either using IPv6 stateless address auto-configuration (SLAAC) and/or stateful DHCPv6. While this is still viable and operates as designed, there are some large scale environments where this concept introduces significant performance challenges and implications, specifically related to IPv6 router and neighbor discovery. This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6106: IPv6 Router Advertisement Options for DNS Configuration (Proposed Standard - IETF stream) rfc4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (Draft Standard - IETF stream) rfc4862: IPv6 Stateless Address Autoconfiguration (Draft Standard - IETF stream) rfc3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed Standard - IETF stream) From nobody Wed May 24 10:05:54 2017 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 1282C129BCB for ; Wed, 24 May 2017 10:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.367 X-Spam-Level: ** X-Spam-Status: No, score=2.367 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiO0_956biIX for ; Wed, 24 May 2017 10:05:52 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7849C129BA0 for ; Wed, 24 May 2017 10:05:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v4OH5oqg173751 for ; Wed, 24 May 2017 19:05:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 558E0205036 for ; Wed, 24 May 2017 19:05:50 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3254C204D11 for ; Wed, 24 May 2017 19:05:50 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4OH5ni5005319 for ; Wed, 24 May 2017 19:05:49 +0200 To: "v6ops@ietf.org" From: Alexandre Petrescu Message-ID: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> Date: Wed, 24 May 2017 19:05:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] DHCPv6 PD client on cellular on some IoT platform X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 17:05:54 -0000 Hello, We discussed extensively about the potential use of DHCPv6 Prefix Delegation on cellular links. The chicken issue is the lack of DHCPv6 PD software on typical User Equipment. For example, there is no DHCPv6-PD app on Android. The egg issue is the lack of operator support of DHCPv6-PD towards the User Terminal. For example, there is no cellular operator answering to DHCPv6-PD requests issued by the User Terminal. To address the chicken issue, we started with an ISC DHCP open software client, which does implement Prefix Delegation. It can be (cross)compiled on various platforms; then type "./dhclient -6 -P"; this sends an DHCPv6 Solicit Identity Associtaion for Prefix Delegation message on the interface. However, whereas this software runs ok on interfaces such as Ethernet, USBnet and WiFi interfaces, it breaks if run on the cellular interface of some IoT cellular platform. The error can be corrected by the quick-and-dirty solution below. Alex ------------------------------------------------------------------------ The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0." dhcp-4.3.5 ./common/lpf.c line number: 551 //default: // log_fatal("Unsupported device type %ld for \"%s\"", // (long int)sa->sa_family, name); default: hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; (two programmers worked this out). Alex From nobody Wed May 24 11:03:37 2017 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 4256C126C89 for ; Wed, 24 May 2017 11:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 (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 U58KPGswHYx4 for ; Wed, 24 May 2017 11:03:34 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 D80F71200F1 for ; Wed, 24 May 2017 11:03:33 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id a5so58404997lfh.2 for ; Wed, 24 May 2017 11:03:33 -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-language:content-transfer-encoding; bh=DXaNAqrKtM7OhOoKe5ESp76Qxye6dniK6SRDhVMTGIA=; b=anohwbRpGbrgkTtBnS0Jv5JKYKLdoKWnDERpDk31iRgOwS1zlvjiHgQS2v1NUNLBPW B96dZc4coq8mPfRyUEUcvB7i2qwhEykrW0qez5daAMAhDbO3PX2D0/FaNT0ErNHdCcoS 0+27OZDa0VV4esldPOIwhFX+uCr6IpjKyuZdMoHKoaFXSZqR9Q6ZTyeYcBbtk3hGv2WY Jvk74EYiuwV6am8R02o7io+1RnZUNeGV+ayPdERxv/PNoEWdhZCw1UNpo6G6VE3GLMff mBmSdgy13340LSi9FRsBAX69uwO7XTYNZwCYbl2G9tJUR2fOH6M4UiqF9E0KgacOw0yT 9amA== 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-language :content-transfer-encoding; bh=DXaNAqrKtM7OhOoKe5ESp76Qxye6dniK6SRDhVMTGIA=; b=IIfM9gaTILebyXyRPQRjezO4JGKg96fZBMckfKa4KIl7nzzpequA90+ZiNGma581SP N1SpKfYDmyjluM3TwgS1z0sjqM48ncas7D6YqopH3ewqVUBgYDkVe0F02BpXo2DLEOyV mhhhjyMUFsR6whipqJknZ7SMjn61l2dCT+Y4WmH4IvikzppXnJwnxo+g4lwhXU/7T6f3 qcgoDrXgWhwHE8/x9VuZHmQ5H0J/W7vK3w4nJ8c0Q4erZVcVZGUYSr9F5RONr/Ooqb42 OXbIzLztGpHc9bwSbMTelnJnd+P0+LarPX6lEiEj+sBBzyV0dK6FezA3s1QmvAOgKTHO 4/hA== X-Gm-Message-State: AODbwcDP1dken1I8tqU8B16zsD2+A8pmiekkuGSB1yb4BG+zHzxlm2x2 A9g+4MA+BVHncdBQ X-Received: by 10.25.35.87 with SMTP id j84mr10671753lfj.118.1495649011501; Wed, 24 May 2017 11:03:31 -0700 (PDT) Received: from [192.168.0.5] (109241207033.gdansk.vectranet.pl. [109.241.207.33]) by smtp.googlemail.com with ESMTPSA id b71sm942359lfg.32.2017.05.24.11.03.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 11:03:29 -0700 (PDT) To: v6ops@ietf.org References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> From: Tomek Mrugalski Message-ID: Date: Wed, 24 May 2017 20:03:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on some IoT platform X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 18:03:36 -0000 W dniu 24.05.2017 o 19:05, Alexandre Petrescu pisze: > We discussed extensively about the potential use of DHCPv6 Prefix > Delegation on cellular links. > > The chicken issue is the lack of DHCPv6 PD software on typical User > Equipment. For example, there is no DHCPv6-PD app on Android. The egg > issue is the lack of operator support of DHCPv6-PD towards the User > Terminal. For example, there is no cellular operator answering to > DHCPv6-PD requests issued by the User Terminal. > > To address the chicken issue, we started with an ISC DHCP open software > client, which does implement Prefix Delegation. It can be > (cross)compiled on various platforms; then type "./dhclient -6 -P"; this > sends an DHCPv6 Solicit Identity Associtaion for Prefix Delegation > message on the interface. > > However, whereas this software runs ok on interfaces such as Ethernet, > USBnet and WiFi interfaces, it breaks if run on the cellular interface > of some IoT cellular platform. The error can be corrected by the > quick-and-dirty solution below. Alex, Thanks for bringing this issue up and for using ISC software. Personally I think v6ops (and any other WG mailing list) is not an appropriate place for discussing topics specific to a given implementation, but I'll leave that determination for the chairs. Can I ask you to repost your report to dhcp-users, a list dedicated to users of ISC DHCP software? It's available at https://lists.isc.org/mailman/listinfo/dhcp-users Once you do that, I'll respond there explaining how to improve your patch, as it has a couple flaws that require improvements. Thanks, Tomek Mrugalski ISC From nobody Wed May 24 14:21:39 2017 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 AFC53129B21 for ; Wed, 24 May 2017 14:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WM36WxLvXqNh for ; Wed, 24 May 2017 14:21:37 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 3C03C127863 for ; Wed, 24 May 2017 14:21:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4OLLaA6050867; Wed, 24 May 2017 14:21:36 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4OLLWNE050453 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 24 May 2017 14:21:32 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 24 May 2017 14:21:31 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 24 May 2017 14:21:31 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] DHCPv6 PD client on cellular on some IoT platform Thread-Index: AQHS1LAKWsHR+akJJEGy3XAfHLYfKKID+7lQ Date: Wed, 24 May 2017 21:21:31 +0000 Message-ID: <1e7de6487fef4959b9177993c7581e3e@XCH15-06-08.nw.nos.boeing.com> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> In-Reply-To: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on some IoT platform X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 21:21:39 -0000 Hi Alex, We have been doing DHCPv6 PD on Androids for a long time. DHCPv6 messaging is via a tunnel over the cellular and WiFi links. The DHCPv6 client app was= easy to implement and requires just a small amount of code and a few DHCPv6 message= s. The DHCPv6 server we are using is from ISC. Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petres= cu > Sent: Wednesday, May 24, 2017 10:06 AM > To: v6ops@ietf.org > Subject: [v6ops] DHCPv6 PD client on cellular on some IoT platform >=20 > Hello, >=20 > We discussed extensively about the potential use of DHCPv6 Prefix > Delegation on cellular links. >=20 > The chicken issue is the lack of DHCPv6 PD software on typical User > Equipment. For example, there is no DHCPv6-PD app on Android. The egg > issue is the lack of operator support of DHCPv6-PD towards the User > Terminal. For example, there is no cellular operator answering to > DHCPv6-PD requests issued by the User Terminal. >=20 > To address the chicken issue, we started with an ISC DHCP open software > client, which does implement Prefix Delegation. It can be > (cross)compiled on various platforms; then type "./dhclient -6 -P"; this > sends an DHCPv6 Solicit Identity Associtaion for Prefix Delegation > message on the interface. >=20 > However, whereas this software runs ok on interfaces such as Ethernet, > USBnet and WiFi interfaces, it breaks if run on the cellular interface > of some IoT cellular platform. The error can be corrected by the > quick-and-dirty solution below. >=20 > Alex >=20 > ------------------------------------------------------------------------ > The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0." > dhcp-4.3.5 > ./common/lpf.c > line number: 551 >=20 > //default: > // log_fatal("Unsupported device type %ld for \"%s\"", > // (long int)sa->sa_family, name); > default: > hw->hlen =3D 7; > hw->hbuf[0] =3D HTYPE_ETHER; > memcpy(&hw->hbuf[1], sa->sa_data, 6); > break; >=20 > (two programmers worked this out). >=20 > Alex >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu May 25 14:48:33 2017 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 69A16129B82; Thu, 25 May 2017 14:48:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: v6ops@ietf.org, draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149574889740.8736.3270119983003121650@ietfa.amsl.com> Date: Thu, 25 May 2017 14:48:17 -0700 Archived-At: Subject: [v6ops] Genart last call review of draft-ietf-v6ops-unique-ipv6-prefix-per-host-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 21:48:17 -0000 Reviewer: Joel Halpern Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-?? Reviewer: Joel Halpern Review Date: 2017-05-25 IETF LC End Date: 2017-06-06 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an RFC Major issues: N/A Minor issues: I will leave the decision on the appropriate status of this document to the IESG. I note that sections, for example the third paragraph of section 3, are currently written as if the IETF is recommending this practice, rather than merely describing how to do this when it is desired. Whether this is appropriate is again a call for the members of the IESG. Nits/editorial comments: From nobody Thu May 25 16:12:58 2017 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 8687D128792 for ; Thu, 25 May 2017 16:12:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 dTEriA1gqQIu for ; Thu, 25 May 2017 16:12:48 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 AC58A126CF9 for ; Thu, 25 May 2017 16:12:46 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id u10so124015292uaf.1 for ; Thu, 25 May 2017 16:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qrv6v4C4KwmDpu4Annv2kJRQBQo6zHdS43tJQm5x3JE=; b=CbjFG55JDSlTie9/wtyXSPNxp9ntcfbQiiVo2ixUm5bkEIphLNnNnP9x7ukGKKfnu8 CduXGlH/BeBEsqix0aT+Q3q4JbGwuvrJWLRm0jipzwkHuOB7R9zfFW01LGNtVb9J7jcn UVpALKquRIiyXBxdnCxBr6HpNY6DxSf6l26/9bkf+QUivuBE3zKx4t+czIBcjd99edPK jgD/Kt4+yHp0CZVQasARv2VTQ/1ZYokKp8B2m/+1wpeCw/TDiRzzSbHiZhkTTNtgukA/ es4axyQ72HUJeTrj2mjKhxYTjDSCUSt9WwPV5gCYMiEZjrcmKs4Q2mhq+nhqH8x/cioo HCaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qrv6v4C4KwmDpu4Annv2kJRQBQo6zHdS43tJQm5x3JE=; b=YMbUhGveaFuFH+ihI2N9kriTbcDHHHqlvphRnoJURicwAuP6zl+4G6uXBUca24/szf KKHnZh3hS/bARqlEzPzcr8/M35N5poi0jyyh2P8KU2n7pSaT1N3hdB8jGC8+73UC+As1 Ly1gjU9liPsdsCRHYBzI76IPBCJn5pz14dvT6EMtmZQqxNmje4dJv9L7F/y4FSJGiGtE dq1elIrCngPfFM6YvQ4EgHnwalGS7AAz47BJEku5w0xTbC3Og0jmbPsrXKn3pgus+oVi DhED11i4O9bDK4UdP+McCRzP4OsxwU0Z8+xDoDw8QS5eM9J04ROjZbDZ34LALrZEYA46 PyPg== X-Gm-Message-State: AODbwcBq4rgvJKMSs0xvKmbgkzFcJOtGgTWtHzorHh70MXRdjlJ6Q9Pj DH9nAVF/Wxtvc96JtqtlEAJwBFUIUWJy X-Received: by 10.176.95.201 with SMTP id g9mr6080035uaj.71.1495753965609; Thu, 25 May 2017 16:12:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Thu, 25 May 2017 16:12:25 -0700 (PDT) In-Reply-To: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> References: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 25 May 2017 16:12:25 -0700 Message-ID: To: IETF Discussion Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org Content-Type: multipart/alternative; boundary="089e08204dd8cb05650550615b05" Archived-At: Subject: Re: [v6ops] Last Call: (Unique IPv6 Prefix Per Host) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 23:12:50 -0000 --089e08204dd8cb05650550615b05 Content-Type: text/plain; charset="UTF-8" On Tue, May 23, 2017 at 12:41 PM, The IESG wrote: > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Unique IPv6 Prefix Per Host' > as Best Current > Practice > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. I think this is a desirable way to configure public IPv6 network access and support the publication of this document as BCP. I see a couple issues that probably need to be resolved before publication: 1. Off-link flag. If the UE/ subscriber desires to send anything external including other UE/ subscriber devices (assuming device to device communications is enabled and supported), then, due to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router. I think the document might need to say what the First Hop Provider Router needs to do in the case when it the host sends the router a packet for a destination in the same prefix as the host. (This can happen since L=0.) It seems that the router could simply turn around and send an NS for that IPv6 address, which would likely just end up going back to the host. Seems like we might want to avoid that. 2. If this document is to be a BCP, then the RA timers should probably not be a part of this document. They are over-prescriptive, and they conflict with the suggestions in RFC 7772, which says: In order to limit the amount of power used to receive Router Advertisements to, say, 2% of idle power (i.e., to impact idle battery life by no more than 2%), the average power budget for receiving RAs must be no more than 0.1 mA, or approximately 7 RAs per hour. That argues for an RA interval of > 500 seconds, which is half the power consumption of the value in this document (300 seconds). Cheers, Lorenzo --089e08204dd8cb05650550615b05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, May 23, 2017 at 12:41 PM, The IESG <iesg-secretary@ietf.org&= gt; wrote:
The = IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Unique IPv6 Prefix Per Host'
=C2=A0 <draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt> as = Best Current
Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.

=C2=A0I thin= k this is a desirable way to configure public IPv6 network access and suppo= rt the publication of this document as BCP. I see a couple issues that prob= ably need to be resolved before publication:

1. Of= f-link flag.

=C2=A0 =C2=A0If the UE/
=C2=A0 =C2=A0subscriber desires to send anything external including other= UE/
=C2=A0 =C2=A0subscriber devices (assuming device to device c= ommunications is
=C2=A0 =C2=A0enabled and supported), then, due t= o the L-bit set, it SHOULD send
=C2=A0 =C2=A0this traffic to the = First Hop Provider Router.

I think the docum= ent might need to say what the First Hop Provider Router needs to do in the= case when it the host sends the router a packet for a destination in the s= ame prefix as the host. (This can happen since L=3D0.) It seems that the ro= uter could simply turn around and send an NS for that IPv6 address, which w= ould likely just end up going back to the host. Seems like we might want to= avoid that.

2. If this document is to be a BCP, t= hen the RA timers should probably not be a part of this document. They are = over-prescriptive, and they conflict with the suggestions in RFC 7772, whic= h says:

=C2=A0 =C2=A0 =C2=A0 In order to limi= t the amount of power used to receive Router
=C2=A0 =C2=A0 =C2=A0= Advertisements to, say, 2% of idle power (i.e., to impact idle
= =C2=A0 =C2=A0 =C2=A0 battery life by no more than 2%), the average power bu= dget for
=C2=A0 =C2=A0 =C2=A0 receiving RAs must be no more than = 0.1 mA, or approximately 7 RAs
=C2=A0 =C2=A0 =C2=A0 per hour.

That argues for an RA interval of > 500 seco= nds, which is half the power consumption of the value in this document (300= seconds).

Cheers,
Lorenzo
--089e08204dd8cb05650550615b05-- From nobody Fri May 26 13:24:54 2017 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 26266129449; Fri, 26 May 2017 13:24: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 KxeEirpys1sB; Fri, 26 May 2017 13:24:33 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 81649127ABE; Fri, 26 May 2017 13:24:33 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id f27so5139132pfe.0; Fri, 26 May 2017 13:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0+15Wnn7qCVXpCaKEserYudgwmMvNsx8/CMe5aHwyU4=; b=GrXuqEAAUNckJ4eYBi3e3Vw+fxl0AdAiesZ2tw16Xjeq34KH41BqR7JIQ7Ivk1fFoH OKZPyWFyDP9xC6jvy4OrlKNPoQWEb0L70LyeodQebqCCmXTt9pMaMvWVbTokmMF1GiBJ IuHa0mBtl/9ejSLRkDQv/AxNJzBRjRAYlxLC3xmCQhqADnazE6+VqrTcyN15vR8LsBSp cDVwrZNkvvncLcI2fet3bPwRjqkrMBqV3HJlliZT0Kur1GjxV0bkAvpVRB6cVMuowxR6 WwIF+xH0KfNv0/zCJ7yOCNE110fubx47dl0sqnnH6J6ZprXqH8+l3hlKtmVLHsiymAd3 N4uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0+15Wnn7qCVXpCaKEserYudgwmMvNsx8/CMe5aHwyU4=; b=QK6VwY2PqB44v2X4ab8NWwM+xX8DaBsnSUUT9CZisCI0J717EkDayf8eQDdJVcK+Bf PmPYZB6y5kTcwKcv2WiN1LwDYgd5O7jtyu7m0blCHG2+vPvi58z52OdWlcQIHQKfeRet tqnpiI5iy1L8JepMQiW/y8+OLD0a0At1f1To9YbKJBGqW9I3de9jhhrUf2n8CplXDgyo K0bquQvUKxK13Y1ESBZjXk74uIwaCAOfYqoRUqQJnbxTVHjzZTCli+DTEsW+f0cLd/mE WTDzNUSw2LRDT1Pn76TBaNDBuA7GmmYzv6Lsr7YJsJDM3GIOwljblOf9O0y4ko6E8H32 Vmag== X-Gm-Message-State: AODbwcCRsQdnkxbrBQxpQhGkcVZhbWbk4sirqnKZ9fDmWfN9ETg9v2/E Tnn2DaQW2sP6vj6u X-Received: by 10.98.192.143 with SMTP id g15mr4427295pfk.219.1495830272874; Fri, 26 May 2017 13:24:32 -0700 (PDT) Received: from [192.168.178.21] ([118.149.96.135]) by smtp.gmail.com with ESMTPSA id n22sm3330869pfa.123.2017.05.26.13.24.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 13:24:32 -0700 (PDT) To: ietf@ietf.org Cc: v6ops@ietf.org, draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org References: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 27 May 2017 08:24:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Last Call: (Unique IPv6 Prefix Per Host) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 20:24:35 -0000 Hi, I should have noticed this during the v6ops discussions, but I didn't, sorry. This draft cites RFC4862 (SLAAC) and mentions Router Advertisements (without also citing RFC4861, which is possibly a mistake). Those documents do not specify the subnet prefix length. So the draft shouldn't assume a particular prefix length either. We all know that it's usually 64 today, but that doesn't affect the argument made by the draft. We need consistency with RFC 7608 (BCP 198). Regards Brian Carpenter On 24/05/2017 07:41, The IESG wrote: > > The IESG has received a request from the IPv6 Operations WG (v6ops) > to consider the following document: - 'Unique IPv6 Prefix Per Host' > as Best > Current Practice > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send substantive > comments to the ietf@ietf.org mailing lists by 2017-06-06. > Exceptionally, comments may be sent to iesg@ietf.org instead. In > either case, please retain the beginning of the Subject line to allow > automated sorting. > > Abstract > > > In some IPv6 environments, the need has arisen for hosts to be able > to utilize a unique IPv6 prefix, even though the link or media may > be shared. Typically hosts (subscribers) on a shared network, > either wired or wireless, such as Ethernet, WiFi, etc., will acquire > unique IPv6 addresses from a common IPv6 prefix that is allocated or > assigned for use on a specific link. > > In most deployments today, IPv6 address assignment from a single > IPv6 prefix on a shared network is done by either using IPv6 > stateless address auto-configuration (SLAAC) and/or stateful DHCPv6. > While this is still viable and operates as designed, there are some > large scale environments where this concept introduces significant > performance challenges and implications, specifically related to > IPv6 router and neighbor discovery. > > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique IPv6 address from the service provider > include improved subscriber isolation and enhanced subscriber > management. > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ballot/ > > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. See RFC > 3967 for additional information: rfc6106: IPv6 Router Advertisement > Options for DNS Configuration (Proposed Standard - IETF stream) > rfc4941: Privacy Extensions for Stateless Address Autoconfiguration > in IPv6 (Draft Standard - IETF stream) rfc4862: IPv6 Stateless > Address Autoconfiguration (Draft Standard - IETF stream) rfc3315: > Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed > Standard - IETF stream) > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops . > From nobody Fri May 26 20:24:34 2017 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 C3E7112EAAF for ; Fri, 26 May 2017 20:24:32 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8TbymE7lCafF for ; Fri, 26 May 2017 20:24:32 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 2E35412EAAA for ; Fri, 26 May 2017 20:24:31 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id y4so14558742uay.2 for ; Fri, 26 May 2017 20:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MOx32uabCYy0kIEko1W5PXt4p0qzsn7/gae0ivVXTl0=; b=ItwypI3RdBwRxlGmVm4CrVq60L0NAqu/SssdnAqwd/5HaJeD4DQ5UrEMSxQzkibH8e v6OlsmQzbKyUUKT/AZjB0BtWlwiu9IJpZ2eR0fY9cxc10IBkP24P+6NfQuvBPOQwV9TJ 4P99anePCSbOGwZsZ03gX4aodncVd3rCMfDZxGO/vxuX0IAKAw9bQOswjV68SsFUIpYk eDnM72SdXvZNwKx9Iv2ySsdvs4QzViXriWYtdRlhugysc/tATdYEw5OB6VSzs2qGJm0K VxNV4Jxo1UvcMUEXJKtMlkpjW8KRUD+kdNBkSAssPHExMjgXqT/5fGm3DYuFmC1uiKeE ZpYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MOx32uabCYy0kIEko1W5PXt4p0qzsn7/gae0ivVXTl0=; b=LU96Yhj7IlPK4IInXFMDED8H+9novqTGmCyo3lCkzaNXjx1B6uQcFtRqpSEDVAaRuj piU5PQpeH//VP6qtYo9LThrXxRKMq+kMPElqSw+qX4neZLDI8/Dvahh2PPYvg77kiF5q 0Uwv0TnB6AosBx1OxhxRNsTAHqX9biaUnzqSUPHTamhKzAM1BkoztHYFrQ/vOzojfqwv LfuAtbydNRlt+f8axuG4s0XiN+a6zukDVZ4Gb0f7iHlrScbrpaemor8aTllCsL7AE5qr dU01I2K1KCbeiowwsyQ9zNlvpA4WZLdamJVdluSganUFc+A5sU7b3yfJOQ4pQzm5GXEL HMvA== X-Gm-Message-State: AODbwcDs+IISUAisFHHGXN9k7ucvIpqb2uZxF6QYrE5wiKjUZTLxeCdx hS+OQNJGnS3xzLDVwXWX87iUei5n3iRp X-Received: by 10.159.35.232 with SMTP id 95mr2882552uao.48.1495855470202; Fri, 26 May 2017 20:24:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.138 with HTTP; Fri, 26 May 2017 20:24:28 -0700 (PDT) Received: by 10.31.168.138 with HTTP; Fri, 26 May 2017 20:24:28 -0700 (PDT) In-Reply-To: References: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Fri, 26 May 2017 20:24:28 -0700 Message-ID: To: "Brian E. Carpenter" Cc: IETF Discussion , "v6ops@ietf.org WG" , draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c03c790f03850055078fdbf" Archived-At: Subject: Re: [v6ops] Last Call: (Unique IPv6 Prefix Per Host) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 03:24:33 -0000 --94eb2c03c790f03850055078fdbf Content-Type: text/plain; charset="UTF-8" On 26 May 2017 13:24, "Brian E Carpenter" wrote: So the draft shouldn't assume a particular prefix length either. We all know that it's usually 64 today, but that doesn't affect the argument made by the draft. It's always /64 for all addresses starting with binary 000, which cannot be assigned to hosts in a real network because they are unallocated space. We need consistency with RFC 7608 (BCP 198). No, we don't. RFC 7608 is about forwarding, not address assignment. --94eb2c03c790f03850055078fdbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 26 May 2017 13:24, "Brian E Carpenter" <brian.e.carpenter@gmail.com= > wrote:
So the draft
shouldn't assume a particular prefix length either. We all know that it's usually 64 today, but that doesn't affect the argument made by=
the draft.

It's always /64 for all addresses starting with binary 000,= which cannot be assigned to hosts in a real network because they are unall= ocated space.

We need consistency with RFC 7608 (BCP 198).

No, we don't. RFC 7608 is about forwarding, not address assi= gnment.
--94eb2c03c790f03850055078fdbf-- From nobody Sat May 27 23:50:01 2017 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 F1BAD1293D6; Sat, 27 May 2017 23:49:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149595419894.24426.7074020393438812680@ietfa.amsl.com> Date: Sat, 27 May 2017 23:49:58 -0700 Archived-At: Subject: [v6ops] Genart last call review of draft-ietf-v6ops-v4v6-xlat-prefix-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 06:49:59 -0000 Reviewer: Roni Even Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-v6ops-v4v6-xlat-prefix-?? Reviewer: Roni Even Review Date: 2017-05-27 IETF LC End Date: 2017-06-05 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready with issues for publication as standard track RFC Major issues: Minor issues: I was wondering why this document does not update RFC6052. My reasoning is that RFC7915 section 6 says "The translator MUST support the stateless address mapping algorithm defined in [RFC6052], which is the default behavior." This document suggests that the mapping in this document can be used. Nits/editorial comments: From nobody Sun May 28 04:27:46 2017 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 3112712422F; Sun, 28 May 2017 04:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-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 qyxs5eOm5HQ8; Sun, 28 May 2017 04:27:31 -0700 (PDT) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 866241205F0; Sun, 28 May 2017 04:27:31 -0700 (PDT) Received: from [2a02:fe0:c420:330a::bc8] (port=55670 helo=envy.e1.y.home) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dEwM5-000501-Ce; Sun, 28 May 2017 11:27:29 +0000 Date: Sun, 28 May 2017 13:27:28 +0200 From: Tore Anderson To: Roni Even Cc: , v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org Message-ID: <20170528132728.1b418349@envy.e1.y.home> In-Reply-To: <149595419894.24426.7074020393438812680@ietfa.amsl.com> References: <149595419894.24426.7074020393438812680@ietfa.amsl.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Genart last call review of draft-ietf-v6ops-v4v6-xlat-prefix-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 11:27:33 -0000 Hi Roni, and thank you for your review. > I was wondering why this document does not update RFC6052. My > reasoning is that RFC7915 section 6 says "The translator MUST support > the stateless address mapping algorithm defined in [RFC6052], which is > the default behavior." This document suggests that the mapping in > this document can be used. There's nothing in RFC6052 that needs updating, as RFC6052 already caters for the use of its stateless address mapping algorithm with arbitrary IPv6 prefixes outside of the WKP 64:ff9b::/96. Tore From nobody Mon May 29 07:47:02 2017 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 5DC501270A0; Mon, 29 May 2017 07:46:54 -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.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149606921435.3762.14727398533646344700@ietfa.amsl.com> Date: Mon, 29 May 2017 07:46:54 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 14:46:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-rfc7084-bis-02.txt Pages : 30 Date : 2017-05-29 Abstract: This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers several transition technologies, as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are able to do so. The document obsoletes RFC 7084. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc7084-bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 29 07:53:52 2017 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 48892129A92 for ; Mon, 29 May 2017 07:53:51 -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; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es 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 QonTSPZ8JJ1k for ; Mon, 29 May 2017 07:53:50 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD433129A90 for ; Mon, 29 May 2017 07:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1496069628; x=1496674428; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=kMhjdPxowRJGJ+TZ/GKtN17Nz PuAQfEWXu6/T+Dqnuw=; b=Akew9rEO8z+ifMo5puGZwttFQcaUzoRbYaE1pNOAg uZLts31bOGlDiOCTkRw9bvRm/XyAOETfYzDCfPiE4tfSkVLmX30d+jjxhbWZ97TN 7TLmVL6ajRfffvHDx17+/WiULFzZsAb7xllOCcT1mjhgy6m9YifvFx3DTck+MGMC Mc= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=JHrWKyK41K08CmTKzqxeM9H/QJssB9qf6nD5kboeIkgqzPMFxa+hDdmF4Gys 9c+gUJukyxlFtAGiVR6rWucMqXdyu0IeGh74bV7XpFGVVxTSyfpO3d5oi 1lhY6tQttcpru7gzmWS1ydsVJ3NVYQ6lkwC/s0NFiNRJuIIXeJJzdM=; X-MDAV-Processed: mail.consulintel.es, Mon, 29 May 2017 16:53:48 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 29 May 2017 16:53:47 +0200 Received: from [192.168.0.126] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005441079.msg for ; Mon, 29 May 2017 16:53:46 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170529:md50005441079::OCr4TV2G9om+ORzx:00001Ck/ X-MDRemoteIP: 201.27.7.90 X-Return-Path: prvs=132276cefb=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Mon, 29 May 2017 11:53:37 -0300 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt References: <149606921435.3762.14727398533646344700@ietfa.amsl.com> In-Reply-To: <149606921435.3762.14727398533646344700@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 14:53:51 -0000 Hi all, This is an updated version of this document, including the following changes: 11. ANNEX D: Changes from RFC7084-bis-01 Section to be removed for WGLC. Significant updates are: 1. G-5 added in order to comply with [RFC7608]. 2. LW4O6-5 removed. 3. MAPE-3 removed. 4. MAPT-3 removed. 5. Included non-normative reference to [RFC7849] to clarify that the details of the connectivity to 3GPP/LTE networks is out of the scope. 6. Split of transition in two sub-sections for the sake of clarity. 2, 3 and 4 above (added in the previous version) were referring to the explicit mention of NAT behavior. As each mechanism has the relevant text in its respective RFC, I leave that to those documents, to avoid any misunderstanding or conflict. Regards, Jordi -----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: lunes, 29 de mayo de 2017, 11:46 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations of the IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-rfc7084-bis-02.txt Pages : 30 Date : 2017-05-29 Abstract: This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers several transition technologies, as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are able to do so. The document obsoletes RFC 7084. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc7084-bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From nobody Tue May 30 01:14:46 2017 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 7AAAD129B8B; Tue, 30 May 2017 01:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiCo7l6P6Dgv; Tue, 30 May 2017 01:14:43 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 0B236129511; Tue, 30 May 2017 01:14:42 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id g15so23267516wmc.2; Tue, 30 May 2017 01:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=r3mb58DuLqJIEqRF9OdFBKBKRp+u1p/d+iDHIXFFqcM=; b=r3PSG2V339+v9il9eHcga62dVUwBfMje8JyxL28VzQ/VHWp+q9t0tXmw/PtjpD9xNF z5rnB9mm44uIPn3IWegiJiNWIZrtDhD7GUuK6PPwbyAt0/3pzrM1fL3Yw+AwHkoaCY73 2IG79LEmotUBUBb6rewjTJgRr9QKfWIMAjOHwNBFiREIZac+mo+q8YfeTLYkCYULs02o 5VwkulyRQP4xH/0xep6TiUbHOOL0SVedoVGjmHeH+tOskKQqHjGxNr44DrzA5au5ZqLL N300jUMz0PuVlXqpGWEIQ99K5jeIWZEGOMWFZl8n/Xf7H0Ja5ST0/MeSz40I/hnJ2Gay nzwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=r3mb58DuLqJIEqRF9OdFBKBKRp+u1p/d+iDHIXFFqcM=; b=S3Eu1TGrtFZhsvrIH0YhsXMHrLCPUwXO9G9PTMXYRXDBrJD9E7f20uMtVJSlTS9Ay8 ofHfpK7ppKqthU0WRZL7VW6D64EYMekCv40vVNmWFAxhJwxEnFRf1qmCojlB3T8ap2dA 3JIYf49UaUrhf6v2CgcZjm0r7k3iamuqchb8JVPRp1FuDgiDCczHWo2wtlvDUJ12UHqA GuupdswKSLiILJnw6ScPWIokuW8vpwDBCCwoeG9yj1/UVsUkUWz8EmS8faYJC+kA3ns4 f3vj1olE7+FMlQZdEgFzgHLM0GeIUYfHw7bQ04YMBCibNcbXCkB5v5KcOdUJ/oLSJmRg mCvA== X-Gm-Message-State: AODbwcB16t9337PwUnhK8ZOhich8feXVHhU0SKxHImQUyOg38jYrqGdd POKPkI6wKClCwc7jREI= X-Received: by 10.223.165.14 with SMTP id i14mr16078232wrb.127.1496132080322; Tue, 30 May 2017 01:14:40 -0700 (PDT) Received: from ?IPv6:2001:648:22b0:0:a5fc:c650:d3a3:a232? ([2001:648:22b0:0:a5fc:c650:d3a3:a232]) by smtp.googlemail.com with ESMTPSA id n92sm9539711wrb.62.2017.05.30.01.14.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 01:14:39 -0700 (PDT) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu To: Lorenzo Colitti , "Brian E. Carpenter" References: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org, IETF Discussion Message-ID: Date: Tue, 30 May 2017 11:14:36 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Last Call: (Unique IPv6 Prefix Per Host) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 08:14:44 -0000 Le 27/05/2017 à 06:24, Lorenzo Colitti a écrit : > On 26 May 2017 13:24, "Brian E Carpenter" > > > wrote: > >> So the draft shouldn't assume a particular prefix length either. We >> all know that it's usually 64 today, but that doesn't affect the >> argument made by the draft. > > > It's always /64 for all addresses starting with binary 000, which > cannot be assigned to hosts in a real network because they are > unallocated space. > >> We need consistency with RFC 7608 (BCP 198). > > > No, we don't. RFC 7608 is about forwarding, not address assignment. But forwarded packets reach assigned addresses. Some situations can be unfortunate, such as forwarding a /65 to an address containing a 64bit IID. Consistency is desirable. Alex > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue May 30 11:51:30 2017 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 79F19129440; Tue, 30 May 2017 11:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 x-w0MmMXzvHX; Tue, 30 May 2017 11:51:19 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 E890B129420; Tue, 30 May 2017 11:51:18 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id u75so76024345qka.3; Tue, 30 May 2017 11:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=l+siWs4Zxd8827PTbYgaDszkKJi+QRaL/JSUSnlwXlw=; b=rexeH9Xx3zQGdZnCKTnugG3512pXBNSKKOYrauzIAkNstIRWRzCBzCw0KKfon7pylH +lmlgbJC5x8dy/+HWMwpM0huHXXl22NJK0epKHcyoBW4CjfB7+N2L5bPXphMe8wug+2h nFzfczxWmkhGILm7o+YgXamLbBL/22gy5UN052Q9Cx+ujMBrABjXV8NhjirowugFl/Un fEvrmzMmwkIPyw64BE9sN5FCtHDfz3/TDfYy8PRyVMaWEFwmbNCLjE2y9EMpw2FsdYUe 1bUtkoyj06o0qEF9bvcm5k0GjCSP5Nqjze+n0RVTTQFJQMb0dQSlUU5Z9NqBYLveMu8D q01w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=l+siWs4Zxd8827PTbYgaDszkKJi+QRaL/JSUSnlwXlw=; b=jaC1MUh6Nb5SqkR8RJiUZ/Kp8DGUwanLtMNN7Qzsn8zUdZAYz/mmHnMbYI2zIUB/NH r0jggzE4RIyW49pevbuuto4pDWtGjhSbKzilfz/EVisJcYrlkbBUgrqXquwxZYK0kT6T tWWJn1i9/N68u5iP+1UHP+WyhK8MRHTEBagK6gxTmkbQ7MTHFxZhuRCtmoLOx+UNf82D kpJBESFu2GGMU4+KH53dm0CrP54iv+77hRCXgT0QewsLqGPyow5A8/gLF9g+0+Mh4UB4 lUftLySSrGu/NndDFmm3WAWiOqHhtoJ66fiuMHjxojEBaDIRfay7a717wLHBa9prB27D CpQw== X-Gm-Message-State: AODbwcDoFnPS/0XPW83WDcl1P8YwypplM4c46WJPpW/SgxWNqsz/DlqB mjrlVpp2XK273o9xDyxYfvyMuvVtnQ== X-Received: by 10.55.104.129 with SMTP id d123mr26987944qkc.126.1496170278051; Tue, 30 May 2017 11:51:18 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.48.141 with HTTP; Tue, 30 May 2017 11:51:17 -0700 (PDT) In-Reply-To: References: <149556850339.28443.2716896366216678645.idtracker@ietfa.amsl.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 30 May 2017 11:51:17 -0700 X-Google-Sender-Auth: 0gfMttB0zGD93h3h_yqDAWPhgTs Message-ID: To: Brian E Carpenter Cc: IETF Discussion , "v6ops@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Last Call: (Unique IPv6 Prefix Per Host) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 18:51:22 -0000 At Sat, 27 May 2017 08:24:39 +1200, Brian E Carpenter wrote: > This draft cites RFC4862 (SLAAC) and mentions Router Advertisements > (without also citing RFC4861, which is possibly a mistake). Those > documents do not specify the subnet prefix length. So the draft > shouldn't assume a particular prefix length either. We all know that > it's usually 64 today, but that doesn't affect the argument made by > the draft. We need consistency with RFC 7608 (BCP 198). It looks like this draft has the commonly seen confusion I tried to clarify in my own draft: draft-jinmei-6man-prefix-clarify-00 Specifically, in Section 4 v6ops-unique-ipv6-prefix-per-host-03 states: This RA contains two important parameters for the EU/subscriber to consume: (1) a /64 prefix and (2) flags. [...] o A-flag = 1 (The UE/subscriber can configure itself using SLAAC) [...] o L-flag = 0 (The UE/subscriber is off-link, which means that the UE/subscriber will ALWAYS send packets to its default gateway, even if the destination is within the range of the /64 prefix) Since A-flag=1 and L-flag=0, this /64 prefix is an "SLAAC subnet prefix" but not an "on-link prefix" (using the terminology introduced in draft-jinmei-6man-prefix-clarify-00). And, in that sense, the "which means..." part could even be misleading in that it might read as if this (SLAAC subnet) prefix were somehow related to an on-link prefix. I'd also note that "The UE/subscriber is off-link" is not accurate. When L=0 "the advertisement makes no statement about on-link or off-link properties of the prefix" (RFC4861 Section 4.6.2). See below for a specific suggestion to fix it. As for the reference to the specific number of 64, I think it's okay with this clarification, the fact that that's the only possible SLAAC subnet prefix length today in practice, and the intended status of this document (BCP). But I also tend to agree with Brian in that this document could be more clarified to avoid confusing and/or misleading readers. My high level suggestion is: - clearly state that the prefix in this document is a kind of "SLAAC subnet prefix" but not an "on-link prefix". I understand "SLAAC subnet prefix" may not be the best choice since this document doesn't limit the address configuration method to SLAAC - hence "a kind of". But the main point is that it's better to explicitly clarify the prefix is one and the only one of the two kinds of prefixes advertised via RA PIO. With this clarification, and fixing the error I pointed out above, the description for the L-flag would look something like this: o L-flag = 0 (the prefix is not an on-link prefix, which means that the UE/subscriber will NEVER assume destination addresses that match the prefix are on-link and will ALWAYS send packets to those addresses to its default gateway.) - if it refers to a specific (SLAAC subnet) prefix length of 64, explain that it's the SLAAC subnet prefix length derived from the current addressing architecture for unicast IPv6 addresses starting with the binary value 000 (and those are only addresses used in production today). It might also note that future specification may or may not introduce a different prefix length for different ranges of addresses, but that's out of scope of the document as a BCP. -- JINMEI, Tatuya From nobody Tue May 30 12:40:08 2017 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 6F0641292FD for ; Tue, 30 May 2017 12:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 81KeR67UR2Lp for ; Tue, 30 May 2017 12:40:05 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2642F1250B8 for ; Tue, 30 May 2017 12:40:05 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id w10so124939432oif.0 for ; Tue, 30 May 2017 12:40:05 -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 :to; bh=K/zYh8LEHLP6Rll3dkc54pCpXH04ZIiDDjDD4joAGrk=; b=apt70gZBpJtm0Qax3mJdghDvSeEdlx48bugPknRl3IcWvhsrwSVje094gQXXbgTSFg Io8/sSZC1A9xDJNspRzjewMh2AI27+i/JYSmwU+ArrZj4brQWW4nXvtVsfivF3R1KD/G j4+BRm5XPUbmzqPq9oe3w4hW6Kaz23UKxyPXulnkAVZXHs6RW4v+hs/oOUIedVVvT6Vx ZhrWG2vb7Z8t9KC7Etc7qQak1bP+J43Y30zUeYXAnmp+OBa1bQLktceeLET4r0rIRMuW jqQgFuWZvWmzx41fP4VoSpT4pwJN93qT6KqHScESp/lo58d197XxpQ8Ucl88yd/pNgGK HWhg== 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:to; bh=K/zYh8LEHLP6Rll3dkc54pCpXH04ZIiDDjDD4joAGrk=; b=fp/Jh2Fq0UIlLEvKoXIVkArn49IgJ1/Gox//ay1L7jDVY0clOERWfJXwM+itA3a+gR Gl1wjSaphFQ2j1WvGiX+/8EAzO7Ejj/D8dx68r3ekbcVQffrJ7aIuhoK48qR0BeqP+AY Vgi/IrTsVeVPHP/9iAdonrsC2klmSrdJlHoaY3UVzQMFWGB/kLRu4Q/fmb4kSSTLA8bR dZeC3I6e5trVNHNi1a20TEPYwRfRGixjQoeE/bTeUry1BB2LND6R9z9aWTJ1P3Y3ZKFl YPuYCpl+lAxpeJNBNN2QX4O5VYVmqS7M0dIbOSFJVSe4ZwNFyL5+M0plR9YhmL6LwQjP aJvg== X-Gm-Message-State: AODbwcAfXFvsSHP+osDvcs6wjULtVxcyco7vqPISgq1F0V0+IHvV9AnF ARqPM7F635/TAVkXadM= X-Received: by 10.157.11.110 with SMTP id p43mr9567200otd.215.1496173204154; Tue, 30 May 2017 12:40:04 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1da::1007? ([2600:8802:5600:1da::1007]) by smtp.gmail.com with ESMTPSA id u51sm6236857otu.54.2017.05.30.12.40.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 12:40:03 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <16DFA7BD-E41E-4955-AFC0-1911109518F7@gmail.com> Date: Tue, 30 May 2017 12:40:02 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 19:40:06 -0000 IESG: In Last Call 2017-05-23 draft-ietf-v6ops-unique-ipv6-prefix-per-host 2017-05-22 draft-ietf-v6ops-v4v6-xlat-prefix WG: Unupdated WG Document 2017-03-13 draft-ietf-v6ops-ula-usage-considerations WG: Updated WG Document 2017-05-29 draft-ietf-v6ops-rfc7084-bis 2017-05-05 draft-ietf-v6ops-ipv6rtr-reqs 2017-04-10 draft-ietf-v6ops-rfc6555bis Individual Submission: Unupdated=20 2017-03-27 draft-templin-v6ops-pdhost 2017-03-13 draft-gont-v6ops-host-configuration 2017-03-13 draft-petrescu-v6ops-ipv6-power-ipv4 2017-02-24 draft-shi-v6ops-caba 2017-01-28 draft-xli-v6ops-cernet-deployment For IETF 99, we expect to have two presentations. One is from Marcus = Keane of Microsoft, regarding their effort to turn IPv4 off in their = corporate network. The other is from Vaibhav Bajpai, TU Munich, "A = Longitudinal View of Dual-stacked Websites =E2=80=94 Failures, Latency = and Happy Eyeballs". In both cases, we are looking at IPv6-only = networking issues. We will also have discussion of each of our four = active working group drafts (ula-usage-considerations having been = updated just before IETF 98 and not discussed).=20 If folks have additional drafts they would like to discuss, now would be = the time to file them, and then promote discussion on the list. We can = add drafts to the agenda that the working group expresses interest in.= From nobody Tue May 30 12:57:18 2017 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 544101292FD for ; Tue, 30 May 2017 12:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 3qvxkTVfK8vo for ; Tue, 30 May 2017 12:57:15 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 E69551250B8 for ; Tue, 30 May 2017 12:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1496174235; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=crqHWgRhaypSUFgDfQzA4ZtekQoD7a5ORMA7/J5dr8Q=; b=Q2d0WFLqaDwYfq4C0gXbu5K6VttpmXqwycWEOabEOl4cjAX7bxHOXeE2nT89ytGA RH/L9xpWhRsSF3eTRzlCuo2LwtDTWr9gNWoVN6XYBrqikakKE1wnk02B0qKrfNgW GDUOUV0+apEUWCnqi4Bk9eqjzypVFW0DxipzHo5wmivn2+M5gJvRCbyHPDRz0CLN +tycbQ2mDxa7gzbYRlcREFZIpAkHe6jINkNFfx4BsLk2nFF3O68XdqPU+dw1Gd6o +yKE7w5Tz/ugldJ8Mas5QuYMO+E7b41GgZeJisZLJA2v+LNVi/QL7/yuyRe1u22y RDV3Q4ZUI2fX4ZQ/DL3VMg==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 6D.F3.01595.B9ECD295; Tue, 30 May 2017 12:57:15 -0700 (PDT) X-AuditID: 11973e13-caa429a00000063b-d2-592dce9bbc46 Received: from koseret (koseret.apple.com [17.151.62.39]) by relay8.apple.com (Apple SCV relay) with SMTP id BC.92.21490.B9ECD295; Tue, 30 May 2017 12:57:15 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.226.23.80] (unknown [17.226.23.80]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OQS00EZ27FF5Z80@koseret.apple.com>; Tue, 30 May 2017 12:57:15 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <16DFA7BD-E41E-4955-AFC0-1911109518F7@gmail.com> Date: Tue, 30 May 2017 12:57:14 -0700 Cc: Tommy Pauly , IPv6 Ops WG Content-transfer-encoding: quoted-printable Message-id: <780329DC-449B-4775-ADDC-C26A8289230C@apple.com> References: <16DFA7BD-E41E-4955-AFC0-1911109518F7@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUi2FCYpjv7nG6kwYtLeha3vzawWpw+tpfZ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MrY/OIVc8E/voqLG+UaGPfxdDFyckgImEjc a3jO3MXIxSEksIZJYv75+ewwieNbZrNBJFYxSnw5uosRJMErICjxY/I9li5GDg5mAXWJKVNy QcJCAs1AzQsSQGxhAWmJrgt3WSFsJYlNz/8xgZSzCWhJHFhjBBLmFLCV2Na0nA0kzCKgKvF3 jQpImFnAQeLyy4csELa2xJN3F1ghltpILDo4gR1ik43E/yO3mEFsEQFNidvrpjFBXCwrcWv2 JbBXJARWsEn8fLyJfQKj8CwkR89COHoWkhULGJlXMQrlJmbm6GbmmeolFhTkpOol5+duYgSF 9HQ74R2Mp1dZHWIU4GBU4uE1KNONFGJNLCuuzD3EKM3BoiTOq9wPFBJITyxJzU5NLUgtii8q zUktPsTIxMEp1cDY6au1+pHowvr6jLULOhXEpghf517ffHXjNq+KmGeeklqvpbP5E7L4hHR3 BG9StPh6aNcE7x9/s+Pb9CYdlYuSVVK2s8p8MKN0wd9P8ufVGfK5Ttyafj3njO6vA18/3Iyf ZWLeuKPYn9N+1aMZebtn3f0++eTU21aWiy3CNezuGP7nWB0rvqhLiaU4I9FQi7moOBEAKqUA z0oCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42IRnG6nrjv7nG6kwcQmBYvbXxtYLU4f28vs wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGVsfvGKueAfX8XFjXINjPt4uhg5OSQETCSO b5nN1sXIxSEksIpR4svRXYwgCV4BQYkfk++xdDFycDALqEtMmZILEhYSaGaSmL8gAcQWFpCW 6LpwlxXCVpLY9PwfE0g5m4CWxIE1RiBhTgFbiW1Ny9lAwiwCqhJ/16iAhJkFHCQuv3zIAmFr Szx5d4EVYqmNxKKDE9ghNtlI/D9yixnEFhHQlLi9bhoTxMWyErdmX2KewCgwC8mdsxDunIVk 6gJG5lWMAkWpOYmVFnqJBQU5qXrJ+bmbGEEh2FCYtoOxabnVIUYBDkYlHl6DMt1IIdbEsuLK 3EOMEhzMSiK8748BhXhTEiurUovy44tKc1KLDzFWAb0ykVlKNDkfGB95JfGGJiYGJsbGZsbG 5ibmVBFWEue9skY7UkggPbEkNTs1tSC1CGY5EwenVAOjfYWi5tdvYso8xm0Jj27sW7JQr3PB efWDs20C2iW9bvotlTzwr4d/H/fch7fSDq9ytGq8XXrous66pWG3pnmFfvXmk/9jvrisWfzw in+6xR+emvu85vJ+dLDKWH5eHRvfBU4xvsQ6KUPBuJ2S66eHKEyfHtP30PZu6TzHZWo7Lb4U TylhfGOqxFKckWioxVxUnAgArG7ImpwCAAA= Archived-At: Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 19:57:17 -0000 Hi Fred, We're planning on adding a NAT64 section to draft-ietf-v6ops-rfc6555bis, and would like to discuss that and other updates since Chicago at = IETF99. Would it be possible to get a slot on the agenda? Thanks, David > On May 30, 2017, at 12:40, Fred Baker = wrote: >=20 > IESG: In Last Call > 2017-05-23 draft-ietf-v6ops-unique-ipv6-prefix-per-host > 2017-05-22 draft-ietf-v6ops-v4v6-xlat-prefix >=20 > WG: Unupdated WG Document > 2017-03-13 draft-ietf-v6ops-ula-usage-considerations >=20 > WG: Updated WG Document > 2017-05-29 draft-ietf-v6ops-rfc7084-bis > 2017-05-05 draft-ietf-v6ops-ipv6rtr-reqs > 2017-04-10 draft-ietf-v6ops-rfc6555bis >=20 > Individual Submission: Unupdated=20 > 2017-03-27 draft-templin-v6ops-pdhost > 2017-03-13 draft-gont-v6ops-host-configuration > 2017-03-13 draft-petrescu-v6ops-ipv6-power-ipv4 > 2017-02-24 draft-shi-v6ops-caba > 2017-01-28 draft-xli-v6ops-cernet-deployment >=20 >=20 > For IETF 99, we expect to have two presentations. One is from Marcus = Keane of Microsoft, regarding their effort to turn IPv4 off in their = corporate network. The other is from Vaibhav Bajpai, TU Munich, "A = Longitudinal View of Dual-stacked Websites =E2=80=94 Failures, Latency = and Happy Eyeballs". In both cases, we are looking at IPv6-only = networking issues. We will also have discussion of each of our four = active working group drafts (ula-usage-considerations having been = updated just before IETF 98 and not discussed).=20 >=20 > If folks have additional drafts they would like to discuss, now would = be the time to file them, and then promote discussion on the list. We = can add drafts to the agenda that the working group expresses interest = in. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue May 30 13:25:08 2017 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 7923D1292F4 for ; Tue, 30 May 2017 13:25:07 -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 Ha9AjwQDsyjH for ; Tue, 30 May 2017 13:25:05 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 BD8031292CE for ; Tue, 30 May 2017 13:25:05 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id w10so17638322oif.1 for ; Tue, 30 May 2017 13:25:05 -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=rKmPzCvwfAa5TgAPzlxSrl7zobndC4sK1pijsxTKnkc=; b=a2W80BZ2g8vYjXSY3+5fPP59yPyrKZE5hEj3Q41YJiQZMUrXXPhgsF72mR3qiXNHK3 5Cp0xXF0IohLRVuUkeA3ILGyYEMp8hjUFbpHQ5GKTxsNMjEEqX4lfcWUf1Q4Df5CyGAX wqN29epya4EliouwFghRB2EypN6P1RhZab8ECylQcr6YqUbNehPGZ3LRT2SkiyWLkpRo ie3Mz6Ae89LVi3wW+Y4/GvK1oDvWufCd/bCIXwzgOg71tUHZYL2UZsAUlx/G5csJGIwU X8j2lKkbgz5xM33FEqa5EVnq81eji5OZQc7jKtt5SwUNj8OlPgWbsJBLaqFvbNrVfUIp Oqzg== 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=rKmPzCvwfAa5TgAPzlxSrl7zobndC4sK1pijsxTKnkc=; b=dqJlh5Gi9yzv79E80ntWvAwpQHN7hAX9oFn5LVmtwPF//d6xMooe/Yxq0eATly0Ygv jdnzo34YcqILClEBA9Hdircfybrp2k2ptAOU3k02iZYwbDsM3YNeQcqwYIYmEPl2IyNQ LheOtUZStnZWk7E8N+JG5yo0rt2l0r4OAhU7GyMq/cnr2kRI2KvzX8pLmYM5s8Mr6IE5 GeXitUqr1saEV4J8c2sRiCJcovOTA0dKqF0FbZj8I6g/cKsFnGN/LYLiJcGgTvSHUxQH DHGC5xc9yJFdv5um+/gQgaMsfcAWyLGZHOaBY4JsWaLaJjUZ+9KekA0n63WWhEN9Dl/T wlTw== X-Gm-Message-State: AODbwcDCXIsNEkD+E/MCT2rL2MyhzRiekzQIsElOIWPPvoA4eJV5PVoH J5PuE0DoZUzIFQ== X-Received: by 10.157.56.104 with SMTP id r37mr9833321otd.239.1496175905194; Tue, 30 May 2017 13:25:05 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1da::1007? ([2600:8802:5600:1da::1007]) by smtp.gmail.com with ESMTPSA id q206sm6304157oif.0.2017.05.30.13.25.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 13:25:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Fred Baker In-Reply-To: <780329DC-449B-4775-ADDC-C26A8289230C@apple.com> Date: Tue, 30 May 2017 13:25:02 -0700 Cc: Tommy Pauly , IPv6 Ops WG Content-Transfer-Encoding: quoted-printable Message-Id: <90A8188A-B538-4A45-96DC-D31C1DA6A81E@gmail.com> References: <16DFA7BD-E41E-4955-AFC0-1911109518F7@gmail.com> <780329DC-449B-4775-ADDC-C26A8289230C@apple.com> To: David Schinazi X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 20:25:07 -0000 I said I expected discussion of our four WG drafts. This is one of them. = So, yes. Please update it and plan to discuss the changes from IETF 98. > On May 30, 2017, at 12:57 PM, David Schinazi = wrote: >=20 > Hi Fred, >=20 > We're planning on adding a NAT64 section to = draft-ietf-v6ops-rfc6555bis, > and would like to discuss that and other updates since Chicago at = IETF99. > Would it be possible to get a slot on the agenda? >=20 > Thanks, > David >=20 >=20 >> On May 30, 2017, at 12:40, Fred Baker = wrote: >>=20 >> IESG: In Last Call >> 2017-05-23 draft-ietf-v6ops-unique-ipv6-prefix-per-host >> 2017-05-22 draft-ietf-v6ops-v4v6-xlat-prefix >>=20 >> WG: Unupdated WG Document >> 2017-03-13 draft-ietf-v6ops-ula-usage-considerations >>=20 >> WG: Updated WG Document >> 2017-05-29 draft-ietf-v6ops-rfc7084-bis >> 2017-05-05 draft-ietf-v6ops-ipv6rtr-reqs >> 2017-04-10 draft-ietf-v6ops-rfc6555bis >>=20 >> Individual Submission: Unupdated=20 >> 2017-03-27 draft-templin-v6ops-pdhost >> 2017-03-13 draft-gont-v6ops-host-configuration >> 2017-03-13 draft-petrescu-v6ops-ipv6-power-ipv4 >> 2017-02-24 draft-shi-v6ops-caba >> 2017-01-28 draft-xli-v6ops-cernet-deployment >>=20 >>=20 >> For IETF 99, we expect to have two presentations. One is from Marcus = Keane of Microsoft, regarding their effort to turn IPv4 off in their = corporate network. The other is from Vaibhav Bajpai, TU Munich, "A = Longitudinal View of Dual-stacked Websites =E2=80=94 Failures, Latency = and Happy Eyeballs". In both cases, we are looking at IPv6-only = networking issues. We will also have discussion of each of our four = active working group drafts (ula-usage-considerations having been = updated just before IETF 98 and not discussed).=20 >>=20 >> If folks have additional drafts they would like to discuss, now would = be the time to file them, and then promote discussion on the list. We = can add drafts to the agenda that the working group expresses interest = in. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Wed May 31 01:10:17 2017 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 80FE3126BF6 for ; Wed, 31 May 2017 01:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 6jD_73Bf7_eG for ; Wed, 31 May 2017 01:10:14 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEF71200B9 for ; Wed, 31 May 2017 01:10:14 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 5BFF3100638; Wed, 31 May 2017 10:10:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 3BFA6C0072; Wed, 31 May 2017 10:10:12 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0339.000; Wed, 31 May 2017 10:10:11 +0200 From: To: "jordi.palet@consulintel.es" , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt Thread-Index: AQHS2ItrruE1LgJmVECmPD99k+NfaKIOElIA Date: Wed, 31 May 2017 08:10:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E76580@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <149606921435.3762.14727398533646344700@ietfa.amsl.com> 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.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 08:10:16 -0000 Hi Jordi,=20 Thank you for updating the draft. Below the comments that I do think are st= ill open: * Remove citations to individual I-Ds from the draft.=20 * I'm not sure to understand the motivation for LW4O6-5. Please note that t= his is not equivalent to DSLITE-4 for the simple reason that in DS-Lite the= re are no IPv4 address assigned to the CPE from the network, while there is= one for lw4o6. I suggest to delete LW4O6-5. =20 * Unless I'm mistaken, I don't remember there was a conclusion about obsole= ting RFC7084 or not. =20 Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET > MARTINEZ > Envoy=E9=A0: lundi 29 mai 2017 16:54 > =C0=A0: v6ops@ietf.org > Objet=A0: Re: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt >=20 > Hi all, >=20 > This is an updated version of this document, including the following > changes: >=20 > 11. ANNEX D: Changes from RFC7084-bis-01 >=20 > Section to be removed for WGLC. Significant updates are: >=20 > 1. G-5 added in order to comply with [RFC7608]. >=20 > 2. LW4O6-5 removed. >=20 > 3. MAPE-3 removed. >=20 > 4. MAPT-3 removed. >=20 > 5. Included non-normative reference to [RFC7849] to clarify that the > details of the connectivity to 3GPP/LTE networks is out of the > scope. >=20 > 6. Split of transition in two sub-sections for the sake of clarity. >=20 > 2, 3 and 4 above (added in the previous version) were referring to the > explicit mention of NAT behavior. As each mechanism has the relevant text > in its respective RFC, I leave that to those documents, to avoid any > misunderstanding or conflict. >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: v6ops en nombre de > Responder a: > Fecha: lunes, 29 de mayo de 2017, 11:46 > Para: > CC: > Asunto: [v6ops] I-D Action: draft-ietf-v6ops-rfc7084-bis-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations of the IETF. >=20 > Title : Basic Requirements for IPv6 Customer Edge > Routers > Author : Jordi Palet Martinez > Filename : draft-ietf-v6ops-rfc7084-bis-02.txt > Pages : 30 > Date : 2017-05-29 >=20 > Abstract: > This document specifies requirements for an IPv6 Customer Edge (CE= ) > router. Specifically, the current version of this document focuse= s > on the basic provisioning of an IPv6 CE router and the provisionin= g > of IPv6 hosts attached to it. The document also covers several > transition technologies, as required in a world where IPv4 > addresses > are no longer available, so hosts in the customer LANs with IPv4- > only > or IPv6-only applications or devices, requiring to communicate wit= h > IPv4-only services at the Internet, are able to do so. The > document > obsoletes RFC 7084. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc7084-bis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis-02 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc7084-bis-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc7084-bis-02 >=20 >=20 > 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. >=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 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops