Mailing List Archive: New poll on the IP4 mapped IP6 connection controversy

New poll on the IP4 mapped IP6 connection controversy

Nov 28, 2006, 10:18 AM

Post #1 of 13 (7780 views)

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

> [large snip]

I agree with all of that....

> Therefore, as test-suite czar, I declare the MUTUAL EXCLUSION party the
> winner, [...]

However, I would like to wait to hear more people chim in before
declaring a winner. I don't see any reason why this issue needs to be
decided quickly, it has been lurking in the spec for years, after
all.

And, for what it is worth, I'm still doing research into this to see
what what previously said on the subject.

What should happen when you get an SPF check using example.com and
72.81.252.18:

example.com TXT "v=spf1 ip6:::FFFF:72.81.252.18 -all"

1) The SPF result is well defined and the result is Fail. An ip6:
mechanism that lists an IPv4-mapped IPv6 address is effectively a
no-op and will never be matched.

2) The SPF result is well defined and the result is Pass. All SPF
implementations must check both ip4: and ip6: mechanisms.

3) The SPF result is well defined and it depends on whether the
connecting SMTP session is on an IPv6 socket or an IPv4 socket. If
it is on an IPv4 socket, the result is Fail, if it is on an IPv6
socket, the result is Pass.

4) The SPF result is undefined and implementations can choose to match
or not match this.

5) Some other case

Next, what should happen when you get an SPF check using example.org and
72.81.252.18:

example.org TXT "v=spf1 a -all"
AAAA ::FFFF:72.81.252.18

1) The SPF result is well defined and the result is Fail. An AAAA
record that lists an IPv4-mapped IPv6 address is effectively a
no-op and will never be matched.

2) The SPF result is well defined and the result is Pass. All SPF
implementations must check both A and AAAA records.

3) The SPF result is well defined and it depends on whether the
connecting SMTP session is on an IPv6 socket or an IPv4 socket. If
it is on an IPv4 socket, the result is Fail, if it is on an IPv6
socket, the result is Pass.

4) The SPF result is undefined and implementations can choose to match
or not match this.

5) Some other case

Again, while I think these cases will be somewhat rare, I do see them
happening. I think that as IPv6 becomes more common, people will
start thinking in terms of IPv6 addresses and won't always recognize
that ::FFFF:4851:FC12 is really an IPv4-mapped IPv6 address and the
same as ::FFFF:72.81.252.18. I think people will start adding AAAA
records with IPv4-mapped addresses either accidentally or in order to
save an extra lookup for the equivalent A record. I think people will
make typos such as "ip6::1234:5678:9ABC/8" when they meant to have a
"/48".

-wayne

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

stuart at bmsi

Nov 28, 2006, 11:22 AM

Post #2 of 13 (7650 views)

Permalink

On Tue, 28 Nov 2006, wayne wrote:

> > Therefore, as test-suite czar, I declare the MUTUAL EXCLUSION party the
> > winner, [...]
>
> However, I would like to wait to hear more people chim in before
> declaring a winner. I don't see any reason why this issue needs to be
> decided quickly, it has been lurking in the spec for years, after
> all.

The spec was perfectly clear to me when adding IP6 support to pyspf:
"Even if the SMTP connection is via IPv6, an IPv4-mapped IPv6 IP address MUST
still be considered an IPv4 address." It never even crossed my mind that it
might mean BOTH IPv4 AND IPv6. The word "even" effectively means "and not as
IPv6". Furthermore, IP6 support is simpler with the hole. You take either
the IP6 or the IP4 branch - never both. The BOTH AND would add a third case:
IP6 branch, IP4 socket branch, IP4 mapped IP6 branch. We are not actually
messing up IP6 address space. The split is only for the SPF evaluation
purposes.

I am only taking a second look because of great respect for Julian -
maybe I was missing something. I am quite sure now I didn't miss
anything. I understand how creating a hole in the IPv6 address space
for IPv4 mapped addresses is ugly, and that Julian hates that. But, that is
what RFC4408 says. Furthermore, it is logically necessary to allow IPv4 only
implementation to ignore IP6 issues.

> And, for what it is worth, I'm still doing research into this to see
> what what previously said on the subject.

Ok. I'll wait.

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

william at elan

Nov 28, 2006, 11:28 AM

Post #3 of 13 (7693 views)

Permalink

On Tue, 28 Nov 2006, wayne wrote:

> What should happen when you get an SPF check using example.com and
> 72.81.252.18:
>
> example.com TXT "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>
>
> 1) The SPF result is well defined and the result is Fail. An ip6:
> mechanism that lists an IPv4-mapped IPv6 address is effectively a
> no-op and will never be matched.
>
> 2) The SPF result is well defined and the result is Pass. All SPF
> implementations must check both ip4: and ip6: mechanisms.
>
> 3) The SPF result is well defined and it depends on whether the
> connecting SMTP session is on an IPv6 socket or an IPv4 socket. If
> it is on an IPv4 socket, the result is Fail, if it is on an IPv6
> socket, the result is Pass.
>
> 4) The SPF result is undefined and implementations can choose to match
> or not match this.

3 if you want to be that precise and actually mention it, otherwise 4

--
William Leibzon
Elan Networks
william@elan.net

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

stuart at bmsi

Nov 28, 2006, 11:34 AM

Post #4 of 13 (7644 views)

Permalink

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

> IPv6". Furthermore, IP6 support is simpler with the hole. You take either
> the IP6 or the IP4 branch - never both. The BOTH AND would add a third case:
> IP6 branch, IP4 socket branch, IP4 mapped IP6 branch. We are not actually
> messing up IP6 address space. The split is only for the SPF evaluation
> purposes.

Scratch that. I guess BOTH AND would require expanding IP4 socket
connections to ::FFFF:* and evaluating IP6 and fetching AAAA (despite
RFC explicitly saying not to). So there are still only two cases.

Here is another argument. If everyone jumps on the BOTH AND bandwagon,
and most implementations comply, then the DOS amplification jumps
from 10 to 20. An attacker can get 10 A plus 10 AAAA lookups for each
A mech or MX RR. You don't want to give DougO more ammunition do you?
(He'll wave his hands until 20 turns into 5000).

The MUTUAL EXCLUSION principal stated explicitly (but apparently not
clearly enough for some) in RFC4408 5/15 provides for only one A or AAAA lookup
per A mech or MX RR, not two.

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

stuart at bmsi

Nov 28, 2006, 11:38 AM

Post #5 of 13 (7649 views)

Permalink

On Tue, 28 Nov 2006, william(at)elan.net wrote:

> > 3) The SPF result is well defined and it depends on whether the
> > connecting SMTP session is on an IPv6 socket or an IPv4 socket. If
> > it is on an IPv4 socket, the result is Fail, if it is on an IPv6
> > socket, the result is Pass.
> >
> > 4) The SPF result is undefined and implementations can choose to match
> > or not match this.
>
> 3 if you want to be that precise and actually mention it, otherwise 4

The issue is what the RFC says, not what the RFC should have said.

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

wayne at schlitt

Nov 28, 2006, 11:38 AM

Post #6 of 13 (7630 views)

Permalink

In <Pine.LNX.4.62.0611281126200.422@sokol.elan.net> "william(at)elan.net" <william@elan.net> writes:

> On Tue, 28 Nov 2006, wayne wrote:
>
>> What should happen when you get an SPF check using example.com and
>> 72.81.252.18:
>>
>> example.com TXT "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>>
>
> 3 if you want to be that precise and actually mention it, otherwise 4

Thanks for your input William.

What do you think about the other case, which uses AAAA records?

Are these the same, and if not, why not?

Actually, I'd be interested in hearing your reasoning behind choice of
option 3) or 4).

-wayne

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

wayne at schlitt

Nov 28, 2006, 11:39 AM

Post #7 of 13 (7641 views)

Permalink

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

> What should happen when you get an SPF check using example.com and
> 72.81.252.18:
>
> example.com TXT "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>
>
> 1) The SPF result is well defined and the result is Fail. An ip6:
> mechanism that lists an IPv4-mapped IPv6 address is effectively a
> no-op and will never be matched.

My understanding is that this has always been the correct answer.

> Next, what should happen when you get an SPF check using example.org and
> 72.81.252.18:
>
> example.org TXT "v=spf1 a -all"
> AAAA ::FFFF:72.81.252.18
>
> 1) The SPF result is well defined and the result is Fail. An AAAA
> record that lists an IPv4-mapped IPv6 address is effectively a
> no-op and will never be matched.

My understanding is that this has always been the correct answer.

-wayne

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

william at elan

Nov 28, 2006, 11:43 AM

Post #8 of 13 (7625 views)

Permalink

On Tue, 28 Nov 2006, william(at)elan.net wrote:

> On Tue, 28 Nov 2006, wayne wrote:
>
>> What should happen when you get an SPF check using example.com and
>> 72.81.252.18:
>>
>> example.com TXT "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>>
>>
>> 1) The SPF result is well defined and the result is Fail. An ip6:
>> mechanism that lists an IPv4-mapped IPv6 address is effectively a
>> no-op and will never be matched.
>>
>> 2) The SPF result is well defined and the result is Pass. All SPF
>> implementations must check both ip4: and ip6: mechanisms.
>>
>> 3) The SPF result is well defined and it depends on whether the
>> connecting SMTP session is on an IPv6 socket or an IPv4 socket. If
>> it is on an IPv4 socket, the result is Fail, if it is on an IPv6
>> socket, the result is Pass.
>>
>> 4) The SPF result is undefined and implementations can choose to match
>> or not match this.
>
> 3 if you want to be that precise and actually mention it, otherwise 4

BTW, I think instead of worrying about above, developers need to make
sure that when users do receive IPv6 connection but the other end is
ipv4 mapped address that they can use ipv4 rules when checking SPF.
That is a lot more of an issue then supposed case when somebody puts
ipv6 mapped address directly in SPF - for that case I think people need
to be warned not to do it, without it being specifically disallowed.

--
William Leibzon
Elan Networks
william@elan.net

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

william at elan

Nov 28, 2006, 11:49 AM

Post #9 of 13 (7649 views)

Permalink

On Tue, 28 Nov 2006, wayne wrote:

> In <Pine.LNX.4.62.0611281126200.422@sokol.elan.net> "william(at)elan.net" <william@elan.net> writes:
>
>> On Tue, 28 Nov 2006, wayne wrote:
>>
>>> What should happen when you get an SPF check using example.com and
>>> 72.81.252.18:
>>>
>>> example.com TXT "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>>>
>>
>> 3 if you want to be that precise and actually mention it, otherwise 4
>
> Thanks for your input William.
>
> What do you think about the other case, which uses AAAA records?
>
> Are these the same, and if not, why not?
>
> Actually, I'd be interested in hearing your reasoning behind choice of
> option 3) or 4).

Because I think should not use IPv4 mapped IPv6 addresses in
configuration unless their server is specifically only configured
to accept IPv6 connections.

--
William Leibzon
Elan Networks
william@elan.net

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

stuart at bmsi

Nov 28, 2006, 11:50 AM

Post #10 of 13 (7651 views)

Permalink

On Tue, 28 Nov 2006, wayne wrote:

> 1) The SPF result is well defined and the result is Fail. An ip6:
> mechanism that lists an IPv4-mapped IPv6 address is effectively a
> no-op and will never be matched.

1) The SPF result is well defined and the result is Fail. An ip6:
mechanism that lists an IPv4-mapped IPv6 address is effectively a
no-op and will never be matched. However, senders should avoid
publishing such a policy because some implementations may
get it wrong.

In addition to IP6 and A vs AAAA, the BOTH AND party needs to deal
with the %{v} macro. What should it expand to for a ::FFFF:* connection?
BOTH "in-addr" AND "ip6" ?

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

stuart at bmsi

Nov 28, 2006, 11:53 AM

Post #11 of 13 (7650 views)

Permalink

On Tue, 28 Nov 2006, william(at)elan.net wrote:

> > Actually, I'd be interested in hearing your reasoning behind choice of
> > option 3) or 4).
>
> Because I think should not use IPv4 mapped IPv6 addresses in
> configuration unless their server is specifically only configured
> to accept IPv6 connections.

The *receiver* decides whether to accept only IP6 connections. Whose
configuration are you talking about? Sender or receiver?

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

william at elan

Nov 28, 2006, 12:02 PM

Post #12 of 13 (7647 views)

Permalink

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

> On Tue, 28 Nov 2006, william(at)elan.net wrote:
>
>>> 3) The SPF result is well defined and it depends on whether the
>>> connecting SMTP session is on an IPv6 socket or an IPv4 socket. If
>>> it is on an IPv4 socket, the result is Fail, if it is on an IPv6
>>> socket, the result is Pass.
>>>
>>> 4) The SPF result is undefined and implementations can choose to match
>>> or not match this.
>>
>> 3 if you want to be that precise and actually mention it, otherwise 4
>
> The issue is what the RFC says, not what the RFC should have said.

You're talking about suggestions for developers on how to handle
certain issue which is to a degree the same.

--
William Leibzon
Elan Networks
william@elan.net

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

Re: New poll on the IP4 mapped IP6 connection controversy [ In reply to ]

wayne at schlitt

Nov 28, 2006, 12:09 PM

Post #13 of 13 (7643 views)

Permalink

In <Pine.LNX.4.62.0611281145050.422@sokol.elan.net> "william(at)elan.net" <william@elan.net> writes:

> On Tue, 28 Nov 2006, wayne wrote:
>
>> In <Pine.LNX.4.62.0611281126200.422@sokol.elan.net> "william(at)elan.net" <william@elan.net> writes:
>>
>>> On Tue, 28 Nov 2006, wayne wrote:
>>>
>>>> What should happen when you get an SPF check using example.com and
>>>> 72.81.252.18:
>>>>
>>>> example.com TXT "v=spf1 ip6:::FFFF:72.81.252.18 -all"
>>>>
>>>
>>> 3 if you want to be that precise and actually mention it, otherwise 4
>>
>> What do you think about the other case, which uses AAAA records?
>>
>> Are these the same, and if not, why not?

I'm still curious about the answers to these two questions...

In a different post, William wrote:

>>> 3) The SPF result is well defined and it depends on whether the
>>> connecting SMTP session is on an IPv6 socket or an IPv4 socket. If
>>> it is on an IPv4 socket, the result is Fail, if it is on an IPv6
>>> socket, the result is Pass.
>>>
>>> 4) The SPF result is undefined and implementations can choose to match
>>> or not match this.
>>
>> 3 if you want to be that precise and actually mention it, otherwise 4
>
> BTW, I think instead of worrying about above, developers need to make
> sure that when users do receive IPv6 connection but the other end is
> ipv4 mapped address that they can use ipv4 rules when checking SPF.
> That is a lot more of an issue then supposed case when somebody puts
> ipv6 mapped address directly in SPF - for that case I think people need
> to be warned not to do it, without it being specifically disallowed.

I guess I see this as being somewhat contradictory.

If it is ok for an SPF implementation to choose to only check ip4:
mechanisms if it has an IPv4 socket and ip6: mechanisms if it has an
IPv6 socket, why should it be forced to check ip4: mechanisms if it
has an IPv6 socket?

I guess I really shouldn't have tried to give an exhaustive list,
Stuart is quite right to add the "but people shouldn't add IPv4-mapped
addresses to the SPF records" to my option 1) in his response. I'm
not trying to put words into your mouth, I'm trying to figure out what
a rough consensus should be.

While I agree that publishers *SHOULD* not publish SPF records with
IPv4-mapped addresses, I don't see any point in adding new undefined
behavior to the SPF results. Is there some reason why this should be
left up to the implementation?

-wayne

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