October 1 minutes by: Fred Baker Agenda: 08:30-9:00 breakfast (0:30) 09:00-9:15 practical arrangements (0:15, Jari) 09:15-9:25 goals for the meeting (0:10, Jari) 09:25-9:35 agenda bash (0:10, chairs) 09:35-11:00 scenarios I (1:50, Mark) 11:00-11:30 email break (0:30) 11:30-12:00 lunch (0:30) 12:00-13:00 scenarios II (1:00, Mark) 13:00-13:30 Address Plus Port (A+P) (0:30, Randy) 13:30-14:00 Stateless Address Mapping (0:30, Remi) 14:00-14:15 break (0:15) 14:15-14:45 DS-Lite (0:30, Alain) 14:45-15:15 email break (0:30) 15:15-15:45 comparison (0:30, Dan) 15:45-17:00 discussion (1:15, all) - IPv6 prefix - P-MTU & Fragmentation - End-point discovery - encaps/decaps location? - Tunneling protocol 19:00- social event at [http://www.gibbys.com/ Gibby's] Discussion: Mark Townsley gave an overview of the planned IPv6 deployment using dual stack technology. Reality is that IPv6 did not deploy, and we are facing some issues in the IPv4 address space. We want to look at scenarios (http://tools.ietf.org/id/draft-arkko-townsley-coexistence) sorting out the coexistence phase of deployment. Mar showed five scenarios: (20) IPv4 sites reaching global internet In this scenario, the Internet is kept going by making trade-offs that may prevent edge network deployment of services. (21) service providers running out of private IPv4 space This provides balkanization of the Internet in which service providers don't necessarily provide access to the global IPv4 Internet. (22) Enterprise "greenfield" IPv6-only networks These are networks that run IPv6-only and are built from the ground p to do so. They consider the operational overhead of dual stack networks to be high. These use IPv6 internally and require access to IPv4-supported content. (3a) Wireless "greenfield" IPv6-only networks" Same scenario, but wireless (Cellular Radio) access network. The perception is that the cellular operator has the ability to specify equipment and operations in more detail than in generalized networks. (23) IPv6 hosts reaching private IPv4-only servers This combines a dual stack network providing access to servers in a private IPv4-only space managed by the ISP. This presumes that IPv6-only connectivity is required globally, but not IPv4-access. Randy Bush pointed out that this scenario is much like the expected future scenario in which there are legacy IPv4 servers in an mostly-IPv6 world. This is deemed largely different from that in scale - the IPv4 part is relatively small, not relatively large. (24) IPv4-only hosts reaching IPv6-only servers Mark thinks this is "hard", because he can't map 2^128 addresses into 2^32 in a 1:1 fashion. Design space issues: Dual NAT (CGN) is new territory for some applications; the approach is likely to break some applications and introduce management complexity when servers are deployed between the CGN and the CPE Gateway. Specifically, Port Forwarding as implemented in UPnP will be compromised. Applications can generally continue to work if servers or peer/peer connectivity continues through the global IPv4 space; with modifications, most applications are likely to work. There is significant management complexity in all cases however. If I am able to touch both the CGN and the CPE Gateway, then I can turn off NAT in the CPE Gateway and simply route from the home. If we use point to point connectivity (tunnel/DSL/PPP etc) then I have a large number of options due to total control. A network in Italy does the p2p scenario using 802.1d bridging in the CPE Gateway. One option here would be to use IPv6 in the ISP around a point to point network scenario connecting the CPE GW to the CGN. This lends itself to scenarios in which "port leasing" or "fractional addressing" are real options. Remi Denis-Courmont raised concerns with the ability of the ISP to prevent DOS attacks and such. Complexity and statistical efficiency trade off here; Randy Bush and Mark Townsley argued in favor of simplicity over efficiency. One issue raised here is the statistical behavior of port mapping. Current applications may use many (O(100)) ports while displaying a single web page, which due to issues of multiplexing means multiple hundreds of ports in use per user across a NAT due to mapping lifetime issues. There is support in research for the notion that changing transports to SCTP can dramatically change that while improving the application behavior, so one could expect applications to adapt to the environment. There is also room to consider mapping IPv4 addresses and ports into IPv6 addresses and routing in IPv6, and using that to connect private networks to the CGN in the distribution network. The point was made that we have now spent an hour on various ramifications of the 4-4-4 solution and solutions like it. Within a relatively short period - one business contract cycle, on the order of three years or less - we can expect routers and hosts to all support IPv6. So this is a lot of time spent on how to add incredible complexity to keep IPv4 going for a couple more years. In the chat room, Nathan Ward notes that "the customers on OSes without IPv6 support are unlikely to need inbound Ipv4 connections". So IPv4 translation to access IPv6 servers can support legacy equipment." Enterprise greenfield IPv6-only networks. There are various ways to enable IPv6-only networks to access IPv4 content: NAT64, NAT-PT, or application gateways are options. There was a pretty convoluted discussion of IPv6 networks connecting to dual stack networks containing IPv4-only content. This appears to call for some form of translation. We then went on to ask what scenarios we have missed, and Mark Townsley made it clear that the only scenarios he was interested in were areas in which the IETF needs to charter new work. Ron Bonica went on to look at the combinatorics of the solution space, which can be come quite large. 13:00-13:30 Address Plus Port (A+P) (0:30, Randy) http://mice.cs.columbia.edu/getTechreport.php?techreportID=560 Randy Bush then gave a talk on A+P: basically, he would like to insert IPv4 address and port into the IPv6 address and provide NAT between those things. He would like the ISPs to simply deploy IPv6. For details of the solution, read the document. His fundamental concern, he said, is that control should be as close to the user as possible and his model provides for that. 13:30-14:00 Stateless Address Mapping (0:30, Remi) http://tools.ietf.org/html/draft-despres-sam Remi gave an overview of the SAM technology. 14:15-14:45 DS-Lite (0:30, Alain) http://tools.ietf.org/html/draft-durand-softwire-dual-stack-lite Alain gave an overview of DS-Lite. 15:15-15:45 comparison (0:30, Dan) http://tools.ietf.org/html/draft-wing-nat-pt-replacement-comparison Dan Wing reviewed the comparison document, in a set of slides that tried to capture the significant differences between various proposals. There was a long and wide-ranging discussion here with many people at the mike. To be honest, I couldn't make sense out of what needed to be minuted beyond "read the slides", although there was a lot of discussion. Brian Haberman then ran a "how are we doing" session. In the jabber room, it was pretty clearly asked what the point of scenario 4 was (translation between IPv4 and IPv6, with the IPv4 being a private network) and why that excluded global addresses. Mark Townsley explained that scenario 4 was supposed to be the legacy IPv4 systems in a mostly-converted IPv6 network, while scenario 5 is an interchange between public or potentially-public networks. ======================================================================================= October 2 minutes by: David Miles -------- Thursday IVI: ---- CERNET exists in two halves, the IPv4 and IPv6 half (CNGI-CERNET2). IVI gateways are located between the two networks. CERNET2 is single-stack IPv6. Because of low internet penetration in China, major operators (fixed and mobile) are interested in IVI. Lessons learnt: - The only viable option for future Internet is IPv6 - Building a new IPv6 network is more cost effective than a dual-stack network (especially for un-wired networks) - Stateless is very important (vs stateful) The IVI model leverages IPv6 address planning in order to make a 1:1 mapping between IPv4 and IPv6. You do not randomly select IPv6 addresses. Marcello: I don't understand. If you want communications from IPv4 to IPv6 you need to make that choice - you need to select a few addresses that need static mapping. If you want communications from IPv6 to IPv4 you don't need that static mapping. Xing: Correct. But we do both ways. Dave: The hosts in the IVI network. This is still connecting global IPv4 address space. These consume just as much address space as if they were in the global IPv4 Internet. What about IPv4 exhaustion. This technique will become less useful over time. Alain: I agree with what Dave said. IVI is an optimisation to allow a v4 over v6 tunnel to be sent directly to the machine. Fred: Responding to Dave's point re IPv4 availability. The comparison is to dual-stack mode where you address every system in the IPv6 domain. In the latter you need to put IPv4 addresses on everything, but in IVI you don't need IPv4 addresses on clients. Addresses IPv4 to IPv6 IVI (SIIT extension, stateless) IPv6 IVI to IPv4 (SIIT, stateless) Address format: LIR prefix (ie, /40) Embedded IPv4 address from bits 40-to-72! Dave: Is the 40 bit boundary fixed, or completely under control of the LIR? Xing: It is not fixed Dave: So the 72-bit boundary isnt fixed either? Xing: No Dave: SIIT does not use v4 compatible space, uses v4 translatable space Remi: You mentioned port multiplexing like A+P and SAM. Is this an idea or something you have? Xing: Today I only focused on 1:1 stateless. Marcello: I understood we have this address fromat because you want to keep routing on the highest /64 prefix, you dont want to route on the more specifics that go beyond the /64 boundary. If you want to reach different parts of the v4 internet you inject routes that are shorter than 64 bits. Do we have a problem if we route on more specific than /64? Do we have a problem with routers? Dave: I dont think there is a routing problem. There are some problems with putting it at the end that may depend on implementation. Because your using LIR prefix it does not start with binary 000, and hence hosts do not know this. You now have a problem with the address space definition at 64-bits Interface Id boundary. You may have implementations with embedded assumptions around 64-bit boundaries. Fred: I believe the NAT64 draft has an option for LIR prefix - here (IVI) we have an LIR prefix. The argument for using a LIR prefix is that its easier for the network admin to manage routes. They can choose an exist gateway instead of just hoping when there are more than one gateway. They can manage routing more clearly X: Yes there will be impact to routing scalability. There will be very specific prefixes in the global routing table. This in to a problem specific to this proposal, its general, perhaps it should not stop us from doing this. Randy: Everyone will route it probably, but its one more memory fetch down the tree. [Comment that there is no statement about ensuring no fixed 64-bit boundary] Dave: Interesting routing question: Since a single IPv4 address has multiple IPv6 addresses. The state we want is most hosts are IPv6. We have apps that are v6 and start doing referrals. If we are in one ISP and refer the address to another customer in another ISP - is he still able to reach it? How will the routing policy be configured? Fred: It is a routing policy problem Dave: If this were deployed by multiple ISP would they do it right? Fred: They would only advertise this space within their domain Dave: In which case referrals might not work. So we cant assume referrals will work with this Alain: If you use NAT64 with a special prefix that represents the IPv4 internet and do referral then youre going to have a problem - its not just IVI. You cant expect a routing policy is put into place. Any time you use a prefix of your own choosing you will have the same problem. Routing in IVI networks One IVI gateway, or many Fred: One comment on this magic vs LIR prefix. If you want to talk about routing policy and what SP are likely to do. I expect a magic prefix (000) are more likely to not be advertised outside a domain vs a domain specific prefix. These are specific to a service (translation) here the LIR prefix are just LIR prefix. If you want to use policy as a way of saying this is a bad idea, the policy argues against the 000 type of prefix. I would be more interested in using LIR prefixes not special use Marcello: I thought that too, but, suppose I am in two different ISP but I am using unique prefixes for mapping. If a referral passes the application data from one ISP to another one. Referrals work not because it is routed, but because they have the same meaning and are translated. You dont need this to be advertised (000 prefixes) for this to work. It can be directly translated. I assume you have IVI/NATPT - not that you have v4 host connectivity, but have access to a NAT-PT service. Fred: If we are talking about translated networks. If you are going through translators, how are you going to manage the routing? If policy is going to get in the way of one proposal, what will happen - its going to be for LIR prefixes and against special use prefixes. The IPv4 doesnt come into it Marcello: But we are talking about referrals. If a well-known prefix is used referrals will work - im not saying this means this is a better solution, just thta referrals work Alain: There are two prefixes. The address prefix represents the v4 Internet when you are on a v6 site. The two prefixes dont have to be the same. When i configure my IVI host they can have 2002 prefix. When i want to get a packet back to IPv6 this matters, when I want to send my packet to an IPv4 world you have a better chance using a well known prefix Randy: ISP routing policies are not a roulette game. ISP will route it if they need to. Remi: This discussion is similar to the case of comparison between 6to4 and 6RD? Referring IPv6 to customers has worked, youre differing on the LIR prefix as it is not a generalised tool. There is a strong argument for ISP independance. Eric: There is a lot of 6to4 out there! Remi: Yes, have they any guarantee that the v6 packets they send will return? There is no guaratee. Eric: 70% that hit ipv6.google.com have 6to4 addresses Remi: How they do it I dont know. Prefix Announcement in IVI Lots of routing policy discussion. Here is an example (routing policy) that has been working for 2 years. DNS is similar to other solutions. There will be A to quad A record synthesis. Marcello: When you say you support multiple IVI gateways, this not the case for IPv6-initiated communications? Xing: No Stateless operation There is stateless operation/stateless mode. There is a SIIT extension (prefix-specific address). The transformation of addresses is automatic and requires no state. Stateful (NAT-PT replacement) Address format is the same as the stateless mode. The address and port are mapped to IPv6 addresses in a stateless manner Operation of gateway: Stateless is preferable due to end-to-end principle and simplicity In summary IVI reachability: IPv6 initiated (1:1 mode). Alain: When you do DNS you synthesise records so you have the same DNSSEC issues? Marcello: These are not the same issues as NAT-PT as i understand. NAT-PT intercepts packets. If you place the DNS ALG on the local DNS server or in the resolver in the host then this perfectly matches DNSSEC trust models. You validate and then synthesise. So this works. NAT-PT intercepts and does it on the fly. As this case is implemented in the DNS server this can be solved. Alain: Key work, can be solved Marcello: The point is that there are 2 trust models in DNSSEC - validating server or validating resolver. Here you place the functionality of the syntheses in the place you validate - you have to do it right after you validate. If you want to do it is the resolver you'd need to put the synthesis there. Dave: Diagrams are a bit confusing. Back to the LIR discussion when you have v6 initiated communication. In going from global v6 to global v4 the other thing you can get for free - youre mapping entire v4 address space. Youre also mapping any RFC 1918 space. With the LIR prefix, and as they are different for each ISP, you can get a different prefix for each RFC 1918 space. Andrew: Where you are going to do validation in DNSSEC. There are two directions here, but the overall consensus is that it would be better to have validation as close to the end as possible. If you assume a stub resolver on the client it becomes too appealing as an attack target. It means everyone will need a validator or DNSSEC may not work. Brians suggestion is that if you have a standardised prefix (and can learn what it is in a secure fashion) you can strip it off, validate, then put it back on. The hard part is learning what that prefix is. Marcello: In any case you need to learn that prefix and it is not specific to this mechanism. Laurent: mobile are important. I dont see how this works with existing IETF-defined mechanisms (such as PMIP) - how would this work in a PMIP environment. This mechanism much work in a mobile environment. Marcello: I dont see any problem from a MIP perspective. Y: The reason is once you get a new IP address we initiate another instance of this protocol. Choices: Get no IPv6 jsut do IPv4 - no way Get ipv4 and use them for NAT - state and complexity Get IPv4 and deploy dual stack. Get IPv4 dresses and use them to sell and IVI + general IPv6 service. This is the IVI proposal. Z: Do you have comment or experiance on the protocols that are carrying IP addresses in their payload - how does this work with IVI? Xing: We tried SSH - but yes when addresses are embedded you do need ALG. Z: In the path - yes you would need then an ALG. So a SIP client will not work through Z: In the previous slide you had a v6 adoption s-curve. The time at which IPv4 addresses are sufficiently expensive, you said one was to get IPv4 addresses and use them as IVI addresses - how does that differ to the way IVI works anyway - is that different? Xing: No Alain: Id like to follow up: Can we relate this discussion to yesterday's with Randy with the NAT box in the middle and how to get control. We looked at control at the edge yesterday. How is this possible in IVI Xing: The combination of address and port can be done in stateless fashion. For servers you could embed port number into the IVI address Alain: If i am a normal IPv6 node how do I know what is happening? Xing: In the stateful case? Alain: Yes Xing: Like NAT-PT - the gateway (IVI) will keep the state Mark: If I have an ALG on the IPv6 domain - say a SIP v6 client, that proxy needs to have a leg on the v4 domain. Therefore these is a separate device that forwards packets, separate to the IVI gateway, right? Xing: Yes Fred: There is some process - but it can be in the same device or a different one. We do need work regardless of translation. Regardless of approach some apps need work. I dont think that helps us choose among approaches. --- Marcello: Improving NAT-PT Will talk about what can be improved. NAT64 is not our draft - i just meant the functionality from IPv6 into IPv4. I am comparing the basic NAT-PT. Not talking about static mapping on the IVI or that kind of stuff - just basic NAT-PT. Issues with protocols embedding IP addresses. Common. Solution: v4 NAT is to use ICE. Recommend we follow BEHAVE requirements in any NAT we define (for v6-v4). NAPT-PT Redirection: It only works for TCP and UDP, what about other protocols? You dont have a demux. Recommend: whatever NAT we define needs to support whatever protocols we want to work. If we need to do more protocols lets just do them. NAT-PT binding state decay: State needs to be refreshed. RFC 2266 predated BEHAVE. Recommend: Follow BEHAVE requirements for mapping refresh timer. Hosts now know what to expect. Also can use ICE. Loss of Info: Flow label, extension and ICMP lost. Even RFC 4966 states this isn't really a big issue. I don't think there is much we can do about this, but I do not think (and they [RFC 4966 authors]) do not think its an issues either. There has been an issue around DSCP so I think we may need more work there. NAT-PT and frag - Alain for later SCPT and multihoming. Follow the IPv4 NAT recommendation for multihoming NAT-PT for a proxy correspondent node for MIPv6 This is a non issue from MIPv6 experts NAT-PT and multicast I dont know what this means - is something needed? Brian: NAT-PT and multicast - any translation approach in multicast needs more work. Is it needed, I'm not sure? I have heard some that say you do - but the arguments have not been compelling. If anyone has compelling ideas let me know Marcello: I think we should at a minimum, what things do we need the NAT to do to prevent future problems. Issue with mulitcast routing is RPF checks, you have to be able to have cross-domain knowledge in the routing. They are topics worth identifying. Z: I will give an example using multicast. We have received many requirements to support multicast. I cannot explain how they want to be used, but I have received many requests. Z: There is BEHAVE document on multicast so there has been some thought Dan: There is a draft/RFC on mulitcast in IPv4 - but not cross v4/v6. There has been some thought on it though As first conclusions, the main issue with current NAT-PT it predates BEHAVE work. It is missing things but they can be solved with the BEHAVE knowledege. Most can be solved by just working on the spec. Let's just write a better spec. The DNS ALG issues: Network topology contraints: DNS queries and data packet must follow the same path. Spoofing DNS messages include synthetic records in DNS. For the 4-to-6 direction the DNS reply is associated with the NAT state. For 6-to-4 the DNS function can be separated. Jari: Are you saying you could avoid 6-to-4 component? Marcello: Yes Z: You were saying you need co-location - but it could be seperated and communicated to the transaltor Marcello: you can solve this by sync DNS and NAT. But for multihoming you need sync between different NAT boxes. Here its sync between DNS and NAT. This issue is solved in 64, but harder in 4-6. Seperate NAT64 and NAT46 and make a spec for NAT64. Scalability and SPOF: You have a SPOF doing DNS and NAT. Not true for NAT64 only NAT46. You can get redundancy in NAT64 because there is no state. When the NAT state disappears you no longer have these addresses so you have a problem. With NAT46 you create the state when you see the query by the DNS. So then you have to keep it for a long time even without packets. In NAT46 DNS is creating the NAT state. We can solve the easy part in NAT64 and look at other solutions for NAT46. Again, separate NAT64 and NAT46 and follow BEHAVE for NAT64. DoS Attacks: You reserve the whole address on DNS, on data attack its less efficient because you reserve just one port. We need to separate NAT64 and NAT46 again, there are different problems for both. Most severe issues are easily solved for NAT64 but more work is needed for NAT46. I suggest we separate them. There are some issues when you associated a given prefix to a given NAT box because you need some relationship between the DNS response and the NAT box to which you communicate. The DNS message must be associated with a specific NAT box somewhere. Some scenarios don't need a DNS ALG. Could have a different spec, one for DNS64 and one for NAT64. Jari: I don't think the separation is useful. Marcello: If you read this spec, NAT-PT has different components, and the whole NAT-PT got bashed because of one of the parts have problems. Dave: I agree there is a need to distinguish the different cases. Where you put them and how many specs I don't feel strongly on. Scenario 4 is a subset of the NAT64 domain. The NAT64 domain is a subset of larger things. NAT64 is a subset of what IVI does. There are 3 levels , the full IVI, the NAT64 portion, and the scenario 4 portion. If you put them all together you get one big solution (like IVI). Im not arguing for either separate or combined, but if you believe they should be closer together in one spec, then you could argue the NAT64 and IVI should be combined. Or you think they should be separated to get compliance to individual components (ie, I support this RFC). There is also another one - how fast each piece can advance in the standardisation process - you could also want to separate based on timing. Ie, NAT64 is easy, NAT46 is hard - do NAT64 APAS. NAT46 as experimental, etc. Z: I think splitting is a good idea. I would argue to keep NAT64 and DNS64 together. I don't think we have got much attention from DNS folk - and it needs that attention. This may be one reason to pull them out and we need the involvement of the DNS community. Dual stack to single stack - native connectivity or translated connectivity? When you have v4/v6 only hosts this can be easily solved. But when dual-stack communicates to a v6-only node things are harder. You can play with policy table. EDNS0, try to use well-known prefixes. None of them really achieve what we want. Its hard to do this in an automatic way. Recommend to use described tools. Dave: This is a case that can be solved without DNS64, a dual stack can have A and AAAA records. You don't even need a DNS64. if you collect these by scenario you may be able to evaluate the problems a little easier. Andrew: How much are we willing to insist that the v6 hosts need to have some intelligence. We talk about a DNS ALG at a recursive resolver, and this v6 only host doesn't need anything. Other times it does need knowledge. We need to decide which one. Marcello: You may prefer the translated instead of the native, and it still works. There are other issues with DNSSEC, but there are no deployed DNSSEC resolvers today anyway. So we could do DNSSEC changes and these changes together. Basic connectivity should be provided to all legacy hosts. Optimised features may require some changes. Z: If you want DNSSEC to work you do need to do it in the host. That is the long-term preferred solution. But for compatibility you could use the other solution. Alain: you could always avoid translation in the first place and just use the IPv4 stack. If you do that - none of the DNSSEC issues arise. Dave: There are 3 places to solve the problem. Authoritative DNS server. Only works is certain scenarios, other places: validating recursive resolver, or a validating stub resolver. And where we should do it depends on the scenario. Eventually all host should be doing it , but it may take a while to get there. It has to be a scenario specific thing. A validating resolver solution may be okay in some scenarios. Andrew: We do have running code for stub resolvers. Inappropriate translation of responses to A queries. NAT PT spoofs packets. Its a MITH in NAT-PT, so just place it in the right place. DNS-ALG and multiple addresses node As you're not creating state in NAT64 you don't have this problem. Most issues don't apply to NAT64. The idea of the DNS ALG picking up things on the fly is a bad one, put it in DNS function or resolver. One way to avoid some problems with DNS synthesis could be to use a global prefix. Suresh: If I have a dual-stack node, youe're making it prefer translation or native IPv4 and IPv6. Its up to the node to resolve this issue. I do not agree you should put the onus on the node to decide this. If I prefer v6 over v4 you'd use the synthesised quad A. Marcello: You could solve it in the policy table Dan: If we had a cool secure way of learning what the prefix is, we get a new address. Now we know right away how to do DNSSEC and reconfigure our own policy table. Its not a rip out the stack, this could solve many issues. Marcello: But it doesn't solve the legacy problems Dan: If you want to do something new, do something new sNATPT ------ Not every application uses DNS to resolve addresses. Enables a IPv6 client to connect to an IPv4 server. Eliminate a DNS ALG. sNAT-PT is bi-directional, v4 or v6 initiated. Synthetic addresses may have an IDENT bit in the advanced case to help identify the presence of a translator. TFDP: Resolves some DNS LAG related issues. It synthesises A/AAAA/PTR and can created dynamic mappings (1:1) while being separated from the transport of the packet. Recycle traditional NAT-PT for the translation, remove the DNS ALG and create a Translator Friendly DNS Proxy separate to the NAT device. The translation engine is separated from the configuration. We don't recommend to use dynamic allocation for the anonymous service. RFC 4966 issues with multicast translation: Dave: MLD joints flow to the sNAT-PT. How does it decide what M4 address is used for an M6 address. Z: The sNAT-PT is statically configured with a M4:M6 mapping table ICMP error translation: Z:: How does this differ from what is in SIIT? Z:: This is a new [ICMP] code I think we should not support UDP w/o checksums. SIIT didn't, NAT-PT tried. Dan: All Cisco voice gateways send UDP packets without checksums Reassembly resolves the fragmented packet issue, but introduces its own issues. We can introduce this as optional behaviour Z:: The approach in NAT64 was to specify if you did reassemble, but you could implement it differently. Are you saying you want to go beyond that to say you must reassemble? Z:: Must reassemble at this moment, but I am wondering Z: As a spec, you could say you need this behaviour without a need to actually reassemble. I do not think Marcellos approach is bad, I just would like to present alternatives. EDNS original resource record option (a new option). If RR was authorised and synthesised, the DNS proxy inserts the ORR option inside the RR. RR verification can be done in one message. Z:: Why are you thinking of doing this inside the option instead of using the additional info option Z:: I understood end-node verification is required. So we should give some info to indicate this is synthesised. Z:: But you could put it in the additional information response. Why put it in the option instead of the additional info section? Z:: No real reason Andrew: All your doing is translating the A to the AAAA, but all the other records are passed through untouched? Z:: Yes Andrew: So the validator sees this ORR option and then queries specifically for the A record? Im confused Marcello: In order for this to work, we need to change the client. If you need to change the client, why not just synthesise records inside the client? Marcello: You saying that a bit in the address [IDENT] will indicate it is synthetic? Z:: Yes. Dave: You can use a well-known prefix, or use the IDENT bit when you don't have a well known prefix. If its an arbitrary prefix, how do you know which bit is the IDENT bit? A dummy bit is 128-bits minus 32-bits. IDENT is a bit-number that is always the 33rd from the right. If i receive this address (DNS or otherwise) how do i know whether its synthetic or not. Couldn't this just be a MAC address that has that bit set? Z: Do you think that having a SIP ALG is required? Z: It depends on the policy of the network [operator] Z: Is that SIP ALG for the purpose of setting up the media path? Z: Yes Z: The SIP WG has decided that ICE is the recommended way to go, are you trying to say you don't think that is the right way to go? Z: [No, this is just a description of one implementation.] Q: There may be some confusion in what a SIP ALG means at different times. I wouldn't go so far to say the SIP WG says to use ICE instead of SBC (a type of SIP ALG). SIP and other protocols are designed for certain types of intermediaries - if you put new intermediaries it in things will break. In SIP's case, back to back interconnections. TFDP assigns an IPv4 address dynamically. We face problems that some applications cache DNS record. Some applications are not compliant to [DNS] TTL. If the application caches responses and it doesn't expire TTL it is not friendly for dynamic address assignment. TTL was not designed for applications, it was designed for servers. Propose that any implementation should [use TTL to expire any DNS cached record]. NAT6 Issues ------- Cullen Issues that come up in all the drafts that do translation. Lots of experience with v4-to-v4 ALG. The one that comes up all the time is FTP ALG. All major browsers and FTP clients support PASV mode. PASV solves 4-to-4, EPASV solves 6-to-6 but nothing solves 4-to-6. Need to do some more stuff on FTP. Many people have made SIP ALG. They are a disaster and all have bugs, cant work with SIP TLS. SIP WG has moved to try and avoid them. Many SIP clients work fine through v4 NAT using a variety of techniques. RTSP is getting fixed too, and ALG may not be the right way there either - not sure. MGCP, unlikely to see it in these environments. All the other ALG on v4-to-v4 devices seems non-relevant, H323 may be important - but it is a hard thing to decide on. Are there any other protocols that we need to look at ALG for? If we only need an FTP ALG we can go and do that. Z: Why do we need an FTP ALG for 6to4. For 4to4 all the major browsers use PASV command. EPASV does the same thing for 6to6. Dave: Would EPASV work for 4to4? Z: Yes - EPASV has a protocol family field, so it could be used for 4to4. Z: HTTP ALG: if you find an IPv4 address embedded in a URL what will we do. Cullen: Good example. I have a NAT that looks in HTTP and translates it [URL]. This breaks all kinds of stuff. The problem with this HTTP ALG, for example, consider a binary file transfer that may have the exact 4bytes of my IP address in there and it gets it changed!! Client Port Control Protocols that allow devices behind the NAT to request a port - a particular port. Issue is around authorisation. There are protocols like UPnP to push up to the NAT, NAT-PMP similar to UPnP to control the NAT directly. Is the virus you just downloaded allowed to open up as many ports as it wants. Also, multi-layer NAT is common today. This issue is not specific to IPv6 at all. Alain: What is important is the difference between requesting any port, vs. a specific port. For example, if you want a specific port you'll never be able to get it in any of these solution/scenario (1/2/3). Move this semantic to wanting to work on any port. Marcello: There are some things that you could do different in IPv6. Authorisation for example. There is a draft that shows some ideas. In IPv6 you can actually prove address ownership. Cullen: Okay. The problem is not how to have a secure connection between host and NAT (ie, using CGA). But the problem is which clients should be authorised and which hosts, or applications, should not. There are brilliant ideas on how to solve this, but they are orthogonal. Fragmentation Goal: deal with the MTU differences between IPv4 and IPv6. How to we match the semantics of the DNF bit in IPv4 with options in IPv6. The ideal solution would not rely on ICMP, but ICMP would be an optimisation. Didn't force you to retransmit the first packet every time, and one that allows the application to be involved in this discovery process. Options: - v6 end hosts include Frag Header in all packets larger than about 500 octets. Downside requires a change in host or applications - something we are trying to avoid. - host sends the first packet and NAT sends ICMP error telling host to insert frag error - and host resends. I'm unclear on how the API work between stack and application to allow an application to differentiate between this case and the case where you really want to be un-frag. When a packet is more than v4 MTU and less than v6 MTU - you also need retransmission. - Host sends the packet that may be too big and relies on getting an IPv4 ICMP error - the NAT could then send back the IPv6 frag error. This wont work if there is something that drops ICMP on the v4 network between the NAT and whatever devices needs the fragmentation. Marcello: If this specific to the solution, or just relating to how IPv6 fragmentation works? Cullen: How v6 frag works, we guarantee we get 1280B and it usually works. Suresh: I don't know what's going to happen with an IPv6 host when it sends a 1280B packet and gets a "too big". Cullen: Me too - but the guess is that the right thing will happen. The implementers never expected this. Fred: It's supposed to work. Cullen: I know we need testing, but I don't think it should be a serious concern. Dave: the RFC requires that subsequent packets come with a fragment header, but they can still be 1280B. Dave: I think C and D are the same option, its just topological case differences. In C the min MTU is attached to the NAT, in D its beyond the NAT. Suresh: These are options not only for the sending host, but also the NAT implementers. Dave: No, the only time a NAT sends ICMP sends an error today if its IPv4 link has an MTU link to small for the packet. That is different to saying if it would not have to fragment. Cullen: What I had meant by C is that the NAT had 1500B MTU on its uplink. Take the case where it opportunistically sent a frag error. Dave: The disadvantage is that the first packet after the SYN is dropped. Y: There are some more interesting options. I wonder if you can forward a packet anyway to allow fragmentation. Cullen: I thought about when v6 says don't frag this packet, but then you allow it to be fragmented in the v4 world anyway Z: Are you assuming the NAT behaviour is more or less what SIIT says today? Cullen: I went through all of that and there are some differences Out of order fragments Truth about v4 NAT today: they deal with out of order packets with varying degrees of bugginess. out of order packets do happen so what do we do? Trying to deal with DoS and memory attacks on a NAT with 40G line cards, detect, buffer and reassemble is going to be very hard. Lots of people just block out of order fragments - so they only need to deal with keeping track. This will become a judgement and taste call - we break things if we do this. If we don't do this we have other issues. Any input? Z: I think we should do what behave says - behave says you should handle out of order packets. Whether the NAT actually reassembles, or just acts as if it reassembles is okay. Cullen: Yeah ,sure - but the question is whether we have to save them. Marcello: I asked this in v6ops - the answer is that you need a slot of time Dave: I agree with Marcello, be it 3 seconds or of that order. With fragments things are usually back-to-back. IP does not guarantee lack of reordering - so I do not think we should just drop them. IPSec AH: Some things just don't work. AH for example. Dan --- Proposal summary: Im going to also show all of the proposals on one slide. I tried to map these to the scenarios as know this morning. Mark is working on them. Dave: Between the three tables we are not complete. An example case not covered: v6 internet on top right in slide 3, and v4 intranet on bottom left. Connectivity inbound. Dan: I am not trying to capture scenarios. Z: From the discussion it seems obvious that the translation based solutions are all pretty similar. I don't think any of us have nailed it correctly. Somewhere is the best way. Lets take ideas from all the solutions (translation). We should try and merge the various translation proposals. Randy: I agree. I believe I have (as an operator) 2 problems. Problems with the broadband provider, or the problems the broadband provider causes me. Alain: In some of those cases where you have a v6 only server - scenario 4. Its not that you cant have an address, its just an application that doesn't work in v6 yet. Another point this morning discussed intranets. In these examples , using IPv6 can be quite compelling. Finally, giving the control of the NAT back to the user is something we will try to achieve. What is happening for green-field (it is not clear)? What we need is a roadmap - SP are running out of v4 space, and we need something simple right now. Marcello: My take is that we should take input and honour the input we receive. Alain: When I hear about legacy IPv6 hosts - this is too hard to swallow. There is very little deployment of IPv6-only networks. Yes devices exist with v6 capability, but when we turn off v4....... Jari: I think we need to understand the S-curve/adoption curve. We are not all in the same place. Remi: I agree with Alain that there is a host with only v6 stack. We have to deal with dual stack hosts that have IPv6-only addresses without IPv4 addresses. To deal with these hosts we don't require NAT64. Z: There is still software that is not good at running IPv6 on these devices. I don't think you can have only IPv6 networks. Alain: You make a good point. We have been confusing three things: what the network provides (addresses), what does the stack do, and finally what does the app do. If all of those three things are IPv6 then you can do the protocol translation and it works. If one isn't IPv6, typically the app, there is a lot of interest in doing the tunnel + v4 NAt clearly. We must look at all the hosts. The requirement of v6-only and then choose the solution isn't good - we need to define the "v6-only" definition better. Jari: we do have people explaining they have this issue and they want to do these things. Mark: Scenario 1: NAT 44 stuff Scenario 2: Service providers running out of IPv4 space. V4 over v6 encapsulations/tunnels. This is really still about delivering IPv4 to the user. Scenario 3a: Wireless Greenfield. Its still about v4 in v6 encapsulations. Talking about a host setting up the tunnel instead of the gateway. Host to gateway tunnel. Scenario 3-5: Translation Options. one big box that translates the whole IPv4 Internet into the whole of the IPv6 internet both ways. Such a box doesn't exist. Scenario 3: My IPv6 Network translates to the IPv4 Internet. My IPv6-network initiated traffic. Scenario 4: My IPv6 network is exposed to parts of the IPv4 internet. Initiate from IPv4 internet to My IPv6 Network Scenario 5: I want to expose My IPv4 Network to the entire IPv6 Internet. Initiate from the IPv6 Internet Scenario 6: I want to expose My IPv4 network to the entire IPv6 Internet, Initiate from My IPv4 Network Scenario 3: Greenfield. NAT64/DNS64. Scenario 5: Exposing some of my v6 Internet to the Internet. IVI, NAT-PT. Scenario 4: IPv6 Internet to my IPv4 Network. NAT64. 1:1 stateless Forget about the names and numbers! We cannot build a translator that can translate in both directions simultaneously. We must scope things. Shrink things down to the network I care about on one side, and translate to the remaining global network. Alain: This last scenario (My IPv4 to IPv6 Internet) is not solved. This scenario is actually an endgame scenario when the world has already gone v6, and services may only be on v6. I have not cared about v6 for a long time, but not apps are only on v6. Mark: The argument for why this is already solved is because by the time IPv6 only traffic exists out here, then hosts within the IPv4 network will be dual-stack hosts. Dave: I agree with Alain. This is not already solved. In the translation category there are four possible solutions. You're not talking about network devices in the "network" its the apps, hosts, etc. This scenario is not solved by Teredo because they are IPv4 networks. There hasn't been much demand for this so far, but this is a real, and unsolved, fourth case. Christian: This may be an important scenario in the future so IPv6 deployments will be high, so there will be less incentive on the IPv6 side to solve this problem, and more on the IPv4 side. The other solution is deployed on the IPv6 side, and as a consequence they need global IPv4 addresses. At some point in the future they will not get global addresses. Thus, better to have something on the side of the IPv4 network we don't need additional IPv4 addresses, we need more IPv6 global addresses. The virtual IPv6 document I have been working on addresses this scenario. Phillip: I object to the existence of a tunnel in Scenario 2. It may well be that the IETF recommends a tunnel-based solution, but I don't think it should be in the description. Mark: This is not a description of the scenario. Phillip: It seems you are declaring a tunnel based approach is the correct way to solve this problem. We need to discuss why we think tunnel-based is the correct way, and why we think back-to-back translation is bad. Jari: My recommendation is that we explain which tools fit with what scenarios. I don't want to entertain theoretical things. Phillip: We are going to build equipment in scenarios 3/4/5. This will solve scenario 2. Ie, say that it is a bad idea to do back-to-back NAT. Marcello: Even though that is the case for scenario 2, I'm not sure I'm convinced the scenario in 3a is the solution. Mark: It's a solution. It doesn't matter because people will do what they want to do. Cullen: I think that these tunnelling ones come down to v4 floated over 6 by the CPE or by the host. Ed: I like the definition of the translation - big problem before little problems. In terms of prohibiting 464, why prohibit things between "consenting adults". Jari: Its mostly about the question of which scenarios you actually care about. If you care about scenarios with hosts still. Mark: Scenario 3a represents a host that you can change. Remi: This could be used in an ISP network, right? Alain: I think that Remi has a point : you cannot have a clear cut scenario 1/2 prolonging v4, and 4/5/6 which translate. There is overlap. In scenario 3 you can address it either over tunnels or translation. Mark: I agree Z: Mobiles may possibly have IPv4-only software I propose that the next version of this document classifies things as follows: 1) Topologically we have IPv4 Networks reaching the IPv4 Internet with no IPv6 involved in reaching the IPv6 internet. NAT 444 or SAM with PPP tunnels, etc. No IPv6 introduced. 2) You are introducing an IPv6 network to help solve your IPv4 continuation problem. Eg: 2a: RFC1918 address space exhaustion , 2b: I want to run my IPv6 because I don't want to run dual stack. Listing the business scenarios that fit within this topological heading of IPv4 over IPv6. 3, 4, 5, and 6: These are the translation options. Point being that a [god box] for NAT is impossible. Must always think of things in the context of My Network. Christian: It is sufficient for one of the components between the application and the other end can make you 6-only. There are 3 parts that may be v6 only, the app, the host, the network. Dave: I agree with Christian. The router and the next router and stack and app are IPv6 only, no - that AND should be an OR. If you are trying to say : for things that make an interesting translations scenario, its the stack and the application. If your host can only support one [stack] then you cannot tunnel. Ed: The situation where the network is v6 only is covered in scenarios 1/2. Thus this comes down to application or hosts. Alain: All of us have been talking about networks. This is really relevant to the Ip stack and applications. Mark: you can still solve it with tunnels. Dave: No, your application can only see v6, the other end can only do v4. The reason might be because the app was never written to support another family, or it could be because its running on a host that is v6 or v4 only. We would really like all apps to be version agnostic, but they may be on a IPv6 only host. Peter: The issue is not equipment is dual stack v4/v6. At some point you just will not be able to get an IPv4 address. Dave: legacy v4 to v6 internet - looking for concensus to not solve this problem, asking who cares about this? Alain: argues that it may not be high priority, but that shouldn't stop anyone from working on it, Fred: again - looking for clarification - claims US military and China both have this requirment Ed Jenkins: IPV4 to IPV6 will eventually be needed and will be a long lasting requirement because of the existence of equipment that can never be upgraded (DOD) Dave: how to decide how to prioritize, 1) what scenarios need to be solved today, 2) for what are people currently using NAT-PT . What problems are being solved by NAT-PT. If we don't fix these problems people will never move off of NAT-PT. Woj: Scenario #3: confiused by how this has been changed - are we trying to address an IPv4 endpoint, Mark: Scenarios 1 and 2 both deal with keeping v4 alive - #1 has no v6, #2 brings in ipv6 has an infrastructure but is still about v4. Ok now we move into the land of translation - that is between ipv4 only worlds and ipv6 worlds. Translation land has to do with introducing new things that (4 scenarios that are combinations of V4 to V6) that can perform the translation. Woj: hmm scenario 3 - must it be tunneled over IPv6 Mark: could use MPLS or something , but , well this is an ipv4 ipv6 group so.... Woj: isn't this more like scenario #1? Mark: repeated his translation story - Woj: Does Scenario #1 include dual stack ... Mark: This is about NEW work .. feel free to dual stack if you like... Woj: can be done with other tunnel techniques.. ... : there are other solutions in this space, Dave Miles: confirm view that CGN is adding something new, Mark agrees: Dave: clarify - is their an assumption of using RFC1918 private IP space between CPE and CGN? Mark: issue is how to deal with overlapping private IP address space, could pop into #2 and don't have an with overlapping IPs Dave: argues tunneling not the only way to resolve the issue of overlapping rfc 1918 ip space, there are alternatives. CGN application - clarify that CGN can coexist with IPv6 - so is scenario #2 really a subset of scenario #3. Mark: it's an issue of why one uses IPv6. RFC1918 exhaustion with scenario #2 was written as a solution - could be written differently as a problem statement. Mark: continues about how #2 and #3 are different - #2 is I want to deploy IPv6 in my SP network and run IPv4 over it - it happens to solve the RFC 1918 problem Dave: mark and Dave agree on the restatement of the problem. Alain: doesn't like Dave's class E example - maybe PPOE would be a better example of how to transit the V6 portion of the net. Dave: is there a NAT 444 written down anywhere? Chair: no - there is a CGN document, but no 444 doc Dave: I'll write a draft. Jabber request: can we put number of hosts on the scenarios for clarification. Mark: no - because everyone's network is different. Woj: when do we see IPv4 ONLY talking to IPV6 only or vice versa - Mark: answer scenarios 3,4,5,6.. mark: Its not about apps, the doc is about wanting to deploy a _network_. Jari: There is an additional constraint in corp networks where you cant actually touch the software. you are expected to run a normal [existing] OS. Dave: You're right. We are talking about an IPv4 provisioned app, and an IPv6 provisioned app. There is a third, the stack is dual stack, host is dual stack, and the app is agnostic, but he only gets one type of address. We are all talking about a v4 only provisioned app and a v6 only provisioned app talking to each other. Mark: Concerned we are looking at this, that, etc. We are in the trap of listing out every combination that you can touch. That trap is providing less clarity than I had hoped for. Dave: My point is that it is not theoretical that you have v4 applications or v4 only OS. It is reality. It is also not theoretical that networks consist of heterogenous devices where you have both v4 and v6. I am saying we can simplify the problem because they all come out to the same thing Jari: We should ensure we can deploy these things in more cases than can be deployed today. Lets go through the scenarios and this or that, but we must give people tools so they can do this in more situations than we can do today. It's important that we motivate people to do IPv6. Christian: We are simplifying. We are defining what it means for something to be IP version X only. It means either the application, or the host, or the network is IP version X only. My push back on the doc is that it should define that in the beginning and then it makes it easier to describe. Ed: I agree too. The problem statement is the application that deals with only one address family. The solution space is richer with different solutions whether it is the application or the stack. There are always going to be different solutions. The solutions need to consider those different flavours where the restricted part of the pipe is. Alain: I think that doing this between this stack and the IP address on the machine is helpful because of the cases where we have overlapping technologies, and the cases where we have no choice. Mark: Everyone is agreeing. At the same time we have to step back. I hear, its not about saying I need an IPv6 only network - its about saying I need and IPv6 application. The drivers have been "oh wait, i need an IPv6 network", "i want to run a single stack network", "I want one network". We speak in terms of networks networks networks. Its not about the network, its about the applications. We need app developers in the room. All the applications need to turn IPv6. Dave: I don't think the wrong people are in the room. Im not a fan of saying you want an app-specific solution, that's every app doing something or ALG. That's the method of last resort. We would like something to be solved in an app independent fashion. We are broadening transition paths. Remi: Some hosts want IPv6 or IPv4 connectivity. The reason may be the application, the software, the IP stack or the networking piece. We are in the right room for talking about IPv6 connectivity. Mark: So there's the walk through the scenarios. THe first two are about v4. The last 4 are about IPv6. I wonder if we need to call out the network vs. the host/application is IPv6 only. Jari: We aren't doing scenarios because its fun, but because its important and we need to know what to do next. We have already decided tunnelling will be done, we have already started one solution in soft wires, so we are already doing work in that. The real question is whether we are going to do work on translation. Brian: We will go thorough the questions and try and gauge a sense of peoples acceptance. -- Brian: Im going to ask two question before asking are you interested in the scenario. 1) Are people interested in working on or writing tunnelling or translation. Jari: May I propose : Do you believe there is a clear cut case for either translation or tunnelling. Ie, there are situations where we have to do that. Remi: There may be solutions that combine both. Brian: 1: tunnelling plus NAT [vast majority raised hand] 2: translation [vast majority raised hand] Brian: Currently the results were a clear decisions for both tunnelling and translation. Randy: What this came to after lunch was: there are two general spaces:1) my broadband friends are running many many pieces that need to tunnel , 2) translation is when there are large chunks to be moved Jari: We will learn what modes/scenarios we are interested in. We will poll soon. Brian: The first scenario, the CGN solution. Who is actually seeing these types of problems today? Jari: We go through each. We ask whether the IETF should address (because you have that issues now or in the future). Fred: Cisco is working actively on CGN. Cullen: Speechless - I bet everyone in the room has one of those NATs, we have BEHAVE. What are we asking here? Jari: A carrier grade one. We are talking about the new work that the IETF needs to do. It is not what new work, but new work in this space. We are asking whether there is a need to do CGN. Etc. Alain: I do believe that this is something that is important, there is good work that is done in behave. I do not behave we should try and expand RFC 1918 into the SP space. Jari: you can object to specific proposals later. Mark: There are no IPv6 tunnels, there are CGN and gateways and there are different ways to do it. Dave: The question you had asked is whether we think the IETF needs work in this area. Then you asked whether you would contribute (to docs). Third, are people using or selling NAT-PT for this particular scenario. Jari: I just want to ask one question. Randy: This is the fourth time we have done on scenarios, when she keeps asking the same question again and again, I'm giving the wrong answer. Must ask, what answer do you want. Shin: If we cannot change CPE we have to look at NAT444. And the existing v4-only devices. We have to do it. I'm not saying IPv6 is not needed - IPv6 is needed. CGN has lots of limitations. There are many limitations, ports, sessions, UPnP. Please think about that. We have to do this. Remi: Does it include the case where the CGN does no NAT? Mark: Yes, anything that has to do with IPv4 to IPv4 without tunnelling/encapsulation. Who thinks the IETF should define scenario 1: 18 or so hands. Who thinks we should not: 0 hands. Scenario 2: Who things the IETF should solve cycles solving scenario 2: 29 for. Against: 0 Scenario 3: My IPv6 network to the IPv4 Internet: For: 28. Against: 1 Scenario 4: IPv6 Internet to Your IPv4 network: For: 27 Against: 2 Scenario 5: IPv4 Internet to my IPv6 Network: For: 20. Against: 3. Scenario 6: My IPv4 network to IPv6 Internet. For: 20 Against: 2 Table: Scenario For Against --------------+----------------+----------------- One 18 0 Two 29 0 Three 28 1 Four 27 2 Five 20 3 Six 20 2 Phillip: There are a number of working groups, BEHAVE, Softwires, v6ops, DNSops. I'm worried because now it will be split across four working groups. I don't know if this is the right solution, but do we at least want one mailing list to talk about this issue? I am worried the people that are focused on tunnels will not be able to provide translations and vice versa. This stuff could all get lost. Jari: We hear you. The trade offs are putting people in the same place - but do we have enough experts in that one place. If we put everything in a new working group can we get the right persons involved. I am not sure there is a perfect solution. Maybe with scenario 1 we could bring a bigger set of people into one room, including legacy v4 guys. Phillip: Maybe we should think about keeping the v4v6interim mailing list alive and going. Jari: How about we keep it alive until Minneapolis. Hopefully by Minneapolis we will have a way for BEHAVE to execute. Remi: I just want to say that I don't share the concern that those working on tunnelled solutions would miss something related to a translated solution. I think there can be a clear-cut separation. Phillip: We could bring the tunnelling stuff back into BEHAVE. It does in make some sense. Mark: If you look at some of the solutions that Softwires have done, like mesh, that you might not end up having those that build big routers going to BEHAVE, and therefore may not appreciate some of the things that go with routing. In Softwires we have people that know about big routers and IPv6. Phillip: Should BEHAVE look at NATs, and Softwire just look at how to plug that into the tunnelling solution? Mark: Whenever you start carving up port spaces this way, that way, the other way, that is when you need BEHAVE experts. When talking about tunnels you need Softwires. Jari: Time to close the meeting. We reach the conclusion that we do need both the solutions. I am kind of surprised, perhaps I saw we had only two solutions [translation and tunnelling]. Thank you all. Dan: Today was my 40th Birthday, and I enjoyed spending it with you. ---- Meeting Closed ----