Mailing List Archive

Summary of the controversy:

Paragraph 5/15 says,

When any mechanism fetches host addresses to compare with <ip>, when <ip>
is an IPv4 address, A records are fetched, when <ip> is an IPv6 address,
AAAA records are fetched. Even if the SMTP connection is via IPv6, an
IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still be
considered an IPv4 address.

Party A says this paragraph should be clarified as follows:

When any mechanism fetches host addresses to compare with <ip>, when <ip>
is an IPv4 address, A records are fetched, when <ip> is an IPv6 address,
AAAA records are fetched. Even if the SMTP connection is via IPv6, an
IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still be
considered an IPv4 address, and not as an IPv6 address.

Party B says this paragraph should be clarified as follows:

When any mechanism fetches host addresses to compare with <ip>, when <ip>
is an IPv4 address, A records are fetched, when <ip> is an IPv6 address,
AAAA records are fetched. Even if the SMTP connection is via IPv6, an
IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still be
considered an IPv4 address, as well as an IPv6 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/?list_id=1007

On Mon, 27 Nov 2006, Stuart D. Gathman wrote:

> Party A says this paragraph should be clarified as follows:
>
> IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still be
> considered an IPv4 address, and not as an IPv6 address.

The "mutual exclusion" party.

> Party B says this paragraph should be clarified as follows:
>
> IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still be
> considered an IPv4 address, as well as an IPv6 address.

The "both and" party.

Can people with an opinion let me know which party they currently belong
to? I am currently with the mutual exclusion party.

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

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

> On Mon, 27 Nov 2006, Stuart D. Gathman wrote:
>
>> Party A says this paragraph should be clarified as follows:
>>
>> IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still be
>> considered an IPv4 address, and not as an IPv6 address.
>
> The "mutual exclusion" party.

This was my understanding while I was editing the I-D. It is still my
understanding that a most, if not almost all, SPF implementations
follow this interpretation. One of my main guiding goals in the
development of the final RFC was to try to be backwards compatible
unless there was a *really* important reason to deviate. In cases
where the various implementations and the various prior specs
conflicted with each other, things weren't as easy to decide.

That said, I never viewed myself as the final word on the I-D and
tried to reach consensus. I would like to see us reach a consensus on
this also. All I'm saying is that when I wrote that sentence, I
thought it was clear enough that the ", and not as an IPv6 address"
part was not needed. I also still think that backwards compatibility
should be an important goal.



The language from the specs:

Paragraph 5/15 of RFC4408 says,

When any mechanism fetches host addresses to compare with <ip>, when <ip>
is an IPv4 address, A records are fetched, when <ip> is an IPv6 address,
AAAA records are fetched. Even if the SMTP connection is via IPv6, an
IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still be
considered an IPv4 address.


Specs prior to draft-schlitt-spf-01 do not mention "IPv4-mapped IPv6
IP addresses" and the above sentence was added at this point. Note
that draft-schlitt-spf-01 was *earlier* than any of the I-Ds that I
submitted to the IETF. When that happened, I had to rename the drafts
to draft-schlitt-spf-classic-00, starting the numbering over again.


draft-lentczner-spf-00 section 4.2 says:

When any mechanism fetches host addresses to compare with <ip>, when
<ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
address, AAAA records are fetched.


draft-mengwong-spf-0[01] section 4.3 both say:

The following conventions apply to designated sender mechanisms:

If the optional <CIDR-length> is given, then only the upper
<CIDR-length> bits of each IP are compared to the <sending-host>.

If the SMTP connection is IPv6, read "AAAA lookup" for "A lookup",
except where "A" lookups are explicitly specified.



-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

Stuart D. Gathman wrote:
> On Wed, 15 Nov 2006, Julian Mehnle wrote:
> > In the Mail::SPF test-suite driver, I am currently skipping the
> > "cidr6-0-ip4" and "cidr6-ip4" test cases. They assume that IPv4
> > connec- tions must never match the "ip6" mechanism, even if the IPv4
> > connection comes in through an IPv6 interface. I discussed this with
> > Wayne and Scott on #spf extensively, and it seems we cannot agree on a
> > common interpreta- tion of RFC 4408. Here's my rationale:
> >
> > Nowhere does RFC 4408 say that the "ip6" mechanism must not match IPv4
> > addresses. 5/9 saying "Even if the SMTP connection is via IPv6, an
> > IPv4-mapped IPv6 IP address [...] MUST still be considered an IPv4
> > address" doesn't change that.
>
> Why do you make ip4 mapped ip6 connections match IP6, but not A or MX?
> To be consistent, you should fail tests like a-cidr6-0-ip4mapped as
> well:
>
> e2a.example.com:
> - AAAA: 1234::1
> - SPF: v=spf1 a//0 -all
>
> If ip4 mapped connections are considered as *both* ip4 and ip6, then
> they should match the above a//0 mech as well. But your SPF lib
> apparently passes the above test.

You are right. I really should do _both_ "A" and "AAAA" lookups for IPv4-
mapped IPv6 addresses in order to be consistent with my "ip6:" rationale.

However, I need to think more about (1) whether such dual address lookups
can be justified, and (2) whether there's perhaps a conceptual difference
between "ip6:" and "a:" that would justify NOT being consistent in this
regard. I'll let you know where my meditations lead me.

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

iD8DBQFFa1FAwL7PKlBZWjsRAiBgAKCm5KWCe1w5uMcT94jRyt7qV5kGXQCg0Dxj
6BimMO8x0reEvMLykiO+jKg=
=GadF
-----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

Stuart D. Gathman wrote:
> On Mon, 27 Nov 2006, Stuart D. Gathman wrote:
> > Party A says this paragraph should be clarified as follows:
> >
> > IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST
> > still be considered an IPv4 address, and not as an IPv6 address.
>
> The "mutual exclusion" party.
>
> > Party B says this paragraph should be clarified as follows:
> >
> > IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST
> > still be considered an IPv4 address, as well as an IPv6 address.
>
> The "both and" party.
>
> Can people with an opinion let me know which party they currently belong
> to? I am currently with the mutual exclusion party.

Thanks for your nice summary. Needless to mention, I'm in the "both and"
camp.

As I have said before, I'm certainly not going to request an exclusive
change in the test suite to the end of the "both and" interpretation
because I do see and respect Wayne's intention in writing the I-D. The
original intention cannot and should not be ignored, and thus should
remain valid.

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

iD8DBQFFa1LqwL7PKlBZWjsRAvj3AKCcQ16HECEeQg+qpWD0N1IqZeF6UACgsSbf
qpIRDGiDrpwfZbQK06Sw02U=
=nAQ/
-----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 Monday 27 November 2006 14:36, Stuart D. Gathman wrote:
> On Mon, 27 Nov 2006, Stuart D. Gathman wrote:
> > Party A says this paragraph should be clarified as follows:
> >
> > IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still
> > be considered an IPv4 address, and not as an IPv6 address.
>
> The "mutual exclusion" party.
>
> > Party B says this paragraph should be clarified as follows:
> >
> > IPv4-mapped IPv6 IP address (see RFC 3513, Section 2.5.5) MUST still
> > be considered an IPv4 address, as well as an IPv6 address.
>
> The "both and" party.
>
> Can people with an opinion let me know which party they currently belong
> to? I am currently with the mutual exclusion party.

I'm not sure I care....

The main thing is that IPv4 has to be able to operate in an IPv6 ignorant
manner (modulo not generating errors on the IPv6 mechanisms when they appear
in records). IPv6 needs to understand that IPv4 exists (i.e. the
interoperability burden goes to the new protocol).

What needs to happen is that if I send mail via 72.81.252.18 and I have
ip4:72.81.252.18 in my record (I do) then it MUST match regardless if the
receiver is on an IPv4 or IPv6 network. If an implementer chooses to also
make that match to an equivalent IP6: mechanism, I'm not sure I care. As an
IPv6 ignorant sender I'll never put that in my record.

If I am reading the discussion correctly, this is a distinction that can never
make a difference. Would somebody please explain why we need to argue over
this?

Scott K

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

In <200611271629.48766.scott@kitterman.com> Scott Kitterman <scott@kitterman.com> writes:

>> Can people with an opinion let me know which party they currently belong
>> to? I am currently with the mutual exclusion party.
>
> I'm not sure I care....
>
> The main thing is that IPv4 has to be able to operate in an IPv6 ignorant
> manner (modulo not generating errors on the IPv6 mechanisms when they appear
> in records). IPv6 needs to understand that IPv4 exists (i.e. the
> interoperability burden goes to the new protocol).

Yes, I agree with this, and I think as a result, this dictates the
mutually exclusive interpretation.


> What needs to happen is that if I send mail via 72.81.252.18 and I have
> ip4:72.81.252.18 in my record (I do) then it MUST match regardless if the
> receiver is on an IPv4 or IPv6 network. If an implementer chooses to also
> make that match to an equivalent IP6: mechanism, I'm not sure I care. As an
> IPv6 ignorant sender I'll never put that in my record.
>
> If I am reading the discussion correctly, this is a distinction that can never
> make a difference. Would somebody please explain why we need to argue over
> this?

The questions are along the lines of:

What should this match:

"v=spf1 ip6:::FFFF:72.81.252.18 -all"

My answer is:

* This should always fail. An ip6: mechanism that lists an
IPv4-mapped IPv6 address is effectively a no-op.


Other possibilities are:

* This should always pass if the connection is from the equivalent of the
IPv4 address of 72.81.252.18, even if the SPF implementation is "IPv6
ignorant".

* This should pass if the SMTP connection came in on an IPv6 socket,
but not if it came in on an IPv4 socket. (This can only happen if
the host is dual-homed in both IPv4 and IPv6 connections.)


As Stuart points out, there may be other cases where treating IPv4
addresses as being appart of the IPv6 space can cause different
results. His example was "a//0" would then have to match all IPv4
addresses, just like "a/0" would.


-wayne

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

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

> As I have said before, I'm certainly not going to request an exclusive
> change in the test suite to the end of the "both and" interpretation
> because I do see and respect Wayne's intention in writing the I-D. The
> original intention cannot and should not be ignored, and thus should
> remain valid.

Again, I don't think it should be so much of "what was my intention?",
but rather "what is likely to be the most backwards compatable?".


OH, and to give credit where credit is due, I'm pretty sure it was
Julian that first brought many of the finer points of IPv6 and RFC4408
would be much worse off without his insight and knowledge.


I suspect that Meng, when designing the IPv6 stuff just said "uh, I'm
sure I'm going to need to do stuff here, let's throw in an ip6:
mechanism and an IPv6 CIDR", without giving any really deep thought to
it. I suspect that most implementors, including myself, just said
"uh, if we are dealing with an IPv4 connection, we can ignore all the
IPv6 sutff". I seem to recall asking about "ipv4-mapped" and
"ipv4-compatible" stuff, but not really understanding it.


I'll go dig through the archives to see what stuff I can come up with.



-wayne


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

On Monday 27 November 2006 16:42, wayne wrote:
> In <200611271629.48766.scott@kitterman.com> Scott Kitterman
<scott@kitterman.com> writes:
> >> Can people with an opinion let me know which party they currently belong
> >> to? I am currently with the mutual exclusion party.
> >
> > I'm not sure I care....
> >
> > The main thing is that IPv4 has to be able to operate in an IPv6 ignorant
> > manner (modulo not generating errors on the IPv6 mechanisms when they
> > appear in records). IPv6 needs to understand that IPv4 exists (i.e. the
> > interoperability burden goes to the new protocol).
>
> Yes, I agree with this, and I think as a result, this dictates the
> mutually exclusive interpretation.

I'm still not following on the practical distinction.

> > What needs to happen is that if I send mail via 72.81.252.18 and I have
> > ip4:72.81.252.18 in my record (I do) then it MUST match regardless if the
> > receiver is on an IPv4 or IPv6 network. If an implementer chooses to
> > also make that match to an equivalent IP6: mechanism, I'm not sure I
> > care. As an IPv6 ignorant sender I'll never put that in my record.
> >
> > If I am reading the discussion correctly, this is a distinction that can
> > never make a difference. Would somebody please explain why we need to
> > argue over this?
>
> The questions are along the lines of:
>
> What should this match:
>
> "v=spf1 ip6:::FFFF:72.81.252.18 -all"

My question would be why would this ever appear in a record? If I'm writing
the record from an IPv4 perspective, I'd never put that in. I'd use:

"v=spf1 ip4:72.81.252.18 -all"

So my question is still why do we care if it matches?
>
> My answer is:
>
> * This should always fail. An ip6: mechanism that lists an
> IPv4-mapped IPv6 address is effectively a no-op.

Agreed it's effectively a no-op, but if it's a no-op what does it hurt if it
matches? I can see from an implementation perspective it might be simpler
not to have to make this a special case. If it's easier to implement, why
not?
>
> Other possibilities are:
>
> * This should always pass if the connection is from the equivalent of the
> IPv4 address of 72.81.252.18, even if the SPF implementation is "IPv6
> ignorant".
>
> * This should pass if the SMTP connection came in on an IPv6 socket,
> but not if it came in on an IPv4 socket. (This can only happen if
> the host is dual-homed in both IPv4 and IPv6 connections.)
>
>
> As Stuart points out, there may be other cases where treating IPv4
> addresses as being appart of the IPv6 space can cause different
> results. His example was "a//0" would then have to match all IPv4
> addresses, just like "a/0" would.

I can see that, but I'm equally uncertain of any harm that could result...

Scott K

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

In <200611271652.08455.scott@kitterman.com> Scott Kitterman <scott@kitterman.com> writes:

>> The questions are along the lines of:
>>
>> What should this match:
>>
>> "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>
> My question would be why would this ever appear in a record? If I'm writing
> the record from an IPv4 perspective, I'd never put that in. I'd use:
>
> "v=spf1 ip4:72.81.252.18 -all"

I suspect that this will change as IPv6 becomes more common. People
will stop thinking in terms of IPv4 and start thinking in terms of
IPv6.

I suspect that as IPv6 becomes more common, you will also get various
errors such as "ip6:0000:1234:5678::/8" instead of
"ip6:0000:1234:5678::/48". If this matches all IPv4 addresses in some
implementations, but is effectively a no-op in others, then this error
will not show up without a lot of testing. Likewise with incorrect
IPv6 cidrs on other mechanisms. I guess maybe our validators should
check this kind of thing and give a warning.


Your point, however, is well taken. If the choice of interpretations
makes no practical difference, then either interpretation is backwards
compatible.

One thing we might do is stress that publishers SHOULD not publish
IPv4-mapped addresses as ip6: mechanisms since it is not clear how all
SPF implementations will interpret them. We have some similar
wordings in RFC4408 already.

> So my question is still why do we care if it matches?

In large part, the test suite is attempting to split hairs and
attempting to give as consistent a defintion of what "SPF" is as can
reasonably be done. I think it is reasonable to try and nail down the
spec as close as we can.



-wayne

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

On Mon, 27 Nov 2006, Scott Kitterman wrote:

> What needs to happen is that if I send mail via 72.81.252.18 and I have
> ip4:72.81.252.18 in my record (I do) then it MUST match regardless if the
> receiver is on an IPv4 or IPv6 network. If an implementer chooses to also
> make that match to an equivalent IP6: mechanism, I'm not sure I care. As an
> IPv6 ignorant sender I'll never put that in my record.

IPv4 only senders are safe with either interpretation.

> If I am reading the discussion correctly, this is a distinction that can
> never make a difference. Would somebody please explain why we need to argue
> over this?

So that IP6 senders can get consistent results. If there is no consensus,
then we will have to tell IP6 senders to avoid any IP6, A, or MX mechanisms
that might match ::FFFF:*, otherwise they will get inconsistent results
from receivers. This is unfriendly because it is not always obvious
that the mechanism will match ::FFFF:*.

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

In <x4psb8h88d.fsf@footbone.schlitt.net> wayne <wayne@schlitt.net> writes:

> I suspect that Meng, when designing the IPv6 stuff just said "uh, I'm
> sure I'm going to need to do stuff here, let's throw in an ip6:
> mechanism and an IPv6 CIDR", without giving any really deep thought to
> it. [...]
>
> I'll go dig through the archives to see what stuff I can come up with.


Well, I'm still digging, but I did find this gem:

http://archives.listbox.com/735/200310/0449.html

In it, about three years ago, Meng wrote:

: We need someone to represent IPv6 --- I know nothing about it!

And

: Surely we don't want to have the RFC go through and then three years
: down the road suddenly all the IPv6 people hate us.

yep. three years later, and the IPv6 people hate us. ;-)



-wayne

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

On Mon, 27 Nov 2006, wayne wrote:

> > The main thing is that IPv4 has to be able to operate in an IPv6 ignorant
> > manner (modulo not generating errors on the IPv6 mechanisms when they appear
> > in records). IPv6 needs to understand that IPv4 exists (i.e. the
> > interoperability burden goes to the new protocol).
>
> Yes, I agree with this, and I think as a result, this dictates the
> mutually exclusive interpretation.

In case anybody didn't catch it, Wayne and I are not contradicting each
other. Wayne is talking about IP4 only *receivers* evaluating SPF
records that might contain IP6 mechs or reference AAAA RRs. They are likely
ignoring ip6 mechs and ignoring AAAA RRs. If we decide that ip4 mapped
connections are BOTH ip4 AND ip6, then for ip4 only receivers to get
the same results as an IP6 receiver for IP4 connections, they would have to
also treat IP4 connections as ::FFFF:ip4 connections and match
ip6 mechs and look for AAAA records. No legacy implementation does this.
Therefore, the BOTH AND interpretation will break all ip4 only implemtations
(at least when there are IP6,A,MX mechs that match ::FFFF:*).

Julian, that alone should convince you that the mutual exclusion camp
is the only backwards compatible one. Are you ready to change parties?

I was talking about IP4 only *senders*, who are safe as long as they don't
use IP6 or reference any AAAA in A or MX.

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

On Mon, 27 Nov 2006, Stuart D. Gathman wrote:

> ip6 mechs and look for AAAA records. No legacy implementation does this.
> Therefore, the BOTH AND interpretation will break all ip4 only implemtations
> (at least when there are IP6,A,MX mechs that match ::FFFF:*).
>
> Julian, that alone should convince you that the mutual exclusion camp
> is the only backwards compatible one. Are you ready to change parties?

I think most of us will agree that the "both and" interpretation
Would Have Been Nice if it had been put in from the beginning. But backward
compatibility with ip4 implementations that were promised they could "just
ignore" ip6 demands the "mutually exclusive" interpretation - for better or for
worse.

Therefore, ip6:::FFFF:0/96 will never match anything. Ugly, but the
only way to keep our promise to the ip4 only people. (Otherwise, IP4
folks would have to actually parse and interpret ip6 to detect and
match that case.)

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

> -----Original Message-----
> From: wayne [mailto:wayne@schlitt.net]
> Sent: maandag 27 november 2006 22:43
> To: SPF Development
> Subject: Re: [spf-devel] IP4 mapped IP6 connection controversy
>
>
> What should this match:
>
> "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>
> My answer is:
>
> * This should always fail. An ip6: mechanism that lists
> an IPv4-mapped IPv6 address is effectively a no-op.

Purely from a sender perspective, is not the sole purpose of publishing an
ip6 mechanism to indicate that it should only have meaning/relevance on an
IPv6 socket?

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

All fine and dandy. But again, what is the relevance of "seeing" an IPv4
address on an IPv6 connection? The socket-type, IPv4 or IPv6, should
determine which of the namesake mechs has (mutual exclusive) relevance. So
as to say that "v=spf1 ip6:::FFFF:72.81.252.18 -all", while, according to
our RFC, MUST still be considered an IPv4 address, STILL should have no
relevance as IPv4 address in the context of evaluating an ip6 mech on an
IPv6 connection. As if saying: "You have the right key, but you're trying
to open the wrong door with it."

> Other possibilities are:
>
> * This should always pass if the connection is from the
> equivalent of the IPv4 address of 72.81.252.18, ...

I'd say that on an IPv4 socket, matching an IP address via an ip6 mech
that just happens to have an IPv4-mapped IPv6 IP address, is really
questionable. The more cleaner solution were to not evaluate the ip6 mech
on an IPv4 socket at all.

> * This should pass if the SMTP connection came in on an IPv6 socket,
> but not if it came in on an IPv4 socket.

I'd still say that's questionable.

Section 4.6.2 of our RFC ("Mechanisms") says that "Each mechanism is
considered in turn from left to right." So, I don't think RFC 4408 really
allows room to literally skip either ip4 or ip6; but I certainly see
nothing to prevent us from saying that the evaluation of ip6 always
results in "not match" on an IPv4 socket, and vice versa.

- Mark

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

Mark wrote:
> Section 4.6.2 of our RFC ("Mechanisms") says that "Each mechanism is
> considered in turn from left to right." So, I don't think RFC 4408
> really allows room to literally skip either ip4 or ip6; but I certainly
> see nothing to prevent us from saying that the evaluation of ip6 always
> results in "not match" on an IPv4 socket, and vice versa.

I think you're mistaking the nature of "an IPv6 socket". An IPv6 listen
socket can very well accept IPv4 connections. That's exactly when the
listening process sees an IPv4-mapped IPv6 address. This was introduced
to allow applications to use just a single (IPv6) socket (as opposed to
having to use both an IPv4 and an IPv6 socket) and still be able to talk
to IPv4 endpoints. (This is also why I think that, for all intents and
purposes, the IPv4 address space is embedded in the IPv6 address space.)

Thus you simply cannot say "never match 'ip4:' on an IPv6 socket". IPv6-
enabled applications aren't even normally supposed to know _what_ an IPv4-
mapped IPv6 address is -- they should just use it like any other IPv6
address.

However, this debate is about the _other_ weird "IPv6 socket" case, i.e.
can 'ip6:' match an IPv4 connection if it comes through an IPv6 socket?

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

iD8DBQFFa47/wL7PKlBZWjsRAoarAKDUq96LoOYh34nWjdjKcebK8SkvtACglNJJ
PQ6Tzs83GloXpjBXQl7gvdU=
=VDLP
-----END PGP SIGNATURE-----

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

In <200611272347.kARNlEqG047492@asarian-host.net> Mark <admin@asarian-host.net> writes:

>
> Purely from a sender perspective, is not the sole purpose of publishing an
> ip6 mechanism to indicate that it should only have meaning/relevance on an
> IPv6 socket?

I think that is what is being debated.

> ... 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.
>
> All fine and dandy. But again, what is the relevance of "seeing" an IPv4
> address on an IPv6 connection? The socket-type, IPv4 or IPv6, should
> determine which of the namesake mechs has (mutual exclusive) relevance. So
> as to say that "v=spf1 ip6:::FFFF:72.81.252.18 -all", while, according to
> our RFC, MUST still be considered an IPv4 address, STILL should have no
> relevance as IPv4 address in the context of evaluating an ip6 mech on an
> IPv6 connection. As if saying: "You have the right key, but you're trying
> to open the wrong door with it."


Ok, I'm far from an IPv6 expert, but my understanding is as follows:

Besides the case that Julian mentioned, where an OS may translate all
sockets, whether they are IPv4 or IPv6, into IPv6 sockets so that
applications just have to deal with one format, there are other cases.



It is quite possible to have a host that has IPv6 connectivity only,
just like it is possible to have only IPv4 connectivity. Such an IPv6
host will, for the next few decades, almost certainly need to use an
IPv4 gateway to access IPv4-only hosts. Such a gateway will act very
much like NAT gateways and the RFC1918 private addresses, such as the
10.x.y.z space. This includes having things similar to
port-forwarding where a connection on a certain IPv4 address on port
80 will get translated by the IPv6<->IPv4 gateway into a connection on
the IPv6-only host on port 80.

So, some IPv4-only machine goes off and tries to send mail to
ipv6-only.net. It will connect on some "IPv4" address and use port
80, which will automatically get run through the gateway.
ipv6-only.net will now see an IPv6 socket connection using an
IPv4-mapped IPv6 address.


Another case is that even if a host has both IPv4 and IPv6
connectivity, it may be the case that the fastest/best routing is to
use a IPv4<->IPv6 gateway and end up in a similar situation as above.
While this is almost never the case today, that could easily change in
another 10 years.


Corrections and/or questions are welcome. As I said, I'm not an IPv6
expert and I may misunderstand this and I certainly could be doing a
poor job of explaining it.



-wayne

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

> I am currently with the mutual exclusion party.

+1 Julian's position runs into contradictions wrt A vs. AAAA and
dualcidr.

Frank


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

It is not IP6 enabled MTAs that drive the decision (between BOTH and
EITHER), but IP4 only MTAs. While not explicit in the RFC, there was
an understanding that an IP4 only MTA could ignore IP6 and be a fully
conforming SPF implementation.

If the BOTH AND party wins, this will NOT be the case. IP4 only
implementations will have to evaluate IP6 mechs and lookup AAAA records,
just in case they might match ::FFFF:*. If you don't have this requirement,
then the SPF result for the same sender and connect ip will depend on whether
an IP4 or an IP6 MTA evaluates it - defeating the purpose of SPF
(to provide a consistent result based on sender and connect IP only).

Only the MUTUAL EXCLUSION party allows IP4 only hosts to ignore IP6 issues.
The vast majority of installed SPF checkers are IP4 only. A victory by
the BOTH AND party will make these formerly mostly compliant implementations
LESS compliant.

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

On Tuesday 28 November 2006 11:39, Stuart D. Gathman wrote:
> It is not IP6 enabled MTAs that drive the decision (between BOTH and
> EITHER), but IP4 only MTAs. While not explicit in the RFC, there was
> an understanding that an IP4 only MTA could ignore IP6 and be a fully
> conforming SPF implementation.
>
> If the BOTH AND party wins, this will NOT be the case. IP4 only
> implementations will have to evaluate IP6 mechs and lookup AAAA records,
> just in case they might match ::FFFF:*. If you don't have this
> requirement, then the SPF result for the same sender and connect ip will
> depend on whether an IP4 or an IP6 MTA evaluates it - defeating the purpose
> of SPF
> (to provide a consistent result based on sender and connect IP only).
>
> Only the MUTUAL EXCLUSION party allows IP4 only hosts to ignore IP6 issues.
> The vast majority of installed SPF checkers are IP4 only. A victory by
> the BOTH AND party will make these formerly mostly compliant
> implementations LESS compliant.

As I understand the issue, I agree. I think that the response that doing the
match is trivial ignores the fact that it's a concept that's not implemented
in the current IPv4 centric implementations and so holds no water.

Even if BOTH AND is theoretically more correct, the backward compatibility
issue trumps the theory in my book.

That said, if an IPv6 implementation wants to match ::FFFF:*, then I think
it's no harm. So I think that the IPv6 implementation MUST match ip4 and *
and MAY match ip6: ::FFFF:*. Record publishers MUST NOT depend on matching
ip6: ::FFFF:*.

Scott K

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

On Tue, 28 Nov 2006, Scott Kitterman wrote:
> On Tuesday 28 November 2006 11:39, Stuart D. Gathman wrote:
> > It is not IP6 enabled MTAs that drive the decision (between BOTH and
> > EITHER), but IP4 only MTAs. While not explicit in the RFC, there was
> > an understanding that an IP4 only MTA could ignore IP6 and be a fully
> > conforming SPF implementation.
> >
> > If the BOTH AND party wins, this will NOT be the case. IP4 only
> > implementations will have to evaluate IP6 mechs and lookup AAAA records,
> > just in case they might match ::FFFF:*. If you don't have this
> > requirement, then the SPF result for the same sender and connect ip will
> > depend on whether an IP4 or an IP6 MTA evaluates it - defeating the purpose
> > of SPF
> > (to provide a consistent result based on sender and connect IP only).
> >
> > Only the MUTUAL EXCLUSION party allows IP4 only hosts to ignore IP6 issues.
> > The vast majority of installed SPF checkers are IP4 only. A victory by
> > the BOTH AND party will make these formerly mostly compliant
> > implementations LESS compliant.
>
> As I understand the issue, I agree. I think that the response that doing the
> match is trivial ignores the fact that it's a concept that's not implemented
> in the current IPv4 centric implementations and so holds no water.
>
> Even if BOTH AND is theoretically more correct, the backward compatibility
> issue trumps the theory in my book.
>
> That said, if an IPv6 implementation wants to match ::FFFF:*, then I think
> it's no harm. So I think that the IPv6 implementation MUST match ip4 and *
> and MAY match ip6: ::FFFF:*. Record publishers MUST NOT depend on matching
> ip6: ::FFFF:*.

+1, this is where I sit on the issue.

--
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 <200611281150.10749.scott@kitterman.com> Scott Kitterman <scott@kitterman.com> writes:

> Even if BOTH AND is theoretically more correct, the backward compatibility
> issue trumps the theory in my book.

I also think that backwards compatibility is very important.

> That said, if an IPv6 implementation wants to match ::FFFF:*, then I think
> it's no harm. So I think that the IPv6 implementation MUST match ip4 and *
> and MAY match ip6: ::FFFF:*. Record publishers MUST NOT depend on matching
> ip6: ::FFFF:*.

Ok, so back to my question of what should this match:

"v=spf1 ip6:::FFFF:72.81.252.18 -all"

You are saying that it is ok to sometimes give a Pass and sometimes to
give a Fail?

Personally, I would rather not allow for inconsistent SPF results.
Are there any SPF implementations that will give a pass on this, other
than Julian's very recent one?


-wayne

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

On Tuesday 28 November 2006 12:02, wayne wrote:
> In <200611281150.10749.scott@kitterman.com> Scott Kitterman
<scott@kitterman.com> writes:
> > Even if BOTH AND is theoretically more correct, the backward
> > compatibility issue trumps the theory in my book.
>
> I also think that backwards compatibility is very important.
>
> > That said, if an IPv6 implementation wants to match ::FFFF:*, then I
> > think it's no harm. So I think that the IPv6 implementation MUST match
> > ip4 and * and MAY match ip6: ::FFFF:*. Record publishers MUST NOT depend
> > on matching ip6: ::FFFF:*.
>
> Ok, so back to my question of what should this match:
>
> "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>
> You are saying that it is ok to sometimes give a Pass and sometimes to
> give a Fail?
>
> Personally, I would rather not allow for inconsistent SPF results.

Agreed, but I also think that the chances of such a record ever being written
are low enough that it may not be worth worrying about.

Scott K

-------
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:
> > I am currently with the mutual exclusion party.
>
> +1 Julian's position runs into contradictions wrt A vs. AAAA and
> dualcidr.

How so?

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

iD8DBQFFbHEIwL7PKlBZWjsRAqOgAKD9gWVbFAfpOuAZ5K78VcLa9a12DQCg9xto
aUkCo6evffN9XdfhC8D9WII=
=bnab
-----END PGP SIGNATURE-----

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