Subject: Comment on draft-reid-ipv6ok-00.txt

From: Kevin Darcy <[email-masked]>
Date: Thu, 31 Oct 2002 11:11:08 -0500

Why allocate a bit in the EDNS0 extended flags, which you'll probably never be
able to de-allocate/re-allocate?

Use an OPTION record instead. For an option which is basically just boolean, it
only takes up 4 octets (2 for the option code and 2 for the length field); hardly
enough to break the bank, and when the option is no longer needed, it can simply
be phased out.

- Kevin

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 31 Oct 2002 10:11:03 -0600

> 	Title		: Indicating Resolver Support for AAAA Records
> 	Author(s)	: J. Reid, S. Woolf
> 	Filename	: draft-reid-ipv6ok-00.txt
> 	Pages		: 4
> 	Date		: 2002-10-30

This works for me, at least as a model. Some specifics:

There isn't a lot of discussion on what the flag is supposed to cause to
happen. Does it mean that whenever a server would normally return an A RR
 (either as answer or additional-data) that it should also return any
available AAAA RRs for all of those names?

What if the size of the answer will overload the EDNS message? That will
put us back into the original problem case. Should the server not return
the AAAA data, should the server give a truncated response using the
existing rules, or what.

On a broader note, include-AAAA-for-every-A implicitly updates several
specifications which prescribe additional-data behavior. Even if this
doesn't result in any significant problems, it may still be necessary to
itemize (at the least) or discuss (at the worst) the impact of this change
to those specifications. OTOH, if the intention is architecture --
facilitating standardized usage but not updating the default behavior for
any existing specifications -- then that should be stated somewhere
explicitly as well.

| More explicitly, IPv6-aware nameservers MUST NOT insert AAAA RRs in
| a response unless the IO bit was set on the request.

Should be "MUST NOT insert [unsolicited] AAAA RRs" if I understand the
model correctly.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/