View Issue Details

IDProjectCategoryView StatusLast Update
0002107unrealircdpublic2004-11-28 13:05
ReporterNeo-Vortex Assigned Tocodemastr 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformi386OSFreeBSDOS Version5.2.1-RELEASE
Product Version3.2.1 
Fixed in Version3.2.3 
Summary0002107: IPv6 Numeric IPs not in compressed form
Descriptionaddresses 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 Reproduceconnect to an ipv6-enabled unreal server using ipv6 with no reverse dns and atleast one 16-bit group of of zeros
Additional Informationcheck rfc2373 for information about Text Representation of IPv6 Addresses
TagsNo tags attached.
3rd party modules

Activities

Neo-Vortex

2004-10-03 10:05

reporter   ~0007858

arrr, missed the category bit... supposed to be under ircd... cant edit it either :(

codemastr

2004-10-03 17:17

reporter   ~0007865

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.)

Neo-Vortex

2004-10-04 10:35

reporter   ~0007868

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...

codemastr

2004-10-04 17:53

reporter   ~0007873

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.

Neo-Vortex

2004-10-05 07:36

reporter   ~0007877

Last edited: 2004-10-05 07:37

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

codemastr

2004-10-05 19:18

reporter   ~0007879

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.

aquanight

2004-10-06 00:15

reporter   ~0007883

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?

Neo-Vortex

2004-10-07 06:35

reporter   ~0007898

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...

al5001

2004-10-08 06:59

reporter   ~0007912

Last edited: 2004-10-08 07:01

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

Neo-Vortex

2004-10-08 07:11

reporter   ~0007914

i'd have to say the manual is better than a help chan... dam lazy people...

anyway, forgot about how cidr was implimented :P

codemastr

2004-10-08 14:24

reporter   ~0007919

[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.

al5001

2004-10-09 00:33

reporter   ~0007926

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.

codemastr

2004-10-09 03:18

reporter   ~0007927

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.

Neo-Vortex

2004-10-09 03:25

reporter   ~0007928

Last edited: 2004-10-09 03:26

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

al5001

2004-10-12 04:30

reporter   ~0007984

Last edited: 2004-10-12 04:39

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

aquanight

2004-10-12 04:44

reporter   ~0007985

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.

al5001

2004-10-12 04:56

reporter   ~0007987

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...

codemastr

2004-10-12 17:58

reporter   ~0007990

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.

al5001

2004-10-13 01:55

reporter   ~0007993

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.

codemastr

2004-10-13 02:16

reporter   ~0007994

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.

al5001

2004-10-14 06:10

reporter   ~0008002

Last edited: 2004-10-14 06:23

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

Neo-Vortex

2004-10-14 08:14

reporter   ~0008003

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...)

vonitsanet

2004-10-14 10:08

reporter   ~0008004

Last edited: 2004-10-14 10:10

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

codemastr

2004-10-14 20:24

reporter   ~0008005

[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.

al5001

2004-10-17 16:48

reporter   ~0008033

Last edited: 2004-10-17 16:49

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

aquanight

2004-10-17 23:32

reporter   ~0008034

Last edited: 2004-10-17 23:33

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

al5001

2004-10-18 23:44

reporter   ~0008040

Last edited: 2004-10-18 23:53

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

aquanight

2004-10-19 11:46

reporter   ~0008041

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.

codemastr

2004-10-19 17:12

reporter   ~0008042

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.

codemastr

2004-10-20 14:02

reporter   ~0008052

Thanks to everyone who continued to post about CIDR even though I said NOT to post about CIDR!

aquanight

2004-10-20 19:07

reporter   ~0008054

[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...

codemastr

2004-10-21 15:41

reporter   ~0008058

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.

aquanight

2004-10-21 15:48

reporter   ~0008059

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.

codemastr

2004-10-22 15:23

reporter   ~0008062

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.

aquanight

2004-10-29 15:30

reporter   ~0008176

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...

codemastr

2004-10-29 15:50

reporter   ~0008177

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]

codemastr

2004-11-28 13:05

reporter   ~0008424

I added a #define IPV6_COMPRESSED in config.h in .197

Issue History

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 codemastr Note Added: 0007865
2004-10-04 10:35 Neo-Vortex Note Added: 0007868
2004-10-04 17:53 codemastr 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 codemastr 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 codemastr Note Added: 0007919
2004-10-09 00:33 al5001 Note Added: 0007926
2004-10-09 03:18 codemastr 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 codemastr Note Added: 0007990
2004-10-13 01:55 al5001 Note Added: 0007993
2004-10-13 02:16 codemastr 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 codemastr 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 codemastr Note Added: 0008042
2004-10-20 14:02 codemastr Note Added: 0008052
2004-10-20 19:07 aquanight Note Added: 0008054
2004-10-21 15:41 codemastr Note Added: 0008058
2004-10-21 15:48 aquanight Note Added: 0008059
2004-10-22 15:23 codemastr Note Added: 0008062
2004-10-29 15:13 codemastr Status new => assigned
2004-10-29 15:13 codemastr Assigned To => codemastr
2004-10-29 15:30 aquanight Note Added: 0008176
2004-10-29 15:50 codemastr Note Added: 0008177
2004-11-28 13:05 codemastr Status assigned => resolved
2004-11-28 13:05 codemastr Fixed in Version => 3.2.3
2004-11-28 13:05 codemastr Resolution open => fixed
2004-11-28 13:05 codemastr Note Added: 0008424
2004-11-28 13:05 codemastr Category documentation => ircd