[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: on NAT-PT
so you don't apologize for attacking me on "product advertisement"?
>> what you are proposing here will affect every application
>> that use DNS resolver (since the DNS resolver attaches magic prefix
>> to all the responsees from DNS). there's big difference.
>It only affecst v6-only applications on v6-only nodes that
>want to sent packet to v4-only nodes. Regular communication
>with IPv6 hosts is not affected.
even though it is for limited scope, what you are proposing is harmful.
>>>Yes, but the next one will succeed. I think of this as a good property,
>>>as in case of failure, not everything is lost, just current connections.
>> what is the "next one" in your text above? i was not talking about
>> a connection attempt, but an existing TCP connection suddenly shut down
>> by routing changes.
>I think we are concerned about different things.
>You express concerns about maintening an existing connection
>in the event of a NAT box failure,
>I'm concerned about mainteting 'usability of the Internet'
>in the event of this failure. Many connections in the Internet
>are short lived or can be easily restarted.
>Example: in typical Web browsing usage, connections are very short.
>To load a particular page, usually there are several connections
>happening under the hood. If one fails, that's no big deal,
>maibe a picture or an icon will not display and the user
>will do 'refresh'. If we can make sure that when
>the user does 'refresh', this new connection actually
>works, I think we would have achieved a reasonable
>level of reliability.
i'm not convinced at all with your argument on TCP lifetime (that
TCP lifetime is short and it is okay to terminate one as people will
re-connect). translators cannot make assumptions on TCP lifetime.
even if you are proposing it for HTTP-only translators, i object -
starting HTTP/1.1 they reuse TCP connection for multiple HTTP requests
and you can't assume that the TCP lifetime is short.
>> yes, if Ti goes down, connections that went through Ti will go down.
>> however, many of the host resolver implementation do not cache DNS
>> responses (luckily for translators, unluckily for DNS), so the next
>> connection attempt will use something other than Ti.
>This is not true for every implementation. In particular, ours does cache.
>I do not think it is a good think to build a protocol based on the
>assumption that DNS stub resolvers are stupid and do not cache.
DNS-ALG can respond with shorter DNS TTL for fabricated responses
to minimize the impact to resolvers that perform caches, in case of
failure in one of the translator boxes.
>> if you attack NAT-PT on this point, your proposal must have no state
>> at all in your translation boxes.
>I disagree. Re-read my paragraph about web browsing.
>Stateless is always better, but if we need to introduce state,
>we have to make sure that we mimimalized the impact in
>case of problem.
>NAT-PT DNS-alg as you describe introduces state
>in the stub resolver on a per-name resolution basis.
>Even if the stun resolver does not cache, the application
>that ask for the resolution may very well do.
>Using a well know prefix (a la NAT64, but not necessarily ::ffff:0:0)
>put state in the NAT box on a per-connection basis.
>If the box fails, current connections are trashed, but new
>ones can be routed to a new box.
i disagree with the above. see below. what you are proposing is RSIP.
on TCP lifetime discussion, see above (about 40 lines before).
>>>Also very bad, this breaks DNSsec.
>> (i think i have repeated this too many times)
>I repeat it because it is true.
>> when you rely on intermediate device which rewrites your packet,
>> what kind of protection do DNSsec really provide?
>Using NAT-PT DNS ALG, the node does not know it is using
>NAT, so it cannot differentiate DNSsec does not work because
>I'm behind NAT-PT from DNSsec tells me something fishy
>happened. Remember, DNSsec will still work fine for 'regular'
>IPv6 name to address translation for regular IPv6 addresses.
>> and when you
the nodes MUST NOT know that there is a middlebox. never. if the end
nodes has to be aware of middleboxes, it's not IP. it's called RSIP.
this is why i have been objecting your idea to alter resolver in the
>> fabricate address by attaching some hardcoded prefix onto the value
>> returned from DNSsec?
>DNSsec signature can still be checked in the stub resolver
>before the wkn prefix is attached.
you have been ignoring my comment (i made this comment months ago)
to use "AD is secure" for the response from DNS-ALG.
>> with the lack of deployment of DNSsec, and the likelihood of
>> deployment is so low, i don't think your popular claim "it breaks
>> DNSsec" is realistic.
>How can you make such a public statement! How can you say publically
>we are deploying IPv6 and do not care about DNSsec!
>This makes no sense to me...
this is a operational group. you need to face the operational reality,
instead of acting as an armchair detective.