Subject: Re: [BEHAVE] NAT64 and MIPv6

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 01 Sep 2009 10:54:16 +0200

Hesham Soliman escribió:
>
>
> => Please read my text above, I didn't suggest host changes. First we need
> to acknowledge an issue then figure out what to do about it.
>   
I certainly agree that we need to ack the issues and i think it is also 
important to document them, so people are aware of the limitations of 
the tools they are using.
In the case of NAT64, when used in conjunction with DNS64, we have some 
scenarios where it will present some issues.

The case that Wassim has pointed out is certainly one of them.

The case is:

MN is in an IPv6 only visited network with DNS64/NAT64 services
The home network is also IPv6 only and is providing DNS64/NAT64 services.

They prefix used in the two DNS64/NAT64 are different
 In particular, it should be noted that in case both networks use the WK 
prefix (which is the default prefix for the NAT64/DNS64) the problem 
does _not_ occur.

So, in case the MN is using the BT mode and using the DNS server from 
the visited network, then the communication will fail.

So, the possible ways to deal with this are:
- use the WK prefix (which is the default prefix) or,
- use the dns server of the home network, or
- implement dns64 in stub resolver mode in the MN

We can think of other configurations that will present problems, namely:

- Any situation where the host is using the dns server that is provided 
by a different entity than the one providing nat64 services. For 
example, if the host is using a remote dns server, which is not 
uncommon. The solutions for this one are similar tot he one for the case 
of MIP.

- A configuration where there is a recursive resolver sitting behind the 
dns64. In this case, the recursive resolver will query directly to the 
authoritative servers, so it won't receive the synthetic RR. (this is 
part of the issue that is being disucssed in the thread about what to do 
with the additional section info). the solution here seems to involve 
making the recursive resolver dns64 aware.

So, i agree that it makes sense to document the limitations of the 
proposed tools and describe ways to handle the limitations. I am not 
sure what is the best place to do this though. Probably the NAT64 and 
the DNS64 documents could be a good fit. Some part could also be 
included in the prefix document. another option would be to write a 
separate document. thoughts?

Regards, marcelo

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 01 Sep 2009 22:48:11 +1000

> separate document. thoughts?

=> I like the idea of having the limitations of the proposal in the same
document. I think it provides the read with a complete picture and it's
generally good practice to do that.

Hesham

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 01 Sep 2009 15:44:24 +0200

> generally good practice to do that.

right, the problem is that there are 4 documents related to the 
mechanisms involved int he problem, the dns64 one, the nat64 one, the 
doc defining the prefixes, and the framework document....

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 1 Sep 2009 07:12:23 -0700

> right, the problem is that there are 4 documents related to the mechanisms
> involved int he problem, the dns64 one, the nat64 one, the doc defining the
> prefixes, and the framework document....
>>

That said, is the best and most general solution to not make a
statement about MIPv6, but to state that DNS64, NAT64, and prefix64
all must be configured and managed as a single system.  Attempting to
mix different elements from different management domains may result in
unexpected behavior.   This is an operational assumption that i have
had, but it may be best to codify it here so that there is no more
confusion.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 1 Sep 2009 07:26:00 -0700

> => Hmm, I think linux, BSD  and Symbian are pretty major but I guess you
> disagree.
>

I don't disagree if the standard build supports it. My understanding
is that FreeBSD and Linux require a kernel patch to work with MIPv6,
in which case your scenario could read "your average kernel developer
at an IETF meeting tries to go to youtube ...."  :)  My ubuntu laptop
does not support MIPv6.

>  If a user would
>> like to have  MIPv6 work, they should conspire through non-technical
>> means to communicate using IPv6 (i know paying for v6 is a novel
>> idea), because that is the end-state the MIPv6 designers had in mind.
>> If we make the middle-box so smart, we will never get rid of it.  Or,
>> it will never be done.
>
> => I have no idea what you're talking about or what you think MIPv6
> desginers conspired to do. The point is there is a problem that first need
> to be acknowledged instead of delving into irrelevant discussions.

I did spend a lot of time looking at this when Wassim first sent out
his text.  I concluded at that point that he must have assumed mixing
DNS64 and NAT64 across service providers or domains within a service
provider.  Today, this type of issue is a considered an end user
configuration error.  If i statically configure my laptop to use my
work's private DNS server and I go home and cannot get DNS to resolve,
it is a configuration issue, not a failure or DHCP or DNS.  This
thread mentions that MIPv6 does not make any statements regarding
where the DNS is hosted, that is a problem.  We can make the general
statement that DNS64, NAT64, and Prefix64 must be part of one
administrative domain to ensure proper operation.

>
>>
>> I want NAT64 in my network because it is a needed interim step, but i
>> don't want to stop the network evolution there.  I need IPv6
>> end-to-end to be realized (NAT64 does have an exit strategy), then
>> MIPv6 will work great (if your firewall does not break it).
>
> => That's fine, but you can't force everyone in the world to be in lock step
> with your vision so things that break existing protocols should be
> documented with a pointer on what IETF concensus is for the solution, or
> lack of.

Not forcing anything.  I am just putting forward my deployment
scenario.  I agree that we need to explicitly say that DNS64, NAT64,
and Prefix64 do not stand on their own.  They should be viewed as a
system under a single management domain.

>> Cameron Byrne
>> Principal Engineer
>> T-Mobile USA

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 02 Sep 2009 00:46:09 +1000

> at an IETF meeting tries to go to youtube ...."  :)  My ubuntu laptop

=> FreeBSD *does* come with MIPv6 in its standard distribution. Linux has a
separate module. As I'm sure you know, you don't need a kernel developer to
load a module, it can be done almost seamlessly to the user. But, this is
not the issue that behave cares about. Even if MIPv6 was not supported by
anybody today (which is not the case), it doesn't mean we just assume this
to be the case 2-4 years from now. Makes no sense.

> it is a configuration issue, not a failure or DHCP or DNS.

=> Yes but he's not suggesting doing anything statically, he's using a
standard mechanism developed by IETF.

  This
> where the DNS is hosted, that is a problem.

=> It's a problem when you think about this scenario with NAT64 or when you
think about people storing local names in the DNS. Local names are a
separate issue and you do it at your own risk and there is usually
indicators for the user as to why something didn't resolve (e.g. I forgot to
connect to the office). But the case here is simply a clash between two
solutions. 

Hesham

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 1 Sep 2009 11:06:55 -0400

+1

Wassim H.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 01 Sep 2009 20:12:31 +0200

Cameron Byrne escribió:
> all must be configured and managed as a single system.

mmm, the must is a bit too strong i think
if the WK prefix is being used, the dns64 and the nat64 can be in 
different admin domains and everything works just fine

>   Attempting to

i think the assumption is lighter than that i.e. that the nat64 and the 
dns64 use the same prefix, which in the LIR prefix is likely to be true 
in the case of a single admin domain, but in the WK prefix case is broader

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 1 Sep 2009 11:32:13 -0700

On Tue, Sep 1, 2009 at 11:12 AM, marcelo bagnulo
braun<[email-masked]> wrote:
>>> mechanisms

I have know issues with making the language weaker.

> if the WK prefix is being used, the dns64 and the nat64 can be in different
> admin domains and everything works just fine

For my deployment scenario, i don't think the WK prefix is a good
option so i don't like to to engineer around it.

draft-miyata-behave-prefix64-02 covers some of the issues, but i
believe this text should also have covered that the WK prefix does not
lend itself well to load balancing across many NAT64 systems.  I would
like my DNS64 system to hand out different prefix64 based on loading
and resiliency, even if the DNS64 can round-robin prefix64 it allows
me to scale the NAT64 state and connections per second across many
systems.   This may be off topic for this thread, but this is the
reasoning why i think WK prefix is weaker than just using LIR
addressing.

Cameron

> dns64 use the same prefix, which in the LIR prefix is likely to be true in
> the case of a single admin domain, but in the WK prefix case is broader
>
>