RE: Netfilter (Linux) Does IPv6 NAT
Hi Doug, We have local source address selection mechanisms in recent Windows versions that use randomized IIDs on outbound connections today. This doesn't prevent exposure of the information regarding the internal network structure, but nor do firewalls at publically addressed IPv4 institutions today. This has been covered many times, but once more (with feeling) ... The problem that 4941 is designed to fix is to avoid being able to track the same user on *different* networks. This is possible because by default the host portion of the address remains constant, and theoretically globally unique. Privacy for a user that is always connecting through the same network is a whole different basket of bagels. We have not had carrier NAT solutions until walled gardens came in with 3G networks, and now people are mooting CGNs, but I have not seen many in general use for access networks. Up until now, we have migrated addresses when a new PDP-Context, PPP (Dialup/xDSL) or DHCP Lease has been supplied. In IPv4, the session uniquely identifies/identified the session and links to the user during that interval. The same is true for IPv6, except that IPv6 defaulted to MAC based IIDs. With 4941, the same Layer 2 identity is removed, and we have the same circumstances with IPv4 and IPv6. So CGNs for IPv4 are an answer to a new question that you pose where the implicit assumption is that it is insufficient to maintain address unlinkability between different PDP-Context/PPP/DHCP sessions. Given that we have good local addressing mechanisms in IPv6 (ULA, Link-local) and automatic global prefix configuration mechanisms (SAA/RA/DHCPv6/DHCPv6-PD), I would like to know: What are the advantages of CGNs for IPv6 and does the cost to application development justify the change? Sincerely, Greg Daley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
Sabahattin Gucukoglu wrote: 1. If you just want to camouflage internal clients, do it with privacy addresses or a socks proxy and clients. I don't see a purpose to camouflage internal clients from internal peers. And my ISP would probably and rightfully refuse to route my IP datagrams if he could not recognize me as a peer and paying customer. But there is regularly no need that anybody else besides my ISP can distinguish my IP datagrams from those of other customers of this ISP. The typical residential/home internet access is like a 1-family home, and this is even explicit part of many ISPs home DSL subscriber contracts. In real life, all members of a household typically have a key to the outer door, and that outer door is usually closed or locked most of the time, while most doors within the house are not locked most of the time. It is very desirable to have as much privacy as achievable from the rest of the world at the network layer, because it is the ultimate prerequisite for application and user to control and limit disclosure of ones identity to network peers. When a sufficient part of the network address that your peers on the internet see when you talk to them, is sufficiently unique and constant over time, then privacy is *completely* impossible. A network address with a prefix that uniquely idenfies individual subscribers over a prolonged time amounts to a pseudonym. RFIDs with unique IDs and biometrics have the very similar problems. Since there _are_ going to be situations when your identity is visible along with the IP address that was used to convey your identity, this information will spread within a matter of at most days. SMTP-Servers regularly write the sender's IP-Address into rfc(2)822 Received:-headers of EMails they forward and distributed to all receipients. In case of EMail lists, this informatio may end up in public Email archives and easily accessible through Internet search engines for everyone as a result. A logical step for muggers would be to profile prospective victims with a smart phone by covertly take a photo, try Facebooks face recognition, use peoplefinders, and then google streetview in order to assess the amount of money someone might be capable and willing to spend on _not_ getting harmed when being assaulted. Profiling people is fairly easy when there are no privacy protection laws, as in the US, and more and more common for businesses on employees and customers. Crooks might appreciate a level playing field. I don't! The problem with biometrics, when they're abused, is that they're regularly difficult to change (face recognition, retina scan, fingerprint). Over here, in old Europe, we believe that privacy is a basic human right and that implies that each person must have ultimate control over all collection, use and distribution of PII. Which means an explicit opt-in prerequisite, that is voluntary and revocable anytime, precise and clearly limited about collectors, data items, purposesuse cases for all PII about oneself -- backed laws to enforce data privacy and punish violators. 2. If you want to hide, do it with proper means, i.e., tor. Tor is of limited usefulness, at least for me. I can not think of a single reasonable use case for myself (I do not have any stuff for upload to any *leaks places). You needn't suppose that the one agent who has the most insight into your network traffic, that being your ISP, is trustworthy. My neighbours are the ones who know best at what time I go on vacation, and I even leave the key to my house with one of them while I'm away. You are implying, that particular neighbour should be my real and only concern and everybodyeverthing else should be irrelevant in comparison. Fortunately, the real world where I live is quite different from yours. I'm not afraid of my neighbor and neither of my ISP. It would be a felony with serious consequences for my ISP to listen into communication of its customers (even when it is cleartext). While keeping the shutters on ones windows firmly locked 24/7 might be safer, it believe the benefits of opening the shutters during the day outweigh the risks...at least where I live. Especially true given that it's the one agent with the highest likelihood of actually succeeding in the intercept of your Internet traffic. I'm much more worried about other threat scenarios. By your logic, it would be a bad idea for banks and shop owners to let bank clerks and armoured car personnel touch any of their cash money, because those would be the folks with the highest likelyhood in succeeding to steal it. I believe this amounts to flawed logic. One will need to deal with that kind of risk in a different fashion. Or that it often has controls over its routers which allow monitoring beyond rightful boundaries. Best intentions aside. So what? Google probably stores and anylyzes more about google searches and more about @gmail.com EMail contents than all of the
Re: Netfilter (Linux) Does IPv6 NAT
You really don't know what IPv6 boxes are capable of. Below is the start of a netstat of the active IPv6 connections. The first connection is a internal connection. The stack automatically choose to use the ULA address (fd92) over the non-ULA address as it was a connection to a internal host. Both machines have ULA and non ULA addresses. The other connections are all to external servers. They use the non-ULA address. That address could be changed at anytime the same as your IPv4 is being changed. The IPv6 hosts don't care. You also don't need NAT66 to achieve this. Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp6 0 0 fd92:7065:b8e::6.50942 fd92:7065:b8e::2.22ESTABLISHED tcp6 0 0 2001:470:1f00:82.50941 2001:4860:8005::.80ESTABLISHED tcp6 0 0 2001:470:1f00:82.50940 2001:4860:4001:8.80ESTABLISHED tcp6 0 0 2001:470:1f00:82.50286 2001:4860:4001:8.80CLOSE_WAIT tcp6 0 0 2001:470:1f00:82.49833 2001:4f8:4:d::8.5223 ESTABLISHED This is done using machines that you can walk down to the local computer store and pick up today. I didn't have to configure anything to achieve this other than have the router advertise a second ULA prefix. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
Greg Daley wrote: I do not know if this is a current environment, or what you would like to see (A reference would be good). That is the current environment for home DSL subscribers (IPv4) in Germany. One would use DHCPv6-PD to request the lease for a period, Router Advertise it downstream to your devices, which use it only for 24h, and at the end of the time return the prefix to the pool. At most 24h, I can get a new DHCP lease on request every 2 minutes if I want to. With a single IPv4 address on the external interface of the DSL router, this does affect all connections, of course. If you wish to rotate through address space, you could still use the 24 hour lease either as a replacement for or in addition to your static prefix in IPv6, but you do not need to use NAT. I do *NOT* want dynamic addresses on my local network. These ought to be static. This is why IPv4 NAT and rfc1918 private address space is so useful. An IPv6 NAT would have to offer the same functionality, of course: Address assigned through DHCP on the local/home network, but extending the leases for the same addresses, and a randomized temporary dynamic address on the external interface of the DSL router. Renumbering the internal network would be completely silly. You certainly do not want any interruptions of the local network traffic just because you frequently change the address on the external interface for privacy reasons. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Netfilter (Linux) Does IPv6 NAT
Hi Martin, The assumption that information is present only within the IP address is erroneous. This has been studied for mobile IPv6 users as well, and there is information leakage up and down the stack. We have local source address selection mechanisms in recent Windows versions that use randomized IIDs on outbound connections today. This doesn't prevent exposure of the information regarding the internal network structure, but nor do firewalls at publically addressed IPv4 institutions today. Putting NATs on the path just causes the device inside the network to be unaware of its presented addresses, which means that it will impede peer-to-peer communications, as it cannot even describe its available services without external information services. This is the awful situation in IPv4 today: Address scarcity is not the problem, addressability is the problem. Greg Daley -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: Tuesday, 6 December 2011 1:00 PM To: mail-dated-1325290081.a3a...@sabahattin-gucukoglu.com Cc: ietf@ietf.org Subject: Re: Netfilter (Linux) Does IPv6 NAT Sabahattin Gucukoglu wrote: In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working- on -NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. I fail to understand the issue that you have with this. Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for outbound connections by default (i.e. *NO* static network prefix that can be linked to a single ISP customer) would be extremely irresponsible with respect to data privacy protection. Without that, I consider IPv6 a complete no-go. And many DSL routers are based on Linux, so having an implementation of such a NAT is a prerequisite before IPv6 can be reasonably offered to home customers in Europe. I'm perfectly OK with folks getting static IPv6 network prefixes for specific applications that desperately need it. But the default definitely ought to be temporary dynamic IPv6 addresses, especially for outbound connections. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Netfilter (Linux) Does IPv6 NAT
Hi Martin, -Original Message- From: Martin Rex [mailto:m...@sap.com] Sent: Tuesday, 6 December 2011 1:30 PM To: Greg Daley Cc: m...@sap.com; mail-dated-1325290081.a3a4e0@sabahattin- gucukoglu.com; ietf@ietf.org Subject: Re: Netfilter (Linux) Does IPv6 NAT Greg Daley wrote: The assumption that information is present only within the IP address is erroneous. This has been studied for mobile IPv6 users as well, and there is information leakage up and down the stack. Your reasoning is obviously flawed. Having a temporary dynamic IP address assigned will not prevent any negligent or privacy-ignorant protocols and apps higher up the stack to reveal identifying information about you. My point is that it is unhelpful to ignore the principles underpinning IPv6 architecture in order to fail to achieve your privacy goal. But _without_ a temporary dynamic IP address, each and every of your network communcation will be 100% identifyable as you for everybody that can oberserve you IP datagrams floating by, even when you're using IPSEC. Yes, when your outbound sessions hit the internet, devices on the path can see where you come from. In my world, these people can see what they can already learn from watching my IKEv1 aggressive mode identity (if not using certs) or WWW cookies, or TCP stack behaviour and use profile. In your world you gave up peer-to-peer IPSec, SIP, etc initiated from either end to gain a false feeling of privacy. I fail to understand what you mean by randomized IIDs. What you need is a temporary network address randomized by you ISP so that your address blends within the entire customer base of that ISP. Please read RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration. Putting NATs on the path just causes the device inside the network to be unaware of its presented addresses, which means that it will impede peer-to-peer communications, as it cannot even describe its available services without external information services. Asking your border router for the temporary external IP-Address is trivial compared to performing a secure DNS lookup. I have no interest in comparing apples to oranges. I have implemented ICE and I can say it is non-trivial. Sincerely Greg Daley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Netfilter (Linux) Does IPv6 NAT
Dear Martin, I think you're confused. Whatever IPv6 source address is in the outgoing packet from the CPE is bound 1:1 to the subscriber. You can't conceal the address of the subscriber, if you ever want to get any packets back. The outgoing packet is bound 1:1 to the ISP of the subscriber, any only the ISP knows to which of his customers he is routing the datagrams during any specific point in time. The DHCP lease should be 24h at most and the ISP is bound by data protection laws to not make the mapping publicly accessible except under very specific legal exceptions. I do not know if this is a current environment, or what you would like to see (A reference would be good). If you wish to rotate through address space, you could still use the 24 hour lease either as a replacement for or in addition to your static prefix in IPv6, but you do not need to use NAT. One would use DHCPv6-PD to request the lease for a period, Router Advertise it downstream to your devices, which use it only for 24h, and at the end of the time return the prefix to the pool. The mapping then becomes a routing one, rather than a NAT one, and the routing mapping only exists as long as the connection is available (if using PPP) AND the DHCP lease is held (under the same rules or laws you indicate). While I do not think there is an option to return this prefix to the pool, and assign me a different prefix, it would be trivial to implement, and would not create a barrier to sessions like NAT would. (Note that I would decouple the prefix return and assignment to de-link them in time). This is presented as a counter-example to NAT is the answer, because this is a technologist perspective, and there are other solutions. What we should really be doing is engaging with industry to identify the actual need, not choosing technical paths because of their feasibility in code. Sincerely, Greg Daley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
On 12/05/2011 18:11, Greg Daley wrote: The assumption that information is present only within the IP address is erroneous. This has been studied for mobile IPv6 users as well, and there is information leakage up and down the stack. We have local source address selection mechanisms in recent Windows versions that use randomized IIDs on outbound connections today. This doesn't prevent exposure of the information regarding the internal network structure, but nor do firewalls at publically addressed IPv4 institutions today. This has been covered many times, but once more (with feeling) ... The problem that 4941 is designed to fix is to avoid being able to track the same user on *different* networks. This is possible because by default the host portion of the address remains constant, and theoretically globally unique. Privacy for a user that is always connecting through the same network is a whole different basket of bagels. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
On 2011-12-06 18:14, Mark Andrews wrote: ... The so-called IPv6 privacy addresses are terminology fud. No, there is no fear, uncertainty or doubt involved. If you don't want to be traceable by your MAC address, use privacy addresses. That will even conceal from parents which child is downloading music. If parents want to know which child is doing what they can do that even with privacy addresses. Privacy addresses don't change the mac, that just don't encode the mac in the IPv6 address. If the kids start playing mac games use 802.1x. Yes, of course it depends on the child's and the parents' technical sophistication. I was limiting my comment to layer 3, since Martin was arguing that layer 3 NAT helps privacy. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
Martin, Renumbering the internal network would be completely silly. You certainly do not want any interruptions of the local network traffic just because you frequently change the address on the external interface for privacy reasons. This is why ULAs are useful. People just need to get used to the fact that IPv6 addresses derived from ISPs will change from time to time, and that you will have several of them. This is not your grandfather's TCP/IP. This is also why we have the MIF, HOMENET and 6RENUM WGs. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
Brian, I'd like to join this from another angle. What exactly does changing your v4 address get you in terms of privacy? It's my understanding that protocols including TCP, HTTP, TLS, and very much the web platform are fairly easily linked. That is, it's relatively easy to determine with reasonably widely available software whether two connections come from the same end-system across a NAT and regardless of what's done to the IP addresses. So, I'd like to better understand what attacks changing the outer DHCP address protects against in terms of privacy. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
Sabahattin Gucukoglu wrote: In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. I fail to understand the issue that you have with this. Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for outbound connections by default (i.e. *NO* static network prefix that can be linked to a single ISP customer) would be extremely irresponsible with respect to data privacy protection. Without that, I consider IPv6 a complete no-go. And many DSL routers are based on Linux, so having an implementation of such a NAT is a prerequisite before IPv6 can be reasonably offered to home customers in Europe. I'm perfectly OK with folks getting static IPv6 network prefixes for specific applications that desperately need it. But the default definitely ought to be temporary dynamic IPv6 addresses, especially for outbound connections. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
On 2011-12-06 15:00, Martin Rex wrote: Sabahattin Gucukoglu wrote: In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. I fail to understand the issue that you have with this. Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for outbound connections by default (i.e. *NO* static network prefix that can be linked to a single ISP customer) I think you're confused. Whatever IPv6 source address is in the outgoing packet from the CPE is bound 1:1 to the subscriber. You can't conceal the address of the subscriber, if you ever want to get any packets back. If you want to protect the privacy of individuals within the home (etc.) behind the CPE, you can use IPv6 privacy addresses. But the traffic will still be traceable back to the CPE, of course. I hope you aren't under the illusion that NAT44 in CPE provides any privacy. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
Greg Daley wrote: The assumption that information is present only within the IP address is erroneous. This has been studied for mobile IPv6 users as well, and there is information leakage up and down the stack. Your reasoning is obviously flawed. Having a temporary dynamic IP address assigned will not prevent any negligent or privacy-ignorant protocols and apps higher up the stack to reveal identifying information about you. But _without_ a temporary dynamic IP address, each and every of your network communcation will be 100% identifyable as you for everybody that can oberserve you IP datagrams floating by, even when you're using IPSEC. We have local source address selection mechanisms in recent Windows versions that use randomized IIDs on outbound connections today. This doesn't prevent exposure of the information regarding the internal network structure, but nor do firewalls at publically addressed IPv4 institutions today. I fail to understand what you mean by randomized IIDs. What you need is a temporary network address randomized by you ISP so that your address blends within the entire customer base of that ISP. Putting NATs on the path just causes the device inside the network to be unaware of its presented addresses, which means that it will impede peer-to-peer communications, as it cannot even describe its available services without external information services. Asking your border router for the temporary external IP-Address is trivial compared to performing a secure DNS lookup. This is the awful situation in IPv4 today: Address scarcity is not the problem, addressability is the problem. It is a problem for which solutions exists or can be built with moderate effort. Privacy is a much more serious problem today, and without temporary dynamic addresses assigned by the ISP privacy can no longer exist. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
Brian E Carpenter wrote: Martin Rex wrote: Sabahattin Gucukoglu wrote: In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. I fail to understand the issue that you have with this. Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for outbound connections by default (i.e. *NO* static network prefix that can be linked to a single ISP customer) I think you're confused. Whatever IPv6 source address is in the outgoing packet from the CPE is bound 1:1 to the subscriber. You can't conceal the address of the subscriber, if you ever want to get any packets back. The outgoing packet is bound 1:1 to the ISP of the subscriber, any only the ISP knows to which of his customers he is routing the datagrams during any specific point in time. The DHCP lease should be 24h at most and the ISP is bound by data protection laws to not make the mapping publicly accessible except under very specific legal exceptions. If you want to protect the privacy of individuals within the home (etc.) behind the CPE, you can use IPv6 privacy addresses. But the traffic will still be traceable back to the CPE, of course. The so-called IPv6 privacy addresses are terminology fud. I hope you aren't under the illusion that NAT44 in CPE provides any privacy. For my ISP (and it seems to be the norm for german home customers), that is not an illusion, but rather a feature. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
On 2011-12-06 15:40, Martin Rex wrote: Brian E Carpenter wrote: Martin Rex wrote: Sabahattin Gucukoglu wrote: In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. I fail to understand the issue that you have with this. Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for outbound connections by default (i.e. *NO* static network prefix that can be linked to a single ISP customer) I think you're confused. Whatever IPv6 source address is in the outgoing packet from the CPE is bound 1:1 to the subscriber. You can't conceal the address of the subscriber, if you ever want to get any packets back. The outgoing packet is bound 1:1 to the ISP of the subscriber, any only the ISP knows to which of his customers he is routing the datagrams during any specific point in time. The DHCP lease should be 24h at most and the ISP is bound by data protection laws to not make the mapping publicly accessible except under very specific legal exceptions. If you are paranoid about your IP address, that's fine. Personally, I prefer a stable address. If your IPv6 prefix changes every day, your home network will get renumbered every day. What does this have to do with NAT? If you want to protect the privacy of individuals within the home (etc.) behind the CPE, you can use IPv6 privacy addresses. But the traffic will still be traceable back to the CPE, of course. The so-called IPv6 privacy addresses are terminology fud. No, there is no fear, uncertainty or doubt involved. If you don't want to be traceable by your MAC address, use privacy addresses. That will even conceal from parents which child is downloading music. I hope you aren't under the illusion that NAT44 in CPE provides any privacy. For my ISP (and it seems to be the norm for german home customers), that is not an illusion, but rather a feature. You mean there is a privacy benefit in translating some address such as 10.1.1.2 into a routeable IPv4 address that can, as you say, be traced back to you even if it changes every day? You'll have to explain that. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
In message 4edd894e.6030...@gmail.com, Brian E Carpenter writes: On 2011-12-06 15:40, Martin Rex wrote: Brian E Carpenter wrote: Martin Rex wrote: Sabahattin Gucukoglu wrote: In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on-N AT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. I fail to understand the issue that you have with this. Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for outbound connections by default (i.e. *NO* static network prefix that can be linked to a single ISP customer) I think you're confused. Whatever IPv6 source address is in the outgoing packet from the CPE is bound 1:1 to the subscriber. You can't conceal the address of the subscriber, if you ever want to get any packets back. The outgoing packet is bound 1:1 to the ISP of the subscriber, any only the ISP knows to which of his customers he is routing the datagrams during any specific point in time. The DHCP lease should be 24h at most and the ISP is bound by data protection laws to not make the mapping publicly accessible except under very specific legal exceptions. If you are paranoid about your IP address, that's fine. Personally, I prefer a stable address. If your IPv6 prefix changes every day, your home network will get renumbered every day. What does this have to do with NAT? If you want to protect the privacy of individuals within the home (etc.) behind the CPE, you can use IPv6 privacy addresses. But the traffic will still be traceable back to the CPE, of course. The so-called IPv6 privacy addresses are terminology fud. No, there is no fear, uncertainty or doubt involved. If you don't want to be traceable by your MAC address, use privacy addresses. That will even conceal from parents which child is downloading music. If parents want to know which child is doing what they can do that even with privacy addresses. Privacy addresses don't change the mac, that just don't encode the mac in the IPv6 address. If the kids start playing mac games use 802.1x. I hope you aren't under the illusion that NAT44 in CPE provides any privacy. For my ISP (and it seems to be the norm for german home customers), that is not an illusion, but rather a feature. You mean there is a privacy benefit in translating some address such as 10.1.1.2 into a routeable IPv4 address that can, as you say, be traced back to you even if it changes every day? You'll have to explain that. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Netfilter (Linux) Does IPv6 NAT
Is the problem that they don't get what IPv6 is for? Or that we haven't articulated the use cases appropriately? Alternatively, Is there something they are trying to achieve other than more=good? Greg Daley -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sabahattin Gucukoglu Sent: Thursday, 1 December 2011 11:08 AM To: ietf@ietf.org Subject: Netfilter (Linux) Does IPv6 NAT In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on- NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
Does it support RFC 6296? Jumping into this discussion - it doesn't support RFC 6296 yet, but I'm currently looking into this as an additional option. Also I'm looking into doing only port assigments instead of Full NAT for IPv6, as suggested by Rusty Russell. Please keep my CCed, I'm not subscribed. Regards Brian Carpenter On 2011-12-01 13:07, Sabahattin Gucukoglu wrote: In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Netfilter (Linux) Does IPv6 NAT
In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
Does it support RFC 6296? Regards Brian Carpenter On 2011-12-01 13:07, Sabahattin Gucukoglu wrote: In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
On 1 Dec 2011, at 01:20, Brian E Carpenter wrote: Does it support RFC 6296? That was done in a separate, non-official implementation here: http://lwn.net/Articles/451914/ With this one, you can NAT between ranges, and that's it, if I've got this right. Fragmentation is also an issue. I'm not a netfilter expert, though, so I can't say whether it's possible to implement RFC6296 with it. The checksum difference calculation is obviously going to pose a problem. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Iljitsch van Beijnum allegedly wrote on 03 20 2009 9:18 AM: The renumbering and multihoming arguments are especially troublesome: the hard part in multihoming isn't giving a host interface a new address, but making sure that everything that points to that address, from the DNS to firewall rules, is updated. But address independence eliminates 90% of what needs to be updated (internal policy etc.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Christian Vogt allegedly wrote on 03 19 2009 2:21 PM: I was actually making a different statement. I was saying that end-to-end (locator/address) transparency is important in the existing Internet because IP addresses are overloaded as identifiers by some applications. If there wasn't this kind of overloading, then the lack of end-to-end (locator/address) transparency would be less of an issue. OK, now I understand. You're not talking about end-to-end transparency in general but end-to-end address transparency. I think I agree completely. We are certainly working toward not caring what addresses are used. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Brian E Carpenter allegedly wrote on 03 22 2009 7:30 AM: (I never said I liked NAT, did I?) In your opinion, what sucks less? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Comment on draft-iab-ipv6-nat-00
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Scott Brim Sent: Sunday, March 22, 2009 7:11 AM To: Brian E Carpenter Cc: Iljitsch van Beijnum; IAB; IETF Discussion Mailing List; Lixia Zhang Subject: Re: Comment on draft-iab-ipv6-nat-00 Brian E Carpenter allegedly wrote on 03 21 2009 4:07 PM: So instead, you run NAT at every ISP connection. Your internal users get NATted to an ISP prefix at whichever exit point their traffic happens to reach, which automatically causes their return traffic to come through the same ISP. That exit point is locally chosen by the local routing setup. You don't need any worldwide coordination of the BGP4 advertisements, because there aren't any expect the ISP's normal ones. Also, traffic flows inside your network are localised, since traffic goes out and returns through a (reasonably) local gateway. When one of these NATs goes down, active connections will be lost, but IGP routing will switch users automatically to a different NAT when they retry. If you allow your hosts to use multiple connection points into the Internet, and external routing changes so that the packets they send go out different connection points, their apparent source address can change. One of the requirements for effective use of NAT and multihoming is that your hosts' peers need to handle this (via Multipath, HIP, MIP, SCTP or whatever). That is, you can't allow your hosts to use multiple connection points until everyone _else_ they talk to has been upgraded. How will you know when that is? A host knows if it is using HIP, MIP, or SCTP to communicate with another host. FYI, there is also a new idea for Mobile DTLS which provides similar address mobility, draft-barrett-mobile-dtls-00.txt. -d ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Brian E Carpenter allegedly wrote on 03 19 2009 1:48 PM: I recently had this exchange with Dan Wing on the BEHAVE list: ... it seems to me that we might consider defining a generic 'referral object', containing more information than just an address, that could be passed among application entities. It could contain TLVs that would provide the semantics of the referred address as well as the raw address bits. Does this seem worth exploring? Yes, this could form the basis for very useful guidance to application designers. ICE does something like this already, but abstracting its functions up several levels, as you propose, would be useful. Referrals are hard to figure out. I think the tradeoffs are worth serious study. First party referrals like this are interesting but not so hard as third party referrals (Tom tells Dick how to reach Harry). They assume that Tom knows Dick's and Harry's shared scope. Can we assume we have some kind of globally unique identifiers that are globally unique? So far that has been extremely hard to pull off. I have a suspicion that for referrals you want to go all the way back to domain names and URIs. Also, the referral problem is multilayer (you want to be able to refer to processes in addition to machines) but only at the layer that needs that information. The question, which is something like the e2e argument, is whether to bother providing details in network-layer referrals if they will be trumped by higher-layer needs. But in any case we should do a major investigation of referrals in the light of location/identification separation and the fracturing of the Internet into various scopes. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Dan Wing allegedly wrote on 03 22 2009 10:09 AM: When one of these NATs goes down, active connections will be lost, but IGP routing will switch users automatically to a different NAT when they retry. If you allow your hosts to use multiple connection points into the Internet, and external routing changes so that the packets they send go out different connection points, their apparent source address can change. One of the requirements for effective use of NAT and multihoming is that your hosts' peers need to handle this (via Multipath, HIP, MIP, SCTP or whatever). That is, you can't allow your hosts to use multiple connection points until everyone _else_ they talk to has been upgraded. How will you know when that is? A host knows if it is using HIP, MIP, or SCTP to communicate with another host. I was asking how the site knows when its hosts peers have been upgraded, so that it can allow their traffic to be routed out multiple interfaces. FYI, there is also a new idea for Mobile DTLS which provides similar address mobility, draft-barrett-mobile-dtls-00.txt. Yes but that should be a different thread. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Scott Brim wrote: I was asking how the site knows when its hosts peers have been upgraded, so that it can allow their traffic to be routed out multiple interfaces. Yeah, exactly, although the canonical Unix-y way to do this would be to try it and see what you get back. If it doesn't work, catch the error and fall back to whatever it is you've planned to fall back to. There are obvious problems with this in a network environment (latency, resource consumption) but it's already how the IETF has chosen to deal with NAT traversal (ICE) so I expect there's a reasonable question about whether or not connectivity tests can (or should) be extended to transport, etc.. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Melinda Shore wrote: Scott Brim wrote: I was asking how the site knows when its hosts peers have been upgraded, so that it can allow their traffic to be routed out multiple interfaces. Yeah, exactly, although the canonical Unix-y way to do this would be to try it and see what you get back. If it doesn't work, catch the error and fall back to whatever it is you've planned to fall back to. There are obvious problems with this in a network environment (latency, resource consumption) but it's already how the IETF has chosen to deal with NAT traversal (ICE) so I expect there's a reasonable question about whether or not connectivity tests can (or should) be extended to transport, etc.. Yeah because resource reservation and and capability negotiation are definitely thing we want to have to do on an IP network before initiating a connection. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Comment on draft-iab-ipv6-nat-00
-Original Message- From: Scott Brim [mailto:s...@employees.org] Sent: Sunday, March 22, 2009 10:53 AM To: Dan Wing Cc: 'Brian E Carpenter'; 'Iljitsch van Beijnum'; 'IAB'; 'IETF Discussion Mailing List'; 'Lixia Zhang' Subject: Re: Comment on draft-iab-ipv6-nat-00 Dan Wing allegedly wrote on 03 22 2009 10:09 AM: When one of these NATs goes down, active connections will be lost, but IGP routing will switch users automatically to a different NAT when they retry. If you allow your hosts to use multiple connection points into the Internet, and external routing changes so that the packets they send go out different connection points, their apparent source address can change. One of the requirements for effective use of NAT and multihoming is that your hosts' peers need to handle this (via Multipath, HIP, MIP, SCTP or whatever). That is, you can't allow your hosts to use multiple connection points until everyone _else_ they talk to has been upgraded. How will you know when that is? A host knows if it is using HIP, MIP, or SCTP to communicate with another host. I was asking how the site knows when its hosts peers have been upgraded, so that it can allow their traffic to be routed out multiple interfaces. Thinking out loud, I posit that IPv6 route headers might be useful to steer traffic to a specific NAT66, until the host indicates (to the network) that it doesn't need such steering. There are undoubtedly other techniques. -d FYI, there is also a new idea for Mobile DTLS which provides similar address mobility, draft-barrett-mobile-dtls-00.txt. Yes but that should be a different thread. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Keith Moore allegedly wrote on 03 19 2009 5:17 AM:
It's all well and good to imagine a world where there would be a clear
ID-LOC separation. But we've never created such a world, and we don't
currently have an ID-LOC mapping layer that is good enough to use by all
applications.
I don't think this question needs to arise. There is no need, or
reason, that a single identifier would be used for all purposes.
Identifiers that are used to find out where to send packets for {initial
discovery (mapping), contact, and establishment of a session} do not
have to be the same as identifiers that applications use for session
maintenance. Higher layer identifiers can be transient and only need to
be unique within their very limited scope of use. The requirements on
their use are very different from requirements for identifiers used for
initial discovery and contact. There is no reason why they need to have
anything to do with locators. Only the identifiers that are used for
initial discovery need to be mapped -- for example domain names and URIs.
DNS falls short in many ways. And as long as there is
not a universal mapping layer that is aware of things like NATs and
mobility, and for that matter as long as there are devices that impose
arbitrary limitations on traffic flow (e.g. connections have to be
initiated from inside), there will be a need for applications to deal
explicitly with IP addresses. Sure it's ugly but it's the best that
applications can do.
I don't see this. You need something (e.g. a domain name or URI) to map
to _some_ addresses which you can use to launch your initial packets
toward your destination. They don't have to be the same addresses that
the destination thinks it has, as long as the packets get there and
there is a mechanism to establish security associations and multiple
path use.
Saying that applications should use names rather than addresses,
especially in the context of a NATted Internet, is tantamount to saying
(a) that we have perfect faith in DNS to reliably map names to addresses
at all times, in all realms, and that DNS RRs will never leak across
realm boundaries, and (b) that we have perfect faith that any address
pair chosen by the host stack for communication will continue to
function for the entire lifetime of the association.
No no no. The address pair just has to last long enough to establish an
association. If we're lucky we'll figure out how to do it even while IP
addresses are changing.
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Pete Resnick allegedly wrote on 03 19 2009 11:04 AM: I'm guessing we're in violent agreement, but NATs and mobility and traffic flow limiters actually make it impossible (viewing it from the other end) to use IP addresses: Giving a reference to myself using my own IP address when I am behind a NAT is useless; using a name, if one is available, is the only way to go. (And I still agree with your above paragraph.) Yes. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
NAT66 multihoming red herring, was: Re: Comment on draft-iab-ipv6-nat-00
On 20 mrt 2009, at 14:40, Brian E Carpenter wrote: NAT does not offer ANY multihoming benefits whatsoever, in fact, NAT breaks multihoming because after a rehoming event, the addresses are translated differently. It's correct that NAT changeovers break existing sessions. But your blanket statement isn't true. NAT-based multihoming has the major benefit that the number of extra BGP4 routes caused by a multihomed site is exactly zero. No. What you're talking about is multiaddress multihoming. Then you add NAT to hide the changes to addresses from the hosts. But IPv6 hosts can work with multiple addresses anyway (well, there's the ingress filtering issue) so NAT is largely orthogonal to the multihoming. Also, shim6 gives you actual multihoming where sessions survive rather than the watered down thing where you only get to reestablish new sessions. Also, NAT-based multihoming has value for large international corporate networks with dozens or hundreds of interconnection points to the public network. It basically solves their address management problem when dealing with multiple ISPs in multiple locations. That's running code today. People run whatever they can get away with. Doesn't mean it's a good idea. However, I do agree that it's useful to have stable internal addressing when external connectivity is subject to change. That is a legitimate advantage of NAT (66) which we haven't managed to make work without NAT. We could though, by making sure that ULAs are used for local connectivity regardless of the external connectivity. On 21 mrt 2009, at 16:07, Brian E Carpenter wrote: Suppose you're operating a large international network with (to take a random example) IPv4 1/8 as its PI prefix. You can't just advertise 1/8 in BGP4, because in fact it is split up into many longer prefixes for various kinds of use and various geographies. Then what is the point of having a single prefix? So how do you connect your internal users to the Internet? Same way as everyone else, return the /8. You have (I'm making this up) 100 different interconnects to the public Internet around the world, across a variety of ISPs. If you advertise longer prefixes out of 1/8 through those ISPs, life gets highly complex if you want multihoming. Certainly you won't be able to advertise *all* those prefixes through *all* those ISPs, so you'll need a complex worldwide management system just for your BGP4 advertisements, to decide which prefixes are advertised where, and what the desired backup paths are. It can be done, but the OPEX is high. Cost for the community is also high because a single organization puts a whole bunch of prefixes in the routing table. So instead, you run NAT at every ISP connection. Ok, I said they didn't need the /8 before, but now you've completely lost me. What is the point of having that prefix now?? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Comment on draft-iab-ipv6-nat-00
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel Jaeggli Sent: Sunday, March 22, 2009 11:05 AM To: Melinda Shore Cc: 'IAB'; 'IETF Discussion Mailing List' Subject: Re: Comment on draft-iab-ipv6-nat-00 Melinda Shore wrote: Scott Brim wrote: I was asking how the site knows when its hosts peers have been upgraded, so that it can allow their traffic to be routed out multiple interfaces. Yeah, exactly, although the canonical Unix-y way to do this would be to try it and see what you get back. If it doesn't work, catch the error and fall back to whatever it is you've planned to fall back to. There are obvious problems with this in a network environment (latency, resource consumption) but it's already how the IETF has chosen to deal with NAT traversal (ICE) so I expect there's a reasonable question about whether or not connectivity tests can (or should) be extended to transport, etc.. Yeah because resource reservation and and capability negotiation are definitely thing we want to have to do on an IP network before initiating a connection. ICE does not perform resource reservation and ICE does not perform capability negotiation. -d Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Dan Wing wrote: ICE does not perform resource reservation and ICE does not perform capability negotiation. You might not call it that but it does, in fact, snag resources. On the capability negotiation front I figure that's just a matter of time. (Somebody needs to come up with a cool acronym expansion for METASTASIS). That said, I'm not crazy about capability negotiation. Try something and send meaningful error messages if it doesn't work. Avoid race conditions and try to keep state machines cleaner. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Comment on draft-iab-ipv6-nat-00
-Original Message- From: Melinda Shore [mailto:melinda.sh...@gmail.com] Sent: Sunday, March 22, 2009 12:44 PM To: Dan Wing Cc: 'Joel Jaeggli'; 'IAB'; 'IETF Discussion Mailing List' Subject: Re: Comment on draft-iab-ipv6-nat-00 Dan Wing wrote: ICE does not perform resource reservation and ICE does not perform capability negotiation. You might not call it that but it does, in fact, snag resources. ICE sends UDP packets and TCP packets. I agree they might create state in a NAT, and state in a NAT is a resource. But with that argument my web browser is also doing 'resource reservation'. On the capability negotiation front I figure that's just a matter of time. (Somebody needs to come up with a cool acronym expansion for METASTASIS). Sure. But every exensible protocol can do 'capability negotiation'. TCP does it: winscale, timestamps, and SACK are all capabilities that are negotiated during connection establishment. -d That said, I'm not crazy about capability negotiation. Try something and send meaningful error messages if it doesn't work. Avoid race conditions and try to keep state machines cleaner. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT66 multihoming red herring, was: Re: Comment on draft-iab-ipv6-nat-00
On 2009-03-23 08:26, Iljitsch van Beijnum wrote: On 20 mrt 2009, at 14:40, Brian E Carpenter wrote: NAT does not offer ANY multihoming benefits whatsoever, in fact, NAT breaks multihoming because after a rehoming event, the addresses are translated differently. It's correct that NAT changeovers break existing sessions. But your blanket statement isn't true. NAT-based multihoming has the major benefit that the number of extra BGP4 routes caused by a multihomed site is exactly zero. No. What you're talking about is multiaddress multihoming. That's true too, but it isn't the same scenario. If it's NAT-based, the site can use a nice home-made ULA prefix and never has to think about it again. Multi-prefix based multihoming doesn't have that convenience factor for the site's IT manager. See draft-carpenter-renum-needs-work for some of the consequences. Then you add NAT to hide the changes to addresses from the hosts. But IPv6 hosts can work with multiple addresses anyway (well, there's the ingress filtering issue) so NAT is largely orthogonal to the multihoming. In fact, there's the exit router selection issue as a result of the ingress filtering issue. Certainly a site with many exits gets that problem in any case, but I suggest that it's less acute in the NAT model because in the end, any exit point will do. Also, shim6 gives you actual multihoming where sessions survive rather than the watered down thing where you only get to reestablish new sessions. Correct. That's why we're standardising shim6. The question isn't there; it's about what gets deployed. Also, NAT-based multihoming has value for large international corporate networks with dozens or hundreds of interconnection points to the public network. It basically solves their address management problem when dealing with multiple ISPs in multiple locations. That's running code today. People run whatever they can get away with. Doesn't mean it's a good idea. However, I do agree that it's useful to have stable internal addressing when external connectivity is subject to change. That is a legitimate advantage of NAT (66) which we haven't managed to make work without NAT. We could though, by making sure that ULAs are used for local connectivity regardless of the external connectivity. Yes. So how can we persuade IT managers to adopt that as standard practice? On 21 mrt 2009, at 16:07, Brian E Carpenter wrote: Suppose you're operating a large international network with (to take a random example) IPv4 1/8 as its PI prefix. You can't just advertise 1/8 in BGP4, because in fact it is split up into many longer prefixes for various kinds of use and various geographies. Then what is the point of having a single prefix? Mainly historical, or to say it another way, a large corporate network acquires its own routing swamp over many years. Suppose you sell a department of the company off to another company, for example, but the cost of renumbering is considered too high? (I am not making any of this up, although 1/8 is an example.) So how do you connect your internal users to the Internet? Same way as everyone else, return the /8. Not if you want to do traffic engineering, so that traffic for the Hong Kong office doesn't enter the Internet in New York. You have (I'm making this up) 100 different interconnects to the public Internet around the world, across a variety of ISPs. If you advertise longer prefixes out of 1/8 through those ISPs, life gets highly complex if you want multihoming. Certainly you won't be able to advertise *all* those prefixes through *all* those ISPs, so you'll need a complex worldwide management system just for your BGP4 advertisements, to decide which prefixes are advertised where, and what the desired backup paths are. It can be done, but the OPEX is high. Cost for the community is also high because a single organization puts a whole bunch of prefixes in the routing table. Yes So instead, you run NAT at every ISP connection. Ok, I said they didn't need the /8 before, but now you've completely lost me. What is the point of having that prefix now?? None, by now; it's become a private swamp. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Suggestion for draft-iab-ipv6-nat-00
Hi Dave and Lixia, I went through this document and it looks good. It provides a nice balanced viewpoint on the issues. One thing I would like to be added into the document is a cost-benefit analysis of doing ipv6 NAT for each of the problems in section 2. e.g. Avoid renumbering Benefit: Don't have to renumber since it is hard... Cost: Another box to manage, Application complexity, Traversal infrastructure, Power consumption... I am afraid that absent this analysis, we might be optimizing for the worst case scenario and end up with a permanent box on the path. Renumbering due to provider changes is a fairly rare phenomenon (for some definition of rare) and every operator needs to perform this analysis for themselves to see if NAT66 or some other solution would end up being the better solution for them. Thanks Suresh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Scott Brim wrote: Brian E Carpenter allegedly wrote on 03 19 2009 1:48 PM: I recently had this exchange with Dan Wing on the BEHAVE list: ... it seems to me that we might consider defining a generic 'referral object', containing more information than just an address, that could be passed among application entities. It could contain TLVs that would provide the semantics of the referred address as well as the raw address bits. Does this seem worth exploring? Yes, this could form the basis for very useful guidance to application designers. ICE does something like this already, but abstracting its functions up several levels, as you propose, would be useful. Referrals are hard to figure out. I think the tradeoffs are worth serious study. First party referrals like this are interesting but not so hard as third party referrals (Tom tells Dick how to reach Harry). They assume that Tom knows Dick's and Harry's shared scope. ...or that Dick can, given the information in the referral structure obtained from Tom, figure out an effective way to reach Harry given their shared scope. Can we assume we have some kind of globally unique identifiers that are globally unique? So far that has been extremely hard to pull off. Yes and no. We've managed to cope with the IPv4 address shortage in the short term and get away with not requiring every host to have a global address. But this is only because there is still a large set of globally unique addresses. I have a suspicion that for referrals you want to go all the way back to domain names and URIs. Ah, if only that would work well... it's a house of cards. But in any case we should do a major investigation of referrals in the light of location/identification separation and the fracturing of the Internet into various scopes. It might be a bit late for that. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Brian E Carpenter - le (m/j/a) 3/20/09 2:40 PM: NAT does not offer ANY multihoming benefits whatsoever, in fact, NAT breaks multihoming because after a rehoming event, the addresses are translated differently. It's correct that NAT changeovers break existing sessions. But your blanket statement isn't true. NAT-based multihoming has the major benefit that the number of extra BGP4 routes caused by a multihomed site is exactly zero. That feature may have low value today, but will have very high value if we collectively succeed in exceeding BGP4's scaling limits. Full agreement. And it's possible to do even better than NATs for multihoming in IPv6. (That's a feature of SAM.) Also, NAT-based multihoming has value for large international corporate networks with dozens or hundreds of interconnection points to the public network. It basically solves their address management problem when dealing with multiple ISPs in multiple locations. That's running code today. I don't understand the configuration of this case. Any reference to clarify it (or an explanation)? RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Comment on draft-iab-ipv6-nat-00 FYI
No business case for IPv6, survey finds But Internet Society members report rising customer demand, deployment plans http://www.networkworld.com/news/2009/032009-ipv6-business-case.html?nladnam e=032009dailynewspmalcode=nldailynewspm187866 Business incentives are completely lacking today for upgrading to IPv6, the next generation Internet protocol, according to a survey of network operators conducted by the Internet Society (ISOC). In a new report, ISOC says that ISPs, enterprises and network equipment vendors report that there are ``no concrete business drivers for IPv6.'' Developers and Identity Services : Tackling Identity Data with Identity Hub: Download now However, survey respondents said customer demand for IPv6 is on the rise and that they are planning or deploying IPv6 because they feel it is the next major development in the evolution of the Internet. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, March 19, 2009 4:48 PM To: Pete Resnick Cc: Christian Vogt; Lixia Zhang; Keith Moore; IETF Discussion Mailing List Subject: Re: Comment on draft-iab-ipv6-nat-00 I recently had this exchange with Dan Wing on the BEHAVE list: ... it seems to me that we might consider defining a generic 'referral object', containing more information than just an address, that could be passed among application entities. It could contain TLVs that would provide the semantics of the referred address as well as the raw address bits. Does this seem worth exploring? Yes, this could form the basis for very useful guidance to application designers. ICE does something like this already, but abstracting its functions up several levels, as you propose, would be useful. Something like: here is my IPv4 address, it goes through a translator so avoid using it if you can utilize my IPv6 address and so on. Brian On 2009-03-20 07:04, Pete Resnick wrote: On 3/19/09 at 8:17 AM -0400, Keith Moore wrote: Lixia Zhang wrote: I believe that people in general agree that applications should not use IP address for referrals. I don't know which people you're referring to there, but that's absolutely not the case for application developers. In the current internet, use of IP addresses for referrals is essential. That IP addresses are currently essential for referral is not mutually exclusive with the idea that applications should not use IP addresses for referrals. IP addresses fail for referrals in a vast number of cases including 1918 addresses, firewalled networks, certain asymmetric routing cases, etc. Given the current state of the network, you can neither recommend nor completely forbid the use of IP addresses for referrals in applications. (And nowhere in what Lixia said was the statement that applications MUST NOT use IP addresses for referrals.) And in fact every application that uses DNS does exactly that. I think that's a rather narrow view of where DNS falls in the architecture. It's all well and good to imagine a world where there would be a clear ID-LOC separation. But we've never created such a world, and we don't currently have an ID-LOC mapping layer that is good enough to use by all applications. Yup. In part, that's what LISP is about. But I actually think it's incorrect to talk about having an ID-LOC mapping layer good enough to use by all applications. If we're talking about the ideal world, applications should almost never need to use the mapping layer; they should be able to simply use the ID (without touching the LOC) and let the routing system deal with finding a LOC for the ID. That an application would have to actually deal with the mapping is an artifact of the current state of affairs where neither the LOC (IP address) or ID (DNS) is good enough to allow the application to do what it needs to do. DNS falls short in many ways. And as long as there is not a universal mapping layer that is aware of things like NATs and mobility, and for that matter as long as there are devices that impose arbitrary limitations on traffic flow (e.g. connections have to be initiated from inside), there will be a need for applications to deal explicitly with IP addresses. Sure it's ugly but it's the best that applications can do. I'm guessing we're in violent agreement, but NATs and mobility and traffic flow limiters actually make it impossible (viewing it from the other end) to use IP addresses: Giving a reference to myself using my own IP address when I am behind a NAT is useless; using a name, if one is available, is the only way to go. (And I still agree with your above paragraph.) pr ___ Ietf mailing
Re: Comment on draft-iab-ipv6-nat-00
On 2009-03-22 06:11, Rémi Després wrote: Brian E Carpenter - le (m/j/a) 3/20/09 2:40 PM: ... Also, NAT-based multihoming has value for large international corporate networks with dozens or hundreds of interconnection points to the public network. It basically solves their address management problem when dealing with multiple ISPs in multiple locations. That's running code today. I don't understand the configuration of this case. Any reference to clarify it (or an explanation)? Suppose you're operating a large international network with (to take a random example) IPv4 1/8 as its PI prefix. You can't just advertise 1/8 in BGP4, because in fact it is split up into many longer prefixes for various kinds of use and various geographies. So how do you connect your internal users to the Internet? (We're talking about desktop users, not about servers in a DMZ.) You have (I'm making this up) 100 different interconnects to the public Internet around the world, across a variety of ISPs. If you advertise longer prefixes out of 1/8 through those ISPs, life gets highly complex if you want multihoming. Certainly you won't be able to advertise *all* those prefixes through *all* those ISPs, so you'll need a complex worldwide management system just for your BGP4 advertisements, to decide which prefixes are advertised where, and what the desired backup paths are. It can be done, but the OPEX is high. So instead, you run NAT at every ISP connection. Your internal users get NATted to an ISP prefix at whichever exit point their traffic happens to reach, which automatically causes their return traffic to come through the same ISP. That exit point is locally chosen by the local routing setup. You don't need any worldwide coordination of the BGP4 advertisements, because there aren't any expect the ISP's normal ones. Also, traffic flows inside your network are localised, since traffic goes out and returns through a (reasonably) local gateway. When one of these NATs goes down, active connections will be lost, but IGP routing will switch users automatically to a different NAT when they retry. I'm sure there are people who can give a more accurate explanation than that. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Thanks, Brian, for the detailed explanation. IMHO, this case is _very_ interesting. It identifies one more NAT44 service that must be available in IPv6 with a defined solution for it. AFAIK, it was not identified in RFC4864, and I didn't have it either in draft-despres-sam-02. Regards, RD Brian E Carpenter - le (m/j/a) 3/21/09 4:07 PM: On 2009-03-22 06:11, Rémi Després wrote: Brian E Carpenter - le (m/j/a) 3/20/09 2:40 PM: ... Also, NAT-based multihoming has value for large international corporate networks with dozens or hundreds of interconnection points to the public network. It basically solves their address management problem when dealing with multiple ISPs in multiple locations. That's running code today. I don't understand the configuration of this case. Any reference to clarify it (or an explanation)? Suppose you're operating a large international network with (to take a random example) IPv4 1/8 as its PI prefix. You can't just advertise 1/8 in BGP4, because in fact it is split up into many longer prefixes for various kinds of use and various geographies. So how do you connect your internal users to the Internet? (We're talking about desktop users, not about servers in a DMZ.) You have (I'm making this up) 100 different interconnects to the public Internet around the world, across a variety of ISPs. If you advertise longer prefixes out of 1/8 through those ISPs, life gets highly complex if you want multihoming. Certainly you won't be able to advertise *all* those prefixes through *all* those ISPs, so you'll need a complex worldwide management system just for your BGP4 advertisements, to decide which prefixes are advertised where, and what the desired backup paths are. It can be done, but the OPEX is high. So instead, you run NAT at every ISP connection. Your internal users get NATted to an ISP prefix at whichever exit point their traffic happens to reach, which automatically causes their return traffic to come through the same ISP. That exit point is locally chosen by the local routing setup. You don't need any worldwide coordination of the BGP4 advertisements, because there aren't any expect the ISP's normal ones. Also, traffic flows inside your network are localised, since traffic goes out and returns through a (reasonably) local gateway. When one of these NATs goes down, active connections will be lost, but IGP routing will switch users automatically to a different NAT when they retry. I'm sure there are people who can give a more accurate explanation than that. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Brian E Carpenter wrote: Suppose you're operating a large international network with (to take a random example) IPv4 1/8 as its PI prefix. Are you assuming that an organization operating such a large network does not operate any externally accesible servers? I would rather assume that there are a lot of such servers distributed worldwide and the servers are, of course, multihomed. So, the servers have PI addresses. As there is no reason to assign extra address block that the PI addresses will be from 1/8. Considering that trafic to the servers should be localized, local PI address block with prefixes longer than 8 should be advertised to local ISPs, BGP4 advertisement of which must be coordinated worldwide. life gets highly complex if you want multihoming. That's life. I'm sure there are people who can give a more accurate explanation than that. That there are poeple who are doing unreasonable things does not rationalize their behaviour. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
On 21/03/2009, at 3:18 AM, Iljitsch van Beijnum wrote: On 19 mrt 2009, at 7:43, Lixia Zhan Are we ready to adopt the policy that forbids IPv6 NAT traversal mechanisms? no. This industry needs standards, and relies on standards. For many years the Internet Engineering Task Force has viewed standardization of NATs and their behaviour as being an action that would encourage further deployment of a technology that was apparently considered undesireable. The result has been that NATs have been deployed for reasons entirely unconnected with the IETF and standardization. However, because the original specification of NAT behaviour was at such a general level, each NAT implementor has been forced into making local decisions as to how the NAT should behave under specific circumstances. We now enjoy a network with widespread deployment of an active device that does not have consistent implementations and, in the worst cases, exhibits non-deterministic behaviours. This has made the task of deployment of certain applications on the Internet, including voice-based applications, incredibly difficult. Whether NATs are good or bad, they’d be less of a collective headache today if they shared a common standard core behaviour. NATs for IPv6 may be felt to be unnecessary today, and it can be argued they represent no real value to an IPv6 site. But a collection of IPv6 NAT implementations with no common core behaviour would be a far worse of problem for applications and their users. Standardization of technology at least eliminates some of the worst aspects of application-level guesswork out of technology deployment. regards Geoff ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
On 19 mrt 2009, at 7:43, Lixia Zhang wrote: The draft did not take any position on 1:1 NAT; it simply stresses the importance to strive for (re-installing) Internet's end-to-end reachability model, if/when one designs IPv6 NAT. Which I find strange. The ability to have 1:1 mappings, which are orders of magnitude less harmful than 1:N mappings that we get in IPv4, make a huge difference towards NAT in IPv6. I have no problem with the conclusion that IPv6 NAT shouldn't happen, but I'm not very happy with the draft in its current state. See below. Also, let everyone realize that IPv6 NAT shouldn't happen is a much stronger position than we don't standardize IPv6 NAT. Under the no IPv6 NAT regime, the IESG MUST make sure that no mechanisms are published by the IETF that allow for nothing else than IPv6 NAT traversal. Anything less than that is a de facto we won't stop IPv6 NAT but we just don't want to bother standardizing it. Are we ready to adopt the policy that forbids IPv6 NAT traversal mechanisms? The arguments for NAT are mostly bogus or fall within the polkadot realm: if the paint shop starts selling paint that's pink with fluorescent green polkadots, some person will paint their house with that paint, no matter how ugly the results will be. The renumbering and multihoming arguments are especially troublesome: the hard part in multihoming isn't giving a host interface a new address, but making sure that everything that points to that address, from the DNS to firewall rules, is updated. NAT does not offer ANY multihoming benefits whatsoever, in fact, NAT breaks multihoming because after a rehoming event, the addresses are translated differently. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Iljitsch, On 2009-03-21 05:18, Iljitsch van Beijnum wrote: ... NAT does not offer ANY multihoming benefits whatsoever, in fact, NAT breaks multihoming because after a rehoming event, the addresses are translated differently. It's correct that NAT changeovers break existing sessions. But your blanket statement isn't true. NAT-based multihoming has the major benefit that the number of extra BGP4 routes caused by a multihomed site is exactly zero. That feature may have low value today, but will have very high value if we collectively succeed in exceeding BGP4's scaling limits. Also, NAT-based multihoming has value for large international corporate networks with dozens or hundreds of interconnection points to the public network. It basically solves their address management problem when dealing with multiple ISPs in multiple locations. That's running code today. Sad but true. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
On Mar 18, 2009, at 6:06 PM, Robin Whittle wrote: End-to-end transparency (the packet received is identical to that sent, including its source and destination addresses, but not including hop limit etc.) is a major component of the Internet's flexible and open-ended nature. I'm actually of a slightly different opinion. I think it is important that one application instance be able to select another application instance, or a set of them, and send packets to all of those applications, one of them, or a specific one as it requires. That doesn't mean that the process knows anything about what is happening below the application layer; in fact, that would be about naming those application instances, and the fact that it can name and exchange sessions with sets of applications that it is authorized access to implies nothing further than that. I also think it is important that one transport endpoint be able to select another transport endpoint, or a set of them, and send packets to all of those transport endpoints, one of them, or a specific one as it requires. That doesn't mean that the transport endpoint knows anything about what is happening below the transport layer beyond a string of bits that it uses to identify the far end; in fact, that would be about addressing those transport endpoints, and the fact that it can address and exchange datagrams with sets of transport endpoints that it is authorized access to implies nothing further than that. The fact that a system, and by extension the applications and transports on it, can identify other systems by name or address is the critical bit, not that every system in the network uses the same name or address. If that were not true, multi-named systems and multihomed systems would be a problem, as would multicast and anycast. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
On Mar 20, 2009, at 9:18 AM, Iljitsch van Beijnum wrote: Are we ready to adopt the policy that forbids IPv6 NAT traversal mechanisms? Preemptive to the BOF on the topic? You might recall the IAB making a preemptive decision in 1992, just prior to the Cambridge meeting. CLNS was going to be the next generation IP as I recall. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Christian, I want to say thank you for the comments! In fact I wondered whether people noticed this draft as there had been no comment till this msg showed up. On Mar 18, 2009, at 9:44 AM, Christian Vogt wrote: Lixia, David, and all - I think it is very useful that IAB is taking position on the issue of NAT in IPv6. And it is great that you, Lixia and David, have documented this position. Below I have one comment on the document. I admit that the comment is a bit hypothetical, but I do believe it is worthwhile to be considered in the discussion around IPv6 NAT. On page 9, you state, based on a citation from RFC 4924: We believe that providing end-to-end transparency [...] is key to the success of the Internet. I think this statement needs elaboration. Let me first quote the RFC4924 text here so people can see the context of this discussion: As [RFC4924] states: A network that does not filter or transform the data that it carries may be said to be transparent or oblivious to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success. To me this essentially stated that network, please let users data go end-to-end and stay intact End-to-end transparency is not a reason for the success of the Internet. Instead, it is a requirement that follows from the overloading of identification and location semantics onto IP addresses: It is exactly those applications that pursue this overloading, in form of address referrals, which have difficulties with the lack of end-to-end transparency. I believe that people in general agree that applications should not use IP address for referrals. As RFC1958 Architectural Principles of the Internet (June 1996) stated: 4.1 Avoid any design that requires addresses to be hard coded or stored on non-volatile storage (except of course where this is an essential requirement as in a name server or configuration server). In general, user applications should use names rather than addresses. Maybe it's too late so my brain got foggy, however between these two issues, (1) keeping user packets intact as they transit through the network, and (2) applications using address for referral I do not see that (2) is a consequence of (1), as you seem to believe. Since the comments below seem trying to justify for IPv6 NAT, I would also like to point out the following text in draft-iab-ipv6-nat-00: If we accept the view that some, but not all, parties want IPv6 NAT, then the real debate should not be on what benefits IPv6 NAT may bring. As every coin has two sides, it is undeniable that network address translation can bring certain benefits to its users. However the real challenge we should address is how to design IPv6 NAT in such a way that it can hide its impact within some localized scope. If IPv6 NAT design can achieve this goal, then the Internet as a whole can strive for (re-installing) the end-to-end reachability model. The draft did not take any position on 1:1 NAT; it simply stresses the importance to strive for (re-installing) Internet's end-to-end reachability model, if/when one designs IPv6 NAT. And I believe you too agree with this. Lixia (no hat on) Of course, this is not to mean that NAT, as used in IPv4 today, would be a harmless technology if we had a clean identifier-locator separation. But this is because IPv4 NAT does more potentially harmful things apart from removing end-to-end transparency. The reason for the harmfulness of IPv4 NAT is not the address rewriting by itself; it is that IPv4 NATs multiplex multiple internal addresses onto a single external address. This address overloading is causing problems that wouldn't go away even if we had a clean identifier-locator separation -- problems in terms of reduced host reachability, reduced network robustness, and a limitation to connection types with en-route-modifiable port numbers. The reason why address overloading causes these problems is that it (a) makes addresses ambiguous and, for the purpose of disambiguation, (b) adds per-connection state to the network. Now, assuming we had a large enough number of addresses for a one-to- one mapping between the internal and external addresses of a NAT, the NAT could do simple address rewriting without address overloading, hence avoiding aforementioned problems. If we further assume that we had a clean identifier-locator separation, then why would it matter that simple address rewriting causes a loss of end-to-end transparency? Why would it matter if a locator changes en route for a packet if both the old and the new locator map unambiguously to the same identifier? I
Re: Comment on draft-iab-ipv6-nat-00
Lixia Zhang wrote: I believe that people in general agree that applications should not use IP address for referrals. I don't know which people you're referring to there, but that's absolutely not the case for application developers. In the current internet, use of IP addresses for referrals is essential. And in fact every application that uses DNS does exactly that. It's all well and good to imagine a world where there would be a clear ID-LOC separation. But we've never created such a world, and we don't currently have an ID-LOC mapping layer that is good enough to use by all applications. DNS falls short in many ways. And as long as there is not a universal mapping layer that is aware of things like NATs and mobility, and for that matter as long as there are devices that impose arbitrary limitations on traffic flow (e.g. connections have to be initiated from inside), there will be a need for applications to deal explicitly with IP addresses. Sure it's ugly but it's the best that applications can do. As RFC1958 Architectural Principles of the Internet (June 1996) stated: 4.1 Avoid any design that requires addresses to be hard coded or stored on non-volatile storage (except of course where this is an essential requirement as in a name server or configuration server). In general, user applications should use names rather than addresses. Yes, that's in there. The last sentence was a stretch even in 1996, and it's simply incorrect as applied to the current Internet. (Note that NATs were not so widely deployed in 1996 as they are now.) Saying that applications should use names rather than addresses, especially in the context of a NATted Internet, is tantamount to saying (a) that we have perfect faith in DNS to reliably map names to addresses at all times, in all realms, and that DNS RRs will never leak across realm boundaries, and (b) that we have perfect faith that any address pair chosen by the host stack for communication will continue to function for the entire lifetime of the association. Both of those assumptions would clearly be naive today. Maybe it's too late so my brain got foggy, however between these two issues, (1) keeping user packets intact as they transit through the network, and (2) applications using address for referral I do not see that (2) is a consequence of (1), as you seem to believe. Part of what we mean by transparency is that applications should not have to care about how the network routes packets or the way it is connected. In the original Internet there was a clear separation of function - the applications generated messages to send to each other than the network made a best effort to route those messages to their intended destinations. That's no longer true today. And as long as there are NATs in the network (or for that matter other devices that violate the best effort model), some applications will be forced to care about such things. Part of the way they learn about such things today is by looking at endpoint addresses, and part of the way they deal with such things today is by using addresses for referral. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
On 3/19/09 at 8:17 AM -0400, Keith Moore wrote: Lixia Zhang wrote: I believe that people in general agree that applications should not use IP address for referrals. I don't know which people you're referring to there, but that's absolutely not the case for application developers. In the current internet, use of IP addresses for referrals is essential. That IP addresses are currently essential for referral is not mutually exclusive with the idea that applications should not use IP addresses for referrals. IP addresses fail for referrals in a vast number of cases including 1918 addresses, firewalled networks, certain asymmetric routing cases, etc. Given the current state of the network, you can neither recommend nor completely forbid the use of IP addresses for referrals in applications. (And nowhere in what Lixia said was the statement that applications MUST NOT use IP addresses for referrals.) And in fact every application that uses DNS does exactly that. I think that's a rather narrow view of where DNS falls in the architecture. It's all well and good to imagine a world where there would be a clear ID-LOC separation. But we've never created such a world, and we don't currently have an ID-LOC mapping layer that is good enough to use by all applications. Yup. In part, that's what LISP is about. But I actually think it's incorrect to talk about having an ID-LOC mapping layer good enough to use by all applications. If we're talking about the ideal world, applications should almost never need to use the mapping layer; they should be able to simply use the ID (without touching the LOC) and let the routing system deal with finding a LOC for the ID. That an application would have to actually deal with the mapping is an artifact of the current state of affairs where neither the LOC (IP address) or ID (DNS) is good enough to allow the application to do what it needs to do. DNS falls short in many ways. And as long as there is not a universal mapping layer that is aware of things like NATs and mobility, and for that matter as long as there are devices that impose arbitrary limitations on traffic flow (e.g. connections have to be initiated from inside), there will be a need for applications to deal explicitly with IP addresses. Sure it's ugly but it's the best that applications can do. I'm guessing we're in violent agreement, but NATs and mobility and traffic flow limiters actually make it impossible (viewing it from the other end) to use IP addresses: Giving a reference to myself using my own IP address when I am behind a NAT is useless; using a name, if one is available, is the only way to go. (And I still agree with your above paragraph.) pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Pete Resnick wrote: On 3/19/09 at 8:17 AM -0400, Keith Moore wrote: Lixia Zhang wrote: I believe that people in general agree that applications should not use IP address for referrals. I don't know which people you're referring to there, but that's absolutely not the case for application developers. In the current internet, use of IP addresses for referrals is essential. That IP addresses are currently essential for referral is not mutually exclusive with the idea that applications should not use IP addresses for referrals. Let me put it a different way: Many of us look forward to a day when some other token, identifier, structure than an IP address will suffice for referrals from and to anywhere in the network, and this will work so universally and reliably that there will be no need whatsoever to use IP addresses in referrals. However that's an incredibly difficult problem to solve, especially as long as the network contains a large number of NATs in arbitrary locations. At the rate we are going now, I'll be very surprised to see that problem solved before I die. And in fact every application that uses DNS does exactly that. I think that's a rather narrow view of where DNS falls in the architecture. A and records are address referrals. It's all well and good to imagine a world where there would be a clear ID-LOC separation. But we've never created such a world, and we don't currently have an ID-LOC mapping layer that is good enough to use by all applications. Yup. In part, that's what LISP is about. Except that LISP doesn't actually define the mechanism to do the mapping (i.e. maintain the bindings and allow them to be queried), and that's the hard part of the problem. At least, it's the hard part of the problem if you believe that ID-LOC separation can solve the problem of referrals in the presence of NATs (and maybe some of the other problems caused by NATs). If you're just trying to solve the routing scalability problem the mapping is somewhat easier to accomplish, but then you need yet another mapping layer to deal with NATs...back to square one. But I actually think it's incorrect to talk about having an ID-LOC mapping layer good enough to use by all applications. If we're talking about the ideal world, applications should almost never need to use the mapping layer; they should be able to simply use the ID (without touching the LOC) and let the routing system deal with finding a LOC for the ID. That an application would have to actually deal with the mapping is an artifact of the current state of affairs where neither the LOC (IP address) or ID (DNS) is good enough to allow the application to do what it needs to do. Oh it's perfectly fine with me if the mapping isn't dealt with explicitly by applications - provided of course, that it works so well that applications never have a need to deal with it explicitly. There's the rub. DNS falls short in many ways. And as long as there is not a universal mapping layer that is aware of things like NATs and mobility, and for that matter as long as there are devices that impose arbitrary limitations on traffic flow (e.g. connections have to be initiated from inside), there will be a need for applications to deal explicitly with IP addresses. Sure it's ugly but it's the best that applications can do. I'm guessing we're in violent agreement, but NATs and mobility and traffic flow limiters actually make it impossible (viewing it from the other end) to use IP addresses: Giving a reference to myself using my own IP address when I am behind a NAT is useless; using a name, if one is available, is the only way to go. Actually, the internal IP address is not useless at all, as (a) it's still often the best identifer for use with other hosts in the same realm and (b) it is useful to compare with the external IP address (as obtained by STUN or UPnP or by talking to a peer) to determine if one is behind a NAT. Nor is the DNS name the only way to go as a DNS query by a peer might or might not yield a useful result, and two-faced DNS doesn't work very well, and there are the usual reliability problems with DNS (especially when making queries through NATs that have buggy DNS proxies). Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
I recently had this exchange with Dan Wing on the BEHAVE list: ... it seems to me that we might consider defining a generic 'referral object', containing more information than just an address, that could be passed among application entities. It could contain TLVs that would provide the semantics of the referred address as well as the raw address bits. Does this seem worth exploring? Yes, this could form the basis for very useful guidance to application designers. ICE does something like this already, but abstracting its functions up several levels, as you propose, would be useful. Something like: here is my IPv4 address, it goes through a translator so avoid using it if you can utilize my IPv6 address and so on. Brian On 2009-03-20 07:04, Pete Resnick wrote: On 3/19/09 at 8:17 AM -0400, Keith Moore wrote: Lixia Zhang wrote: I believe that people in general agree that applications should not use IP address for referrals. I don't know which people you're referring to there, but that's absolutely not the case for application developers. In the current internet, use of IP addresses for referrals is essential. That IP addresses are currently essential for referral is not mutually exclusive with the idea that applications should not use IP addresses for referrals. IP addresses fail for referrals in a vast number of cases including 1918 addresses, firewalled networks, certain asymmetric routing cases, etc. Given the current state of the network, you can neither recommend nor completely forbid the use of IP addresses for referrals in applications. (And nowhere in what Lixia said was the statement that applications MUST NOT use IP addresses for referrals.) And in fact every application that uses DNS does exactly that. I think that's a rather narrow view of where DNS falls in the architecture. It's all well and good to imagine a world where there would be a clear ID-LOC separation. But we've never created such a world, and we don't currently have an ID-LOC mapping layer that is good enough to use by all applications. Yup. In part, that's what LISP is about. But I actually think it's incorrect to talk about having an ID-LOC mapping layer good enough to use by all applications. If we're talking about the ideal world, applications should almost never need to use the mapping layer; they should be able to simply use the ID (without touching the LOC) and let the routing system deal with finding a LOC for the ID. That an application would have to actually deal with the mapping is an artifact of the current state of affairs where neither the LOC (IP address) or ID (DNS) is good enough to allow the application to do what it needs to do. DNS falls short in many ways. And as long as there is not a universal mapping layer that is aware of things like NATs and mobility, and for that matter as long as there are devices that impose arbitrary limitations on traffic flow (e.g. connections have to be initiated from inside), there will be a need for applications to deal explicitly with IP addresses. Sure it's ugly but it's the best that applications can do. I'm guessing we're in violent agreement, but NATs and mobility and traffic flow limiters actually make it impossible (viewing it from the other end) to use IP addresses: Giving a reference to myself using my own IP address when I am behind a NAT is useless; using a name, if one is available, is the only way to go. (And I still agree with your above paragraph.) pr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Lixia - Maybe it's too late so my brain got foggy, however between these two issues, (1) keeping user packets intact as they transit through the network, and (2) applications using address for referral I do not see that (2) is a consequence of (1), as you seem to believe. I was actually making a different statement. I was saying that end-to-end (locator/address) transparency is important in the existing Internet because IP addresses are overloaded as identifiers by some applications. If there wasn't this kind of overloading, then the lack of end-to-end (locator/address) transparency would be less of an issue. Another clarification: I am surprised that you say I would justify IPv6 NAT. As I said in my posts, NAT does introduce issues simply because the existing overloading of IP addresses as locators and identifiers works best if IP addresses are carried unchanged by the network. Whether these issues are worth the benefits of NATs is something that requires a separate discussion. Makes sense? - Christian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
I will get back to your original comments in the next msg, but I feel the need to first correct potentially a very big error in the above: would you please kindly point to the exact text in draft-iab-ipv6- nat-00 that either stated or implied end-to-end *locator* transparency, as you attributed to the draft? Hi Lixia - I used the term locator transparency to distinguish this from other types of transparency, such as data transparency or, in a world with identifier-locator separation, identifier transparency. I found this useful given that I was talking about identifier-locator separation. Consequently, locator transparency in my posts has the meaning of IP address transparency, i.e., the type of transparency that NATs break. Since your document is about NAT, I am assuming that this is also the type of transparency that you are referring to in your document. - Christian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Comment on draft-iab-ipv6-nat-00
Lixia, David, and all - I think it is very useful that IAB is taking position on the issue of NAT in IPv6. And it is great that you, Lixia and David, have documented this position. Below I have one comment on the document. I admit that the comment is a bit hypothetical, but I do believe it is worthwhile to be considered in the discussion around IPv6 NAT. On page 9, you state, based on a citation from RFC 4924: We believe that providing end-to-end transparency [...] is key to the success of the Internet. I think this statement needs elaboration. End-to-end transparency is not a reason for the success of the Internet. Instead, it is a requirement that follows from the overloading of identification and location semantics onto IP addresses: It is exactly those applications that pursue this overloading, in form of address referrals, which have difficulties with the lack of end-to-end transparency. Of course, this is not to mean that NAT, as used in IPv4 today, would be a harmless technology if we had a clean identifier-locator separation. But this is because IPv4 NAT does more potentially harmful things apart from removing end-to-end transparency. The reason for the harmfulness of IPv4 NAT is not the address rewriting by itself; it is that IPv4 NATs multiplex multiple internal addresses onto a single external address. This address overloading is causing problems that wouldn't go away even if we had a clean identifier-locator separation -- problems in terms of reduced host reachability, reduced network robustness, and a limitation to connection types with en-route-modifiable port numbers. The reason why address overloading causes these problems is that it (a) makes addresses ambiguous and, for the purpose of disambiguation, (b) adds per-connection state to the network. Now, assuming we had a large enough number of addresses for a one-to-one mapping between the internal and external addresses of a NAT, the NAT could do simple address rewriting without address overloading, hence avoiding aforementioned problems. If we further assume that we had a clean identifier-locator separation, then why would it matter that simple address rewriting causes a loss of end-to-end transparency? Why would it matter if a locator changes en route for a packet if both the old and the new locator map unambiguously to the same identifier? I don't think it would matter -- again, provided we had enough addresses and an identifier-locator separation. Luckily, in IPv6 we have the former; unfortunately, though, neither in IPv4 nor in IPv6 we have the latter. - Christian PS: FWIW, draft-vogt-address-translation-harmfulness [1] is related to your document. It is a harmfulness analysis of possible NAT designs, which looks at potential problems of the NAT designs, and evaluates the cost and completeness of solutions to those problems. This includes an evaluation of impacts that NAT deployment may have on the rest of the Internet -- a question which, as you say, has so far not been sufficiently attended to. [1] http://users.piuha.net/chvogt/pub/2009/draft-vogt-address-translation-harmfulness-02.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Excerpts from Christian Vogt on Wed, Mar 18, 2009 09:44:20AM -0700: On page 9, you state, based on a citation from RFC 4924: We believe that providing end-to-end transparency [...] is key to the success of the Internet. I think this statement needs elaboration. End-to-end transparency is not a reason for the success of the Internet. I invoke Feynman and the philosophy of ignorance. The reason you want e2e transparency is because you do not know what it might enable, and we want that. We _want_ to have uncertainty about what the future of the Internet is. We do not know what advantages or restrictions our decisions will bring in the future. The richness of the Internet experience has come about because we have given end users the capability to develop new ways of using it, and somehow managed to have got out of the way, so far. Feynman said (among other things -- search for it): Our responsibility is to do what we can, learn what we can, improve the solutions, and pass them on. It is our responsibility to leave the people of the future a free hand. In the impetuous youth of humanity, we can make grave errors that will stunt our growth for a long time. This we will do if we say we have the answers now, so young and ignorant as we are. If we suppress all discussion, all criticism, proclaiming “This is the answer, my friends; man is saved!” we will doom humanity for a long time to the chains of authority, confined to the limits of our present imagination. It has been done so many times before. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
Scott - Feynman is absolutely right, and certainly a network should enable future, unknown applications. But your conclusion that end-to-end locator transparency is a requirement to build such a network does not convince me. This said, there is no question that end-to-end locator transparency is a critical property in the Internet we have. (And this was, after all, was the point that Lixia and Dave were making.) My point was that end-to-end locator transparency is not the /reason/ for the Internet's success, because you could build networks that function perfectly fine without it. E.g., a network with identifier-locator separation. - Christian On Mar 18, 2009, Scott Brim wrote: I invoke Feynman and the philosophy of ignorance. The reason you want e2e transparency is because you do not know what it might enable, and we want that. We _want_ to have uncertainty about what the future of the Internet is. We do not know what advantages or restrictions our decisions will bring in the future. The richness of the Internet experience has come about because we have given end users the capability to develop new ways of using it, and somehow managed to have got out of the way, so far. Feynman said (among other things -- search for it): Our responsibility is to do what we can, learn what we can, improve the solutions, and pass them on. It is our responsibility to leave the people of the future a free hand. In the impetuous youth of humanity, we can make grave errors that will stunt our growth for a long time. This we will do if we say we have the answers now, so young and ignorant as we are. If we suppress all discussion, all criticism, proclaiming “This is the answer, my friends; man is saved!” we will doom humanity for a long time to the chains of authority, confined to the limits of our present imagination. It has been done so many times before. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
I support Scott Brim's position, I understanding as: End-to-end transparency (the packet received is identical to that sent, including its source and destination addresses, but not including hop limit etc.) is a major component of the Internet's flexible and open-ended nature. We would need extraordinarily strong arguments to eliminate this from IPv6 - or to remove other such basis which may facilitate the development of applications we cannot yet imagine. Christian Vogt wrote: Feynman is absolutely right, and certainly a network should enable future, unknown applications. But your conclusion that end-to-end locator transparency is a requirement to build such a network does not convince me. I am not sure what end-to-end locator transparency means. End-to-end transparency is defined here: http://tools.ietf.org/html/rfc4924#section-1 in terms of data in the packet, but my definition involves the source and destination addresses, since these are typically important for how each host interprets the packet. I fully support: http://tools.ietf.org/html/draft-iab-ipv6-nat-00#section-4.1 We believe that providing end-to-end transparency, as defined above, is key to the success of the Internet. While some fields of traffic (e.g., Hop Limit) are defined to be mutable, transparency requires that fields not defined as such arrive un-transformed. Currently, the source and destination addresses are defined as immutable fields, and are used as such by many protocols and applications. My definition of end-to-end transparency is not affected by some function between the hosts which tunnels the packet to some intermediate device at locator address as part of efficiently forwarding it to the destination host. Any system such as NAT which changes the source or destination addresses of packets between hosts adds complexity and restrictions to what would otherwise be a clean, open, network. This was forced upon us with IPv4. If such changes to packets as seen by hosts is proposed as part of a scalable routing solution for IPv6, I think there would need to be robust arguments why any other scalable routing approach which preserved end-to-end transparency was impractical or for some very strong reason undesirable. The Richard Feynman quote is from What Do You Care What Other People Think?: Further Adventures of a Curious Character (1988). http://en.wikiquote.org/wiki/Richard_Feynman - Robin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
On Mar 18, 2009, Keith Moore wrote: This said, there is no question that end-to-end locator transparency is a critical property in the Internet we have. (And this was, after all, was the point that Lixia and Dave were making.) My point was that end-to-end locator transparency is not the /reason/ for the Internet's success, because you could build networks that function perfectly fine without it. E.g., a network with identifier-locator separation. That's an interesting theory. I've yet to be convinced it's more than wishful thinking. [...] Me too. ;-) Oh, and the question whether and when to introduce identifier-locator separation is an orthogonal one. We are talking about it, e.g., in RRG. Here, I was just making an observation. - Christian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comment on draft-iab-ipv6-nat-00
On Mar 18, 2009, at 5:07 PM, Christian Vogt wrote: Scott - Feynman is absolutely right, and certainly a network should enable future, unknown applications. But your conclusion that end-to-end locator transparency is a requirement to build such a network does not convince me. This said, there is no question that end-to-end locator transparency is a critical property in the Internet we have. (And this was, after all, was the point that Lixia and Dave were making.) Hi Christian, I will get back to your original comments in the next msg, but I feel the need to first correct potentially a very big error in the above: would you please kindly point to the exact text in draft-iab-ipv6- nat-00 that either stated or implied end-to-end *locator* transparency, as you attributed to the draft? I do not recall the draft mentioned the word locator at all. Lixia My point was that end-to-end locator transparency is not the /reason/ for the Internet's success, because you could build networks that function perfectly fine without it. E.g., a network with identifier-locator separation. - Christian On Mar 18, 2009, Scott Brim wrote: I invoke Feynman and the philosophy of ignorance. The reason you want e2e transparency is because you do not know what it might enable, and we want that. We _want_ to have uncertainty about what the future of the Internet is. We do not know what advantages or restrictions our decisions will bring in the future. The richness of the Internet experience has come about because we have given end users the capability to develop new ways of using it, and somehow managed to have got out of the way, so far. Feynman said (among other things -- search for it): Our responsibility is to do what we can, learn what we can, improve the solutions, and pass them on. It is our responsibility to leave the people of the future a free hand. In the impetuous youth of humanity, we can make grave errors that will stunt our growth for a long time. This we will do if we say we have the answers now, so young and ignorant as we are. If we suppress all discussion, all criticism, proclaiming “This is the answer, my friends; man is saved!” we will doom humanity for a long time to the chains of authority, confined to the limits of our present imagination. It has been done so many times before. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Harald Alvestrand wrote: Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( [EMAIL PROTECTED] (MY, what an useful reverse map!) Like a lot of things, it depends. For SMTP/SSH and for management-alike protocols requiring proper reverse - forward - reverse mapping is IMHO a good thing. Clients servers using these protocols should be on stable trackable addresses. (of course you an set a low TTL etc, that is why one should always log the name + IP, the more information the better). With management I mean for instance reverses on router IP addresses, as it makes traceroute so much more informative, also reverses on servers etc. For SSH you will most likely have firewall rules in place anyway. SMTP should similarly only be allowed to clients that are in your client list. One doesn't have to require r-f-r if the client is in your client-list of course. Your server, which talks to other SMTP servers outside of your control, should be on a stable IP and have functioning r-f-r. For SMTP the current track of mind is: no reverse, no communication. Which stops most of the spam already, as that client is clearly not configured correctly to do inter-domain SMTP. For that matter anything that is 'stable' should (note should) IMHO have a proper r-f-r. For any other protocol _requiring_ reverse is silly IMHO. You don't need it for HTTP, you don't need it for BitTorrent etc. Having reverse in those cases is nice, as it might give extra information (eg the remote is most likely dsl as it contains 'dsl' in the reverse), but it is always a guess and might quite well be faked. The biggest issue with the use of reverses tends to be with applications which only lookup a reverse, but don't check if the r-f-r link is complete. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Jeroen Massar wrote: Harald Alvestrand wrote: Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( [EMAIL PROTECTED] (MY, what an useful reverse map!) Like a lot of things, it depends. For SMTP/SSH and for management-alike protocols requiring proper reverse - forward - reverse mapping is IMHO a good thing. Clients servers using these protocols should be on stable trackable addresses. (of course you an set a low TTL etc, that is why one should always log the name + IP, the more information the better). With management I mean for instance reverses on router IP addresses, as it makes traceroute so much more informative, also reverses on servers etc. For SSH you will most likely have firewall rules in place anyway. SMTP should similarly only be allowed to clients that are in your client list. One doesn't have to require r-f-r if the client is in your client-list of course. Your server, which talks to other SMTP servers outside of your control, should be on a stable IP and have functioning r-f-r. For SMTP the current track of mind is: no reverse, no communication. Which stops most of the spam already, as that client is clearly not configured correctly to do inter-domain SMTP. For that matter anything that is 'stable' should (note should) IMHO have a proper r-f-r. For any other protocol _requiring_ reverse is silly IMHO. You don't need it for HTTP, you don't need it for BitTorrent etc. Having reverse in those cases is nice, as it might give extra information (eg the remote is most likely dsl as it contains 'dsl' in the reverse), but it is always a guess and might quite well be faked. The biggest issue with the use of reverses tends to be with applications which only lookup a reverse, but don't check if the r-f-r link is complete. The biggest issue with reverse mapping for clients (any protocol) is that people try to make their applications treat it as anything but here is some information you might find interesting. I think draft-ietf-dnsop-reverse-mapping-considerations-05.txt has it right: 4.3 Application considerations Applications should not rely on reverse mapping for proper operation, although functions that depend on reverse mapping will obviously not work in its absence. Operators and users are reminded that the use of the reverse tree, sometimes in conjunction with a lookup of the name resulting from the PTR record, provides no real security, can lead to erroneous results and generally just increases load on DNS servers. FYI, I ssh out from the address I used as an example above every day. Thinking that SSH clients should be required to be on round-trippable mapped addresses is just silly. Harald ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
On 21 feb 2008, at 14:31, Rémi Després wrote: - These addresses would, for example, have FF00::/8 at the beginning of their IID (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough). You're right, there is currently no way other than a rather non- obvious use of manual address configuration or DHCPv6 address pool configuration to arrive at an interface identifier where the U/L bit is global and the group bit is set, i.e., with bits 6 and 7 of the IID set to 1. This means that there is an untapped range of 62 bits worth of IIDs that we can still give a new purpose where the address type can be relatively unambiguously determined from the IID. It would be a shame to squander that resource without thinking about other uses first. (Although using only one of the 64 possible ranges of 56 bits is probably reasonalbe.) But shouldn't we be having this discussion in 6man? ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Rémi Després wrote: Harald Alvestrand a écrit : Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( One approach to achieve it could be ias follows: - An IPv6 link where some privacy source addresses may be used would have in the DNS a record for a generic privacy address. - This address would be the /64 of the link followed by an agreed joker IID (0:0:0:0 or some other to be agreed on, e.g. :0:0:0). - Resolvers, if they recognize a privacy remote address, would query the reverse DNS with this generic privacy address of the remote link. - They could also do this type of queries after failures of full address queries. Problem: Privacy addresses, as specified today, cannot be distinguished with 100% certainety from addresses obtained with stateful DHCPv6. A proposal would be an addition to the privacy extension spec (rfc 4941). - A variant of privacy addresses would be defined for dsitinguishable privacy addresses. - These addresses would, for example, have FF00::/8 at the beginning of their IID (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough). - Then resolvers could recognize such privacy addresses for sure, and could query the reverse DNS with the generic privacy address only when this is appropriate. IMHO, this is a feasible step to reconcile: (1) privacy requirements of individuals; (2) desire to know which site is at the other end where and when such a desire exists. My desire to have privacy is, in itself, something I may want to keep private. If what you want to know is indeed which site is at the other end, wildcards at the /64 level will achieve that with no changes to existing code. Harald ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
This is a retransmission with a source address accepted on this discussion list. Apologies to those who received it already. If you respond, please use preferably this copy. RD Harald Alvestrand wrote: Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a "mechanism" is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( One approach to achieve it could be ias follows: - An IPv6 link where some privacy source addresses may be used would have in the DNS a record for a "generic privacy address". - This address would be the /64 of the link followed by an agreed "joker IID" (0:0:0:0 or some other to be agreed on, e.g. :0:0:0). - Resolvers, if they recognize a privacy remote address, would query the reverse DNS with this "generic privacy address" of the remote link. - They could also do this type of queries after failures of full address queries. Problem: Privacy addresses, as specified today, cannot be distinguished with 100% certainety from addresses obtained with stateful DHCPv6. A proposal would be an addition to the privacy extension spec (rfc 4941). - A variant of privacy addresses would be defined for "dsitinguishable privacy addresses". - These addresses would, for example, have FF00::/8 at the beginning of their IID (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough). - Then resolvers could recognize such privacy addresses for sure, and could query the reverse DNS with the generic privacy address only when this is appropriate. IMHO, this is a feasible step to reconcile: (1) privacy requirements of individuals; (2) desire to know which site is at the other end where and when such a desire exists. RD ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Harald Alvestrand a écrit : Rémi Després wrote: Harald Alvestrand a écrit : Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( One approach to achieve it could be ias follows: - An IPv6 link where some privacy source addresses may be used would have in the DNS a record for a generic privacy address. - This address would be the /64 of the link followed by an agreed joker IID (0:0:0:0 or some other to be agreed on, e.g. :0:0:0). - Resolvers, if they recognize a privacy remote address, would query the reverse DNS with this generic privacy address of the remote link. - They could also do this type of queries after failures of full address queries. Problem: Privacy addresses, as specified today, cannot be distinguished with 100% certainety from addresses obtained with stateful DHCPv6. A proposal would be an addition to the privacy extension spec (rfc 4941). - A variant of privacy addresses would be defined for dsitinguishable privacy addresses. - These addresses would, for example, have FF00::/8 at the beginning of their IID (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough). - Then resolvers could recognize such privacy addresses for sure, and could query the reverse DNS with the generic privacy address only when this is appropriate. IMHO, this is a feasible step to reconcile: (1) privacy requirements of individuals; (2) desire to know which site is at the other end where and when such a desire exists. My desire to have privacy is, in itself, something I may want to keep private. I am not sure I see the practical consequences. If my source address says I am someone but you will not know who I am, isn't this sufficient? If what you want to know is indeed which site is at the other end, wildcards at the /64 level will achieve that with no changes to existing code. I am not familiar enough with wildcard operation in the DNS. If it provides for queries that concern only site prefixes, then you are right: no need for an agreed wildcard IID. The result is the same with existing mechanisms, which is clearly better. RD ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Iljitsch van Beijnum a écrit : On 21 feb 2008, at 14:31, Rémi Després wrote: - These addresses would, for example, have FF00::/8 at the beginning of their IID (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough). (Sorry for the typo. Should be 56.) You're right, there is currently no way other than a rather non-obvious use of manual address configuration or DHCPv6 address pool configuration to arrive at an interface identifier where the U/L bit is global and the group bit is set, i.e., with bits 6 and 7 of the IID set to 1. This means that there is an untapped range of 62 bits worth of IIDs that we can still give a new purpose where the address type can be relatively unambiguously determined from the IID. It would be a shame to squander that resource without thinking about other uses first. (Although using only one of the 64 possible ranges of 56 bits is probably reasonalbe.) But shouldn't we be having this discussion in 6man? Yes, I think so. ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Rémi Després wrote: My desire to have privacy is, in itself, something I may want to keep private. I am not sure I see the practical consequences. If my source address says I am someone but you will not know who I am, isn't this sufficient? You're not thinking this through. Think of the case where there are 1000 users on a LAN, and one of them desires to use the address privacy option for all the normal reasons. Then think about the policeman / bad guy / secret agent / mafioso with a trace of all traffic from that LAN - he can immediately say that the 999 were using non-privacy-enhanced addresses, and the resulting trace will show him immediately what the 1000th was up to, no matter how many times he changed his address. If what you want to know is indeed which site is at the other end, wildcards at the /64 level will achieve that with no changes to existing code. I am not familiar enough with wildcard operation in the DNS. If it provides for queries that concern only site prefixes, then you are right: no need for an agreed wildcard IID. The result is the same with existing mechanisms, which is clearly better. Read RFC 1034 - or perhaps better, RFC 4592. They've been around for a while (although their behaviour still surprises many). Harald ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
On 21 feb 2008, at 16:34, Harald Alvestrand wrote: Think of the case where there are 1000 users on a LAN, and one of them desires to use the address privacy option for all the normal reasons. Then think about the policeman / bad guy / secret agent / mafioso with a trace of all traffic from that LAN - he can immediately say that the 999 were using non-privacy-enhanced addresses, and the resulting trace will show him immediately what the 1000th was up to, no matter how many times he changed his address. I'm assuming you mean a trace of the activities of addresses from that LAN as seen from elsewhere, because if they can sniff the LAN they can also see the link addresses. But what the good/bad guy sees is 1099 addresses, 999 of which are used for somewhat long periods, and 100 of which are used for somewhat short periods. They don't know how many users there were on the LAN, although they can probably guess to within 10% or so based on the amount of traffic. They also don't have any way to know which user was using which privacy address at any given time unless they had a much more intimite view of the LAN in question. ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Iljitsch van Beijnum wrote: On 21 feb 2008, at 16:34, Harald Alvestrand wrote: Think of the case where there are 1000 users on a LAN, and one of them desires to use the address privacy option for all the normal reasons. Then think about the policeman / bad guy / secret agent / mafioso with a trace of all traffic from that LAN - he can immediately say that the 999 were using non-privacy-enhanced addresses, and the resulting trace will show him immediately what the 1000th was up to, no matter how many times he changed his address. I'm assuming you mean a trace of the activities of addresses from that LAN as seen from elsewhere, because if they can sniff the LAN they can also see the link addresses. But what the good/bad guy sees is 1099 addresses, 999 of which are used for somewhat long periods, and 100 of which are used for somewhat short periods. They don't know how many users there were on the LAN, although they can probably guess to within 10% or so based on the amount of traffic. They also don't have any way to know which user was using which privacy address at any given time unless they had a much more intimite view of the LAN in question. Unless you implement an identifiable format for privacy enhanced addresses; in that case they can 100% accurately say that 100 addresses were used by someone with something to hide. That was the idea I was trying to point out the bad sides of. ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Harald Alvestrand wrote : Rémi Després wrote: My desire to have privacy is, in itself, something I may want to keep private. I am not sure I see the practical consequences. If my source address says I am someone but you will not know who I am, isn't this sufficient? You're not thinking this through. Think of the case where there are 1000 users on a LAN, and one of them desires to use the address privacy option for all the normal reasons. Then think about the policeman / bad guy / secret agent / mafioso with a trace of all traffic from that LAN - he can immediately say that the 999 were using non-privacy-enhanced addresses, and the resulting trace will show him immediately what the 1000th was up to, no matter how many times he changed his address. Right if the user keeps the same address for a series of outgoing connections. However things are different in the context in which I proposed, in earlier mails of the same thread, that the resolver would query the DNS for site prefixes. The concern was client hosts for which one desires both: (1) a privacy similar to that offered by NATs; (2) undisturbed E2E significance of addresses and ports. For this, the idea at hand is that these clients would use a fresh privacy address for each outgoing connection (with some more specification work left to avoid unreasonable Duplicate Address Detection). If this is done, the poor mafioso will believe that consecutive connections of a single host are connections initiated by various hosts (or at least will be unable to decide which connections come from the same host) :-). If what you want to know is indeed which site is at the other end, wildcards at the /64 level will achieve that with no changes to existing code. I am not familiar enough with wildcard operation in the DNS. If it provides for queries that concern only site prefixes, then you are right: no need for an agreed wildcard IID. The result is the same with existing mechanisms, which is clearly better. Read RFC 1034 - or perhaps better, RFC 4592. They've been around for a while (although their behaviour still surprises many). Thanks. I will have a look. ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
Mark Andrews wrote : On 19 feb 2008, at 10:02, Dan Wing wrote: It would be interesting to write it down, and to see what would break if the IP stack acquired and provided a fresh v6 address to every new connection. Maybe nothing would break, which would be great. You also don't want to do it as you would also need massive churn in the DNS. The proposal is, more precisely, a new fresh v6 address for each OUTGOING connection. (A new address per incoming connection wouldn't make sense, right?) Then, there is no need to concern the DNS with these new addresses: - Addresses in the DNS would remain stable. - Hosts would simultaneously have their advertised address(es), registered in the DNS, and transient addresses for outgoing connections. This approach, say "extended privacy with fresh address per connection", has been introduced as a potential alternative to v6 to v6 NATs. The goal is to have : (1) privacy and security similar to that of these NATs; (2) preservation of E2E significance of addresses and port numbers. If there is interest in at least looking at it, more work would clearly be needed. In particular, some way to improve the Duplicate Address Discovery would have to be devised. IMHO, preserving E2E significance has numerous advantages, worth extending the scope of studied solutions. RD ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
On Wed, Feb 20, 2008 at 10:08:37AM +0100, Rémi Després [EMAIL PROTECTED] wrote a message of 68 lines which said: The proposal is, more precisely, a new fresh v6 address for each OUTGOING connection. ... Then, there is no need to concern the DNS with these new addresses: Mark Andrews' concern was, I believe, for the many services which refuse you or, worse, delay you deliberately, when there is no PTR DNS record for the source IP address (see draft-ietf-dnsop-reverse-mapping-considerations). ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
Can't you set your MUA to emit TEXT/PLAIN? It's just plain impolite to send only HTM ~!#!~!#$~ L. !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head meta content=text/html;charset=ISO-8859-1 http-equiv=Content-Type /head body bgcolor=#ff text=#00 Mark Andrews wrote : blockquote cite=mid:[EMAIL PROTECTED] type=cite blockquote type=cite pre wrap=On 19 feb 2008, at 10:02, Dan Wing wrote: /pre blockquote type=cite pre wrap=It would be interesting to write it down, and to see what would break if the IP stack acquired and provided a fresh v6 address to every new connection. Maybe nothing would break, which would be great. /pre /blockquote /blockquote pre wrap=! You also don't want to do it as you would also need massive churn in the DNS. /pre /blockquote The proposal is, more precisely, a new fresh v6 address for each OUTGOING connection.br There are plenty of services that want working reverse lookups before they will let you in. So yes, OUTGOING needs to be registered in the DNS as much as INCOMING. In addition that registration has to propogate to all the authoritative servers for the relevent zones. (A new address per incoming connection wouldn't make sense, right?)br Then, there is no need to concern the DNS with these new addresses:br - Addresses in the DNS would remain stable.br - Hosts wouldnbsp; simultaneously have their advertised address(es), registered in the DNS, and transient addresses for outgoing connections.br br This approach, say extended privacy with fresh address per connection,nbsp; has been introduced as a potential alternative to v6 to v6 NATs.br The goalnbsp; is to have : (1) privacy and security similar to that of these NATs; (2)nbsp; preservation of E2E significance of addresses and port numbers.br br If there is interest in at least looking at it, more work would clearly be needed.br In particular, some way to improve the Duplicate Address Discovery would have to be devised.br IMHO, preserving E2E significance has numerous advantages, worth extending the scope of studied solutions.br br RDbr br /body /html -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
Stephane Bortzmeyer wrote : The proposal is, more precisely, a new fresh v6 address for each OUTGOING connection. ... Then, there is no need to concern the DNS with these new addresses: Mark Andrews' concern was, I believe, for the many services which refuse you or, worse, delay you deliberately, when there is no PTR DNS record for the source IP address (see draft-ietf-dnsop-reverse-mapping-considerations). Thanks for the comment. Note that the "fresh part" of addresses we discuss here concerns only "in-site" information (the IID in the lowest 64 bits). The first 64 bits of IPv6 addresses are still available to identify sites from which connections are initiated. PTR RRs are normally used to get names corresponding to prefixes, not to addresses, so that there is IMU no reverse DNS problem here. Not also that v6 to v6 NATs, that this proposal aims at making unnecessary, tend to be bad in various contexts for remote address checking applications. RD ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
[Mark Andrews is right, it is very difficult to separate your message from the parts you quote, my mail reader does not have a HTML parser !] On Wed, Feb 20, 2008 at 01:57:18PM +0100, Rémi Després [EMAIL PROTECTED] wrote a message of 44 lines which said: The first 64 bits of IPv6 addresses are still available to identify sites from which connections are initiated. I was not speaking about you *can* do but about what people *do* today. A lot of people use the existence (or not) of a PTR record to grant you access or not. You may tell them PTR is useless, use the first 64 bits of the address instead, they won't listen. PTR RRs are normally used to get names corresponding to prefixes, not to addresses, so that there is IMU no reverse DNS problem here. AFAIK, there is no DNS way to resolve prefixes into names (RFC 1101, may be? Can we apply it to IPv6 addresses?). A PTR is for a complete adress, not for a prefix. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
Stephane Bortzmeyer wrote : [Mark Andrews is right, it is very difficult to separate your message from the parts you quote, my mail reader does not have a HTML parser !] Thanks. I will try to be more careful. On Wed, Feb 20, 2008 at 01:57:18PM +0100, Rémi Després [EMAIL PROTECTED] wrote a message of 44 lines which said: The first 64 bits of IPv6 addresses are still available to identify sites from which connections are initiated. I was not speaking about you *can* do but about what people *do* today. A lot of people use the existence (or not) of a PTR record to grant you access or not. You may tell them PTR is useless, use the first 64 bits of the address instead, they won't listen. I didn't tell anybody that PTRs were useless (and don't think it either!) :-). PTR RRs are normally used to get names corresponding to prefixes, not to addresses, so that there is IMU no reverse DNS problem here. AFAIK, there is no DNS way to resolve prefixes into names (RFC 1101, may be? Can we apply it to IPv6 addresses?). A PTR is for a complete adress, not for a prefix. I have to recognize that my knowledge of the DNS needs improvements. Sorry for that. Thanks for the rectification. As I now se it, I wrongly interpreted PTR RRs used for zone delegation as RRs that could also be used to identify sources. Then the point is different. An advantage of NATs, for remote host identification, is that a host name given to a NAT device serves as substitute name to all real hosts behind this NAT. A similar result could be achieved if resolvers, when they have to get a name for an IPv6 address having a privacy ID, instead of having no chance to get any name, would replace this ID by an agreed standard value for which there is a PTR RR. RD ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
On Wed, Feb 20, 2008 at 03:42:43PM +0100, Rémi Després [EMAIL PROTECTED] wrote a message of 49 lines which said: A similar result could be achieved if resolvers, when they have to get a name for an IPv6 address having a privacy ID, instead of having no chance to get any name, would replace this ID by an agreed standard value for which there is a PTR RR. It seems a good idea. RFC 1101 is probably the right basis for such a feature (which does not exist today). So, the roadmap is: * write a RFC 1101bis, mostly to introduce IPv6 support * convince the resolver's authors to use it (it requires code on their side) ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
Stephane Bortzmeyer wrote : On Wed, Feb 20, 2008 at 03:42:43PM +0100, Rémi Després [EMAIL PROTECTED] wrote a message of 49 lines which said: A similar result could be achieved if resolvers, when they have to get a name for an IPv6 address having a privacy ID, instead of having no chance to get any name, would replace this ID by an agreed standard value for which there is a PTR RR. It seems a good idea. Thanks. RFC 1101 is probably the right basis for such a feature (which does not exist today). So, the roadmap is: * write a RFC 1101bis, mostly to introduce IPv6 support * convince the resolver's authors to use it (it requires code on their side) Assuming that a RFC would describe the mechanism (1101bis or another) and that such a standard value would be found, I believe resolver developpers shouldn't be too reluctant to add this in a next release (full upward compatibility). NB: unless there are objections I don't know, the value could simply be 0:0:0:0, to mean unknown IID. Could we discuss all this in Philadelphia? RD ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
PTR for IPv6 clients (Re: IPv6 NAT?)
Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( [EMAIL PROTECTED] (MY, what an useful reverse map!) ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
On 19 feb 2008, at 10:02, Dan Wing wrote: It would be interesting to write it down, and to see what would break if the IP stack acquired and provided a fresh v6 address to every new connection. Maybe nothing would break, which would be great. You really don't want to do that for stuff like the web where you can easily end up setting up a dozen new TCP sessions in a second. (Web designers use insanely wasteful techniques with multiple external javascripts and style sheets per page, often loaded from different domains, not to mention the persistent use of spacer images.) Duplicate address detection takes too much time to make this useful, and the creation of such a large number of addresses makes DAD all the more important. You also don't want to do it for applications that require referrals, such as peer-to-peer. Current address privacy mechanisms change addresses at certain intervals, often 24 hours. Last time I checked this was enabled by default on Windows (Vista and on XP if IPv6 is enabled) but not on any other system, although I believe they all support it. The reason for this mechanism is not that two sessions can't be attributed to the same host, but that when a host moves it can't be tracked by its MAC address that would otherwise be in the lower 64 bits of its IPv6 address when using stateless autoconfig. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
Iljitsch van Beijnum wrote : It would be interesting to write it down, and to see what would break if the IP stack acquired and provided a fresh v6 address to every new connection. Maybe nothing would break, which would be great. You really don't want to do that for stuff like the web where you can easily end up setting up a dozen new TCP sessions in a second. (Web designers use insanely wasteful techniques with multiple external _javascript_s and style sheets per page, often loaded from different domains, not to mention the persistent use of spacer images.) Duplicate address detection takes too much time to make this useful, and the creation of such a large number of addresses makes DAD all the more important. I share the view that, with only the Duplicate Address Discovery protocol as is, this would be very inefficient. Some work would be needed to complement the DAD protocol in order to improve its efficiency for this kind of application. A number of addresses can at least be acquired in advance, to avoid delays when they have to be used, but this would clearly not be good enough. My feeling is that DAD protocol complements are possible such that the extended privacy we talk about would become practicable. But it seems unclear at this stage whether, in order to reach the same privacy and security objective, people will prefer to work on the IPv6 NAT paradygm, or on an Extended Privacy Address paradygm, or on both in parallel, My point here is just to discuss an ALTERNATIVE to IPv6 NATs with those who believe they are unavoidable. You also don't want to do it for applications that require referrals, such as peer-to-peer. Right. For these applications, addresses to be reached must be published somewhere, e.g. in the DNS. They appear as DESTINATION addresses of newly established connections. They therefore don't conflict with the"one new address for each outgoing connection" rule. (The rule concerns SOURCE addresses, a point which was implicit in what I wrote, but which may be worth making clearer) . RD ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
Le Tuesday 19 February 2008 11:02:49 ext Dan Wing, vous avez écrit : Is this functionality already available in Vista and Leopard? I ignore whether the privacy extension of stateless autoconfiguration of RFC 4941 is supported. It is supported in XP/Vista, and used by default for outgoing connections. It is supported by Linux, but outgoing connections default to the EUI64 address. Not sure about OSX. The one new address per outgoing connection rule, which I propose here for the fist time, would IMHO be worth implementing in addition to RFC 4941. But some more work to specify it in details would be needed before that. Some support of the idea would be a prerequisite. It would be interesting to write it down, and to see what would break if the IP stack acquired and provided a fresh v6 address to every new connection. Maybe nothing would break, which would be great. Overkill. RFC 5014 already specifies an API to control privacy extensions. -- Rémi Denis-Courmont ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 NAT?
-Original Message- From: Rémi Després [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 19, 2008 12:53 AM To: Dan Wing Cc: ietf@ietf.org Subject: Re: IPv6 NAT? Dan Wing wrote : It would not be an application concern. If users want this kind of strong privacy, Typically, users don't know or care; more often it is the network administrator that cares. Agreed. Users, or network administrators as the case may be, would be better. Ok, that's fair. they activate this extended privacy option in their hosts. Then the stack below applications applies the one new address for each outgoing connection rule. Addresses and ports keep their E2E significance for ALL applications. Thanks for the educating me on where this feature would be implemented. I have long assumed that v6 privacy is something the application would need to be involved with. Is this functionality already available in Vista and Leopard? I ignore whether the privacy extension of stateless autoconfiguration of RFC 4941 is supported. The one new address per outgoing connection rule, which I propose here for the fist time, would IMHO be worth implementing in addition to RFC 4941. But some more work to specify it in details would be needed before that. Some support of the idea would be a prerequisite. It would be interesting to write it down, and to see what would break if the IP stack acquired and provided a fresh v6 address to every new connection. Maybe nothing would break, which would be great. -d ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
* Iljitsch van Beijnum: On 14 feb 2008, at 21:49, Florian Weimer wrote: The prevailing assumption is that IPv6 end nodes will be globally addressable for practical purporses. I think this is a very unlikely outcome. Are you saying that there will be IPv6 NAT? Is a node globally adressable if it never receives any packets you (or others) send? From an upper-layer protocol point of view, I'd say it isn't. And that we should design protocols running on top of IPv6 to take NAT into account? These protocols need to take into account that if there's a (virtual) connection between two hosts, it's still not possible to establish arbitrary other (virtual) connections between them. If yes on both, how can we do that without a NAT specification so that the IETF can design protocols to work with NAT and vendors can build NATs that work with IETF protocols? I think the NAT question is a bit of a red herring. I suppose that anything that is broadly NAT-compatible increases its chances it will work well on actually deployed networks, be it IPv4, IPv6, or something else. However, I don't think we will see as much highly dynamic NAT (including port translation) on IPv6 as on IPv4. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
2. that all end nodes will 'automagically' be able to be reached through the IPv6 routing and routed protocols. Obviously #2 is sound But it's not what will happen on the Internet. Protocol development needs to take that into account. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
--On Monday, 18 February, 2008 16:33 +1300 Brian E Carpenter [EMAIL PROTECTED] wrote: While it is surely a factor, I believe the dominant driver for NAT is addressing autonomy. For enterprise networks, certainly, coupled with multihoming. But absolutely not for SOHO networks, where the dominant driver is having address space for a LAN. Brian, I suggest that it isn't that simple. The following drivers are, IMO, very important for SOHO networks. I won't try to judge dominant but suggest that the first is very important to those ISPs who provide connectivity and support to SOHO networks and that, in many cases, they and not the end-user are the customer for both equipment and addressing architectures. (1) With NATs, every SOHO network (or at least every SOHO network an ISP can claim with a straight face to support) has exactly the same topology and addressing architecture. That makes customer support much cheaper because one does not have to figure out how to parameterize the little scripts from which people select and read. (2) Security and address-hiding. While we know that the advantages of this via NAT are not significant, that hasn't prevented the marketing hype and the selling on NATs --or NATs plus a little packet inspection and lightweight versions of other firewall functions-- on that basis.If one accepts the belief that any marketing strategy that works is unlikely to be discontinued, this motivation for NATs won't go away. Worse, if we figure out how to eliminate it for IPv6, its effectiveness for IPv4 networks will impede the deployment of IPv6. (3) LAN configuration. While IPv6 autoconfiguration may be a better solution, the available user-interface and user-useable tools for managing LANs with NAT, DHCP, and MAC addresses are far superior to anything we have available and well-documented for NAT-less, multiple-address-per-host IPv6. That won't change until the boundary devices change and due consideration is given to the knowledge, skills, and patience of the typical network manager of the SOHO network. This is probably a non-issue as long as all of the machines on the LAN are pure clients but, as Keith points out, pure-client machines are fairly rare and becoming more rare. Certainly, as soon as one installs the first on-LAN file server or printer, one either has to face configuration issues or resource discovery protocols that tend to work poorly (or at least to be confusing) as soon as there are more than one device of a given type. (4) Multihoming. While it may not be general or obvious yet, I'm seeing a slowly growing trend toward wanting to attach SOHO networks to two (occasionally more) ISPs, whether on a load-sharing or a fallover basis. This is done in the hope that both ISPs won't be incompetent on the same day and in recognition that two residential connections are typically still a lot cheaper than one business connection, even when the latter comes with real support and an SLA. There are relatively inexpensive and relatively easy-to-manage devices on the market that support dual connections. They all use NATs, even when the addresses facing one or both WANs are public. There may be others, and probably are, but dismissing these as unimportant is a way to become irrelevant, not to either get rid of NATs or to encourage IPv6 deployment. john ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 NAT?
I think that many people in the security world and rather more outside it are repeating a big mistake we made during the cryptowars of the 1990s here. During the cryptowars, designing protocols to make them 'Freeh-proof' became a priority. It was certainly a bigger priority than making them usable by ordinary people. Case in point, insisting on deploying S/MIME and PGP as pure end-to-end security protocols to remove the possibility of interception at the server. This is the architecture that you need to defeat interception at the server but it comes at the cost of having to push out credentials to all the end points. So fewer than 0.01% of users ever enroll for an end user credential, fewer use them. Meanwhile we have a major problem with spam and social engineering attacks, both of which exploit the lack of authentication in the email system. The risk we face here is that people dismiss trustworthy computing in the same way for no other reason than to spite the RIAA. Security responds badly to political mandates, particularly the mandate 'don't make the system too secure'. There are real problems in using trustworthy computing for copyright enforcement systems. Any system that depends on protecting the confidentiality of decryption keys that are embedded in a couple of billion end points is going to have limited effectiveness. But that fact says nothing about the practicality of protecting secrets that are only deployed out to a few thousand end points that are subect to regular and effective control. I'll continue on my personal (not corporate) blog: http://dotfuturemanifesto.blogspot.com/2008/02/dont-make-it-too-secure.h tml -Original Message- From: Theodore Tso [mailto:[EMAIL PROTECTED] Sent: Monday, February 18, 2008 7:58 PM To: Hallam-Baker, Phillip Cc: Christian Huitema; Spencer Dawkins; Iljitsch van Beijnum; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: IPv6 NAT? On Mon, Feb 18, 2008 at 03:34:50PM -0800, Hallam-Baker, Phillip wrote: In the scenario I gave, the data I wish to stop the kids accessing is already on my network, net nanny is totally useless in this instance. Let us imagine that I have a configuration that consists of one Vista machine and one Home Server on which there is stored a collection of ripped DVDs of video nasties, you know The Sound of Music, Care Bears Movie etc. some of the nastiest films I have seen. I do not with the kids tastes to be corrupted by this rubbish. Heh. From the Capitol Step's, All I Want For Christmas Is A Tax Increase album: http://www.amazon.com/gp/music/wma-pop-up/B03JOO001001/ref=mu_sam_wm a_001_001 Security cannot be effective when it is provided in the form of a DIY assembly required project. But thats what the field has been doing. I'm afraid it's worse than that. As long as we provide general purpose computers, and some insiders that are determined to bring home databases filled with SSN so they can do work in the evenings, or children who know more about computers than their parents and who are determined download videos of Barney does Dallas, I'd claim is pretty much impossible to solve the particular security problem which you are worried about. And I'm not sure people are really willing to accept computers with the sorts of controls that would prevent these sorts of attacks on data. Look at the resistence to Microsoft's Palladium project by people such as Ross Anderson. (http://www.cl.cam.ac.uk/%7Erja14/tcpa-faq.html) Most consumers are far more focused on the sorts of abuse that could be perpetrated by Hollywood, the Music Industry, and Microsoft, rather than problems with databases filled with US Military personnel's credit information getting stolen out of unsecured laptops of incompentent government bureaucrats. One could have a debate about whether this is a correct assessment of risks by the consumer and by organizations like EFF and EPIC, but it's reality that won't be easily changed. In any case, this is a bit of a rathole from the original discussion, I suspect - Ted ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
On 19 feb 2008, at 14:20, John C Klensin wrote: (1) With NATs, every SOHO network (or at least every SOHO network an ISP can claim with a straight face to support) has exactly the same topology and addressing architecture. Is this important? The external address(es) are still different. (2) Security and address-hiding. While we know that the advantages of this via NAT are not significant, that hasn't prevented the marketing hype and the selling on NATs --or NATs plus a little packet inspection and lightweight versions of other firewall functions-- on that basis.If one accepts the belief that any marketing strategy that works is unlikely to be discontinued, this motivation for NATs won't go away. There are three options: 1. Port overloading NAT 2. 1-to-1 NAT 3. Stateful firewall 4. Nothing It looks like you're talking about 1., while most people assume that IPv6 requires 3. Also, IF NAT is deployed in IPv6, it's not a given that it's 1. rather than 2. Personally, I'm happy with 4. (3) LAN configuration. While IPv6 autoconfiguration may be a better solution, the available user-interface and user-useable tools for managing LANs with NAT, DHCP, and MAC addresses are far superior to anything we have available and well-documented for NAT-less, multiple-address-per-host IPv6. That won't change until the boundary devices change and due consideration is given to the knowledge, skills, and patience of the typical network manager of the SOHO network. This is probably a non-issue as long as all of the machines on the LAN are pure clients but, as Keith points out, pure-client machines are fairly rare and becoming more rare. Certainly, as soon as one installs the first on-LAN file server or printer, one either has to face configuration issues or resource discovery protocols that tend to work poorly (or at least to be confusing) as soon as there are more than one device of a given type. Untrue. The only problem I've ever had with stateful autoconfiguration is a delay when the initial router solicitation wasn't sent or received. With DHCP for IPv4, I've had problems on numerous occasions. Also, NAT is completely orthogonal to address configuration. Service discovery still has room for improvement, but generally, it works quite well. The IPv6 equivalent of http://192.168.1.1/ to configure some piece of equipment isn't fully formed yet, but it certainly doesn't require NAT, even if it requires stable addressing and more sane service discovery can't be used for some reason. (4) Multihoming. While it may not be general or obvious yet, I'm seeing a slowly growing trend toward wanting to attach SOHO networks to two (occasionally more) ISPs, whether on a load-sharing or a fallover basis. This is done in the hope that both ISPs won't be incompetent on the same day and in recognition that two residential connections are typically still a lot cheaper than one business connection, even when the latter comes with real support and an SLA. There are relatively inexpensive and relatively easy-to-manage devices on the market that support dual connections. They all use NATs, even when the addresses facing one or both WANs are public. Really? I've never seen such a box. NAT of course completely breaks multihoming because your sessions die when there is a rehoming event. I'd much rather run shim6, which requires nor supports NAT. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
ISP support models Re: IPv6 NAT?
On Feb 19, 2008, at 9:11 AM, Iljitsch van Beijnum wrote: On 19 feb 2008, at 14:20, John C Klensin wrote: (1) With NATs, every SOHO network (or at least every SOHO network an ISP can claim with a straight face to support) has exactly the same topology and addressing architecture. Is this important? The external address(es) are still different. Sure, but the home internal networks are identical. So Homeowner A calls up the ISP support and is having a problem getting a machine to work with the wireless router provided by the ISP. So the ISP tech says on a working machine, point your browser to 192.168.10.1 and A while later Homeowner B calls in with a similar problem. The ISP tech says on a working machine, point your browser to 192.168.10.1 and... Same with Homeowners C, D, E and so on. The variables are reduced to the smallest number so that the tech support issues can be reduced to as few as possible. The responses to those issues can then be scripted so that call center folks with minimal knowledge of the subject can assist (or the entire support operation can be outsourced to some remote call center). So for those ISPs that do this, using NAT to have identical home networks is a beautiful thing. Keeps their costs low and hopefully their customer satisfaction high. (Of course, probably exactly *none* of those of us on this list have such an ISP since we all like to mess with our own networks.) Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: ISP support models Re: IPv6 NAT?
On 19 feb 2008, at 15:40, Dan York wrote: Is this important? The external address(es) are still different. Sure, but the home internal networks are identical. So Homeowner A calls up the ISP support and is having a problem getting a machine to work with the wireless router provided by the ISP. So the ISP tech says on a working machine, point your browser to 192.168.10.1 and A while later Homeowner B calls in with a similar problem. The ISP tech says on a working machine, point your browser to 192.168.10.1 and... Same with Homeowners C, D, E and so on. I'm not buying that this is so important that it's worth having a box rewrite EVERY address in EVERY packet for. If you really want this, you can simply create a loopback interface with address fc00::1 on it and users can type http://[fc00::1]/; (ok, so the brackets are annoying, but no NAT helps against that) and the users can connect to that address regardless of what the addresses used on the LAN are. If the box runs a DNS resolver and mechanisms to inform hosts about the resolver address, you can avoid the whole address typing thing. And of course the use of a proper service discovery mechanism is highly recommended. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: ISP support models Re: IPv6 NAT?
I'm not buying that this is so important that it's worth having a box rewrite EVERY address in EVERY packet for. If you really want this, you can simply create a loopback interface with address fc00::1 on it and users can type http://[fc00::1]/; (ok, so the brackets are annoying, but no NAT helps against that) and the users can connect to that address regardless of what the addresses used on the LAN are. If the box runs a DNS resolver and mechanisms to inform hosts about the resolver address, you can avoid the whole address typing thing. And of course the use of a proper service discovery mechanism is highly recommended. If nobody writes all of this up into a set of guidelines for implementors of SOHO IPv6 gateways, including some more details on a proper service discovery mechanism, then it isn't going to happen. Implementors will just go with the tried and true technique of rewriting EVERY address in EVERY packet because that is what the experts suggest. If you want to let them know that the real experts suggest something different, then at minimum, an RFC should be published. However I'm beginning to believe that we need more than just a few good RFCs with guidelines for IPv6 gateways and middleboxes. We probably also need some books, magazine articles, conference presentations etc. to back it up. And the presentations need to be at conferences like this one http://www.date-conference.com/ not at the IETF meetings. And this one http://www.realtimelinuxfoundation.org/ and this http://www.embedded.com/ --Michael Dillon ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: ISP support models Re: IPv6 NAT?
Hi, Iljitsch, I'm confused... From: Iljitsch van Beijnum [EMAIL PROTECTED] On 19 feb 2008, at 15:40, Dan York wrote: Is this important? The external address(es) are still different. Sure, but the home internal networks are identical. So Homeowner A calls up the ISP support and is having a problem getting a machine to work with the wireless router provided by the ISP. So the ISP tech says on a working machine, point your browser to 192.168.10.1 and A while later Homeowner B calls in with a similar problem. The ISP tech says on a working machine, point your browser to 192.168.10.1 and... Same with Homeowners C, D, E and so on. I'm not buying that this is so important that it's worth having a box rewrite EVERY address in EVERY packet for. If you really want this, you can simply create a loopback interface with address fc00::1 on it and users can type http://[fc00::1]/; (ok, so the brackets are annoying, but no NAT helps against that) and the users can connect to that address regardless of what the addresses used on the LAN are. Were you thinking that the loopback interface would be on the working machine Dan mentioned, or the inner interface on the LAN router device (in my case, 192.168.10.1 would be my wireless router plugged into my cable modem) that is having connectivity issues on its outer interace? Because I'm almost sure the second case is what Dan's talking about... Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: ISP support models Re: IPv6 NAT?
--On Tuesday, 19 February, 2008 16:05 +0100 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 19 feb 2008, at 15:40, Dan York wrote: Is this important? The external address(es) are still different. Sure, but the home internal networks are identical. So Homeowner A calls up the ISP support and is having a problem getting a machine to work with the wireless router provided by the ISP. So the ISP tech says on a working machine, point your browser to 192.168.10.1 and A while later Homeowner B calls in with a similar problem. The ISP tech says on a working machine, point your browser to 192.168.10.1 and... Same with Homeowners C, D, E and so on. Exactly I'm not buying that this is so important that it's worth having a box rewrite EVERY address in EVERY packet for. Certainly you are entitled to that opinion. As Dan suggests, you probably don't have such a network or a need for it because you, like many of the rest of us, like to fuss with configurations or at least know how. I would guess, just judging from your notes to this list, that it has been a very long time since you have called your ISP looking for help that turns out to be about configuration of your LAN (probably as long as it has been for me, i.e., never). However, in much of the world, profit margins for ISPs in the residential and SOHO business are sufficiently thin that a single support call can wipe out a few month's of profits from that account and one that actually requires getting someone with knowledge on the phone can wipe out a year or more. If one is that ISP and has to make a choice between avoiding * the costs of even a few more support calls and * the costs of a box (whose cost is incurred by the user, not the ISP, or immediately passed on to the user) and some reduced performance in the user's connection (which, at worst, might induce the user to buy more bandwidth) the question of whether this is so important or even important enough is an absolute no-brainer: the standardized NAT configuration provides nothing but an upside for you (the ISP) and no downside that you care at all about. Sorry, life is hard sometimes and overall network rationality doesn't help much. If you really want this, you can simply create a loopback interface with address fc00::1 on it and users can type http://[fc00::1]/; (ok, so the brackets are annoying, but no NAT helps against that) and the users can connect to that address regardless of what the addresses used on the LAN are. I'm not sure this helps in any useful way, since the concern isn't reaching the home host but another host/ server (even if only a local server) on the same LAN. See the aside below, but, if our recommendation for moving from IPv4 to IPv6 involves training a user who has gotten used to typing, e.g., http://10.0.0.5;, or maybe just 10.0.0.5, to type http://[fc00::1]/; we will have inserted another stumbling block on the way to IPv6 deployment. If the box runs a DNS resolver and mechanisms to inform hosts about the resolver address, you can avoid the whole address typing thing. Sure. And I continue to be surprised that the current crop of home/SOHO router boxes don't automagically support local DNS with a fixed set of addresses, local names, and SRV records, as well as a LAN-boundary full-service resolver and cache. But it hasn't happened, which may or may not tell us something else that we should be worried about. And of course the use of a proper service discovery mechanism is highly recommended. Of course. I'd also like a new pony. Seriously (and this is the aside referred to above), I think we are going to be in big trouble wrt IPv6 deployment at the residential and SOHO sides of the market unless we figure out how to provide local DNS services _and_ very strongly discourage the use of numeric addresses in any application protocol. We've already got guidance against literal address use out there, but we keep writing notes --if only to each other-- that say no problem, just type this increasingly-complicated address. In actual practice (i.e., regardless of what the standard says about what is permitted) we have already pretty much deprecated address literals in email addresses. I believe that the HTTPbis effort should deprecate their use in URLs and that we should be moving toward deprecating their use in URIs entirely. There is some strangeness about all of this the user and application should figure out how to work with and manipulate literal addresses stuff vis-a-vis the original decisions to adopt what became IPv6. To some extent, the applications folks were told that, as long as they used names and called on TCP, the transition to IPv6 would be largely transparent to them and their applications and they signed off on
Re: ISP support models Re: IPv6 NAT?
On 19 feb 2008, at 16:25, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If nobody writes all of this up into a set of guidelines for implementors of SOHO IPv6 gateways, including some more details on a proper service discovery mechanism, then it isn't going to happen. Well, I was working in that direction: http://psg.com/lists/v6ops/v6ops.2008/msg00086.html However, I'm not getting the type of feedback that I need (i.e., from people running IPv6 ISP networks or building IPv6 CPEs, arguably, those people may not exist) so I hesitate to proceed. Implementors will just go with the tried and true technique of rewriting EVERY address in EVERY packet because that is what the experts suggest. Hm, in my book, suggesting that automatically disqualifies the suggester as an expert. On 19 feb 2008, at 16:30, Spencer Dawkins wrote: If you really want this, you can simply create a loopback interface with address fc00::1 on it and users can type http:// [fc00::1]/ (ok, so the brackets are annoying, but no NAT helps against that) and the users can connect to that address regardless of what the addresses used on the LAN are. Were you thinking that the loopback interface would be on the working machine Dan mentioned, or the inner interface on the LAN router device (in my case, 192.168.10.1 would be my wireless router plugged into my cable modem) that is having connectivity issues on its outer interace? Because I'm almost sure the second case is what Dan's talking about... Yes, and that's what I'm talking about, too. I sometimes forget that not everyone spends their days configuring routers :-) where loopback interfaces have a very different function than they do on hosts. Since you're sending all your packets to the router, the packets addressed to the router's FC00::1 address, which is tied to the loopback interface simply because loopback interfaces never go down, will be processed locally so you get to manage the router. Obviously this only works for your default gateway, and, as I said before, a good service discovery mechanism is still a very good idea. On 19 feb 2008, at 16:58, John C Klensin wrote: I'm not buying that this is so important that it's worth having a box rewrite EVERY address in EVERY packet for. Certainly you are entitled to that opinion. How nice. As Dan suggests, you probably don't have such a network or a need for it because you, like many of the rest of us, like to fuss with configurations or at least know how. I would guess, just judging from your notes to this list, that it has been a very long time since you have called your ISP looking for help that turns out to be about configuration of your LAN (probably as long as it has been for me, i.e., never). Right, how would my ISP know how my LAN is configured? Also, as a general rule I avoid support calls because they are invariably a waste of time. However, in much of the world, profit margins for ISPs in the residential and SOHO business are sufficiently thin that a single support call can wipe out a few month's of profits from that account and one that actually requires getting someone with knowledge on the phone can wipe out a year or more. And you think this works in FAVOR of NAT? The whole point of avoiding support calls is that everything works without trouble in the first place. Telling someone how to type in a URL to get at their device configuration is something you should avoid at almost any cost, because best case, it wastes time, worst case the user simply can't do it. I'm not kidding here. My current ISP (who forces me to use IPv4 NAT) lets me manage my port mappings through their website. Much smarter: if I were to call them, they could easily look inside their own system and fix things, rather than tell me to go into the box and do it. See the aside below, but, if our recommendation for moving from IPv4 to IPv6 involves training a user who has gotten used to typing, e.g., http://10.0.0.5;, or maybe just 10.0.0.5, to type http://[fc00::1]/; we will have inserted another stumbling block on the way to IPv6 deployment. Hence the need for a decent service discovery mechanism. I was merely illustrating the fact that there are MANY ways to arrive at the desired result that do not require NAT. They're not all especially great, but so far, nobody has been able to show how having NAT makes this better. Without service discovery or a DNS or external connectivity, you would still have to type a URL like above. Seriously (and this is the aside referred to above), I think we are going to be in big trouble wrt IPv6 deployment at the residential and SOHO sides of the market unless we figure out how to provide local DNS services _and_ very strongly discourage the use of numeric addresses in any application protocol. Allow me to take exception to the numeric part. Everyone knows how to type numbers. Even people who use
Re: ISP support models Re: IPv6 NAT?
On Feb 19, 2008, at 11:50 AM, Iljitsch van Beijnum wrote: However, in much of the world, profit margins for ISPs in the residential and SOHO business are sufficiently thin that a single support call can wipe out a few month's of profits from that account and one that actually requires getting someone with knowledge on the phone can wipe out a year or more. And you think this works in FAVOR of NAT? The whole point of avoiding support calls is that everything works without trouble in the first place. Telling someone how to type in a URL to get at their device configuration is something you should avoid at almost any cost, because best case, it wastes time, worst case the user simply can't do it. I'm not kidding here. My current ISP (who forces me to use IPv4 NAT) lets me manage my port mappings through their website. Much smarter: if I were to call them, they could easily look inside their own system and fix things, rather than tell me to go into the box and do it. DY Yes, you will undoubtedly get better customer service from ISPs who provide management of the SOHO endpoints (whether or not that is through a managed services offering or just their default operational style). I would expect most smart ISPs are moving in that direction. But there will certainly be those out there who don't. DY For those who don't manage the remote router/gateway, having an identical address pool for each location could be a useful way to minimize support issues. DY Forgetting about ISPs, for a moment, let's think about equipment vendors. If you think of all the zillion Linksys (or D-Link or whomever) home gateways... all of which are probably using 192.168.0.1 or whatever is the default address block. The fact that they are all identical makes *their* technical support issues much easier to address. And in this case they probably have no way to manage those devices remotely. See the aside below, but, if our recommendation for moving from IPv4 to IPv6 involves training a user who has gotten used to typing, e.g., http://10.0.0.5;, or maybe just 10.0.0.5, to type http://[fc00::1]/; we will have inserted another stumbling block on the way to IPv6 deployment. Hence the need for a decent service discovery mechanism. I was merely illustrating the fact that there are MANY ways to arrive at the desired result that do not require NAT. They're not all especially great, but so far, nobody has been able to show how having NAT makes this better. Without service discovery or a DNS or external connectivity, you would still have to type a URL like above. DY I don't know that any of us are saying that having NAT makes this better. I'm saying that having NAT is a *reality* in the corporate network environment and I personally expect that it will continue to be used in those environments after the IPv6 transition. (For reasons I've previously expressed.) DY So, in my view, the IETF has the option of addressing how to properly do NAT for IPv6 for those people out there who may wish to do so - or NOT addressing IPv6 NAT and letting equipment vendors and customers make it up as they go along. Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
Dan Wing wrote : It would not be an application concern. If users want this kind of strong privacy, Typically, users don't know or care; more often it is the network administrator that cares. Agreed. Users, or network administrators as the case may be, would be better. they activate this extended privacy option in their hosts. Then the stack below applications applies the one new address for each outgoing connection rule. Addresses and ports keep their E2E significance for ALL applications. Thanks for the educating me on where this feature would be implemented. I have long assumed that v6 privacy is something the application would need to be involved with. Is this functionality already available in Vista and Leopard? I ignore whether the privacy extension of stateless autoconfiguration of RFC 4941 is supported. The one new address per outgoing connection rule, which I propose here for the fist time, would IMHO be worth implementing in addition to RFC 4941. But some more work to specify it in details would be needed before that. Some support of the idea would be a prerequisite. RD ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
