i guess i prefer AAAA much more than A6, because of the following
logic. could someone shed some light on the following items?
i don't think i'm convinced yet.
i agree that we need to test A6 in the real world situation.
however, for a guy who is using IPv6 in a daily basis, i cannot wait
till the test gets done... so i prefer AAAA gets deployed and kept.
(note: the following is separate from topics raised by DJB)
itojun
real dns cloud:
- if we end up using "A6 0 <128bit>" everywhere, there's no benefit
against AAAA.
- if we are to use fragmented A6s (128bit splitted into multiple A6s),
i got couple of issues/worries.
(1) query delays bothers me and we don't know how the additional
delays interact with various timeout parameters. also, are we sure that we
have no problem with additional query/reply traffic imposed by fragmented A6?
(2) some says that caches will avoid querying fragmented A6s again and again.
however, most of the libc resolver implementations do not cache anything.
(3) if some of the fragments are DNSSEC-signed and
some are not, how should we treat that address? RFC2874 section 6 briefly
talks about it, not sure if complete answer is given.
(4) it is much harder to code A6 fragment reassemble code, i expect
to see a lot of security-issue bugs in the future (from our experiences).
(5) i don't think there's too big benefits from renumbering.
query-replace over AAAA zone file is easy enough. you may need to sign
zones on renumber, but given that the frequency of renumber is fairly low
it shouldn't be an issue.
to those who says that we can renumber frequently: from rrenum discussion
it is clear that we cannot renumber more frequently than DNS TTL (or TTL*2).
(6) there were some mentions about limiting # of fragments, but there's no
such guarantee.
resolver issues:
suppose that we synthesize AAAA, or A6 0 <128bit>, at the DNS server
contacted by libc resolver, to avoid some of the complexities given above
(see BIND 9.2.0 snap behavior). the approach has the following drawbacks:
- DNSSEC signs will get removed, making it impossible for libc resolvers
- when do we decide to synthesize A6 0 <128bit>? client may be asking for
raw A6 record (can be fragmented), client may be asking for synthesized A6 0
<128bit> record.
- synthesized records have TTL=0. is it really okay? (most of libc resolvers
do not cache, so it should not be too bad)
we at least need a flag to determine when to synthesize, and when we do not.
(note that if we simply use AAAA in all places, we have no such problem at all)
deplyment issue:
we can't wait till BIND9 gets deployed everywhere.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
