On Oct 30, 2010, at 7:39 PM, Fred Baker wrote: > > On Oct 30, 2010, at 4:22 PM, Keith Moore wrote: > >> If the authors can see their way to putting in some sort generalizable >> support for letting hosts/apps find out their external/global addresses (by >> generalizable, I mean a protocol that can be extended for stateful NA[p]T >> and NA[p]T between v4 and v6 also), I'm inclined to support it. > > I'm not at all opposed to doing that, and have already contacted the behave > chairs for advice. I actually do think that's a protocol, separate from the > function of the translator, but I have no problem with its existence. I do > have a question why; from statements made in this forum, the reason seems to > be "in order to populate dynamic dns correctly" and "in order to know the > external address(es) of a peer that I will refer sessions to". Is that a > correct summary?
I agree that the protocol is separate from the function of the translator. I'm not sure of the best way to proceed, though. I want the control/query protocol something that can stand on its own and apply to all NATs rather than just NAT66. But I doubt that you want to make NAT66 dependent on approval of a generalized new protocol especially when NAT66 doesn't need that generality. Offhand I'm thinking that the thing to do is to define an interface for NAT66 that can be extended into a general purpose interface to NATs in general. Knowing the external address(es) to give to a peer is for me the primary justification for such a protocol. Populating DDNS correctly only applies to the stateless 1-1 NAT case which of course is true for your proposal. It would not apply to other use cases for such a protocol. > I do have a problem with one aspect of that, though, which is that you want > the mechanism to be the same for stateful translators that will potentially > come up up with a different TCP four-tuple per session AND apply to the > stateless (configured but no dynamic state, with no port translation) version. Right. I have done a bit of work in this area in conjunction with an earlier proposal that I did. I think it suffices if the request is something that can be meaningful for both stateless and stateful NAT (also for NAT and NAPT) and the response from the NAT can be different for different kinds of NAT. But obviously the details would have to be worked out. > With NAT66 as specified, you can do this once and know the values until you > have a change of hardware or your company has a change of contract. If you're > doing NA(P)T and the NAT is configured with a set of addresses on its public > side, you have to do it per session. I'm not convinced you want the same > solution for both. I understand why you would like me to provide one, but I'm > honestly not sure you really want one. Think that assymetry through and tell > me that you really want to design your software so that something you can do > daily or weekly has to be done for each of the 10-20 sessions that > potentially open when you click on a web link, and I'll think about that. If you're writing an application that interacts with a NAT, you want it to be general enough to work with any kind of NAT that supports this kind of mechanism, so you're probably going to do it once per session anyway. Maybe if the first response you get back says "the mapping is 1-1 and algorithmic and will never change" you can optimize and not bother to do the query again for any addresses in that range, but your code has to potentially be able to do it. If you're trying to put code into a host stack to support this semi-transparently (sort of like RSIP) you'd probably do the optimization rather than issue a query either time. But my main goal is to provide applications with a uniform interface for dealing with NAT without requiring them to have a server in the core of the network. > I continue to wonder - if remote systems find it adequate to do a reverse DNS > lookup to validate an IP address by associating it with a DNS name, why local > systems can't do a DNS query "once and know the values until the peer has a > change of hardware or your company has a change of contract" to find what > addresses that name might have associated with it. No, not a great idea per > session. But I'm not looking at something that changes per session. I'm not sure what any of this has to do with validating an IP address. Nor do I know of any purpose for which it's "adequate" to do a reverse DNS lookup. Lots of apps do such lookups, but the results are not an assurance of much of anything. In particular you can't expect hosts to be listed in DNS in either forward or reverse zones. It's just not generally true in practice that they are. > If that's not adequate - and no, I don't accept "it's not adequate" as an > answer, I'd really like an explanation, because I don't see why not in the > stateless case - then I find myself thinking in terms of ICMP or something > akin to it. If I could send a datagram that would follow the same path to the > same DMZ, perhaps as an anycast or multicast, and get zero or more responses > saying "I would have changed your source address to []", would that be > adequate? I need to go back and look over my notes from before when (if I recall correctly) I worked this out in detail. I seem to remember that there were some constraints on how this had to work, but I don't remember what they were. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
