Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words

From: "John Levine" <[email-masked]>
Date: 9 Feb 2013 18:04:39 -0000

>> "IPv4-mapped IPv6 address" as it is not easy to fix.
>
>I don't think not mentioning it is a good option.  I'll figure something out.

Perhaps don't explain them, just mention them, e.g.

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

If a coder doesn't know enough about IPv6 to know what they are already, we're
not going to solve that problem.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 Feb 2013 13:16:51 -0500

On Saturday, February 09, 2013 06:04:39 PM John Levine wrote:
>   SPF implementations on IPv6 servers need to handle both AAAA and A
> records, for clients on IPv4 mapped IPv6 addresses [RFC4291].
> 
> If a coder doesn't know enough about IPv6 to know what they are already,
> we're not going to solve that problem.

For coders writing SPF libraries, I think that's sufficient. Thanks.

I lot of people that try to write SPF records for their domains are much less 
technical (imagine for a moment how much the average non-technical domain 
owner knows about DNS and then realize half of them know less than that).  
Most of them don't read RFCs, so maybe it's not important, but perhaps 
something like:

> SPF implementations on IPv6 servers need to handle both AAAA and A
> records, for clients on IPv4 mapped IPv6 addresses [RFC4291].  IPv4 IP
> addresses are listed an SPF record using the "ip4" mechanism as IPv4
> addresses.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Sat, 9 Feb 2013 14:31:18 -0500

>> we're not going to solve that problem.
...
> owner knows about DNS and then realize half of them know less than that).

A side note on these comments, which we shouldn't further discuss here
(maybe take it to <[email-masked]> if you like) is that directorate
reviewers and other-area ADs often comment on something for which the
response is that anyone in the [X] community will understand this, and
we don't need to explain it.  I have a mixed view of that.  On the one
hand, no document can explain (nor cite) everything, and there'll
always be stuff for which we have to assume knowledge.  On the other
hand, we all know about plenty of poor implementations done by people
who *did not* understand what we assumed they would.

This goes to a broader question of how accessible our standards
specifications need to be to those who are *not* expert in the
technology they're trying to work with.  I have it on my list of
topics to discuss at this year's IESG "retreat".

Back to the real topics at hand....

Barry

---

From: SM <[email-masked]>
Date: Sat, 09 Feb 2013 15:21:22 -0800

Hi John,
>   for clients on IPv4 mapped IPv6 addresses [RFC4291].

The SPF implementation would have to support IPv6 [1].  A reviewer 
may ask what the above means.  Somebody would then have to explain that.

Regards,
-sm

1. "v=spf1 ip4:12.22.58.0/26 ip4:64.170.98.0/26 ip4:209.208.19.192/27 
ip6:2607:f170:8000:1500::0/64 ip6:2001:1890:123a::0/56 
ip6:2001:1890:126c::0/56 -all"

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2013 00:55:01 -0000

>may ask what the above means.  Somebody would then have to explain that.

If they do, which I think is unlikely, the answer is "It's part of
IPv6 addressing.  See the reference."

Having actually written IPv6 mail software, I can say it really is
something that anyone who programs for IPv6 would know about.  It's
like writing DNS software and knowing what SRV records are.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 Feb 2013 20:11:49 -0500

SM <[email-masked]> wrote:

>records,

IPv6 support isn't optional,  so I'm not sure what you mean? 

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 9 Feb 2013 20:33:33 -0500

There are two versions of IP6 support at the receiver side.

  - SPF IP6 syntaxes, directive parsing support, and
  - A Full implementation with IP6 Stack/Layer support.

At the publisher side, it needs to do IP4/IP6 mapping or provide the policy that will work for either IP4 or IP6 ready receivers.

I believe our IP4 only SPF verifier code right now skips over IP6 rules.

BIS needs to ready for the spectrum of possible IP4/IP6 interfaces, including that many still don't a sh-t about IP6.  Don't wish people time enforcing something that is still impractical for many still today.
 
----- Original Message ----- 
From: "SM" <[email-masked]>
To: "John Levine" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, February 09, 2013 6:21 PM
Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words

> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 9 Feb 2013 20:35:49 -0500

----- Original Message ----- 
From: "Scott Kitterman" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, February 09, 2013 8:11 PM
Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words

> IPv6 support isn't optional,  so I'm not sure what you mean? 

Parsing support is the minimum scott, i.e. so that you don't generate a PermError, etc. The publisher needs to be told that it can not assume a IP6 only world. If he has IP6 interest, he needs to be aware of mapping and IP4 level stacks and the policy should, if possible, reflect it.

--

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 Feb 2013 23:48:45 -0500

On Saturday, February 09, 2013 08:33:33 PM Hector Santos wrote:
> At the publisher side, it needs to do IP4/IP6 mapping or provide the policy
> that will work for either IP4 or IP6 ready receivers.
> 
> BIS needs to ready for the spectrum of possible IP4/IP6 interfaces,
> including that many still don't a sh-t about IP6.  Don't wish people time
> enforcing something that is still impractical for many still today.

If you are on an IPv4 only host, you'll never need to match an ip6: mechanism, 
so no need to worry about it.  If you check SPF with a code base that doesn't 
know about ip6: and AAAA on a host with IPv6 connectivity, you're doomed and 
there's nothing a specification can do to help you.

For specific cases, it may be OK to deploy code that doesn't process the IPv6 
related SPF features, but for general purpose systems, you really do need it.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 Feb 2013 23:50 -0500

On Saturday, February 09, 2013 08:35:49 PM Hector Santos wrote:
> Parsing support is the minimum scott, i.e. so that you don't generate a
> PermError, etc. The publisher needs to be told that it can not assume a IP6
> only world. If he has IP6 interest, he needs to be aware of mapping and IP4
> level stacks and the policy should, if possible, reflect it.

I think my proposed language does that.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 10 Feb 2013 00:52:16 -0500

On Saturday, February 09, 2013 01:16:51 PM Scott Kitterman wrote:
> I lot of people that try to write SPF records for their domains are much
> less technical (imagine for a moment how much the average non-technical
> domain owner knows about DNS and then realize half of them know less than
> that). Most of them don't read RFCs, so maybe it's not important, but
> perhaps
> something like:

Here's what I have committed locally for -11:

      When any mechanism fetches host addresses to compare with &lt;ip&gt;,
      when &lt;ip&gt; is an IPv4, A records are fetched; when &lt;ip&gt; 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 <xref target="RFC4291"/>.  IPv4 &lt;ip&gt;
      addresses are only listed in an SPF record using the "ip4" mechanism.

Scott K

---

From: SM <[email-masked]>
Date: Sun, 10 Feb 2013 16:10:59 -0800

Hi Scott,
>IPv6 support isn't optional,  so I'm not sure what you mean?

My reading of the text is that there are:

   (i)   SPF implementations on IPv6 servers
   (ii)  SPF implementations not on IPv6 servers

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 10 Feb 2013 21:33:57 -0500

>   (ii)  SPF implementations not on IPv6 servers

OK. Thanks for the clarification. I think the proposed text I have for -11 addresses both cases.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 11 Feb 2013 11:16:06 +0100

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

Does the last sentence mean that terms like ip6:::ffff:c0.0.2.1 are
illegal?  What should implementations do when they find one?

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 Feb 2013 06:23:16 -0500

>illegal?  What should implementations do when they find one?

You can only get connections from valid addresses.  If you're getting invalid addresses, it should be dealt with at a lower level. 

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Feb 2013 07:33:54 -0800

I don't think this is a big concern for SPF implementations.  That kind of
thing is typically passed directly to inet_pton() or such, which implements
standards (either published or de facto) for converting between internal
integer forms and presentation forms.  Relying on them to do the right
thing seems fine to me.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 11 Feb 2013 20:55:36 +0100

On Mon 11/Feb/2013 16:33:54 +0100 Murray S. Kucherawy wrote:
> I don't think this is a big concern for SPF implementations.  That
> kind of thing is typically passed directly to inet_pton() or such,
> which implements standards (either published or de facto) for
> converting between internal integer forms and presentation forms. 
> Relying on them to do the right thing seems fine to me.

Probably yes.  However, some examples, specially for IPv4-mapped
cases, might clarify doubts such as the meaning of:

 IN TXT "v=spf1 ip4:192.0.2.1 ip6:::ffff:192.0.2.2 -all"

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 Feb 2013 15:08:19 -0500

>  IN TXT "v=spf1 ip4:192.0.2.1 ip6:::ffff:192.0.2.2 -all"

I don't think there's any doubt about what those mean.  The ip6: mechanism is 
redundant and shouldn't be in the record.  OTOH, it's presence isn't a major 
problem. Since ip6: requires no DNS lookups, the only effect is a slightly 
larger record and a few more bits on the wire.

Such redundancies should be discourages operationally, but I think the 
protocol can ignore them.

Scott K

---

From: Stuart Gathman <[email-masked]>
Date: Mon, 11 Feb 2013 22:06:51 -0500

> there's nothing a specification can do to help you.
Actually, even on an IPv4 only host, you have to parse ip6 mechanisms 
and issue PermError for syntax errors to be compliant. Parsing is just a 
matter of a regex derived fairly directly from rfc 3986, so it shouldn't 
be a problem.

So for instance, your Ipv4 only implementation is deficient if it fails 
to issue PermError for:

v=spf1 ip6:1234:0 -all

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 12 Feb 2013 15:48:31 +0100

On Tue 12/Feb/2013 04:06:51 +0100 Stuart Gathman wrote:
> and issue PermError for syntax errors to be compliant. Parsing is just
> a matter of a regex derived fairly directly from rfc 3986, so it
> shouldn't be a problem.

Hey, in Section 3.2.2 of RFC 3986 are the production rules "we didn't
find [it] in 2005", as Scott replied to Murray in July (find qnum in:
http://www.ietf.org/mail-archive/web/spfbis/current/msg01842.html )

We can import IPv6address and IPv4address from there, can't we?