Mailing List Archive

On Tue, 28 Nov 2006, Stuart D. Gathman wrote:

Therefore, the BOTH AND position, while theoretically attractive from an IPv6
standpoint,

1) is incompatible with IP4 implementations that ignore IP6.
2) is logically inconsistent in matching ip6, but not fetching AAAA.
3) or else increases DOS amplification potential from 10 to 20
by fetching BOTH A AND AAAA.
4) goes against the language of the RFC, specifically the "Even if" phrase.
5) can't make the %{v} macro expand to BOTH 'in-addr' AND 'ip6'.
6) has only one implementation and it was just completed this week.
7) seems to have only one proponent on SPF mailing lists.

The MUTUAL EXCUSION position, on the other hand,

1) is the plain reading of RFC4408
2) gives uniform SPF results for IP4 and IP6 senders.
3) gives uniform SPF results for IP4 only implementations that simply
ignore ip6 (other than syntax checking) as well as IP6 implementations.
4) gives uniform SPF results for both IP4 and IP6 receivers.
5) makes mechanisms like "ip6:::FFFF:1.2.3.4" officially a noop, so that
publishers have no reason to use them - thereby avoiding problems
with the implementation that insists on the BOTH AND position.
(And thus should be acceptable to the COMPROMISE position.)
6) is easy to implement by simply changing ip4 mapped ip6 connections to
ip4 before evaluating (per the plain reading of the RFC instructions).

Really, people, this is a no brainer.

--
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/?list_id=1007

Stuart D. Gathman wrote:

> Really, people, this is a no brainer.

For Julian's code it's a bit ugly, he tried to get away with a
"let's pretend that IPv4 is just a subset of IPv6" approach...

..first reported after the MAAWG meeting in Duesseldorf and
his hacking session with Shevek. It turns out that he has to
elaborate on this simplification in some places. Probably he
needs a global flag "actually IPv4", and some IFs for this
case.

I didn't look into the code because I couldn't read perl, but
I guess it's not a no-brainer from his POV, and duplicates the
code (with new "actually IPv4" branches at some places).

On the other hand the simpler form doesn't work as it should,
and the problem is in this simple implementation, not in the
spec. <tough />

If there would be some convention to map IPv6 to IPv4 (that's
for obvious reasons impossible :-) it would also hit all other
implementations.

Frank

P.S.: did anybody here read the funny drafts claiming that
there are far more IPv4 than expected, because there's a
fundamental flaw in the binary notation caused by an error of
Leibniz ?

http://www.ietf.org/internet-drafts/draft-terrell-math-quant-ternary-logic-of-binary-sys-03.txt


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

In <456DB7CC.7C12@xyzzy.claranet.de> Frank Ellermann <nobody@xyzzy.claranet.de> writes:

> For Julian's code it's a bit ugly, he tried to get away with a
> "let's pretend that IPv4 is just a subset of IPv6" approach...
>
> ..first reported after the MAAWG meeting in Duesseldorf and
> his hacking session with Shevek. It turns out that he has to
> elaborate on this simplification in some places. Probably he
> needs a global flag "actually IPv4", and some IFs for this
> case.


I do not think this is the reason why Julian dislikes the MUTUALLY
EXCLUSIVE option.

Checking to see if an IPv6 address is an IPv4-mapped address is very
simple and quick. It really is only a few more keystrokes and a few
more instructions than if you were checking a flag, which all
SPF implementations that support IPv6 have to do anyway.

I think this is more of a philosophical objection on Julian's part.
He believes that IPv4 is a fundemental and "obvious" subset of IPv6
and it doesn't make sense to think of them separately.


Maybe an analogy would be helpful here.

Say we were designing a computer programing language. At the time we
were doing it, support for Integers is easy, but supporting Floating
Point is hard because not all the hardware and OS support it.
Moreover, the vast majority of us really have only used Integers and
don't really understand Floating Point.

So, anyway, we design our language that lets you compare a bunch of
different datatypes, such as "alpha:foobarbaz", "int:1", oh, yeah, we
recognize that we need a "float:" thing too, but we don't think about
it.

Ok, along comes someone who says "hey, if you are comparing the number
seven, both 'int:7' and 'float:7.0' should match".

Now, everyone who has implemented this language has either not
implemented float: at all, or has decided that, gee, Integers only
compare with int: and Floating Point only compares with float: and
that Integers and Floating Point numbers are MUTUALLY EXCLUSIVE.

Oh, and for people who have never actually implemented software to
support an IEEE 754 floating point like I have, let me assure you that
floating point numbers can deal with *exact* integers very well, and
that "7.0" will come out as exactly an integer. It is only when you
start working with non-integers, or very large integers that things
get fuzzy.


Ok, so where are we?

Well, we can declare that seven must match int:7, float:7.0, float:7,
float:6.9999999999999999 (yes that will come out as an integer too),
etc.

We can declare that Integers and Floating Point are mutually exclusive.

Or, we can declare that whether the number seven matches float:7.0
depends on various things, or is even implemenation defined.



I'm still interested in the responses to the "New Poll" post I made,
especially with answers to *both* situations (ip4: vs ip6: and also A
vs AAAA).


-wayne

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

On Wed, 29 Nov 2006, wayne wrote:

> I think this is more of a philosophical objection on Julian's part.
> He believes that IPv4 is a fundemental and "obvious" subset of IPv6
> and it doesn't make sense to think of them separately.

I agree with that part, and would support a more elegant IP6 support in SPFv3.

> We can declare that Integers and Floating Point are mutually exclusive.
>
> Or, we can declare that whether the number seven matches float:7.0
> depends on various things, or is even implemenation defined.

RFC4408 has already declared them mutually exclusive. It pretty much
had to to maintain backward compatibility. SPFv3 will not have that
baggage, and can do it better. It will also benefit from lots more
IP6 experience, which was somewhat lacking for SPFv1.

> I'm still interested in the responses to the "New Poll" post I made,
> especially with answers to *both* situations (ip4: vs ip6: and also A
> vs AAAA).

Don't forget %{v}

--
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/?list_id=1007

wayne wrote:

> floating point numbers can deal with *exact* integers very well, and
> that "7.0" will come out as exactly an integer. It is only when you
> start working with non-integers, or very large integers that things
> get fuzzy.

This can get very ugly. I created some Wikipedia templates to do
date arithmetics, e.g. extract HHMMSS from YYYYmmDDHHMMSS with mod
operations. Under the surface that's PHP, and for PHP mod depends on
the O/S, if you hit a 64bits server (most of the time) it works, but
if the goddess of load balancing picks a 32bits server... oh well.

I tried to fix that, but I fear there are still some places where it
fails miserably. If you ever plan to use the MJD (modified Julian day,
not our Julian :-) templates on Meta, make sure to run a stress test
first. Actually always if you port PHP code from a 64bits box to a
32bits box, or worse to some mixed network.

> Well, we can declare that seven must match int:7, float:7.0, float:7,
> float:6.9999999999999999 (yes that will come out as an integer too),
1234567890123456

Float. For double it would be some nines more. We had a lot of fun
with it on Meta, with pointers to an article about macheps etc., check
out Help:Calculation (if it's still there, I left it some months ago)

> I'm still interested in the responses to the "New Poll" post I made,
> especially with answers to *both* situations (ip4: vs ip6: and also
> A vs AAAA).

Your choice "1.3" is bad, the result should not depend on the socket.
"1.4" is worse than "1.3". Maybe an "1.5" PermError would be an idea.

Otherwise it's "1.1", ugly, but a consequence of the spec., and that
was no random result of bad thinking on your side, we discussed this
again and again back in 2004.

2nd scenario, is the AAAA record valid ? Even if it is, it should not
be queried for an IPv4, the result is FAIL (2.1) if there is no A.

Frank


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

In <456DED11.6D41@xyzzy.claranet.de> Frank Ellermann <nobody@xyzzy.claranet.de> writes:

> wayne wrote:
>
>> floating point numbers can deal with *exact* integers very well, and
>> that "7.0" will come out as exactly an integer. It is only when you
>> start working with non-integers, or very large integers that things
>> get fuzzy.
>
> This can get very ugly. I created some Wikipedia templates to do
> date arithmetics, e.g. extract HHMMSS from YYYYmmDDHHMMSS with mod
> operations. Under the surface that's PHP, and for PHP mod depends on
> the O/S, if you hit a 64bits server (most of the time) it works, but
> if the goddess of load balancing picks a 32bits server... oh well.

That sounds like a problem with integers not floating point. Yes,
YYYYmmDDHHMMSS is too large for a 32-bit integer.



>> Well, we can declare that seven must match int:7, float:7.0, float:7,
>> float:6.9999999999999999 (yes that will come out as an integer too),
> 1234567890123456
>
> Float. For double it would be some nines more.

I no longer have my copy of IEEE 754 handy to quote, but 17 digits is
enough for any IEEE 754 complaint system to accurately create a double
precision rounded correctly to the bottom bit and vice versa. Either
you are working with a non-complaint system, or a float that longer
than 64 bits. That is, if you can't read and write a double precision
number using %.17f without any changes, you have a broken system.

IEEE standards cost money and you can't download it. However, a quick
look shows that
http://en.wikipedia.org/wiki/IEEE_floating-point_standard points to
http://docs.sun.com/source/806-3568/ncg_goldberg.html#1251 which
confirms that 17 digits is enough for double precision.


-wayne

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

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

Frank Ellermann wrote:
> Stuart D. Gathman wrote:
> > Really, people, this is a no brainer.
>
> For Julian's code it's a bit ugly, he tried to get away with a "let's
> pretend that IPv4 is just a subset of IPv6" approach...
> [...]
> I didn't look into the code because I couldn't read perl, but I guess
> it's not a no-brainer from his POV, and duplicates the code (with new
> "actually IPv4" branches at some places).

No, I am NOT trying "to get away" with an oversimplistic implementation.
After having written all the rest of Mail::SPF, there really wouldn't be
much point, either. And, as a matter of fact, implementing "ip6: does NOT
match IPv4-mapped IPv6 addresses" IS trivial.

Furthermore, my general observation that SPF implementations should
_internally_ treat all IP addresses as IPv6 addresses in order to save
time and effort has in fact nothing to do with the "should ip6: match
IPv4-mapped IPv6 addresses" issue debated here.

I am going to make a final response to this thread later, however my only
intention in raising this issue was to do what's right, and NOT to save
0.05% (not 5% or something!) of the implementation effort.

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

iD8DBQFFbsejwL7PKlBZWjsRAvrDAKCK5f6MLpMDCcuI4Tcw0wfRMn8qrQCfazpr
UV37+5Bxs6g1Astw0c1M+KQ=
=SDqc
-----END PGP SIGNATURE-----

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

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

I already portrayed my final position on the "IP4 mapped IP6 connection"
controversy, but for fun I will reply to Stuart's "reasons why Julian's
position makes my head hurt" list. ;-)


Stuart D. Gathman wrote:
> Therefore, the BOTH AND position, while theoretically attractive from an
> IPv6 standpoint,
>
> 1) is incompatible with IP4 implementations that ignore IP6.

Agreed. However, old SPF implementations should not be "correct by defi-
nition". Rather, we worked on RFC 4408 to build a common formal ground
for existing implementations and clarify any ambiguities -- however,
unfortunately we obviously did NOT clarify some ambiguities (at least not
to a sufficient degree), and claiming that implementors resolving them
"the wrong way" were violating RFC 4408 is unjustified.

> 2) is logically inconsistent in matching ip6, but not fetching AAAA.

Theoretically yes, practically no. It is sufficiently unlikely that domain
owners would publish IPv4 addresses using AAAA records.

> 3) or else increases DOS amplification potential from 10 to 20 by
> fetching BOTH A AND AAAA.

Right, but no one says that should be done really.

> 4) goes against the language of the RFC, specifically the "Even if"
> phrase.

I disagree with the interpretation that the "Even if" wording implies
"[MUST still be considered an IPv4 address] _only_".

> 5) can't make the %{v} macro expand to BOTH 'in-addr' AND 'ip6'.

There is no need to. Just have it expand to "in-addr". Macro expansion is
about _output_ generation, not _input_ processing, so all that is really
needed is _some_ expansion form to be clearly and unambiguously specified.
This is a red herring and has nothing to do with the "should ip6: match
IPv4 addresses" issue.

> 6) has only one implementation and it was just completed this week.

That doesn't make it wrong.

> 7) seems to have only one proponent on SPF mailing lists.

As I said on #spf already, we are of course a democracy (sort of), and I
have no problem with being voted down on this issue. I still think my
position is more correct, though.

> The MUTUAL EXCUSION position, on the other hand,
>
> 1) is the plain reading of RFC4408

Says you. :-)

> 2) gives uniform SPF results for IP4 and IP6 senders.

I don't know what you mean.

> 3) gives uniform SPF results for IP4 only implementations that simply
> ignore ip6 (other than syntax checking) as well as IP6
> implementations.

See (1) of your first list above. Apart from that, I'd agree to a BCP
document recommending that domain owners do NOT publish "ip6:" with
IPv4-mapped IPv6 addresses or, generally, with the expectation that "ip6:"
is guaranteed to match IPv4 addresses. (That would be consistent with my
expectation that domain owners do not publish IPv4 addresses using AAAA
records.)

> 4) gives uniform SPF results for both IP4 and IP6 receivers.

The socket type should not play any role whatsoever with the SPF
implementation. I never suggested anything to such an effect.

> 5) makes mechanisms like "ip6:::FFFF:1.2.3.4" officially a noop, so
> that publishers have no reason to use them - thereby avoiding
> problems with the implementation that insists on the BOTH AND
> position. (And thus should be acceptable to the COMPROMISE position.)

Silent no-ops are a very bad thing (unless they're called "noop"). If we
wanted to disallow "ip6:::ffff:n.n.n.n" & Co., those cases should at least
throw a PermError.

> 6) is easy to implement by simply changing ip4 mapped ip6 connections to
> ip4 before evaluating (per the plain reading of the RFC
> instructions).

True. However, it also happens to be true that the BOTH AND position is
easy to implement if you use only IPv6 addresses internally by converting
IPv4 addresses to IPv4-mapped IPv6 addresses before evaluating, which is
generally equivalent to the implementation design suggested by the RFC.
(I still have to check "everywhere" for whether an IPv6 address at hand is
an IPv4-mapped one, though, so having to do it in one more place ("ip6:"
matching) certainly cannot be, and never was, the motivation for this
thread.)


Now, wrapping all this up, I'll say again that I have no problem with being
voted down on this issue.

EOT

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

iD8DBQFFbvCXwL7PKlBZWjsRAt98AJ4285c5xt4B7dm39/FvdZNpUIJ3twCg4pNq
CwCT1DCXI5oAN3PJ0LCen+Y=
=Jz9n
-----END PGP SIGNATURE-----

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

On Thu, 30 Nov 2006, Julian Mehnle wrote:
> I already portrayed my final position on the "IP4 mapped IP6 connection"
> controversy, but for fun I will reply to Stuart's "reasons why Julian's
> position makes my head hurt" list. ;-)
>
> Stuart D. Gathman wrote:
> > Therefore, the BOTH AND position, while theoretically attractive from an
> > IPv6 standpoint,
> >
> > 1) is incompatible with IP4 implementations that ignore IP6.
>
> Agreed. However, old SPF implementations should not be "correct by defi-
> nition". Rather, we worked on RFC 4408 to build a common formal ground
> for existing implementations and clarify any ambiguities -- however,
> unfortunately we obviously did NOT clarify some ambiguities (at least not
> to a sufficient degree), and claiming that implementors resolving them
> "the wrong way" were violating RFC 4408 is unjustified.

+1

> > 2) is logically inconsistent in matching ip6, but not fetching AAAA.
>
> Theoretically yes, practically no. It is sufficiently unlikely that domain
> owners would publish IPv4 addresses using AAAA records.

+1

> > 3) or else increases DOS amplification potential from 10 to 20 by
> > fetching BOTH A AND AAAA.
>
> Right, but no one says that should be done really.

+1

> > 4) goes against the language of the RFC, specifically the "Even if"
> > phrase.
>
> I disagree with the interpretation that the "Even if" wording implies
> "[MUST still be considered an IPv4 address] _only_".

+1 I think I may now side with Julian on this one.

> > 5) can't make the %{v} macro expand to BOTH 'in-addr' AND 'ip6'.
>
> There is no need to. Just have it expand to "in-addr". Macro expansion is
> about _output_ generation, not _input_ processing, so all that is really
> needed is _some_ expansion form to be clearly and unambiguously specified.
> This is a red herring and has nothing to do with the "should ip6: match
> IPv4 addresses" issue.

+1

> > 6) has only one implementation and it was just completed this week.
>
> That doesn't make it wrong.

+1
> > 7) seems to have only one proponent on SPF mailing lists.
>
> As I said on #spf already, we are of course a democracy (sort of), and I
> have no problem with being voted down on this issue. I still think my
> position is more correct, though.

+1

> > The MUTUAL EXCUSION position, on the other hand,
> >
> > 1) is the plain reading of RFC4408
>
> Says you. :-)


I can see it being read either way right now. But I can not really now
side with either. Both arguments can be understood. I am now slightly
moving in Julians postition.


--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

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

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

> Stuart D. Gathman wrote:
>> Therefore, the BOTH AND position, while theoretically attractive from an
>> IPv6 standpoint,
>>
>> 1) is incompatible with IP4 implementations that ignore IP6.
>
> Agreed. However, old SPF implementations should not be "correct by defi-
> nition".

Well, I disagree here, since one of the goals of RFC4408 was to try
and write a spec that was largely backwards compatible. If all
implementations do <x>, but the spec isn't clear on that point, then
the spec is wrong.

> nition". Rather, we worked on RFC 4408 to build a common formal ground
> for existing implementations and clarify any ambiguities -- however,
> unfortunately we obviously did NOT clarify some ambiguities (at least not
> to a sufficient degree), and claiming that implementors resolving them
> "the wrong way" were violating RFC 4408 is unjustified.

I disagree with this too. I think the spec is clear enough. If you
read it as IPv4 and IPv6 addresses as being mutually exclusive, which
most people apparently did, you get a consistent reading. If you read
that IPv4-mapped IPv6 addresses are both, then you don't get a
consistent reading.


>> 2) is logically inconsistent in matching ip6, but not fetching AAAA.
>
> Theoretically yes, practically no. It is sufficiently unlikely that domain
> owners would publish IPv4 addresses using AAAA records.

Right, if you say that IPv4-mapped IPv6 addresses are both, then this
is another inconsistency in the spec.


>> 3) or else increases DOS amplification potential from 10 to 20 by
>> fetching BOTH A AND AAAA.
>
> Right, but no one says that should be done really.

Well, you say that theoretically it should be done, so someone in a
year or two could start doing it. And, if allowed, we need to make
the DoS analysis take this doubling of the checks into account.


>
>> 4) goes against the language of the RFC, specifically the "Even if"
>> phrase.
>
> I disagree with the interpretation that the "Even if" wording implies
> "[MUST still be considered an IPv4 address] _only_".

Again, if I had thought that it wasn't clear enough, I would have
added more text. At the time of the writing of the spec, no one had
advanced your position that ip6::ffff:<ip4> should be matched on IPv4
connections.


>
>> 5) can't make the %{v} macro expand to BOTH 'in-addr' AND 'ip6'.
>
> There is no need to. Just have it expand to "in-addr". Macro expansion is
> about _output_ generation, not _input_ processing, so all that is really
> needed is _some_ expansion form to be clearly and unambiguously specified.
> This is a red herring and has nothing to do with the "should ip6: match
> IPv4 addresses" issue.

Right, if you say that IPv4-mapped IPv6 addresses are both, then this
is another inconsistency in the spec. Oh, and the %{i} and %{c}
macros are also a problem.


>> 3) gives uniform SPF results for IP4 only implementations that simply
>> ignore ip6 (other than syntax checking) as well as IP6
>> implementations.
>
> See (1) of your first list above. Apart from that, I'd agree to a BCP
> document recommending that domain owners do NOT publish "ip6:" with
> IPv4-mapped IPv6 addresses or, generally, with the expectation that "ip6:"
> is guaranteed to match IPv4 addresses. (That would be consistent with my
> expectation that domain owners do not publish IPv4 addresses using AAAA
> records.)

I disagree here. I *do* expect domain owners to publish AAAA records
with IPv4-mapped addresses. So does the author of:
http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/ipv4-mapped.txt

And, here is a discussion of resolvers that already return IPv4-mapped
addresses when doing AAAA lookups.
http://www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00419.html

And another:
http://developer.apple.com/documentation/Darwin/Reference/Manpages/man3/getipnodebyaddr.3.html

Mind you, those are *just* the top 3 hits on google for "ipv4-mapped AAAA"
and there are another 17k hits to go.


Yes, I *really* think that once IPv6 takes off (e.g. when the IPv4
address space runs out in 3-5 years), that people *will* start
publishing IPv4-mapped addresses in AAAA records, and some of those
will not have corresponding A records.

If you are going to go down the path that IPv4-mapped addresses are
both IPv4 and IPv6, you really need to do AAAA checking to.


>> 5) makes mechanisms like "ip6:::FFFF:1.2.3.4" officially a noop, so
>> that publishers have no reason to use them - thereby avoiding
>> problems with the implementation that insists on the BOTH AND
>> position. (And thus should be acceptable to the COMPROMISE position.)
>
> Silent no-ops are a very bad thing (unless they're called "noop"). If we
> wanted to disallow "ip6:::ffff:n.n.n.n" & Co., those cases should at least
> throw a PermError.

There are *lots* of silent no-ops in SPF. One more won't hurt us.
Certainly not more than checking both A and AAAA records all the time
and not as much as gratuitous incompatibilities.



>> 6) is easy to implement by simply changing ip4 mapped ip6 connections to
>> ip4 before evaluating (per the plain reading of the RFC
>> instructions).
>
> True. However, it also happens to be true that the BOTH AND position is
> easy to implement if you use only IPv6 addresses internally by converting
> IPv4 addresses to IPv4-mapped IPv6 addresses before evaluating, which is
> generally equivalent to the implementation design suggested by the RFC.

And that pretty much requires that people implement IPv6, something I
don't think anyone ever intended to do.



From what I can see, you are splitting hairs and deliberately
misreading the spec in order to make one corner case be ambiguous, and
then spitting hairs saying that the other corner cases you open up
don't count.

And, I can't see a single thing gained by opening up this ambiguity.



-wayne

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

On Thu, 30 Nov 2006, Julian Mehnle wrote:

> > 4) gives uniform SPF results for both IP4 and IP6 receivers.
>
> The socket type should not play any role whatsoever with the SPF
> implementation. I never suggested anything to such an effect.

OK, if you get all IP4 receivers to upgrade to software that
converts all IPs to IP6 and matches ip6, then yes, BOTH AND would
get consistent results in that hypothetical case. So I guess you could
combine this point with the compatibility point.

> Now, wrapping all this up, I'll say again that I have no problem with being
> voted down on this issue.

But stick to your guns to SPFv3 - at least until the RFC is published.

We effectively have the COMPROMISE position, since the test suite allows
both match and not match for ip6:::FFFF:*. This should discourage use
just as surely as making it officially a NOOP. :-)

BTW, re PermError. Yes, ideally you are correct, but the test suite is
about what the existing actual RFC4408 says, not what we wish we had put
in while we were editing the final words. (That was the time for this
argument.) Also, consider ip6::://0. That certainly shouldn't be a PermError,
yet it would match IP4 addresses under the BOTH AND theory and not otherwise.
(As would A//0, but you've already made an ugly exception for that case.)

While the actual RFC is perfectly clear to me, since it is not clear to an
otherwise very smart person, I'm going along with the COMPROMISE position - but
only because the end result (nobody uses ip6:::FFFF:*) is the same.

For SPFv3, you should come up with use cases for having ip6:::FFFF:* match
something. That would really help get it right for the next round.

Also, I suggest that the SPFv1 test suite be forked, and modified for SPFv3.
That way we can hopefully hash this type of thing out before it is published.

--
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/?list_id=1007

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

Wayne Schlitt wrote:
> From what I can see, you are splitting hairs and deliberately misreading
> the spec [...]

Not true. Perhaps I'm misreading it, but certainly not deliberately.

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

iD8DBQFFbv6gwL7PKlBZWjsRAg7eAKD409aILbvoHZ5KwjFNbBVRxz2b+gCgqHsd
o9ANvfqc5YFgysHv9BC0O1I=
=Vh/g
-----END PGP SIGNATURE-----

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