Re: Production-scale NAT64
On 27/Aug/15 14:59, Bjoern A. Zeeb wrote: The question I have not seen the answer yet to is “why?” Is this really because of the network, e.g., separate pipes in some places still, with forwarding devices handling a lot less pps? Is it because of people having done a newer cleaner-cut network stack implementation and lately cared about its performance? Is it about middle nodes? Has anyone done the research on this?. The life of an IPv4 packet on the Internet is very likely to undergo some NAT at some point in its travels. I haven't yet heard of many doing NAT66, hence IPv6 not undergoing NAT means any slow-downs caused by NAT44 are missed (gladly) on IPv6. This might not necessarily be immediately visible on regular networks, but the large content players could count this quite easily due to the significant volumes of traffic their networks are having to aggregate and process. Mark.
Organization - Network and Firewall
In your orgs (Enterprise, Service Provider, whatever), how are your Network and Firewall teams organized? I'm a fan of having operational staff from both teams under the same leadership with an architectural presence from your security org directly involved enough to have influence. What have you seen work most effectively? Poorly? Thanks!
Re: Production-scale NAT64
On Thu, Aug 27, 2015 at 5:59 AM, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On 26 Aug 2015, at 15:23 , Ca By cb.li...@gmail.com wrote: On Wed, Aug 26, 2015 at 8:16 AM, valdis.kletni...@vt.edu wrote: On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said: Another relevant metric, less than 25% of my mobile subscribers traffic require NAT64 translating. 75+% of bits flows through end-to-end IPv6 (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...). So I'm guessing that 75% of the traffic flows with better latency than the 25% IPvhorse-n-buggy traffic? ;) Facebook says IPv6 is 20-40% faster http://www.internetsociety.org/deploy360/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/ Another way to look at it, IPv4 is 20-40% slower than IPv6. The question I have not seen the answer yet to is “why?” Is this really because of the network, e.g., separate pipes in some places still, with forwarding devices handling a lot less pps? Is it because of people having done a newer cleaner-cut network stack implementation and lately cared about its performance? Is it about middle nodes? Has anyone done the research on this? I too do not know, and i do not care. Looking in the rear view mirror at why NAT encumbered IPv4 sucks is not a priority of mine, but may be an interesting pedantic project for internet historians. We know that NAT causes very minor latency (session setup and matching per packet) and very minor loss (state management chaos), but i can hardly believe that is a 20-40% speedup. Then again, TCP is a sensitive thing. Either way, Twitter and Amazon seem a tad slow... perhaps they should enable IPv6. Or maybe they have plenty of IPv4 and don't care much about the 20-40% performance gain that Facebook has seen. CB
Re: Production-scale NAT64
On 26 Aug 2015, at 15:23 , Ca By cb.li...@gmail.com wrote: On Wed, Aug 26, 2015 at 8:16 AM, valdis.kletni...@vt.edu wrote: On Wed, 26 Aug 2015 07:28:08 -0700, Ca By said: Another relevant metric, less than 25% of my mobile subscribers traffic require NAT64 translating. 75+% of bits flows through end-to-end IPv6 (thanks Google/Youtube, Facebook, Netflix, Yahoo, Linkedin and so on ...). So I'm guessing that 75% of the traffic flows with better latency than the 25% IPvhorse-n-buggy traffic? ;) Facebook says IPv6 is 20-40% faster http://www.internetsociety.org/deploy360/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/ Another way to look at it, IPv4 is 20-40% slower than IPv6. The question I have not seen the answer yet to is “why?” Is this really because of the network, e.g., separate pipes in some places still, with forwarding devices handling a lot less pps? Is it because of people having done a newer cleaner-cut network stack implementation and lately cared about its performance? Is it about middle nodes? Has anyone done the research on this?
Re: Level(3) ex-twtelecom midwest packet loss (4323)
Finally got a call back from the Level3 NOC. There is a global ticket for this, #ST1878748. This is a wide-ranging outage effecting the entire Level3 network. I am supposed to get emailed updates now automatically, and will reflect those here. -mel On Aug 26, 2015, at 6:01 PM, Mel Beckman m...@beckman.org wrote: We continue to see 10 to 20 percent packet loss crossing TW border and even between clients in the same region (e.g. LA and Santa Barbara). No news from the NOC yet. -mel From: NANOG nanog-boun...@nanog.org on behalf of Jason Hellenthal jhellent...@dataix.net Sent: Wednesday, August 26, 2015 5:33 PM To: nanog@nanog.org Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323) Cleared up here in WI TW/Level3 COLO between 19:00 - 19:20 CST - 3235 Intertech Dr. Brookfield On Aug 26, 2015, at 16:44, Ryan K. Brooks r...@hack.net wrote: Seems to be impacting their entire network now. On 8/26/15 4:41 PM, Rafael Possamai wrote: I have been seeing the same issues, but haven't heard anything back yet. It has improved in the last 30 minutes or so, see below. http://imgur.com/KVAzetA * * On Wed, Aug 26, 2015 at 4:34 PM, Ryan K. Brooks r...@hack.net mailto:r...@hack.net wrote: Seeing packet loss on AS4323 since 2:30 Central time. NOC is unresponsive to phone and email. Anyone have an idea what's going on over there? -- Jason Hellenthal JJH48-ARIN
Re: Production-scale NAT64
On Thu, 27 Aug 2015, Mark Tinka wrote: If your IPv4 is public, you should not feel slow. Of course, if your IPv4 is private, then yes, some NAT44 may happen somewhere along the path. I strongly advise you to not assume that just because an IPv4 address is public (which I'm reading as RFC1918) means that it's not NATed. I learned the hard way that Tmobile, for one, squats on other organization's public IP space on their mobile network and NATs it to address space they are actually assigned. What you really mean is if your IPv4 is not NATed, then it should not feel slow, the type of address isn't necessarily an indicator. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross
RE: DDoS appliances reviews needed
I assume they don't list their testing methodology right? It always feels like they just read vendor spec sheets. Steve Mikulasik -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Joe Chisolm Sent: Thursday, August 27, 2015 9:53 AM To: nanog@nanog.org Subject: Re: DDoS appliances reviews needed Gartner did a report about a year ago. Not free. https://www.gartner.com/doc/2910217/ddos-comparison-defense-approaches On 08/26/2015 07:40 AM, Ramy Hashish wrote: Good day all, Anybody here has experienced a PoC for any anti DDoS appliance, or already using a anti DDoS appliance in production and able to share his user experience/review? We need to collect good reviews from people whom got their hands dirty with the configuration/attack mitigation, real experience. Thanks, Ramy -- Joe Chisolm Computer Translations, Inc. Network and Datacenter Consulting Marble Falls, Tx. 830-265-8018 Public Key Available at http://www.sks-keyservers.net
Re: DDoS appliances reviews needed
On Thu 2015-Aug-27 02:48:31 -0700, alvin nanog nano...@mail.ddos-mitigator.net wrote: --snip-- defending against DNS is almost equally trivial - 53/udp is used for dns queries ... ...except when it's not. TCP is an accepted transport for DNS queries and necessary for response sizes 512 bytes where EDNS is not in use / available. - 53/tcp is used for zone transfers between primary and secondary DNS servers thus, all incoming tcp packets to a DNS server are DDoS attacks except your own primary and secondary dns server ip# As per above, that's not entirely accurate, though you're welcome to cause some FPs by dropping legitimate DNS queries over TCP. Granted on our own recursive resolvers the percentage of TCP queries is vanishingly small to non-existent, but all is not correct. - we're all assuming your DNS server is closed for recursive queries to prevent DNS amplification attacks ... ...for different degrees of closed. I'm assuming $dayjob for at least *some* of the folks on this list entails a service provider network of some sort, where it'd be pretty likely there are some recursive resolvers available to their customers. DNS amplification queries sourced from (or spoofed as) within customer ranges and able to reach the resolvers are still a vector. -- Hugo signature.asc Description: Digital signature
Re: DDoS appliances reviews needed
Gartner did a report about a year ago. Not free. https://www.gartner.com/doc/2910217/ddos-comparison-defense-approaches On 08/26/2015 07:40 AM, Ramy Hashish wrote: Good day all, Anybody here has experienced a PoC for any anti DDoS appliance, or already using a anti DDoS appliance in production and able to share his user experience/review? We need to collect good reviews from people whom got their hands dirty with the configuration/attack mitigation, real experience. Thanks, Ramy -- Joe Chisolm Computer Translations, Inc. Network and Datacenter Consulting Marble Falls, Tx. 830-265-8018 Public Key Available at www.sks-keyservers.net
Re: Production-scale NAT64
On 27/Aug/15 17:57, Brandon Ross wrote: I strongly advise you to not assume that just because an IPv4 address is public (which I'm reading as RFC1918) means that it's not NATed. I learned the hard way that Tmobile, for one, squats on other organization's public IP space on their mobile network and NATs it to address space they are actually assigned. What you really mean is if your IPv4 is not NATed, then it should not feel slow, the type of address isn't necessarily an indicator. If we're being pedantic, yes. Mark.
BT contact?
http://www.bt.com over IPv6 has been down since ~8:52 am U.S. Central. Please send me a PM if you have a contact there, or forward this over. Thanks, Frank Bonus: www.brocade.com over IPv6 has been down since last night, too, as the was removed, but I have a contact there. root@nagios:/# wget -6 www.bt.com --2015-08-27 14:30:23-- http://www.bt.com/ Resolving www.bt.com... 2a00:2381:::1 Connecting to www.bt.com|2a00:2381:::1|:80... connected. HTTP request sent, awaiting response... No data received. Retrying. --2015-08-27 14:30:24-- (try: 2) http://www.bt.com/ Connecting to www.bt.com|2a00:2381:::1|:80... connected. HTTP request sent, awaiting response... No data received. Retrying. --2015-08-27 14:30:27-- (try: 3) http://www.bt.com/ Connecting to www.bt.com|2a00:2381:::1|:80... connected. HTTP request sent, awaiting response... No data received. Retrying. --2015-08-27 14:30:30-- (try: 4) http://www.bt.com/ Connecting to www.bt.com|2a00:2381:::1|:80... connected. HTTP request sent, awaiting response... No data received. Retrying. ^C root@nagios:/#
load balancer product for dns content switching
Spent quite a bit of time researching products out there looking for one that will do content switching based on the domain being queried, and I'm coming up empty. Can anyone point me in a decent direction? For example: all requests are sent to one (HA) VIP, and then: host.bob.domain.com gets routed to dns server group 1 host.bill.domain.com gets routed to dns server group 2 and so on... Thanks for any advice -- Brooks Bridges Firestorm Networks Email: bro...@firestormnetworks.net Voice: +1.8006975891 Fax: +1.8889721835
Re: load balancer product for dns content switching
F5 Big-IP? Pricey but it should do what you are looking for. Robert On Thu, 27 Aug 2015 12:13:37 -0700 Brooks Bridges bro...@firestormnetworks.net wrote: Spent quite a bit of time researching products out there looking for one that will do content switching based on the domain being queried, and I'm coming up empty. Can anyone point me in a decent direction? For example: all requests are sent to one (HA) VIP, and then: host.bob.domain.com gets routed to dns server group 1 host.bill.domain.com gets routed to dns server group 2 and so on... Thanks for any advice -- Brooks Bridges Firestorm Networks Email: bro...@firestormnetworks.net Voice: +1.8006975891 Fax: +1.8889721835
Re: load balancer product for dns content switching
While still in pre-production state, you might want to look at: http://dnsdist.org/ Andrew Andrew Fried andrew.fr...@gmail.com On 8/27/15 3:13 PM, Brooks Bridges wrote: Spent quite a bit of time researching products out there looking for one that will do content switching based on the domain being queried, and I'm coming up empty. Can anyone point me in a decent direction? For example: all requests are sent to one (HA) VIP, and then: host.bob.domain.com gets routed to dns server group 1 host.bill.domain.com gets routed to dns server group 2 and so on... Thanks for any advice
Re: Level(3) ex-twtelecom midwest packet loss (4323)
If you have access to the Level3 portal you should see ticket #9639047 under Network Events now. Event Summary:IP Network Event ~ Multiple Markets 08/27/2015 8:05 PM GMT Level 3 Tier III and Operations Engineering teams have identified Internet Protocols dropping, affecting customer services. Restoration efforts are in progress, but an estimated time of restoral is not available at this time. 08/27/2015 6:36 PM GMT IP and Transport Tier III, Operations Engineering and Field Services continue collaboratively working the issue. 08/27/2015 4:59 PM GMT Operations Engineering is engaged and Field Services is on site in Chicago, IL investigating the issue. 08/27/2015 4:38 PM GMT The engineers are currently migrating traffic in efforts of restoring services while troubleshooting continues. Field Services is being dispatched to a Chicago, IL site to assist. 08/27/2015 4:21 PM GMT IP services are affected across multiple markets and the root cause is currently under investigation. The IP NOC and IP and Transport Tier III are actively troubleshooting and working to isolate the cause. The engineers have detected peering issues which are resulting in packet loss for customers. Please be advised that updates will be provided at minimum of hourly unless otherwise noted.
RE: load balancer product for dns content switching
A10, brocade, etc lots of options out there- Sent from my Windows PhoneFrom: Brooks Bridges Sent: 8/27/2015 3:15 PM To: nanog@nanog.org Subject: load balancer product for dns content switching Spent quite a bit of time researching products out there looking for one that will do content switching based on the domain being queried, and I'm coming up empty. Can anyone point me in a decent direction? For example: all requests are sent to one (HA) VIP, and then: host.bob.domain.com gets routed to dns server group 1 host.bill.domain.com gets routed to dns server group 2 and so on... Thanks for any advice -- Brooks Bridges Firestorm Networks Email: bro...@firestormnetworks.net Voice: +1.8006975891 Fax: +1.8889721835
RE: BT contact?
Thanks for all the responses and assistance. I'm not sure if that help was the reason or not, but the site came back up at 4:16 pm U.S. Central. Frank -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Frank Bulk Sent: Thursday, August 27, 2015 2:32 PM To: nanog@nanog.org Subject: BT contact? http://www.bt.com over IPv6 has been down since ~8:52 am U.S. Central. Please send me a PM if you have a contact there, or forward this over. Thanks, Frank Bonus: www.brocade.com over IPv6 has been down since last night, too, as the was removed, but I have a contact there. root@nagios:/# wget -6 www.bt.com --2015-08-27 14:30:23-- http://www.bt.com/ Resolving www.bt.com... 2a00:2381:::1 Connecting to www.bt.com|2a00:2381:::1|:80... connected. HTTP request sent, awaiting response... No data received. Retrying. --2015-08-27 14:30:24-- (try: 2) http://www.bt.com/ Connecting to www.bt.com|2a00:2381:::1|:80... connected. HTTP request sent, awaiting response... No data received. Retrying. --2015-08-27 14:30:27-- (try: 3) http://www.bt.com/ Connecting to www.bt.com|2a00:2381:::1|:80... connected. HTTP request sent, awaiting response... No data received. Retrying. --2015-08-27 14:30:30-- (try: 4) http://www.bt.com/ Connecting to www.bt.com|2a00:2381:::1|:80... connected. HTTP request sent, awaiting response... No data received. Retrying. ^C root@nagios:/#
Re: load balancer product for dns content switching
On 28 Aug 2015, at 6:29, William Cooper wrote: A10, brocade, etc dnsdist, as well. --- Roland Dobbins rdobb...@arbor.net
RE: load balancer product for dns content switching
A10Networks should be able to do what you are looking for. Nathan Sipes Principal Network Architect Tel: 713-369-9866 FAX: 303-763-3510 Kinder Morgan 1001 Louisiana St KMB 548 Houston, TX 77002 nathan_si...@kindermorgan.com -Original Message- From: NANOG [mailto:nanog-bounces+nathan_sipes=kindermorgan@nanog.org] On Behalf Of Robert Webb Sent: Thursday, August 27, 2015 3:12 PM To: Brooks Bridges bro...@firestormnetworks.net; nanog@nanog.org nanog@nanog.org Subject: Re: load balancer product for dns content switching F5 Big-IP? Pricey but it should do what you are looking for. Robert On Thu, 27 Aug 2015 12:13:37 -0700 Brooks Bridges bro...@firestormnetworks.net wrote: Spent quite a bit of time researching products out there looking for one that will do content switching based on the domain being queried, and I'm coming up empty. Can anyone point me in a decent direction? For example: all requests are sent to one (HA) VIP, and then: host.bob.domain.com gets routed to dns server group 1 host.bill.domain.com gets routed to dns server group 2 and so on... Thanks for any advice -- Brooks Bridges Firestorm Networks Email: bro...@firestormnetworks.net Voice: +1.8006975891 Fax: +1.8889721835
Re: load balancer product for dns content switching
Citrix Netscaler as well. On Thu, Aug 27, 2015 at 4:11 PM, Robert Webb rw...@ropeguru.com wrote: F5 Big-IP? Pricey but it should do what you are looking for. Robert On Thu, 27 Aug 2015 12:13:37 -0700 Brooks Bridges bro...@firestormnetworks.net wrote: Spent quite a bit of time researching products out there looking for one that will do content switching based on the domain being queried, and I'm coming up empty. Can anyone point me in a decent direction? For example: all requests are sent to one (HA) VIP, and then: host.bob.domain.com gets routed to dns server group 1 host.bill.domain.com gets routed to dns server group 2 and so on... Thanks for any advice -- Brooks Bridges Firestorm Networks Email: bro...@firestormnetworks.net Voice: +1.8006975891 Fax: +1.8889721835 -- :o@
Re: Level(3) ex-twtelecom midwest packet loss (4323)
08/28/2015 3:08 AM GMT Event Conclusion Summary Start: August 27, 2015 13:20 GMT Stop: August 28, 2015 00:00 GMT Root Cause: A protocol issue impacted IP services in multiple markets. Fix Action: Adjustments were made to clear the errors. Summary: The IP NOC began investigating the root cause with Tier III Technical Support. It was reported that the issue was causing packet loss for customers. Operations Engineering teams were engaged, and Field Services were dispatched to a site in Chicago, IL to assist with investigations. Troubleshooting identified a protocol issue, and Operations Engineering worked with Tier III Technical Support to perform adjustments on the links. It was confirmed that the errors cleared. The traffic load was also lowered on cards in Chicago to alleviate any further issues. Should any additional impact be experienced, please contact the Level 3 Technical Service Center. What the hell is a protocol issue? I'm not an idiot, you can tell me specifically what happened... - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com - Original Message - From: Ryan Gelobter rya...@atwgpc.net To: Mel Beckman m...@beckman.org Cc: nanog@nanog.org nanog@nanog.org Sent: Thursday, August 27, 2015 3:14:59 PM Subject: Re: Level(3) ex-twtelecom midwest packet loss (4323) If you have access to the Level3 portal you should see ticket #9639047 under Network Events now. Event Summary:IP Network Event ~ Multiple Markets 08/27/2015 8:05 PM GMT Level 3 Tier III and Operations Engineering teams have identified Internet Protocols dropping, affecting customer services. Restoration efforts are in progress, but an estimated time of restoral is not available at this time. 08/27/2015 6:36 PM GMT IP and Transport Tier III, Operations Engineering and Field Services continue collaboratively working the issue. 08/27/2015 4:59 PM GMT Operations Engineering is engaged and Field Services is on site in Chicago, IL investigating the issue. 08/27/2015 4:38 PM GMT The engineers are currently migrating traffic in efforts of restoring services while troubleshooting continues. Field Services is being dispatched to a Chicago, IL site to assist. 08/27/2015 4:21 PM GMT IP services are affected across multiple markets and the root cause is currently under investigation. The IP NOC and IP and Transport Tier III are actively troubleshooting and working to isolate the cause. The engineers have detected peering issues which are resulting in packet loss for customers. Please be advised that updates will be provided at minimum of hourly unless otherwise noted.
Hosted Lync Platform
Is there anyone within the group that is running a Hosted Lync Platform that would be open to having a conversation? Cheers Ryan
Re: DDoS appliances reviews needed
hi ya ramy - ddos mitigation is NOT one appliance or cloud scrubber ... you'd require multiple layers of different ddos mitigation methodologies On 08/27/15 at 08:22am, Ramy Hashish wrote: Thank you Alvin, I have just remembered that I wanted to reply to your previous input on Wanguard versus the other vendors in the market, I will reply this there. per your comments on the other posts, its okay to disagree etc, etc ... everybody has their views .. maybe i wasnt clear enough with what i was saying too I can't get exactly what you are doing, do you have your own mitigation SW? If so I would like to know more about it. you can download the free version for testing .. http://DDoS-Mitigator.net/Download On Wed, Aug 26, 2015 at 8:53 PM, alvin nanog nano...@mail.ddos-mitigator.net wrote: ... for your reviewing or collecing info from folks .. - what's your metrics that is important to you ? Our important metrics includes but not limited to the following: - Ability to mitigate all kinds of volumetric DDoS attacks. mitigating all kinds of volumetric DDoS attacks means you'd probably fail most of the time ... the (simulated) ddos attackers can always, 100% of the time, generate more traffic that you want to defend against in hw or $$$ or time or staff ... i say, first defend against all the current DDoS attacks you are getting every minute of every day that'd already take lots and lots of time and $$$ and resources as is ... and volumizing it, to 1,000,000 packets/sec or more 10M or 100M packets/sec doesn't solve anything ... imho, the only way to defend against any volumetric ddos attacks that exceed your bandwidth capacity is to buy more capacity from the ISP or from (more expensive) DDoS cloud scrubbers - Ability to mitigate application level attacks for at least HTTP, HTTPs, SMTP and DNS. it should be trivial to defend against incoming http/https/smtp ddos attacks - the so called 10 minute problem defending against DNS is almost equally trivial - 53/udp is used for dns queries ... - 53/tcp is used for zone transfers between primary and secondary DNS servers thus, all incoming tcp packets to a DNS server are DDoS attacks except your own primary and secondary dns server ip# if UDP attacks against DNS servers exceed your bandwidth, again, you have to buy more bandwidth or have the ISP or the ddos scrubber cloud drop it for you - limiting replies to incoming udp or icmp is useless since it already used your bandwidth, cpu, memory, disk and the expensive staff's time - we're all assuming your DNS server is closed for recursive queries to prevent DNS amplification attacks ... - similary fix/patch NTP servers and ntp clients - if the ISP doesn't want to help defend against incoming UDP/ICMP attacks, than you're kinda screwed ... time to find a new ISP similarly, always turn off replies to ping broadcast from the outside to prevent smurf'ing yourself - Time-to-detect and time-to-mitigate. ddos mitigation should be automated ... people cannot watch and defend the servers watching millions of packets per second flowing thru the servers more importantlty, if people are looking at the packets and if you're sending/receiving confidential data, do you really want 3rd party eyeballs looking at all your packets, and regulations say they should be certified eyeballs and certified colo facilities too - False positives. hard to avoid which requires careful planning and lots of testing - Response time to the management plan. why would management dictate ddos mitigation policy vs IT security folks - Ability to sniff packets for further analysis with the support. too much work ... you have million or gazillion ddos packets per second to look at and you will NOT be able to see the attack from the legitimate packets or more importantly, might not care anymore ... - Granularity of detection thresholds. seem arbitrary to hit some threshold ... either it IS a ddos attack or it's NOT ... it should be fairly clear - Percentage of DDoS attack leakage. i dont understand the leakage - Multitenancy (We are an ISP) good the customers can help you determine legit traffic from DDoS traffic - Fast to detect/mitigate appliance, no problem to work inline. as is always the case, anytime you have a server inline, be sure they are crossed connected so that the other server can take over in case of hw failure my requirement: all tcp-based ddos attacks must be tarpit'd ... ... Could you please give more details on this? tarpit holds any incoming tcp-based connection attempt open for say 2minutes during which time the attacking server is stuck if the zombie ddos attacker sends 100,000 tcp packets/sec against your webserver or mail server, they'd have to have a lots of kernel memory ( 100,000 packet/sec * 1500byte/packet ) *
Re: Production-scale NAT64
On 27/Aug/15 08:34, Tore Anderson wrote: Hi Mark, There's not much difference between 464XLAT and MAP-*/DS-Lite/lw4o6 in this respect, the way I see it. In all cases you need four things: 0) Native IPv6. 1) A central component connected to the IPv4 internet and the IPv6. access network (464XLAT: PLAT, MAP-*: BR, DS-Lite/lw4o6: AFTR) 2) Signalling to client that #1 exists and can be used (464XLAT: DNS64, others: DHCPv6 options). 3) A distributed component at the customer premise/nodes that acts on #2 and connects an isolated IPv4 network to the IPv6 access network (464XLAT: CLAT, MAP-*: CE, DS-Lite/lw4o6: B4). The necessary undo work in all cases is to disable #2. At that point components #1 and #3 will become un-used and can be removed if you care. My guess is that you'll care about removing #1 because it probably uses power and space in your PoP, but that you won't care about #3 because that's just an unused software function residing in a customer device you might not even have management access to. I'll grant you that with NAT64/DNS64 *without* 464XLAT there is no #3 to remove as part of your undo work, but as I mentioned above I doubt you'll care about that particular distinction. Besides, since a CLAT is included by default in multiple client platforms, you can't really prevent your users from using 464XLAT if you're providing NAT64/DNS64 to begin with, unless you're doing something really weird like disabling DNS64 for the ipv4only.arpa. hostname specifically. Agree that with 464XLAT, the situation is not that different. The issue with 464XLAT for a service provider such as ourselves is that the majority of our customer's CPE and terminal equipment does not have 464XLAT support. You are mostly seeing 464XLAT support in mobile phones, and on specific mobile OS's (iOS does not support 464XLAT today, for example - unless this has changed or is changing). In that situation, our particular use-case could use more DNS64 for the signaling than 464XLAT or equivalent. You can't have it all - each network will have to choose the least of the various evils that can apply to it. Mark.
Re: Production-scale NAT64
* Mark Tinka mark.ti...@seacom.mu On 27/Aug/15 07:16, Mark Andrews wrote: Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T all of which are better solutions than NAT64. NAT64 + DNS64 which breaks DNSSEC. Because with NAT64/DNS64/464XLAT, there isn't any undo work after the dust settles. Hi Mark, There's not much difference between 464XLAT and MAP-*/DS-Lite/lw4o6 in this respect, the way I see it. In all cases you need four things: 0) Native IPv6. 1) A central component connected to the IPv4 internet and the IPv6. access network (464XLAT: PLAT, MAP-*: BR, DS-Lite/lw4o6: AFTR) 2) Signalling to client that #1 exists and can be used (464XLAT: DNS64, others: DHCPv6 options). 3) A distributed component at the customer premise/nodes that acts on #2 and connects an isolated IPv4 network to the IPv6 access network (464XLAT: CLAT, MAP-*: CE, DS-Lite/lw4o6: B4). The necessary undo work in all cases is to disable #2. At that point components #1 and #3 will become un-used and can be removed if you care. My guess is that you'll care about removing #1 because it probably uses power and space in your PoP, but that you won't care about #3 because that's just an unused software function residing in a customer device you might not even have management access to. I'll grant you that with NAT64/DNS64 *without* 464XLAT there is no #3 to remove as part of your undo work, but as I mentioned above I doubt you'll care about that particular distinction. Besides, since a CLAT is included by default in multiple client platforms, you can't really prevent your users from using 464XLAT if you're providing NAT64/DNS64 to begin with, unless you're doing something really weird like disabling DNS64 for the ipv4only.arpa. hostname specifically. Tore
