Subject: [spfbis] IPv4 mapped IPv6 addresses

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Apr 2013 14:59:58 -0700

Hello,

Section 5 of draft-ietf-spfbis-4408bis-14 has the following text:

   'When any mechanism fetches host addresses to compare with <ip>, when
    <ip> is an IPv4, "A" records are fetched; when <ip> is an IPv6
    address, "AAAA" records are fetched.  SPF implementations on IPv6
    servers need to handle both "AAAA" and "A" secords, for clients on
    IPv4 mapped IPv6 addresses [RFC4291].  IPv4 <ip> addresses are only
    listed in an SPF record using the "ip4" mechanism.'

Is the text about "IPv4 mapped IPv6 addresses" correct?

Regards,
S. Moonesamy (as document shepherd)

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Apr 2013 10:31:03 +0200

> Is the text about "IPv4 mapped IPv6 addresses" correct?

I, for one, have no idea what a "client on IPv4-mapped IPv6 address" 
might be. So the text doesn't look correct to me.

If you describe in a little bit more detail what the intent is, we can 
help you reformulate.

Simon

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Apr 2013 02:54:03 -0700

Hi Simon,
At 01:31 24-04-2013, Simon Perreault wrote:
>If you describe in a little bit more detail what the intent is, we 
>can help you reformulate.

Thanks for feedback.

For context the text is in the ninth paragraph of Section 5 of 
draft-ietf-spfbis-4408bis-14.  I'll rewrite the text as follows:

   SPF implementations on IPv6 servers need to handle both "AAAA" and
   "A" DNS records, for SMTP clients on IPv4 mapped IPv6 addresses [RFC4291].

The intent seems to be about an IPv4 host (client) connecting to an 
IPv6 host (server).  The IPv6 host matches the source IP address of 
the TCP connection against a list which may contain IPv4 mapped IPv6 
addresses.  Does that make sense or it is easier to forget about 
"IPv4 mapped IPv6 addresses"?

Regards,

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Apr 2013 13:33:21 +0200

>    "A" DNS records, for SMTP clients on IPv4 mapped IPv6 addresses

I'm sorry, I've read section 5 and that still doesn't make sense to me.

> The intent seems to be about an IPv4 host (client) connecting to an IPv6
> host (server).

How does that work? Is there a NAT46 in between?

> The IPv6 host matches the source IP address of the TCP
> connection against a list which may contain IPv4 mapped IPv6 addresses.
> Does that make sense or it is easier to forget about "IPv4 mapped IPv6
> addresses"?

As IPv4-mapped IPv6 addresses do not go on the wire, this still doesn't 
make sense to me!

IPv4-mapped IPv6 addresses have two uses:

1) They are used internally on a single host, between a userland app and 
the kernel, to represent IPv4 addresses using an IPv6-only socket. The 
address never leaves the host. It can be considered an implementation 
detail. They are most useful when porting an IPv4-only app to 
dual-stack. Newer applications should never use IPv4-mapped IPv6 
addresses, and it is good practice to disable them explicitly.

2) In various signalling protocols, to represent an IPv4 address in an 
IPv6 address field. This is protocol-specific. It is used only for 
signalling, never as actual addresses in IPv6 packet headers.

At this point, I'm guessing that it would be better to forget about 
IPv4-mapped IPv6 addresses, although I still don't understand exactly 
what your intent is.

Simon

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Apr 2013 07:04:55 -0700

Hi Simon,
>I'm sorry, I've read section 5 and that still doesn't make sense to me.

I share your opinion.

>How does that work? Is there a NAT46 in between?

That question was never discussed within the working group.  My guess 
is that there would have to be a transition mechanism in between for 
that to work.

>As IPv4-mapped IPv6 addresses do not go on the wire, this still 
>doesn't make sense to me!

I should have explained it better; the IPv4-mapped IPv6 address does 
not go over the wire.

>1) They are used internally on a single host, between a userland app 
>and the kernel, to represent IPv4 addresses using an IPv6-only 
>socket. The address never leaves the host. It can be considered an 
>implementation detail. They are most useful when porting an 
>IPv4-only app to dual-stack. Newer applications should never use 
>IPv4-mapped IPv6 addresses, and it is good practice to disable them explicitly.
>
>2) In various signalling protocols, to represent an IPv4 address in 
>an IPv6 address field. This is protocol-specific. It is used only 
>for signalling, never as actual addresses in IPv6 packet headers.
>
>IPv4-mapped IPv6 addresses, although I still don't understand 
>exactly what your intent is.

Thanks for the explanation.  The intent was to ask the IPv6 
Maintenance working group to review the text.  I'll follow your guess 
as it makes sense to me.  By the way you will be credited in the 
document shepherd write-up for your feedback.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 10:26:54 -0400

> document shepherd write-up for your feedback.

It was discussed.

The case here is #2.  In SPF there are various mechanisms that can be used in 
an SPF record to identify sources from which mail is authorized.  Two of these 
mechanisms directly specify IP addresses.  "ip4" is used to specify IPv4 
addresses and "ip6" is used to specify IPv6 addresses (that's a design 
decision that was made in 2003, so it is what it is).

The intent of the text was to communicate that if the SPF verification process 
(which could possibly be running in any internet networking environment you 
might think of) were presented with an IPv4-mapped IPv6 address, the correct 
way to check if that address is authorized is using the IPv4 part of the 
address to check against an "ip4" mechanism.

I hope that clarifies the intent.

If that makes sense, I would really appreciate suggestions as a better way to 
word it.

Scott K
(4408bis editor)

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 11:09:26 -0400

On Wednesday, April 24, 2013 04:56:33 PM Simon Perreault wrote:
> Le 2013-04-24 16:26, Scott Kitterman a écrit :
> > The case here is #2.  In SPF there are various mechanisms that can be used
> > in an SPF record to identify sources from which mail is authorized.  Two
> > of these mechanisms directly specify IP addresses.  "ip4" is used to
> > specify IPv4 addresses and "ip6" is used to specify IPv6 addresses
> > (that's a design decision that was made in 2003, so it is what it is).
> > 
> > The intent of the text was to communicate that if the SPF verification
> > process (which could possibly be running in any internet networking
> > environment you might think of) were presented with an IPv4-mapped IPv6
> > address, the correct way to check if that address is authorized is using
> > the IPv4 part of the address to check against an "ip4" mechanism.
> > 
> Very clear.
> One problem I can think of:
> 
> What is the effect of specifying IPv4-mapped IPv6 addresses in "ip6" SPF
> data? Or through a AAAA DNS record that the SPF "ip6" process looks up?
> If an SPF process that checks an IPv4-mapped IPv6 address uses
> exclusively the "ip4" SPF data, then IPv4-mapped IPv6 addresses in "ip6"
> data would be ignored. I would consider that surprising. For example, I
> would expect an SPF rule producing ::ffff:0.0.0.0/96 to apply to all
> IPv4-mapped IPv6 addresses, but it would simply get ignored.
> 
> Generally you want to treat IPv4-mapped IPv6 addresses like regular,
> opaque IPv6 addresses unless you have good and specific reasons not to
> do so.

My initial thought is you should have put that in an "ip4" mechanism.   Other 
way around (which is the concern that caused the text to be added) if the 
IPv4-mapped addresses are treated as IPv6 addresses, then senders who only 
used IPv4 might have to dual publish any IPv4 addresses in both "ip4" and 
"ip6" mechanisms.  That's bad in many ways.

The goal was to try and cover this case in a way that it was clear that this 
was the reciever's problem to sort out and the sender didn't have to double 
publish, just in case (I've seen people do this).

Suggestions?

Scott K

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Apr 2013 16:56:33 +0200

Very clear.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Apr 2013 17:15:37 +0200

> "ip6" mechanisms.  That's bad in many ways.

I guess I just don't understand where those IPv4-mapped IPv6 addresses 
that the SPF process needs to check are coming from. An example would be 
very helpful.

> publish, just in case (I've seen people do this).

Yeah, this is bad. Variants arise in many situations. Usually it is 
solved by treating IPv6 addresses as opaque and not giving any special 
meaning to the IPv4-mapped prefix.

Simon

---

From: Philipp Kern <[email-masked]>
Date: Wed, 24 Apr 2013 18:09:54 +0200

Simon,

am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben:
> I guess I just don't understand where those IPv4-mapped IPv6
> addresses that the SPF process needs to check are coming from. An
> example would be very helpful.

on Linux, if you set bindv6only to 0 and set up a socket listening on
AF_INET6 you are able to receive IPv4 connections to that IPv6 socket. The
source IPs will be mapped into IPv4-mapped IPv6 space. This means that you
only need to setup one socket instead of one for v4 and one for v6.

> solved by treating IPv6 addresses as opaque and not giving any
> special meaning to the IPv4-mapped prefix.

As above that does not help. If your SPF process is operating in the
setup above, IPv4-mapped IPv6 space needs to be treated with the IPv4
ruleset.

Kind regards
Philipp Kern

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 12:22:52 -0400

> setup above, IPv4-mapped IPv6 space needs to be treated with the IPv4

That sounds right.  Apparently I fail at describing it though.  Going back to 
the current text in the document:

Section 5 of draft-ietf-spfbis-4408bis-14:

I'd appreciate suggestions on making it clearer.

Thanks,

Scott K

---

From: Stuart Gathman <[email-masked]>
Date: Wed, 24 Apr 2013 12:21:53 -0400

Long ago, Nostradamus foresaw that on 04/24/2013 12:09 PM, Philipp Kern
> only need to setup one socket instead of one for v4 and one for v6.
As an example, if you want sendmail-8.14 to handle IP6, you configure it
for IP6, and IP4 connections are IP4 mapped.  I'm not sure where the
translation takes place (maybe even in the kernel), but the sender
socket address for IP4 mapped connections has address family IP4, and
milters and logs get the IP4 address.

So IP4 mapped IP6 connections MUST be treated exactly like an IP4
connection.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Apr 2013 18:27:19 +0200

> only need to setup one socket instead of one for v4 and one for v6.

I know what an IPv4-mapped IPv6 address is.

In that case, you should convert IPv4-mapped IPv6 addresses to IPv4 
addresses before feeding them to the SPF checker. Just like with any 
other protocol.

> setup above, IPv4-mapped IPv6 space needs to be treated with the IPv4

The SPF process should never see IPv4-mapped IPv6 addresses since the 
underlying layer needs to convert them to IPv4 addresses. There is 
nothing specific to the SPF protocol here.

Simon

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 12:46:28 -0400

> nothing specific to the SPF protocol here.

So from your perspective, we could remove that guidance and replace it with 
something along the lines of:

Check_host() [that's our generic SPF validation function name we use in the 
document] should never see IPv4-mapped IPv6 addresses.  The underlying layer 
needs to convert them to IPv4 addresses.

Is that about right?

Phil?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 12:55:19 -0400

On Wednesday, April 24, 2013 06:52:28 PM Simon Perreault wrote:
> Le 2013-04-24 18:46, Scott Kitterman a écrit :
> > document] should never see IPv4-mapped IPv6 addresses.  The underlying
> > layer needs to convert them to IPv4 addresses.
> > 
> > Is that about right?
> 
> Yes, that's perfect.
> 
> Now, there's nothing specific to SPF here, but I don't know of any
> general guidelines that you could reference, so feel free to go ahead
> with that.

Thanks.  I'll use that unless Phil responds and it turns out you two need to 
argue some more.

Scott K

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Apr 2013 18:52:28 +0200

Yes, that's perfect.

Simon

---

From: Tom Taylor <[email-masked]>
Date: Wed, 24 Apr 2013 12:57:16 -0400

Could I suggest the following:

- Keep the first sentence unchanged.

- Then:

   SPF implementations on IPv6 servers need to handle both
   "AAAA" and "A" records. This is because clients on IPv4
   mapped IPv6 addresses [RFC4291] will appear to the SPF
   implementation as IPv4 clients. Complementarily to this,
   SPF records for such clients must contain only IPv4 <ip>
   addresses.

> On Wednesday, April 24, 2013 06:09:54 PM Philipp Kern wrote:
...
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "John Levine" <[email-masked]>
Date: 24 Apr 2013 17:49:40 -0000

>needs to convert them to IPv4 addresses.

Depends on the implementation.  On FreeBSD, you sometimes see
addresses like ::ffff:1.2.3.4 which are mapped.

I think we should leave the text alone, since anyone implementing SPF
on dual stacked hosts should know what it means.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 11:10:36 -0700

On Wed, Apr 24, 2013 at 9:52 AM, Simon Perreault <
[email-masked]> wrote:

> Now, there's nothing specific to SPF here, but I don't know of any general
> guidelines that you could reference, so feel free to go ahead with that.
>
>
I like this, but I would change "needs" to "is expected".  (And be careful
with "should".)

-MSK

---

From: Philipp Kern <[email-masked]>
Date: Wed, 24 Apr 2013 20:50:05 +0200

> Thanks.  I'll use that unless Phil responds and it turns out you two need to 

I don't think so, that seems fine. ;-)

Indeed one would assume that guidance wrt IPv4-mapped IPv6 exists somewhere
already.

Kind regards
Philipp Kern

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Apr 2013 13:42:08 -0700

Hi Philipp,
>Indeed one would assume that guidance wrt IPv4-mapped IPv6 exists somewhere

I looked into this issue some time back but I could not find anything 
of use.  There is a short discussion at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03226.html  In 
my opinion the text could be used for a DISCUSS.  I do not know how 
to resolve that as SPFBIS WG participants have not provided any 
references to support the text.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 14:22:12 -0700

I think Scott's last suggestion is perfectly defensible.

On Wed, Apr 24, 2013 at 1:42 PM, S Moonesamy <[email-masked]> wrote:

> I looked into this issue some time back but I could not find anything of
> use.  There is a short discussion at http://www.ietf.org/mail-**
> archive/web/spfbis/current/**msg03226.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg03226.html> In my opinion the text could be used for a DISCUSS.  I do not know how to
> resolve that as SPFBIS WG participants have not provided any references to
> support the text.
>
> Regards,
> S. Moonesamy
> ______________________________**_________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/spfbis<https://www.ietf.org/mailman/listinfo/spfbis>
>

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Apr 2013 12:13:25 +0200

On Wed 24/Apr/2013 18:52:28 +0200 Simon Perreault wrote:
>> So from your perspective, we could remove that guidance and replace
>> it with something along the lines of:
>>
>>    Check_host() [that's our generic SPF validation function name
>>    we use in the document] should never see IPv4-mapped IPv6
>>    addresses.  The underlying layer needs to convert them to
>>    IPv4 addresses.
>>
>> Is that about right?
> 
> Yes, that's perfect.
> 
> general guidelines that you could reference, so feel free to go
> ahead with that.

It is not clear to me what underlying layer we'd refer to.  The kernel
obviously cannot do that if the socket is IPv6.

If we remove from Section 5 the sentence:

   SPF implementations on IPv6 servers need to handle both "AAAA"
   and "A" secords, for clients on IPv4 mapped IPv6 addresses
   [RFC4291].

Then, IMHO, we should append to Section 4.3 *Initial Processing* a
paragraph like:

   If the <ip> is an IPv4-mapped IPv6 address [RFC4291], substitute
   it with a true IPv4 address of that value.

In that case, the sentence:

   IPv4 <ip> addresses are only listed in an SPF record using the
   "ip4" mechanism.

should be moved from Section 5 to Section 5.6 *"ip4" and "ip6"*

jm2c

---

From: S Moonesamy <[email-masked]>
Date: Sat, 27 Apr 2013 07:49:36 -0700

>obviously cannot do that if the socket is IPv6.

Tim Taylor suggested some text [1].  There is also some text from 
Scott Kitterman [2].  Could someone please explain what this 
"underlying layer" is?

Regards,

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03440.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg03436.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 27 Apr 2013 09:11:24 -0700

As I understand it, the idea is that a connection arriving via an
IPv6-mapped IPv4 address is supposed to be reported to the accepting
application as an IPv4 connection, so SPF would never know about the
"IPv6-mapped" part in the first place.

On Sat, Apr 27, 2013 at 7:49 AM, S Moonesamy <[email-masked]> wrote:

> Tim Taylor suggested some text [1].  There is also some text from Scott
> Kitterman [2].  Could someone please explain what this "underlying layer"
> is?
>
>
> Regards,
> 1. http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03440.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg03440.html>
> 2. http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03436.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg03436.html>

---

From: "John Levine" <[email-masked]>
Date: 27 Apr 2013 18:53:01 -0000

>"IPv6-mapped" part in the first place.

It depends on the implementation.  Here in FreeBSD land, the preferred
way to listen to both IPv4 and IPv6 is to set up two sockets and
listen to both, but you can also flip a kernel setting, listen on one
IPv6 socket, and the IPv4 connections will show up in your application
on mapped addresses.

The current language on page 21 of the draft seems fine to me, at
worst harmless, and addresses the real situation I described above.

R's,
John

---

From: Commerco WebMaster <[email-masked]>
Date: Sat, 27 Apr 2013 15:32:34 -0600

> "IPv6-mapped" part in the first place.

Sort of.  There is a defined area of around 4 billion addresses within 
the IPv6 space that directly one to one map back to the entire IPv4 
space, which was limited by addresses that fit into an unsigned 32bit 
integer and kind of the reason why we ran out of the IPv4 address space 
to allocate.

I think the point of the discussion is that SPF might get requests via 
IPv6 which talk to using A records in the IPv4 space (that 4 billion 
limitation thingy).  IPv6 uses AAAA records to map the IPv6 addresses to 
the entire IPv6 name space.

However, while the IPv4 space is a rather small area within the IPv6 
space, for compatibility it would be rather important for IPv6 to be 
able to handle both A and AAAA records.  SPF must also be able to handle 
the reality that too it might be dealing with A record requests 
(from/for either IPv4 or IPv6 connections) and AAAA record requests 
(exclusively from/for IPv6 connections).

I think this is an attempt to acknowledge that SPF must incorporate the 
same kind of thinking as regards handling either A or AAAA records that 
the good people who handle DNS implementations have done to properly 
support the continuing migration from IPv4 to IPv6.

Hope that helped.

>
>
> On Sat, Apr 27, 2013 at 7:49 AM, S Moonesamy <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     1.
>     http://www.ietf.org/mail-__archive/web/spfbis/current/__msg03440.html <http://www.ietf.org/mail-archive/web/spfbis/current/msg03440.html>
>     2.
>     http://www.ietf.org/mail-__archive/web/spfbis/current/__msg03436.html <http://www.ietf.org/mail-archive/web/spfbis/current/msg03436.html>
>
>     _________________________________________________

Best,

Alan M.

---

From: Commerco WebMaster <[email-masked]>
Date: Sat, 27 Apr 2013 15:38:02 -0600

> worst harmless, and addresses the real situation I described above.

+1

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 29 Apr 2013 11:27:29 +0200

> IPv6 socket, and the IPv4 connections will show up in your application

AFAIK, the latter is the only case where mapped addresses show up.

> worst harmless, and addresses the real situation I described above.

+1, but if we are to improve that wording by using layers, the only
layering we can meaningfully refer to is that between the message
handler part of the verifier and check_host().  In that case, it makes
more sense to check for mapped addresses in the library, which is what
Mail::SPF does.  Accordingly, I'd address that point in the "Initial
Processing" section as mentioned at the end of
http://www.ietf.org/mail-archive/web/spfbis/current/msg03520.html

That would match smoothly with wordings such as "when <ip> is an
IPv4", as used in mechanism definitions.  In either case, wordings
such as "appropriate for the connection type" might appear ambiguous
to an idiotic reader.