Re: NAT64 in RA, draft-ietf-6man-ra-pref64

David Farmer <farmer@umn.edu> Fri, 26 July 2019 21:58 UTC

Return-Path: <farmer@umn.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843AD120181 for <ipv6@ietfa.amsl.com>; Fri, 26 Jul 2019 14:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.056
X-Spam-Level:
X-Spam-Status: No, score=-3.056 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, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3nokGelorr_T for <ipv6@ietfa.amsl.com>; Fri, 26 Jul 2019 14:58:06 -0700 (PDT)
Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 D22B3120173 for <6man@ietf.org>; Fri, 26 Jul 2019 14:58:06 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 573F9A5F for <6man@ietf.org>; Fri, 26 Jul 2019 21:58:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtC7g0UdZm82 for <6man@ietf.org>; Fri, 26 Jul 2019 16:58:06 -0500 (CDT)
Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 18F789CF for <6man@ietf.org>; Fri, 26 Jul 2019 16:58:05 -0500 (CDT)
Received: by mail-vk1-f200.google.com with SMTP id x83so23412704vkx.12 for <6man@ietf.org>; Fri, 26 Jul 2019 14:58:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vco+5p7VXqe0tJ4uAaYjLpu6fxrCyJ8MXLuKuwutb6I=; b=HIeulxj5Ehg4ZdAfL6aXXVUsVdZXBOpL3Gy23Cqj/CFrdsvZ8CQ5KqhEsEAJybrWV0 Se0g15wpHeYPktiINZfFBaG7KB5ppvMIZBdyv2JdXLZv2mpdRW2JvDTyjHLPqgf3tskv fDcvHqYhUbRMelv22cB55GDlSIkCvrK3XF5stBmJahkuGrDYfcw8BeX5AijAdNiqOcfQ VMAGN6ikQYfjWTzvN91QMY19sVOP8f6/pEeociYhJOyC1BACIqIpNyQ5cvc+//gEQyQZ YXk8TFhUWhLU48qCUc/2vyswC9I9p74f7t1rP8drQtG5lirOBp2V0iOQDQ00ySlkD7Ui uS8A==
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=Vco+5p7VXqe0tJ4uAaYjLpu6fxrCyJ8MXLuKuwutb6I=; b=ahMEL7xdO90+tqaD35lVW1XZNCFn+Xd8DOpVBO3dyTcA+KaD/9omZdno2JvH3TIAc/ bbTgyy9A5NlUbWWH0GIhO9/Z+eEQcDkueUmtcQvqvqM2Jx7fQM8ngnhGEty5TK71K98P gpBd0wOb0JvGWmilf3efVV/ybbofBV06x/VszTDe0S0wb98xitHR73Z/oMRa7QDaxzcq mkrGasfbGzVHdq2MFV3FoIpTqhxXShj/Fjr2bBuQKc1ipCrxHSVGElfNR5yl79P31Wds /PhZZNQdLGnmMMBeXGBcxLNsdqpu5WdrNkjoaDxOl2Dqf3z0oR2tMo/87Ww/3MoLIqvf EJ6g==
X-Gm-Message-State: APjAAAWUa8HgKpWqn16CnDg3ZTmjjiU5qPsopiexjryf5eRniIBXNiMG VPJ9kfTXWSMI83Zan6qaFE4/W21ixgTKwvKi0wupRQIoBGjjgma47hmamXCY13juNA+pZ72dilq TX95xd73vI14QkrKFRg14upd/
X-Received: by 2002:a67:a209:: with SMTP id l9mr65965854vse.125.1564178284760; Fri, 26 Jul 2019 14:58:04 -0700 (PDT)
X-Google-Smtp-Source: APXvYqwvxvxcoYcE2EtBOrgGF9iO6/8Pn+pjlkhssIFcrQ0v+HI/Ef/04dlzfhiAKCKwKe+9TyWLiPAXW14/9YtS/Gc=
X-Received: by 2002:a67:a209:: with SMTP id l9mr65965832vse.125.1564178284076; Fri, 26 Jul 2019 14:58:04 -0700 (PDT)
MIME-Version: 1.0
References: <12187.1558972629@localhost> <D3C7EB41-02E8-48D6-9335-26A041FD64C2@isc.org> <00C00FE5-C7CD-4B99-A2C9-CCBFCB1E4850@isc.org> <CAFU7BASfJ4YS6xBzK8hNJRSMnFZmdn3VE5A=sPCC3JqRa8SQEQ@mail.gmail.com> <EC63A89D-26CD-4093-8814-4461B6D3D327@isc.org> <CAFU7BASsAwitEc==Zj6qT4izy-tFosg23DHXFVVzOixidEfMFA@mail.gmail.com> <CAKD1Yr3jDTS25ERGZYDDM9yRRTxEfY4Ltcd-QgFNor6ze2G7xA@mail.gmail.com> <6053.1561748461@localhost> <CAFU7BAR9kmnk3Q9aOpsqGFVRZkiRXb0FkZjMXWG2gN0-o1MjGw@mail.gmail.com> <0167874A-F2B4-434A-B674-792FE3AD0E2D@gmail.com> <CAFU7BAT2zw2+EnLW_MZnj2L9RBwH2DyStgRUbaY6bCZLuJwG9g@mail.gmail.com> <CAKD1Yr2mzeVzXFmzh3N21MCr-sg1xJ9D67TPqvEd9YffCrzdqA@mail.gmail.com> <CAN-Dau3qMAH0KAfahjFgN2-mMttmwpM4wEt4vypAxZcvUXB=gQ@mail.gmail.com> <CAFU7BAShnFAApACS2+fBH7oqqLrO1oHCxm78jjnJrCPnvFtVFg@mail.gmail.com>
In-Reply-To: <CAFU7BAShnFAApACS2+fBH7oqqLrO1oHCxm78jjnJrCPnvFtVFg@mail.gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Fri, 26 Jul 2019 16:57:47 -0500
Message-ID: <CAN-Dau2WXL4_rV8Rv2kvB0zxhJDy4F5CTtdYL+sdPA1h=UUmRw@mail.gmail.com>
Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64
To: Jen Linkova <furry13@gmail.com>
Cc: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, 6man <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fcf65a058e9ca221"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/29BmDn3pUuSgdZpy5xQkIEJ2kes>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2019 21:58:10 -0000

On Tue, Jul 2, 2019 at 8:11 AM Jen Linkova <furry13@gmail.com> wrote:

> On Tue, Jul 2, 2019 at 10:09 PM David Farmer <farmer@umn.edu> wrote:
> > I mostly agree, but there is a scenario I've been thinking about;
> >
> > What if the network operator doesn't want RFC1918 and RFC 6598 IPv4
> addresses synthesized at all? I suppose the NAT64 function could block
> these addresses. However, for a large enough population that could be a lot
> of useless traffic going to the NAT64 function. While on the other hand
> some network operators, especially enterprise operators, will probably want
> these addresses synthesized.
>
> Oh funny you should mention that..I've been thinking about it but have
> not managed to untangle the chain of RFCs yet...
>

Actually, I was rereading the draft and found a possible answer for my
scenario already partially discussed in the draft.

Section 4, paragraph 2, says;

   This option specifies exactly one NAT64 prefix for all IPv4
   destinations.  If the network operator desires to route different
   parts of the IPv4 address space to different NAT64 devices, this can
   be accomplished by routing more specifics of the NAT64 prefix to
   those devices.  For example, if the operator would like to route
   10.0.0.0/8 through NAT64 device A and the rest of the IPv4 space
   through NAT64 device B, and the operator's NAT64 prefix is
   2001:db8:a:b::/96, then the operator can route
   2001:db8:a:b::a00:0/104 to NAT64 A and 2001:db8:a:b::/64 to NAT64 B.

One answer for my scenario is if the NAT64 prefix is 2001:db8:a:b::/96,
then null route or filter traffic for 2001:db8:a:b::a00:0/104 and the other
RFC1918 blocks in the network ahead of the NAT64 function, then it won't
see the traffic.

Maybe add something about filtering or null routing as well as routing to
an alternate NAT64 function to the above paragraph.

Thanks.

-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================