[patch] IPv6 address field support

IP6AddressField patch

This looks good, but there are a few things missing:

• Naming is inconsistant; some places use "ip6" and some "ipv6". I'd prefer "ipv6" (so "IPv6AddressField" and such).
• There's a bug in the maxlength of IP6AddressField; it should be 39, not 15.

I'm marking wontfix; if you can fix those things with a new patch I'll apply it.

Updated IPv6 Field patch

I've cleaned up naming and fixed the bug in the original patch. All fields and validators are clearly marked as being IPv4 or IPv6 now with the exception of the original IPAddressField. Renaming this would break backwards compatibility.

Hi all im fine, gl all!

This needs a lot more work before it is ready for checkin. There are no tests for the validators, no documentation of the new field, and it doesn't provide any integration with newforms.

Bumping back to wontfix. The current implementation needs a lot of work to get it up to speed, and the fact that this hasn't been touched in over a year suggests that people aren't really crying out for a dedicated field here.

seduction Here's my post on how to get laid in the next month or two. This post does not maximize your chances of "getting really good at pickup" - in fact, it does the opposite.

IPv4/IPv6 field with doc, tests and integration with new/oldforms

Since I don't want to see this sinking into oblivion, I'm taking on the task.

Here is a patch I've been using for a few months. It has documentation, integration with new/oldforms and a few tests for the newforms field. IPy is used to validate, since the compressed IPv6 form is near impossible to accurately validate with regexps. I'd be happy if somebody could prove me wrong, of course.

Note that this field can store both IPv4 and IPv6 addresses. Which should be a good thing since I don't think many people are running pure IPv6 stacks out there. But that makes the field name a bit misleading. Any suggestion?

Hi Johann,

I'm very impressed with your patch. Well done! However I don't think IPy is necessary to perform IPv6 address validation, http://code.djangoproject.com/attachment/ticket/811/ipv6field.diff has regexps that will do that. Not that I object to using IPy but the Django core developers might object to introducing a third-party package.

I'm +1 for merging IPv4 and IPv6 fields into a single field.

I considered your patch but it actually fails on some edge cases, like 1::2:3:4:5:6:7:8:9 or 0:0:0:0:0:0:0::ffff:1.2.3.4. To elaborate a little on what I said, I don't see any way to *accurately* validate the compressed form with regexp, short from using a separate expression for each possible position of the dual colon shortcut. Nearly times two with the IPv4 compatibility notation. But I'm certainly not a regexp god so yes, feel free to propose a better way and I'll be glad to learn something new :)

Or instead, an alternate solution: getting ride of the regexps altogether and checking if an address converts cleanly to a binary string form. But wouldn't that equals to incude a fair part of IPy in the framework?

I'm also reluctant to introduce yet another third-party dependency, but there is a choice between accuracy and convenience here. Aside from the root of the problem (invalid data), convenience is problematic with PostgreSQL since the inet field will perform a formal validation and either behave eraticaly or throw a ProgrammingException?.

To sum things up, it's either :

1. allowing invalid data to pass through
2. using something like fifteen regexps
3. adding a part of IPy to the framework
4. asking people to install IPy

If I had to choose, I'd be +1 for the third, -1 for the first and +0 for whatever else. This patch implements the last one since it was the easiest way to get something done. But since it doesn't seem like a trivial issue, we should push this issue on the mailing list. I'm okay to rewrite the validation according to whatever consensus is reached.

Replying to Johann Queuniet <johann.queuniet@gmail.com>:

I considered your patch but it actually fails on some edge cases, like 1::2:3:4:5:6:7:8:9 or 0:0:0:0:0:0:0::ffff:1.2.3.4. To elaborate a little on what I said, I don't see any way to *accurately* validate the compressed form with regexp, short from using a separate expression for each possible position of the dual colon shortcut. Nearly times two with the IPv4 compatibility notation. But I'm certainly not a regexp god so yes, feel free to propose a better way and I'll be glad to learn something new :)

You could always change the "::" to ":0000:" before validation, the address is the same anyway. Or even:

• Change "::" to ":0000:"
• Validate
• If valid, take the original address as the good one

It's a bit more complicated since a :: can act as a shortcut for any number of 0s. But that's part of what I meant by "adding a part of IPy". You can read that as doing some normalization work before the actual validation.

I was in the mood for a first try, so here it is.

def normalize(addr):
    # Some basic error checking
    if addr.count('::') > 2 or addr.find(':::') > -1:
        raise ValueError

    li = addr.split(':')
    nbfull = len([elem for elem in li if elem != ''])

    if nbfull == 8:
        # No need to bother
        return ':'.join(full)
    if nbfull > 8:
        # Has to be invalid anyway
        raise ValueError

    # Begin normalization of ::
    start, end, index = (None, None, 0)
    for elem in li:
        if elem == '':
            if start is None:
                start = index
                end = index
            else:
                end = index
        index += 1
    pad = 8 - nbfull
    if end != start:
        li[start:end-start+1] = ['0'] * pad
    else:
        li[start] = '0'
        if pad > 1:
            li[start:1] = ['0'] * (pad - 1)
    return ':'.join(li)

I'll try to add support for IPv4 and put a new patch together by the week-end. The old one shouldn't apply cleanly anymore since FilePathField? has been added to newforms/fields.py

Same as the 02/02/08 patch, without IPy

Well, here we are. I added a normalization function in django.utils.http, since I didn't want to create a new module just for that. It should get ride of tricky things like IPv4 mapped addresses and this :: shortcut, without the IPy dependency this time.

All the concerns that were raised for this ticket (when marked "Needs improvement") seem to have been solved with the latest patch. Even the inclusion of documentation and tests. The patch still applies cleanly and passes tests so I hope no triager will feel upset for me moving this to Ready for checkin ;)

screenshot