So there's been a lot of buzz lately over IPv6 now that the IPv4 allocations are run dry. A couple of people have asked in passing if there's anything special MUDs need to do in order to support it. I haven't looked into it and don't know for sure if there is but I suspect it's not some trivial flag somewhere in the port binding that needs to be set.

So anyone have any idea what's needed? It won't be terribly long before this needs to be thought about more seriously and it's probably better to jump ahead of it that be caught blind later.

Dealing with the connection itself isn't a big deal, however anything that maintains data about IP addresses will need some rewriting. This goes from assumptions about fixed length (an IPv4 address is, at most, 16 bytes, xxx.xxx.xxx.xxx\0 ). Any ban code that allows banning of CIDR subnets (127.0.0.0/8) will need rewriting.

I have yet to hear of anyone being on an IPv6 address that doesn't map directly to an IPv4 address, so I wouldn't exactly lose sleep over it yet. I consider it to be in the same category as global warming, or chicken little.

Heh. I don't know about it being quite the false crisis as global warming or chicken little, because the IANA has in fact run out of allocatable blocks. This isn't a Y2K thing where they make a bunch of hype that turns out to be entirely unwarranted. I grant that right now it's not terribly important but it seems more prudent to make plans while there's still some wiggle room in the timeline.

Getting a working test bed that has access to IPv6 capability is the only real obstacle I can see right now.

This came up somewhere else too (can't remember where), but I do recall someone saying the "Dawn of Time" codebase was IPv6 compatible. That might be a reasonable place to start, as it's also a dikurivative and should have enough in common to figure out.

If true, of course.

Of course, Linode seems to be taking steps in this direction now, so I guess we'll see. Maybe I should have chosen the Fremont site instead of Dallas

I'll check into Dawn of Time too. Wasn't aware someone else had already done this.

Desc| Constate |Idle| Player | HostIP
----+-------------------+----+--------------+--------------------------
6| Playing | 0| Admin | fe80::ac0d:5d:fd9d:96c8


that was actually pretty easy... all the ban code and stuff seems to just use strings.

sam@shiny-dev:~/smaugfuss19/src$ diff comm.c /home/sam/original/smaugfuss19/src/comm.c
564c564
<    struct sockaddr_in6 sa;
---
>    struct sockaddr_in sa;
568c568
<    if( ( fd = socket( AF_INET6, SOCK_STREAM, 0 ) ) < 0 )
---
>    if( ( fd = socket( AF_INET, SOCK_STREAM, 0 ) ) < 0 )
598,599c598,599
<    sa.sin6_family = AF_INET6;
<    sa.sin6_port = htons( mudport );
---
>    sa.sin_family = AF_INET;
>    sa.sin_port = htons( mudport );
830a831,836
>             /*
>              * check for input from the dns
>              */
>             if( ( d->connected == CON_PLAYING || d->character != NULL ) && d->ifd != -1 && FD_ISSET( d->ifd, &in_set ) )
>                process_dns( d );
>
971c977
<    struct sockaddr_in6 sock;
---
>    struct sockaddr_in sock;
1028c1034
<    dnew->port = ntohs( sock.sin6_port );
---
>    dnew->port = ntohs( sock.sin_port );
1037,1040c1043,1044
<
<       char line[100];
<    // mudstrlcpy( log_buf, inet_ntoa( sock.sin_addr ), MAX_STRING_LENGTH );
<    mudstrlcpy( log_buf, inet_ntop( AF_INET6, &sock.sin6_addr, line, sizeof line ), sock.sin6_port );
---
>
>    mudstrlcpy( log_buf, inet_ntoa( sock.sin_addr ), MAX_STRING_LENGTH );
1044,1061c1048,1056
<
<
<         struct addrinfo *ai;
<         struct addrinfo hints;
<         memset( &hints, '\0', sizeof hints );
<         hints.ai_flags  = AI_PASSIVE;
<         hints.ai_family = PF_UNSPEC;          /* IPv4 or IPv6. */
<
<         if ( getaddrinfo( NULL, "tcp", &hints, &ai ) != 0 ) {
<                perror( "getaddrinfo: error" );
<                return;
<         }
<
<         char hostBuffer[100];
<         char servBuffer[100];
<         getnameinfo( ai->ai_addr, ai->ai_addrlen, hostBuffer, sizeof hostBuffer, servBuffer, sizeof servBuffer, NI_NUMERICHOST | NI_NUMERICSERV );
<
<         dnew->host = STRALLOC( hostBuffer );
---
>       mudstrlcpy( buf, in_dns_cache( log_buf ), MAX_STRING_LENGTH );
>
>       if( buf[0] == '\0' )
>          resolve_dns( dnew, sock.sin_addr.s_addr );
>       else
>       {
>          STRFREE( dnew->host );
>          dnew->host = STRALLOC( buf );
>       }

note.. i also removed the DNS resolver from this

So the question becomes... how do you ban someone once you accept both IPv6 and IPv4 connections? I would assume if you ban the IPv6 source, they could reconnect and their router (or a router along their path) would see the unreachable state and retry via IPv4?

I really wish the brainiacs in charge of this mess had just set a drop-dead date and had all backbones stop accepting IPv4 traffic on that date. It's the only way to get people to let go and move on. That's part of the reason I haven't bothered with it...

It's a chicken and egg problem I suppose. ISPs don't do it because content providers don't do it. Content providers don't do it because the ISPs don't. They're also both waiting on their providers to jump. Reality will bite them all in the ass soon enough, which I guess is why big places like Google are doing things like World IPv6 Day.

With APNIC expected to burn up their last allocation in the next month or so, RIPE to follow suit not long after, and ARIN to burn up the last of ours by 2012 it's going to start to cause a lot of hurt. Frankly I'd much rather see IPv6 get deployed quickly than end up having to suffer under the hell of carrier grade NAT because everyone thinks the world is crying wolf again.

Oddly enough Kiasyn noticed some issues.

When I do the part to do with init_socket, even though it compiles clean and runs fine I can't connect to it (After changing it all caused it I tried with only changing this function and it had the same problem). Compiling and running in cygwin. Trying to connect with gMUDix v1.0.

If I just deal with just the other parts I can connect and all, but for host all I get is ": :".

Not sure what the deal is just figured I'd see if anyone had any clues lol.

         getnameinfo( ai->ai_addr, ai->ai_addrlen, hostBuffer, sizeof hostBuffer, servBuffer, sizeof servBuffer, NI_NUMERICHOST | NI_NUMERICSERV );
<
<         dnew->host = STRALLOC( hostBuffer );

This is the bit that sets the host, if that helps.

nod not that part since I dont have resolve on, this is the part that only gave ::

<       char line[100];
<    // mudstrlcpy( log_buf, inet_ntoa( sock.sin_addr ), MAX_STRING_LENGTH );
<    mudstrlcpy( log_buf, inet_ntop( AF_INET6, &sock.sin6_addr, line, sizeof line ), sock.sin6_port );

Looking at Kiasyn's code here now that the Arthmoor box has IPv6 available and it appears as though it's removing the IPv4 code and replacing it with IPv6. Is that right? If so, how would one go about getting the MUD to listen to the same port on a dual-stack setup?

I've looked at the Dawn of Time code but it's pretty convoluted in how things connect and I'm not making much sense of it.

Beej to the rescue. Got something thrown together that works. It seems to want to insist on only binding to the IPv6 address directly and doing some funky crap if an IPv4 connects even though that does work.

What I don't get, and it's irritating the crap out of me, is why SSH is allowed to bind itself to both the IPv4 host *AND* the IPv6 host, like so:

tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      
tcp        0      0 66.228.51.143:22            96.251.77.204:53988         ESTABLISHED 
tcp        0      0 66.228.51.143:22            96.251.77.204:51051         ESTABLISHED 
tcp        0     52 66.228.51.143:22            96.251.77.204:54612         ESTABLISHED 
tcp        0      0 :::22                       :::*                        LISTEN 

But if I try and force Smaug to do this, it just bitches that the address is in use and refuses to bind the second call.

whats your ipv6 and ipv4 addresses?

IPv4: 66.228.51.143
IPv6: 2600:3c00::f03c:91ff:fe93:835a

Dropping in to see if anyone made any progress on this with Smaug?

I haven't even tried it again since it kept annoying me sorry

No worries, always bigger fish to fry. Will keep subscribed in case of developments.

I haven't done anything more with it either since I still haven't seen any info on getting the code to listen on both IPv4 and IPv6 using the same port. Which implies that might not even be possible?

Samson said:

I haven't done anything more with it either since I still haven't seen any info on getting the code to listen on both IPv4 and IPv6 using the same port. Which implies that might not even be possible?

I did find this page, have not had a chance to digest it yet but it looked promising. Perhaps this will help? It does look like they're only defining one port here, FWIW.

Also tried looking at some of the DoT code, but now my brain really hurts. I can't believe it has to be that complicated.