I wrote: "Generally -04 is almost there..." I meant: Generally -05 is almost there...
Regards Brian On 04/08/2017 11:31, Brian E Carpenter wrote: > I'm just coming back on a couple of points. Generally -04 is almost there... > > On 03/08/2017 13:08, Toerless Eckert wrote: > ...>>> 2.1.8. Long term direction of the solution >>> ...> 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the >>>> network to enable use of ACP is long term undesirable. Having >>>> IPv4 only applications automatically leverage IPv6 connectivity >>>> via host-stack options is likely non-feasible (NOTE: this has >>>> still to be vetted more). >>> >>> That NOTE needs to be cleared up. Something like 464XLAT (RFC6877) >>> might be a good compromise. >> >> 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). > >> 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? > >> >> 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. > > ... >>>> 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 > > Regards, > Brian > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
