Easy to remember IP-address
Gentlemen, Some days ago, I told Jaap Akkerhuis about allocation of 2.2.2.0/24 address space for our DNS-service and he advice me to contact this workgroup. Our company Ideco is located in Russia and is in the business of developing and selling Internet gateways for small and middle businesses in Russia as well as billing software for ISPs. We’re now starting a new project for Russia and Eastern Europe that will provide secure Internet access for educational institutions, commercial and non-profit organizations. We’re planning to set up a number of DNS-centers that will block malware, adult websites and phishing links. For this project we’ll need an easy to remember IP-address, for example like the one for Google Public DNS service (8.8.8.8) We have contacted RIPE NCC with a request to get a block of addresses 2.2.2.0/24, but were told that the standard procedure does not allow us to choose an address range. Is it possible to modify current Address Policy? -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz@idecogateway.com Web: www.idecogateway.com
You forgot the ladies. RIR policies are set by the members of the RIR... so yes, it is possible to modify current address policy. I'll note that in the case you referece, Google made a deal with the folks who were allocated the net 8 space, not with the RIR. --bill On Mon, Mar 29, 2010 at 04:41:35PM +0600, Sergey Gotsulyak wrote:
Gentlemen,
Some days ago, I told Jaap Akkerhuis about allocation of 2.2.2.0/24 address space for our DNS-service and he advice me to contact this workgroup.
Our company Ideco is located in Russia and is in the business of developing and selling Internet gateways for small and middle businesses in Russia as well as billing software for ISPs.
Webre now starting a new project for Russia and Eastern Europe that will provide secure Internet access for educational institutions, commercial and non-profit organizations. Webre planning to set up a number of DNS-centers that will block malware, adult websites and phishing links.
For this project webll need an easy to remember IP-address, for example like the one for Google Public DNS service (8.8.8.8)
We have contacted RIPE NCC with a request to get a block of addresses 2.2.2.0/24, but were told that the standard procedure does not allow us to choose an address range.
Is it possible to modify current Address Policy?
-- Kind regards, Sergey Gotsulyak
Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016
Phone: (800) 715-3502 Email: goz@idecogateway.com Web: www.idecogateway.com
Hi, On Mon, Mar 29, 2010 at 04:41:35PM +0600, Sergey Gotsulyak wrote:
Is it possible to modify current Address Policy?
Yes. RIPE has a well-defined policy development process, which can be used for that - it's documented here: http://www.ripe.net/ripe/docs/pdp.html Now, there's of course a catch - the PDP takes a while to run through (a couple of months at best, some times much longer), and you need *consensus* for a proposed policy change to become policy - so you need to convince the RIPE community that it's of common interest to change this. Since we're running out of addresses quickly, even if you succeed in changing the policy, the subnet containing 2.2.2.2 might already be handed out to someone else. So I wouldn't bet the success of my company on the chance of receiving 2.2.2.2 - you might succeed, but you might as well not. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hay, Am 29.03.2010 12:58, schrieb Gert Doering:
Hi,
On Mon, Mar 29, 2010 at 04:41:35PM +0600, Sergey Gotsulyak wrote:
Is it possible to modify current Address Policy?
Yes. RIPE has a well-defined policy development process, which can be used for that - it's documented here:
http://www.ripe.net/ripe/docs/pdp.html
Now, there's of course a catch - the PDP takes a while to run through (a couple of months at best, some times much longer), and you need *consensus* for a proposed policy change to become policy - so you need to convince the RIPE community that it's of common interest to change this.
Since we're running out of addresses quickly, even if you succeed in changing the policy, the subnet containing 2.2.2.2 might already be handed out to someone else. So I wouldn't bet the success of my company on the chance of receiving 2.2.2.2 - you might succeed, but you might as well not.
or to put it simpler: If we would have such a policy, all nice vanity addresses would have been "sold out" (mind the quotes) by now already anways. And you might not have the budget to "buy" a nice address either because it would cost a fortune like sex.com or so :-) But, fortunately, IP addresses are not Domain Names.... -- ====================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================
If we would have such a policy, all nice vanity addresses would have been "sold out" (mind the quotes) by now already anways. And you might not have the budget to "buy" a nice address either because it would cost a fortune like sex.com or so :-)
But, fortunately, IP addresses are not Domain Names....
This is not bad on one side. But on the other – let’s picture a situation when a company gets randomly assigned for example domain dju48d.com instead of clear and simple domain company.com... For many this situation is even worse than the first one :-) -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz@idecogateway.com Web: www.idecogateway.com
Gert, On 2010-03-29 12:58, Gert Doering wrote:
Hi,
On Mon, Mar 29, 2010 at 04:41:35PM +0600, Sergey Gotsulyak wrote:
Is it possible to modify current Address Policy?
Yes. RIPE has a well-defined policy development process, which can be used for that - it's documented here:
http://www.ripe.net/ripe/docs/pdp.html
Now, there's of course a catch - the PDP takes a while to run through (a couple of months at best, some times much longer), and you need *consensus* for a proposed policy change to become policy - so you need to convince the RIPE community that it's of common interest to change this.
Since we're running out of addresses quickly, even if you succeed in changing the policy, the subnet containing 2.2.2.2 might already be handed out to someone else. So I wouldn't bet the success of my company on the chance of receiving 2.2.2.2 - you might succeed, but you might as well not.
All true. Still, there are other easy-to-remember blocks, like 2.3.4.0/24 or 2.22.22.0/24, and so on. Geoff Huston and George Michaelson at APNIC have been doing some research into what "interesting" addresses there are, since APNIC had the bad (?) luck to get allocated 1.0.0.0/8 recently. You can ask them for some hints as to what people tend to use. :) I note that there is some precedence for this kind of request, at least at ARIN (I hear AS42 was assigned when asked for, although I was not involved with this so it is just a rumor). As for actually getting the RIPE NCC to issue a resource based on a request... I think there are two ways to go about this. One is making it a POLICY matter, and going through the PDP and updating the relevant documents. The other is solving it PROCEDURALLY, which basically means convincing the RIPE NCC to accept special requests and handle them when possible. I generally think it is in everyone's best interest to keep the policies as simple as possible. I think it is especially in the RIPE NCC's interest to handle requests for specific resources procedurally and not have a policy, because if there is a policy then every new LIR will see this and of course they will look for "interesting" numbers to request, meaning lots of extra work for everyone involved. In summary: * I support allowing people to request specific unused resources * I hope that can be done without a policy change -- Shane
On 29 Mar 2010, at 12:35, Shane Kerr wrote:
* I support allowing people to request specific unused resources
Of course. Unused resources are there to be used.
* I hope that can be done without a policy change
By that I hope you don't mean that the NCC does some fancy footwork around the current policies to give an LIR the particular address block they want. It is extremely important now that we're in the end- game for IPv4 that the current non-discriminatory policies based on technical need are followed. If there is a new requirement for allocating the remaining resources -- eg vanity addresses -- that simply has to go through the policy making process. IMO it would be very unwise to tinker with these policies for non-technical reasons as IPv4 runs out. Very Bad Things will happen if the RIRs allocate resources in ways that violate our policies. Or there's a suggestion that the current rules are not being followed. Or a suspiciion that needs-based allocation no longer applies. Governments, regulators and competition authorities are going to be paying special attention to what RIRs do with the remaining IPv4 space. So it's essential that there's not even a hint of the RIRs treating allocation requests differently by applying criteria which are not part of the current policies. The week before last, the ITU had a meeting where they discussed the possibility of becoming an RIR. [Some of the motivations for that included "fairness towards developing countries", "reduced cost" and "addressing the imblance of IPv4 allocations." Sigh.] If the RIRs are suspected of bending their own policies, this will give ammunition to those who say that these Internet people are not to be trusted -- "See! They ignore their own rules/processes or make them up as they go along!" -- and it's time for the ITU to step in and provide adult supervision. As far as getting the block containing 2.2.2.2 goes, I think the way forward should be for the LIR to keep an eye out for when that block is about to be allocated, submit a template at the appropriate point and take their chances. IIUC this is what some folk have sort of done with AS numbers. I have heard of people who monitor the RIR databases and watch for "interesting" ASNs to be handed back. When such a number is returned to the RIR, they then submit a template for a new ASN and hope it gets allocated the one that was just returned.
Jim, On 2010-03-29 14:26, Jim Reid wrote:
On 29 Mar 2010, at 12:35, Shane Kerr wrote:
* I support allowing people to request specific unused resources
Of course. Unused resources are there to be used.
* I hope that can be done without a policy change
By that I hope you don't mean that the NCC does some fancy footwork around the current policies to give an LIR the particular address block they want. It is extremely important now that we're in the end-game for IPv4 that the current non-discriminatory policies based on technical need are followed. If there is a new requirement for allocating the remaining resources -- eg vanity addresses -- that simply has to go through the policy making process. IMO it would be very unwise to tinker with these policies for non-technical reasons as IPv4 runs out.
To be clear, we're not talking about anyone getting more or less address space, or allocating in a way that makes aggregation more difficult. I thought those were the two basic goals of IP allocation policy, right? The RIPE NCC does not have any restrictions on which particular resources it allocates or assigns. In fact, I am pretty sure that any sensible person would argue that the RIPE NCC should have as much freedom as possible to do things in the most efficient way. So I think the RIPE NCC already has the power to issue "vanity addresses" in the rare case where someone asks for these. Mostly I find it a pity that the NCC wasn't more accommodating and that we're having this discussion at all. Maybe the software used for this process does not have a manual override or something? Oh well, compared to the horror stories I hear about the bad old days, I guess we have no complaints.... In the end I suppose we can just let the addresses fall wherever and let "the market" sort it out, now that there is a "trading" policy. While the desire for vanity addresses might accelerate the process of IP addresses becoming property, that is probably inevitable, so it won't change the big picture too much. -- Shane
On 29 Mar 2010, at 14:48, Shane Kerr wrote:
To be clear, we're not talking about anyone getting more or less address space, or allocating in a way that makes aggregation more difficult. I thought those were the two basic goals of IP allocation policy, right?
I'm not sure Shane that an allocation of vanity addresses would fit with these goals. If it does, then fine. Though I'm doubtful. If there were "too many" vanity assignments, that may well fragment the unused space in a way that prevents another LIR getting a contiguous allocation that's big enough for their genuine technical needs. It might also encourage a land-grab by people gobbling up vanity space that they don't actually need in the hope that they could sell it on later.
On Mon, Mar 29, 2010 at 03:24:18PM +0100, Jim Reid wrote:
On 29 Mar 2010, at 14:48, Shane Kerr wrote:
To be clear, we're not talking about anyone getting more or less address space, or allocating in a way that makes aggregation more difficult. I thought those were the two basic goals of IP allocation policy, right?
I'm not sure Shane that an allocation of vanity addresses would fit with these goals. If it does, then fine. Though I'm doubtful. If there were "too many" vanity assignments, that may well fragment the unused space in a way that prevents another LIR getting a contiguous allocation that's big enough for their genuine technical needs. It might also encourage a land-grab by people gobbling up vanity space that they don't actually need in the hope that they could sell it on later.
to be clear, a "vanity" address is in the eye of the beholder. --bill
To be clear, we're not talking about anyone getting more or less address space, or allocating in a way that makes aggregation more difficult. I thought those were the two basic goals of IP allocation policy, right?
But it could lead to a less then optimal address distribution if somebody runs of with a vanity /24, leaving a bunch of smaller blocks for the poor fellow who can justify his /16. MarcoH
Now, there's of course a catch - the PDP takes a while to run through (a couple of months at best, some times much longer), and you need *consensus* for a proposed policy change to become policy - so you need to convince the RIPE community that it's of common interest to change this.
Thank you for the information about PDP. I guess the process will take much longer than we expected. Is it probable that an agreement could be reached regarding an assignment of a block of IP-addresses from the yet unallocated ranges? Has this question ever been raised before? For example, we’d like to get address 2.2.2.2 – but if a similar *easy to rmemeber address* is available from a allocatable space, we’ll be satisfied with that too. Should we send a request for a policy change or is it most likely not going to help reach a consensus?
Since we're running out of addresses quickly, even if you succeed in changing the policy, the subnet containing 2.2.2.2 might already be handed out to someone else. So I wouldn't bet the success of my company on the chance of receiving 2.2.2.2 - you might succeed, but you might as well not.
Ok, I see. Is it technically possible to get address 2.2.2.2 when this range 2.*.*.* becomes publicly available for assignment? -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz@idecogateway.com Web: www.idecogateway.com
On 29 Mar 2010, at 3:41, Sergey Gotsulyak wrote: [...]
Some days ago, I told Jaap Akkerhuis about allocation of 2.2.2.0/24 address space for our DNS-service and he advice me to contact this workgroup.
It may be worth noting that the RIPE NCC has already committed not to allocate prefixes longer than a /21 from 2.0.0.0/8. See: http://www.ripe.net/ripe/docs/ripe-479.html It appears that if you want an IPv4 prefix as long as a /24 from the RIPE NCC it will come from 91/8, 193/8 or 194/7. Regards, Leo Vegoda
Hello Sergey, Le 29/03/2010 11:41, Sergey Gotsulyak a écrit :
We have contacted RIPE NCC with a request to get a block of addresses 2.2.2.0/24, but were told that the standard procedure does not allow us to choose an address range.
Is it possible to modify current Address Policy?
I know this is not going to answer your question, but you're better off going for IPv6. :-) Modifying current address policy to add value (through simplicity) to IP addresses? Unlikely. It was designed the way it is today, specifically to avoid this and all its resulting head-aches. Warm regards, Olivier -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
Sergey Gotsulyak wrote:
For this project we?ll need an easy to remember IP-address, for example like the one for Google Public DNS service (8.8.8.8)
I'm afraid you typed wrong characters for "we'll", which is a problem, among many, of unicode Anyway, 4 byte addresses of IPv4 is not so bad to memorize. You are right, however, that IPv6 addresses are impossible to remember not only for end users but also for network operators, which is one of a reason why IPv6 is NOT deployable. The magic number for memory is 7. That is, one can easily remember 4 bytes and may be able to remember 8 bytes. However, it is virtually impossible to remember 16 bytes. That is, for fairness, IPv6 is unusable. Instead, everyone should be able to remember 4 byte IPv4 addresses and 2 byte short port numbers as was documented in <draft-ohta-e2e-nat-00.txt> When an ISP operate a NAT gateway, the ISP should, for fairness between customers, reserve some well know port numbers and assign small port numbers evenly to all the customers.
We have contacted RIPE NCC with a request to get a block of addresses 2.2.2.0/24, but were told that the standard procedure does not allow us to choose an address range.
Is it possible to modify current Address Policy?
You had better to abandone IPv6 and IPv6 address policies and just stick to IPv4 with A+P including, but not limited to, <draft-ohta-e2e-nat-00.txt>. Masataka Ohta
On 30.03.2010 14:37, Masataka Ohta wrote:
Sergey Gotsulyak wrote:
For this project we?ll need an easy to remember IP-address, for example like the one for Google Public DNS service (8.8.8.8)
I'm afraid you typed wrong characters for "we'll", which is a problem, among many, of unicode
Anyway, 4 byte addresses of IPv4 is not so bad to memorize.
You are right, however, that IPv6 addresses are impossible to remember not only for end users but also for network operators, which is one of a reason why IPv6 is NOT deployable.
Sorry, but you must be one sieve-brain (is there such a word in english?) of a network operator if you aren't able to remember your /32 prefix .. As for end users - end users do not have to remember ANY IPs ... that's what DHCP, DNS etc. are for, as well as (if necessary) documents given to end users when they sign up and receive their login information... or would you state that the initial setup information for a dial-up account (e.g. username/password) is shorter than some single IP-address (both v4 and v6)? Please stop spreading FUD about IPv6, just because _YOU_ are either incapable or unwilling to deploy IPv6 doesn't mean that the other currently >2000 prefix owners would prefer to wait another n years to see whether your RFC-draft would be implemented by one single vendor ...
The magic number for memory is 7. That is, one can easily remember 4 bytes and may be able to remember 8 bytes. However, it is virtually impossible to remember 16 bytes.
Let's see. "ipv6.google.com". Looks easy to remember to me. And my computer - what a surprise - automagically converts that to those "impossible" to remember numbers like 2a00:1450:8001::63. Just like that. Seems like at least the computer had no trouble at all remembering them ... Oh, and I have no trouble remembering the IPs for my mailserver ... both v4 and v6 ... along with several dozens of other v4 and v6 addresses for personal and customer servers, firewalls and routers that I need more or less ... as do many if not all of our tech staff ... and in case somebody may not remember a specific IP from time to time - that's what documentation is for ...
That is, for fairness, IPv6 is unusable.
for you, maybe. Now go home and play with your draft while the rest of the world goes ahead with technical progress ...
Instead, everyone should be able to remember 4 byte IPv4 addresses and 2 byte short port numbers as was documented in <draft-ohta-e2e-nat-00.txt>
Exactly. Because "www.site1.de:1234" and "www.site2.com:1324" and "www.site3.org:1243" are so d@mn easy to remember for the average-joe-enduser ... compared to impossible to remember "www.site1.de", "www.site2.com" and "www.site3.org", which unnoticed by the enduser are resolved to either IPv4 or IPv6 addresses and just simply work ... now tell me, what exactly does the end user gain from sticking with YAPOSNL? (yet another POS nat layer) -gg
Garry Glendown wrote:
Anyway, 4 byte addresses of IPv4 is not so bad to memorize.
You are right, however, that IPv6 addresses are impossible to remember not only for end users but also for network operators, which is one of a reason why IPv6 is NOT deployable.
Sorry, but you must be one sieve-brain (is there such a word in english?) of a network operator if you aren't able to remember your /32 prefix ..
So? Note that there is no guarantee that IPv6 prefix length is /32. The fact is that many, if not all, network operators can't remember IPv6 addresses, which is a major, among many, obstacle against IPv6.
Please stop spreading FUD about IPv6, just because _YOU_ are either incapable or unwilling to deploy IPv6 doesn't mean that the other currently >2000 prefix owners would prefer to wait another n years to see whether your RFC-draft would be implemented by one single vendor ...
2000 prefixes in some private network 15 years after rfc1883??? No, my interest is on >300000 prefixes routed over the real internet.
Let's see. "ipv6.google.com". Looks easy to remember to me.
I'm not talking about end users.
Instead, everyone should be able to remember 4 byte IPv4 addresses and 2 byte short port numbers as was documented in <draft-ohta-e2e-nat-00.txt>
Exactly. Because "www.site1.de:1234" and "www.site2.com:1324" and "www.site3.org:1243" are so d@mn easy to remember for the average-joe-enduser ...
Exactly, which is why my draft says: assign small port numbers evenly to all the customers. Read it. A user may be assined ports 100, 199, 298, ... while another user may be assigned ports 101, 200, 299, ...
compared to impossible to remember "www.site1.de", "www.site2.com" and "www.site3.org", which unnoticed by the enduser are resolved to either IPv4 or IPv6 addresses and just simply work ...
Let DNS map from domain names to 6 byte address+port is no more difficult than to let DNS map from domain names to IPv6 address.
now tell me, what exactly does the end user gain from sticking with YAPOSNL? (yet another POS nat layer)
End to end transparency. Masataka Ohta
Hi, can we please stop this thread? Whether or not IPv6 addresses are easier to remember than IPv4 addresses or not is NOT RELEVANT to address policy, and as such, completely off-topic here. Masaka, may I suggest you go and post to nanog, or some other place where IPv6<->IPv4 advocacy is commonplace? List, please stop feeding the troll. We have more important work to do. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi, On Wed, Mar 31, 2010 at 09:06:08PM +0900, Masataka Ohta wrote:
Gert Doering wrote:
Masaka, may I suggest you go and post to nanog, or some other place where IPv6<->IPv4 advocacy is commonplace?
Do you mean some other place not censored by IPv6 fundamentalists?
This list is here to decide on the rules for handling out numbers to members of the RIPE NCC and to end users in the RIPE service region (= "address policy"). Address policy for IPv4 addresses, for IPv6 addresses, and for AS numbers is on-topic - and all discussions that have direct implications on policy. It is *NOT* the right place to discuss whether IPv4 or IPv6 is "better". Feel free to voice anything that you concern relevant to *address policy* - but the question or not "IPv6 sucks because you don't want to use DNS" is completely irrelevant to the rules of responsible stewardship for limited resources. Which *this* list is about. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 150584 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Actually it is quite possible to memorize IPv6 addresses - break it into two pieces (say, perhaps, network and host). Especially when the high-order side of your address is fairly static ... although obviously this becomes less easy when some portion was randomly chosen, but those addresses aren't usually the ones you need to memorize. And I didn't realize "memorizability" was a key design criteria for a network protocol - if only we had some way of converting words into those oh-so-hard-to-remember numbers ... /TJ *And with continued deployment advances from Google, Microsoft, NetFlix, Comcast, Verizon Wireless, certain US DoD Components, etc. etc. ... overall, it is looking like a good year for IPv6 :).* On Tue, Mar 30, 2010 at 08:37, Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote:
Sergey Gotsulyak wrote:
For this project we?ll need an easy to remember IP-address, for example like the one for Google Public DNS service (8.8.8.8)
I'm afraid you typed wrong characters for "we'll", which is a problem, among many, of unicode
Anyway, 4 byte addresses of IPv4 is not so bad to memorize.
You are right, however, that IPv6 addresses are impossible to remember not only for end users but also for network operators, which is one of a reason why IPv6 is NOT deployable.
The magic number for memory is 7. That is, one can easily remember 4 bytes and may be able to remember 8 bytes. However, it is virtually impossible to remember 16 bytes.
That is, for fairness, IPv6 is unusable.
Instead, everyone should be able to remember 4 byte IPv4 addresses and 2 byte short port numbers as was documented in <draft-ohta-e2e-nat-00.txt>
When an ISP operate a NAT gateway, the ISP should, for fairness between customers, reserve some well know port numbers and assign small port numbers evenly to all the customers.
We have contacted RIPE NCC with a request to get a block of addresses 2.2.2.0/24, but were told that the standard procedure does not allow us to choose an address range.
Is it possible to modify current Address Policy?
You had better to abandone IPv6 and IPv6 address policies and just stick to IPv4 with A+P including, but not limited to, <draft-ohta-e2e-nat-00.txt>.
Masataka Ohta
-- /TJ
* mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) [Tue 30 Mar 2010, 14:45 CEST]:
Sergey Gotsulyak wrote:
For this project we?ll need an easy to remember IP-address, for example like the one for Google Public DNS service (8.8.8.8)
I'm afraid you typed wrong characters for "we'll", which is a problem, among many, of unicode
He didn't write in Unicode but used a Microsoft-proprietary character set wrapped in a layer of quoted-unprintable. Get a fucking clue and learn to read mail headers before you run your mouth again.
The magic number for memory is 7. That is, one can easily remember 4 bytes and may be able to remember 8 bytes. However, it is virtually impossible to remember 16 bytes.
Wow, doing shopping must be such a hardship for you. The only way you survive must be by doing separate trips to the mall for breakfast and dinner each day. -- Niels. --
participants (13)
-
bmanning＠vacation.karoshi.com -
Garry Glendown -
Gert Doering -
Jim Reid -
Leo Vegoda -
Marco Hogewoning -
Masataka Ohta -
niels=apwg＠bakker.net -
Olivier MJ Crepin-Leblond -
Sascha Lenz -
Sergey Gotsulyak -
Shane Kerr -
TJ