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

[Toerless Eckert <[e-mail]>]

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