At 10:58 PM -0700 3/23/09, Margaret Wasserman wrote: >Your right. Translation of both addresses is needed, effectively >translating in both the outbound and inbound directions, so that the >return packets will go back through a NAT66 box to be translated back >again. >
I am sure I am misunderstanding this here. It sounds like you are saying that instead of this: Application desires to contact service provided on some node on the 'net. It causes its node's DNS to collect one or more addresses from the relevant dns server. It constructs a flow such that its source address is selected according to the existing mechanism (selecting a global scope address for anything beyond the link scope, since ULAs are global scope here). The packets in these flows go through normal routing to some administrative boundary at which boundary they are altered by this new box. That alteration changes their source address to some PA-relevant source address for the upstream network. It goes out into the wild world, where response packets are constructed, using this new source address as destination addresses. Those reach the same box as before (or a box that has state on the transformation) which alters them to carry the original source address. You want to do or allow this: Application desires to contact service provided on some node on the 'net. It causes its node's DNS to collect one or more addresses from the relevant dns server. That information is altered such that one or more of the addresses is related to a specific local scope (e.g. matches the local ULA). [DNSSEC breaks here] The host constructs a flow such that its source address is selected according to the existing mechanism (selecting the local scope in the DNS packets it just got back). It sends out a packet which is then updated as above and is returned as above. I *have* to be getting this wrong. What is the right step here? Ted _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
