Subject: increasing DNS message entropy, a solution for NATs

From: "Roy Arends" <[email-masked]>
Date: Mon, 21 Jul 2008 13:17:55 +0200

The proposed solution to solve the problem highlighted by Dan Kaminsky is 
randomizing source ports. As some have mentioned, NAT/PAT scenarios do not 
benefit from this solution. 

A while back, Alessandro Linari (Oxford Brookes, working in our advanced 
projects team), mentioned this alternative solution:

A simple, straightforward method to increase entropy in DNS message 
transaction, is to query for the same name twice (or N times for even more 
increased entropy) and require that the answers be the same. This does 
require a change to the resolver, but not to the authoritative server. 

There are a few things to consider, such as auth-servers not agreeing on 
zone content (or other protocol violations), or avoiding birthday paradox 
when sending two queries to the same server, but overall, this solution is 
an alternative for those deployments that are not capable of making use of 
source port randomization. 

Roy Arends
Nominet UK

--
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: Joe Abley <[email-masked]>
Date: Mon, 21 Jul 2008 11:57:25 -0400

> require a change to the resolver, but not to the authoritative server.

This will lead to trouble if the query is ever answered by one of a  
cluster of servers, where there is the potential for some servers in  
the cluster to be slightly more up-to-date than others.

It also might lead to trouble if the query is ever answered by a  
single-source server which updates between query i and query j for  
some j>i.

> source port randomization.

Joe

---

From: [email-masked]
Date: Mon, 21 Jul 2008 16:22:04 +0000

> single-source server which updates between query i and query j for  

	welcome to the loose coherency feature of the DNS.

--bill

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Jul 2008 16:48:11 +0000

> From: "Roy Arends" <[email-masked]>
> 
> ...
> 

with all respect to alessandro, i can think of three reasons why this is a
terrible idea.  but first i'll comment on your reasons:

> when sending two queries to the same server, ...

so, this means:

1. the fact that the SOA will not always be present in responses means that
differences in responses due to serial number slippage will look the same
as an attack.

2. with or without an SOA present in responses, differences for load
balancing or traffic redirection purposes will look the same as an attack.

3. a server, which may be a load balancing cluster, or which may be a
multihomed server using separate NS RRs rather than one NS RR with multiple
A RRs (which is a form of undetectable server aliasing) may have reason to
rate-limit the apparently-duplicate requests, which could look the same as
a DDoS.

but i have three more reasons which i consider much more damning:

4. at the point in the topology where this action ("send N queries") must
be done, there is no way to determine that it needs to be done.  therefore
the configuration for it will not be automatic, and will be set blindly.
history teaches us that it will usually be set when it should not be, or
not be set when it should be, and that it will not be changed when it needs
to be changed (when the NAT/PAT device gets upgraded or downgraded.)

5. we have no way to know whether some future guessing attack will come
along that only takes five packets for success.  (amit klein's took 11
queries.)  there is therefore no reason to expect that making the same
query N times will make you safer, in real measurable terms, than making
that query 1 time.

6. unlike the EDNS transition, the extra traffic implied by this proposal
has no finishing date.  it's not a transition at all.  the additional
traffic isn't just sent until the other end upgrades, but rather, forever.
so, even when our grandchildren are grandparents, this extra traffic would
still be in the system.

so:

> ... but overall, this solution is an alternative for those deployments
> that are not capable of making use of source port randomization.

i really don't agree that this is a solution or an alternative.  we can all
contemplate duplicating the upstream query whenever there is a mismatch in
only the QID or only the UDP port or only the 0x20 bits or only the Q-tuple,
but in that case one is likely better off just retrying with TCP.  note that
mismatches in only the UDP port are usually not application-visible, so it
would be very hard to implement that portably on most operating systems.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: "Roy Arends" <[email-masked]>
Date: Mon, 21 Jul 2008 22:36:59 +0200

> single-source server which updates between query i and query j for 

Make j-i zero, use one server.

Roy

---

From: Alex Bligh <[email-masked]>
Date: Mon, 21 Jul 2008 22:04:41 +0100

--On 21 July 2008 22:36:59 +0200 Roy Arends <[email-masked]> wrote:

> Make j-i zero

I presume the notation meant the i'th query and the j'th query made by
the stub. If j-i=0, then i=j and there is only one query made!

> use one server.

Difficult to achieve with unicast.

Alex

---

From: "Roy Arends" <[email-masked]>
Date: Mon, 21 Jul 2008 23:09:54 +0200

Alex Bligh <[email-masked]> wrote on 07/21/2008 11:04:41 PM:

> the stub. 

No, this discussion is about resolvers talking to authoritative servers.

Not about stubs talking to resolvers.

> If j-i=0, then i=j and there is only one query made!

At a single point in time, issue two queries with the same question 
section. For more entropy, randomize everything else: source address, 
destination address, query ID, source port.

Roy

---

From: Alex Bligh <[email-masked]>
Date: Mon, 21 Jul 2008 22:22:55 +0100

Roy,

> Not about stubs talking to resolvers.

What's talking to what is I think irrelevant.

> destination address, query ID, source port.

Perhaps I am being more than usually thick here.

At a single point in time (well, obviously a marginal difference as packets
obviously get into one order or another on the wire), you send 2 queries (I
and J) either to 2 different IP addresses, or both to the same address.
Assume in both case QID, source port, source address are randomised. Now
take the two cases.

Different IP addresses: one server is out of sync with the other, as the
zone has been modified. The replies are different. False positive for
spoofing.

Same IP address: unbeknownst to you, the two packets do not reach the same
server due to loadbalancing / local unicast. The servers are out of sync
as an update has not yet been processed on one. The replies are different,
false positive for spoofing. Less likely but possible: no unicast, single
server, in the fraction of a second between the arrival of queries I and J,
the server updates; same result.

Alex

---

From: "Roy Arends" <[email-masked]>
Date: Mon, 21 Jul 2008 23:32:44 +0200

Joe Abley <[email-masked]> wrote on 07/21/2008 11:16:07 PM:

> On 21 Jul 2008, at 17:09, Roy Arends wrote:
> 
> > At a single point in time,
> 
> There is no single point of time to do two things, in practice (at 
> least, in general).

Joe, you're splitting hairs here.

> > issue two queries with the same question
> So, considering there are well-documented examples of TLD, root, and 
> other DNS infrastructure which will, by design, respond with different 
> answers to these two queries, what conclusions should such a resolver 
> draw from the observed incoherence?

if different, use either, cache neither.

Roy

---

From: bert hubert <[email-masked]>
Date: Tue, 22 Jul 2008 00:11:33 +0200

How about:

http://lists.oarci.net/pipermail/dns-operations/2008-July/002972.html
Which discusses adding some DNS message entropy, by some means, detailed
below.

> Lutz,

(...)

> But you may be right. I haven't heard of any TCP/IP hijacks lately, the
> famed 'Mitnick-attacks' of the past. However, TCP/IP has around 16+32+32=80
> bits of entropy to play with. Some bits are lost because of window size etc,
> and to other things, so give it a good 70 bits.

> If we get DNS to the same level of entropy, we should be safe, or at least
> as safe as TCP which I hear no worries about.

> DNS is now at 16 (source port) + 16 (id) + 1 (nameserver), so indeed the 16
> extra bits I mentioned above would only get us to 49.

> So adding 32 bits or even 48 bits of additional random would be best.

> The algorithm might in fact be quite simple: 
>	1) See if a remote nameserver talks extended query id. 
>	2) If it doesn't fall back to TCP and get the bits from there. 
>	3) If that doesn't work, wait for people to fix their firewalls.

> What do you think? Move to DNSEXT? There has already been extended query id
> discussion there.

I implemented the server part of this, using EDNS option number 4 ('EDNS
PING'), and added support for the addition of EDNS PINGS to outgoing
questions from the resolver. These appear not to cause problems, but of
course nobody pings back yet.

An EDNS PING is nothing but an EDNS option containing a blob of data (or
arbitrary lengt) we expect to see back in the answer.

I've given this some thoughts over the past week, it might be doable to
slowly turn this on. First try the ping and use it if available, and keep
state ("this IP address pings back to us, don't believe any answers where it
doesn't"), but don't fall back to TCP.

A year from now we turn on fall back to TCP if you don't EDNS-ping back.

People who are afraid they will be overwhelmed by TCP queries make sure they
have EDNS-pingback ability. 

A little bird tells me a scheme like this is already in use between stubs
and certain resolvers, using EDNS option number 4 no less, but it works
slightly differently, so we might have to use EDNS option 5.

What do you think? The idea itself was thought up by Paul Vixie I think, the
details about 'fallback to TCP otherwise' and the keep-state are my tiny
addition.

	Bert

On Mon, Jul 21, 2008 at 10:22:55PM +0100, Alex Bligh wrote:
> !DSPAM:48850135193055702515455!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Jul 2008 08:12:14 +0900

> The proposed solution to solve the problem highlighted by Dan Kaminsky is

The proper reference is section 2.2 of RFC3833 published in 2004.

> No, this discussion is about resolvers talking to authoritative servers.

What? Resolvers behind NAT/PAT are directly talking to authoritative
servers?

You should first document all the possible senarios to combine DNS
and NAT/PAT.

> This does 

Given possible chaching on NAT/PAT and everywhere, you must update
entire resolver chains between stub resolvers and authoritative
servers, which is practically impossible.

						Masataka Ohta

---

From: Duane <[email-masked]>
Date: Tue, 22 Jul 2008 12:10:31 +1000

> would be very hard to implement that portably on most operating systems.

This is where SSLv2 failed, they used ICMP to pass messages about
connection closure, SSLv3 onwards ignore the ICMP messages for the most
part.

-- 

Best regards,
 Duane

---

From: Joe Abley <[email-masked]>
Date: Mon, 21 Jul 2008 17:38:34 -0400

> Joe, you're splitting hairs here.

Yeah. My intent was to reinforce the point that two queries, no matter  
how rapidly they are sent in succession to one another, are going to  
be handled autonomously and quite possibly by different servers.

> if different, use either, cache neither.

Thanks.

It would be interesting to consider what class of queries or  
nameserver deployment scenarios might result in such observed  
incoherence regularly, and to further consider the impact if the  
answers relating to those queries wind up not being cached, most of  
the time.

I haven't done such thinking, on the grounds that it is Monday. But it  
seems worth worrying about.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 21 Jul 2008 17:16:07 -0400

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 21 Jul 2008 16:43:24 -0400

> Make j-i zero, use one server.

j-i can't be zero if the client is repeating queries.

Using a single server is certainly an option, but the semantics of  
loose coherency have led some of us to deploy service somewhat  
differently. I think it's reasonable to acknowledge the practical  
consideration that a client that expects subsequent (near-adjacent)  
queries to be answered identically in all cases might run into  
problems talking to many servers responsible for zones at and near the  
root of the namespace.

More generally, if we change the basic semantics of the protocol, I  
think it's fair to assume there will be unexpected consequences.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Jul 2008 03:35:06 +0000

there are negative replies to two different branches of this thread below.

> if different, use either, cache neither.

since the verb "use" in this case just means "to cache", since many RDNS
cache and regenerate all data passing through them from ADNS to stub, this
is a meaningless suggestion in response to an absolutely fatal observation.

> From: bert hubert <[email-masked]>
> 
> How about:
> 

this is completely undeployable.  tcp is blocked in way too many places, and
the large commercial stub vendors would never implement #3 above, which turns
this into the same basic downgrade vector all versions of XQID or cookies
have ever had.

---

From: Doug Barton <[email-masked]>
Date: Mon, 21 Jul 2008 21:58:36 -0700

> benefit from this solution. 

I'm not as up on firewall/NAT stuff as I used to be, but don't most of 
them nowadays try to assign the same port on the outside as the client 
starts with on the inside? I do know that most firewalls nowadays have 
knobs to enable "randomization" of the outgoing UDP ports, so while it 
may not have the same level of effectiveness as what BIND is doing 
directly, it is "better than nothing."

> require a change to the resolver, but not to the authoritative server. 

That actually depends on how the authoritative server is configured. 
For example, I've written in the past about a hack we added when I was 
DNS Admin at Yahoo! to limit the number of A records in a rotor to 
those that would fit into a 512 byte UDP packet. So, if this proposal 
was in effect at that time, you would be virtually certain to get a 
different response _every_ time you query, which would trigger the 
"we're being attacked" alarm.

I don't want to go down the "but that's a protocol violation" road 
again on this topic, I know it is. My point in this context is that 
this is being done "out in the wild," and it's probably being done a 
lot more often than people realize.

Plenty of other folks have chimed in on why this multiple query idea 
is probably not a good path to pursue, but I thought I'd throw one 
more log on the fire.

hth,

Doug

---

From: bert hubert <[email-masked]>
Date: Tue, 22 Jul 2008 08:35:14 +0200

Dan Kaminksy's issue accidentally leaked?
http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally-leaked.html

Plus :

> this into the same basic downgrade vector all versions of XQID or cookies

At least this shows us a path that gives immediate benefit to those who
play, especially the "opportunistic keep-state EDNS PING" where resolvers
cache who has done EDNS PING in te past, and know they should not be
downgraded (for now).

 "[it] might be doable to slowly turn this on. First try the ping and use it
  if available, and keep state ("this IP address pings back to us, don't
  believe any answers where it doesn't"), but don't fall back to TCP.

  People who are afraid they will be overwhelmed by TCP queries make sure
  they have EDNS-pingback ability. "

EDNS PING moved to EDNS option 5 today. I'll wrap up some informal specs and
see who plays.

There is an immediate benefit for everybody who joins.

Especially since 
http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally-leaked.html
..

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Jul 2008 07:16:01 +0000

> Dan Kaminksy's issue accidentally leaked?

i don't think it was an accident.

> > ... completely undeployable.  tcp is blocked in way too many places,
> > and the large commercial stub vendors would never implement #3 above,
> > which turns this into the same basic downgrade vector all versions of
> > XQID or cookies have ever had.
> 

what's your plan for times when the responder legitimately does downgrade,
or when load balancing (in the local or wide or remote area) replaces the
endpoint entity in an on-path (non-spoofed) way?

> EDNS PING moved to EDNS option 5 today. I'll wrap up some informal specs
> and see who plays.

this being the internet, there's room for a zillion boutique solutions.

> There is an immediate benefit for everybody who joins.

that may be so, but also, immediate risks, which will prevent scale.

note, i've met several large internet companies recently who refuse to
deploy EDNS at all, one said their eyeball count dropped by 3% when they
started honouring EDNS signalling in their DNS responses.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Jul 2008 17:41:40 +1000

> started honouring EDNS signalling in their DNS responses.

	Was this before or after referrals to the COM servers from
	the root started exceeding 512 octets?

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

---

From: bert hubert <[email-masked]>
Date: Tue, 22 Jul 2008 09:44:26 +0200

> started honouring EDNS signalling in their DNS responses.

Wow - I never knew it was this bad. Amazing how moribund DNS has become. 

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Jul 2008 07:43:56 +0000

> 	the root started exceeding 512 octets?

after.  as you know, inability to fit all the glue into 512 bytes is not
cause for concern (nor TCP retry.)

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Jul 2008 15:44:01 +0100

On Mon, 21 Jul 2008, Doug Barton wrote:
>
> I've written in the past about a hack we added when I was DNS Admin at
> Yahoo! to limit the number of A records in a rotor to those that would
> fit into a 512 byte UDP packet. So, if this proposal was in effect at
> that time, you would be virtually certain to get a different response
> _every_ time you query, which would trigger the "we're being attacked"
> alarm.
>
> I don't want to go down the "but that's a protocol violation" road again
> on this topic, I know it is. My point in this context is that this is
> being done "out in the wild," and it's probably being done a lot more
> often than people realize.

Yes. DJB's tinydns uses this hack for A RR sets with more than 8 items.
http://cr.yp.to/djbdns/balance.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT: NORTHWESTERLY 4 OR 5, BECOMING VARIABLE 3 LATER. MODERATE. FAIR.
MODERATE OR GOOD.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Jul 2008 04:57:15 +0100

> What? Resolvers behind NAT/PAT are directly talking to authoritative

Why not?

And on the question of NAT randomness: http://www.links.org/?p=352.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 31 Jul 2008 13:29:21 +0900

> Why not?

Because various NAT/PAT gateways put all the possible and impossible
modificaitons on certain, including DNS, packets that there is virtually
no directness expected.

> And on the question of NAT randomness: http://www.links.org/?p=352.

That is one, among so many, example of indirectness of NAT.

						Masataka Ohta

---

From: Alex Bligh <[email-masked]>
Date: Thu, 31 Jul 2008 08:18:23 +0100

> modificaitons on certain, including DNS, packets that there is virtually

I am guessing this is a very common SoHo configuration though.

Alex

---

From: Duane <[email-masked]>
Date: Thu, 31 Jul 2008 17:54:50 +1000

> I am guessing this is a very common SoHo configuration though.

Has anyone stopped to ask how much effort/emphasis should really be
spent trying to protect end users?

People perpetrating attacks on the internet still pay attention to the
principals of economics, that is getting the most benefit from the least
amount of work.

For what it's worth, I think the real focus here should be ISP
resolvers, not home users. Not to mention this should be a simpler
problem to solve for a number of reasons.

It seems to me that there is an excessive amount of attention being paid
to protect what is potentially 1 machine in most cases.

-- 

Best regards,
 Duane

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Jul 2008 09:17:38 +0100

> I am guessing this is a very common SoHo configuration though.

Given the difficulty of getting IPv4 address space these days, it's 
pretty common full stop.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Jul 2008 09:18:57 +0100

> modificaitons on certain, including DNS, packets that there is virtually

I can't really parse this. What do you mean by "directness"? And what 
possible/impossible modifications to NAT/PAT gateways make to packets?

> That is one, among so many, example of indirectness of NAT.

Source port modification, you mean?

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Jul 2008 09:19:54 +0100

> to protect what is potentially 1 machine in most cases.

This problem does not only affect home users.

---

From: Duane <[email-masked]>
Date: Thu, 31 Jul 2008 18:25:30 +1000

> This problem does not only affect home users.

Lets face it, most people that would/will be effected won't upgrade
their routers, so that's already a lost cause, anyone that does upgrade
their NAT solution should do a better job of it and it's not really a
DNS issue.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Thu, 31 Jul 2008 18:38:00 +1000

Ben Laurie wrote:
> Then why are we discussing it?

Beats me, everyone seems rather concerned over an issue that no one
could fix if they wanted to in any case. That isn't to say that someone
shouldn't be doing in terms of getting NAT better for in future, but
existing deployments by and large are never going to be upgraded until
new hardware is purchased.

-- 

Best regards,
 Duane

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Jul 2008 09:32:35 +0100

---

From: Duane <[email-masked]>
Date: Thu, 31 Jul 2008 18:44:09 +1000

Ben Laurie wrote:

> Whether that's true or not, isn't it a good idea that the new hardware
> actually does the right thing?

I already suggested that, but apparently NAT needs to be fixed as much
as DNS in new hardware.

-- 

Best regards,
 Duane

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Jul 2008 09:41:55 +0100

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Jul 2008 09:51:10 +0100

> I already suggested that, but apparently NAT needs to be fixed as much

Exactly.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 31 Jul 2008 09:54:27 +0100

> their NAT solution should do a better job of it and it's not really a

I am guessing the half-life of ADSL equipment is less than 3 years.

Alex

---

From: Duane <[email-masked]>
Date: Thu, 31 Jul 2008 18:54:32 +1000

>> I already suggested that, but apparently NAT needs to be fixed as much

Ok, so problem solved as far as I can see, someone just needs to tell
hardware companies to fix NAT + DNS and that's that.

-- 

Best regards,
 Duane

---

From: bert hubert <[email-masked]>
Date: Thu, 31 Jul 2008 11:11:50 +0200

> I am guessing the half-life of ADSL equipment is less than 3 years.

While that may be true, the level of fail is showing no similar signs
however..

---

From: [email-masked]
Date: Thu, 31 Jul 2008 10:12:56 +0100

> I am guessing the half-life of ADSL equipment is less than 3 years.

Unfortunately for many manufacturers the half-life of firmware updates is 
the same :(

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 31 Jul 2008 11:22:03 +0200 (CEST)

> I am guessing the half-life of ADSL equipment is less than 3 years.

But it can't hurt to educate the vendors so they do it right.
I'f you're behind a NAT, like I am, and run a DNS server, like I do, and 
if you care enough to get it right, like I do, then you replace your 
cheap hardware with a proper one anyway.

Let's get lists out of vendors that do it proper/inproper so the problem 
will go away.

And  must give you this thought:
Being behind a NAT that passes through port randomness unaffected when 
there is no other traffic, other activity behind the NAT can even increase 
the randomness of the ports as nobody can "guess" the activity I'm going 
to do on my internal network.

Antoin.

---

From: [email-masked]
Date: Thu, 31 Jul 2008 10:21:50 +0100

> hardware companies to fix NAT + DNS and that's that.

Actually there's stacks of other stuff that the router manufacturers need 
to fix relating to DNS, particularly w.r.t the DNS proxies contained in 
most CPE:

-  tcp/53 support - currently almost non-existent
-  DNSSEC support - some mfrs block DNSSEC queries
-  EDNS0 - many DNS proxies can't do UDP fragment reassembly
-  open udp/53 ports on the WAN interface
-  probable "poor" PRNGs for port and QID selection (c.f. Ben's blog 
article)

There's going to be a report published fairly soon containing the results 
of a joint study between myself and a US-based researcher detailing which 
routers have various deficiencies.

Ray

---

From: Duane <[email-masked]>
Date: Thu, 31 Jul 2008 19:50:44 +1000

[email-masked] wrote:

> 	as long as your going to point fingers, jumbograms in general
> 	get the short shrift.  4k UDP... 9k large frame...  don't fit
> 	nicely in a SoHo device.
> 
> 	Make sure you use/refer to David Piscatellos excellent study of
> 	firewalls.

I'm surprised no one mentioned IPv6 since we're on this soap box.

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Thu, 31 Jul 2008 09:47:09 +0000

--bill

---

From: [email-masked]
Date: Thu, 31 Jul 2008 11:06:08 +0100

> I'm surprised no one mentioned IPv6 since we're on this soap box.

That would be nice, but AFAIK my own test environment (which uses rp-pppoe 
and pppd as a DSL BRAS) isn't capable of doing IPv6.

Ray

---

From: [email-masked]
Date: Thu, 31 Jul 2008 10:26:32 +0000

> I'm surprised no one mentioned IPv6 since we're on this soap box.

	sorry about the indirect reference
	http://www.icann.org/committees/security/sac016.htm

--bill

---

From: [email-masked]
Date: Thu, 31 Jul 2008 10:33:22 +0000

> and pppd as a DSL BRAS) isn't capable of doing IPv6.

	some folks have a hard time seeing boxen of that ilk as being 
	routers.  stripped down NAT, sure.

> Ray

	so as long as you and your US researcher are clear that you are looking 
	at "settop boxes" ...  then I have no problems.  

	but if you start building a punchlist of desired characteristics that
	are missing, then you'll be getting any number of feature requests.
	if one is after EDNS0 support, then dealing w/ UDP fragmentation will
	be an issue -unless- the device in question can handle 4k UDP frames.

	"rewriting" DNS queries will muck w/ DNSSEC signed data.

	etc.etc.  good luck.

--bill

---

From: Alex Bligh <[email-masked]>
Date: Thu, 31 Jul 2008 12:47:00 +0100

> But it can't hurt to educate the vendors so they do it right.

Indeed that was my point. I am assuming end users never (or hardly
ever) upgrade their firmware. Thus realistically speaking the only
way to get non-broken NAT (or other DNS related features) into the
ecosystem is to educate vendors and wait for the existing hardware
base to churn.

Alex