Re: DHCPv6 PD & Routing Questions
On 2015-11-21 05:08, Dave Taht wrote: > y'all might want to look over the work of the ietf homenet working > group for some insight into plans for dhcp-pd, and routing > interactions, in the home and small business, at least. > > https://tools.ietf.org/wg/homenet/ > > some dhcpv6 specific info is spread around using the new hncp protocol. > > blatant plug - https://github.com/sbyx/odhcp6c is now the best open > source dhcpv6 (and pd) client "out there" right now IMHO. > Dave Täht > Let's go make home routers and wifi faster! With better software! > https://www.gofundme.com/savewifi > > > On Sat, Nov 21, 2015 at 11:13 AM, Frederik Kriewitz > <frede...@kriewitz.eu> wrote: >> On Fri, Nov 20, 2015 at 10:35 PM, Jim Burwell <j...@jsbc.cc> wrote: >>> 2) What are the most common ways of managing the routing of delegated >>> prefixes in the ISPs routing domain? Has a standard method/best >>> practice emerged yet? Routing protocols? IPv6 RAs? >>> >>> One obvious answer would be routing protocols. In my brief googling, >>> I've seen a forum post that seems to indicate that Comcast makes use of >>> RIPng on their CPE to propagate routing information for prefixes >>> delegated to it. Can someone confirm this? This would seem as good a >>> method as any to do this, albeit with obvious security concerns. >> We've build a small tool which watches the dhcpd6 lease file for >> changes and injects the PD routes using exabgp (iBGP session with >> corresponding IA_NA address as next-hop for the IA_PD prefix). >> >> Best Regards, >> Frederik Kriewitz Thanks for all the replies. The gist I get is that no real SOP/BCP has emerged yet for doing this, and everyone is home-brewing their own methods. One of the other reasons I ask is because I was experimenting with Comcast Business IPv6. I was sent a cable modem that could do dual-stack and did PD. But it seemed really broken. It would only assign a /64, and never routed anything it assigned back to the head end as far as I could see through the customer interface. I was told that the firmware was broken. - Jim
Re: DHCPv6 PD & Routing Questions
On 2015-11-20 15:36, Owen DeLong wrote: >> On Nov 20, 2015, at 13:35 , Jim Burwell <j...@jsbc.cc> wrote: >> >> Hi, >> >> Have a simple couple of questions here. >> >> In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any >> reference to the protocol having any role in managing the routing of >> prefixes it delegates. Perhaps I missed it, but I somewhat expected the >> omission of this responsibility would be the case. >> >> My questions are: >> >> 1) Does the DHCPv6 protocol include any standards/mechanisms/methods for >> managing routes to prefixes it delegates, or does it consider this >> outside of its function? (I suspect the latter) > Yes and no… > > DHCPv6 doesn’t include anything specifically per se, but it does require that > the local router sees the DHCPv6 PD answer in the process of passing it > along to the target, and there’s a pretty obvious expectation that said router > will have to arrange to do the needful in that respect. > >> 2) What are the most common ways of managing the routing of delegated >> prefixes in the ISPs routing domain? Has a standard method/best >> practice emerged yet? Routing protocols? IPv6 RAs? > RAs really only apply to subnet local advertisement of routers and > the on-net prefixes in most implementations. > > I don’t think any of the various methods of using routing protocols, > static pre-routed blocks from which PDs are delegated, etc. could > necessarily be called “standardized”, but there are probably a few > that are more popular than most of the others. > > Unfortunately, PD is really still in its infancy in terms of development > and real running code for complete implementations throughout any > sort of site hierarchy. > > Owen > > On 2015-11-20 15:36, Owen DeLong wrote: >> On Nov 20, 2015, at 13:35 , Jim Burwell <j...@jsbc.cc> wrote: >> >> Hi, >> >> Have a simple couple of questions here. >> >> In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any >> reference to the protocol having any role in managing the routing of >> prefixes it delegates. Perhaps I missed it, but I somewhat expected the >> omission of this responsibility would be the case. >> >> My questions are: >> >> 1) Does the DHCPv6 protocol include any standards/mechanisms/methods for >> managing routes to prefixes it delegates, or does it consider this >> outside of its function? (I suspect the latter) > Yes and no… > > DHCPv6 doesn’t include anything specifically per se, but it does require that > the local router sees the DHCPv6 PD answer in the process of passing it > along to the target, and there’s a pretty obvious expectation that said router > will have to arrange to do the needful in that respect. > >> 2) What are the most common ways of managing the routing of delegated >> prefixes in the ISPs routing domain? Has a standard method/best >> practice emerged yet? Routing protocols? IPv6 RAs? > RAs really only apply to subnet local advertisement of routers and > the on-net prefixes in most implementations. > > I don’t think any of the various methods of using routing protocols, > static pre-routed blocks from which PDs are delegated, etc. could > necessarily be called “standardized”, but there are probably a few > that are more popular than most of the others. > > Unfortunately, PD is really still in its infancy in terms of development > and real running code for complete implementations throughout any > sort of site hierarchy. > > Owen > > Thanks for the answer Owen! So it sounds like things are still in flux. But it least it answers my main question of "have I missed something here"? Could you elaborate on the "local router seeing the PD answer" a bit? I presume by "local router" you mean router acting as DHCPv6 relay? Or do you mean the router which made the original request? Would it be fair to say that the RFCs only really talk about delegating the prefixes, and leave what to do with the prefixes themselves up to the implementer? I'm asking these questions because I'm doing a little class for some folks on IPv6 and this is one area where I couldn't find answers. - Jim
DHCPv6 PD & Routing Questions
Hi, Have a simple couple of questions here. In my admittedly cursory glances over the DHCPv6 RFCs, I don't see any reference to the protocol having any role in managing the routing of prefixes it delegates. Perhaps I missed it, but I somewhat expected the omission of this responsibility would be the case. My questions are: 1) Does the DHCPv6 protocol include any standards/mechanisms/methods for managing routes to prefixes it delegates, or does it consider this outside of its function? (I suspect the latter) 2) What are the most common ways of managing the routing of delegated prefixes in the ISPs routing domain? Has a standard method/best practice emerged yet? Routing protocols? IPv6 RAs? One obvious answer would be routing protocols. In my brief googling, I've seen a forum post that seems to indicate that Comcast makes use of RIPng on their CPE to propagate routing information for prefixes delegated to it. Can someone confirm this? This would seem as good a method as any to do this, albeit with obvious security concerns. What's the best way to implement a DHCPV6 PD client on a Linux router? Dibbler seems to do everything except route propagation (asks for PD, puts PD address on local NIC if asked). Anything better out there? TIA, - Jim
Re: Comcast IPv6 Milestone
Congrats to you and your team John! I presume Comcast Business is still a work in progress? - Jim On 7/24/2014 08:08, Brzozowski, John wrote: FYI – please feel free to contact me directly if you have any questions: http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-in-launch-of-ipv6-broadband-network Thank you, John = John Jason Brzozowski Comcast Cable w) www.comcast6.net e) john_brzozow...@cable.comcast.com =
Problems for route to 92.43.96.0/21 for Comcast?
Can't seem to get to 92.43.96.0/21 (specifically 92.43.96.130 ... in Salzburg Austria) from Comcast Business in the Bay Area (traceroute stops close to provider edge). Works from Verizon FiOS down in LA, and a HE.net host in Fremont. Comcast folks may want to look at this. :-) - Jim
Re: Comcast IPv6 Update
On 6/1/2012 11:06, Seth Mattinen wrote: On 6/1/12 7:04 AM, Brzozowski, John wrote: Jimmy, Trust me, I work for Comcast and run the IPv6 program. This has been the case for nearly 7 years. We can take some of the items below off list. We have launched IPv6 for residential broadband at this time. Commercial DOCSIS support is later this year. We can do two things. Get you a residential trial kit so you can have IPv6 for W6L and make sure I have your information for when we start trials for commercial DOCSIS support for IPv6. Forgive me if this is a stupid question since I've never been a cable guy, but what's physical difference between residential and commercial coax? ~Seth I'm a Comcast biz customer, mostly so I can have static IPs. I believe the main differences are that biz class has a different group of people supporting it and provisioning it. They also use different CPE. Probably also use different VLANs and such past the head end. But for biz class customers on cable, it uses the same underlying infrastructure as residential. I'm mostly speculating here, but I'd think a big hurdle for getting IPv6 service on biz class is in coming up with the support/provisioning/logistics infrastructure to support biz customers with IPv6. The residential customers have less control over the CPE than business class, likely making it easier for comcast to make changes for residential service. Comcast can update the CPE image, start running DHCPv6, and voila. But biz customers routers are somewhat configurable, and many biz class customers run their own routers/firewalls behind the comcast CPE (as do some residential customers also, of course), likely making things more complicated. I'd speculate that all the technical pieces are there to do it, but the logistical/support/management pieces probably aren't ready yet. Obviously, only the Comcast guys on here (John and Jason) know the whole story. But I'm patiently waiting for my native v6! It'll happen eventually. :-)
Re: Comcast IPv6 Update
On 6/1/2012 12:21, Jared Mauch wrote: On Fri, Jun 01, 2012 at 11:06:24AM -0700, Seth Mattinen wrote: On 6/1/12 7:04 AM, Brzozowski, John wrote: Jimmy, Trust me, I work for Comcast and run the IPv6 program. This has been the case for nearly 7 years. We can take some of the items below off list. We have launched IPv6 for residential broadband at this time. Commercial DOCSIS support is later this year. We can do two things. Get you a residential trial kit so you can have IPv6 for W6L and make sure I have your information for when we start trials for commercial DOCSIS support for IPv6. Forgive me if this is a stupid question since I've never been a cable guy, but what's physical difference between residential and commercial coax? Usually these are terminated on a different CMTS and may use different frequencies allocated. From a business side, there is a higher SLA afforded to the users, including phone notification of planned outages, etc that would happen. - Jared Ah I didn't know they even used separate CMTS for the biz customers.
Re: Comcast IPv6 Update
On 11/9/2011 08:58, Livingood, Jason wrote: On 11/9/11 11:54 AM, Blake T. Pfankuchbl...@pfankuch.me wrote: This appears directed at the Home market. Any word on the Business Class market even as a /128? Business Class is coming later. It won't hurt to contact the Business Class sales number and ask about IPv6 (and tell them to escalate it) - it all helps get us internal support and buy in. It is definitely on our radar though. - Jason Yeh. I've been waiting since before the trial started for biz class IPv6. I even read some article on one of the Comcast sites (IIRC) that one of their business class customers was doing NDS. I guess it was a one-off. :)
Re: useful bgp example
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/19/2010 11:58, Dan White wrote: You should be using 192.168.2.0 for documented examples,or at least private space. Configs like this tend to get cut and pasted into routers and get changed only when they don't work. Should that be 192.0.2.0/24, 198.51.100.0/24, or 203.0.113.0/24 (TEST-NET-3) per RFC 5737 http://tools.ietf.org/html/rfc5737#section-3 ? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv0R4UACgkQ2fXFxl4S7sScDACgulmdHhk6QJX/OlfvP1cCMq2e TZcAoIgrbd9HPFjpoSJvRFbML8VgckKj =zKse -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Re: Internationalized domain names in the root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/7/2010 22:53, Peter Beckman wrote: On Fri, 7 May 2010, Jeroen van Aart wrote: David Conrad wrote: Perhaps a bit off-topic, but some folks might get support calls... http://وزارة-الأتصالات.مصر/ That actually looks quite handsome. :-) And this is what it looks like to DNS: http://xn--4gbrim.xnrmckbbajlc6dj7bxne2c.xn--wgbh1c/ Hurrah for Punycode. Yeah I was experimenting around with that yesterday. Imagine a zone file full of such domain names. Ack! Did I accidentally hit x in the middle of that name in VIM? Better run it through the converter to make sure. Yay yet another level of complexity in DNS management. Some of the names look as ugly as the contents of DNSSEC RRs. :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvluX8ACgkQ2fXFxl4S7sTghwCg8sh1ZrKpa3d/GlYaGYhAZKN+ /HEAmgPrKZaaHynHRQuTAYfe4xQAWIh1 =cO/L -END PGP SIGNATURE-
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/26/2010 03:36, Mikael Abrahamsson wrote: On Sun, 25 Apr 2010, Owen DeLong wrote: I fail to see how link local is any more difficult than any other IPv6 address. They're different because you have to know your local network interface name as well. Windows might get interesting as windows interface naming is, uh, creative at best. Exactly. Installation software could make this easy. It could either prompt the user to type in the address on a sticker then enumerate all interfaces on the system and attempt to contact the router on each NIC. Another possibility is that it could enumerate all the interfaces, then use the IPv6 link-local scope all routers multicast (ff02::2) to enumerate a list of routers found on each link, sort them and/or filter them by ethernet OUI, and present a list of choices for the user to click on to configure the router. The user could also easily match the enet address on a little slip of paper or sticker on the router to this list, or through some initial settings on the router which allow info to be pulled from it somehow, present a list of unconfigured routers, etc, etc. Point is, I can imagine a lot of ways this could be made user-proof via software/firmware combination that requires no advanced networking knowledge. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvVpywACgkQ2fXFxl4S7sSCuwCg07Gwxz6NDYuTkVYr5gP5LUMC n4EAoIdqZQ7C/01X0EcV3vnZiTD4b7Vc =hDQN -END PGP SIGNATURE-
Re: Connectivity to an IPv6-only site
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/23/2010 05:42, Jared Mauch wrote: On Apr 23, 2010, at 5:49 AM, Dave Hart wrote: On Fri, Apr 23, 2010 at 08:26 UTC, Steve Bertrand st...@ibctech.ca wrote: - in WHOIS, I have ns1 and ns2.onlyv6.com listed as the authoritative name servers - both of these servers *only* have IPv6 addresses Which seems a bit far afield from reality to me. Yes, there are lots of folks with IPv6 connectivity and v4-only recursive DNS servers. I don't think ISPs will have problems setting aside a handful of IPv4 addresses for authoritative DNS infrastructure to work around this until v6 transport in recursive DNS servers is common enough. Not really, having your nameservers be IPv6 enabled is a reasonable thing to do. FYI: on comcast I see SERVFAIL, meaning their recursives do not have IPv6 transport. (I know we have that at my employer on our customer-facing recursives). ; DiG 9.6.0-APPLE-P2 any www.onlyv6.com. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 54773 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.onlyv6.com.INANY ;; Query time: 1605 msec ;; SERVER: 68.87.72.130#53(68.87.72.130) ;; WHEN: Fri Apr 23 08:41:08 2010 ;; MSG SIZE rcvd: 32 You'll see a lot of this. I've done my own little tests on a few friends' systems, and on public wifi, etc, establishing some sort of IPv6 connectivity, and trying to resolve a subdomaiin of mine with a IPv6 only DNS server. Many ISP recursive NS don't have IPv6 transport yet, so they choke getting to my NS. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRnmUACgkQ2fXFxl4S7sTfJwCfaKEB8juoXkHsgX7N+F+HNrEC PDwAoJm+Hn8NhBi6LKcX00T9JTEA35ma =nzM5 -END PGP SIGNATURE-
Re: Rate of growth on IPv6 not fast enough?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/23/2010 06:17, Clue Store wrote: But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from. Matthew Kaufman Yeh that information leak is one reason I can think of for supporting NAT for IPv6. One of the inherent security issues with unique addresses I suppose. flame-suit-on What makes you think that not using NAT exposes internal topology?? I have many cases where either filtering at layer-2 or NAT'ing a /48 for itself (or proxy-arp for those that do not have kits that can NAT IP blocks as itself) does NOT expose internal topology. Get your filtering correctly setup, and there is no use for NAT/PAT in v6. NAT was designed with one puropose in mind . extending the life of v4... period! The so called security that most think NAT gives them is a side effect. NAT/PAT also breaks several protocols (PASV FTP, H.323, etc) and I for one will be happy to see it go. I think it's a mistake to include NAT in v6 because there are other methodologies of accomplishing all of the side effects that everyone is use to seeing NAT provide without having to actually translate IP's or ports. I for one (as well as alot of other folks I know) am not/will not be using any kind of NAT moving forward. /flame-suit-on I'm not really advocating NAT for v6. I'm just saying it's one valid security issue with using any sort of globally unique IP address (v4 or v6), in that analyzing a bunch of traffic from a particular netblock would allow one to build a topology map. It's easier with IPv6 since you can presume most if not all addresses are on /64s out of a /48 (so look to the fourth quad for the subnet ID). Obviously if someone is super concerned with revealing this sort of info there are other things besides NAT they can do, such as using a proxy server(s) for various internet applications, transparent proxies, etc. But it is a valid security concern for some. Also, is that your real name? ;-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRozwACgkQ2fXFxl4S7sSACQCfeRfk5VmKjkW2SYkn/gZl53Ng Q0cAoKsQTGdTTBaEg1paE44yTNVy2OSQ =WAPA -END PGP SIGNATURE-
Re: Rate of growth on IPv6 not fast enough?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/22/2010 05:34, Simon Perreault wrote: On 2010-04-22 07:18, William Herrin wrote: On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of. Simon I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently. Of course, for browsers, as someone else mentioned, it's somewhat moot because of cookies. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvQR1IACgkQ2fXFxl4S7sT0agCglqjxX9d2kYuadrreIqPo5+rN FMAAniW1GodHwArieT/Czd96aMGQTgEF =xYjP -END PGP SIGNATURE-
Re: Rate of growth on IPv6 not fast enough?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/22/2010 22:00, Owen DeLong wrote: On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/22/2010 05:34, Simon Perreault wrote: On 2010-04-22 07:18, William Herrin wrote: On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of. Simon I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently. 4941 specified changing over time as one possibility. It does allow for per flow or any other host based determination of when it needs a new address. Owen K. Can't say I've read the RFC all the way through (skimmed it). Current implementations do the time thing. XP, Vista, and 7 seem to have it turned on by default. *nix has support via the net.ipv6.conf.all.use_tempaddr=2 variable, typically not on by default. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRLkUACgkQ2fXFxl4S7sQ2YgCg3uSkp1GNxcgjCDVc1jxnDv7s DtoAniXH8nND7+r6xEFJXGHrRJ77CBkZ =eSHI -END PGP SIGNATURE-
Re: Rate of growth on IPv6 not fast enough?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/22/2010 22:18, Matthew Kaufman wrote: Owen DeLong wrote: On Apr 22, 2010, at 5:55 AM, Jim Burwell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/22/2010 05:34, Simon Perreault wrote: On 2010-04-22 07:18, William Herrin wrote: On the other hand, I could swear I've seen a draft where the PC picks up random unused addresses in the lower 64 for each new outbound connection for anonymity purposes. That's probably RFC 4941. It's available in pretty much all operating systems. I don't think there's any IPR issue to be afraid of. Simon I think this is different. They're talking about using a new IPv6 for each connection. RFC4941 just changes it over time IIRC. IMHO that's still pretty good privacy, at least on par with a NATed IPv4 from the outside perspective, especially if you rotated through temporary IPv6s fairly frequently. 4941 specified changing over time as one possibility. It does allow for per flow or any other host based determination of when it needs a new address. Owen But none of this does what NAT does for a big enterprise, which is to *hide internal topology*. Yes, addressing the privacy concerns that come from using lower-64-bits-derived-from-MAC-address is required, but it is also necessary (for some organizations) to make it impossible to tell that this host is on the same subnet as that other host, as that would expose information like which host you might want to attack in order to get access to the financial or medical records, as well as whether or not the executive floor is where these interesting website hits came from. Matthew Kaufman Yeh that information leak is one reason I can think of for supporting NAT for IPv6. One of the inherent security issues with unique addresses I suppose. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRMCsACgkQ2fXFxl4S7sShwACgpZEd1rQD+/+dxonkOVpwPaUj oBIAoOJ78A5Yvftfz+JPjGWWQoVhb6F8 =oQHv -END PGP SIGNATURE-
Re: Rate of growth on IPv6 not fast enough?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/21/2010 03:38, Mark Smith wrote: On Tue, 20 Apr 2010 21:16:10 -0700 Owen DeLong o...@delong.com wrote: Frankly, when you hear people strongly using the argument stateful firewalling == NAT, you start to wonder if they've ever seen a stateful firewall using public addresses. I've run several of them. My comment wasn't a reply to you, more of a general comment about the surprising effort you still need to go to explain that stateful firewalling doesn't mandate NAT. I sometimes wonder if some people's heads would explode if I told them that this PC is directly attached to the Internet, has both public IPv4 and IPv6 addresses, and is performing stateful firewalling - with no NAT anywhere. I hear ya. Except for simple translations (e.g. one-to-one, whole net xlates), NAT is dependent on SPI, but SPI is not dependent on NAT. But some seem to combine the two into a single inseparable concept. I've definitely run into people who confuse the concepts. And also presume that without NAT there is less or no security. This head definitely wouldn't explode, since back in the early to mid 90s I ran enterprise networks on which all hosts had public IPs and there was no NAT at all. First protected by dumb filters on routers, which were fairly quickly replaced by dedicated SPI firewalls (such as Checkpoint). The first couple SPI firewalls I used didn't even *have* NAT capability. Yet, they did a fine job securing my LANs without it. And this is at a time when most workstations and servers on the LAN didn't have firewalls themselves (no OS included FW). Despite it doing the job it was intended to do, I've always seen NAT as a bit of an ugly hack, with potential to get even uglier with LSN and multi-level NAT in the future. I personally welcome a return to a NAT-less world with IPv6. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvO87cACgkQ2fXFxl4S7sSzQQCfU4Ip5mHkJ/inTfKO/1zih5yY VWUAnjte4aAbrcYvUraMXsUmaPj2JHGA =S3Gn -END PGP SIGNATURE-
Re: BGP hijack from 23724 - 4134 China?
On 4/9/2010 15:42, Benjamin Billon wrote: This is also blocking Sina, Netease, Yahoo.cn and other major Chinese ISP/ESP. Am I the only to think this is not very smart? It depends. I'am not a fan of country blocking. But in my case it can work for a home server. You could adapt the list and block port 22 only for production servers where you can't expect to never have email from China, but can safely block brute force ssh attacks. Yep, home server, your server. That's not the same when you have customers who rely on your server. IMHO, port 22 and other critical ports should always be blocked except from known places. I personally use a port knocking setup and it pretty much eliminates SSH brute force account/password hacks. Actually, on one box that didn't have the ability to do that, I simply moved the SSH port. This was surprisingly effective, although a bit inconvenient. I'll have to say that a very large number of the brute attempts were from Chinese IPs. Hopefully they're not reading this. ;-)
Re: what about 48 bits?
On 4/4/2010 08:46, Jonathan Lassoff wrote: Excerpts from John Peach's message of Sun Apr 04 08:17:28 -0700 2010: On Sun, 4 Apr 2010 11:10:56 -0400 David Andersen d...@cs.cmu.edu wrote: There are some classical cases of assigning the same MAC address to every machine in a batch, resetting the counter used to number them, etc.; unless shown otherwise, these are likely to be errors, not accidental collisions. -Dave On Apr 4, 2010, at 10:57 AM, jim deleskie wrote: I've seen duplicate addresses in the wild in the past, I assume there is some amount of reuse, even though they are suppose to be unique. -jim On Sun, Apr 4, 2010 at 11:53 AM, A.B. Jr. skan...@gmail.com wrote: Hi, Lots of traffic recently about 64 bits being too short or too long. What about mac addresses? Aren't they close to exhaustion? Should be. Or it is assumed that mac addresses are being widely reused throughout the world? All those low cost switches and wifi adapters DO use unique mac addresses? Sun, for one, used to assign the same MAC address to every NIC in the same box. I could see how that *could* work as long as each interface connected to a different LAN. That was a logic Sun used. Every NIC would be connected to a different subnet, so duplicate MACs shouldn't be a problem. For the most part this worked, but some situations required a unique MAC per NIC, and Sun had a bit you could flip to turn this on. I believe it was an OpenBoot prom variable called local-mac-address? which you'd set to true if you wanted it to use each NICs MAC instead of the system MAC. -Jim
Re: What is The Internet TCP/IP or UNIX-to-UNIX ?
On 4/4/2010 12:18, Steven Bellovin wrote: On Apr 4, 2010, at 3:08 16PM, Lyndon Nerenberg wrote: File transfer wasn't multihop It was, for at least some versions (V2 and later?), if the intermediate site(s) allowed execution of the uucp command. 25 years on the brain is fuzzy on the details ... You could certainly add uux and uux to the list of legal remote commands, but I confess that my memory is also dim about whether uucp file a!b!c would be translated automatically. It has indeed been a while... Heh this brings back some memories. uucp/uux for email and news. I remember writing shells scripts that would pull the UUCP maps out of the UseNet newsgroup (comp.mail.maps IIRC) and run pathalias on it to generate email bang path routes to all other mapped UUCP sites from yours so that you could use domain-style email addresses instead of remembering the paths! So then you could address an email to u...@uucpsite.uucp and Sendmail or Smail (I ran Smail) would look it up in the pathalias generated databse and convert it to a bang path. :) I also remember a few key dual-connected sites which were both on the UUCP network and the internet were used as gateways into the internet/DNS/SMTP email world. Specifically I remember psuvax being a widely used, and abused site for this, which eventually shut down that service because too many people were using them as a UUCP/internet gateway for email, sucking up all their cycles and bandwidth! -Jim
Re: What is The Internet TCP/IP or UNIX-to-UNIX ?
On 4/4/2010 17:20, Barry Shein wrote: I still believe that had as much to do with the collapse of the Soviet Union as the million other politicians who wish to take credit. It's arguable that UUCP (and Usenet, email, etc that it carried) was one of the most powerful forces for change in modern history. All you needed was some freely available software, a very modest computer, a modem, a phone line, and like so many things in life, a friend. And then once you got it, you looked towards connecting to the real internet, you knew just what you were after. I agree. I remember back in the 80s when I first got access to UseNet and UUCP based email thinking and saying things like the net will change the world, because for the first time people from all over the globe were communicating fairly openly and inexpensively, and somehow the internet and UUCP seemed to come in under the radar back then. I had more than a few people scoff at me for thinking that way though. :-)
Re: what about 48 bits?
On 4/4/2010 19:16, Mark Smith wrote:
-snip-
Actually the IEEE have never called it Ethernet, it's all been IEEE
802.3 / XXX{BASE|BROAD}-BLAH.
Ethernet, assuming version 1 and 2, strictly means thick coax, vampire
taps and AUI connectors running at (half-duplex) 10Mbps. I saw some of
it once.
I worked with it at my first job at a large government institution.
Talk about painful and unweildy. We had parts of our network wired with
10base5 (thick ethernet) with vampire taps, and had some segments wired
with transceivers which had a pair of threaded type N connectors (not
sure if this is the proper name ... it's what my boss called them ...
looked like oversized CATV F connectors). The xceiver boxes were
pretty big (4-5 inches wide) and connected to the node via an AUI drop
cable.
The N connectors were easier to deal with than the vampire taps. To add
a node, you just spliced a new xceiver box onto the line where you
needed it by screwing a new length of cable into the new + existng
xceivers, then connecting the AUI drop cable from the box to the node.
Eventually we went to 10base2 (thin ethernet) and then like everyone
else, 10baseT hubs.
Re: legacy /8
On 4/2/2010 19:13, George Bonser wrote: -Original Message- From: Jim Burwell [mailto:j...@jsbc.cc] Sent: Friday, April 02, 2010 6:00 PM To: nanog@nanog.org Subject: Re: legacy /8 So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem? And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases. No problem, everyone tunnels v4 in v4 and the outer ip address is your 32-bit ASN and you get an entire /0 of legacy ip space inside your ASN. Just need to get rid of BGP and go to some sort of label switching with the border routers having an ASN to upstream label table and there ya go. Oh, and probably create an AA RR in DNS that is in ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go! Done. :) So essentially add 32-bits to the IPv4 address, used as a ASN, and use legacy V4 on the backbone which tunnels everything, so the entire intra-ASN internet has to go through v4-in-v4 tunnels. A few little changes to DNS, and voila! And of course, there's no devils in the details we have to worry about. Heck.Just quote that last post up and submit it as an RFC to replace the IPv6 RFCs! :-) Seriously though, would that really be easier to implement, or be better than IPv6 as this point? I'd think the IETF would probably have considered solutions like that, but IPv6 is what we got. So best learn to love it. :P -Jim smime.p7s Description: S/MIME Cryptographic Signature
Re: legacy /8
On 4/2/2010 21:23, Randy Bush wrote: Anyway, I see it as pretty much moot, since many major players (Comcast, Google, etc) are in the midst of major IPv6 deployments as we speak. Eventually you will have to jump on the bandwagon too. :-) clue0: the isp for which i work deployed ipv6 in the '90s. we were the world's first commercial ipv6 isp deployment. golf clap clue1: not only can i do the math, but i can remember history Heh. I didn't really doubt that you understood the math. Was just being a bit snarky. :p (this whole thread is sort of flame bait anyway hehe). Anyway, with just 2000::/3 alone, there's about 500 million /32s. According to the CIDR report, there's ~34,000 ASs in BGP right now. Lets double that for future growth just for fun. If we do that, it means if we divided those /32s evenly among all of those ASes, each would get about 7800 of them. Each one contains 64Ki /48s. And again, that's just one /3 of the entire v6 space (yeah I know they won't be divided evenly ... different sizes orgs, regional assignments, etc, etc, etc). Anyway, I think the addy space will tide us over for quite a while, even if it's not enough as your last post seemed to indicate. Hey, and if we ever do run out, we can just NAT! ;) ;) ;) -Jim
Re: legacy /8
On 4/3/2010 01:03, Jeroen van Aart wrote: Owen DeLong wrote: It was thought that we would not have nearly so many people connected to the internet. It was expected that most things connecting to the internet would be minicomputers and mainframes. It took some visionary and creative thinking to come up with the internet. But given such a train of thought the idea of everyone being connected isn't such a wild idea. I can imagine it'd be almost a given. Although if I get the time frame right in those days you had 2 camps, those (ibm, dec...) who believed that there was no need for home computers and you only needed a few (hundred?) thousand big mainframes and minicomputers and those (commodore, apple...) who believed (rightfully so) there was going to be a big future and demand for home computers. So I guess depending on what camp you were in, it's not that strange to not envision all these household computers being interconnected. Hindsight is always 20/20. But remember that the internet started as a DoD project with just the military, mil contractors, universities, etc, connected to it. At first it wasn't even envisioned as something the general public would even use. And back in those times having a computer at home was still a fairly unusual thing. Only geeks had them (I remember kids poking fun at me back in middle school when they found out I had a home computer). Back then, during the computer revolution, you used a modem to connect to BBSes, services like Compu$serve, and perhaps the UUCP network for email and usenet. The internet was something only big orgs, corps, universities, and the military had. So it's not *too* surprising that the explosion that happened after the web browser/server came into being was a bit of a surprise for people. And it wasn't all that long after the explosion that I started hearing about things like IP-NG, etc (for a while I thought IPv6 would use OSI NSAPs hehe). So they got busy addressing the problem pretty quickly, despite having not predicted such a big explosion in internet use. Of course my memory could be a bit foggy, but there are guys on this list who were on the leading edge of all this who could (and probably have) tell the whole story in more detail. :) -Jim
Re: legacy /8
On 4/2/2010 17:22, Randy Bush wrote: ipv4 spae is not 'running out.' the rirs are running out of a free resource which they then rent to us. breaks my little black heart. even if, and that's an if, ipv6 takes off, ipv4 is gonna be around for a lng while. when 95% of the world has end-to-end ipv6, do you think amazon et alia are gonna blow 5% of their market by decomissioning ipv4? we are gonna learn how to distribute and use ipv4 more efficiently. it's not that hard, we know how to do it. internet engineers have worked through and around a lot of problems, it's our job. making connectivity continue work for folk who, for whatever reason, delay migration from ipv4 is just part of our job. not to panic. the hard part is figuring out how the rirs make money off ipv4 holders redistributing it among themselves. if that becomes a non-goal, things get a lot simpler. So, jump through hoops to kludge up IPv4 so it continues to provide address space for new allocations through multiple levels of NAT (or whatever), and buy a bit more time, or jump through the hoops required to deploy IPv6 and eliminate the exhaustion problem? And also, if the IPv4 space is horse-traded among RIRs and customers as you allude to above, IPv6 will look even more attactive as the price and preciousness of IPv4 addresses increases. The idea isn't for IPv4 to be replaced (decommissioned). The idea is for IPv6 to be added, then things will slowly transition. IPv4 will be around for a long time indeed, but increasingly, new sites/services, and old sites/services will be adding IPv6 as a way to connect to them. Then at some point, IPv6 will become the normal way to connect, and IPv4 will be a the legacy way, with fewer and fewer using it. Also, reading your other post, if you don't understand the difference between 2^32 and 2^128, please start here: http://en.wikipedia.org/wiki/Exponential_growth Anyway, I see it as pretty much moot, since many major players (Comcast, Google, etc) are in the midst of major IPv6 deployments as we speak. Eventually you will have to jump on the bandwagon too. :-) - Jim
Re: Important: IPv4 Future Allocation Concept RFC
On 4/1/2010 15:41, Joe Greco wrote: Someone suggested this be posted more visibly. ... JG LOL smime.p7s Description: S/MIME Cryptographic Signature
Re: IP4 Space
On 3/10/2010 05:06, Andy Koch wrote: On Wed, Mar 10, 2010 at 04:55, Jens Link li...@quux.de wrote: Owen DeLong o...@delong.com writes: denial anger bargaining depression acceptance--- My dual-stacked network and I are here. So am I. But most IT people I talk to are still at the denial phase. And there is not much one can do about it. Denial, incredulity, and even anger have often been the reaction I get from IT people when I bring up IPv4 exhaustion and IPv6. I'm careful to try to be cool about it too, trying not to be preachy or annoying about it. Some recent samples of IT people I talk to regularly in IRC: sam: Basically. We've had ipv6 for how many years in the UNIX world and we STILL haven't switched yet ... Ken: only Jim cares about IPv6 sam: 15 years of hype and we might get to it in another 5 sam: Emphasis on might sam: Everything I've installed in the last 2 years has ipv6 disabled Ken: i finally got an email from comcast about my participating in their ipv6 trials ... haha ... TRIALS - they're still at least 2 years out i'm sure I doubt I'm the only one who's run across these sorts of attitudes. At least Ken is willing to participate in the Comcast trial. :) IMHO, only personally experienced pain is going to push a lot of these sorts of people into ipv6. By pain, I mean things such as not being able to deploy their new service (web site, email server, VPN box, whatever) on the internet due to lack of ipv4 addresses, having to implement double NAT, CGN/LSN, or being forced to live behind such an arrangement [what do you mean I can't port forward the port for my favorite game/new service?!?! (yes, I know some schemes will still allow customer port forwards, but this will be made more difficult, painful, since many users will now be sharing the same publics.)] Once the pain hits, many will be doing crash courses in ipv6 and rolling it out as quickly as they can. I think it's just human nature. :) - Jim
Re: IP4 Space
On 3/10/2010 16:57, Owen DeLong wrote: IMHO, only personally experienced pain is going to push a lot of these sorts of people into ipv6. By pain, I mean things such as not being able to deploy their new service (web site, email server, VPN box, whatever) on the internet due to lack of ipv4 addresses, having to implement double NAT, CGN/LSN, or being forced to live behind such an arrangement [what do you mean I can't port forward the port for my favorite game/new service?!?! (yes, I know some schemes will still allow customer port forwards, but this will be made more difficult, painful, since many users will now be sharing the same publics.)] Once the pain hits, many will be doing crash courses in ipv6 and rolling it out as quickly as they can. I think it's just human nature. :) - Jim 8---snip I try to avoid being preachy, but, at the same time, there are some pretty hard numbers available. It's not the guys on IRC that need the most convincing anyway. They know, and in many cases, while they're still in denial, they don't need to change because they couldn't get support from above if they did. The target really needs to be the CxOs and the management, especially in places where there is content facing the general public. Fortunately, Google, Yahoo, Netflix, etc. get it and have moved forward with IPv6. Some others are coming along. True. CxOs can basically order it to be done. But for the guys in the trenches, I often talk about the issues just to give them a heads up, so they don't get caught off guard when ipv4 exhaustion hits. Plus, they can also exert pressure upwards that can cause decisions to be made. And in the case of small shops and start ups, they often are the primary decision makers/influencers for all things IT anyway (a situation I'm very familiar with). 8---snip The main thing we need to convey to our colleagues in the IRC crowd is that IPv6 really isn't as difficult as some have made it out to be. While it does require some different thinking, mostly in the area of address planning, the rest of it is pretty much business as usual just like IPv4. The other hurdle I've encountered is fear about switching to IPv6. We need to be clear that we aren't switching to IPv6, we're adding IPv6 capabilities to the existing IPv4 network. The former creates a lot more fear of change than the latter. Yep. I always try to convey how similar everything is for day to day network operations. I try to tell them that if they understand IPv4 CIDR, subnetting, etc, they're already 3/4 of the way there for IPv6. IMHO, address planning for the average company is far simpler under IPv6. Typically they'll be given a /48, and then they'll have 64Ki /64s to use for subnets, and that's it, and often all they'll ever need. To me this is simpler than the typical assortment of RFC1918s with heavy VLSM. Not to mention the RFC1918 overlap complications that arise with partnerships, mergers, etc. :-) Yes. I always emphasize dual-stack too. I tell them to just give it a try by setting up, say, an HE tunnel to one machine. Then later terminate the tunnel to a router and try it on a few more boxes. Another thing I do if they're running Vista or Windows 7, is to ping an IPv6 address, and when Teredo gets them ping replies, I tell them see, you're already running IPv6 and have basic connectivity. Although I don't know if this is a good idea, since Teredo isn't the most reliable thing. :p Owen (Oh, and in case anyone doesn't know, yes, I work for Hurricane Electric. I went to work there because I liked what they were doing with IPv6. I'd recommend their products (and did) even if I did not work there.) I get my IPv6 over an HE 6in4 tunnel. :-) I wish my ISP (who shall remain unnamed) provided native IPv6 service, but this is the response I got last time I inquired: Unfortunately, we don't have a status on changing to IPv6. We currently offer only ADSL2, Fiber and T1. And then after a second inquiry about a few months later: We are aware of the IPv4 situation and at this point and time we have no plans to switch over to IPv6. A shame since I'm otherwise very pleased with this ISP. I may hit them up again since it's been nearly a year since the last inquiry. Or at least try to get through to someone other than a TSE or a Billing Collections Manager. :)
Re: IP4 Space - the lie
On 3/5/2010 06:38, Cameron Byrne wrote: There is one of other catch with NAT64 and IPv6-only. It breaks communications with IPv4 literals. Now, you might says that IPv4 literals in URLs are very seldom well ... have a look at how Akamai does a lot of their streaming. I just hope it does not come to a show-down where networks move to IPv6-only since IPv4 is a goner and now Akamai content is not available while IPv6 early adopters like Google and Limelight laugh all the way to bank. One of the reasons I like the idea of DS-Lite. It may not be as native-IPv6 pure-and-holy as NAT64/DNS64, but it allows end users, IPv4 only applications, and legacy/non-IPv6 equipment to actually use IPv4 addresses. When the end user's favorite application stops working, or he can't play games online with his Xbox 360, he won't care about any explanations of NAT64/DNS64, or whose fault it is. He'll just want things to work. DS-Lite still allows this, and doesn't have any real impact on IPv4 exhaustion, since the end user will be issued RFC1918s, (likely) overlapped with other end users' RFC1918s. I also speculate that if one takes a large user community, say, customers of an ISP, and put them on NAT64/DNS64, we'll likely discover a lot more IPv4 only applications/services/appliances out there than we were expecting via the explosive ringing of flooded help desk lines. :p Granted, DS approaches will slow native IPv6 adoption a bit, but I think the real-world alternative is chaos. I personally prefer a scenario where users can go on using the internet as they've always done, likely oblivious to whether any particular site or application is using IPv6 or IPv4, while behind the curtain these same sites/applications are switching over to native IPv6, than a scenario where things simply stop working for them. Also, I hope that any pain associated with going through a CGN used in any of these sorts of approaches, and/or the benefits of native IPv6, will speed native IPv6 adoption more than any transition method might slow it. One can hope. :p
Re: Using /126 for IPv6 router links
On 1/26/2010 23:32, Mark Smith wrote: A minor data point to this, Linux looks to be implementing the subnet-router anycast address when IPv6 forwarding is enabled, as it's specifying Solicited-Node multicast address membership for the all zeros node address in it's MLD announcements when an interface comes up. Yes, I believe you are correct. It appears to be implemented. When I ping the subnet anycast from a Linux or Windows XP box I get a reply from the IPv6 router on my LAN. The router is a Linux box running Kernel 2.6.31. Interestingly, on a Linux box, the ping6 command shows the router's unicast address answering the pings (same goes for ping6 under Cygwin on a Windows box). But on a Windows box ping shows the anycast address answering. However, in both cases packet captures show it actually is the unicast address of the router answering, which I believe is the expected behavior. Windows ping just shows the wrong address for whatever reason. smime.p7s Description: S/MIME Cryptographic Signature
Re: Using /126 for IPv6 router links
On 1/25/2010 20:06, Mark Smith wrote: This from people who can probably do decimal to binary conversion and back again for IPv4 subnetting in their head and are proud of it. Surely IPv6 hex to binary and back again can be the new party trick? :-) Hehe. Decimal - binary in your head? I don't even bother except if it's some well known magic #s. Hex - binary though is super simple since unlike decimal, each digit translates exactly into a nybble. You just have to know the binary from 0 - 15, 16 simple four-bit patterns, and it's a piece of cake. You can give me hex numbers and and I'll rattle off binary all day, or vica-versa. Octal is similarly easy, but would result in some long IPv6 addresses. :-) smime.p7s Description: S/MIME Cryptographic Signature
Re: Are IPv6-only Internet services viable today?
On 1/15/2010 23:45, Owen DeLong wrote: On Jan 15, 2010, at 7:53 PM, Jim Burwell wrote: Sorry for late response here... On 1/14/2010 15:20, Cameron Byrne wrote: On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell j...@jsbc.cc mailto:j...@jsbc.cc wrote: On 1/14/2010 11:10, Cameron Byrne wrote: Folks, My question to the community is: assuming a network based IPv6 to IP4 translator is in place (like NAT64 / DNS64), are IPv6-only Internet services viable as a product today? In particular, would it be appropriate for a 3G /smartphone or wireless broadband focused on at casual (web and email) Internet users? Keep in mind, these users have NAT44 today. You may also want to read up on Dual Stack Lite (DS-Lite) http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-02, I have looked at DS-lite very carefully. First, DS-Lite fits better for cable operators since they have CPE and can have a DS-lite function in the CPE that they control, and that in turn allows them to provide IPv4, IPv6, and dual-stack to the end-host that they do not control. DS-Lite does not fit as well for a mobile phones since it would require a major change to the phone's OS. Second, DS-Lite requires tunneling as well as translation, so it is one more piece of overhead in addition to NAT64 solution. For me, i believe it is less complex to manage a single stack IPv6 host with NAT64 translation than a dual stack host, tunneling infrastructure, as well as NAT44 CGN, which is what DS-lite requires. They both achieve the same result, but I believe in the mobile space there is a quicker time to market as well as more progress toward the end-goal of IPv6-only using NAT64 than DS-lite. I guess the choice here is between standing up and managing a NAT64 CGN + special DNS64 DNS server infrastructure, or a DS-Lite CGN + DS-Lite tunneling infrastructure (you'd be able to keep existing vanilla DNS servers). As I understand DS-Lite, an IPv6-capable device is a DS-Lite capable device without any modification. The DS-Lite Gateway does all the heavy lifting to provide IPv4 services and do the NAT64 translation between the IPv6-only end-user device (phone) and the IPv4 internet. Could well be the case. My idea was that you could do it either way. You could have a DS-Lite gateway (Typical. Likely built into the cable modem or similar device), or in the case where no gateway is available, a DS-Lite client (basically a virtual nic/tunnel driver) on the machine would establish the tunnel and an IPv4 address itself. But perhaps this latter method was never intended? smime.p7s Description: S/MIME Cryptographic Signature
Re: Are IPv6-only Internet services viable today?
Sorry for late response here... On 1/14/2010 15:20, Cameron Byrne wrote: On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell j...@jsbc.cc wrote: On 1/14/2010 11:10, Cameron Byrne wrote: Folks, My question to the community is: assuming a network based IPv6 to IP4 translator is in place (like NAT64 / DNS64), are IPv6-only Internet services viable as a product today? In particular, would it be appropriate for a 3G /smartphone or wireless broadband focused on at casual (web and email) Internet users? Keep in mind, these users have NAT44 today. You may also want to read up on Dual Stack Lite (DS-Lite) http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-02, I have looked at DS-lite very carefully. First, DS-Lite fits better for cable operators since they have CPE and can have a DS-lite function in the CPE that they control, and that in turn allows them to provide IPv4, IPv6, and dual-stack to the end-host that they do not control. DS-Lite does not fit as well for a mobile phones since it would require a major change to the phone's OS. Second, DS-Lite requires tunneling as well as translation, so it is one more piece of overhead in addition to NAT64 solution. For me, i believe it is less complex to manage a single stack IPv6 host with NAT64 translation than a dual stack host, tunneling infrastructure, as well as NAT44 CGN, which is what DS-lite requires. They both achieve the same result, but I believe in the mobile space there is a quicker time to market as well as more progress toward the end-goal of IPv6-only using NAT64 than DS-lite. I guess the choice here is between standing up and managing a NAT64 CGN + special DNS64 DNS server infrastructure, or a DS-Lite CGN + DS-Lite tunneling infrastructure (you'd be able to keep existing vanilla DNS servers). Presuming you could set up DS-Lite capable routers somewhere in the path, one nice thing about DS-Lite would be that you could allow a mix of dual-stack phones, IPv4 only phones, and even DS-Lite capable phones on the same network. This could be an advantage if IPv6 stacks or DS-Lite virtual nic/tunnel drivers weren't available on all customer phones. Also, as Mr. Durand mentioned earlier, DS-Lite has an advantage in application compatibility too. And, admittedly getting a bit speculative here, by virtue of the fact that a DS-Lite solution would give each phone an IPv4 address, NAT compatibility of various applications may also be better on the CGN, since NAT44 is so well understood and generally worked out today, where a NAT64 CGN might not support as many problem apps which require fixups as a DS-lite NAT44 CGN. But if we can presume all phones will have IPv6, and all applications running on them are IPv6 capable, then DNS64/NAT64 would in some ways be cleaner, since it'd eliminate the traffic overhead of tunneling, etc. You'd just have to stand up and manage the DNS64 servers and NAT64 CGNs. presuming you haven't. I know you mentioned you didn't like any dual-stack solutions, but the thing about DS-Lite I like is that it has no problem with RFC1918 overlap of different customers, since the CGN uses a tunnel ID in the connection/NAT table in addition to the other typical data. I just wonder how it will scale, since each device, or a gateway the device goes though, will require a IPv4-in-IPv6 tunnel to the CGN box(es). Also, it doesn't require a DNS-ALG like NAT64/DNS64. NAT64/DNS64 does not use a DNS-ALG. DNS-ALG died with NAT-PT. DNS64 is a standalone function which is decoupled from the translation process. Yeah this is improper terminology I suppose. I use DNS-ALG in the IPv6 transition context as a generic term for any specialized DNS server which hacks IPv4 addresses into fake IPv6 addresses for these sorts of purposes, which is further overloading the term I guess. :p Not sure what to use as a better generic term for this. The point I was trying to make is that DS-Lite doesn't require any DNS hackery, unlike NAT64/DNS64, for what it's worth. Anyway, plenty to weigh/consider here. PS: Nice to see the author of the DS-Lite drafts participating here too. :) smime.p7s Description: S/MIME Cryptographic Signature
Re: Are IPv6-only Internet services viable today?
On 1/14/2010 11:10, Cameron Byrne wrote: Folks, My question to the community is: assuming a network based IPv6 to IP4 translator is in place (like NAT64 / DNS64), are IPv6-only Internet services viable as a product today? In particular, would it be appropriate for a 3G /smartphone or wireless broadband focused on at casual (web and email) Internet users? Keep in mind, these users have NAT44 today. You may also want to read up on Dual Stack Lite (DS-Lite) http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-02, presuming you haven't. I know you mentioned you didn't like any dual-stack solutions, but the thing about DS-Lite I like is that it has no problem with RFC1918 overlap of different customers, since the CGN uses a tunnel ID in the connection/NAT table in addition to the other typical data. I just wonder how it will scale, since each device, or a gateway the device goes though, will require a IPv4-in-IPv6 tunnel to the CGN box(es). Also, it doesn't require a DNS-ALG like NAT64/DNS64. smime.p7s Description: S/MIME Cryptographic Signature
Re: Default Passwords for World Wide Packets/Lightning Edge Equipment
On 1/6/2010 01:23, Dobbins, Roland wrote: On Jan 6, 2010, at 4:18 PM, Matthew Palmer wrote: The closest I can come to a solution is to set a random password and flash it using a front-panel LED using morse. grin heh No password at all, operator prompted at the console during startup unless/until he sets one. No IP address, et. al. until a password is set. Yeah. And for devices with no console, only network interfaces, a default IP address, no default password, and no default route (just in case they plug it into a real LAN instead of a laptop. :p ).
Re: IPv6 Training
On 12/23/2009 13:03, Mike Leber wrote: Marty Anstey wrote: Just wondering if anyone has had any experience with IPv6 training courses. A quick search turns up a few results on the subject, but it would be handy to hear if anyone has any firsthand experiences or recommendations. We're based in western Canada but don't mind traveling a bit, but alternatively an online course would be acceptable as well. Once you have IPv6 connectivity established (either native IPv6 or via a tunnel from anybody (for example tunnelbroker.net or sixxs.net) if you want a self teaching procedural guide where you can setup and test various IPv6 services (HTTP, SMTP, reverse DNS, forward DNS, host record glue) then you might checkout our free IPv6 certification service at: http://ipv6.he.net/certification It's a bit tongue in cheek and meant to be sort of like entertainment with education for engineers (for example the certification ranks are from Newb to Sage). By the time you are done you are done IPv6 won't seem weird. (In fact, you'll probably be thinking that's it?!) Tongue in cheek? You mean I'm not *really* a Sage? :p :p The tunnelbroker.net forum is also a good source of info/discussion about IPv6. It'd be nice if it was a bit more active though. smime.p7s Description: S/MIME Cryptographic Signature
