Mailing List Archive

On Thu, 31 Aug 2006, Stuart D. Gathman wrote:
> Should an IP4 connect ip be translated to the equivalent IP6 address (I
> forget the prefix) for SPF matching? Very little light in RFC 4408,
> Perhaps RFC 3513 tells us more?

To clarify, should ip6:::FFFF:1.2.3.4 match an ip4 connect of 1.2.3.4 ?
Conversly, should an ip6 connect of ::FFFF:1.2.3.4 match ip4:1.2.3.4 ?

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Thu, 31 Aug 2006, Stuart D. Gathman wrote:
> > Should an IP4 connect ip be translated to the equivalent IP6 address
> > (I forget the prefix) for SPF matching? Very little light in RFC
> > 4408, Perhaps RFC 3513 tells us more?
>
> To clarify, should ip6:::FFFF:1.2.3.4 match an ip4 connect of 1.2.3.4 ?

Yes, that's the spirit of 5/9/2.

> Conversly, should an ip6 connect of ::FFFF:1.2.3.4 match ip4:1.2.3.4 ?

Yes, that's the letter of 5/9/2.

5/9/2:

| Even if the SMTP connection is via IPv6, an IPv4-mapped IPv6 IP address
| (see [RFC3513], Section 2.5.5) MUST still be considered an IPv4 address.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE90jdwL7PKlBZWjsRAlVIAJ4mQPROrj5LtrIR3RpC/3/t4r3RjACfZSvm
2K3XePm+pqpBShLET3I0l8E=
=blpp
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <200608312038.53435.julian@mehnle.net> Julian Mehnle <julian@mehnle.net> writes:

> Stuart D. Gathman wrote:
>> On Thu, 31 Aug 2006, Stuart D. Gathman wrote:
>> > Should an IP4 connect ip be translated to the equivalent IP6 address
>> > (I forget the prefix) for SPF matching? Very little light in RFC
>> > 4408, Perhaps RFC 3513 tells us more?
>>
>> To clarify, should ip6:::FFFF:1.2.3.4 match an ip4 connect of 1.2.3.4 ?
>
> Yes, that's the spirit of 5/9/2.

pardon my ignorance, but what is "5/9/2"?

I think this one should be "no". The sentence from RFC4408 that you
quote below says that those special IPv6 connections must be
considered to be IPv4 for the purposes of SPF. It doesn't say that
IPv4 addresses ever need to be considered IPv6.

I would say that "ip6:::FFFF:1.2.3.4" is a no-op that will never match
anything, as would ip6:0:000::FFFF:0102:0304 and all other variations
that this IP address could be represented as.


Remember, there are still systems out there that don't have any
reasonable support of IPv6 and trying to match IPv4 addresses to all
the different formats would be a huge pain.

I also think that anyone who tries to depend on existing
implementations to do this match is being very foolish. I suspect
that the vast majority, if not 100%, of the ipv4-only SPF
implementations just completely ignore all ip6: mechanism.




>> Conversly, should an ip6 connect of ::FFFF:1.2.3.4 match ip4:1.2.3.4 ?
>
> Yes, that's the letter of 5/9/2.

I agree with this one.

>
> 5/9/2:
>
> | Even if the SMTP connection is via IPv6, an IPv4-mapped IPv6 IP address
> | (see [RFC3513], Section 2.5.5) MUST still be considered an IPv4 address.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Thu, 31 Aug 2006, wayne wrote:

> pardon my ignorance, but what is "5/9/2"?

Section 5, paragraph 9, sentence 2 in the syntax used by the test suite.

> I would say that "ip6:::FFFF:1.2.3.4" is a no-op that will never match
> anything, as would ip6:0:000::FFFF:0102:0304 and all other variations
> that this IP address could be represented as.

Yes, that is the literal interpretation of 5/9/2. If it said
"MUST still be considered an IPv4 address as well as IPv6", then
it would be a different story:

> I also think that anyone who tries to depend on existing
> implementations to do this match is being very foolish. I suspect
> that the vast majority, if not 100%, of the ipv4-only SPF
> implementations just completely ignore all ip6: mechanism.

Including pyspf. It would be a huge pain to parse ip6 in pyspf when IP6
is disabled in the system. You can't use Python socket.inet_pton(AF_INET6,i)
unless it is available in the system socket library. I did have to parse
dual-cidr-length to be compliant, however.

> > 5/9/2:
> > | Even if the SMTP connection is via IPv6, an IPv4-mapped IPv6 IP address
> > | (see [RFC3513], Section 2.5.5) MUST still be considered an IPv4 address.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Julian Mehnle wrote:

>> should ip6:::FFFF:1.2.3.4 match an ip4 connect of 1.2.3.4 ?

> Yes, that's the spirit of 5/9/2.

IMO that spirit is more in the direction of "NOT RECOMMENDED":

Otherwise you could different results for IPv4 and the ersatz-
IPv6 (where you then apparently MUST use the IPv4 result, even
if the ip6 mechanism gives another result).

>> should an ip6 connect of ::FFFF:1.2.3.4 match ip4:1.2.3.4 ?
> Yes, that's the letter of 5/9/2.

ACK.

>| MUST still be considered an IPv4 address.

MUST. Any ip6:::FFFF:wh.at.ev.er case is utter dubious. If
you think you can get away with tolerating it add test cases
with conflicts. This can get messy if an IPv4 client would
be forced to look at the ip6:::FFFF:wh:at:ev:er directives
of the sender.

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Frank Ellermann wrote:
> Julian Mehnle wrote:
[..]
>>> should an ip6 connect of ::FFFF:1.2.3.4 match ip4:1.2.3.4 ?
>> Yes, that's the letter of 5/9/2.
>
> ACK.
>
>> | MUST still be considered an IPv4 address.
>
> MUST. Any ip6:::FFFF:wh.at.ev.er case is utter dubious. If
> you think you can get away with tolerating it add test cases
> with conflicts. This can get messy if an IPv4 client would
> be forced to look at the ip6:::FFFF:wh:at:ev:er directives
> of the sender.

In my view on this subject the notation ::ffff:x.x.x.x should have never
existed. As an _entry_ method, maybe, but for logging methods and for
presenting it to the user: never. There is afaik no reason at all to
represent an IPv4 address in mapped or compat form. It is an internal
representation, nothing else.

getaddrinfo()/inet_ntop() and friends should never return
::ffff:x.x.x.x, they should cut off the ::ffff: and simply return
1.2.3.4. There are loads of issues with it, especially in the case of
firewalls, log rules etc.

Thus (IMHO :), a tool which receives a IPv4-MAPPED address, should
convert it to a IPv4 address and handle it like an IPv4 address for the
rest of the code path. Code can use IN6_IS_ADDR_V4MAPPED(a) to easily
check this. Unfortunately every tool needs to do this.

Note that there is also ::x.x.x.x aka "an IPv6 IPv4 Compatible address",
these should be handled in the same way.

Greets,
Jeroen

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Fri, 1 Sep 2006, Frank Ellermann wrote:

> MUST. Any ip6:::FFFF:wh.at.ev.er case is utter dubious. If
> you think you can get away with tolerating it add test cases
> with conflicts. This can get messy if an IPv4 client would
> be forced to look at the ip6:::FFFF:wh:at:ev:er directives
> of the sender.

I am going with the backward compatible only approach. ::FFFF:1.2.3.4
is treated as IP4 and does *not* match ip6. IP4 connects never match IP6
either. This allows IP4 only implementations to mostly ignore
IP6.

However, should IP4 only implementations be required to check syntax of IP6?
To what degree? For instance, the test suite currently requires
"v=spf1 ip6" to return permerror, even for IP4 connect. Should I
also require "v=spf1 ip6::://0" to return permerror, even for
IP4 connects?

The RFC is pretty clear that, yes, IP4 only implementations MUST
fully syntax check ip6 mechanisms. However, the reality is that
none of the current IP4 only implementations do so, including mine.
So I am including the tests, but only for IP6 connections.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Stuart D. Gathman wrote:

> This allows IP4 only implementations to mostly ignore IP6.

Good. I recall that Julian implemented the opposite approach,
pretend that everybody uses IPv6, that should also work if
he's careful with those dubious ip6:::FFFF:cases

> should IP4 only implementations be required to check syntax
> of IP6?

Sure, a policy with an error in ...//xy or ip6: should also get
Permerror feedback a.s.a.p. And vice versa, an IPv6 client
should also check ..../xy and ip4: because syntax errors MUST
be reported. Implementations should never evaluate anything to
the right of a syntax error.

And unless they've studied the various SHOULD / MUST / MAY very
carefully they'd never begin to evaluate a policy with a syntax
error - the "left to right" loophole is carefully hidden.

> To what degree?

To the specified degree, the IPv6 construct has 128 bits.

> Should I also require "v=spf1 ip6::://0" to return
> permerror, even for IP4 connects?

It has at least one Permerror, no double slash in ip6.

IIRC "::" is no valid notation, it needs a part that's not
empty before or after it, or on both sides if the "::" isn't
the begin or end. Better check this, the ABNF for IPv6 is
simple, e.g. simpler than UTF-8, but I don't know it by heart.

> the reality is that none of the current IP4 only
> implementations do so, including mine.

Then they're not fully conformant, and the test suite will
tell them where the problem is, and that it's limited to IPv6
oddities. The implementors can then fix it when they like.

You could offer a cute "SPF conformance test Pass" icon, like
the W3C validator, when the test suite is ready and stable for
some months... :-)

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <Pine.LNX.4.44.0609011036250.30375-100000@bmsred.bmsi.com> "Stuart D. Gathman" <stuart@bmsi.com> writes:

> However, should IP4 only implementations be required to check syntax of IP6?
> To what degree? [...]
>
> The RFC is pretty clear that, yes, IP4 only implementations MUST
> fully syntax check ip6 mechanisms.

Agreed, that's what the spec says.

> However, the reality is that
> none of the current IP4 only implementations do so, including mine.
> So I am including the tests, but only for IP6 connections.

The closer to complete checking you do, the better.

It shouldn't be too hard to make sure the cidr is correct, it is
basically the same code as for ip4:.

As for the stuff inbetween the "ip6:" and the cidr, just making sure
that all characters are in the set [0-9a-f:.] would be easy and cover
a lot of the obvious errors.

If you want to get even fancier, you could do things like make sure
there is at least one colon, that there aren't more than 4 hex digits
between colons, there are at most 8 colons, and that any dots appear
at the end of the IPv6 address.


If you want to do complete checking, you can use the following abnf:

ip6-network = "::" /
7( hex4 ":" ) hex4 /
1*8( hex4 ":" ) ":" /
7( hex4 ":" ) ( ":" hex4 ) /
6( hex4 ":" ) 1*2( ":" hex4 ) /
5( hex4 ":" ) 1*3( ":" hex4 ) /
4( hex4 ":" ) 1*4( ":" hex4 ) /
3( hex4 ":" ) 1*5( ":" hex4 ) /
2( hex4 ":" ) 1*6( ":" hex4 ) /
( hex4 ":" ) 1*7( ":" hex4 ) /
":" 1*8( ":" hex4 ) /
6( hex4 ":" ) ip4-network /
6( hex4 ":" ) ":" ip4-network /
5( hex4 ":" ) ":" 0*1( hex4 ":" ) ip4-network /
4( hex4 ":" ) ":" 0*2( hex4 ":" ) ip4-network /
3( hex4 ":" ) ":" 0*3( hex4 ":" ) ip4-network /
2( hex4 ":" ) ":" 0*4( hex4 ":" ) ip4-network /
( hex4 ":" ) ":" 0*5( hex4 ":" ) ip4-network /
"::" 0*6( hex4 ":" ) ip4-network
hex4 = 1*4HEXDIG

ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255


I could translate the above abnf to a regex, if anyone *really*
cares...


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Fri, 1 Sep 2006, wayne wrote:

> I could translate the above abnf to a regex, if anyone *really*
> cares...

I care, and came up with the following regex manually for pyspf:

PAT_IP4 = r'\.'.join([r'(?:\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])']*4)+'$'
HEXSEQ = r'(?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)'
RE_IP6 = re.compile(
r'%s?(?:::)?%s?(?::%s)?'%(HEXSEQ,HEXSEQ,PAT_IP4),re.IGNORECASE)

Seems rather complex. Is yours simpler?

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

wayne wrote:

> ip6-network = "::" /

The beast I vaguely recall didn't have this. Maybe I'm wrong.

> 6( hex4 ":" ) ip4-network /

s/6/7/

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Fri, 1 Sep 2006, Stuart D. Gathman wrote:

> On Fri, 1 Sep 2006, wayne wrote:
>
> > I could translate the above abnf to a regex, if anyone *really*
> > cares...

The abnf Ruby module doesn't seem to be available anymore. All the
links I can find give 404 for the download.

> I care, and came up with the following regex manually for pyspf:
>
> PAT_IP4 = r'\.'.join([r'(?:\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])']*4)+'$'
> HEXSEQ = r'(?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)'
> RE_IP6 = re.compile(
> r'%s?(?:::)?%s?(?::%s)?'%(HEXSEQ,HEXSEQ,PAT_IP4),re.IGNORECASE)
>
> Seems rather complex. Is yours simpler?

I based mine on the RFC - but according to the author of abnf, the
ABNF in RFC is wrong! It doesn't match "::1.2.3.4".

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Well, I learned something new today:

RFC4408 references RFC3513, but that has now been replaced by RFC4291.

http://tools.ietf.org/html/rfc4291


In <44F8642E.6EAF@xyzzy.claranet.de> Frank Ellermann <nobody@xyzzy.claranet.de> writes:

> wayne wrote:
>
>> ip6-network = "::" /
>
> The beast I vaguely recall didn't have this. Maybe I'm wrong.

That is explicitly mentioned in RFC3513/RFC4291 as being ok.


>> 6( hex4 ":" ) ip4-network /
>
> s/6/7/

Uh, I think 6 is correct. Why do you say 7?


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <Pine.LNX.4.44.0609011357080.32489-100000@bmsred.bmsi.com> "Stuart D. Gathman" <stuart@bmsi.com> writes:

> On Fri, 1 Sep 2006, Stuart D. Gathman wrote:
>
>> On Fri, 1 Sep 2006, wayne wrote:
>>
>> > I could translate the above abnf to a regex, if anyone *really*
>> > cares...
>
> The abnf Ruby module doesn't seem to be available anymore. All the
> links I can find give 404 for the download.

:-<

I sent email to the author and asked what's up. I still have a copy
of the tarball, so maybe I'll host it if he no longer wants to.




>> I care, and came up with the following regex manually for pyspf:
>>
>> PAT_IP4 = r'\.'.join([r'(?:\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])']*4)+'$'
>> HEXSEQ = r'(?:[0-9a-f]{1,4}(?::[0-9a-f]{1,4})*)'
>> RE_IP6 = re.compile(
>> r'%s?(?:::)?%s?(?::%s)?'%(HEXSEQ,HEXSEQ,PAT_IP4),re.IGNORECASE)
>>
>> Seems rather complex. Is yours simpler?

lol

you must not remember the regular expressions I posted a while back (a
year ago?) that would match SPF records.

No, the converted stuff is *not* simplier. Mind you, once it is
compiled, I doubt there is any significant speed differences. Here it
is, slightly munged:

(wayne@footbone) $ ruby range_abnf.rb 2>/dev/null | convert_re
^::|
([0-9A-Fa-f]{1,4}:){7}[0-9A-Fa-f]{1,4}|
([0-9A-Fa-f]{1,4}:){1,8}:|
([0-9A-Fa-f]{1,4}:){7}:[0-9A-Fa-f]{1,4}|
([0-9A-Fa-f]{1,4}:){6}(:[0-9A-Fa-f]{1,4}){1,2}|
([0-9A-Fa-f]{1,4}:){5}(:[0-9A-Fa-f]{1,4}){1,3}|
([0-9A-Fa-f]{1,4}:){4}(:[0-9A-Fa-f]{1,4}){1,4}|
([0-9A-Fa-f]{1,4}:){3}(:[0-9A-Fa-f]{1,4}){1,5}|
([0-9A-Fa-f]{1,4}:){2}(:[0-9A-Fa-f]{1,4}){1,6}|
[0-9A-Fa-f]{1,4}:(:[0-9A-Fa-f]{1,4}){1,7}|
:(:[0-9A-Fa-f]{1,4}){1,8}|
([0-9A-Fa-f]{1,4}:){6}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])|
([0-9A-Fa-f]{1,4}:){6}:([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])|
([0-9A-Fa-f]{1,4}:){5}:([0-9A-Fa-f]{1,4}:)?
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])|
([0-9A-Fa-f]{1,4}:){4}:([0-9A-Fa-f]{1,4}:){0,2}
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])|
([0-9A-Fa-f]{1,4}:){3}:([0-9A-Fa-f]{1,4}:){0,3}
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])|
([0-9A-Fa-f]{1,4}:){2}:([0-9A-Fa-f]{1,4}:){0,4}
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])|
[0-9A-Fa-f]{1,4}::([0-9A-Fa-f]{1,4}:){0,5}
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])|
::([0-9A-Fa-f]{1,4}:){0,6}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.
([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Fri, 1 Sep 2006, wayne wrote:

> No, the converted stuff is *not* simplier. Mind you, once it is
> compiled, I doubt there is any significant speed differences. Here it
> is, slightly munged:
>
> (wayne@footbone) $ ruby range_abnf.rb 2>/dev/null | convert_re
> ^::|
> ([0-9A-Fa-f]{1,4}:){7}[0-9A-Fa-f]{1,4}|
> ([0-9A-Fa-f]{1,4}:){1,8}:|

...

Actually, the converted stuff *is* simpler. It is just macro expanded.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

wayne wrote:

> RFC4408 references RFC3513, but that has now been replaced
> by RFC4291.

Strange, I recall that I went through all references checking
that that we have the freshest. Maybe a race condition, 4291
and 4408 are relatively close. Odd that the RFC editor also
missed it.

Isolated ::
> That is explicitly mentioned in RFC3513/RFC4291 as being ok.

See STD 66 (3986), referenced by USEFOR and SPF. The ABNF is
slightly simpler, I add it below.

>>> 6( hex4 ":" ) ip4-network /
>> s/6/7/

> Uh, I think 6 is correct. Why do you say 7?

Because I counted IPv4 as four hex. digits and missed 16 bits. :-)

IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"

ls32 = ( h16 ":" h16 ) / IPv4address
; least-significant 32 bits of address

h16 = 1*4HEXDIG
; 16 bits of address represented in hexadecimal


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Fri, 1 Sep 2006, wayne wrote:

> If you want to do complete checking, you can use the following abnf:
>
> ip6-network = "::" /
> 7( hex4 ":" ) hex4 /
> 1*8( hex4 ":" ) ":" /
> 7( hex4 ":" ) ( ":" hex4 ) /
> 6( hex4 ":" ) 1*2( ":" hex4 ) /
> 5( hex4 ":" ) 1*3( ":" hex4 ) /
> 4( hex4 ":" ) 1*4( ":" hex4 ) /
> 3( hex4 ":" ) 1*5( ":" hex4 ) /
> 2( hex4 ":" ) 1*6( ":" hex4 ) /
> ( hex4 ":" ) 1*7( ":" hex4 ) /
> ":" 1*8( ":" hex4 ) /
> 6( hex4 ":" ) ip4-network /
> 6( hex4 ":" ) ":" ip4-network /
> 5( hex4 ":" ) ":" 0*1( hex4 ":" ) ip4-network /
> 4( hex4 ":" ) ":" 0*2( hex4 ":" ) ip4-network /
> 3( hex4 ":" ) ":" 0*3( hex4 ":" ) ip4-network /
> 2( hex4 ":" ) ":" 0*4( hex4 ":" ) ip4-network /
> ( hex4 ":" ) ":" 0*5( hex4 ":" ) ip4-network /
> "::" 0*6( hex4 ":" ) ip4-network
> hex4 = 1*4HEXDIG
>
> ip4-network = qnum "." qnum "." qnum "." qnum
> qnum = DIGIT ; 0-9
> / %x31-39 DIGIT ; 10-99
> / "1" 2DIGIT ; 100-199
> / "2" %x30-34 DIGIT ; 200-249
> / "25" %x30-35 ; 250-255


Here is a python translation that preserves the form of the ABNF:

RE_IP6 = re.compile('|'.join([.
'(?:%(hex4)s:){6}%(ip4)s',
'::(%(hex4)s:){0,6}%(ip4)s',
'(?:%(hex4)s:):(?:%(hex4)s:){0,5}%(ip4)s',
'(?:%(hex4)s:){2}:(?:%(hex4)s:){0,4}%(ip4)s',
'(?:%(hex4)s:){3}:(?:%(hex4)s:){0,3}%(ip4)s',
'(?:%(hex4)s:){4}:(?:%(hex4)s:){0,2}%(ip4)s',
'(?:%(hex4)s:){5}:(?:%(hex4)s:){0,1}%(ip4)s',
'(?:%(hex4)s:){7}%(hex4)s',
'(?:%(hex4)s:){1,8}:',
'(?:%(hex4)s:){7}(?::%(hex4)s)',
'(?:%(hex4)s:){6}(?::%(hex4)s){1,2}',
'(?:%(hex4)s:){5}(?::%(hex4)s){1,3}',
'(?:%(hex4)s:){4}(?::%(hex4)s){1,4}',
'(?:%(hex4)s:){3}(?::%(hex4)s){1,5}',
'(?:%(hex4)s:){2}(?::%(hex4)s){1,6}',
'(?:%(hex4)s:)(?::%(hex4)s){1,7}',
':(?::%(hex4)s){1,8}', '::'
]) % {
'ip4': r'\.'.join([r'(?:\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])']*4),
'hex4': r'(?:[0-9a-f]{1,4})'
} + '$', re.IGNORECASE)

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Sat, 2 Sep 2006, Frank Ellermann wrote:

> IPv6address = 6( h16 ":" ) ls32
> / "::" 5( h16 ":" ) ls32
> / [ h16 ] "::" 4( h16 ":" ) ls32
> / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
> / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
> / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
> / [ *4( h16 ":" ) h16 ] "::" ls32
> / [ *5( h16 ":" ) h16 ] "::" h16
> / [ *6( h16 ":" ) h16 ] "::"
>
> ls32 = ( h16 ":" h16 ) / IPv4address
> ; least-significant 32 bits of address
>
> h16 = 1*4HEXDIG
> ; 16 bits of address represented in hexadecimal

This is different from the previous: it does not allow :: to elide
0 words. E.g.:

1111:2222:3333:4444::5555:6666:7777:8888

was allowed by the previous ABNF, and forbidden by the above.

I translated to a python RE:

PAT_IP4 = r'\.'.join([r'(?:\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])']*4)
RE_IP6 = re.compile( '(?:%(hex4)s:){6}%(ls32)s$'
'|::(?:%(hex4)s:){5}%(ls32)s$'
'|(?:%(hex4)s)?::(?:%(hex4)s:){4}%(ls32)s$'
'|(?:(?:%(hex4)s:){0,1}%(hex4)s)?::(?:%(hex4)s:){3}%(ls32)s$'
'|(?:(?:%(hex4)s:){0,2}%(hex4)s)?::(?:%(hex4)s:){2}%(ls32)s$'
'|(?:(?:%(hex4)s:){0,3}%(hex4)s)?::%(hex4)s:%(ls32)s$'
'|(?:(?:%(hex4)s:){0,4}%(hex4)s)?::%(ls32)s$'
'|(?:(?:%(hex4)s:){0,5}%(hex4)s)?::%(hex4)s$'
'|(?:(?:%(hex4)s:){0,6}%(hex4)s)?::$'
% {
'ls32': r'(?:[0-9a-f]{1,4}:[0-9a-f]{1,4}|%s)'%PAT_IP4,
'hex4': r'[0-9a-f]{1,4}'
}, re.IGNORECASE)

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <44F8AF96.5B6A@xyzzy.claranet.de> Frank Ellermann <nobody@xyzzy.claranet.de> writes:

> wayne wrote:
>
>> RFC4408 references RFC3513, but that has now been replaced
>> by RFC4291.
>
> Strange, I recall that I went through all references checking
> that that we have the freshest. Maybe a race condition, 4291
> and 4408 are relatively close.

I suspect that was the case... we had to wait for RFC4409 (message
submission update) to finish and that took a long time.


> Odd that the RFC editor also
> missed it.

I dunno... from what I can tell, the job of the RFC editor is to mess
up the formatting and make minor gramtical changes. :-<


> Isolated ::
>> That is explicitly mentioned in RFC3513/RFC4291 as being ok.
>
> See STD 66 (3986), referenced by USEFOR and SPF. The ABNF is
> slightly simpler, I add it below.

the stuff you listed from 3986 allows for a bare "::" via the last
term. It is cleaner than the stuff I copied from the ABNF->RE page.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

wayne wrote:

> from what I can tell, the job of the RFC editor is to mess
> up the formatting and make minor gramtical changes. :-<

LOL. They might get input where they can do more than for
your -02. BTW, one of your mails made it to the "pending
errata", but not the one wrt Danish / Danisch. Or I missed
it, the public "pending errata" mbox is messy if read as
plain text.

> 3986 allows for a bare "::" via the last term.

That wasn't my day, three clear errors, first the // for IPv6
except from ip6:, then an attempt to invent IPs with 144 bits,
and finally I missed [ *6( h16 ":" ) h16 ] "::"

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Stuart D. Gathman wrote:

> This is different from the previous: it does not allow :: to
> elide 0 words. E.g.:
> 1111:2222:3333:4444::5555:6666:7777:8888
> was allowed by the previous ABNF, and forbidden by the above.

That's probably the idea. 2821 has a comment:

; The "::" represents at least 2 16-bit groups of zeros
; No more than 6 groups in addition to the "::" may be
; present

That's a third concept, it doesn't allow to use :: instead of
:0:. Plausible, but unnecessarily restrictive. RFC 4219 says:

| The use of "::" indicates one or more groups of 16 bits of
| zeros. The "::" can only appear once in an address.

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I know I'm late on this thread, but for the record:

Wayne Schlitt wrote:
> Julian Mehnle writes:
> > Stuart D. Gathman wrote:
> > > To clarify, should ip6:::FFFF:1.2.3.4 match an ip4 connect of
> > > 1.2.3.4?
> >
> > Yes, that's the spirit of 5/9/2.
>
> [...]
> I think this one should be "no". The sentence from RFC4408 that you
> quote below says that those special IPv6 connections must be
> considered to be IPv4 for the purposes of SPF. It doesn't say that
> IPv4 addresses ever need to be considered IPv6.

I know that it doesn't say that. That's why I wrote that I thought it was
the _spirit_, not the letter, of said paragraph.

> I would say that "ip6:::FFFF:1.2.3.4" is a no-op that will never match
> anything, as would ip6:0:000::FFFF:0102:0304 and all other variations
> that this IP address could be represented as.
>
> Remember, there are still systems out there that don't have any
> reasonable support of IPv6 and trying to match IPv4 addresses to all
> the different formats would be a huge pain.

I'm aware of that, but defining "ip6:::ffff:0102:0304" to _not_ match
1.2.3.4 would be really unexpected.

> I also think that anyone who tries to depend on existing
> implementations to do this match is being very foolish. I suspect
> that the vast majority, if not 100%, of the ipv4-only SPF
> implementations just completely ignore all ip6: mechanism.

To that I absolutely agree. We should have recommended against publishing
"ip6:::ffff:xxxx:xxxx" (or equivalents) in the spec.

For now, let's just say that whoever publishes "ip6:::ffff:xxxx:xxxx" (or
equivalents) is doing so at their own peril.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFDx1MwL7PKlBZWjsRAjCeAJ0bv8C7alNjpqPs6rodRNyLT2ckAgCgiuaI
9OPErEMoZbAoFRc53m/YcSc=
=Wohq
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeroen Massar wrote:
> In my view on this subject the notation ::ffff:x.x.x.x should have never
> existed. As an _entry_ method, maybe, but for logging methods and for
> presenting it to the user: never. There is afaik no reason at all to
> represent an IPv4 address in mapped or compat form.

Arguably, yes.

> Thus (IMHO :), a tool which receives a IPv4-MAPPED address, should
> convert it to a IPv4 address and handle it like an IPv4 address for the
> rest of the code path.

I always thought that embedding the IPv4 address space in the IPv6 address
space was a very clever idea, so systems could confine themselves to doing
IPv6-math only.

I know dual code paths are a necessity in reality, but in principle,
they're unnecessarily ugly.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFDyCLwL7PKlBZWjsRApcmAJ0S8wnJkUKf9amCZns/6mZCfBO9MQCguxdz
BVuJL1Z67rsMtOLcnTrnDp4=
=39+D
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com