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 [email protected] https://www.ietf.org/mailman/listinfo/anima
