Thursday, September 29, 2011

Speaking of filters - my segment of the BT Tower webcast

As a follow up to my post-live webcast blogpost, here is just my segment from the webcast where I talk about IPv6. Enjoy!

Handy AAAA filter in BIND 9.8

The ISC introduced a pair of new configuration file options in BIND 9.8 to enable administrators to easily filter who may receive AAAA record type responses even if valid responses exist. For example, clients on subnets that do not have IPv6 network access can be excluded from receiving affirmative answers for AAAA queries. This feature provides simpler administration than the alternative mechanism using views.

The first option, filter-aaaa-on-v4,defines whether the server will return AAAA records to certain clients. Such clients are defined by the address match list parameter of the second option, filter-aaaa. Note that BIND must be compiled with the --enable-filter-aaaa option on the configure command line to enable AAAA filtering. The syntax of these options is as follows:

  • filter-aaaa-on-v4 (yes | no | break-dnssec) ;
  • filter-aaaa {addr_match_list;} ;

The filter-aaaa option identifies the address match list for which the filter-aaaa-on-v4 option is to be applied as described next. Multiple filter-aaaa options may be defined. The default is any.

If the filter-aaaa-on-v4 option is set to yes, AAAA records are filtered out of (not included in) the response if the client falls within the filter-aaaa address match list and no DNSSEC signatures are included. If set to no, such filtering is not performed and AAAA records are returned. If set to break-dnssec, the AAAA records are filtered out even if DNSSEC signatures exist.

The filter-aaaa pair of options provides control at the DNS level to control distribution of AAAA responses; just remember to remove (unfilter) corresponding address match lists as you deploy IPv6 and enable IPv6 access!

Tuesday, September 20, 2011

Dual stack host default address selection

As many organizations ponder IPv6 deployment, the most popular approach will be dual-stack deployment according to a recent survey. This approach entails activating IPv4 and IPv6 address types and assigning corresponding addresses by defined means such as manual, DHCP or auto-configuration for a given device's interface(s). All major host operating systems (OSs) support IPv4 and IPv6 and in some cases auto-configure IPv6 addresses by default.

When an application seeks to communicate with a remote host given its hostname, the application calls the getaddrinfo() sockets API call. This API call triggers one or more DNS lookups (though other forms of name resolution could be used) with the query name set to the hostname passed in the getaddrinfo() call, the query class set to Internet and the query type set to A and AAAA on successive DNS queries. So given a host with both IPv4 and IPv6 interface addresses and destination host name resolution yielding both IPv4 and IPv6 addresses, which addresses are used? Microsoft, Linux, Unix and Mac operating systems all prefer IPv6 source addresses over IPv4 by default. when an appropriate IPv6 destination address is available.

RFC 3484 defines an algorithm for source address selection in the form of a policy table which prioritizes precedence values and preferred source address prefixes for returned destination addresses. This table enables the host to select the most appropriate source address given the possible destination addresses returned with the DNS queries. The original default policy table published in RFC 3484 appeared as:

::/0401Default (matching unicast) IPv6 address
::/96203IPv4-compatible IPv6 address
::ffff:0:0/96104IPv4-mapped IPv6 address

While RFC 3484 defines independent rules for selecting source and destination addresses based on the policy table, the logic is generally the same and consists of selection in the following priority order:

  1. Prefer the same address type
  2. Prefer the same address scope (link-local, site/ULA, etc.)
  3. Prefer non-deprecated addresses (avoid both globally deprecated addresses like site-local and addresses in deprecated state)
  4. Prefer home addresses over care-of addresses (Mobile IPv6)
  5. Prefer source addresses on the selected outbound interface assigned by the designated next hop (e.g., if the outbound interface connects to multiple ISPs, each of which assigned an IP address to the interface, select the one assigned by the corresponding ISP (next-hop)
  6. Prefer matching labels (source and destination prefix mapping)
  7. Prefer public address space
  8. Prefer the address with the longest matching prefix up to the subnet prefix length (this "up to" qualifier added to enable proper DNS round robin operation where multiple round robin destinations on the same subnet resulted in always the same one being selected, that having the longest total bit-wise matching prefix

RFC 3484 is currently undergoing revision and is currently in Internet draft status to add Unique Local Addresses (ULA) as well as Teredo addresses. Though unofficial as yet, the revised policy table currently looks like:

::/0402Default (matching) IPv6 address
::ffff:0:0/96303IPv4-mapped IPv6 address
::/96110Avoid IPv4-compatible IPv6 address
fec0::/10111Avoid site local IPv6 address

A given host's policy table may be modified if needed in one of the following ways depending on the OS:

  • On Linux you can explicitly denote a prefix as non-preferred setting the preferred_lft parameter to 0. For example, ip -6 addr change 2001:db8:4e/128 dev eth0 preferred_lft 0 disables selection of 2001:db8::4e address as an outbound source address.
  • On Unix/Solaris you can edit the /usr/sbin/ipaddrsel.conf file which is formatted just like the policy tables above. This allows insertion or demoting of address prefixes as desired. Run the /usr/sbin/ipaddrsel command to load the new configuration.
  • On Windows XP, use the ipv6.exe command to update the policy table for a given prefix in the form of:
    ipv6 ppu prefix precedence precedence_value srclabel label_value_source [dstlable label_value_dest ].
  • On Windows 7, Server 2003 and 2008R2, you can update the policy table for a given prefix in the form of:
    netsh interface IPv6 add prefixpolicy [prefix =] prefix/length [precedence=] precedence_value [label=]label_value[[[store=] {active | persistent}]].

Of course creation of and sending of an IP packet with the best match IP source and destination addresses does not guarantee delivery as intermediate transit nodes may or may not support the chosen protocol. As with most things, having a second or third choice improves the probability of a successful connection.

Wednesday, September 14, 2011

Planned Obsolescence in the IPAM Industry

Many products become obsolete or passe over time due to the availability of newer products with technology improvements or of more attractive replacement products, or even due to intangible factors such as social fads or trends. I'd term these natural or unplanned obsolescence. But planned obsolescence is a scheme where a product is consciously designed, manufactured or offered with a limited lifetime. The motivation is obvious: the product bought this year will become obsolete within x years, so the customer will need to re-purchase the product at that time.

Perhaps you've recently heard something like this from your IPAM (aka DDI) vendor: "Sorry that version of software doesn't run on that version of hardware." Or "that version of product has expired as has your support. I guess you'll have to repurchase everything!"

While this may be sound strategy for growing top-line revenue as every sale today will be repeated in x years, it's not necessarily attractive to customers. In fact I'm surprised customers knowingly buy into such vendors. And that those who unwittingly do so, repurchase again when "support" expires. There are alternatives out there and perhaps it's time for another look when "hit" with a repurchase invoice from your vendor. In this economy, who can afford to buy the same product every x years?

I invite you to check out BT Diamond IP products and services as your support expiration approaches. If you have to purchase your IPAM infrastructure again, why not consider a vendor from whom you only have to purchase the product one time. There's no doubt that evaluating IPAM vendors and products is a laborious and tedious process, and vendors with a repurchase strategy are counting on the theory that it's easier just to repurchase than to re-open the evaluation process. Don't be taken advantage of! Go with vendors who will support their products!