Subject: [spfbis] New (minor) issue: Inconsistency on ip4: address format

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Oct 2012 00:53:01 -0400

The ABNF for an IPv4 address is:

ip4-network      = qnum "." qnum "." qnum "." qnum

(paragraph 5.6 and the collected ABNF).

At the beginning of paragraph 5 there is a general statement about how ip4/6 
mechanisms with CIDR lengths are processed:

   If a CIDR prefix length is specified, then only the specified number
   of high-order bits of <ip> and the IP address are compared for
   equality.

Both of these items are unchanged between RFC 4408 and the current WG draft.

I just got an email complaining that my SPF record validator was wrong because 
it calls ip4:198.51.100/24 a syntax error (which it is per the ABNF) because 
the correspondent claimed that since the low-order bits weren't compared for 
equality, they didn't need to be provided.

I can see the source of their confusion.

Is the sentence about only comparing the specified number of high order bits 
really needed or is that just a note about implementation?  If we could just 
drop it, it would remove this source of confusion.  As long as it wouldn't 
lose something substantive in the processing definition, I think we should do 
that.

Opinions?

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Fri, 26 Oct 2012 13:43:13 -0400

I would prefer to add to the sentence in paragraph 5, making it something
like, "...compared for equality.  The entire IP address is nevertheless
specified, with the non-compared bits set to zero."

Barry, participant

On Friday, October 26, 2012, Scott Kitterman wrote:

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

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Oct 2012 18:16:05 -0400

> specified, with the non-compared bits set to zero."

Thanks Barry.  I like that.

For IPv6, there is a different type of definition in the ABNF:

   ip6-network      = <as per [RFC 4291], section 2.2>
            ; e.g., 2001:DB8::CD30

As I read that, the "entire IP address" requirement only applies to IPv4.  Is 
that right?

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Fri, 26 Oct 2012 21:54:01 -0400

> As I read that, the "entire IP address" requirement only applies to IPv4.

Yes, that's right.

b

---

From: "John Levine" <[email-masked]>
Date: 27 Oct 2012 03:00:30 -0000

>As I read that, the "entire IP address" requirement only applies to IPv4.  Is 

The usual syntax for writing IPv6 addresses uses :: to abbreviate a string of
zeros.  So the SPF record for my outgoing mail includes this:

  ip6:2001:470:1f07:1126::/64

That is an entire IPv6 address, even though the low 64 bits are only
implicitly specified.

So the literal answer to your question is no, since you have to
provide an entire IPv6 address, but that address is usually written in
a way that elides the boring low bits.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 28 Oct 2012 00:33:44 -0700

> specified, with the non-compared bits set to zero."

I don't know if it affects this question or not, or how we word the
specification, but conventional implementations of inet_addr() would
interpret the string "198.51.100" by saying the first octet is 198,
the second is 51, and the third and fourth combined are 100.  I think
this goes back to pre-CIDR implementations.

Yuck, I know.  But it's a fairly ubiquitous function by now.

-MSK