Re: [Anima] Is this how BRSKI/IPIP works?

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 15 July 2017 02:08 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5674F12F299 for <anima@ietfa.amsl.com>; Fri, 14 Jul 2017 19:08:22 -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 RFQwsBMBNToI for <anima@ietfa.amsl.com>; Fri, 14 Jul 2017 19:08:21 -0700 (PDT)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 E173F12EB4E for <anima@ietf.org>; Fri, 14 Jul 2017 19:08:20 -0700 (PDT)
Received: by mail-pg0-x232.google.com with SMTP id k14so53405467pgr.0 for <anima@ietf.org>; Fri, 14 Jul 2017 19:08:20 -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=1MdYbt6aPZQMxbbyC/BMMjnw0pebsSeDQHLwRnidW4g=; b=JgXCdTXDlnE6UqjOem3YLW5XaoaEamFBjyocsHWBnNQYuabMVvmBfsdLPzPnSBG3Gt NCpVIQ66kw06batN60E97Dg1HR6lWsa5VimQEcwGV7pnSF5Kw4q1hc24Q3iJv04m0+cb bWGS1Tz7A94XmODj+6eWHr1WFWNsNBLBVzs3Egp7RcAju8NGk9YM8jVkSCgSFEQ7ByJ5 mAMiZvlbAYxXvgfewr7w0bf5VZOFB+wEEEE2Vq7/McMEy9RgRraoX+Jhnqqy0M9mVedq jAcbVQXtiMJAiYi8lDP+ZiCRB0Kefa0ghqG7Y/nktD8KJiRfATNRfRY+jcy6GcKYoTWm 4VUQ==
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=1MdYbt6aPZQMxbbyC/BMMjnw0pebsSeDQHLwRnidW4g=; b=qgmZ1rlLDdzl631SiXffL+1IrIPBlRbs1Z29rOqf8zO+RIMo0o1AzY8CKR2ZMNaPio v8MPzaIHCLJL1USEE+TVT2PSSwFIf7/tyHNiv8RLpyt0zI6fCkE2ptH/DJpPOE/Da85e HKlH6pwt/Pz1ru7y6uqveXrbZPSaqtTsPwW7FhguHn5mfb7CMxLTu4MsyQjaFZ4jEwYC 4HEV086yzoF+lTPMEKszSChKzltI/04PcAR0B26e8rARQU2nAdEeNG1tdQGoza2mXR6r 0/fSEhCNUTTuWkzC5WGr3GUDDcbafDJNux+hR7sW9RHmTe0IMNLlK/p9awVc6uubo/z0 4gkg==
X-Gm-Message-State: AIVw111V4tGlCgQM5x605KshhwPieA/Ur2mZT1J8LjAFsuVBC+AN+qKx 6y1sYZxXdlb52bjN
X-Received: by 10.84.130.42 with SMTP id 39mr18746060plc.60.1500084500150; Fri, 14 Jul 2017 19:08:20 -0700 (PDT)
Received: from ?IPv6:2406:e001:55f4:1:28cc:dc4c:9703:6781? ([2406:e001:55f4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n3sm17333415pfb.87.2017.07.14.19.08.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 19:08:19 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Anima WG <anima@ietf.org>
References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <3a2a138d-df80-8231-918e-b7dd33ff4fd6@gmail.com> <25643.1499875039@dooku.sandelman.ca> <81be3d6c-d5b6-92a6-da3d-b10365e53964@gmail.com> <17795.1499938811@dooku.sandelman.ca> <ca5083c5-83b5-1733-601e-154258ac61a2@gmail.com> <7355.1500068682@dooku.sandelman.ca>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <0fba3423-b41b-7338-dc87-b851b0634d38@gmail.com>
Date: Sat, 15 Jul 2017 14:08:27 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <7355.1500068682@dooku.sandelman.ca>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/KAj-gQUqoXV2-eBRnEIcOXDvHls>
Subject: Re: [Anima] Is this how BRSKI/IPIP works?
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Jul 2017 02:08:22 -0000

On 15/07/2017 09:44, Michael Richardson wrote:
> 
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>     >> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > OK, I'm
>     >> getting there. More in line:
>     >> 
>     >> >> 1) Registrar accepts any Lx1 as local.  There is no precedent in v6
>     >> >> APIs to open such a socket, but this actually supported on many >>
>     >> platforms.  It's used for nasty stuff like transparent application >>
>     >> layer proxies, forced HTTP proxying, and the like.
>     >> 
>     >> > I think there's a more subtle way to look at it. When the registrar
>     >> > receives a protocol 41 packet from a new ACP address, it
>     >> conceptually > synthesises a new virtual interface and assigns Lx1 as
>     >> its link local > address. On that interface, things would look
>     >> normal. Thus RFC2473:
>     >> 
>     >> I can buy this.  It argues that the Proxy should send a gratuitous
>     >> packet to the Registrar to prime that virtual interface.  An ICMP echo
>     >> request perhaps.
> 
>     > Or a GRASP M_NOOP, designed for such purposes!
> 
> I think that's also reasonable.  
>  
>     >> How can we document this well?
> 
>     > I think it has to be spelled out almost at the pseudocode level. We had
>     > to spell out the encap/decap behaviour for 6to4 in some detail, and
>     > that was just about the only bit of 6to4 that never created trouble
>     > ;-). There are various encap/decap specs of that kind, and the NAT64
>     > stuff also goes into horrible detail...
> 
> okay.  Are you suggesting the 6to4 document should be looked at for style?

Not especially. I'm more saying: if you can't write the equivalent of 
pseudocode, you can't expect other programmers to get it right.

Maybe a really good example of a painstaking encap description
is in IPsec: RFC4301 section 5.1.2 and its subsections. I don't think
we need to go that far, but we need to be 100% unambiguous.

All IMHO of course.

   Brian