headers
Mark Andrews | 1 Aug 2009 09:18

Re: DNS64 reverse


In message <20090731222142.GH14838 <at> shinkuro.com>, Andrew Sullivan writes:
> On Sat, Aug 01, 2009 at 07:54:31AM +1000, Mark Andrews wrote:
> > 	You made this way to complicated which is why I suggested the
> > 	CNAME in the first place.
> 
> I am willing to countenance a charge that I've made it more
> complicated than you think necessary.  Perhaps just synthesizing the
> CNAME is indeed trivial (though I think you're waving away some of the
> steps I outlined without admitting that you have in fact to do them).
> But …
> 
> > > to be _that_ bad, so it's by no means impossible.  But it's more
> > > complication in an already fragile and complicated mess that we're
> > > creating just as a transition strategy.
> > 
> > 	FUD
> 
> … I am not willing to stand for that.  What I am saying is not FUD,
> it's simply asking whether a given trade-off is worth it.  It's fun to
> point and laugh at people we disagree with, but that isn't an
> argument.

Your making it out to be much harder that it is.  You are over
estimating the difficulty.  Named already does something like this
to authorise UPDATES in the 6to4 range.  It digs the IPv4 address
out of the UPDATE request and matches it against the source address
of the UPDATE as well as checking that it is coming in via TCP.

Doing this was trivial.  Doing a similar thing with queries is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Perreault | 2 Aug 2009 13:08
Picon
Favicon

Re: draft-ietf-behave-dns64-00 Additional section processing

On Friday 31 July 2009 16:10:44 Andrew Sullivan wrote:
>     1.  "We don't care.  Don't run a DNS server that offers recursion
>     and performs caching behind a DNS64, period."  I think this won't
>     really work, because we have no way of knowing how many such
>     resolvers there are out there, and the whole point of this effort
>     is to reduce the need to upgrade all the deployed systems
>     (particularly, all the customer equipment) or to know exactly what
>     equipment lies where in the network.

This is what I would prefer.

There are many cases where B is controlled by the same entity as the one who 
controls the DNS64. In this case, B's configuration can be modified so that it 
works in this context. No need to change software, just configuration.

Otherwise, there are many cases where the entity who controls the DNS64 also 
controls the network, and may then simply redirect all DNS queries to the 
DNS64. Many ISPs currently do this anyway with DNS servers that lie in 
arguably less useful fashion.

Are there significant instances of other cases (the entity who controls the 
DNS64 controls neither B nor the network) we should care about? I can't think 
of any.

Simon
--

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 3 Aug 2009 00:23
Picon

Re: [Francis.Dupont <at> fdupont.fr: [dnsext] DNS64 and lying cache servers]

It's an interesting point but it misses the point IMHO:
we *have* to lie to classical IPv6-only hosts.

I've always preferred the stub resolver approach, right back
to draft-van-beijnum-v6ops-mnat-pt-00.txt, but that preference is
useless if the real world contains classical IPv6 hosts.

   Brian

On 2009-07-31 19:44, Andrew Sullivan wrote:
> Dear colleagues,
> 
> Some of the participants in dnsext are reluctant to join another
> mailing list the subject of which is mostly not of interest to them.
> I have offered to accept comments from those participants and forward
> them to behave when appropriate and if asked.  Attached is one such
> example.
> 
> A
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> [dnsext] DNS64 and lying cache servers
> From:
> Francis Dupont <Francis.Dupont <at> fdupont.fr>
> Date:
> Wed, 29 Jul 2009 14:28:26 +0200
(Continue reading)

Permalink | Reply | 2 comments |
headers
Charles E. Perkins | 3 Aug 2009 00:46
Favicon

Re: [Francis.Dupont <at> fdupont.fr: [dnsext] DNS64 and lying cache servers]


Hello folks,

There is a reference below to a disaster that can occur
when DNS64 encounters mobility.  Is there something
more I can read about this?

Thanks in advance for any pointers to reading
material.

Regards,
Charlie P.

Brian E Carpenter wrote:
> It's an interesting point but it misses the point IMHO:
> we *have* to lie to classical IPv6-only hosts.
>
> I've always preferred the stub resolver approach, right back
> to draft-van-beijnum-v6ops-mnat-pt-00.txt, but that preference is
> useless if the real world contains classical IPv6 hosts.
>
>    Brian
>
>
> On 2009-07-31 19:44, Andrew Sullivan wrote:
>   
>> Dear colleagues,
>>
>> Some of the participants in dnsext are reluctant to join another
>> mailing list the subject of which is mostly not of interest to them.
(Continue reading)

Permalink | Reply | 1 comment |
headers
teemu.savolainen | 3 Aug 2009 08:41
Picon

Re: [Francis.Dupont <at> fdupont.fr: [dnsext] DNS64 and lying cache servers]

Hi,

For me this sounds exactly like the split-DNS problem I describe here:
draft-savolainen-mif-dns-server-selection
(http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection-00) and what we discuss
in MIF WG.

Essentially even today multi-interfaced hosts can not really trust DNS information being fully coherent
between different administrative domains.

I plan to include the faked AAAA records as additional example of private information DNS servers are
providing, and information that must be used only in the administrative domain they were learned from. 

Best regards,

	Teemu

>-----Original Message-----
>From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] 
>On Behalf Of ext Charles E. Perkins
>Sent: 03 August, 2009 01:46
>To: Andrew Sullivan
>Cc: behave <at> ietf.org
>Subject: Re: [BEHAVE] [Francis.Dupont <at> fdupont.fr: [dnsext] 
>DNS64 and lying cache servers]
>
>
>Hello folks,
>
>There is a reference below to a disaster that can occur when
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rémi Després | 3 Aug 2009 11:41
Picon
Favicon

Re: Comments on prefix format requirements


Le 28 juil. 09 à 11:14, Erik Nordmark a écrit :

> Brian E Carpenter wrote:
>
>> I don't think that is quite the point. The point is that if (and it's
>> a big if) we ever try to retro-fit some form of 8+8 to the Internet,
>> the U flag needs to be trustworthy, since 8+8 requires universally
>> unique IIDs. That's an architectural change that IMHO is clearly out
>> of BEHAVE's scope and belongs in 6MAN. I see that Rémi D has started
>> a thread on that in 6MAN.
>
> Yes, we definitely should discuss this in 6MAN.
>
> FWIW I don't see any utility in remote interpretation of the U- 
> flag. It was added as a result of the 8+8/GSE discussion as being  
> potentially useful for multihoming.
> I've explored many different ways to do multihoming and read about  
> a few more,

> but I've seen no worked out proposal which would benefit from a  
> remote node using the U bit in the interface ID.

And the point is that for SAM, not only would it not be a benefit but  
it would prevent a simple design.
(BTW, your comments and/or questions on draft-despres-sam-03 would be  
most welcome.)

Regards,
RD
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rémi Després | 3 Aug 2009 12:18
Picon
Favicon

Re: UDP zero checksums and v4 to v6 translators


Le 30 juil. 09 à 03:09, Christian Huitema a écrit :

>> On 2009-07-29 19:43, Benny Amorsen wrote:
>>> Brian E Carpenter <brian.e.carpenter <at> gmail.com> writes:
>>>
>>>> Er, do your routers do that when they throw away packets due to
>>>> congestion?
>>>
>>> If a router throws away a packet due to congestion, there's a good
>>> chance that a retransmission will go through. In this case you can
>>> retransmit as many no-UDP-checksum packets you want, none of them  
>>> will
>>> get through. The host really ought to be told that it is wasting its
>>> time.
>>
>> There's no retransmission in UDP.
>>
>> Presumably there is no harm in sending back some kind of ICMP error,
>> most likely Parameter Problem, at a throttled rate. But we shouldn't
>> mandate
>> it IMHO, and you certainly can't rely on a host stopping a UDP stream
>> as a result.
>
> What happened to being conservative with what we send and  
> permissive with what we receive?
>
> It seems that the direct application should be:
>
> 1) Be conservative: hosts should not send UDP packets with null
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lars Eggert | 3 Aug 2009 13:54
Picon
Gravatar

Re: [BEHAVE] UDP zero checksums and v4 to v6 translators

Hi,

On 2009-8-3, at 13:18, Rémi Després wrote:
> In view of the various arguments made, here is IMHO a good  
> combination:
...
> - IPv6 hosts MAY accept UDP datagrams with zero checksum.

I see no reason why allowing a UDP checksum of zero for router-to- 
router tunnels under specific circumstances (existence of a payload  
checksum), which is what we've been discussing for AMT and LISP,  
motivates *any* changes for the host. As far as hosts as concerned,  
nothing changes with regards to RFC2460.

> - IPv6 hosts that accept zero-checksum UDP datagrams MAY restrict
> this tolerance to remote hosts whose IPv6 addresses include an IPv4
> mapped address.
> (Thus no new tolerance is introduced for IPv6 hosts.)

Since there is no IP header checksum in IPv6, these IP addresses can  
be corrupted, and so this check may fail.

> - IPv4 to IPv6 translators that receive UDP datagrams with zero
> checksums MAY keep these checksums in translated datagrams.

Translators are not tunnels. The argument why a zero outer checksum  
may be OK for tunnels is that the inner payload is still protected by  
a checksum, which is not true for translators.

Lars
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Savola | 3 Aug 2009 14:28
Picon

Re: [BEHAVE] UDP zero checksums and v4 to v6 translators

On Mon, 3 Aug 2009, Lars Eggert wrote:
> I see no reason why allowing a UDP checksum of zero for router-to-router 
> tunnels under specific circumstances (existence of a payload checksum), which 
> is what we've been discussing for AMT and LISP, motivates *any* changes for 
> the host. As far as hosts as concerned, nothing changes with regards to 
> RFC2460.

While this is true for LISP, unfortunately an AMT tunnel endpoint may 
be a host; in fact it's likely it will be. :-/

For the specific case of AMT, I wouldn't personally see a problem with 
IPv6 encapsulating plain IP instead of UDP, though this would 
complicate the spec slightly.  The LAG argument doesn't apply in the 
case of AMT.

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Rémi Denis-Courmont | 3 Aug 2009 15:02
Picon

Re: UDP zero checksums and v4 to v6 translators

On Monday 03 August 2009 15:28:59 ext Pekka Savola wrote:
> On Mon, 3 Aug 2009, Lars Eggert wrote:
> > I see no reason why allowing a UDP checksum of zero for router-to-router
> > tunnels under specific circumstances (existence of a payload checksum),
> > which is what we've been discussing for AMT and LISP, motivates *any*
> > changes for the host. As far as hosts as concerned, nothing changes with
> > regards to RFC2460.
>
> While this is true for LISP, unfortunately an AMT tunnel endpoint may
> be a host; in fact it's likely it will be. :-/
>
> For the specific case of AMT, I wouldn't personally see a problem with
> IPv6 encapsulating plain IP instead of UDP, though this would
> complicate the spec slightly.  The LAG argument doesn't apply in the
> case of AMT.

I still don't understand why AMT cannot use a new Foobar protocol number.
Then we can specify that 64 translators translate:
- UDP/IPv6 to summed UDP/IPv4, and vice versa, and
- Foobar/IPv6 to unsummed UDP/IPv4, and vice versa.
And conversely, that LISP and AMT shall use Foobar instead of UDP in the case 
of IPv6.

Then, we can have a _constant_ checksum that protects the Foobar port numbers 
but not the inner packets. Basically it's just like UDP-Lite with 8-bytes 
coverage.

--

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
(Continue reading)

Permalink | Reply | 0 comments |

Gmane