[RFCI-Discuss] IPv6 and BogusMX

[Jimmy Hess]

Derek J. Balling wrote:
> So there's been a lot of IPv6 talk lately, and what it means for bogusmx.
> Well, we've reached a critical-mass of "requests for support", so I've 
> begun testing a revamped bogusmx checker that (I *think*) will 
> adequately test bogusmx criteria in the IPv6 space.
Requests to be able to make queries over ipv6 to  rfci ? I don't think 
there are many V6 mail exchanges, yet.
> However, it's worth pointing out, that I personally know NOTHING about 
> IPv6 netmasks, etc.  I'm relying on a list of bogons detailed here:
>
An IPV6 address is 16 octets (128 bits)  in hexadecimal notation.  Every 
two octets are separated by a colon  (:)

IPV6  textual notation allows abbreviating long strings of zeros by 
placing a single ::  in an address.
For example,
fe80::21b:78ff:fe2d:8843 %eth0

is the same link-local address as
fe80:0000:0000:000:21b:78ff:fe2d:8843 %eth0

Netmasks are denoted by network prefix length, and work much the same as 
CIDR notation with ipv4.
Except that a "subnet" for a site should be  /64.
> So here's what I need, you can do this privately to me if you like:
>
>     - A couple syntactically valid IPv6 addresses ... things which I 
> could use to
>         - prove that doing a straight MX_hostname -> valid_ipv6 test 
> "passes"
>         - prove that doing MX points to IPv6 address fails
Well, MX RRs don't point to ip addresses, they contain a record
"owner" name in the DNS, i.e. of A, AAAA, or other record.
AAAA records contain IPV6 addresses   (128 bits in network-byte order).

There is the possibility of crazy but legitimate (textual) RR output like:

                                        86400 MX 2618:F360:000B::1234
2618:F360:000B::1234   86400 IN AAAA  2618:F360:000B::1234
myhost                            86400  CNAME 2618:F360:000B::1234



The important thing is that when you do a DNS MX query against that 
domain, the
result _contains_ a  name record for the MX label response  in the 
ADDITIONAL section of the
response to the query, with an A type,  AAAA type,  or both,  and that 
response in the additional
section is not a bogon.


The response in the additional section is in binary:   it has no syntax 
other than bits in network byte order.
 there's no way you can get a "AAAA" response and have it not be  be a 
syntactically valid Ipv6 address..

That's not to say whether the response is well-formed or not, it's just 
that it is impossible you see something like
"86400 AAAA  1234:this_address_has_invalid_characters_in_it:Q"

I would call that a very strange bug (of some sort) in the response 
parser/address printing subroutine.



>     - A couple RFC-bogus IP addresses (as defined by the 
> above-mentioned URL) so I can
>         - prove that situating an MX_hostname in bogon-IPv6-space will 
> generate a "fail"
There _really_ are not many  prefixes  that can't be valid.


I haven't seen a strict equivalent to IPv4's RFC1918 for IPv6 addresses  
that state  the "local only"
addresses _must_ be kept out of the DNS, though it's still a good idea, 
the RFCs may just not require it.



One prefix that (I believe) a normal mail server should not be within is 
this one:

FF00::/8      <== IPV6 multicast  addresses.

  IPv6's  rough equivalent to  "IPv4's broadcast addresses"  are also in 
this range and nowhere
  else  (link-local scoped all-nodes address, for example).


FE80::/10           <==  Link local Unicast      (These are valid but 
not globally routable)
FC00::/7             <==  Unique Local Unicast  (Globally unique, not 
supposed to be globally routable)



RFC4193 S 4.4
"At the present time, AAAA and PTR records for locally assigned local 
IPv6 addresses are not recommended to be installed in the global DNS."


It should be clear somewhere that it is not allowed to use a link-local 
MX address.
I just couldn't find it explicitly stated, so far.

Some domains may use intentionally unavailable MXes as part of an 
anti-spam scheme, but
the IPs  used should have proper RDNS, and at least one mail server 
operational at all times.


--
-Mysid