Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017

Brian E Carpenter <> Thu, 14 September 2017 23:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18E4D13219F for <>; Thu, 14 Sep 2017 16:05:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OtWq6Twhc-7q for <>; Thu, 14 Sep 2017 16:05:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A049113214D for <>; Thu, 14 Sep 2017 16:05:47 -0700 (PDT)
Received: by with SMTP id m63so450194pfk.7 for <>; Thu, 14 Sep 2017 16:05:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=7mf3O+AskTjQp7mCBWuSYum0wVNSOox9FV54G/r37M8=; b=WeY5NO6h9sh0JO0yy2mMieoRLlSXDChcVbeAEqW0qnyTYQQfOY8djUqkB2w0fNYMw6 BzmsaDQRkkN8QLtOlZPuW+lqiXF0sI/CaZPUerCw+Jxt8fiIRI2GNWjl2KjFET2JTVDa T3W9QFnAYhvJ2BUKbLN+eTomJEUa+XXzF6T3paFvPQqPY3Gw8LT6IjYZERaD5ttWJ8VV QOvs8ks9hr1gFzcas9BXAwgcoCVih54l5f2uBco7nS98ECaub0JWUnlld8+D8MA41meo bmhhNMd0xuvRfau3mRcv2wWPy2pubFARzzhObhOZAX1ojkO5PyHPVv3IFre4xQ90rIF0 xv+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=7mf3O+AskTjQp7mCBWuSYum0wVNSOox9FV54G/r37M8=; b=UH9laEXU7yENvJhLayfxrZ7naDtIxF7NFCbblBDu8DywE5SMwkIqCMwR5FKZiJTKHy ba3r+ThLjbAAR+AoOtyhjablLjd6qHsDlarw5pbb6M7l6pVS0FiPtZh/I6VycFx22T5C /1xIhQMTX5r98vDNZ4DM/DH1cGxDMjE7DXuiS2clg5592XCej+pqdNtzZMNbl0O4cSUg 0+y6Q1c8wIolbrx0065OovrbCQ6NC2m6HyWpc9sf3NL51KQPh3cWalrQkmQ3kZTnJjQB E/OKrI1THTpG18MTI9B8FZoWAxaItw4Vb+Hy62v0pJMkVHAhFHChlWyitL2gxHgjLuIQ u25A==
X-Gm-Message-State: AHPjjUhWBFnZTxP76RIFnkK8DmDcLc+w8hRIgJrfqqdjukZIOWEh66m6 i/Z59uyEcwabtP3f
X-Google-Smtp-Source: ADKCNb7TDzZ1yEtKVTH2LHbMttFRK0eaZYtENUaz1PIYYC/EU7shpwKIE5GIC4/IQP5YNA7q++Ifvg==
X-Received: by with SMTP id p19mr22440263pgc.303.1505430346545; Thu, 14 Sep 2017 16:05:46 -0700 (PDT)
Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by with ESMTPSA id u184sm30752321pfb.126.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Sep 2017 16:05:45 -0700 (PDT)
To: Toerless Eckert <>
Cc: Anima WG <>
References: <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 15 Sep 2017 11:05:51 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Sep 2017 23:05:50 -0000

To cut a long story short, here's a friendly suggestion. The goal is to avoid
comments during IETF/IESG review that the NAT text is too vague:

   To bridge an IPv4 only management plane with the ACP, IPv4 to IPv6
   NAT can be used.  This NAT setup could for example be done in Rt1r1
   in above picture to also support IPv4 only NMS hots connected to

   To bridge an IPv4-only management plane with the ACP, IPv4 to IPv6
   translation [RFC 6145] could be used. This could for example be done in Rt1r1
   in the above picture to also support IPv4-only NMS hosts connected to
   NOClan. Details of the address mapping to be used would depend on
   the exact scenario and are not specified here.

And yes, I like this:

> i'd suggest to replace the "split-horizon" sentence with:
> Operators may therefore need to use a private DNS setup for the ACP ULA
> addresses. This is the same setup that would be necessary for using
> RFC1918 addresses in DNS. See for example [RFC1918] section 5, last
> paragraph. In [RFC6950] section 4, these setups are discussed in more detail.


On 15/09/2017 09:18, Toerless Eckert wrote:
> Hi Brian, 
> Sorry, for the delay. I have not sen further feedback on stable-connectivity-05
> bside this mail of yours. See answers below, let me know if you want me to rev
> with the one possible textual improvement or if we think -05 is good enough.
> Cheers
>     Toerless
> On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote:
>> I'm just coming back on a couple of points. Generally -05 is almost there...
>>> See the rewritten SIIT section. IMHO, there can be no simpler "network" based
>>> address translation. Where network based means that the translation happens
>>> in some device he network operator needs to provision. Like the ACP edge device.
>>> Or even an additional address translation device.
>>> So, the only IMHO easier option is when the OS of the NMS host would internally
>>> have IPv4/IPv6 translation so the device/VM looks to the outside like full IPv6.
>> Yes, that is exactly the effect of 464XLAT in the end-system (not in the
>> router).
> I found rfc6877 a confusing read, but from what i figure, it's not exactly what
> i was thinking of: with rfc6877, you still need the server side to have a reachable/mappable
> IPv4 address, and that is something any device in the ACP does not have naturally.
> (aka: NOC server as client connecting to ACP device, ACP device is server).
> If i already need to set up some other form of NAT to give an ACP device an outside IPv4
> address, then 464XLAT does not buy me any simplifications.
> I was rather thinking of taking the NAT network function that i was describing
> and simply embody them in a set of linux NAT rules configured on on the NOC linux
> system that runs the IPv4-only NMS application. Aka: Not a novel NAT scheme,
> but just a way to avoid having to deal with the problem in the network (adding a NAT
> device you would otherwise not need):
> Its a NMS host problme, deal with it in the NMS host. If you can not change the app,
> let the OS do the NAT. Of course, this would not work for the poor customer who bought
> a black-blox NMS soution which may run windows, or where you can not configure the
> linux. Then again, nowadays, most NOC components should be software in VMs, and
> for those, you should certainly be able to do the NAT in the vswitch of the server.
> In any case: my interest in expanding the NAT section further is quite limited.
> The whole goal of the NAT section was to explain that you need 1:1 address mapping
> and that you can hack this up in likely most available routers with NAT support,
> but do not consider this to be a good long term solution but use it as a stopgap
> to upgrade your NOC software to IPv6.
> No idea why IETF draft/RFC doesn't allow me to write such a simple paragraph ;-))
> So, let me know if you feel strongly anything that should be added/modified to the
> NAT section.
>>> Alas, i didn't have the time to investigate these options. And most likely if at
>>> all you could only make those work for linux.
>> Linux or Windows, yes. In a vendor's router o/s, who knows? But maybe they
>> will all support IPv6 anyway?
> Lets hope so, yes.
>>> So, for now i just remove the note and clarified the last sentence a bit.
>>> If there is anything specific to be said bout why 464XLAT might be better
>>> longer term, let me know and i can add it. For now it looks like yet another
>>> network device configured option to me, but i have not tried to understand it
>>> all the way.
>> I think you'd need one of the 464XLAT authors to have a look at the scenario,
>> because I don't claim to understand it all.
> Well, the analysis i made above (server must support IPv4 as stated in the RFC)
> makes me discount it as a more beneficial option to mention.
>>>>>    Using current registration options implies that there will not be
>>>>>    reverse DNS mapping for ACP addresses.
>>>> Really? I assume we're talking about two-faced DNS, and afaik nothing
>>>> stops an operator providing reverse mapping in the private DNS.
>>>> That seems to be implied by the following paragraphs, so the text
>>>> seems inconsistent anyway.
>>> I know it under the name "split-horizon DNS". Is there any reference ?
>> The DNS community in the IETF hates split DNS so much that
>> not much has been written about it. I did find these:
> RFC1918 actually explains it succinctly without giving it a name.
> RFC4193 only tells you what you shouldn't do with DNS. How helpfull ;-)
> So, let me know if you think it's worth creating another stable-connectivity rev,
> i'd suggest to replace the "split-horizon" sentence with:
> Operators may therefore need to use a private DNS setup for the ACP ULA
> addresses. This is the same setup that would be necessary for using
> RFC1918 addresses in DNS. See for example [RFC1918] section 5, last
> paragraph. In [RFC6950] section 4, these setups are discussed in more detail.
> Cheers
>     Toerless
>> Regards,
>>     Brian