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. Regards Brian 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: > .... > > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
