Re: [v6ops] GRASP

Mark Smith <markzzzsmith@gmail.com> Sun, 14 January 2018 03:54 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED73126579 for <v6ops@ietfa.amsl.com>; Sat, 13 Jan 2018 19:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.326
X-Spam-Level:
X-Spam-Status: No, score=0.326 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.626, 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 IkDLtvbnZCse for <v6ops@ietfa.amsl.com>; Sat, 13 Jan 2018 19:54:44 -0800 (PST)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 C3D14120713 for <v6ops@ietf.org>; Sat, 13 Jan 2018 19:54:44 -0800 (PST)
Received: by mail-vk0-x22e.google.com with SMTP id k132so5751500vke.10 for <v6ops@ietf.org>; Sat, 13 Jan 2018 19:54:44 -0800 (PST)
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:content-transfer-encoding; bh=e5Lfl2ylPRhG+pxtQn3ivEXjtsqcWC0MTkwqc9zA92I=; b=G/jQuliKBA1opRtdl+K5O3oNV1ZgCfWwhoICNQ2wEKkVwSlfDz61LhmdaGvsYU9HjW Fog7J+1UJx3aei6Ttf6sAy5miprPZORdWlwAS0DDNk82JcUbLCR5ORreiMVKTTdCtT3l 4frVixX6rrmsJudiAT3NlCc29xfMBg7BYxPG0JTisZgbNOYZmyIzLc36rtSQHOGCLD4g 8fN2Zb9eRIXH4NGK3bugPCFZB3XhAoaYDdo7wbUDJ33SAB8mGFVV3pLcPgi8NNpaKBYS ZKIEIlla6gRoJhlQuM5yn7+04uAr2fyA/9/2weVXbdh02GK4WdWzhi6c17O7Mlf3RhLN 4ilg==
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=e5Lfl2ylPRhG+pxtQn3ivEXjtsqcWC0MTkwqc9zA92I=; b=nEI7IEQmXrx9HkxDveVPlr3hZoZbKY00BjEGUe4KTg5XKlsOl3qjfkO7TQlPF8me2B hpaBjX8Z0hL3K5nvWu2tfPmTl3KycPSYsTOnwqkZQtXUFx5XN9C41TnkFjB+XU9RD59k GSwzJ2vYDU/35MgNJm7N1u/WJqbULbaxjm9WpNQawWykmkwIJgiSUyhDVAoGpHK1TJvc fS01cME/4biEDEuebaeQwl6ORTij0TbLuryS5vX39hcAvBY/MEOy5iwMG6HD7aNrkM/t GDzY+klt61deq797q5sO5YXpeW04qfuEpgJzYGxQk1dM1z/jRB10bdF34WrwjTrlerMd bw3w==
X-Gm-Message-State: AKwxytfalT5Xz3KcvNzm6LIhNFh3o24l/XTYKsAK24DXmcScyWE0eP1e Fh3/yWaYU90dvRKX9qfM5GG4GP8NbOJXAaWAKiI=
X-Google-Smtp-Source: ACJfBosd0BNnH6YIVVVOWARJ2He7JSWK8RSrwKmyh9Jkbkp9M1kSN9PJrDrMi6GF5O1pShSKAQE/UbrjmM2jy4S0h6w=
X-Received: by 10.31.92.200 with SMTP id q191mr6744399vkb.151.1515902083560; Sat, 13 Jan 2018 19:54:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.53.99 with HTTP; Sat, 13 Jan 2018 19:54:13 -0800 (PST)
In-Reply-To: <B07B4644-B5DC-408E-8130-0832AFAE47E2@google.com>
References: <fc31bd170b134c8292d33f52400b175b@XCH15-06-08.nw.nos.boeing.com> <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> <B07B4644-B5DC-408E-8130-0832AFAE47E2@google.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sun, 14 Jan 2018 14:54:13 +1100
Message-ID: <CAO42Z2y6rO8S-F93J6BDcMzgkHb4-czuQd-1QArzM3MfO77EKw@mail.gmail.com>
To: james woodyatt <jhw@google.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, v6ops list <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LHOTV_g70tgDavGTAmE_OF4DtWg>
Subject: Re: [v6ops] GRASP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jan 2018 03:54:47 -0000

Forgot to send this, still useful I think.

On 28 December 2017 at 10:07, james woodyatt <jhw@google.com> wrote:
> On Dec 22, 2017, at 19:35, Brian E Carpenter <brian.e.carpenter@gmail.com>
> wrote:
>
>
> I don't see that argument for homenets. ISPs don't seem reluctant to hand
> out /64, /56 or /48 to paying subscribers. I can see that if you want to do
> something fancy while roaming, you might have to deal with a single /128.
>
>
> They are very reluctant to deploy CPE gateways that use any current or
> forthcoming protocol to delegate automatically any portion of their prefix
> to routers on home network links. In shorter terms, they are happy to hand
> out /56 (less so /48) to CPE edge routers owned by paying customers, but
> there is no appetite for supporting customers with interior routers
> downstream of the CPE edge router. Certainly not in their provider
> provisioned CPE gateway devices that are more often than not bundled in the
> service agreement and quietly included in the total charge for access. Oh,
> they might have plans to use that number space with some non-standard prefix
> distribution protocol, but it appears there is very little appetite for
> adopting any standard made available for third parties to use freely.
>
> That’s why anybody planning to offer consumers technology solutions that
> include IPv6 router functions running on nodes located behind CPE routers
> are forced to resort to address amplifying NAT to operate as a router on the
> downstream links and a host on the upstream home network link behind the CPE
> router. Just as happened with IPv4 for pretty much the same reasons. I’ve
> spent the better part of three years trying to avoid that conclusion, and my
> experience in V6OPS and HOMENET has led me to conclude that it was a badly
> wasted effort. NAT66 is the wave of the future.

Is NAT66 the only option?

It seems to me that one of the fundamental problems with NAT,
including 1:1 NAT, is that it is somewhere in between simple IP
forwarding based on the IP header, and full host/application
processing. The context and state held in the true end-host and
application is not available in the NAT66 device, and that is why it
can't do a fully transparent translation. The NAT device neither a
router or a host.

I wonder if it would be better to have the "NAT66" device be the true
application end-point for all communications, and then have it
communicate with the down stream devices "internally" via a ULA
address space, as internal application inter-process communication.
The external host/application then has all of the context and
application state necessary to function, so none of the NAT issues
occur. Internally, IPv6 with ULA address just happens be being used as
an application message bus between the downstream devices and the
globally reachable application endpoint.

If the downsteam devices need to have globally unique identifiers and
indirectly globally reachable and visible, they could be generic
UUIDs. They don't need to be IPv6 addresses, because all access to
them is via messages sent to the application with the global IPv6
address.




Regards,
Mark.




>
> --james woodyatt <jhw@google.com>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>