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

[Toerless Eckert <[e-mail]>]

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:
....

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt

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:
> >> https://tools.ietf.org/html/rfc6950#section-4
> >> https://tools.ietf.org/html/rfc7157#section-6.3
> >> https://tools.ietf.org/html/draft-richardson-homenet-secret-gardens
> > 
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[e-mail]