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

Brian E Carpenter <> Mon, 18 September 2017 20:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 400321321A4 for <>; Mon, 18 Sep 2017 13:12:02 -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 JkQ6KPaFXxoB for <>; Mon, 18 Sep 2017 13:12:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FEF912421A for <>; Mon, 18 Sep 2017 13:12:00 -0700 (PDT)
Received: by with SMTP id m30so747743pgn.6 for <>; Mon, 18 Sep 2017 13:11:59 -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=uC0AyEVF6jKncpmxGH5/Ytpk28ef+95/MoVXjnRio3c=; b=KwTWmiyVH2/6hZXg2rX6PRvwjXFYdBOnnoqe+EDwCXVJFL1E1NVXMrz5NSBfBzSO10 y2KGW79l8mRMTymfpobB111FpQHGOBBEXgpmK1Gc5qB7tTMxyFvSLvx/d1RHZQyz+Zah sHKnzCaaap0hmnIKh4AfPiRbqu9Sajo3dgerYUtHn5VHuvQHN/GloTSl28W77uaEUcQq y3Yp/7ukRYlev/sFZG2N97trTo69ipZIK5N47q+VLBttUkr76dpSYy7/y6xMuTgsBQFt nEmZzpw34rsBl4TtfM4tvON7m5h+2vbOJDGykotAgTurCbbHh+YfgbOevgYEXDU40ka9 aQMA==
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=uC0AyEVF6jKncpmxGH5/Ytpk28ef+95/MoVXjnRio3c=; b=gGQuJEIwMRQgd0G4O09AOLXbeOlIZHTd1ToKRHUxOswmJRUGMsfdZafZvgTIzBy0P5 JIw0Wn1dRnWsR+VcM+C2wV1zw03iXHCQTRx9m3LRRdDqAK3z7sPLibvSe3XA8FuffbH1 qOcgFGL4Lu49+VgrSiOxd7P6zdO42XI/GBvyquIzpuXnfq9o6TEBGN0iwtQHX8Ge9Laj G8EMjwmYiUsjerotTY+tk1IHRIYPKz1xBXK23CpFcrUShOqZ+ZmlqRYNaNWZCvVuV9HP o2LND5tJ0/09NyEalt8K8/gBEJz/669ZYvwYZWVl3yIoJfg+t7Q8ErP3dgMRdKkVy3fw QUgw==
X-Gm-Message-State: AHPjjUhNbfvDJmGj4SeTI0bteu0iSae5WK0gQu1DamsW2uSNghw3D4aj yrIDH+6//OStEIF/
X-Google-Smtp-Source: ADKCNb7giQedv99f2Br9WELVZerp3ejj74avDjpPlD2DTDMdoaph1jBmcsiu6zUTFHnfU8S2i+oAmQ==
X-Received: by with SMTP id x14mr33440665pfj.258.1505765518559; Mon, 18 Sep 2017 13:11:58 -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 v10sm237843pgf.8.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 13:11:57 -0700 (PDT)
To: Toerless Eckert <>
Cc: Anima WG <>
References: <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Tue, 19 Sep 2017 08:11:56 +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: Mon, 18 Sep 2017 20:12:02 -0000

This is embarassing. For some reason I completely missed the announcement
of draft-ietf-anima-stable-connectivity-05, until today.

I have now looked at the -05 and -06 versions and I'm happy with the result.


On 18/09/2017 17:38, Toerless Eckert wrote:
> Thanks, Brian:
> The "OLD" paragraph you list was from -04. After your review i had already
> changed this in -05 to
> NEW:
>    To connect IPv4 only management plane devices/applications with the
>    ACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is
>    necessary.  The basic mechanisms for this are defined in SIIT
>    ([RFC7915]).  There are multiple solutions using this mechanisms.  To
>    understand the possible solutions, we consider the requirements:
> ....
> I also did spend a good amount of time because of your -04 review and prior
> request by mohammed to detail in the following parapgraphs the possible
> options in more detail.  That text leverages the 'SIIT' term and
> discusses the EAM solutions (RFC7757 is best).
> Given how this is an informational OPS document,
> i think it is helpfull to elaborate on the understood details of
> requirements and how known current solutions fit them.
>  The fact that none of the
> currently defined NAT solutions provides for the most simple possible
> configuration (aka: minimum number of prefix EAM's to configure) is
> also IMHO a perfectly valid outcome for an OPS document.
> It could mean that users will simply accept the need for longer mnaual
> NAT config (long list of 1:1 mappings) or vendors implement a proprietary
> EAM (explicit address mapping) CLI to make it simpler. Or users will
> move faster to IPv6 on the NOC ;-)
> So, for the time being, i just commited -06 with the second fix.
> Let me know what you folks think about WG last call status of
> the stable connectivity draft.
> Cheers
>     Toerless
> On Fri, Sep 15, 2017 at 11:05:51AM +1200, Brian E Carpenter wrote:
>> 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:
>> OLD
>>    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
>>    NOClan.
>> NEW
>>    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.
>> Regards
>>    Brian
>> 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
>> _______________________________________________
>> Anima mailing list