View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002107 | unreal | ircd | public | 2004-10-03 09:48 | 2004-11-28 13:05 |
| Reporter | Neo-Vortex | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | i386 | OS | FreeBSD | OS Version | 5.2.1-RELEASE |
| Product Version | 3.2.1 | ||||
| Fixed in Version | 3.2.3 | ||||
| Summary | 0002107: IPv6 Numeric IPs not in compressed form | ||||
| Description | addresses such as 2001:db0:10e2:1::1 are represented as 2001:db0:10e2:1:0:0:0:1 which is annoying to read | ||||
| Steps To Reproduce | connect to an ipv6-enabled unreal server using ipv6 with no reverse dns and atleast one 16-bit group of of zeros | ||||
| Additional Information | check rfc2373 for information about Text Representation of IPv6 Addresses | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
arrr, missed the category bit... supposed to be under ircd... cant edit it either :( |
|
|
This isn't a bug, this is how we designed it. We purposely wrote a function to add the 0's in! I don't really see what is "annoying" about this. To me, the :: notation is one of the worst readability features ever added. It makes determining the length of an IPv6 harder than it need be. It also would make bans more difficult on IRC. Most people have no idea what IPv6 is. So user@2001:db0:10e2:1:: joins. And needs to be banned. The op sets, +b user@2001:db0:10e2:1:*. Now, he only saw that "1" there so he figures, just like with v4, he's only banning the last section of the IP. However, little does he know, he's just banned several billion IPs! It would lead to more confusion and annoyances if we changed it than if we didn't. Also, to my knowledge, every IRCd shows the fully expanded IP, so I don't see why we should be different. That would lead to further confusion (on EFnet it does A and on Unreal it does B, etc.) |
|
|
EFnet does it 2001:db0:10e2:1::1 203438 -!- Neo-Vorte [Neo-Vortex@2001:db0:10e2:1::1] 203438 -!- ircname : Neo-Vortex 203439 -!- channels : #port- #windowsxp #irc6 #ipv6 #knoppix #FreeBSDHelp 203439 -!- server : efnet.ipv6.xs4all.nl [open your eyes - IPv6!] 203439 -!- idle : 0 days 0 hours 11 mins 58 secs [signon: Mon Oct 4 15:44:57 2004] 203439 -!- End of WHOIS so as you said... more confusion... |
|
|
Well regardless, I'm not changing it. I get confused by the :: notation, and I'm familiar with IPv6. I don't expect someone who has never seen IPv6 before to have any clue what it means. It would ruin backwards compatibility, cause desync until all servers are updated, and it would cause confusion because people wouldn't understand :: nor why things suddenly changed. As I said, it wasn't an accident that it was done this way, we purposely did it. And you really haven't given any reason why it should be changed other than you find it "annoying." Well I find the compressed format annoying, so whether it is/isn't annoying is not a good enough reason. |
|
|
ok, what about something in config.h to change it? that would be fine by me (and anyone else who wants it like that) i would to it myself... but editing is unsupported... *shifty eyes*... ok, i havnt looked close enough... there, happy? :P that and for other people too... edited on: 2004-10-05 07:37 |
|
|
I would not mind having a config.h option for it. I'd have to see exactly what that would involve though, I'm not too familiar with our IPv6 code. But it would be important to note that you would need to have this option set the same on all servers, otherwise bans will be ineffective. |
|
|
We have 3 unused fields in NETINFO, could one of those (or maybe just a compile version flag sent in the VL info - better this way so we can use deny version {} :P ) be used so that a/the server can spew out a warning in case of a mismatch? |
|
|
oh, another thing to note, banning a whole /48 isnt much of a problem because most people have /48's or /64's anyway... (and if its a 64, i can gurantee you its not going to have only three blocks then ::, so it wouldnt ban the /48, only a /64, if they didnt, they can just change their ip cause they have so many...) also, mabe make the ban check for both compressed, and uncompressed forms reguardless of the setting, because some people who do know ipv6 may only want to ban a /80 or something which would be impossible if it only checked for the compressed form when its enabled... and same for people who want to use :: when compressed form is disabled for bans... (just like using ip bans, hostname bans, and cloaked hostname bans) as for being able to read it... most people ive talked to find compressed form easier to read... |
|
|
user@2001:db0:10e2:1:: Just use CIDR :P user@2001:db0:10e2:1::/128 Or ban like this user@2001:db0:10e2:1:: I really don't see any problem with having the IPs compressed... and if an op doesn't know what CIDR is, that's exactly what the manual is for, better yet, help channels. I rather dislike how unreal compresses the addresses though (2001:db0:10e2:1:0:0:0:0). Either the address should be fully compressed (2001:db0:10e2:1::) as is in RFC2373, or use the full form (2001:0db0:10e2:0001:0000:0000:0000:0000), as not to confuse people with different ways of the compressed forms. edited on: 2004-10-08 07:01 |
|
|
i'd have to say the manual is better than a help chan... dam lazy people... anyway, forgot about how cidr was implimented :P |
|
|
[quote]I really don't see any problem with having the IPs compressed... and if an op doesn't know what CIDR is, that's exactly what the manual is for, better yet, help channels.[/quote] That's nice, except +b and +e do not support CIDR. [quote]I rather dislike how unreal compresses the addresses though (2001:db0:10e2:1:0:0:0:0). Either the address should be fully compressed (2001:db0:10e2:1::) as is in RFC2373, or use the full form (2001:0db0:10e2:0001:0000:0000:0000:0000), as not to confuse people with different ways of the compressed forms.[/quote] All your method serves to do is waste memory. It's been a while since I took a math class, but I'm pretty sure just about everyone who is using IRC is smart enough to know that 01 is the same as 1. Knowing that :: is the same as a series of 0's, however, that's not something they are likely to know. And since you referred to RFC2373, allow me to quote it: "The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal values of the eight 16-bit pieces of the address. Note that it is not necessary to write the leading zeros in an individual field" The method we are using is the "preferred" text representation for IPv6 addresses. So if we're using the recommended method, I don't see how that is going to confuse people. |
|
|
I don't see how it uses more memory really... /* pasted from Unreal3.2/include/struct.h version 1.1.1.1.2.16 */ #define HOSTLEN 63 /* Length of hostname. Updated to */ /* comply with RFC1123 * char sockhost[HOSTLEN + 1]; /* This is the host name from the socket ** and after which the connection was ** accepted. */ Now, wouldn't sockhost be using 64*sizeof(char) of memory? Would filling the whole string with \0's make it use less memory? I'm a bit confused, but help me out here, I could be wrong. |
|
|
al5001, you're absolutely correct, the memory used by sockhost would not be affected. But now go look at the char *ip_str. That is allocated using malloc. Therefore, doing 0000 instead of 0 means we're allocating 4 bytes rather than 1. So for ip_str it will use more memory. |
|
|
so...? its a yes then? Edit: on a side note codemastr, can you go on irc? i need to ask you something... edited on: 2004-10-09 03:26 |
|
|
Ahh, but using malloc would waste more space for ip_str... why not just point it to sockhost? Something like ip_str = &sockhost; printf("%s", *ip_str); well.. just an example, but something like that edited on: 2004-10-12 04:39 |
|
|
I could be wrong, but I think the problem there is, sockhost could be used to store a hostname. IPv6 addresses can be resolved to DNS Hostnames just as good as IPv4 address can. |
|
|
Ah yes, you could be right about that, I never thought of it; DNS never crossed my mind. I was thinking sockhost held the IP and ip_str just printed info from sockhost... Perhaps though, totally compressed addresses are still fine. I mean, all IPv6 addresses have to have 8 octets, so like if you see beef::, it's automatically beef:0000:0000:0000:0000:0000:0000:0000... if you guys know what I mean...I don't see the purpose to store beef:0:0:0:0:0:0:0 when there is no need really... |
|
|
al5001, what you're saying is irrelevant. Of course the compressed form is legal for representing an IPv6. No one is disputing that (anyone who did would be a fool). What I am saying is compressed IPs make +b ambiguous. |
|
|
I see what you mean now, but I believe IRC clients should start changing to support CIDR bans... instead of adding a * on the end.. When it happens, it may be a good idea to use the fully compressed form, but for now, the :0:0:0 is good enough to allow clients to do :0:0:*, as opposed to ::* which could ban a pretty big prefix. |
|
|
Clients can't use CIDR bans because Unreal doesn't support CIDR bans! In fact, no IRCds do, at least not by default. So I doubt clients will be switching to CIDR soon. And even if every IRCd did support CIDR bans, I still doubt it would catch on. Most IRC users have no need to know what CIDR is. When they see such bans, it will likely lead to more confusion. |
|
|
Clients can't use CIDR bans because Unreal doesn't support CIDR bans! In fact, no IRCds do, at least not by default. So I doubt clients will be switching to CIDR soon. And even if every IRCd did support CIDR bans, I still doubt it would catch on. Most IRC users have no need to know what CIDR is. When they see such bans, it will likely lead to more confusion. Uhh... Hybrid supports CIDR in everything. +e +b +I bans everything. My ircd is based on hybrid and has tons more features than hybrid now, and even my ircd supports CIDR bans (my ircd isn't up for full public release yet). It also supports fully compressed IPs. Even unreal's CIDR code looks almost alike the hybrid's CIDR code. And unreal's ipv6 code looks pretty close to dancer ircd's ipv6 code. Not sure if it's a coincidence or not...but :P By the way, confusion is cured by reading the manual. edited on: 2004-10-14 06:23 |
|
|
ok, back to the point, config.h option... second point, whoop de do if they ban a whole /48 (6.6680144328798542740798517907213e+240 IPs), does it matter? most tb's allocate private /48's to people anyway... and if they allocated /64's there would be another 16 bits significant on the prefix (ie, not all 0x0), so you wouldnt ban a /48, you would ban a /64... and if your using the endpoint ip instead of one from your allocation (god knows why...) then A) use ipv4, B) use one from your ipv6 ip, or C) msg an op and tell them the situation... also, if they did only ban a /112 (which is if you ban everything except the last segment), then you could easily evade the ban by using another ip from your allocation, and if its a shared prefix (ie, tunnel endpoints), chances are (because every tb ive checked out does it this way) your still going to ban all the people from it because they only use the last 16 bits for allocations (as for there isnt a need to use more untill they get more users than those 16 bits can provide, and if they are that large, then your still banning half or a third of their users (even though i cant think of any that large...) |
|
|
About CIDR.. I remember that when CIDR support was added for K/Glines codemastr said that he will wait to see if it was stable and then he will add this for bans too ( (http://bugs.unrealircd.org/view.php?id=1296). I think it's stable.. edited on: 2004-10-14 10:10 |
|
|
[quote]Uhh... Hybrid supports CIDR in everything[/quote] Check Hybrid 7.1, you'll now see that CIDR support in +b/+e is optional. [quote]I think it's stable..[/quote] You think it's stable because you are judging from your experiences. I have to look at more than just your server. I have to look at Unreal as a whole. There were still some bugs in the CIDR code. I fixed 2-3 bugs since 3.2.1 was released. If I had added support in +b, it would have resulted in problems (some bans would not have worked). It's stable when I'm sure that it can't crash. Have you tried giving it all kinds of strange masks? Doing things like ::*::/23*.::*/200 to make sure it doesn't crash? I doubt it. Well, a guy who wants to crash your server will try such ban masks. And, if somehow there is a case we didn't check for, now they can crash your server. I'd like to try to avoid that if possible. |
|
|
Well people will have to learn to stop using * with CIDR bans. There's no need to use * in a CIDR host/ip ban unless you're using it on the left side of the @, as in *@192.168.0.0/16, which would be the same as *@192.168.* edited on: 2004-10-17 16:49 |
|
|
True, but people probably will try to use * or ? in CIDR IPs. What should Unreal do? Reject the ban? Maybe interpret in some odd way? Crash (NOT what code wants :P)? Mixing wildcards and CIDR is certainly something someone (especially not-so-nice people) will try. Eg, what should Unreal do for *@23?.17.*/16 ? Ban all *.17 B blocks in the 230-239 A range? Reject the ban? And what about misnomers like 192.168.122.196/24 ? You can garuntee these are things that need to be handled, or coders got a ton of angry admins on their hands :P . *edit* Get my nonroutable IPs right :-/ */edit* edited on: 2004-10-17 23:33 |
|
|
Well, there should be * allowed for backwards compatibility, but if a / is encountered in the ban, then disallow a * after the @. I don't believe this would be hard to implement. For the other part, there really shouldn't be a char limit for CIDR bans. Think about this: *!*@aol.com/24. Well, if the ircd checks round robins... it would affect all IPs in the RR. :P Edit: this is more of a dream though, cause this round robin thing would never work on unreal... edited on: 2004-10-18 23:53 |
|
|
Right, but the point is, what should Unreal do for such an invalid mask? Yes, it's probably going to validate it, but what should happen if the mask doesn't pass? And how will something like ~q/~n handle it (they need to be the same for it to work like some would expect). You can garuntee someone will attempt to +b *!*@127.0.*/8 or something similar. What should Unreal do? IIRC, for nonexistant extbans I think it does nothing. Absolutely nothing, no +b sent, no ban added, no error message. Should it be the same for CIDR/Wildcard mixing? I'm starting to wonder what this has to do with IPv6... though CIDR stuff does apply to that to... 1234:5678:90AB:*:1234:????:90AB:CDEF/45 ... And finally for something related to the original bug, how does unreal display the IP6<->IP4 address (::ffff:I.P.v.4) ? as 0:0:0:0:0:0:0:ffff:I.P.v.4 (which is kinda pointless really...)? Because if an op baned ::ffff:192.168.* ... I don't think there's gonna be problems with compressed vs. uncompressed there. |
|
|
al5001, you couldn't be more wrong about CIDR. * IS a necessity. Please show me the CIDR mask that would let me do 123.*.123.123 you can't, because there isn't one. Please show me the CIDR mask that replaces 123.123.123.12* you can't, because there isn't one. Then you say aol.com/24??? WHAT?? CIDR is for IPs, it has *nothing* to do with hosts. And to aquanight, Unreal will display the IPv4 in the way IPv4's are displayed, a.b.c.d, it does not use a v6 mapped representation. Doing so would break things. I.e., an IPv6 server is linked to a v4. If it shows ::ffff:1.2.3.4 on IPv6 server, and 1.2.3.4 on the v4 server, we've got a serious problem with desync. In any case, if no one has anymore comments on the original compression suggestion, then I'm going to plan this for probably 3.2.3 as an #ifdef. If people want to continue to talk about CIDR bans, then create a new bug post because it has very little to do with this. |
|
|
Thanks to everyone who continued to post about CIDR even though I said NOT to post about CIDR! |
|
|
[quote]Unreal will display the IPv4 in the way IPv4's are displayed, a.b.c.d, it does not use a v6 mapped representation. Doing so would break things. I.e., an IPv6 server is linked to a v4. If it shows ::ffff:1.2.3.4 on IPv6 server, and 1.2.3.4 on the v4 server, we've got a serious problem with desync.[/quote] I'm still a bit confused as to what you mean by this... IIRC, the client's local server is what sets the IP address... then again, I think NICKIP sends the IP in binary form b64'd, so maybe that causes what you're describing, but I dunno... |
|
|
You're right, NICKIP does that. However, what about unresolved hostnames? They are sent as text strings. So that will cause desync. ServerA says ::1, serverB says 0:0:0:0:0:0:0:1. The ban doesn't match. |
|
|
Right, because of course the user could reconnect to a different server. Hence why the setting needs to be homogenous across a network, like netname/cloakkeys/etc. But of course, if I'm on ServerA, all servers should show my host as ::1 since it's ServerA that's telling everyone else about my hostname. Only if I quit and reconnect to ServerB does it become something different. In which case, it's the server admins' faults for not agreeing on the setting :P . So, I believe I mentioned earlier about using some kind of compile flag / NETINFO field or something so that servers can raise a big stink when there's a mismatch :P . Like how it does with mismatched cloak keys, et al. |
|
|
My point is it *can't* be homogeneous because on an IPv4 only server it would be stupid and wrong to make it send ::ffff:1.2.3.4. |
|
|
Well, for IPv4 servers, it won't matter. They should never have to deal with IPv6 addresses simply because they don't support IPv6 :P . What I'm saying is two (or more) IPv6 servers on the same net need to have the option set the same. For IPv4 this whole "::1 or 0:0:0:0:0:0:0:1?" issue doesn't even apply... |
|
|
I don't know what you are talking about, but I was referring to: [quote]And finally for something related to the original bug, how does unreal display the IP6<->IP4 address (::ffff:I.P.v.4) ? as 0:0:0:0:0:0:0:ffff:I.P.v.4 (which is kinda pointless really...)? Because if an op baned ::ffff:192.168.* ... I don't think there's gonna be problems with compressed vs. uncompressed there.[/quote] |
|
|
I added a #define IPV6_COMPRESSED in config.h in .197 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-10-03 09:48 | Neo-Vortex | New Issue | |
| 2004-10-03 10:05 | Neo-Vortex | Note Added: 0007858 | |
| 2004-10-03 17:17 |
|
Note Added: 0007865 | |
| 2004-10-04 10:35 | Neo-Vortex | Note Added: 0007868 | |
| 2004-10-04 17:53 |
|
Note Added: 0007873 | |
| 2004-10-05 07:36 | Neo-Vortex | Note Added: 0007877 | |
| 2004-10-05 07:37 | Neo-Vortex | Note Edited: 0007877 | |
| 2004-10-05 19:18 |
|
Note Added: 0007879 | |
| 2004-10-06 00:15 | aquanight | Note Added: 0007883 | |
| 2004-10-07 06:35 | Neo-Vortex | Note Added: 0007898 | |
| 2004-10-08 06:59 | al5001 | Note Added: 0007912 | |
| 2004-10-08 07:01 | al5001 | Note Edited: 0007912 | |
| 2004-10-08 07:11 | Neo-Vortex | Note Added: 0007914 | |
| 2004-10-08 14:24 |
|
Note Added: 0007919 | |
| 2004-10-09 00:33 | al5001 | Note Added: 0007926 | |
| 2004-10-09 03:18 |
|
Note Added: 0007927 | |
| 2004-10-09 03:25 | Neo-Vortex | Note Added: 0007928 | |
| 2004-10-09 03:26 | Neo-Vortex | Note Edited: 0007928 | |
| 2004-10-12 04:30 | al5001 | Note Added: 0007984 | |
| 2004-10-12 04:32 | al5001 | Note Edited: 0007984 | |
| 2004-10-12 04:35 | al5001 | Note Edited: 0007984 | |
| 2004-10-12 04:39 | al5001 | Note Edited: 0007984 | |
| 2004-10-12 04:39 | al5001 | Note Edited: 0007984 | |
| 2004-10-12 04:44 | aquanight | Note Added: 0007985 | |
| 2004-10-12 04:56 | al5001 | Note Added: 0007987 | |
| 2004-10-12 17:58 |
|
Note Added: 0007990 | |
| 2004-10-13 01:55 | al5001 | Note Added: 0007993 | |
| 2004-10-13 02:16 |
|
Note Added: 0007994 | |
| 2004-10-14 06:10 | al5001 | Note Added: 0008002 | |
| 2004-10-14 06:11 | al5001 | Note Edited: 0008002 | |
| 2004-10-14 06:13 | al5001 | Note Edited: 0008002 | |
| 2004-10-14 06:16 | al5001 | Note Edited: 0008002 | |
| 2004-10-14 06:16 | al5001 | Note Edited: 0008002 | |
| 2004-10-14 06:16 | al5001 | Note Edited: 0008002 | |
| 2004-10-14 06:20 | al5001 | Note Edited: 0008002 | |
| 2004-10-14 06:20 | al5001 | Note Edited: 0008002 | |
| 2004-10-14 06:23 | al5001 | Note Edited: 0008002 | |
| 2004-10-14 08:14 | Neo-Vortex | Note Added: 0008003 | |
| 2004-10-14 10:08 | vonitsanet | Note Added: 0008004 | |
| 2004-10-14 10:10 | vonitsanet | Note Edited: 0008004 | |
| 2004-10-14 20:24 |
|
Note Added: 0008005 | |
| 2004-10-17 16:48 | al5001 | Note Added: 0008033 | |
| 2004-10-17 16:49 | al5001 | Note Edited: 0008033 | |
| 2004-10-17 23:32 | aquanight | Note Added: 0008034 | |
| 2004-10-17 23:33 | aquanight | Note Edited: 0008034 | |
| 2004-10-18 23:44 | al5001 | Note Added: 0008040 | |
| 2004-10-18 23:48 | al5001 | Note Edited: 0008040 | |
| 2004-10-18 23:50 | al5001 | Note Edited: 0008040 | |
| 2004-10-18 23:51 | al5001 | Note Edited: 0008040 | |
| 2004-10-18 23:53 | al5001 | Note Edited: 0008040 | |
| 2004-10-19 11:46 | aquanight | Note Added: 0008041 | |
| 2004-10-19 17:12 |
|
Note Added: 0008042 | |
| 2004-10-20 14:02 |
|
Note Added: 0008052 | |
| 2004-10-20 19:07 | aquanight | Note Added: 0008054 | |
| 2004-10-21 15:41 |
|
Note Added: 0008058 | |
| 2004-10-21 15:48 | aquanight | Note Added: 0008059 | |
| 2004-10-22 15:23 |
|
Note Added: 0008062 | |
| 2004-10-29 15:13 |
|
Status | new => assigned |
| 2004-10-29 15:13 |
|
Assigned To | => codemastr |
| 2004-10-29 15:30 | aquanight | Note Added: 0008176 | |
| 2004-10-29 15:50 |
|
Note Added: 0008177 | |
| 2004-11-28 13:05 |
|
Status | assigned => resolved |
| 2004-11-28 13:05 |
|
Fixed in Version | => 3.2.3 |
| 2004-11-28 13:05 |
|
Resolution | open => fixed |
| 2004-11-28 13:05 |
|
Note Added: 0008424 | |
| 2004-11-28 13:05 |
|
Category | documentation => ircd |
