Subject: [DNSOP] draft-ietf-dnsop-edns-client-subnet-01

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Jun 2015 11:25:24 +1000

Since draft-ietf-dnsop-edns-client-subnet-01 theoretically reverted
the changes made in -00 from draft-vandergaast-edns-client-subnet
then why is the last sentence here with a SHOULD.  MUST be omitted
would be correct to match draft-vandergaast-edns-client-subnet and
the IANA assignment of the option code.

   o  ADDRESS, variable number of octets, contains either an IPv4 or
      IPv6 address, depending on FAMILY, truncated to the number of bits
      indicated by the SOURCE PREFIX-LENGTH field, with bits set to 0 to
      pad to the end of the last octet needed.  Trailing all-zero octets
      SHOULD be omitted.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 11 Jun 2015 15:31:04 -0400

Mark Andrews writes:
> why is the last sentence here with a SHOULD.

It technically doesn't hurt anything to include them, because the
option length field of the opt rdata tells you how long the variable
part is.  If there is an important technical reason that MUST is
required here for interoperability I'm happy to change it, but it does
not appear to be a fundamental requirement.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Jun 2015 09:32:12 +1000

> not appear to be a fundamental requirement.

Well it makes extra work for parsers for no good reason.

10.0.0.0/7 requires checking 3 extra octets for all zeros.  Thats
additional code that needs to be written to cover the SHOULD that
doesn't need to be written to cover a MUST.

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

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 11 Jun 2015 21:02:24 -0400

> doesn't need to be written to cover a MUST.

But your code already has to check that the option length correctly
matches up.  Is anyone else seeing undue additional code complexity
here?

---

From: Tony Finch <[email-masked]>
Date: Fri, 12 Jun 2015 02:10:02 +0100

> matches up.  Is anyone else seeing undue additional code complexity

Wouldn't it be much simpler to use the normal fixed address length, so
that serializers and parsers can just choose a bcopy based on the address
family?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Utsire, Forties: Variable 3 or 4. Smooth or slight. Rain or drizzle at
times. Moderate or good, occasionally poor.

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 11 Jun 2015 21:57:07 -0400

> that serializers and parsers can just choose a bcopy based on the address

Simple in its way, yes, but of course there still has to be packet
parsing checks based on declared lengths.  That's where I'm not seeing
that SHOULD versus MUST is making any sort of meaningful
implementation complexity difference.

Also, when every byte counts for possibly having to end up doing tcp
fallback, saving one might make a difference of not having to do that.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Jun 2015 12:27:39 +1000

> fallback, saving one might make a difference of not having to do that.

bytes = (bits + 7) / 8

/* check lsb bits are zero */
if (bits % 8 != 0) {
	mask = ~0 << (8 - bits % 8);
	if ((x[bytes - 1] & mask) != x[bytes - 1])
		FORMERR;
}

/* check additional octets allowed by SHOULD are zero */
for (i = bytes; i < length; i++)
	if (x[i] != 0)
		FORMERR;

---

From: Wilmer van der Gaast <[email-masked]>
Date: Fri, 12 Jun 2015 12:42:22 +0100

Just to add my ¢2 on this point:

In the last version of the draft that I wrote (and the one used for
most implementations), there was no MUST/SHOULD terminology, so it was
a little vague.

Reason we've added the truncation at the time is to save space. This
is DNS, where saving bytes is sometimes still considered important.
With IPv4 the saving is ridiculously low, but with IPv6 with
truncation you can easily cut off 8 \0-bytes.

The original wording was kind of intended as a MUST, for example in
case of later versions of the draft having additional bits of info
after the address. But likely for a new version a new option code
would have to be used anyway so that's not really important.

I have no strong feelings about this. Slight preference for MUST, but
nothing's going to fall apart if this becomes a SHOULD. I've just
checked the parser in our codebase, it will just ignore extra bytes at
the end.