Subject: [BEHAVE] DNS64, AAAA synthesis, and multihoming related question

From: <[email-masked]>
Date: Mon, 5 Oct 2009 10:50:25 +0200

Hi,

A question relating to DNS64 and multihoming. (I'm updating my DNS server selection draft: http://tools.ietf.org/internet-drafts/draft-savolainen-mif-dns-server-selection-00.txt )

The synthesised AAAA record may be constructed by using Network-Specific Prefix or Well-Known Prefix, right?

Let's assume we have a host connected to two networks which both employ protocol translators (both are IPv6-network-to-IPv4-Internet deployments).

In the case of Network-Specific Prefix, the synthesised AAAA record can only be used on the interface it was learned from (or synthesised for in stub resolver based DNS64)? Trying to send IPv6 packet to the synthesised IPv6 destination address on wrong interface would unlikely work, right? I.e. with Network-Specific Prefix, the AAAA record should only be used on the interface it was learned from (synthesised for)?

In the case of Well-Known Prefix, and non-private IPv4 destination address, the AAAA record should be used on the interface it was learned from (synthesised for), but in case both networks use WKP based Pref64, the synthesised AAAA record could actually be used on either interface, right?

In the case of Well-Known Prefix, and private IPv4 destination address [RFC1918], the AAAA record must only be used on the interface it was learned from (synthesised for).

To summarize: can it be stated that synthesised AAAA record should only be used on the network interface the host received one (or host synthesised it for)?

Thanks,

        Teemu

---

From: Simon Perreault <[email-masked]>
Date: Mon, 5 Oct 2009 07:38:44 -0400

On Monday 05 October 2009 04:50:25 [email-masked] wrote:
> To summarize: can it be stated that synthesised AAAA record should only be
> used on the network interface the host received one (or host synthesised it
> for)?

Well, theoretically one could query a DNS64 server on one interface and use 
its synthetic records on another, as long as the DNS64 and the NAT64 use the 
same prefix. In all currently envisaged use cases it will end up being the 
same interface.

So I would rephrase like this: a AAAA record synthesized by a DNS64 using a 
given Pref64::/n can only be used on a network interface where a NAT64 is 
available and is using the same Pref64::/n.

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 05 Oct 2009 15:19:03 +0200

[email-masked] escribió:
> Hi,
>  
> A question relating to DNS64 and multihoming. (I'm updating my DNS 
> server selection draft: 
> _http://tools.ietf.org/internet-drafts/draft-savolainen-mif-dns-server-selection-00.txt_ 
> )
>  
> The synthesised AAAA record may be constructed by using 
> Network-Specific Prefix or Well-Known Prefix, right?
>  
> Let's assume we have a host connected to two networks which both 
> employ protocol translators (both are IPv6-network-to-IPv4-Internet 
> deployments).
>  
> In the case of Network-Specific Prefix, the synthesised AAAA record 
> can only be used on the interface it was learned from (or synthesised 
> for in stub resolver based DNS64)? Trying to send IPv6 packet to the 
> synthesised IPv6 destination address on wrong interface would unlikely 
> work, right? I.e. with Network-Specific Prefix, the AAAA record should 
> only be used on the interface it was learned from (synthesised for)?
>  
> In the case of Well-Known Prefix, and non-private IPv4 destination 
> address, the AAAA record should be used on the interface it was 
> learned from (synthesised for), but in case both networks use WKP 
> based Pref64, the synthesised AAAA record could actually be used on 
> either interface, right?
well, but the problem that you may encounter here is that in the other 
interface, you don't have a NAT64 available, so packets addressed to the 
WK prefix are sink
So, if you are sure that there are NAT64 in both interfaces, then you 
could use synthetic AAAA RR with the WK prefix in any of them, but the 
problem is how to know that you have a NAT64 in the other interface.
I assume that if you receive a synthetic AAAA RR in one interface, then 
you can reach a NAT64 in that interface, but assuming that becuase you 
have received a synthetic AAAA RR in one interface you can reach a NAT64 
in the other one, doens't seem wise.

>  
> In the case of Well-Known Prefix, and private IPv4 destination address 
> [RFC1918], the AAAA record must only be used on the interface it was 
> learned from (synthesised for).
>  
WKP and private addresses are not supposed to be used together, so if 
you receive this, something went wrong

>  
> To summarize: can it be stated that synthesised AAAA record should 
> only be used on the network interface the host received one (or host 
> synthesised it for)?

That seems to be the safe side, yes.

Regards, marcelo

>  
>  
> Thanks,
>  
>         Teemu
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 05 Oct 2009 15:20:29 +0200

> available and is using the same Pref64::/n.

right, the problem that i guess Teemu has i how to guess if there is a 
NAT 64 in that interface. I think that a reasonable guess is that there 
ought ot be a NAT64 through the interface that you have recieved the 
synthetic AAAA RR, but not a clue about the other interfaces imho

Regards, marcelo

---

From: <[email-masked]>
Date: Mon, 5 Oct 2009 15:53:04 +0200

Thanks Marcelo and Simon,

I'm mainly looking at the aspect of a host learning synthetic AAAA record from one DNS server on one network interface: the host should not use the learned address on other network interfaces (unless they are actually facing the same network domain) even if the other interfaces would be more preferred for other reasons. 

E.g. if a host has learned synthetic AAAA from DNS server of IPv6 cellular access, it should not use it on some random IPv6-enabled WLAN access, but instead redo DNS query also on the WLAN interface.

Best regards,

	Teemu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext marcelo bagnulo braun
>Sent: 05 October, 2009 16:20
>To: Simon Perreault
>Cc: [email-masked]
>Subject: Re: [BEHAVE] DNS64, AAAA synthesis, and multihoming 
>related question
>
>> Well, theoretically one could query a DNS64 server on one interface 
>> and use its synthetic records on another, as long as the 
>DNS64 and the 
>> NAT64 use the same prefix. In all currently envisaged use cases it 
>> will end up being the same interface.
>>
>> So I would rephrase like this: a AAAA record synthesized by a DNS64 
>> using a given Pref64::/n can only be used on a network 
>interface where 
>> a NAT64 is available and is using the same Pref64::/n.
>>   
>
>
>right, the problem that i guess Teemu has i how to guess if 
>there is a NAT 64 in that interface. I think that a reasonable 
>guess is that there ought ot be a NAT64 through the interface 
>that you have recieved the synthetic AAAA RR, but not a clue 
>about the other interfaces imho
>
>Regards, marcelo
>
>> Simon
>>   
>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Oct 2009 10:24:43 -0400

On Mon, Oct 05, 2009 at 03:53:04PM +0200, [email-masked] wrote:

> record from one DNS server on one network interface: the host should
> not use the learned address on other network interfaces (unless they
> are actually facing the same network domain) even if the other
> interfaces would be more preferred for other reasons.

Not even that "unless" is right.  "The same network domain" is not
exactly meaningful in the context of resolution (or anyway it's often
not meaningful in the way people think it is).  Therefore, the
limitation should be that you only use results obtained by one
interface on that interface.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 5 Oct 2009 16:00:43 -0400

Hi Andrew,

> interface on that interface.

I agree with you. The DNS server information should be interface 
specific. This is the only scenario that is guaranteed to work.

Cheers
Suresh

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Oct 2009 16:15:24 -0400

> specific. This is the only scenario that is guaranteed to work.

Thanks.  Unless anyone objects, this stricture will be in the next
dns64 draft (on which I am working this week).

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: <[email-masked]>
Date: Mon, 5 Oct 2009 23:20:52 +0200

Thanks all, this is what I wanted to get confirmed. 

	Teemu

>On Behalf Of ext Andrew Sullivan
>Sent: 05 October, 2009 23:15
>To: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Oct 2009 13:47:31 +1100

The real problem is that RA's don't provide "site" information,
just link information.  If we had site information provided then
address selection rules would actually work.

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