Subject: 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: Simon Perreault <[email-masked]>
Date: Wed, 24 Apr 2013 13:33:21 +0200

Le 2013-04-24 11:54, S Moonesamy a écrit :
> Hi Simon,
> At 01:31 24-04-2013, Simon Perreault wrote:
> 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].

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

   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: 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: Simon Perreault <[email-masked]>
Date: Wed, 24 Apr 2013 16:56:33 +0200

> I hope that clarifies the intent.

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.

Simon

---

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

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 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: 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: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: Simon Perreault <[email-masked]>
Date: Wed, 24 Apr 2013 18:50:52 +0200

>      listed in an SPF record using the "ip4" mechanism.'

This is very wrong. IPv4-mapped IPv6 addresses resulting from the use of 
AF_INET6 sockets with bindv6only=0 are an *implementation detail*.  The 
draft should focus exclusively on externally-observable behaviour. Since 
there is no IPv4-mapped IPv6 address anywhere in the packets, you should 
not say anything at all. Doing otherwise is just creating confusion.

Simon

---

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

Le 2013-04-24 18:46, Scott Kitterman a écrit :
> 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.

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.

Simon

---

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

Is that about right?

Phil?

Scott K

---

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: Philipp Kern <[email-masked]>
Date: Wed, 24 Apr 2013 20:50:05 +0200

On Wed, Apr 24, 2013 at 12:55:19PM -0400, Scott Kitterman wrote:
> Thanks.  I'll use that unless Phil responds and it turns out you two need to 
> argue some more.

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

Scott K

---

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